On Mon, 09 Oct 2006 17:01:44 -0500, Josh Stern wrote:


> 
> The Qt commercial licensing fee is only relevant if one needs to distribute a closed source app outside of your organization.  Offhand I can't think who it is really a problem for other than impoverished shareware writers.  At the point at which most proprietary applications are reading to be distributed, the tradeoff of a developer license fee for professional support is a good one.

I was wrong about part of the above.   The TrollTech commercial license incluedes, the following text, which basically means you have to decide up front whether to use commercial or GPL licensing.

*********************************************************************** You must purchase a Qt Commercial License from Trolltech or from any of its authorized resellers before you start developing proprietary software. The Commercial license does not allow the incorporation of code developed with the Open Source Edition of Qt into a proprietary product.

For desktop applications, there are no royalties, runtime licenses, or other additional costs.

The license is sold on a per-developer basis and assigned to an individual. It may be transferred, but only every six months and within the same organization.

***************************************************************

Kirk McDonald wrote:
> Walter Bright wrote:
>> C can't do OOP based designs.
> 
> Sure it can! I've used plenty of faux-OOP C APIs (see also: the Python/C API). It's just that it's usually annoying to use such things. :-)

True, but I did mean "can't" in the sense of "impractical" or "only if you're desperate". I don't think someone would want to design a gui toolkit around a desperate workaround <g>.

Isn't that what the gtk people did?

On Mon, 09 Oct 2006 14:43:46 -0700, Walter Bright wrote:

>
> D is a multiparadigm language, and that's important for library development because appealing designs shouldn't be shut out because they are impractical with D. For example, C++ can't do GUI toolkits that are based on gc. C++ can't do toolkits based on signals and slots (Trolltech had to write a C++ preprocessor to make that work). Java can't do template metaprogramming based designs. C can't do OOP based designs.

Just wanted to point out in case it wasn't clear that QtJava (and I think PyQt) are GC'd in the normal way on the application side and allow signals/slot use via different mechanisms which are then bridged to the C++ library side. As written, QtJava uses weak references in a hash map to auto-delete C++ roots when their corresponding Java objects get finalized, but there are other ways that this could be done even without weak reference support.  If D ultimately developed a native mechanism for runtime signals/slots then it could be used instead and bridged.

On Mon, 09 Oct 2006 18:30:48 -0500, Mars wrote:

> Isn't that what the gtk people did?

If you mean wrote an OO widget set in straight C, then "yes". Also Xt/Xaw/Motif before them, among others.

If you meant derive something from Tk, then "no".

Josh Stern wrote:

>>But if you want to port Qt over to D, then by all means go for it! :-)
> 
> Porting Qt itself is both too much work and undesirable (because it would
> be a fork).  What I discussed a few posts back was porting the PyQt or
> QtJava bindings for Qt (which link with the regular Qt libraries).

Actually this was what I meant, "make it accessible from D", not port.

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)

But in the meantime, being able to use the standard GUI libraries from D would be nice as it is currently an advantage that C++ or even Java has. And D wrappers for Qt are missing AFAIK, we "only" have them for GTK+...

A *big* advantage of using the C++ Qt is that it can use system headers.

> These
> are both a) much, much smaller, and b) 90-95% auto-generated from Qt
> headers, so a lot of the work would be just modifying the generator
> programs and then adding support code - they are both designed to be
> readily updated to future Qt release.  The biggest hurdle
> I can see would be figuring out the best naming and documentation
> convention for dealing with the situations where Qt makes use of more
> member function overloading than what D allows.  

The QtJava files look similar to how the current wxD bindings work, while PyQt seems to use a more SWIG-like (.sip) automated approach...

I'm not sure which approach would work best for QtD/QDt, but we're moving towards the second method in wxD as it is more maintainable.

There is also a Qt# project: http://qtcsharp.sourceforge.net/ (GPL) (this one also used a Perl program to generate the initial C# files)

Doing a proof-of-concept spike would probably show which approach would work better for the D bindings/wrappers, maybe even try both of them ?

> The Qt commercial licensing fee is only relevant if one needs to
> distribute a closed source app outside of your organization. 

Or use any "open source" license other than the GPL, for instance.
I don't have a problem with GPL at all, but LGPL is easier to use.

But I do think that the Community Ed. and Commercial Ed. are two separate Qt products, so they would be more like forks in practice.

--anders

Walter Bright wrote:

> True, but I did mean "can't" in the sense of "impractical" or "only if you're desperate". I don't think someone would want to design a gui toolkit around a desperate workaround <g>.

The current (wrapped) GUI toolkits take an OOP design (in C++), wrap it up in a faux-OOP C API and then mimics the original OOP design (in D)...
Not sure I would want to compare "desparate" and "workaround" parts ;-)

I *like* my current C APIs. They're simple. They work. "Good old rock".
--anders

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.

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

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

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

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

>> - Well-defined basic components that everyone expects (all the buttons,
>> menus, etc.) but also /eventually/ packages containing more complex
>> components (e.g. pretty message dialogs with cleanly expandable "more
>> info" sections, headers and footers; colour, date selection dialogs;
>> etc.). Saving people from recreating common widgets (formatted text
>> areas) could really set it apart from the rest, and people not working
>> on the core architecture of the library could certainly lend a hand
>> here.
> 
> This sounds like policy stuff ath the desktop (Gnome or KDE) level. Parallel questions to the above here is "What are the architectural
> limitations of gtk ot Qt that you see as limiting what you want to do here?

This is just part of a vague wish list. The idea of having lots of more advanced pre-built components standard really appeals to me. For example, I'd often want to present an error message to the user with some advanced information available that would not normally be desired. To keep it clean, it would be good to have an expandable section. If this kind of dialog was available stock, then users of the toolkit would be more likely to take advantage of them than if they had to write it themselves.

As for architectural limitations... none that I can imagine (see above).

>> - Developed along-side the D standard library which will no doubt
>> (?) be getting a lot more attention once v1.0 of the D spec is out. - It
>> would be nice if it could take advantage of existing cross-platform
>> libraries where possible (e.g. pango for advanced text rendering, etc.),
>> but maybe not too practical?
> 
> Trying to specify a single "standard" GUI toolkit for D is probably not a
> good idea.   Java had a lot more reason than D for trying to do this
> (goals of sandbox security capability abd hyper-portability) and still
> suffers a lot as a desktop tool because they got it wrong twice. 

Sorry, I didn't mean to imply that it should be a standard GUI toolkit for D. By that I just meant that it would be worth waiting to see where the D standard library ends up going (rather than being too eager to start developing a new toolkit now) to so it and v1.0 of the D spec could be taken advantage of, rather than potentially duplicating a lot of more general functionality, or failing to utilise features that may be added to the spec before v1.0.

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

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

On Tue, 10 Oct 2006 09:17:33 +0200, Anders F Björklund wrote:

> Josh Stern wrote:
> 
>>>But if you want to port Qt over to D, then by all means go for it! :-)
>> 
>> Porting Qt itself is both too much work and undesirable (because it would be a fork).  What I discussed a few posts back was porting the PyQt or QtJava bindings for Qt (which link with the regular Qt libraries).
> 
> Actually this was what I meant, "make it accessible from D", not port.
> 
> 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. 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.

> But in the meantime, being able to use the standard GUI libraries from D would be nice as it is currently an advantage that C++ or even Java has. And D wrappers for Qt are missing AFAIK, we "only" have them for GTK+...
> 
> A *big* advantage of using the C++ Qt is that it can use system headers.

I missed your last point above...compared to what?

>> These
>> are both a) much, much smaller, and b) 90-95% auto-generated from Qt
>> headers, so a lot of the work would be just modifying the generator
>> programs and then adding support code - they are both designed to be
>> readily updated to future Qt release.  The biggest hurdle
>> I can see would be figuring out the best naming and documentation
>> convention for dealing with the situations where Qt makes use of more
>> member function overloading than what D allows.
> 
> The QtJava files look similar to how the current wxD bindings work, while PyQt seems to use a more SWIG-like (.sip) automated approach...
> 
> I'm not sure which approach would work best for QtD/QDt, but we're moving towards the second method in wxD as it is more maintainable.

QtJava looks more elegant to me personally (and Trolltech seems to like it too as they have now turned it into an actual product of theirs called QtJambi).   But I hesitated to state a preference because I believe QtPy has been more widely used and because the issue of Java's closer C++ compatibility wrt function overloading will be one extra issue to overcome (whereas QtPy takes the approach of more often using strings explicitly (e.g. for signals) to name the C++ binding target.

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.


> There is also a Qt# project: http://qtcsharp.sourceforge.net/
(GPL)
> (this one also used a Perl program to generate the initial C# files)

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.


> Doing a proof-of-concept spike would probably show which approach
would
> work better for the D bindings/wrappers, maybe even try both of them ?

Yes, or at least look carefully at all the existing methods.

>> The Qt commercial licensing fee is only relevant if one needs to distribute a closed source app outside of your organization.
> 
> Or use any "open source" license other than the GPL, for instance. I don't have a problem with GPL at all, but LGPL is easier to use.

Agreed.  It' worth pointing out that the restrictive parts of GPL apply only to the act of program distribution and there is an exception for linkage against system components - that is components that are distributed with the OS platform.   So GPL doesn't affect internal projects that stay internal to an organization and Qt is moving close to being a system component on on Linux, at least.

> But I do think that the Community Ed. and
Commercial Ed. are two
> separate Qt products, so they would be more like forks in practice.

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.

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