Here is an excerpt from D docs:

    GUI styles, philosophies, etc., are not portable from machine to
machine. A GUI Windows app should look like a Windows app when running on a
Windows machine. It should not look and feel like a Mac app unless it is
running on a Mac. Attempts to create a common GUI class library between
Windows, Mac, and other GUI operating systems have all to my knowledge
failed.  Java has a successful GUI class library, but does so by creating
its own
GUI with its own look and feel. This approach is fine for a web language,
but not for a systems language like D is.
Windowing class libraries should be separate.

I could help but notice the:
"Attempts to create a common GUI class library between Windows, Mac, and
other GUI operating systems have all to my knowledge failed."

Qt is a feature-rich cross platform GUI framework for C++: www.trolltech.com

Qt ports to Windows, Linux, and Mac all with a native look and feel.
Qt is what KDE for linux is built on.  Qt is what Borland Delphi, Borland
C++ Builder, and Borland Kylix are built upon.  I have used Qt for two years
now and found it to be the absolute best solution for high-performance
cross-platform software.  My application is written in C++ and works on
both Windows and Linux with a common source code base.

As D's specs and compiler become more mature, it will be essential that
D has a cross-platform GUI library.  Perhaps Qt could eventually be ported
to D?

-Craig

"Craig Black" <cblack@ara.com> wrote in news:akljhr$mcr$2@digitaldaemon.com:

> I could help but notice the:
> "Attempts to create a common GUI class library between Windows, Mac,
> and other GUI operating systems have all to my knowledge failed."
> 
> Qt is a feature-rich cross platform GUI framework for C++: www.trolltech.com
>
> Qt ports to Windows, Linux, and Mac all with a native look and feel.

Look&feel only remains "native" as long as M$ doesn't change GUI
once again (like they did in WinXP).

> Qt is what KDE for linux is built on.  Qt is what Borland Delphi, Borland C++ Builder, and Borland Kylix are built upon.  I have used Qt

Delphi is not Qt. Nor is C++Builder. Both are built on top of native Windows API, and they actually use _native_ widgets (and don't emulate them). So you can turn on XP styles for a Delphi program.

I don't have anything against Qt. It is a great thing, but it has its limitations.
Are you aware of any popular commercial Windows software written using
Qt?..

> As D's specs and compiler become more mature, it will be essential that D has a cross-platform GUI library.  Perhaps Qt could eventually be ported to D?

Then, how would you track the changes? It is a hard job... probably it's better to make an import module for Qt.

The proper way to design cross-platform libraries is to minimize all dependencies on the OS.  That means drawing your own widgets using a generic, cross-platform device context layer, rather than relying on native OS widget implementations.

A good example from the commercial world is LabVIEW, which is quite excellent on Windows, Mac, and Linux.  In the open-source world, I most admire the VCF library's philosophy (although it is still in early stages of cross-platform development and retains a few Windows API entanglements).

A poor example is wxWindows which basically wraps native APIs; consequently its code looks like a mess of #ifdefs.  Recognizing their design flaw, they have recently begun an effort called wxUniversal to implement the correct approach.

Mark

Mark Evans <Mark_member@pathlink.com> wrote in news:akm90b$1ebj$1@digitaldaemon.com:

> A good example from the commercial world is LabVIEW, which is quite excellent on Windows, Mac, and Linux.  In the open-source world, I

Didn't heard of it... URL please?

> most admire the VCF library's philosophy (although it is still in early stages of cross-platform development and retains a few Windows API entanglements).

VCF is quite far from completion. We shall see what it can do
when it is completed/

> A poor example is wxWindows which basically wraps native APIs; consequently its code looks like a mess of #ifdefs.  Recognizing their design flaw, they have recently begun an effort called wxUniversal to implement the correct approach.

Funny enough, I find wxWindows the best library. It is rather feature-
rich (at least for multiplatform library), and also because it uses native
widgets. I don't care for the source code - #ifdefs or whatever - it
just works fine for me...

The problem with this is that a "universal" set doesn't make anybody happy. People who use Windows generally do so because they like the way Windows looks and acts.  People who use Macintosh do so because they like the way Macintosh looks and acts.  People who use Linux do so because they like being able to make it act any way they want to...

If you make a universal set, you force everybody on all platforms to use the same thing, and nobody is happy  (unless you modelled your "universal" set on a pre-existing set, like the Windows controls, in which case Windows users are happy and everybody else hates you)

A true cross platform system would require some way to specify extremely high level concepts about what the application is attempting to do.  It would also have to have a constraint-based system for layout, since the application cannot be allowed to directly state where controls should go.  For some of the high-level concepts, it would even need to be illegal to specify _any_ layout constraints, because the eventual concrete expression of the high-level concept may have to be too variable to be constrained.

The a GAL (GUI abstraction layer) would have to be written that knew how to implement the high-level concepts in terms of not only the local native widgets, but also the local native GUI idioms.  It isn't sufficient to use all Macintosh widgets if you lay them out in a Windows arrangement and confuse the user.  It is also unacceptable to use Windows buttom naming and ordering schemes on Linux or Macintosh, where they expect different buttons and may be expecting (for example) OK and Cancel to be in the other order.

Layout idioms are extremely powerful.  My most hated example of breaking them comes from Microsoft itself.  VB comes with an installation set creation tool. The resulting installation set eventually gets to a dialog that looks like:  (my apologies to those of you using proportional width fonts -- I'll try to use some HTML to help at least some of you...)

<pre> +-------------------------------------------------------------+ |                                                             | |   +-------+                                                 | |   |  Pic  |                                                 | |   +-------+                                                 | |                                                             | |   +-----------------------------------------------------+   | |   | C:\program files\whatever                           |   | |   +-----------------------------------------------------+   | |                                                             | |                                      +------------------+   | |                                      | Stop Installation|   | |                                      +------------------+   | +-------------------------------------------------------------+ </pre>

Now, if you read the button, you realize that it is going to abort the installation.  However, that button is exactly where a default OK button should be.  _Any_ sane Windows developer would have put the OK or Continue button there.  Any _decent_ Windows developer would have put an OK button to the left of it, and then had the Cancel button.  That idiom has been in use since Windows 1.0.

Something else you may notice is that there is no OK button.  You have to click on the "Pic", which is a non-obvious button that appears to simply be pointless icon on the dialog.  Also notice that you can't do anything about the directory path from this dialog.  Nor can you back up.  You have to cancel and re-run the program...

This dialog breaks every single Windows dialog design rule.  Most existing cross-platform GUI libraries suffer from this sort of issue.  Resulting apps look fine on the platform where they were developed, but look like they were developed by Martians to users on a different platform.

As Microsoft wins the GUI wars (its happening, and I _really_ do not want to get into a flame war about it...) the other GUIs are taking on more and more of the Windows look-and-feel, or idioms.  If this continues, it will eventually be trivial to write a cross platform GUI library, 'coz all the GUIs will look the same.

Another issue is that for non-business applications, "platform standard" GUI idioms are increasingly irrelevant.  Photoshop, GIMP, WinAMP, Lightwave, Blender, and others have all pretty much just made up their own interface. Sure, they use the native widgets for things like file dialogs, but getting a native file dialog is one function call away for most platforms.  Everything else in the program is completely unique to their own program.  That's cross platform.  It's cross platform the way LabView does it.  And it is really popular for these kinds of applications.  But it will not fly for business applications.  An accountant or a technical writer wants their spreadsheet/word processor to look and work just like every other program on their machine.

And trust me on this, the average user cannot make the mental shift to a different user interface idiom.  For most people, it took so long to figure out how to use whatever machine they started on that they are unwilling to even try to learn a different system unless forced.  As programmers, we are used to more abstract thinking and are generally more flexible, which makes us think that it should be possible to make a "good enough" cross platform GUI library, or that we can just make up a whole new idiom and it'll be fine as long as we are consistent across platforms.  Well, very few individual users ever use more than one platform, so they don't care if you are consistent _between_ platforms.  But they definitely care if you are consistent with the hundred other applications they are already running.

As a side note, wxWindows is going to a "universal" set to fill in advanced functionality on platforms that do not have a corresponding widget of their own. For example, not all platforms have drag-and-droppable tree views that also support icons.  So, you either don't support it on any platform, or you make up something for the weaker platforms and continue to use the native widgets when available.  You could use the universal set on all platforms, but I think you would be setting yourself up for a large number of tech support calls reporting "bugs" in how your program works (just because it doesn't work the way the user expects, based on what it looks like).  If wxWindows users' code is full of #ifdef's, then wxWindows needs to be designed better -- they need to seriously investigate some of the abstract factory and related patterns.  If users' code is clean, and the #ifdefs are all inside the wxWindows code, that is fine.  Have you looked at STL source code?  It is completely unreadable because of all the #ifdefs.  Same for BOOST.  That doesn't mean they are poorly designed, it just means that doing anything cross-platform is a pain in the ____.  They are trying to hide all of that pain inside their libraries so that the users are not exposed to it.

I would like a GUI inside the language as well, but then I look at all the headaches that Java has had with the original AWT, then trying to migrate to Swing, and neither of them are actually guaranteed to be in the language, so you still have to do some kinda goofy stuff just in case you find yourself on an antiquated jvm.  On top of that, I don't like the look or the behavior of either AWT or Swing, but I would be stuck with it if I ever tried to do anything serious with Java.

A built in GUI system would be great, but the right solution hasn't been developed yet, and I wouldn't want to be tied down to any of the existing cross-platform libraries.  Maybe after everything else in D settles down, we can start developing that high-level abstract / GAL system I described earlier...

Mac

In article <akm90b$1ebj$1@digitaldaemon.com>, Mark Evans says...
>
>The proper way to design cross-platform libraries is to minimize all dependencies on the OS.  That means drawing your own widgets using a generic, cross-platform device context layer, rather than relying on native OS widget implementations.
>
>A good example from the commercial world is LabVIEW, which is quite excellent on Windows, Mac, and Linux.  In the open-source world, I most admire the VCF library's philosophy (although it is still in early stages of cross-platform development and retains a few Windows API entanglements).
>
>A poor example is wxWindows which basically wraps native APIs; consequently its code looks like a mess of #ifdefs.  Recognizing their design flaw, they have recently begun an effort called wxUniversal to implement the correct approach.
>
>Mark
>
>

> Look&feel only remains "native" as long as M$ doesn't change GUI
> once again (like they did in WinXP).
>
> Delphi is not Qt. Nor is C++Builder. Both are built on top of native Windows API, and they actually use _native_ widgets (and don't emulate them). So you can turn on XP styles for a Delphi program.

You are wrong about this.  Delphi CLX libraries use Qt which calls
 native Win32 APIs.  That's why you can now write completely portable
Delphi code using CLX. Look and feel is preserved in all cases (even in
WinXP).

> I don't have anything against Qt. It is a great thing, but it has its
limitations.
> Are you aware of any popular commercial Windows software written using Qt?..

You could be using Qt apps and never know it.  It's not like there's a
big banner when the program starts that says "This app was built using Qt."

"Craig Black" <cblack@ara.com> wrote in news:akonln$1d4j$1@digitaldaemon.com:

> You are wrong about this.  Delphi CLX libraries use Qt which calls
>  native Win32 APIs.  That's why you can now write completely portable
> Delphi code using CLX. Look and feel is preserved in all cases (even
> in WinXP).

Everybody still uses VCL when making programs for Windows.

>> Are you aware of any popular commercial Windows software written using Qt?..
> 
> You could be using Qt apps and never know it.  It's not like there's a big banner when the program starts that says "This app was built using Qt."

If I turn on XP visual styles for Qt program, will it behave accordingly? An easy way to know...

poppycock.  My wife is an accountant and when her hard drive crashed she walked right over to my computer and started using Gnome/Linux.  Her only issues were with Mozilla operating differently, but only minor and I had the same issues.  Why?  The look and feel is similar enough and my
"theme" setting is close enough that it didn't bother her and she barely noticed (I only had to explain "the foot is the start button" -- but I've had to explain to countless people you have to press start to shutdown on windows too).  She actually had more trobule ajusting to XP's default theme/etc.

Most user interface issues are faily universal and mimicing the windows look and feel on Linux or any other platform is generally elementry. The VB install screen was confusing....TO ANYONE used to any platform. However I should point out that IIRC it was relatively easy to modify.
You give Microsoft way more credit than they deserve.  They borrowed their ideas from others and others borrowed them back.

The great thing is that bar for creating user interfaces is really low.  Most user interfaces suck so horribly that you only have to make one as good as Windows, Gnome or KDE.

-Andy



Mac Reiter wrote:
> The problem with this is that a "universal" set doesn't make anybody happy.
> People who use Windows generally do so because they like the way Windows looks
> and acts.  People who use Macintosh do so because they like the way Macintosh
> looks and acts.  People who use Linux do so because they like being able to make
> it act any way they want to...
> 
> If you make a universal set, you force everybody on all platforms to use the
> same thing, and nobody is happy  (unless you modelled your "universal" set on a
> pre-existing set, like the Windows controls, in which case Windows users are
> happy and everybody else hates you)
> 
> A true cross platform system would require some way to specify extremely high
> level concepts about what the application is attempting to do.  It would also
> have to have a constraint-based system for layout, since the application cannot
> be allowed to directly state where controls should go.  For some of the
> high-level concepts, it would even need to be illegal to specify _any_ layout
> constraints, because the eventual concrete expression of the high-level concept
> may have to be too variable to be constrained.
> 
> The a GAL (GUI abstraction layer) would have to be written that knew how to
> implement the high-level concepts in terms of not only the local native widgets,
> but also the local native GUI idioms.  It isn't sufficient to use all Macintosh
> widgets if you lay them out in a Windows arrangement and confuse the user.  It
> is also unacceptable to use Windows buttom naming and ordering schemes on Linux
> or Macintosh, where they expect different buttons and may be expecting (for
> example) OK and Cancel to be in the other order.
> 
> Layout idioms are extremely powerful.  My most hated example of breaking them
> comes from Microsoft itself.  VB comes with an installation set creation tool.
> The resulting installation set eventually gets to a dialog that looks like:  (my
> apologies to those of you using proportional width fonts -- I'll try to use some
> HTML to help at least some of you...)
> 
> <pre>
> +-------------------------------------------------------------+
> |                                                             |
> |   +-------+                                                 |
> |   |  Pic  |                                                 |
> |   +-------+                                                 |
> |                                                             |
> |   +-----------------------------------------------------+   |
> |   | C:\program files\whatever                           |   |
> |   +-----------------------------------------------------+   |
> |                                                             |
> |                                      +------------------+   |
> |                                      | Stop Installation|   |
> |                                      +------------------+   |
> +-------------------------------------------------------------+
> </pre>
> 
> Now, if you read the button, you realize that it is going to abort the
> installation.  However, that button is exactly where a default OK button should
> be.  _Any_ sane Windows developer would have put the OK or Continue button
> there.  Any _decent_ Windows developer would have put an OK button to the left
> of it, and then had the Cancel button.  That idiom has been in use since Windows
> 1.0.
> 
> Something else you may notice is that there is no OK button.  You have to click
> on the "Pic", which is a non-obvious button that appears to simply be pointless
> icon on the dialog.  Also notice that you can't do anything about the directory
> path from this dialog.  Nor can you back up.  You have to cancel and re-run the
> program...
> 
> This dialog breaks every single Windows dialog design rule.  Most existing
> cross-platform GUI libraries suffer from this sort of issue.  Resulting apps
> look fine on the platform where they were developed, but look like they were
> developed by Martians to users on a different platform.
> 
> As Microsoft wins the GUI wars (its happening, and I _really_ do not want to get
> into a flame war about it...) the other GUIs are taking on more and more of the
> Windows look-and-feel, or idioms.  If this continues, it will eventually be
> trivial to write a cross platform GUI library, 'coz all the GUIs will look the
> same.
> 
> Another issue is that for non-business applications, "platform standard" GUI
> idioms are increasingly irrelevant.  Photoshop, GIMP, WinAMP, Lightwave,
> Blender, and others have all pretty much just made up their own interface.
> Sure, they use the native widgets for things like file dialogs, but getting a
> native file dialog is one function call away for most platforms.  Everything
> else in the program is completely unique to their own program.  That's cross
> platform.  It's cross platform the way LabView does it.  And it is really
> popular for these kinds of applications.  But it will not fly for business
> applications.  An accountant or a technical writer wants their spreadsheet/word
> processor to look and work just like every other program on their machine.  
> 
> And trust me on this, the average user cannot make the mental shift to a
> different user interface idiom.  For most people, it took so long to figure out
> how to use whatever machine they started on that they are unwilling to even try
> to learn a different system unless forced.  As programmers, we are used to more
> abstract thinking and are generally more flexible, which makes us think that it
> should be possible to make a "good enough" cross platform GUI library, or that
> we can just make up a whole new idiom and it'll be fine as long as we are
> consistent across platforms.  Well, very few individual users ever use more than
> one platform, so they don't care if you are consistent _between_ platforms.  But
> they definitely care if you are consistent with the hundred other applications
> they are already running.
> 
> As a side note, wxWindows is going to a "universal" set to fill in advanced
> functionality on platforms that do not have a corresponding widget of their own.
> For example, not all platforms have drag-and-droppable tree views that also
> support icons.  So, you either don't support it on any platform, or you make up
> something for the weaker platforms and continue to use the native widgets when
> available.  You could use the universal set on all platforms, but I think you
> would be setting yourself up for a large number of tech support calls reporting
> "bugs" in how your program works (just because it doesn't work the way the user
> expects, based on what it looks like).  If wxWindows users' code is full of
> #ifdef's, then wxWindows needs to be designed better -- they need to seriously
> investigate some of the abstract factory and related patterns.  If users' code
> is clean, and the #ifdefs are all inside the wxWindows code, that is fine.  Have
> you looked at STL source code?  It is completely unreadable because of all the
> #ifdefs.  Same for BOOST.  That doesn't mean they are poorly designed, it just
> means that doing anything cross-platform is a pain in the ____.  They are trying
> to hide all of that pain inside their libraries so that the users are not
> exposed to it.
> 
> I would like a GUI inside the language as well, but then I look at all the
> headaches that Java has had with the original AWT, then trying to migrate to
> Swing, and neither of them are actually guaranteed to be in the language, so you
> still have to do some kinda goofy stuff just in case you find yourself on an
> antiquated jvm.  On top of that, I don't like the look or the behavior of either
> AWT or Swing, but I would be stuck with it if I ever tried to do anything
> serious with Java.
> 
> A built in GUI system would be great, but the right solution hasn't been
> developed yet, and I wouldn't want to be tied down to any of the existing
> cross-platform libraries.  Maybe after everything else in D settles down, we can
> start developing that high-level abstract / GAL system I described earlier...
> 
> Mac
> 
> In article <akm90b$1ebj$1@digitaldaemon.com>, Mark Evans says...
> 
>>The proper way to design cross-platform libraries is to minimize all
>>dependencies on the OS.  That means drawing your own widgets using a generic,
>>cross-platform device context layer, rather than relying on native OS widget
>>implementations.
>>
>>A good example from the commercial world is LabVIEW, which is quite excellent on
>>Windows, Mac, and Linux.  In the open-source world, I most admire the VCF
>>library's philosophy (although it is still in early stages of cross-platform
>>development and retains a few Windows API entanglements).
>>
>>A poor example is wxWindows which basically wraps native APIs; consequently its
>>code looks like a mess of #ifdefs.  Recognizing their design flaw, they have
>>recently begun an effort called wxUniversal to implement the correct approach.
>>
>>Mark
>>
>>
> 
> 
> 

Thanks for a great article. You should submit it to the D User's Journal. -Walter

On Thu, 29 Aug 2002 11:59:56 -0500, "Craig Black" <cblack@ara.com> wrote:

>I could help but notice the:
>"Attempts to create a common GUI class library between Windows, Mac, and
>other GUI operating systems have all to my knowledge failed."
>
>Qt is a feature-rich cross platform GUI framework for C++: www.trolltech.com
>

And don't forget the new SWT from IBM used with Java
but written in a compiled language with multi-platform
abstractions. Maybe D should even use SWT.

Seriously, check it out if you have clout...