www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GUI strategy?

reply Frank Benoit <keinfarbton googlemail.com> writes:
Again and again it is said in this newsgroup: "D needs a GUI"
But there are existing alternatives:
DFL/GTKD/MinWin/DWT/wxD/....
(and more http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries)
So I think some ppl are happy with one of those existing solutions.

So what is missing for those, who say D needs a GUI?

In the world outside of D, there are those big ones:
- .NET/Mono
- Eclipse RCP, Netbeans
- QT
- ...?

They all are not only a GUI, say a collection of basic controls. They
are complete frameworks. They offer complete Dialogs, separation of data
and presentation (MFC/data binding), persistance, update mechnisms,
docking systems, extension mechanisms, tools, IDE support, commercial
support, ...

Is it something like this, ppl mean if they say 'D needs a GUI'?
I can only speak for myself, and yes, that is what I think. I wish i
could use a framework, which has an answer for many of the common tasks
while building a GUI application.

What do you think, does this problem "D needs a GUI" really exist?
Seriously, how can this be solved in the next 1..2 years?
... and who will do it?
Sep 28 2007
next sibling parent reply Gregor Richards <Richards codu.org> writes:
People complain that D needs a GUI because people are stupid and 
incompetent, and don't understand the concept of third-party libraries.

  - Gregor Richards
Sep 28 2007
parent reply Regan Heath <regan netmail.co.nz> writes:
Gregor Richards wrote:
 People complain that D needs a GUI because people are stupid and 
 incompetent, and don't understand the concept of third-party libraries.
Harsh.. I prefer to think they are simply un-enlightened as to the presence of dsource. I think having a standard D gui library alongside the standard D library would be beneficial, even if it just does the basics. As long as it is enough to get people coding in D. Regan
Sep 28 2007
next sibling parent BLS <nanali nospam-wanadoo.fr> writes:
Regan Heath schrieb:
 Gregor Richards wrote:
 People complain that D needs a GUI because people are stupid and 
 incompetent, and don't understand the concept of third-party libraries.
Harsh.. I prefer to think they are simply un-enlightened as to the presence of dsource. I think having a standard D gui library alongside the standard D library would be beneficial, even if it just does the basics. As long as it is enough to get people coding in D.
Enough to do what ? Producing a GUI with a yesterday look and feel ? No thanks. Bjoern
 
 Regan
Sep 28 2007
prev sibling next sibling parent reply Gregor Richards <Richards codu.org> writes:
Regan Heath wrote:
 Gregor Richards wrote:
 People complain that D needs a GUI because people are stupid and 
 incompetent, and don't understand the concept of third-party libraries.
Harsh.. I prefer to think they are simply un-enlightened as to the presence of dsource. I think having a standard D gui library alongside the standard D library would be beneficial, even if it just does the basics. As long as it is enough to get people coding in D. Regan
Yes, because having a standard GUI library has proven oh-so-beneficial in the past. Lesse ... Java: 1) AWT is the standard. Whoops, that sucks, so let's write 2) Swing, the new standard. Whoops, that sucks, so lots of things use 3) SWT, which is not standard in that it is not part of the standard library. Python: 1) Tkinter. Whoops, that sucks, so people wrote <place huge list of good libraries here> D: 1) DWT. Who cares about platform compatibility or maintenance? Lesson learned? The standard always sucks because the standard can never change, and people will continue to use the standard even when there are superior alternatives. The desire to add GUIs to a standard library is part of the common ridiculously-poor design of monolithic standard libraries, and thankfully it doesn't have much steam for D. - Gregor Richards
Sep 28 2007
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Gregor Richards" <Richards codu.org> wrote in message 
news:fdjc7i$14ka$1 digitalmars.com...
 Regan Heath wrote:
 Gregor Richards wrote:
 People complain that D needs a GUI because people are stupid and 
 incompetent, and don't understand the concept of third-party libraries.
Harsh.. I prefer to think they are simply un-enlightened as to the presence of dsource. I think having a standard D gui library alongside the standard D library would be beneficial, even if it just does the basics. As long as it is enough to get people coding in D. Regan
Yes, because having a standard GUI library has proven oh-so-beneficial in the past. Lesse ... Java: 1) AWT is the standard. Whoops, that sucks, so let's write 2) Swing, the new standard. Whoops, that sucks, so lots of things use 3) SWT, which is not standard in that it is not part of the standard library. Python: 1) Tkinter. Whoops, that sucks, so people wrote <place huge list of good libraries here> D: 1) DWT. Who cares about platform compatibility or maintenance? Lesson learned? The standard always sucks because the standard can never change, and people will continue to use the standard even when there are superior alternatives. The desire to add GUIs to a standard library is part of the common ridiculously-poor design of monolithic standard libraries, and thankfully it doesn't have much steam for D. - Gregor Richards
You forgot to mention: .NET forms. Wow, it's freaking awesome, lets use it ;) Not that it matters much. I think your overall point is correct. The presence of a good GUI library does not necessarily mean it has to be part of the standard. It just should exist and be as good as current GUI libraries in other languages. Disclaimer: I haven't used any D GUI library yet, so I am pretty much talking out of my ass. -Steve
Sep 28 2007
prev sibling next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Gregor Richards wrote:
 Regan Heath wrote:
 Gregor Richards wrote:
 People complain that D needs a GUI because people are stupid and 
 incompetent, and don't understand the concept of third-party libraries.
Harsh.. I prefer to think they are simply un-enlightened as to the presence of dsource. I think having a standard D gui library alongside the standard D library would be beneficial, even if it just does the basics. As long as it is enough to get people coding in D. Regan
Yes, because having a standard GUI library has proven oh-so-beneficial in the past. Lesse ... Java: 1) AWT is the standard. Whoops, that sucks, so let's write 2) Swing, the new standard. Whoops, that sucks, so lots of things use 3) SWT, which is not standard in that it is not part of the standard library. Python: 1) Tkinter. Whoops, that sucks, so people wrote <place huge list of good libraries here> D: 1) DWT. Who cares about platform compatibility or maintenance? Lesson learned? The standard always sucks because the standard can never change, and people will continue to use the standard even when there are superior alternatives. The desire to add GUIs to a standard library is part of the common ridiculously-poor design of monolithic standard libraries, and thankfully it doesn't have much steam for D. - Gregor Richards
IMHO, you are right about NOT having a standard GUI library as part of D. however, regarding the current options we have - it not a trivial task to install any of them, in the sense that dsss net install should be all i need to start using any of them. besides, current GUI libs carry with them their own problems. in my ideal world the solution is: having the infrastructure for such a lib be part of the standard library: containers, threads, signals and slots, i18n, l13n, etc... now NEW GUI libs would be modular and could be built based on those standard libs. I really don't like most of the C/C++ based toolkits because of the kitchen sink approach: qt has it's own threads, containers, etc. so does gtk+, (i guess it's due to the lack of those features in the standard lib when the kits were made) D native libs would benefit from many D features, and i would like to have a choice: native widgets vs. non-native, or a choice between using real D code vs. some declarative STANDARDIZED form (based on XML, for example) another thing is a standardized framework for deployment. i would prefer something like what adobe does with their AIR offering. only not proprietary.
Sep 28 2007
parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Yigal Chripun wrote:

 
 IMHO, you are right about NOT having a standard GUI library as part of
 D. however, regarding the current options we have - it not a trivial
 task to install any of them, in the sense that dsss net install should
 be all i need to start using any of them.
 
dsss net install minwin
Sep 29 2007
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Tomas Lindquist Olsen wrote:
 Yigal Chripun wrote:
 
 IMHO, you are right about NOT having a standard GUI library as part of
 D. however, regarding the current options we have - it not a trivial
 task to install any of them, in the sense that dsss net install should
 be all i need to start using any of them.
dsss net install minwin
actually i've done just that a few days ago and while it did install it didn't work for me. had problems with the the imports or something like that. does minwin work with tango? (i prefer to use tango myself)
Sep 29 2007
parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Yigal Chripun wrote:

 Tomas Lindquist Olsen wrote:
 Yigal Chripun wrote:
 
 IMHO, you are right about NOT having a standard GUI library as part of
 D. however, regarding the current options we have - it not a trivial
 task to install any of them, in the sense that dsss net install should
 be all i need to start using any of them.
dsss net install minwin
actually i've done just that a few days ago and while it did install it didn't work for me. had problems with the the imports or something like that. does minwin work with tango? (i prefer to use tango myself)
MinWin is currently Phobos only. I do plan to update it to work with both libraries soon though.
Sep 30 2007
prev sibling parent reply Regan Heath <regan netmail.co.nz> writes:
Gregor Richards wrote:
 Regan Heath wrote:
 Gregor Richards wrote:
1) AWT is the standard. Whoops, that sucks, so let's write 2) Swing, the new standard. Whoops, that sucks, so lots of things use
I assume each of these sucked in some fundamental way, something which prevented them 'fixing' it without changing the interface? Or perhaps the 'best way to design a gui' changed, or a new design pattern emerged as superior? In any case none of those are reasons not to have a standard GUI library. I'll try and define what I mean by the phrase standard GUI library below.
  3) SWT, which is not standard in that it is not part of the standard 
 library.
A "D standard GUI library" doesn't have to be part of the D standard library, it just has to use it, build on it, etc. It has to be seen as the standard way of doing a GUI app in D. Examples of GUI code in D should all use it. People shouldn't have to ask where is the GUI library, or how do I write a GUI app in D, it should obvious. Essentially all the "D standard GUI library" is, is a label applied to the GUI library that best suits D (at the time). The effect of that being consistency, and focus for new development. Don't get me wrong I'm all for there being as many GUI libraries as people want, all with myriad pros/cons, but the downside of this can be seen in the current situation where we have a number of half finished libraries. It would be better to focus effort on one library and get it to a stage where it's good enough to use for a major project. At least then if people write custom components etc it's likely they're written for this library and not some other one.
 Lesson learned? The standard always sucks because the standard can never 
 change, and people will continue to use the standard even when there are 
 superior alternatives. 
I don't see a problem with changing the standard library, assuming a new library emerges and does a better job than the old one.
 The desire to add GUIs to a standard library is
 part of the common ridiculously-poor design of monolithic standard 
 libraries, and thankfully it doesn't have much steam for D.
I don't want a monolithic standard library. I want a modular one. i.e. standard core library standard web library standard gui library ... Where the standard gui library module can be swapped for a better one if and when "we" want. Regan
Sep 28 2007
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter "blessed" DWT (I believe it was) and... it promptly died.

Granted, we've got Tioport making excellent progress now, but I don't
think Walter wants to bless any particular library that he himself isn't
responsible for.

As for getting the community to agree on one, good luck on that.  I
remember lots of threads about designing a community-standard, and no
one could agree on something as basic as: should it owner-draw or use
native widgets.  Both sides have very good, solid arguments for them.
And people in general have a habit of (sometimes violently) backing
their very good, solidly justified team. :)

My position is: we're not going to get a "standard" GUI library for D
unless someone comes up with some brilliant new design that can't be
done in C or C++ that really sets is apart for D.  Something to blow the
socks off all those cocky Java programmers.  Until that happens, I don't
really see much point.

	-- Daniel "hell, what do *I* know, anyway?"
Sep 28 2007
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Daniel Keep wrote:
 Walter "blessed" DWT (I believe it was) and... it promptly died.
 
 Granted, we've got Tioport making excellent progress now, but I don't
 think Walter wants to bless any particular library that he himself isn't
 responsible for.
 
 As for getting the community to agree on one, good luck on that.  I
 remember lots of threads about designing a community-standard, and no
 one could agree on something as basic as: should it owner-draw or use
 native widgets.  Both sides have very good, solid arguments for them.
 And people in general have a habit of (sometimes violently) backing
 their very good, solidly justified team. :)
 
Nor will there ever be an agreement on those issues, just as there isn't outside of the D community. It seems to be kinda like static vs. dynamic languages where everyone has a favorite that more adequately suits them, but no objective best one. Still, I think it would be reasonable to hope that at least in each category, there could be a standard (as in, de facto) GUI library. -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 29 2007
parent Don Clugston <dac nospam.com.au> writes:
Bruno Medeiros wrote:
 Daniel Keep wrote:
 Walter "blessed" DWT (I believe it was) and... it promptly died.

 Granted, we've got Tioport making excellent progress now, but I don't
 think Walter wants to bless any particular library that he himself isn't
 responsible for.

 As for getting the community to agree on one, good luck on that.  I
 remember lots of threads about designing a community-standard, and no
 one could agree on something as basic as: should it owner-draw or use
 native widgets.  Both sides have very good, solid arguments for them.
 And people in general have a habit of (sometimes violently) backing
 their very good, solidly justified team. :)
Nor will there ever be an agreement on those issues, just as there isn't outside of the D community. It seems to be kinda like static vs. dynamic languages where everyone has a favorite that more adequately suits them, but no objective best one. Still, I think it would be reasonable to hope that at least in each category, there could be a standard (as in, de facto) GUI library.
I think so too. A case I'm particularly interested in is an owner-draw control. (an example I have in mind is a x-y chart). I'd hope for significant code reuse, regardless of whether such a control is used inside a framework which use native-widget or owner-draw for the basic widgets. Surely we can do that.
Sep 30 2007
prev sibling parent Jari-Matti =?ISO-8859-1?Q?M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Regan Heath wrote:

 Don't get me wrong I'm all for there being as many GUI libraries as
 people want, all with myriad pros/cons, but the downside of this can be
 seen in the current situation where we have a number of half finished
 libraries.
 It would be better to focus effort on one library and get it to a stage
 where it's good enough to use for a major project.  At least then if
 people write custom components etc it's likely they're written for this
 library and not some other one.
Look, open source model doesn't work like this in general. First you have to make people agree on license, then supported platforms (OSes, supported compilers, build tools, tango vs phobos, ...), coding conventions (tabs vs spaces, placement of braces, use of templates, exceptions, OOP vs AOP vs LOP vs C-style functions, documentation syntax, ...), NIH factor (especially if any commercial entity shows interest), etc. The end result is a cartesian product of all these. The only thing people agree on is the language (well, some might still want to write parts of the product using scripting languages and/or assembler and so on).
Sep 29 2007
prev sibling next sibling parent reply Max Samukha <samukha voliacable.com.removethis> writes:
On Fri, 28 Sep 2007 17:51:29 +0100, Regan Heath <regan netmail.co.nz>
wrote:

Gregor Richards wrote:
 People complain that D needs a GUI because people are stupid and 
 incompetent, and don't understand the concept of third-party libraries.
Harsh.. I prefer to think they are simply un-enlightened as to the presence of dsource. I think having a standard D gui library alongside the standard D library would be beneficial, even if it just does the basics. As long as it is enough to get people coding in D. Regan
Just like you I prefer to think that I'm not (hopelessly) stupid or incompetent but that I want a kind of useable 'official' gui library written in D, not a wrapper around C wrapper around C++ wrapper around native API. At least a basic set of widgets. I'm trying to use DFL but it seems to be developed and maintained by one person, is Windows-only and very alpha. And the dead DWT, harmonia and others are not a choice. PS. Gregor, you are one of the smartest people I've ever met, no doubt.
Sep 28 2007
parent Max Samukha <samukha voliacable.com.removethis> writes:
On Fri, 28 Sep 2007 20:39:54 +0300, Max Samukha
<samukha voliacable.com.removethis> wrote:

 I'm trying to use DFL but
it seems to be developed and maintained by one person, is Windows-only
and very alpha. 
I was accused of badmouthing DFL and want to apologize for the emotional 'very alpha'. It's not like that. It just lacks a couple of useful widgets that are being developed or going to be developed and has some issues that get fixed as soon as they are reported.
Oct 02 2007
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Regan Heath wrote:

 People complain that D needs a GUI because people are stupid and 
 incompetent, and don't understand the concept of third-party libraries.
Harsh.. I prefer to think they are simply un-enlightened as to the presence of dsource. I think having a standard D gui library alongside the standard D library would be beneficial, even if it just does the basics. As long as it is enough to get people coding in D.
And I would still like to see D examples use MinWin rather than just the Windows API, even if all MinWin does is play a basic game of Empire... With examples, I mean for instance "dmd/samples/d/winsamp.d" ? See also: http://lists.puremagic.com/pipermail/digitalmars-d/2006-October/008912.html --anders
Sep 29 2007
prev sibling next sibling parent reply BLS <nanali nospam-wanadoo.fr> writes:
Frank Benoit schrieb:

 Is it something like this, ppl mean if they say 'D needs a GUI'?
 I can only speak for myself, and yes, that is what I think. I wish i
 could use a framework, which has an answer for many of the common tasks
 while building a GUI application.
Yes, that is what I think too. written from the scratch, based upon Tango. Bjoern
Sep 28 2007
parent reply Frank Benoit <keinfarbton googlemail.com> writes:
BLS schrieb:
 Yes, that is what I think too.
 written from the scratch, based upon Tango.
 
 Bjoern
But what about "how?", "who?", "when?" ?
Sep 28 2007
next sibling parent reply Ingo Oeser <ioe-news rameria.de> writes:
Hi Frank,

Frank Benoit wrote:

 But what about "how?", "who?", "when?" ?
Who? You. When? When your time permits. How? Make upload source and screenshots of a prototyped GUI somewhere and post a link to this newsgroups. Just be demanding things, they don't get magically done. So either fund it or do it :-) Best Regards Ingo Oeser
Sep 28 2007
parent Frank Benoit <keinfarbton googlemail.com> writes:
Ingo Oeser schrieb:
 Who? You.
 When? When your time permits.
 How? Make upload source and screenshots of a prototyped GUI somewhere
 and post a link to this newsgroups.
I did that. Thanks for the hint.
 Just be demanding things, they don't get magically done.
 So either fund it or do it :-)
But I think it is ridiculous to come up with a one man effort. A GUI maintained by one person, will die as soon as this person leaves. And - as i mentioned - I think that a simple widget collection is not enough. It should be kind of a GUI application framework. And this cannot be done by one spare time person. So we would need a good strategy/idea how to solve this. So I am here, asking for ideas.
Sep 28 2007
prev sibling parent reply BLS <nanali nospam-wanadoo.fr> writes:
Frank Benoit schrieb:
 BLS schrieb:
 Yes, that is what I think too.
 written from the scratch, based upon Tango.

 Bjoern
But what about "how?", "who?", "when?" ?
Indeed, seems to be a huge project. And for sure not doable for a single human beeing. Let's make some realistic guesses GUI for all major platforms 60-80.000 LOC, 3 - 6 developers DAO 20-30.000 LOC, 2 - 4 developers Framework architecture (depends) 20.000 LOC, 2 -4 developers All in all about 130.000 LOC Timeframe 1 year, including QA, and documentation. How : 1)Technical requirements a) SVN, better Mercurial b) IMO the most important thing, a platform independent IDE that supports realtime developper collaboration. 2) Planning a) Architecture GUI, DAO, Framework (allmost about pattern) Who : I am convinced that this project requires money (Maybe a foundation) to hire some full-time D developers. Another idea is to make the GUI SDK open source shareware... probabely paid before you have it ... just needs some clever ideas. When : Done : Money/ business plan Done : Planning Well, this is draft. Written in 5 minutes. Bjoern
Sep 28 2007
parent reply downs <default_357-line yahoo.de> writes:
BLS wrote:
 Indeed, seems to be a huge project. And for sure not doable for a single
 human beeing.
 
 Let's make some realistic guesses
 
 GUI for all major platforms 60-80.000 LOC, 3 - 6 developers
Just for the book, yawr's GUI is ~1500 LOC, 1 dev. :) Now admittedly, that's only the widgets I needed for YAWR, so it's rather limited, but still, 60k sounds a little much. --downs
Sep 28 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
downs wrote:
 BLS wrote:
 Indeed, seems to be a huge project. And for sure not doable for a single
 human beeing.

 Let's make some realistic guesses

 GUI for all major platforms 60-80.000 LOC, 3 - 6 developers
Just for the book, yawr's GUI is ~1500 LOC, 1 dev. :) Now admittedly, that's only the widgets I needed for YAWR, so it's rather limited, but still, 60k sounds a little much. --downs
Ah, but you're forgetting: he asked for a "framework" not a GUI toolkit. "Framework" implies all sorts of useless junk no one outside of three "enterprise" developers is *ever* going to know about, much less use. That GUI has to be able to make coffee and referee football matches by the time it's done. Plus, they haven't even gotten around to using the word "paradigm" yet; that's at least another 15k lines of code! :P -- Daniel P.S. MinWin 4 evar!
Sep 28 2007
next sibling parent downs <default_357-line yahoo.de> writes:
Daniel Keep wrote:
 
 downs wrote:
 BLS wrote:
 Indeed, seems to be a huge project. And for sure not doable for a single
 human beeing.

 Let's make some realistic guesses

 GUI for all major platforms 60-80.000 LOC, 3 - 6 developers
Just for the book, yawr's GUI is ~1500 LOC, 1 dev. :) Now admittedly, that's only the widgets I needed for YAWR, so it's rather limited, but still, 60k sounds a little much. --downs
Ah, but you're forgetting: he asked for a "framework" not a GUI toolkit. "Framework" implies all sorts of useless junk no one outside of three "enterprise" developers is *ever* going to know about, much less use.
No, "Framework" is a separate point in his original list. Allow me to quote:
 BLS wrote:
 GUI for major platforms 60-80.000 LOC, 3 - 6 devs // what I contested
 DAO 20-30.000 LOC, 2 - 4 developers // what's a DAO anyway?
 *Framework* architecture (depends) 20.000 LOC, 2 -4 developers
 That GUI has to be able to make coffee and referee football matches by
 the time it's done.
 
 Plus, they haven't even gotten around to using the word "paradigm" yet;
 that's at least another 15k lines of code! :P
All too true.
 
 	-- Daniel
 
--downs
 P.S.  MinWin 4 evar!
:)
Sep 28 2007
prev sibling parent BLS <nanali nospam-wanadoo.fr> writes:
Daniel Keep schrieb:
 
 downs wrote:
 BLS wrote:
 Indeed, seems to be a huge project. And for sure not doable for a single
 human beeing.

 Let's make some realistic guesses

 GUI for all major platforms 60-80.000 LOC, 3 - 6 developers
Just for the book, yawr's GUI is ~1500 LOC, 1 dev. :) Now admittedly, that's only the widgets I needed for YAWR, so it's rather limited, but still, 60k sounds a little much. --downs
Ah, but you're forgetting: he asked for a "framework" not a GUI toolkit. "Framework" implies all sorts of useless junk no one outside of three "enterprise" developers is *ever* going to know about, much less use.
I am not nessesarily talking about Enterprise frameworks. Ever heard about RoR, .NET, MVC, DAO, MFC ? :) All of them are relative small but usefull frameworks. Beside, at least parts of Enterprise Framework patterns have found there way into smaller frameworks. just to name one: The Active Record pattern.
 That GUI has to be able to make coffee and referee football matches by
 the time it's done.
 
 Plus, they haven't even gotten around to using the word "paradigm" yet;
 that's at least another 15k lines of code! :P
 
 	-- Daniel
 
 P.S.  MinWin 4 evar!
MinWin ? I guess you don't have to sell your products. :) Seriously, I need a GUI which works on db-tables, sortable/searchable table-controls I need grids,tree-tables,charts etc. In other words, D is not usable for me as production system. Bjoern
Sep 29 2007
prev sibling next sibling parent reply torhu <no spam.invalid> writes:
Frank Benoit wrote:
 Again and again it is said in this newsgroup: "D needs a GUI"
 But there are existing alternatives:
 DFL/GTKD/MinWin/DWT/wxD/....
 (and more http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries)
 So I think some ppl are happy with one of those existing solutions.
 
 So what is missing for those, who say D needs a GUI?
 
 In the world outside of D, there are those big ones:
 - .NET/Mono
 - Eclipse RCP, Netbeans
 - QT
 - ...?
 
 They all are not only a GUI, say a collection of basic controls. They
 are complete frameworks. They offer complete Dialogs, separation of data
 and presentation (MFC/data binding), persistance, update mechnisms,
 docking systems, extension mechanisms, tools, IDE support, commercial
 support, ...
 
 Is it something like this, ppl mean if they say 'D needs a GUI'?
 I can only speak for myself, and yes, that is what I think. I wish i
 could use a framework, which has an answer for many of the common tasks
 while building a GUI application.
 
 What do you think, does this problem "D needs a GUI" really exist?
 Seriously, how can this be solved in the next 1..2 years?
 .... and who will do it?
 
It doesn't seem likely that a complete, cross-platform, well maintained gui library written from scratch in D is going to surface for the next 5 years or so. Maybe never if D doesn't gain more momentum. Since I like SWT better than wxWidgets, the best thing as I see it would be that the tioport project is able to solve its current problems. The problems being exe size, and the tango/phobos compatibility issue, off the top of my head. I know that both problems might depend on Walter doing his part, but that might happen sooner or later. Who knows.
Sep 28 2007
parent Frank Benoit <keinfarbton googlemail.com> writes:
 It doesn't seem likely that a complete, cross-platform, well
 maintained gui library written from scratch in D is going to
 surface for the next 5 years or so. Maybe never if D doesn't
 gain more momentum.
Yes, thats also my fear.
 Since I like SWT better than wxWidgets, the best thing as I see it would
 be that the tioport project is able to solve its current problems. The
 problems being exe size, and the tango/phobos compatibility issue, off
 the top of my head.  I know that both problems might depend on Walter
 doing his part, but that might happen sooner or later.  Who knows.
I don't think it depends on Walter. Porting such huge chunks of source code is probably always a dead end.
Sep 28 2007
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Frank Benoit wrote:
 Again and again it is said in this newsgroup: "D needs a GUI"
 But there are existing alternatives:
 DFL/GTKD/MinWin/DWT/wxD/....
 (and more http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries)
 So I think some ppl are happy with one of those existing solutions.
 
 So what is missing for those, who say D needs a GUI?
 
 In the world outside of D, there are those big ones:
 - .NET/Mono
 - Eclipse RCP, Netbeans
 - QT
 - ...?
 
 They all are not only a GUI, say a collection of basic controls. They
 are complete frameworks. They offer complete Dialogs, separation of data
 and presentation (MFC/data binding), persistance, update mechnisms,
 docking systems, extension mechanisms, tools, IDE support, commercial
 support, ...
 
 Is it something like this, ppl mean if they say 'D needs a GUI'?
 I can only speak for myself, and yes, that is what I think. I wish i
 could use a framework, which has an answer for many of the common tasks
 while building a GUI application.
 
 What do you think, does this problem "D needs a GUI" really exist?
 Seriously, how can this be solved in the next 1..2 years?
 ... and who will do it?
I think who will do it is the real issue. Without a leader the GUI will die. Walter didn't kill DWT by giving it his blessings, the main developer(s) killed it by moving on to other things. If you're going to make THE gui for D (or any language), then you'd better be prepared to embark on a 5-10 year, or perhaps even life-long project. You'll need to make frequent releases. And you better respond to people's questions. Not just this week but for the next 5-10 years. And have a bug tracker and use it. And treat people's patches as precious, either telling them why you're rejecting them or incorporating them ASAP. And write lots of documentation and tutorials and example programs demonstrating your library. And really that applies to any big open source library or project. People don't want to rely on any project that seems to be the main developer's "when I can find time" side project. Currently DFL seems the closest to me to having this kind of dedicated leader. Hmm.. maybe I should see if there's anything to do to help DFL out... --bb
Sep 28 2007
next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bill Baxter wrote:
 Frank Benoit wrote:
 Again and again it is said in this newsgroup: "D needs a GUI"
 But there are existing alternatives:
 DFL/GTKD/MinWin/DWT/wxD/....
 (and more http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries)
 So I think some ppl are happy with one of those existing solutions.

 So what is missing for those, who say D needs a GUI?

 In the world outside of D, there are those big ones:
 - .NET/Mono
 - Eclipse RCP, Netbeans
 - QT
 - ...?

 They all are not only a GUI, say a collection of basic controls. They
 are complete frameworks. They offer complete Dialogs, separation of data
 and presentation (MFC/data binding), persistance, update mechnisms,
 docking systems, extension mechanisms, tools, IDE support, commercial
 support, ...

 Is it something like this, ppl mean if they say 'D needs a GUI'?
 I can only speak for myself, and yes, that is what I think. I wish i
 could use a framework, which has an answer for many of the common tasks
 while building a GUI application.

 What do you think, does this problem "D needs a GUI" really exist?
 Seriously, how can this be solved in the next 1..2 years?
 ... and who will do it?
I think who will do it is the real issue. Without a leader the GUI will die. Walter didn't kill DWT by giving it his blessings, the main developer(s) killed it by moving on to other things. If you're going to make THE gui for D (or any language), then you'd better be prepared to embark on a 5-10 year, or perhaps even life-long project. You'll need to make frequent releases. And you better respond to people's questions. Not just this week but for the next 5-10 years. And have a bug tracker and use it. And treat people's patches as precious, either telling them why you're rejecting them or incorporating them ASAP. And write lots of documentation and tutorials and example programs demonstrating your library. And really that applies to any big open source library or project. People don't want to rely on any project that seems to be the main developer's "when I can find time" side project. Currently DFL seems the closest to me to having this kind of dedicated leader. Hmm.. maybe I should see if there's anything to do to help DFL out... --bb
Whatever happened to making the code clean and structured enough so that other people can re-use it, even if the main developer now has no time? -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 29 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Bruno Medeiros wrote:
 Bill Baxter wrote:
 Frank Benoit wrote:
 Again and again it is said in this newsgroup: "D needs a GUI"
 But there are existing alternatives:
 DFL/GTKD/MinWin/DWT/wxD/....
 (and more http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries)
 So I think some ppl are happy with one of those existing solutions.

 So what is missing for those, who say D needs a GUI?

 In the world outside of D, there are those big ones:
 - .NET/Mono
 - Eclipse RCP, Netbeans
 - QT
 - ...?

 They all are not only a GUI, say a collection of basic controls. They
 are complete frameworks. They offer complete Dialogs, separation of data
 and presentation (MFC/data binding), persistance, update mechnisms,
 docking systems, extension mechanisms, tools, IDE support, commercial
 support, ...

 Is it something like this, ppl mean if they say 'D needs a GUI'?
 I can only speak for myself, and yes, that is what I think. I wish i
 could use a framework, which has an answer for many of the common tasks
 while building a GUI application.

 What do you think, does this problem "D needs a GUI" really exist?
 Seriously, how can this be solved in the next 1..2 years?
 ... and who will do it?
I think who will do it is the real issue. Without a leader the GUI will die. Walter didn't kill DWT by giving it his blessings, the main developer(s) killed it by moving on to other things. If you're going to make THE gui for D (or any language), then you'd better be prepared to embark on a 5-10 year, or perhaps even life-long project. You'll need to make frequent releases. And you better respond to people's questions. Not just this week but for the next 5-10 years. And have a bug tracker and use it. And treat people's patches as precious, either telling them why you're rejecting them or incorporating them ASAP. And write lots of documentation and tutorials and example programs demonstrating your library. And really that applies to any big open source library or project. People don't want to rely on any project that seems to be the main developer's "when I can find time" side project. Currently DFL seems the closest to me to having this kind of dedicated leader. Hmm.. maybe I should see if there's anything to do to help DFL out... --bb
Whatever happened to making the code clean and structured enough so that other people can re-use it, even if the main developer now has no time?
It's fine. But it's not enough. --bb
Sep 29 2007
prev sibling parent reply Jordan Miner <jminer2613 students.pcci.edu> writes:
I have been writing a GUI library from scratch in D for over a year now. Of
course, I would like it to become the most popular GUI for D (who wouldn’t?),
but regardless I have had fun working on it and using it for my own programs.

Here is what I think about the current GUI libraries:
My problem with DFL is that since it uses native Windows controls and copies
Windows Forms so much IMO it would be difficult to get working right on Linux
and Macintosh. Other than that, I think it works great on Windows.
As far as GTKD and DUI, I would never in a million years consider using GTK, as
it looks horrible on Windows (and probably Macintosh).
Does DWT have a different API on each platform? If so, that rules it out for me.
With wxD, since wxWidgets uses native controls, it looks good on every platform
most of the time and already works on Windows, Linux, and Macintosh. I don't
really like its API, but if I were not writing my own library, I would probably
use wxD.
Note that I have never used any of these libraries, but I have looked at
documentation and examples. And I have used programs that use their underlying
libraries (GTK, SWT, wxWidgets).

For my library, I decided to not use native controls, partly to make it easier
to port and use on different platforms and partly for flexiblity. I already
have working Windows and X backends, and partially implemented buttons, check
boxes, radio buttons, list boxes, tabs, text boxes, themes, file and directory
dialogs, and clipboard support. For graphics, I am using the cairo graphics
library http://cairographics.org

My biggest goal is ease of use and the ability to do tasks with the shortest,
simplest code. I do not want a large, bloated library, and, so far, the GUI
part is only about 5,000 LOC. I believe 20,000 LOC for a GUI library is more
than enough. (for most features, anyway. There are lots of features a GUI
library could have that would be nice, but not necessary, such as an SVG
renderer.)

Bill Baxter Wrote:
 If you're going to make THE gui for D (or any language), then you'd 
 better be prepared to embark on a 5-10 year, or perhaps even life-long 
 project.  You'll need to make frequent releases.  And you better respond 
 to people's questions.  Not just this week but for the next 5-10 years. 
   And have a bug tracker and use it.  And treat people's patches as 
 precious, either telling them why you're rejecting them or incorporating 
 them ASAP.  And write lots of documentation and tutorials and example 
 programs demonstrating your library.
I agree. All of this is important for a widely used library. I cannot see myself stopping work on this project, as I am fairly addicted to using computers, and this is something that I really like doing. I do work on it in my spare time and am in college, but I have still done a lot in the last year. I have not released it yet, but when I do, I would like to get other people involved. I still have a few things to do before I put it on the internet, such as get the Windows and X backend to have the same functionality, fix the naming convention, move to tango, and get a final name. (How’s Daimyo? It is short and starts with a D. http://en.wikipedia.org/wiki/Daimyo )
Sep 29 2007
next sibling parent Jan Claeys <usenet janc.be> writes:
Op Sat, 29 Sep 2007 13:21:20 -0400
schreef Jordan Miner <jminer2613 students.pcci.edu>:

 As far as GTKD and DUI, I would never in a million years consider
 using GTK, as it looks horrible on Windows
Did you see/use the GTK-Wimp skin? <http://gtk-wimp.sourceforge.net/screenshots/> -- JanC
Sep 29 2007
prev sibling parent "Kris" <foo bar.com> writes:
That sounds interesting! Make it fully skinnable (so it can look like the 
native platform), and you'll have yourself a jolly audience :)

Besides, Cairo is teh shizzle ;p

Any screenshots so far?



"Jordan Miner" <jminer2613 students.pcci.edu> wrote in message 
news:fdm1ig$110n$1 digitalmars.com...
I have been writing a GUI library from scratch in D for over a year now. Of 
course, I would like it to become the most popular GUI for D (who 
wouldn't?), but regardless I have had fun working on it and using it for my 
own programs.

 Here is what I think about the current GUI libraries:
 My problem with DFL is that since it uses native Windows controls and 
 copies Windows Forms so much IMO it would be difficult to get working 
 right on Linux and Macintosh. Other than that, I think it works great on 
 Windows.
 As far as GTKD and DUI, I would never in a million years consider using 
 GTK, as it looks horrible on Windows (and probably Macintosh).
 Does DWT have a different API on each platform? If so, that rules it out 
 for me.
 With wxD, since wxWidgets uses native controls, it looks good on every 
 platform most of the time and already works on Windows, Linux, and 
 Macintosh. I don't really like its API, but if I were not writing my own 
 library, I would probably use wxD.
 Note that I have never used any of these libraries, but I have looked at 
 documentation and examples. And I have used programs that use their 
 underlying libraries (GTK, SWT, wxWidgets).

 For my library, I decided to not use native controls, partly to make it 
 easier to port and use on different platforms and partly for flexiblity. I 
 already have working Windows and X backends, and partially implemented 
 buttons, check boxes, radio buttons, list boxes, tabs, text boxes, themes, 
 file and directory dialogs, and clipboard support. For graphics, I am 
 using the cairo graphics library http://cairographics.org

 My biggest goal is ease of use and the ability to do tasks with the 
 shortest, simplest code. I do not want a large, bloated library, and, so 
 far, the GUI part is only about 5,000 LOC. I believe 20,000 LOC for a GUI 
 library is more than enough. (for most features, anyway. There are lots of 
 features a GUI library could have that would be nice, but not necessary, 
 such as an SVG renderer.)

 Bill Baxter Wrote:
 If you're going to make THE gui for D (or any language), then you'd
 better be prepared to embark on a 5-10 year, or perhaps even life-long
 project.  You'll need to make frequent releases.  And you better respond
 to people's questions.  Not just this week but for the next 5-10 years.
   And have a bug tracker and use it.  And treat people's patches as
 precious, either telling them why you're rejecting them or incorporating
 them ASAP.  And write lots of documentation and tutorials and example
 programs demonstrating your library.
I agree. All of this is important for a widely used library. I cannot see myself stopping work on this project, as I am fairly addicted to using computers, and this is something that I really like doing. I do work on it in my spare time and am in college, but I have still done a lot in the last year. I have not released it yet, but when I do, I would like to get other people involved. I still have a few things to do before I put it on the internet, such as get the Windows and X backend to have the same functionality, fix the naming convention, move to tango, and get a final name. (How's Daimyo? It is short and starts with a D. http://en.wikipedia.org/wiki/Daimyo )
Sep 29 2007
prev sibling parent Jay Norwood <jayn io.com> writes:
I've developed with swt on an eclipse project at work, and am glad to see that
one already ported.  Another I used previously for Solaris was the fox tools,
which I'm surprised no one has ported yet.  

http://www.fox-toolkit.org/fox.html

Another guy has done several years of work on extension to the fox tools,  
creatigg a more extensive cross-platform framework.  I'm amazied at the amount
of work he's put into it.  It might make a good candidate for a port.

http://www.nedprod.com/TnFOX/




 In the world outside of D, there are those big ones:
 - .NET/Mono
 - Eclipse RCP, Netbeans
 - QT
 - ...?

 They all are not only a GUI, say a collection of basic controls. They
 are complete frameworks. They offer complete Dialogs, separation of data
 and presentation (MFC/data binding), persistance, update mechnisms,
 docking systems, extension mechanisms, tools, IDE support, commercial
 support, ...
Sep 30 2007