"Craig Black" <cblack@ara.com> wrote in message news:ds0lt7$srs$1@digitaldaemon.com...
> If I understand you correctly, you are suggesting creating cross-platform solutions for components that will be useful to any GUI framework.  Once these components are in place (perhaps in a standard library), the task of creating the the GUI framework becomes less overwhelming.  It is the logical first step.  Is this a correct assessment of what you are proposing?

Exactly.

Take a look: all toolkits have classes like
Graphics with acompanying Font, Image and other drawing primitivies.
Can we make them as some standard package? Sure, I would say we must to.
Another candidate for standard library are Rect, Point, Polygon - geometric
primitives.

Will all toolkits benefit if we would have them as a standard library? Sure. For example: harmonia.html package as a pure renderer or layout manager could be used in DWT, DFL, etc. if they will use common drawing and geometry primitivies from the "Standard D Graphics" package. Thus all toolkits could have "declarative UI" functionality.

Splitting GUI framework into three modules allows to design
them indepenedently and to do not waste time of relatively small comunity.
"We are not so rich to by cheap things".

Andrew Fedoniouk.
http://terrainformatica.com

"Trevor Parscal" <Trevor_member@pathlink.com> wrote in message news:ds0b3u$jbs$1@digitaldaemon.com...
> I love D, and will probably be a D programmer for life. I have allot of
> time
> invested in Terra, Titan, and Fusion, and hope to contribute to the
> community
> even more as time goes on - I would hate for D to never really spread,
> just
> because we missed the point.

I don't think there is one point - the blocking items for people are different. Some seem to be blocked by templates, others by regex, others by recls (hi Matthew!), others by gui, others by there's no D book, etc. We just have to keep bashing away at this.

"Sebastián E. Peyrott" <as7cf@yahoo.com> wrote in message news:ds0h70$o63$1@digitaldaemon.com...
> I believe a GUI should not be directly incorporated into the standard library.

It won't be part of phobos, it'll have its own prefix.

> Although that's just my subjective way of seeing a standard library.
> Support for
> independent projects is what seems to be best IMO.
> As someone said before, supporting different projects and different ways
> of
> taking up on this problem is what needs to be done. wxD, DWT, DUI,
> whatever.
> Choice is attractive, and we can already offer that, even if it's not
> complete
> ;).

Choice is attractive, and endosing DWT will not prevent other gui libraries from being used in any way. However, having a default gui that comes with the language can be very compelling for users. After all, that's why languages come with libraries <g>. Sometimes too many options can be a detriment, peoples' eyes glaze over and they just move off and use something else where the path is more clear.

That seems to happen a lot whenever someone mentions on a n.g. "what gui do I use with C++?"

You've made some very good points, and I want to address them.

1) Yes, there are the two major approaches to a gui toolkit, good for different purposes. But right now, the important thing is that we have one, not which approach it is. As D grows, then other guis with the other approaches will naturally become available. Picking DWT now does not shut the door on those others, all it does is get enough momentum and focus to get one *done*. It's the chicken and egg problem here, people won't use D because it has no gui, people won't develop guis because there's no people using D. Even if it's not the perfect chicken, we need a chicken to start our farm <g>. Once our farm is going, then we can buy some better chickens and add them in.

2) I agree that it would be better to use delegates and other cool D features to do a better gui design than SWT. I discussed this at length with Kris in email a while back, we both came to the conclusion that this is just not practical to do right now, because we don't have a large staff of minions paid to attack this problem. We have very limited resources, so it's all about leverage. We need a chicken to bootstrap the process, and the fastest way to get one is to forget about redesigning SWT, but to just translate it as is.

3) DWT doesn't need to track changes in SWT once DWT is built. If it forks from SWT, that's OK, because then we'll have our chicken, and so we'll have eggs, then more chickens, etc.

4) You're right in that automated translation from Java to a D program isn't going to work 100%, 90%, or even 80%. If it works 75%, with 25% manual fiddling, that's still a big leg up. The percentage for C++ would be a lot lower, especially if the C++ code uses STL or Boost, where it won't work at all. I tend to write C++ code that would easilly convert to D, but very little of what I run across otherwise would.


"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:ds0i3b$pgs$1@digitaldaemon.com...
> Walter,
>
> can we first define sort of requirements sheet for such thing as "D standard GUI library"?
>
> Sidenote: My deepest respect to Shawn Liu for his tremendous effort to
> port SWT.
> DWT  is really something, but this message about principles rather than
> his
> and some other library in particular.
>
> First of all:
>
> There are two types of approaches universal GUI toolkits are based on:
>    a) wrappers of native OS widgets - AWT/SWT/DWT per se,
>        MFC(at some extent), WTL, etc.
>    b) OS agnostic toolkits implementing their own set of widgets:
>        SWING, GTK, QT, FLTK, FoxToolkit, etc. (my Harmonia is also here)
>
> It depends on the task you need to accomplish which one to choose.
> Obviously toolkits from group A are too OS dependent - as a rule they have
> very thick OS isolation layer and sometimes it is just impossible to make
> a common denominator for different OSes. For example Mac and Win are
> so distinct that it is almost impossible to make practical library (fast,
> effective, compact)
> natively working on both - different principles at all: event dispatching,
> windowing,
> resource architecture, etc.
> Group B has its own pluses and minuses: it is best suitable for
> applications
> which has their own UI standards - really look the same on different
> platforms:
> IDEs, games, things like Google's Picasa or Norton Antivirus - all that
> types of applications.
>
> Sidenote: The history of Swing / SWT wars in Java has simple origin:
>   architectire of Java drawing is based on assumption that "memory
>   is not a resource anymore and GC rocks" thus such things as
>   <java>
>   Dimension Component.getDimension() { return new Dimension(dimension); }
>   </java>
>   (immutability for dummies) are spreaded all over the code
>    making GUI a "joy of GC".  Surely they got a problem in drawing, so SWT
>    was born with the motto:  "If we cannot draw complex things fast then
>    we will delegate this to OS"  Thus and so SWT far less OS
>    independent than Swing.
>
> Second:
>
> Java code as a source...
> I really don't want to start this fire again but:
> 1) "D is not Java" "D is not C++" (C) Walter Bright.
>    Not in notation, not in runtime/VM model, not in architecture.
>    So as we have "Automated translation from C++ is essentially
> impossible." in the
>    same essential way we can say "Automated translation from Java is
> impossible."
>    (Doing Harmonia I personally find that porting code from C++ and Java
> is
>     a task of the same complexity - to be precise - not complex at all,
>     just requires "new D thinking" )
> 2) Automatic translation Java to D... I beleive such tool is just not
>    practically feasible to be honest.
> 3) Having port of SWT always means dependency from it.
>    I beleive that conceptually DWT is a fork - after some point it
>    will go its own way. This is a reality and I don't see nothing criminal
> in that.
>    Just don't even think that you can take project A from Java and do
>    automatic upgrades of D side each time than they will do something new.
>
> Third:
>
> Traditionally any GUI toolkit is a test case of  OOP features of
> particular
> language. I beleive that OOP in D is way superior and handy than what Java
> and C++ offer now. I think that "D standard GUI library" if it will exist
> shall use full
> potential of D from ground up rather than try to inherit OOP workarounds
> from
> Java and C++. Think about delegates at least.
> "D standard GUI library" shall be a hymn of D and not a rehash of some
> other song
> but in different language.
>
> And the last.
> Here is my vision of what "D standard GUI library" should be:
>
> It should be not a single entity but following three:
>
> 1) Standard D Graphics package (SDG) - this is really could be made in
> uniform fashion -
> all GUI OSes has concept of Surface or Graphics and have primitives like
> draw text, draw line etc. Support of Image (and different formats) is also
> here.
> (If we will have only this then it will benefit a lot - different
> frameworks can share
> at least drawing code).
>
> 2) Standard Application Framework, SAF (uses SDG)
> These should use MinWin (Ben Hinkle) approach  -
> minimalistic application framework (events, winmain, menu, OS integration)
> allowing to build application with native look-n-feel for underlying
> platform.
> This framework deals with native OS windows and knows about them and
> probably shall exists in three versions: for Win32, Mac, GTK
> Nothing from rocket science here please: pure window creation and
> handling of native OS events in human readable manner.
>
> 3) Standard "X".... I don't know of how to name this but something like
> Harmonia
> or its part: system of OS independent (windowless) widgets + html engine.
> This Standard "X" shall also use SDG and shall allow to be
> embedabble into SAF (as a component living in some window)
> Also this Standard "X" shall allow to build pure OS independent
> applications (using only top level Window frames from SAF).
>
> Having all these will give D flexibility in various GUI approaches and demonstrate the power of D .
>
> Andrew Fedoniouk.
> http://terrainformatica.com

"Kyle Furlong" <kylefurlong@gmail.com> wrote in message news:ds0m2i$sus$1@digitaldaemon.com...
> As long as we are critiquing DWT...
>
> 1. No Ares support
> 2. Java-like coding style = YUCK!
>
> But as we all know it is a very useful tool, so maybe the PRACTICAL thing is to support it officially.

Personally, I don't like the java coding style either. But think of it like strapping a rocket engine on a chicken, once we get that sucker off the ground, we can build ourselves a nicer set of wings <g>.

> Take a look: all toolkits have classes like
> Graphics with acompanying Font, Image and other drawing primitivies.
> Can we make them as some standard package? Sure, I would say we must to.
> Another candidate for standard library are Rect, Point, Polygon - geometric primitives.

I definitely would like to see something like this... but in the back of my head - with my limited knowledge - I'm wondering how exactly something like this would work.  For example, presumably we are drawing all of these things in a window, right?  So that sort of implies that even a default, simple and "primitive" graphics functionality also involves a standard cross-platform syntax to create and manipulate a window.  So what properties does a window need?  And I would guess that this is the point where things start to snowball out of control with issues like resolution, modality, fullscreen support, color depth, etc.

I remember fondly working with Borland's flavor of C++ in DOS, and using those most basic of functions to create classes to encapsulate the functionality I wanted (windows, buttons, etc).  But while I can understand easily how that works, it seems like we're now in a totally different world when it comes to creating a similar experience that is truly cross-platform with our current operating systems.  I would appreciate any enlightenment! ;)

Mark D.

Walter Bright wrote:
> "Kyle Furlong" <kylefurlong@gmail.com> wrote in message news:ds0m2i$sus$1@digitaldaemon.com...
>> As long as we are critiquing DWT...
>>
>> 1. No Ares support
>> 2. Java-like coding style = YUCK!
>>
>> But as we all know it is a very useful tool, so maybe the PRACTICAL thing is to support it officially.
> 
> Personally, I don't like the java coding style either. But think of it like strapping a rocket engine on a chicken, once we get that sucker off the ground, we can build ourselves a nicer set of wings <g>. 

I'm really enjoying these chicken analogies.  Someone needs to create a D logo that has a picture of a chicken strapped to a rocket ;-)


Sean

"Sean Kelly" <sean@f4.ca> wrote...
> I'm really enjoying these chicken analogies.  Someone needs to create a D logo that has a picture of a chicken strapped to a rocket ;-)


Be careful about that, Sean ...

You might end up with some group of religious fanatics/fundamentalists/ideologists/terrorists trying to kill you for expressing a right to free-speech. Chickens are not to be illustrated! Dammit!

(I'll probably get threats from the same kind & gentle people for noting the above)

"Mark D" <theomnipotentqatmsn@msn.com> wrote in message news:ds0si9$11bk$1@digitaldaemon.com...
>> Take a look: all toolkits have classes like
>> Graphics with acompanying Font, Image and other drawing primitivies.
>> Can we make them as some standard package? Sure, I would say we must to.
>> Another candidate for standard library are Rect, Point, Polygon -
>> geometric primitives.
>
> I definitely would like to see something like this... but in the back of my head - with my limited knowledge - I'm wondering how exactly something like this would work.  For example, presumably we are drawing all of these things in a window, right?  So that sort of implies that even a default, simple and "primitive" graphics functionality also involves a standard cross-platform syntax to create and manipulate a window.  So what properties does a window need?  And I would guess that this is the point where things start to snowball out of control with issues like resolution, modality, fullscreen support, color depth, etc.

The approach I was taking with MinWin was to make the native type available (and encouraged) for direct manipulation. That's why it was very important to have as minimal a layer as possible between the MinWin D code and the underlying OS types and routines. One should be able to easily take a MinWin window (or graphics or whatever) and do to it whatever the native system supports (within reason). Most cross-platform GUI toolkits try as hard as possible to hide the implementation details (as OOP methodology traditionally encourages) but I think for GUI toolkits that just results in a frustratingly limited toolkit. For example there should be no extra state stored in the D objects so that there's no risk of getting the D view of the widget out of sync with the OS view.


> I remember fondly working with Borland's flavor of C++ in DOS, and using those most basic of functions to create classes to encapsulate the functionality I wanted (windows, buttons, etc).  But while I can understand easily how that works, it seems like we're now in a totally different world when it comes to creating a similar experience that is truly cross-platform with our current operating systems.  I would appreciate any enlightenment! ;)
>
> Mark D.

Thanks, Walter, see below:

"Walter Bright" <newshound@digitalmars.com> wrote in message news:ds0run$110u$1@digitaldaemon.com...
> You've made some very good points, and I want to address them.
>
> 1) Yes, there are the two major approaches to a gui toolkit, good for different purposes. But right now, the important thing is that we have one, not which approach it is. As D grows, then other guis with the other approaches will naturally become available. Picking DWT now does not shut the door on those others, all it does is get enough momentum and focus to get one *done*. It's the chicken and egg problem here, people won't use D because it has no gui, people won't develop guis because there's no people using D. Even if it's not the perfect chicken, we need a chicken to start our farm <g>. Once our farm is going, then we can buy some better chickens and add them in.

Well, of course you can assign name "DWT, official toolkit". If it will help then why not?

>
> 2) I agree that it would be better to use delegates and other cool D features to do a better gui design than SWT. I discussed this at length with Kris in email a while back, we both came to the conclusion that this is just not practical to do right now, because we don't have a large staff of minions paid to attack this problem. We have very limited resources, so it's all about leverage. We need a chicken to bootstrap the process, and the fastest way to get one is to forget about redesigning SWT, but to just translate it as is.

Again if it will help....

>
> 3) DWT doesn't need to track changes in SWT once DWT is built. If it forks from SWT, that's OK, because then we'll have our chicken, and so we'll have eggs, then more chickens, etc.

As I said: the egg is strong, simple and effective D-ish Graphical package
wrapping HDC stuff. Chickens and other animals will be born from it.
IMHO of course.

>
> 4) You're right in that automated translation from Java to a D program isn't going to work 100%, 90%, or even 80%. If it works 75%, with 25% manual fiddling, that's still a big leg up. The percentage for C++ would be a lot lower, especially if the C++ code uses STL or Boost, where it won't work at all. I tend to write C++ code that would easilly convert to D, but very little of what I run across otherwise would.

Forget about STL and boost. There is no practical GUI  toolkit in the wild using them anyway.  (This fact speaks for itself)

Andrew Fedoniouk.
http://terrainformatica.com