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

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

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.

> 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

"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

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

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

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

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

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