> As for this primitive graphics library, there already exists one, (made in C), and it not only exists, but it is *The* library. I hope you know which one I'm talking about, and I hope too that you realize that your work should be to make a D layer/version of this lib. Not a direct C wrapper, as that already exists, but one to make use of the relevant D's prime features (OO and structured namespacing)

Sorry, I don't know what is *The* library.
OpenGL probably?

If yes then it is overkill to use it for drawing e.g. one particular custom
button
in let's say some IDE. (I am assuming that all other UI in IDE is using only
standard
set of native OS widgets).

Ideally Standard D Graphics Module/Package shall allow
to do basic drawing without any third party library and
use only OS native primitives.

Nobody will want to create a calculator.exe which will
*always* require installation of some additional DLLs or new version
of the Framework.

Andrew.

In article <ds7un0$6va$1@digitaldaemon.com>, nick says...
>
>Oh, and: http://www.hacknot.info/hacknot/action/showEntry?eid=74
>
>those issues too.

You do raise some good points. Nick, I nominate you to lead this effort, if you have the time. A couple of things I'd like to add though (all IMHO of course):

- License: Assuming the lib. itself is OSS of some form, most importantly it will allow developers to use the D version of the lib. commercially w/o posting their own code.

- Ease of use 'out of the box': Is vital - far and away the most important thing for a D GUI lib. to get accepted and *used* by the great majority of developers.

After the initial selections are made, as part of the overall eval., I think someone should develop an app. for each that opens a window with a button that would display "Hello World" 10 times in a (rich) text box. Simplistic? Yes, but half the battle is convincing people to use the library, and most of those people will start out with an app. just that simple.

For example, considering D's 'style' the ideal would be something like this for me:

import D.gui;
Form f;
Button b;
TextBox t;
void main()
{
f = new Form(0,0,300,300); // default modal,x,y,w,h
b = new Button(f,"Click Me",8,8,75,23); // parent,caption,x,y,w,h
b.Click = &buttonb_onclick;
t = new TextBox(f,88,8,192,248,true); // parent,x,y,w,h,multi-line
f.Show;
}
void buttonb_onclick(EventInfo* e)
{
for(int i = 0; i < 10; i++)
t += "Hello World\n";
}

Just so we can look at the various development 'styles' represented by each.

I'd be happy to help with this *if* I'm not swamped at work when you are ready.

- IDEbility: Is that a word? The lib. we choose should be comparitively easy for 'visual' IDE's to manage the code, needing nothing but legal D code (plus 'anchor' comments) for the majority of uses. The above example shows a 'style' lending itself to that too, I think.

- Performance: Not real important (imagine me saying that!), as long as it isn't a total dog, and the overall winner should have a desing that avoids 'object churn' for larger projects. From what I understand, SWT was originally developed as an answer to basically one thing: object churn.

I (and I think others) don't want a toolkit where the choice was made biased toward game programmers just because it includes a great graphics engine at it's core. The game specific stuff can (and probably should) come from a different library.

- Dave

In article <ds83p6$bmf$3@digitaldaemon.com>, Walter Bright says...
>"nick" <nick.atamas@gmail.com> wrote in message news:ds7542$2fvm$1@digitaldaemon.com...
>> I should caution you against DWT/SWT. In addition to reasons outlined by Roberto Mariottini SWT will be viewed by many people as a "bad move for D", because SWT is a large toolkit that has severe issues. This will create a negative image of stagnation and other negative characteristics associated with SWT. JFace is even more problematic.
>
>The problem is, I've heard such strongly negative comments about every GUI toolkit out there.

Agreed. They all have issues. However, "no gui toolkit" may be better than SWT.

If I had to pick a toolkit to port right off the top of my head, I would choose QT.

Problem: QT vs SWT
------------------
When you google for QT problems you find bugs and people making mistakes while
learning. When you google for SWT problems, you find pages of experts mentioning
SWT design flaws. QT has a prooven track record of being used by commercial
entities whereas SWT has only a small number of applications all of which have
major issues. Why? Because SWT was built to build the Eclipse IDE. When you try
to use it, you always get an eclipse-IDE as a result, even if that's not what
you intended. You can't grow SWT because it's too compelx and broken, so you are
stuck. (All the classes come with a commet: DO NOT EXTEND THIS OR YOU WILL BREAK
THINGS.)
Many people have praised QT as being the best UI toolkit they have ever used. It
definitely has its problems, but moving QT from C++ to D would fix a lot of
them.

Memory: QT vs SWT
------------------
As far as language is concerned, QT and SWT use very similar memory managing models (everything is allocated in the constructor dynamically and freed in the destructor; you end up with a tree where every parent widget keeps track of memory for all its children). That's right, SWT is not _really_ garbage collected; it calls dispose.


Problem: QT vs SWT
------------------
So, my suggestion:
You aren't a GUI expert. I have GUI experience. The people at trolltech are GUI
*EXPERTS*. Furthermore, they have an Open Source evangelist. If we don't know
what we are doing, let's at least ask someone who really does -
http://www.trolltech.com/developer/scottcollins.html.

Who knows what will happen? It is possible that, with a more or less stable D, the next iteration of QT will come with D bindings. At the very least, we can learn things from Scott Collins. It may very well be the case that mimicking QT is going to be easier than SWT.

My lunch break is almost over, but I would be glad to provide a more concrete argument with specific details when I get home.

"nick" <nick_member@pathlink.com> wrote in message news:ds8f77$mvh$1@digitaldaemon.com...

> Problem: QT vs SWT

[skiped]

Agree.

QT is good as does GNOME btw.

But these are, as they say widget toolkits.
They implement everything by hand - every
combobox, editbox, etc. is implemented in QT code.
The same approach uses Swing. And there are pluses and minuses of
this approach. E.g. native OS look-n-feel is a huge task there.
But again for some applications this is not bad at all.

<quote src="http://en.wikipedia.org/wiki/Qt_toolkit#Design">

Complete abstraction of the GUI

Qt uses its own paint engine and controls. It emulates the look of the different platforms it runs on. This made the porting work easier because very few classes in Qt depended really on the target platform. The drawback is that Qt had to emulate precisely the look of the different platforms. This drawback however no longer applies because the latest versions of Qt use the native styles API of the different platforms to draw the Qt controls.

Other portable graphical toolkits have made a different design decision, such as wxWidgets, MFC (Windows only), and the Java based SWT[2] which use the toolkit of the target platform for their implementation.

</quote>

Sidenote: Harmonia uses same approach and it is "natively D" from the very
    beginning, btw. It has own widgets:
    http://www.terrainformatica.com/harmonia/screenshots/harmonia.png
    But I am not proposing Harmonia to be a "Standard GUI toolkit"
    for the simple reason - it is not a toolkit for general use by
definition.
    Harmonia implements only one particular paradigm - OS independent
    windowless toolkit( you may think about it as about micro-QT if you
wish.)
    But there are many cases when you would like to use OS widgets -
    for example html browser (IE or Gecko) widgets.

Andrew Fedoniouk.
http://terrainformatica.com

Walter Bright wrote:
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:ds1g3o$1d63$1@digitaldaemon.com...
>>> 1) Do nothing and argue that a standard gui is a bad idea.
>> Exactly! I don't even know what "standard gui" means.
>> Each application (or group of applications) has its own requirement set here.
>> "standard" of what for the byte sake?
> 
> All standard means is there are is a gui library as part of the D standard, it wouldn't be a separate add-on.
> 
> 
>> I don't understand where this "standard GUI" bright idea comes from.
>> Even Java has no single toolkit: AWT and Swing, SWT plus 3 or 4 more.
> 
> Java started out with just AWT. Without AWT, Java would have gotten nowhere. The other gui libraries came along later as the user base expanded. AWT was Java's proverbial "chicken" to bootstrap the process. We need one, too. It isn't like DWT will be the only gui toolkit ever.
> 
>> The point here - even in Java with its "official
>> toolkit" (two of them, btw) in real life you will be forced to use your own at the end.
> 
> I'm not a bit surprised. Nobody has figured out the last word in gui toolkits.
> 
>> So the question - what is this "standard GUI" for?
> 
> If you like, think of having a standard gui like DWT as useful for marketing. It *is* a big win for marketing the language. Quite a lot of people think it is necessary before even considering D, therefore it is necessary.
> 
Ye, about that... I'm a bit confused on this "standard" GUI thing too. What does it mean and entail? Would it be shipped together with Phobos in the compiler distribution?
And about those "a lot of people think it is necessary", who are they? Do they think D needs a GUI, or do they think D needs a *standard* GUI? (because the latter D already has, several)
I do recall some occasional complaints, but honestly, by the way they were presented I didn't took them seriously. And I too didn't think you would take them seriously Walter (see below).

>> Again, solution could be in building "standard GUI" pyramid
>> from reusable blocks like Graphics Package, etc.
>> Such blocks will have more chance to be a) accepted widely
>> b) to be not thrown away if something will go wrong.
>> If you wish we can establish sort of working group
>> on creation of such D GUI foundation,
>> Graphics Package, etc.
>> I am short on time a bit now but will try to do something here
>> if we need to.
> 
> I think you're probably right, and this would be a better long term solution than DWT is, so I encourage you to work on it. But we need something now.
> 
We need it now, really? Why?
Of all the problems people have with D: language features (templates, ITFI, many more...), fixing/improving the standard library, fixing/improving the docs, contributing new stuff(regexps, recls, etc.) possibly in-language, toolchain (full-featured IDE/editor, full-featured debugger), books in D, and "having a GUI", the GUI one is a superficial one.
We already have pretty decent GUI libs and the difference between a GUI being official/standard or not could only possibly be in having to download and install an additional package besides the compiler, whereas the other problems are actually important. They cannot be workedaround and will actually require significant work by part of Walter and/or someone else in the community. So how can *anyone* call this GUI issue a real problem?

I would like the GUI proponents to explain this to me, as the few posts about this that I vaguely recall from far ago were simple "D needs a GUI too, because I like GUI very much", but no rationale how or why (or even explicit mention of the term "standard").

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

"nick" <nick_member@pathlink.com> wrote in message news:ds8f77$mvh$1@digitaldaemon.com...
> If I had to pick a toolkit to port right off the top of my head, I would choose QT.

QT cannot be used because it's a proprietary, non-free product.

On Mon, 06 Feb 2006 23:02:10 +0000, Bruno Medeiros wrote:

> Walter Bright wrote:
>> I think you're probably right, and this would be a better long term solution than DWT is, so I encourage you to work on it. But we need something now.

> We need it now, really? Why?
> Of all the problems people have with D: language features (templates,
> ITFI, many more...), fixing/improving the standard library,
> fixing/improving the docs, contributing new stuff(regexps, recls, etc.)
> possibly in-language, toolchain (full-featured IDE/editor, full-featured
> debugger), books in D, and "having a GUI", the GUI one is a superficial
> one.

Agreed that a standard GUI library is very priority in the TODO list. There are many higher priority things that we need Walter to do. And some are real simple (of the low hanging fruit variety).

e.g. A clean up of the phobos code: correct all the 'module' statements (including missing ones) and get it to compile with "-w" turned on. Should take about an afternoon to complete and makes me feel like Walter actually cares about it.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
7/02/2006 10:30:36 AM

On Tue, 7 Feb 2006 10:36:27 +1100, Derek Parnell wrote:


> Agreed that a standard GUI library is very priority in the TODO list.

but I meant ....

Agreed that a standard GUI library is a very low priority in the TODO list.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
7/02/2006 10:38:54 AM

Walter Bright wrote:
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:ds10up$14av$1@digitaldaemon.com...
>> Forget about STL and boost. There is no practical GUI  toolkit in the wild
>> using them anyway.  (This fact speaks for itself)
> 
> I know. I have a suspicion that both are evolutionary dead ends. Your fact is evidence for that, as well as the failure of any other language to pick up those features. 
> 
> 

Whoa, huh...? STL is an evolutionary dead end and no other languages have picked it up? Doesn't the STL include mainly generic containers? Then, how is it that that has not been incorporated in other languages?

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

"Walter Bright" <newshound@digitalmars.com> wrote in message news:ds8lvv$s2k$2@digitaldaemon.com...
>
> QT cannot be used because it's a proprietary, non-free product.

Yep, and yet: http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12 :)