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

From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2004-12-24 09:42:30

* Reece Dunn <msclrhd_at_[hidden]> [2004-12-24 07:07]:
> Alan Gutierrez wrote:
> >  * I don't think it matters much, to the user, if the button they
> >    click is a Motif button or an Aqua button, so long as their form
> >    is processed. Go to Amazon. All the buttons there are images.
> 
> True, but you still need native as an option. Windows allows buttons to 
> be either text, image or text+image. I don't yet support images because 
> I do not have a graphics class to represent images yet. When I do, I 
> will allow images in buttons.

> You must also consider how native controls interact with the OS. For 
> example, how are key presses handled? Accessability support? Having a 
> button as a native object allows it to interact with things like screen 
> readers and people who use the keyboard as their main input device (I 
> use a lot of the keyboard shortcuts in Windows for speed).

    Accessability. You got me. Complex and important.
    
    I just can't stand how you can't clip a combo box on a web page.
    The bane of the DHTML developer.

    This might be addressed by creating that XML + CSS control, and
    using that to create the skin for UI components.

> Native interoperability also means things like having the correct menu 
> nomenclature for the specific OS, responding to CTRL-P in Windows for 
> printing. It also means using WinXP L&F when this is applicable.
> 
> Having said that, this should be the default behaviour of an 
> application. This allows you to create a UI based on the components and 
> not having to worry about supporting Windows XP-specific logic to handle 
> themes properly. It should just work :).

    Yeah. I think that web applications drive home the just work
    aspect of things. If I'm using this GUI library to assemble an
    application UI for an OS X application, and it just happens to
    also work on SGI, well, bonus, but I'm not likely to run through
    that build and ensure that the application supports the Solaris
    nomenclature.

    This discussion recalls the SWT library, and the hubub in the
    Java community when it was released. It was a break with Swing.
    It choose to support native controls, but to use Java controls
    when native controls where not available. (Most recently, SWT
    has gone to supporting it's own L&F, so I don't know what
    happened.)

    Also, you mentioned Thunderbird in another post, and I was
    suprised at how Aqua the preferences pane looked, when I know
    that it is an XML document. Now I've very interested in what
    choices Mozilla makes for native versus XUL L & F, since I know
    Mozilla clips dialog controls on Win32.

> The library should allow for you to provide owner/custom draw 
> functionality to provide a custom L&F. For example, allow your 
> application to be skinned like Mozilla Firefox/Thunderbird, WinAMP, 
> Windows Media Player, etc.

    I keep touting XML + CSS.
    
    I've said elsewhere that, since we are talking about a modern
    C++ library, actually using XML or CSS is not a requirement.
    Shipping an XML or CSS parser on a cell phone is not a
    requirement. If one develops an XML + CSS renderer, one could
    skip the XML + CSS, and express the L & F using C++ templates,
    or the Boost Python library.

    I'll note that part of a successul skinnable application, is the
    ability for graphic designers to express the design, and graphic
    desingers are more familiar with XML + CSS than generic programming.

> I need to work out how to support lightweight components that do not 
> consume OS resources for GUI components. Examples of this are the layout 
> managers that act like components, i.e. they need to consume events, but 
> do not take up resources on the OS.

    Huzzah!

> >  * Dealing with Win32 GDI controls is pain. Because they consume a
> >    Win32 window they are not going to place nice a more complex
> >    layout like a grid or a document. They are so few an simple, it
> >    is trivial to replicate them.
> >
> >    The Win32 GDI is going to be a real problem, and it will put
> >    unnecessary design constraints on the GUI library if its poor
> >    behavior is enabled.
> 
> I think we need to do a comparison of how graphics is handled between 
> different systems: Win32/GDI, Win32/GDI+, Win32/DirectX, OpenGL, X11, etc.

  ~ I'll eat my comments, trivial and simple, in light of accessability. 

  ~ It seems like, from looking at some applications (SWT/Eclipse,
    XUL), that native controls are not the quite the bugbear other
    operating systems. It is my understanding that X11 and Carbon
    controls are "lightweight".

  ~ What else goes into a control? Because if the GUI library
    will have to provide accessibility facilities, and once done, it
    might be less challenging to roll Boost GUI implementations.

    These are facilities that I've known operating systems to
    provide:

    - Accessibility.
    - OS hot-key nomenclature.
    - OS colors, look and feel.
    - Text direction.
    - Spell checking (on OS X).
    - Cut and paste.

--
Alan Gutierrez - alan_at_[hidden]