Josh Stern wrote:

>>I mean, having a library written in D is still a nice future goal and I think the current DWT is not a bad choice for such a big porting effort. (Java, or even C#, is actually easier to port to D - than what C++ is)
> 
> "Nice" is hard to argue with.  I mean, running on an OS that had a native
> D API might also be "nice" (in the way LISP machines were nice for LISP). But saying that therefore trying to write a new OS, or at least a new
> libc, in D is the right way to go is whole different kettle of fish.

I was naively assuming that the library would eventually end up linking to system libraries, and that those were the main ones involved here...
But maybe Qt and GTK+ are more like actual system libraries (at least on Linux) than graphical toolkits, though ? (i.e. comparable to Win32 etc.)

But if the "other library" (wx or tk or similar) only wraps the system libraries, then it feels like losing one wrapper layer could be a goal ?

> Clearly writing a state of the art GUI lib from scratch is not nearly as
> hard as writing a state of the art OS and drivers from scratch and the
> issue of incompatibility with existing GUI libs is not nearly as important
> (though not totally irrelevant), but its still an incredible amount of
> work.  One really needs to think hard about whether the manpower resources
> are available to do that and whether the ultimate payoff justifies it.

I don't think so myself. I guess the people that are behind DWT did.
(then again I wasn't ever aiming for the state-of-the-art, either...)

I still think something smaller in ambition, like MinWin or FLTK 1.x, would be nice to have around as an example of "all-D" GUI libraries ?

But porting all of the bigger libraries ? Does sound a bit expensive.
And as an old Mac user, I don't like the dual platform solutions much.

>>A *big* advantage of using the C++ Qt is that it can use system headers.
> 
> I missed your last point above...compared to what?  

Sorry, compared to a native port to D - which can't read C/C++ headers.
(without first converting said headers to "D import modules" that is,
something that is proving to be a lot of work for say Win32 or Carbon)

In wxD, all those pesky system libraries are only accessed by C/C++.
The D library code only needs to talk to the exported "C" functions,
so there is no need for access to all the system headers by D code.

> Most of the people working in this area seem to say that they started out
> with the idea that using Swig would be the way to go and then discovered
> that it was hard to maintain.   I'm not sure how much of that is still
> true now that Swig is a lot more mature.   But talking about Swig gets us
> to three different header parsers as a starting point:  gcc-xml (PyQt),
> Swig, and Kalyptus (QtJava).   QtJambi probably has its own
> specialized parser that would be updated by TrollTech, but I haven't had a
> chance to look at that.

A slight problem for D bindings is that SWIG support for D isn't finished either, but there are others - like the bcd.gen project ?

We're holding SWIG as a "future goal" for wxD (and also for wx.NET),
and continue to work on the Perl/hand-generated classes meanwhile...

> Yes, the Kalyptus tool that generates QtJava also generates Objective-C
> and there are QtRuby bindings that take a slightly different approach as
> well.   At one time there was a hand-generated QtPerl, but that
> was obviously something that ran into difficulties being updated to each
> new Qt release so I'm not sure about its current status.

Cool, I wasn't really aware of all the details - thanks for the info.
(I've only played with the Trolltech Qt examples, not used it anything)

> I guess you mean the code that one develops using each. Right?  That seems
> to be TrollTech's idea.   I wonder whether people have ever tried to
> negotiate back payments to grandfather code that started developing with
> the open source product and what TrollTech's response was.

As far as licensing goes, the two Qt editions are not interchangeable.
So even if they do share a common "code base" (I'm assuming here that
they are more or less identical), they're more like forks of that base ?
But I don't really know (nor care to) what the code differences are...

--anders

On Tue, 10 Oct 2006 16:22:41 +0200, Anders F Björklund wrote:

> Josh Stern wrote:
> 
>>>I mean, having a library written in D is still a nice future goal and I think the current DWT is not a bad choice for such a big porting effort. (Java, or even C#, is actually easier to port to D - than what C++ is)
>> 
>> "Nice" is hard to argue with.  I mean, running on an OS that had a native D API might also be "nice" (in the way LISP machines were nice for LISP). But saying that therefore trying to write a new OS, or at least a new libc, in D is the right way to go is whole different kettle of fish.
> 
> I was naively assuming that the library would eventually end up linking to system libraries, and that those were the main ones involved here... But maybe Qt and GTK+ are more like actual system libraries (at least on Linux) than graphical toolkits, though ? (i.e. comparable to Win32 etc.)

It depends what one means by system library:

1) Lowest stable API  - No, there are other layers below Qt and GTK+
that are API stable (libc/POSIX, X11, etc.), even across other Unix
flavors.

2) Lowest level technically or legally possible - No.

3) Provide basic GUI - Yes.  X11 and related libs don't provide standard widgets that anybody uses today and only provide drawing primitives (like lines and boxes), and don't determine look and feel policy.   On Linux, look and feel policy is set by KDE and Gnome at an even higher layer.

4) Distributed with the OS and/or installed by Default - Depends, on the specific Linux distro, but this is increasingly true for both.

5) Part of a Linux Desktop standard - Yes, getting there.  See http://refspecs.freestandards.org/lsb.shtml




> I still think something smaller in ambition, like MinWin or FLTK 1.x, would be nice to have around as an example of "all-D" GUI libraries ?

More examples of complex D libs of every type would be valuable.

>>>A *big* advantage of using the C++ Qt is that it can use system headers.
>> 
>> I missed your last point above...compared to what?
> 
> Sorry, compared to a native port to D - which can't read C/C++ headers. (without first converting said headers to "D import modules" that is, something that is proving to be a lot of work for say Win32 or Carbon)

Okay, but making decent D bindings for the system headers on
platforms X,Y,Z is an order of magnitude easier than making a good GUI lib
from scratch for all those platforms, so I don't think *that* is a big
consideration (contrast that with the idea Walter put somewhere on his
site that ideally GC should  be  part of the OS).

>> Most of the people working in this area seem to say that they started out
>> with the idea that using Swig would be the way to go and then discovered
>> that it was hard to maintain.   I'm not sure how much of that is still
>> true now that Swig is a lot more mature.   But talking about Swig gets us
>> to three different header parsers as a starting point:  gcc-xml (PyQt),
>> Swig, and Kalyptus (QtJava).   QtJambi probably has its own
>> specialized parser that would be updated by TrollTech, but I haven't had a
>> chance to look at that.
> 
> A slight problem for D bindings is that SWIG support for D isn't finished either, but there are others - like the bcd.gen project ?

Again.  Beefing up D in Swig is a much smaller project than a new GUI.
But the issue remains for the Swig approach that the Swig interface files
need to be individually updated to track API changes in the underlying lib.


> As far as licensing goes, the two Qt editions are not interchangeable. So even if they do share a common "code base" (I'm assuming here that they are more or less identical),

Yes, they are explicitly the same code base.  In fact PyQt has a commercial distribution and they tell people on their web site that end users can use either the free or commercial Qt to dynamically link against at runtime.

 they're more like forks of that base ?
> But I don't really know (nor care to) what the code differences are...

The "fork" idea is only about the restrictions TrollTech puts on the commercial license "version" to help them have a viable business model. The commercial version is explicitly the same code but using a different license.

Josh Stern wrote:
> On Tue, 10 Oct 2006 21:21:43 +1000, Jeff wrote:
> 
>> Before I reply, I should probably note that I didn't mean to come across as if I were claiming any authority or expertise on UI toolkits in general, so I'm sorry if I did; my comments were mostly just my personal opinion from my limited experience.
> 
> Sure.  And before I read what you write below, let me clarify that
> whatever comments I made about writing a new GUI toolkit being a
> tremendous amount of work would apply equally even if you were the
> greatest GUI toolkit writer on the planet.   Let's assum for argument sake
> that you are...
> 
> 
>> Josh Stern wrote:
>>
>>>> I agree; I can understand that people want GUI libraries for D
>>>> available as soon as possible, and indeed there are people working on
>>>> such projects (i.e. D bindings, ports and/or OO abstractions for
>>>> existing toolkits). However, if we really want some thing /good/ and
>>>> maintainable that can really take advantage of D's features, then
>>>> starting from scratch seems like the best path to me.
>>> After the above, I was expecting to see some description below of what
>>> it means to "really take advantage of D's features" but I didn't find
>>> it, so I'm really unsure.   It's clearly important for D that new
>>> application code written in D should be able to sub-class
>>> objects/widgets in D and have access to the full programming API, but
>>> if the bindings are done correctly and the underlying widget set has
>>> good OO then it isn't necessary for the underlying widget set to be
>>> written in D.  In particular, PyQt and QtJava provide examples of this
>>> possibility.  So what is the real idea?
>> By "really take advantage of D's features", I only meant that a faithful
>> translation of an existing OO windowing toolkit wouldn't really have
>> much room to play with D's features, since it would be expected to
>> behave in an all but identical manner to the original (so why not just
>> use the language in which it's already written?).
> 
> I'm still not following what limitations you are talking about.   Can you
> clarify with an example or two?  
> 
>> As far as D wrappers for existing toolkits are concerned, I'd be much
>> more enthusiastic about these than attempts to translate (and keep
>> up-to-date and clean), say, SWT. "DUI"/"DUIT" started looking like a
>> pretty attractive idea once the decision was made to just focus on being
>> a GTK wrapper (rather than using native controls on each target
>> platform), and I guess I could be happy using a GTK wrapper now that it
>> seems to work pretty well on Windows. I'm yet to see a QT application
>> that doesn't look horribly ugly to me. I'm sure it's a quite capable
>> toolkit, but it's hard to feel good about using it given that. (Once
>> again, personal opinion only, there).
> 
> Personally I like the look of KDE (all Qt apps) better than Gnome (all
> Gtk apps), but I know that lots of other people feel the opposite - it
> seems like close to a 50-50 split on this.  Fortunately they are both
> moving close to being able to give the same look and feel as the other, so
> it probably doesn't make sense to base the choice for a new API on looks.
> 
> 
>>>> Even if progress was to be fairly slow, surely I'm not the
> only one
>>> who
>>>> would be enthused enough by such a project to maintain interest?
>>>> Remember, this wouldn't rule out using other toolkits in the meantime,
>>>> but could also provide us with a /really/ good one in the long run.
>>> What is meant by the long run depends on the target feature set.
>>> Already something like Tk or WxWindows or Qt has an incredible number
>>> of man-years invested and new development continues.   That's not to
>>> say anything negative about the educational and/or fun benefits of
>>> writing a new widget lib from scratch so long as one is clear that the
>>> purpose if fun and/or education.   But if the goal is a superior end
>>> product, especially if achieving that goal is essential to the fun,
>>> then a lot more needs to be said about how and why that might happen.
>> I don't have a full answer to that given my total lack of experience
>> writing windowing toolkits... but if proven concepts could be taken from
>> multiple other toolkits rather than trying to clone one exactly, we
>> wouldn't need to be playing catch up to the original, could try to
>> simplify some things by making use of D's delegates, templates, S&S
>> mechanism (if that goes ahead), etc. 
> 
> See my remarks at the top.  I'll elaborate very briefy on two cases:
> 
> Case 1 - totally from scratch in all respects - an *incredible* amount of
> work that is mostly language neutral.
> 
> Case 2 - start from an existing codebase and port/translate as you go -
> still a huge amount of work, you may inherit some license restrictions,
> and you may inherit a lot of design decisions while introducing new bugs. Is it really worth it?
> 
>> Ideally it would be nice to have
>> something usable that was competitive with existing toolkits, but even
>> this didn't happen, I wouldn't consider the venture a complete waste.
> 
> Right, it would  be fun and educational.   Just be clear in the
> beginning if that is okay as a goal.
> 
> 
>>>> For anyone interested, the (utopian? <g>) vision I've had in
> my mind
>>>> for some time of a fresh D windowing toolkit would be:
>>>>
>>>> - Minimal use of native windows/widgets (only for top-level, and other
>>>> cases where really needed?); a Swing-esque approach could be taken to
>>>> native look and feel (making it "somebody else's job"); stops the
>>>> responsibilities getting too tangled, and it seems to have worked
>>>> pretty well for them.
>>> Both Gtk and Qt have converged on methods to allow pluggable look and
>>> feel.  If some aspect of their current ability in this category is
>>> lacking, fixing it directly would be the straightest path.  Gnome and
>>> KDE have parallel and increasingly interoperable methods for telling a
>>> set of applications to conform to the same updated look and feel at
>>> runtime.
>> I don't disagree. I'm just saying what I'd like if the decision were
>> already made to write a new toolkit in D; not trying to justify such a
>> decision.
> 
> Okay.  As an aside on this topic -  there are many people who advocate
> the opposite wrt to achieving native OS look and feel.   I believe that
> WxWindows is a leading advocate of the opposite approach where one tries
> for native look and feel by re-using native widgets wherever possible.
> 
> 
> 
>  
>>>> - Drawing inspiration from Swing, SWT, GTK(gtkmm), QT and other
>>>> toolkits, whilst noting what design traps can be avoided due to D's
>>>> language features.
>>>> - The will to Do It Right, no matter how long it takes. We should be
>>>> in this for the long haul.
>>> What are the design traps you think D will allow you to avoid?
>> Example: over-complicating relatively common tasks, such as hooking up
>> signals and slots. Even if the S&S mechanisms that were being discussed
>> a while back don't find their way into the language, wouldn't D's
>> delegates help to simplify S&S somewhat anyway?
> 
> They help mainly in the library code (that app developers normally don't
> see).  Java style weak references would help more if they somehow found a
> way of sneaking into D :)
> 
>>>> Does anyone else think it would be worth it, or are most people
>>>> content to try to tap into existing toolkits through D?
>>> I'd like to understand the concrete ideas that justify the wording
>>> "content".
>> That comes only from my personal dissatisfaction with a lot of the
>> toolkits that are available for which D wrappers could be made (yet
>> appreciation of many of their features, and of toolkits for which D
>> wrappers could /not/ be made). I was wondering if anyone else felt the
>> same.
> 
> Every lib has some limitations.   But its worthwhile to think carefully
> about which limitations that bother you are based on lib decisions you
> don't like, which are based on missing features that could be added, and
> which are based on the application language (which can  be changed with
> bindings).

This is interesting. Personally, I have never seen a GUI library that I didn't think was dreadful in some way. And there are so many of them! Why? It could be that it's an intrinsically difficult or practically unsolvable problem. In which case any D GUI would be bound to the same fate.

However, it's also possible that it is the language -- I'm inclined to think that's true for C++ GUIs. For example, the preprocessor in Qt is disgusting, but a D binding would avoid that. It could be that my revulsion to some of those libraries is just a result of C++ failings. However, I do think that the language limitations show through the library, and a wrapper doesn't really hide that.

(ie, many lib decisions were made because of the application language).

Which would imply that you get better results wrapping lower level libraries than high level ones. (Example: you can easily wrap the Windows C API, and make something much better).

Don Clugston wrote:
> 
> Which would imply that you get better results wrapping lower level libraries than high level ones. (Example: you can easily wrap the Windows C API, and make something much better).

Definately.


Sean

On Tue, 10 Oct 2006 18:52:49 +0200, Don Clugston wrote:

> Josh Stern wrote:

>> Every lib has some limitations.   But its worthwhile to think carefully about which limitations that bother you are based on lib decisions you don't like, which are based on missing features that could be added, and which are based on the application language (which can  be changed with bindings).
> 
> This is interesting. Personally, I have never seen a GUI library that I didn't think was dreadful in some way. And there are so many of them! Why? It could be that it's an intrinsically difficult or practically unsolvable problem. In which case any D GUI would be bound to the same fate.

Can't comment on that without knowing which aspects of existing ones you find the most undesirable.

> However, it's also possible that it is the language -- I'm inclined to think that's true for C++ GUIs. For example, the preprocessor in Qt is disgusting, but a D binding would avoid that.

Perhaps.  Let's take this pre-processor issue as one example and see how far it can be broken down.   First, let's list which aspects of Qt's use of the moc pre-processor might be considered objectionable:

1) dislike for *any* pre-processor use because they aren't supported well by one's favorite source code debugger - this could be classified as either a language issue, a personal philosophy, or a tool limitation.

2) dislike for use of a non-standard pre-processor - classify this as
mainly a language issue because cpp is particularly sucky, but the
pre-processor or the language itself could be better in many ways and
still not support the same level of source code convenience as moc (yes,
there is build inconvenience, but I get to that in another bullet
point).  In D one could replace part of what moc does with mixins, but not
all of it.  To get all of it mixins would have to be extended with the
capability to use alias arguments in more textual ways and also need to
get access to some of their parsing context (e.g. surrounding class name).

3) build inconvenience - extra step in builds and extra object files need to be dealt with in the build description process and take some small extra time to run as well - seems like a devel environment/hardware speed issue.   I believe that there are various setups for automating the build stuff.

4) unfamiliarity of generated source (e.g. when doing deep debugging) - I guess this could be the same issue for mixins;   one has to decide if the convenience achieved justifies this.

5) methodological choice - the question came up a lot about why they didn't use templates, and the answer was that template support was too non-portable when Qt was written and also that Qt's slots/signals provide different dynamic run-time functionality than what one would get with templates.

All of the above boil down to the question of whether the functionality gained was worth the inconveniences and whether there was some better way to get the same functionality.   Answers in C++ are not obvious to me.  If one has the capability to design a new programming language around the desired functionality, then the story is different, but that also comes with its own disadvantags (e.g. inconvenience using existing libraries, fewer familiar programmers, etc.).


>It could be that my
> revulsion to some of those libraries is just a result of C++ failings. However, I do think that the language limitations show through the library, and a wrapper doesn't really hide that.

How so?

> (ie, many lib decisions were made because of the application language).

Which ones negatively impact you in important ways as a user?   Again it is useful to distinguish between the methods that were used to get to a particular functionality and interface (which you might do differently if you were writing it for the first time, but which don't affect you once it is written), and the choices that make the interface less useful to you. It's definitely true that adding a bindings layer gives one the capability to change some but not all aspects of the interface.


> Which would imply that you get
better results wrapping lower level
> libraries than high level ones. (Example: you can easily wrap the Windows C API, and make something much better).

I'm not following you here.  Much better than what?  Did you mean a better interface than the Win32 API or a better GUI toolkit on top of Win32?

Anyway, I think I disagree with the "imply" part in the sense that whatever one can do theoretically starting from scratch is a different question than what one can do starting from reality with some X hours to spend over some time period Y.

Josh Stern wrote:

>>But maybe Qt and GTK+ are more like actual system libraries (at least on Linux) than graphical toolkits, though ? (i.e. comparable to Win32 etc.)
> 
> It depends what one means by system library:
> 
> 1) Lowest stable API  - No, there are other layers below Qt and GTK+
> that are API stable (libc/POSIX, X11, etc.), even across other Unix
> flavors.
> 
> 2) Lowest level technically or legally possible - No.

What I was trying to say was that the toolkits I have been looking at
are targetting GTK+ as a "platform" in the same way as Win32 or MacOS.
So it's been more about GTK+ as the system library, than about porting
or using GTK+ on another platform - even if that would have worked too.
So even if GTK+ is cross-platform, it is treated as just another OS lib.
(I think that this goes for Qt as well, but I don't know all about it...
Not sure if there is a wxQt port, but otherwise that could be similar ?)

This has worked well for me, the Linux version uses the "native" widgets
in the same theme as the rest of the desktop - and so does Win and Mac.

> 3) Provide basic GUI - Yes.  X11 and related libs don't provide standard
> widgets that anybody uses today and only provide drawing primitives (like
> lines and boxes), and don't determine look and feel policy.   On Linux,
> look and feel policy is set by KDE and Gnome at an even higher layer.

For wx we have "wxX11" which uses the "Universal" (lightweight) widgets that provides a (limited) highlevel interface for such platforms. Maybe not so interesting for "raw" X11, but it also works for embedded so...

But for the full featured version, then having GTK2 is my requirement.

> 4) Distributed with the OS and/or installed by Default - Depends, on the
> specific Linux distro, but this is increasingly true for both.
> 
> 5) Part of a Linux Desktop standard - Yes, getting there.  See
> http://refspecs.freestandards.org/lsb.shtml

The two distributions I have in mind, Fedora Core 5 and Ubuntu Dapper,
both use GNOME as their default desktop - so GTK2 is my target there.

Both offer KDE and Qt as well, and integrated both in the distribution and as per standards and projects you are referring to - a good thing.
So requiring either GTK+ (2+) or Qt (4+) is not a problem, I think...

For now I've chosen GTK+, maybe Qt would have been closer if I used KDE.
I understand that just like Swing it doesn't really use native widgets,
but that they have hidden that fact well by providing a look-and-feel ?

>>I still think something smaller in ambition, like MinWin or FLTK 1.x, would be nice to have around as an example of "all-D" GUI libraries ?
> 
> More examples of complex D libs of every type would be valuable.

Sure, I wouldn't mind at all seeing for instance DWT finished either...
Just that those two were the ones in D that I looked more at (for GUI).

> Okay, but making decent D bindings for the system headers on
> platforms X,Y,Z is an order of magnitude easier than making a good GUI lib
> from scratch for all those platforms, so I don't think *that* is a big
> consideration (contrast that with the idea Walter put somewhere on his
> site that ideally GC should  be  part of the OS).

Yeah, until we can have it fully automated (maybe with a patch or two)
it's mostly a question of plain old boredom and restrictive licensing.
At least for the Win32 and MacOS headers, it's tedious to translate for
potential troubles with legal issues with any redistribution thereof.
(but "WindowsAPI" and "CarbonHeaders" projects are doing those two OS)

For things like GUI libraries, it's usually enough to "port as needed".
(i.e. just adding extern(C) statements for all system functions needed)

> Again.  Beefing up D in Swig is a much smaller project than a new GUI. But the issue remains for the Swig approach that the Swig interface files
> need to be individually updated to track API changes in the underlying lib.

Yeah, it's no more of an obstacle than what the missing OS headers are.
It's just that these little things tends to add up, as they take time ?

But the SWIG approach is probably better in the long run anyway, since
it's at least easier to adapt to API changes than having to edit code ?

> The "fork" idea is only about the restrictions TrollTech puts on the
> commercial license "version" to help them have a viable business model. The commercial version is explicitly the same code but using a different
> license.

Okay, but from their info it looks like you must decide before using it.
The dual licensing model is not uncommon, and much better than closed...

And licensing is just one of the reasons I am sticking with wxWidgets.
From what I saw of Qt4 when I tested it briefly, it looked great to use.

--anders

On Tue, 10 Oct 2006 21:08:12 +0200, Anders F Björklund wrote:

> Josh Stern wrote:
> 
>>>But maybe Qt and GTK+ are more like actual system libraries (at least on Linux) than graphical toolkits, though ? (i.e. comparable to Win32 etc.)
>> 
>> It depends what one means by system library:
>> 
>> 1) Lowest stable API  - No, there are other layers below Qt and GTK+
>> that are API stable (libc/POSIX, X11, etc.), even across other Unix
>> flavors.
>> 
>> 2) Lowest level technically or legally possible - No.
> 
> What I was trying to say was that the toolkits I have been looking at are targetting GTK+ as a "platform" in the same way as Win32 or MacOS. So it's been more about GTK+ as the system library, than about porting or using GTK+ on another platform - even if that would have worked too. So even if GTK+ is cross-platform, it is treated as just another OS lib. (I think that this goes for Qt as well, but I don't know all about it... Not sure if there is a wxQt port, but otherwise that could be similar ?)

Yes, because it is C based, using Gtk as an alternative to Win32 is a little more similar in the code than using Qt as an alternative to Win32 would be.  Also, I believe that historically the first Unix version of WxWindows used Motif, and that was OO C as well, so Gtk was already conceptually close to their previous versions.

> This has worked well for me, the Linux version uses the
"native" widgets
> in the same theme as the rest of the desktop - and so does Win and Mac.
> 
>> 3) Provide basic GUI - Yes.  X11 and related libs don't provide standard widgets that anybody uses today and only provide drawing primitives (like lines and boxes), and don't determine look and feel policy.   On Linux, look and feel policy is set by KDE and Gnome at an even higher layer.
> 
> For wx we have "wxX11" which uses the "Universal" (lightweight) widgets that provides a (limited) highlevel interface for such platforms. Maybe not so interesting for "raw" X11, but it also works for embedded so...

I don't think that raw X11 is that good for embedded since there are few embedded X servers.  There is actually an embedded version of Qt that is based on a frame buffer rather than an X11 model - it was used by Sharp for instance in some of their products.   I'm not competent to discuss the market share merits of different current approaches to embedded semi-portability (including Micro-Java), but I would guess that PalmOS and WinCE are important targets if that is the goal, and I'm not aware of anything GUI toolkits that do a good job with both of these and the regular desktop.


 either GTK+ (2+) or Qt (4+) is not a problem, I think...
> 
> For now I've chosen GTK+, maybe Qt would have been closer if I used KDE. I understand that just like Swing it doesn't really use native widgets, but that they have hidden that fact well by providing a look-and-feel ?

Because Linux GUI apps can come from so many sources, it's very debatable
to say what if anything the "native look and feel" means on Linux at the
present time (at one stage it meant the Motif look on most Unix, but that
was never standard on Linux and definitely uncommon today).  Both KDE and
Gnome offer systems for run-time configuration of fonts, colors, rendering
plugins, etc. in all currently running Gnome or KDE apps.   They have also
talked to each other about standard to let non-toolkit apps participate in
this process and to shared DND for things other than text.  The place to
look at the current theoretical status of those standards is here:
http://freedesktop.org/wiki/
http://portland.freedesktop.org/wiki/

On X11, the window manager that is running decorates the outside of windows.   So, say, if I am running KDE as my desktop environment (with the Kwin window manager) and a version of Firefox that is built against Gtk, then when I update my desktop window manager decorates, it affects the colors of the borders of the Firefox window but not inside the app. Similarly I can change the default text font for all running KDE applications but I can only change the header font from KDE for the text above the border of Firefox and need to go into Firefox itself to configure the fonts it uses for web pages. The stuff above would like to make all of that happen together even for apps built on different toolkits.   I'm not one the people who thinks this is a very important issue.


>> Again.  Beefing up D in Swig is a much smaller project than a new GUI. But the issue remains for the Swig approach that the Swig interface files need to be individually updated to track API changes in the underlying lib.
> 
> Yeah, it's no more of an obstacle than what the missing OS headers are. It's just that these little things tends to add up, as they take time ?

It's only more of an obstacle if you expect the GUI toolkit headers to change more often (or if they are much larger) and you want to track those changes - i.e. easily update to Qt5 if and when it comes out.

> But the SWIG approach is probably better in the long run anyway,
since
> it's at least easier to adapt to API changes than having to edit code ?

Editing interface files is editing code.   But if you have parsing code and auto-generation from the rep of just what is parsed, then that is more automated.


>> The "fork" idea is only about the restrictions TrollTech puts on the commercial license "version" to help them have a viable business model. The commercial version is explicitly the same code but using a different license.
> 
> Okay, but from their info it looks like you must decide before using it. The dual licensing model is not uncommon, and much better than closed...
> 
> And licensing is just one of the reasons I am sticking with wxWidgets.
>  From what I saw of Qt4 when I tested it briefly, it looked great to
>  use.

Hopefully WxWindows can eventually take advantage of the gtk
pluggable rendering engines to allow whatever look and feel the user wants
(at least as far as that is supported by a set of plugins).

Josh Stern wrote:
> On Tue, 10 Oct 2006 18:52:49 +0200, Don Clugston wrote:
> 
>> Josh Stern wrote:
> 
>>> Every lib has some limitations.   But its worthwhile to think carefully
>>> about which limitations that bother you are based on lib decisions you
>>> don't like, which are based on missing features that could be added, and
>>> which are based on the application language (which can  be changed with
>>> bindings).
>> This is interesting. Personally, I have never seen a GUI library that I didn't think was dreadful in some way. And there are so many of them! Why? It could be that it's an intrinsically difficult or practically unsolvable problem. In which case any D GUI would be bound to the same fate.
> 
> Can't comment on that without knowing which aspects of existing ones you
> find the most undesirable.
> 
>> However, it's also possible that it is the language -- I'm inclined to
>> think that's true for C++ GUIs. For example, the preprocessor in Qt is
>> disgusting, but a D binding would avoid that. 
> 
> Perhaps.  Let's take this pre-processor issue as one example and see how
> far it can be broken down.   First, let's list which aspects of Qt's use
> of the moc pre-processor might be considered objectionable:
> 
> 1) dislike for *any* pre-processor use because they aren't supported well
> by one's favorite source code debugger - this could be classified as
> either a language issue, a personal philosophy, or a tool limitation.
> 
> 2) dislike for use of a non-standard pre-processor - classify this as
> mainly a language issue because cpp is particularly sucky, but the
> pre-processor or the language itself could be better in many ways and
> still not support the same level of source code convenience as moc (yes,
> there is build inconvenience, but I get to that in another bullet
> point).  In D one could replace part of what moc does with mixins, but not
> all of it.  To get all of it mixins would have to be extended with the
> capability to use alias arguments in more textual ways and also need to
> get access to some of their parsing context (e.g. surrounding class name).
> 
> 3) build inconvenience - extra step in builds and extra object files need
> to be dealt with in the build description process and take some small
> extra time to run as well - seems like a devel environment/hardware speed
> issue.   I believe that there are various setups for automating the build
> stuff.
> 
> 4) unfamiliarity of generated source (e.g. when doing deep debugging) - I
> guess this could be the same issue for mixins;   one has to decide if the
> convenience achieved justifies this.
> 
> 5) methodological choice - the question came up a lot about why they
> didn't use templates, and the answer was that template support was too
> non-portable when Qt was written and also that Qt's slots/signals provide
> different dynamic run-time functionality than what one would get with
> templates.


and
6) unnatural - fits poorly with any other library in the language.

> 
> All of the above boil down to the question of whether the functionality
> gained was worth the inconveniences and whether there was some better way
> to get the same functionality.   Answers in C++ are not obvious to me.


I don't disagree with that. This is why I said, maybe it's an unsolvable problem.

> If
> one has the capability to design a new programming language around the
> desired functionality, then the story is different, but that also comes
> with its own disadvantags (e.g. inconvenience using existing libraries,
> fewer familiar programmers, etc.).
> 
>> It could be that my
>> revulsion to some of those libraries is just a result of C++ failings.
>> However, I do think that the language limitations show through the
>> library, and a wrapper doesn't really hide that.
> 
> How so?
>  
>> (ie, many lib decisions were made because of the application language).
> 
> Which ones negatively impact you in important ways as a user? 

Things like:
* Why do I have to put this in a class? Why can't I just use a free function? (typical for GUIs that originated in Java).
* In a C++ GUI, you can usually tell that the original language didn't have delegates.

The biggest problem, I think, is that GUI libraries tend to interfere too much with app structure.

>> Which would imply that you get
> better results wrapping lower level
>> libraries than high level ones. (Example: you can easily wrap the
>> Windows C API, and make something much better).
> 
> I'm not following you here.  Much better than what?  Did you mean a better
> interface than the Win32 API or a better GUI toolkit on top of Win32?

I mean a simpler interface than raw API calls, taking out lots of repetitive code. Eg, a simple OO wrapper that puts the HWNDs in a class, so you can remove lots of 'hwnd's. The benefit is obvious (the code size decreases). But when you wrap a high-level framework, you have a lot less freedom.

> Anyway, I think I disagree with the "imply" part in the sense that
> whatever one can do theoretically starting from scratch is a different
> question than what one can do starting from reality with some X hours to
> spend over some time period Y.

That's certainly true. But there's also the problem of getting a consensus on those X hours. How can you convince everyone to work on the same thing? It just seems to be really difficult. I worked on the Windows API headers because I knew that no matter which framework was used, it would still be useful.

The thing that really drives me nuts is that there are *so many* GUI libraries for Windows and Linux, and they are all ultimately using the same hardware! I just think it's so ridiculous. If you look in the coding of any of those frameworks, you find that huge chunks of them are the same. And so I wonder if there is some intermediate level at which you can create widgets (or at least parts of them) that would work regardless of what GUI framework was ultimately used.

Don Clugston skrev:
<snip>
> This is interesting. Personally, I have never seen a GUI library that I didn't think was dreadful in some way. And there are so many of them! Why? It could be that it's an intrinsically difficult or practically unsolvable problem. In which case any D GUI would be bound to the same fate.

I have two GUI libraries that I love:

Cocoa and VCL.

Cocoa takes advantage of Obj-C, and VCL takes advantage of Object Pascal. What they both have in common is that they work with the underlying language, not against it, or using some side-show freaky tricks. Both also have the actual layout of the UI separated from the code.

I think a combination of Walter's suggestion for a mixin solution of signals and slots, combined with informal interfaces for delegates and data providers would be terrific. Sort of a blend of the best parts of Cocoa, VCL, and Qt could be made.


// Fredrik Olsson

Don Clugston wrote:
> Josh Stern wrote:
>> On Tue, 10 Oct 2006 18:52:49 +0200, Don Clugston wrote:
>>
> The thing that really drives me nuts is that there are *so many* GUI libraries for Windows and Linux, and they are all ultimately using the same hardware! I just think it's so ridiculous. If you look in the coding of any of those frameworks, you find that huge chunks of them are the same. And so I wonder if there is some intermediate level at which you can create widgets (or at least parts of them) that would work regardless of what GUI framework was ultimately used.

I think in some ways, that's the layer that SDL targets.

I think part of the reason there's not more reuse may just be aesthetics.  You have to be really picky to decide you'd rather reinvent the GUI wheel than use one of the dozen or so existing solutions, many of which have tens of thousands of man-hours already invested in them. So it's not surprising that the person who wants to write their own GUI cares about every little detail right down to the low level.

--bb