[boost] Re: [gui] On Native Controls

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-12-24 06:04:31

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).

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 :).

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 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.

>   * 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 am going to look into this at some point, but other peoples feedback 
is most welcome. I know Andy Little has experience in this area.

Regards,
Reece