www.digitalmars.com         C & C++   DMDScript  

D - Cross platform GUI library

reply "Craig Black" <cblack ara.com> writes:
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
Aug 29 2002
next sibling parent reply Pavel Minayev <evilone omen.ru> writes:
"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.
Aug 29 2002
next sibling parent reply Mark Evans <Mark_member pathlink.com> writes:
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
Aug 29 2002
next sibling parent Pavel Minayev <evilone omen.ru> writes:
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...
Aug 29 2002
prev sibling next sibling parent reply Mac Reiter <Mac_member pathlink.com> writes:
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
Aug 30 2002
next sibling parent andy <acoliver apache.org> writes:
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
Aug 31 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
Thanks for a great article. You should submit it to the D User's
Journal. -Walter
Sep 01 2002
prev sibling parent Toyotomi <io219 attbi.com> writes:
On Thu, 29 Aug 2002 22:59:24 +0000 (UTC), Mark Evans
<Mark_member pathlink.com> wrote:


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.


No actually this is the 'right way', but wrong is better here.

If wrong wasn't better I'd be using Swing, but Swing is horrid.

See SWT from IBM, it's the best stab at this yet... 

I use it in COMPILED Java apps that end up being 600k completely self
contained and redistributable without any Java crap on the user's PC...

Some SWT articles here in a whole section title 'SWT'
http://www.eclipse.org/articles/index.html
Sep 01 2002
prev sibling next sibling parent reply "Craig Black" <cblack ara.com> writes:
 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."
Aug 30 2002
next sibling parent Pavel Minayev <evilone omen.ru> writes:
"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...
Aug 30 2002
prev sibling parent Toyotomi <io219 attbi.com> writes:
On Fri, 30 Aug 2002 16:28:45 -0500, "Craig Black" <cblack ara.com> wrote:


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


Actually CLX in Windows is fairly looked down upon because of the added
requirements of the QT runtime being distributed.


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


There is though... to those that know how to look.
Sep 01 2002
prev sibling next sibling parent Toyotomi <io219 attbi.com> writes:
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?..


Opera the web browser...
Sep 01 2002
prev sibling parent reply Mark T <Mark_member pathlink.com> writes:
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?..


We use a product (VectorCAST) at work that developed it's GUI with Qt. They are
a small outfit and they need to support Windows and UNIX/Linux platforms.
As long as you are not doing pixel level type stuff then cross-platform GUI is a
great way to achieve easy portability. It basically has a Windows "look and
feel" on each platform.
Nov 01 2002
parent Ilya Minkov <midiclub 8ung.at> writes:
Mark T wrote:

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




Not directly. Delphi's complete windows GUI class libarary was ported to 
other systems (Kylix for Linux) using Qt. It is said to reatain its 
complete functionality. I'm pretty much sure, that the GUI library that 
would resemble Delphi's would be good for D, since it contains no 
windows-specifics, and there has been done a lot: an X windows port made 
for FPK pascal already exists and is open-source, which may simplify 
further development.
Dec 29 2002
prev sibling parent reply Toyotomi <io219 attbi.com> writes:
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...
Sep 01 2002
next sibling parent reply Mark Evans <Mark_member pathlink.com> writes:
 And don't forget the new SWT from IBM used with Java


VCF was inspired by SWT, Delphi, and Qt among other things.  It endeavors to be
a pure, standard C++ cross-platform toolkit.  It still has a long way to go, but
having examined others (and their prices!) I think highly of it at least from a
philosophical standpoint.

Someone pointed out that layout managers are Good Things, and they are.

It's pretty easy to create imitation look & feel for Mac/Win/Linux.  Some
toolkits call this technique "skinning."  I've heard from more than one source
that it's easier to do that, than to wrap all the native GUI APIs with their
weird peculiarities, bugs, and endless changes.  After all, wxWindows has been
doing just that for 10 years, but finally came around to their wxUniversal
concept.

Another benefit of the "universal device context" approach is that I don't have
to be expert in three different APIs to write new widgets, just expert in the
library's API.  A good cross-platform GUI library uses the OS only for minimal,
baseline capabilities -- keystrokes, mouse clicks, cursor positions, and file
services.

I believe that REBOL uses this technique for its REBOL/View platform which runs
on dozens of operating systems.

Of course if one drops the cross-platform requirement on the GUI, then all of
the above is meaningless.  You can just use the native API.  Still one should
strive whenever possible to utilize cross-platform toolkits and I hope that D
will someday rank as one of them!

Mark
Sep 02 2002
next sibling parent reply "Robert M. Münch" <robert.muench robertmuench.de> writes:
"Mark Evans" <Mark_member pathlink.com> schrieb im Newsbeitrag
news:al0tjq$1ovl$1 digitaldaemon.com...


 It's pretty easy to create imitation look & feel for Mac/Win/Linux.  Some
 toolkits call this technique "skinning."  I've heard from more than one


source

 that it's easier to do that, than to wrap all the native GUI APIs with


their

 weird peculiarities, bugs, and endless changes.  After all, wxWindows has


been

 doing just that for 10 years, but finally came around to their wxUniversal
 concept.


Hi Mark, for a GUI library that draws the widget itselft have a look at
OpenAmulet (http://www.openip.org) This library supports a layout manager as
well. This concept is implemented by using constraints and a multi-way
constraint solver. Very powerful concept.


 Another benefit of the "universal device context" approach is that I don't


have

 to be expert in three different APIs to write new widgets, just expert in


the

 library's API.


Right. In OpenAmulet the widgets are implemented using the basic library
functions, and only these are mapped to the platform API.


 I believe that REBOL uses this technique for its REBOL/View platform which


runs

 on dozens of operating systems.


(Hey Mark know you from the Rebol ML ;-)). IMO they have implemented a
portable blitting engine. Most /View stuff is blitting etc. Graphic
primitives like lines etc. are implemented within the Rebol interpreter
utilizing only the blitting functions. So, yes, they have implemented line
drawing algorithms etc. and yes, it's not as fast as if you would use the
navtive OS functions (that are than perhaps mapped to the hardware
implemented functions of the graphic card).

For me using Rebol for the GUI and D for the things that need to be fast and
efficient is a very powerful combination. That's what I want to do :-)).
Robert
Sep 03 2002
parent reply Mark Evans <Mark_member pathlink.com> writes:
Hi Mark, for a GUI library that draws the widget itselft have a look at
OpenAmulet>


I like OpenAmulet, but the project has gone stale; no one works on it any more.
Yes, layout managers are powerful and cool.


 If C++ had something as good as the VCL, we wouldn't even need D


I have difficulty interpreting your comments.  D is better than C++, and of
course we want it, VCF or otherwise.  I see no evidence for VCF being vaporware
or falling behind schedule.  Sorry that the Berlin project did not make it.

Maybe it's time to bring the discussion back around to the question, "what kind
of GUI(s) should D have?".  After all, having a great programming language that
can't create interfaces will be bad news for D.

I don't have an easy answer...Mark's disclaimer!

Mark
Sep 06 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Mark Evans" <Mark_member pathlink.com> wrote in message
news:albltl$39t$1 digitaldaemon.com...

 Maybe it's time to bring the discussion back around to the question, "what


kind

 of GUI(s) should D have?".  After all, having a great programming language


that

 can't create interfaces will be bad news for D.


Why not just port one of the C++ open source ones?
Sep 06 2002
next sibling parent reply Pavel Minayev <evilone omen.ru> writes:
Walter wrote:


 Why not just port one of the C++ open source ones?


I'm afraid discussing which one to choose means starting a flame war. =)
Sep 07 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:ald5be$1h7f$2 digitaldaemon.com...

 Walter wrote:

 Why not just port one of the C++ open source ones?


 I'm afraid discussing which one to choose means starting a flame war. =)


I'd like to make the point that there will be no gui as part of D. There may
be plenty of gui toolkits for D, and some may even ship with D compiler
packages, but D itself should not be tied to any particular gui ideas.

Anyone who believes strongly that a gui should be done a certain way won't
get any argument from me, other than encouragement to implement it in D! D
will be better off having a rich assortment of gui toolkits available.
Sep 07 2002
parent Mark Evans <Mark_member pathlink.com> writes:
Anyone who believes strongly that a gui should be done a certain way won't
get any argument from me, other than encouragement to implement it in D! D
will be better off having a rich assortment of gui toolkits available.


Fully agreed, Walter!  The more the better!

D does not need "built-in GUI support" any more than C++.

Mark
Sep 08 2002
prev sibling parent reply Mark Evans <Mark_member pathlink.com> writes:
Why not just port one of the C++ open source ones?


That's possible.  I would argue instead for something like a SWIG wrapper that
can make C++ accessible to D without rewriting the whole library; e.g. the way
that wxPython works with wxWindows.

Developing and maintaining a D port is a huge proposal, but maintaining a D
interface to the C++ is manageable.  The burden of feature enhancements and bug
fixes remains on the shoulders of the C++ library developers.

Mark
Sep 08 2002
parent "Walter" <walter digitalmars.com> writes:
"Mark Evans" <Mark_member pathlink.com> wrote in message
news:algbei$2i6b$1 digitaldaemon.com...

Why not just port one of the C++ open source ones?


 That's possible.  I would argue instead for something like a SWIG wrapper


that

 can make C++ accessible to D without rewriting the whole library; e.g. the


way

 that wxPython works with wxWindows.

 Developing and maintaining a D port is a huge proposal, but maintaining a


D

 interface to the C++ is manageable.  The burden of feature enhancements


and bug

 fixes remains on the shoulders of the C++ library developers.


That's probably the right initial way to do it, especially if it is a large,
complex code base.
Sep 08 2002
prev sibling parent "Robert M. Münch" <robert.muench robertmuench.de> writes:
"Mark Evans" <Mark_member pathlink.com> schrieb im Newsbeitrag
news:albltl$39t$1 digitaldaemon.com...


 I like OpenAmulet, but the project has gone stale; no one works on it any


more.

Hi, yep that's the petty. I really don't have any time to spend on it..
:-(( even it has such a great concept. And noone else took the stake. Robert
Sep 08 2002
prev sibling parent Toyotomi <io219 attbi.com> writes:
On Mon, 2 Sep 2002 23:52:26 +0000 (UTC), Mark Evans
<Mark_member pathlink.com> wrote:


 And don't forget the new SWT from IBM used with Java


VCF was inspired by SWT, Delphi, and Qt among other things.  It endeavors to be
a pure, standard C++ cross-platform toolkit.  It still has a long way to go, but
having examined others (and their prices!) I think highly of it at least from a
philosophical standpoint.


If C++ had something as good as the VCL, we wouldn't even need D, that's
how strong a supposedly impossible or constantly failing toolkit is.

However, as long as something is vaporware there isn't much that can be
said about it. I remember talking to Graydon Hoare of the Berlin
Consortium about 4 or 5 years ago and being told about the now laughable
and definitely missed timeline of that project. www.berlin-consortium.org
Sep 05 2002
prev sibling parent reply Toyotomi <io219 attbi.com> writes:
On Sun, 01 Sep 2002 20:43:26 -0500, Toyotomi <io219 attbi.com> wrote:


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


The problem is, like C++, those C++ toolkits do not suit us.
SWT is the best I know of ( though VCL is more complete & flexible )
SWT was designed for use with Java but is NOT written in Java.
( Java2D is not written in Java either, it's straight portable C )
SWT is multiplatform, but uses native widgets when possible.
Someone should work on getting SWT support in D.

90% of the many C++ toolkits are rather hilarious.
Sep 09 2002
next sibling parent Pavel Minayev <evilone omen.ru> writes:
Toyotomi wrote:


 SWT was designed for use with Java but is NOT written in Java.
 ( Java2D is not written in Java either, it's straight portable C )
 SWT is multiplatform, but uses native widgets when possible.
 Someone should work on getting SWT support in D.


Where can I download SWT as a separate package?
Sep 09 2002
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
"Toyotomi" <io219 attbi.com> wrote in message
news:rp2qnu8bdjp3j9helj81oai1cts650s4l7 4ax.com...

 SWT was designed for use with Java but is NOT written in Java.


Which is why Java is not a systems language.


 90% of the many C++ toolkits are rather hilarious.


Sure. That leaves 10% which can be mined for great ideas!
Sep 09 2002
prev sibling parent reply Curtis d'Entremont <038535d acadiau.ca> writes:
Toyotomi wrote:


 On Sun, 01 Sep 2002 20:43:26 -0500, Toyotomi <io219 attbi.com> wrote:
 

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


 
 The problem is, like C++, those C++ toolkits do not suit us.
 SWT is the best I know of ( though VCL is more complete & flexible )
 SWT was designed for use with Java but is NOT written in Java.
 ( Java2D is not written in Java either, it's straight portable C )
 SWT is multiplatform, but uses native widgets when possible.
 Someone should work on getting SWT support in D.
 
 90% of the many C++ toolkits are rather hilarious.


SWT is written almost completely in java. There is a small native dll/so 
written in C, but this is nothing more than a bridge to the native OS 
calls, with no functionality. Trust me on this one, I used to work on the 
SWT team.

Curt
Oct 30 2002
next sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
 SWT is written almost completely in java. There is a small native dll/so
 written in C, but this is nothing more than a bridge to the native OS
 calls, with no functionality. Trust me on this one, I used to work on the
 SWT team.


I've been looking through the SWT code, very interesting, especially the
thick layering (multipul versions of the same high level class)  rather than
more layers of wrapper classes (like the AWT with its Peer Classes).

one complaint I would have about this is maintanability, and reliance on
underlying OS support not changing
features like CoolBars, are emulated under GTK, and are mapped to the Win32
common control if present on Win32. (good thing/bad thing I'm not 100%
desided)

so here's my 10pen'th on cross-platfrom GUI's

Java forces some rather unpleasant effects within the SWT i.e. the win32
Control has 60+ virtual functions just to handle the windows messages. I
know that Delphi has a dynamic method that the VCL uses to reduce the vtable
usage (quite what they are I don't know) and my own beginings of a GUI
Library I chose to use a uint to delegate assoc array to handle the
messages. if there was a language feature many GUI libraries require its
call by id, (where id is an int).
the gtk's use of strings and callbacks lowers this to about 20.

when I started working on my Gui code, I had the feeling it should be "all
or nothing" with respect to features
so I wrote it to just ease Message handling, so it processes all messages,
WM_COMMAND/NOTIFY are separated out becuase they are message groups in
themselves and WM_DESTROY is processed.
every thing else is just a message including paint
if you want the paint message you attach a delegate that takes a HDC as a
param and in there all graphics are done by using standard win32 calls.
meaning that the only difference between writing in Win32 C and my lib, is
you never have to use SendMessage or write a WndProc. all the rest is the
same (ish).

then I intended to write a cross-platform GUI lib over the top using just
two base classes (written for each underlying OS and with no dependant
features)
NativeRootFrame and NativeBaseWidget
with all message passing, rendering and other stuff handled by OS/Platform
independant code.

but stumbled straight back to the "all or nothing",
and just ended up with a list of questions:

how rich does the 2D Gui API have to be ?
you can get by with a renderable Widget that has horizontal and vertical
straight line draw, pixel plot, rect fill, image 1:1 render, and text
rendering support.
draw/fill arc is nice if you want MacOS/PalmOS rounded buttons (transparent
images can be use)

OS/GUI library each have their own Mouse behaviours e.g. Windows, Beos, GTK,
Java AWT
which one is "right" ?

can a widgets children overlap each other ?
when you put radio buttons visually into a frame , should they be children
of the frame or of the dialog (like the frame is)  [my vote is no
overlapping] ?

Resources or Dynamic creation only ? [I'm in favor of a good XML based OS
independant Resource format]

which is more important syntax (and ease of programming an app) or
implemented features ?
[I think syntax, today, tomorrow I'll want features  :) ]

how cross platform is cross platform the same as the compiler (win32 and
GTK), planned for most GUI OS's(win32, Beos, GTK, X (no gtk or motif),
MacOs, WinCE, PalmOS) or anything with a screen (including embedded, Gamboy
Advance, Playstations etc) ?

well that was more like £2.50 but never mind.
Oct 31 2002
prev sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
Just found this
http://www.geocities.com/SiliconValley/Vista/7184/guitool.html
the only item it misses that I know about is TurboVision even has a link to
Netscapes IFC (Java)


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




 90% of the many C++ toolkits are rather hilarious.


 SWT is written almost completely in java. There is a small native dll/so
 written in C, but this is nothing more than a bridge to the native OS
 calls, with no functionality. Trust me on this one, I used to work on the
 SWT team.
Oct 31 2002