* 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. * 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. * It is an aspect of the View of MV[PC] and the developer must be able to choose the View that suits their application. I think native controls should be supported in the case of PalmOS, where you can't overlay them anyway. Or in the case of windowing libraries that allow their controls to be clipped, where the native controls will behave properly when overlayed, and thus can take part in a complicated layout. -- Alan Gutierrez - alan@engrm.com
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
* Reece Dunn <msclrhd@hotmail.com> [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@engrm.com
Reece Dunn wrote:
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.
How can you have (natively) a button with text+image, in Win32? Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- http://www.torjo.com/cb/ - Click, Build, Run!
* 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.
"Alan Gutierrez" <alan-boost@engrm.com> wrote in message news:20041224075257.GB9515@maribor.izzy.net... this is simply not true for the mac. if you don't use native controls on a mac you might as well not support the mac at all mac users have come to expect a very consistent ui experience (spoiled rotten as they are). if it does not look right, they won't look twice at your product regards, /michael toksvig
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. my 2c martin michael toksvig wrote:
"Alan Gutierrez" <alan-boost@engrm.com> wrote in message news:20041224075257.GB9515@maribor.izzy.net...
* 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.
this is simply not true for the mac. if you don't use native controls on a mac you might as well not support the mac at all
mac users have come to expect a very consistent ui experience (spoiled rotten as they are). if it does not look right, they won't look twice at your product
regards,
/michael toksvig
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.6.4 - Release Date: 22/12/2004
* Martin Slater <mslater@hellinc.net> [2004-12-26 00:38]:
my 2c
martin
michael toksvig wrote:
"Alan Gutierrez" <alan-boost@engrm.com> wrote in message news:20041224075257.GB9515@maribor.izzy.net...
* 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.
I officially regret saying this. It was not the point.
this is simply not true for the mac. if you don't use native controls on a mac you might as well not support the mac at all
mac users have come to expect a very consistent ui experience (spoiled rotten as they are). if it does not look right, they won't look twice at your product
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. -- Alan Gutierrez - alan@engrm.com
* Alan Gutierrez <alan-boost@engrm.com> [2004-12-26 01:36]:
* Martin Slater <mslater@hellinc.net> [2004-12-26 00:38]:
my 2c
martin
michael toksvig wrote:
"Alan Gutierrez" <alan-boost@engrm.com> wrote in message news:20041224075257.GB9515@maribor.izzy.net...
* 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.
I officially regret saying this. It was not the point.
this is simply not true for the mac. if you don't use native controls on a mac you might as well not support the mac at all
mac users have come to expect a very consistent ui experience (spoiled rotten as they are). if it does not look right, they won't look twice at your product
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. -- Alan Gutierrez - alan@engrm.com
Alan Gutierrez wrote
* Martin Slater <mslater@hellinc.net> [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. 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? Regards Andreas Pokorny -- +++ Sparen Sie mit GMX DSL +++ http://www.gmx.net/de/go/dsl AKTION f�r Wechsler: DSL-Tarife ab 3,99 EUR/Monat + Startguthaben
"Andreas Pokorny" wrote: [snip]
I have the feeling that a gui library has to many different customers, and wishes to make that all available in a single library.
[snip]
Is there a solution that satisfies all users?
May it be possible to develop several GUI libraries independently who share common functionality? For example - data conversions, - data validation, - events handling subsystem, - providing runtime reflection functionality - user specific settings (or themes) - undo-redo module, - (hooks for) scripting, could be universal. /Pavel
* Pavel Vozenilek <pavel_vozenilek@hotmail.com> [2004-12-26 06:14]:
"Andreas Pokorny" wrote:
[snip]
I have the feeling that a gui library has to many different customers, and wishes to make that all available in a single library.
[snip]
Is there a solution that satisfies all users?
May it be possible to develop several GUI libraries independently who share common functionality?
For example - data conversions, - data validation, - events handling subsystem, - providing runtime reflection functionality - user specific settings (or themes) - undo-redo module, - (hooks for) scripting,
could be universal.
Agreed. Many UI libraries are a tree rooted at component. But there is more to a UI than components. There are many different aspects of a UI and they can be made resuable. -- Alan Gutierrez - alan@engrm.com
* Andreas Pokorny <dieMumiee@gmx.de> [2004-12-26 05:02]:
Alan Gutierrez wrote
* Martin Slater <mslater@hellinc.net> [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@engrm.com
participants (7)
-
Alan Gutierrez -
Andreas Pokorny -
John Torjo -
Martin Slater -
michael toksvig -
Pavel Vozenilek -
Reece Dunn