Re: [boost] Re: [gui] On Native Controls

From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2004-12-26 06:34:54

* Andreas Pokorny <dieMumiee_at_[hidden]> [2004-12-26 05:02]:
> Alan Gutierrez wrote
> > > * Martin Slater <mslater_at_[hidden]> [2004-12-26 00:38]:
> > > > Seconded, I dislike immensely UI's that do not have a native look. In 
> > > > the end they just look unprofessional to me. The're fine for hacking 
> > > > quick tools together but if the product is intented to be released to 
> > > > the wider public they must look and feel like the native OS apps.
> > > 
> > >     As noted elsewhere, providing native look and feel in a UI
> > >     manager is not the challenge on Macintosh, where the controls
> > >     are designed to particpate in any aspect of UI.
> > > 
> > >     I want look and feel. Aqua look and feel for Mac. Skinnable look
> > >     and feel for media gizmos. Pen oriented look and feel for handhelds.
> > > 
> > >     I'm only trying to raise a red flag and say that a simple
> > >     wrapper around the UI widgets is not enough. That look and feel
> > >     is a pretty big issue, especially with the Win32 GDI, native
> > >     controls do not participate in overlayed layout managment.
> >     
> >     That last part was suppposed to read:
> > 
> >         That look and feel is a pretty big issue, especially when,
> >         with the Win32 GDI, native controls do not participate in
> >         overlayed layout managment.
> 
> I have the feeling that a gui library has to many different customers, 
> and wishes to make that all available in a single library. I would love
> to see a library that allows really cute self made themes, and simplifies
> extending the library with custom widgets, by adding a class that uses a
> vector rendering library, like for example Anti-Grain-Geometry. 

    That is, actually, an excellent architecture.

    I'd like to have a Document library, that I could use to render
    reflowing edit controls, and a Canvas library that could be used
    to render vector graphics controls. Furthermore, I think they
    should be independent of each other.

> But already these two wishes create lots of problems. Then there are again 
> other people that want to only take care about the data presented, and just
> want the library to display the data in a gui. E.g an application could run 
> as ncurses, fb or x11 gui, without rebuilding the code. 

> And then there are users that want the native look and feel. Here the
> differences between the gui systems might make applications 
> written for the library unportable. 

> Then one might think that the time for simple 2D gui is over, and that we 
> should think about the next level of user interfaces, and write a library
> that presents data in a completetly different way. 3D Controls on curved 
> surfaces spread in a view frustum with perspective projection. 

> Is there a solution that satisfies all users?

    I think that part of the problem with GUI libraries is that they
    are based on an object heirarchy. That with generic programming,
    aspects of GUI programming can be added or removed.
    
    The everything is a widget concept, or everything is a window,
    does not address the wide array of devices on which an
    application must today run.

    Indeed, my FGDC taxonomy, was put forward, because I envisioned
    writing PalmOS Form applications, and for that I'll have no call
    for a vector redering library. But that should not matter.
    
    When filling out a data structure, I should be able to say,
    choose 1 of N items, and not be overly concerned of how that is
    being said. If I'm designing a UI, I should be able to choose a
    a radio set, or a drop down, and not be too concerned about the
    look and feel. I might choose a different "controled vocabulary"
    section device when on PalmOS than on OS X, but the "controled
    vocabluary" is a universal data entry concept.

    Even if you are on a desktop, once you've created your custom
    widget with your vector rendering library to create your drop
    down list, you don't want to have to get to your selection
    through the vector rendering library.

    I think a powerful GUI library realizes that you can't use the
    same code on different platforms, but you can use same idioms.

    Another reason for FGDC, is to raise the concern that advanced
    vector graphics comes at a cost, and shouldn't be a part of some
    UI idioms. An XML Document can be rendered using axis-aligned
    boxes, fonts and that's it. If my target already, has an image
    library, I can ship without code that draws a curve.

    However, if I did want vector graphics in my document, I can
    flow a vector graphics renderer into the flow of the document,
    just like an image. If I want a nicely formatted call-out on my
    ER diagam, I can give a document renderer a co-ordiante in the
    vector graphics canvas.

    There is, of course, so solution to statify all users, but the
    native component issues have been resolved time and again, the
    separation of rendering from model is expressed in MV[CP].

    I feel that the 2d GUI has only recently evoloved to the point
    where development time and cost are getting reduced, and that an
    integration of UI concepts is due.

    In closing, I don't expect to be able to recompile a spreadsheet
    written for OS X and have it run on PalmOS. I do expect that
    when I have to write a PalmOS form, or write an OS X dialog box,
    that I can use the same language, libraries and idioms.

    Thank you for the provocative question.

--
Alan Gutierrez - alan_at_[hidden]