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

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

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.

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

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.

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

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

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

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!

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