GUI strategy?

[Yigal Chripun]

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.