Ilya Minkov wrote:
> LiuXuHong schrieb:
> 
>> I think FOX (Free Object for X : http://www.fox-toolkit.com/) is an excellent
>> cross-platform GUI frameworks. Does anyone has interests to port it to D ?
> 
> 
> I am not very convinced of the sense of this port, because:
> 
> * It is an emulated GUI framework, and as such it is somewhat alien on every system.

What do you mean with "emulated GUI framework"? What would it be emulating? And why would it lead us to wrappers around GTK etc?

"Porting FOX" means rewriting it in D. I think DUI is very valuable right now, but don't we all want a GUI written in D in the end?

The problem I see with blindly porting a C++ design to D is that the power of D might not be fully utilised; C++isms may slip in because it takes effort to think in D when you are reading C++. When there is going to be a D GUI, I would like it to be a pearl of D code. Designing from the ground up would be good, but it is nice to have a couple of examples laying around like FOX, Qt, etc. FOX has the advantage that we can see the low-level calls on the Windows side as well, unlike Qt.

Bastiaan.

Bastiaan Veelo schrieb:

> What do you mean with "emulated GUI framework"? What would it be emulating? And why would it lead us to wrappers around GTK etc?

"Emulated" in the sense of that it draws its own widgets, instead of using the ones provided by the operating system (if the operating system provides them at all). wxWidgets is just about the only usable free C++ native GUI library for all common platforms.

> "Porting FOX" means rewriting it in D. I think DUI is very valuable right now, but don't we all want a GUI written in D in the end?

Perhaps you are right. And if you think FOX is the best basis for such a GUI you are free to take on the job...

Besides, what would be the ground advantage of a GUI written completely in D? Ability to subclass the widgets? A well-designed wrapper may very well allow that. And to what end "completely"? Do OS calls also have to be done from D or may they be incapsulated into a C library for portability and for the cases where calling the OS directly from D may be problematic, say, under MacOS X?

I'm sort-of taking back that praising of DUI - GTK is so heavyweight that it is only usable for foreground software on Windows. If writing a new GUI library, it should be taken into account to try and make it lightweight.

> The problem I see with blindly porting a C++ design to D is that the power of D might not be fully utilised; C++isms may slip in because it takes effort to think in D when you are reading C++. When there is going to be a D GUI, I would like it to be a pearl of D code. Designing from the ground up would be good, but it is nice to have a couple of examples laying around like FOX, Qt, etc. FOX has the advantage that we can see the low-level calls on the Windows side as well, unlike Qt.

There is a number of things which affect library design which need reconsideration when porting into D, including message passing and the use of properties. The second is trivial, the first one was already solved by Andy Friesen, IIRC. I cannot think out anything else (which affects design, not implementation), which needs to be changed, but i'm almost sure i'm missing something out. I'm sure it's possible to make a good rewrite, especially because C++ is not very similar to D conceptually.

There is a very nice workgroup, which currently writes a GUI in D, which aims to be very D-licious and portable to different platforms in the end. They have chosen IBM SWT (a Java toolkit used by Eclipse) as their model. It is apparently in a very early phase.

http://www.dsource.org/projects/dwt/

-eye

Ilya Minkov wrote:
> Bastiaan Veelo schrieb:
> 
>> What do you mean with "emulated GUI framework"? What would it be emulating? And why would it lead us to wrappers around GTK etc?
> 
> "Emulated" in the sense of that it draws its own widgets, instead of using the ones provided by the operating system (if the operating system provides them at all). wxWidgets is just about the only usable free C++ native GUI library for all common platforms.

Seems to me that wxWidgets is a wrapper itself around e.g. Motif, Gtk+ and whatever it is that runs on Windows. There is a universal port, wxUniversal (http://www.wxwidgets.org/wxuniv.htm), that seems to take the same approach as FOX does, or "emulating" in your words. Note that if theming is going to be supported (a popular feature of KDE, for example) the library will have to draw its own widgets.

[...]

> Besides, what would be the ground advantage of a GUI written completely in D? Ability to subclass the widgets? A well-designed wrapper may very well allow that. And to what end "completely"? Do OS calls also have to be done from D or may they be incapsulated into a C library for portability and for the cases where calling the OS directly from D may be problematic, say, under MacOS X?

I don't have figures to back me, but I am concerned about the cost of wrapping, in run-time performance, executable size and library dependencies. We should not forget devices with limited resources. Regarding to where to draw the line of "completely", it will help looking at libraries that went before us, like Qt, FOX and probably wxUniversal.

> I'm sort-of taking back that praising of DUI - GTK is so heavyweight that it is only usable for foreground software on Windows. If writing a new GUI library, it should be taken into account to try and make it lightweight.

Exactly my point :-)

[...]
> There is a number of things which affect library design which need reconsideration when porting into D, including message passing and the use of properties. The second is trivial, the first one was already solved by Andy Friesen, IIRC. I cannot think out anything else (which affects design, not implementation), which needs to be changed, but i'm almost sure i'm missing something out. I'm sure it's possible to make a good rewrite, especially because C++ is not very similar to D conceptually.

I've looked a bit into message passing myself, Andy's Listener template is a nice tutorial. I have extended that idea more into the direction of libsigc++ (at least I think I have) with dcouple (http://svn.dsource.org/svn/projects/dcouple/trunk/managed/doc/index.html) so that connections may be broken at both the sending and receiving end, in support of objects that come and go. It has become a bit hackish to deal with the non-deterministic finalisation of D though (hackish for me, not the user). The feature of "`struct'ized" objects (see
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/11976 and earlier posts in the same thread), which I hope will be supported in the future D, will make this a lot cleaner.

I don't think properties are trivial. A good GUI designer will need a way to infer what properties a dynamically loaded widget has and what values are valid. AFAIK we need a pre-processor for that or better RTTI than we have now. Luckily, we have been promised better RTTI.

Another question I have is whether D's native strings are powerful enough to support translations well. It would be nice if a D GUI library would not have to extend D's strings, unlike all C++ libs. Is there anybody who knows QString and QtLinguist with a view on this?

> There is a very nice workgroup, which currently writes a GUI in D, which aims to be very D-licious and portable to different platforms in the end. They have chosen IBM SWT (a Java toolkit used by Eclipse) as their model. It is apparently in a very early phase.
> 
> http://www.dsource.org/projects/dwt/

I should check that out some time.

Regards,
Bastiaan.

Bastiaan Veelo schrieb:

> Seems to me that wxWidgets is a wrapper itself around e.g. Motif, Gtk+ and whatever it is that runs on Windows. There is a universal port, wxUniversal (http://www.wxwidgets.org/wxuniv.htm), that seems to take the same approach as FOX does, or "emulating" in your words. Note that if theming is going to be supported (a popular feature of KDE, for example) the library will have to draw its own widgets.

Naturally, wxWidgets *is* a Wrapper.

Theming, as in application-wide theming or OS-wide theming? On Windows and OS-X, wxWidgets applications inherit the system-wide theme automatically and without any extra code for the OS-standard widgets. On GTK systems, they inherit the GTK theme the same way. There exists a Metatheme for GTK which inherits the QT theme, so on Unixoid system a wxWidgets or GTK application can more-or-less match the whole OS look.

I'm all for OS-wide theming, just because i think people sometimes need a rest from one particular look and switch to another. Now i feel better when applications have rounded buttons, a few years ago i preferred exactly rectangular ones. Color preferance also changes. System-wide theming is a great advantage. About application wide-theming... I'm not sure it is so valuable. It usually makes sense for small proggies like indicators, players, etc, but they usually have a different GUI concept and that's not necessarily what a mainstream GUI need to directly provide. However, when a normal and "serious" applictaion tries to redefine the look... i find it just irritating.

> I don't have figures to back me, but I am concerned about the cost of wrapping, in run-time performance, executable size and library dependencies. We should not forget devices with limited resources. Regarding to where to draw the line of "completely", it will help looking at libraries that went before us, like Qt, FOX and probably wxUniversal.

The wxWidgets complete DLL for Python is about 10 megabytes in size. WxWidgets applications in C++ usually turn out to be about half megabyte  to two megabytes in size on Win32 - which is roughly the same order of magnitude like VCL and MFC applications so usual under Windows. I would believe it adds even less on GTK systems. I have a strong belief that wrapping it twice for D would increase the size by not more than a half. I'm sure one can leave classes not in use unreferenced, thus there won't be excess bloat. And as for performance conserns... lots of time gets lost somewhere in the back-ends, so unless something is principally wrong in the front-end, it shouldn't matter. Destruction bothers me somewhat though - i shall see how wx.NET has solved that.

> I don't think properties are trivial. A good GUI designer will need a way to infer what properties a dynamically loaded widget has and what values are valid. AFAIK we need a pre-processor for that or better RTTI than we have now. Luckily, we have been promised better RTTI.

Argh, yuck. If you are speaking of the "published" properties for a GUI designer, D files simply don't provide enough specification, because not all public properties also have to be published, and it should be possible to "publish" a field as a property as well. What can make sense, is a sort-of additional specification alongside the D program. Then there are 2 possibilities. First is complete specification, where for each class properties are listed with name and type. The generator reads this specification and "blindly" generates a module to access all of these properties. This module should be done so that the compiler would bark if a type mismatch happens. The second possibility is an abridged specification, which doesn't contain property types, so the tool ust also parse the source and figure out from that.

I think we also need a specialised documentation tool, tailored to the features of D, and featuring a sort of easily readable mark-up like reStructuredText, extended for property specification. As soon as i have some time i (finally) make a D version of COCO/R and then translate partial D grammar made by someone for ANTLR. On that basis, such a tool can be built.

> Another question I have is whether D's native strings are powerful enough to support translations well. It would be nice if a D GUI library would not have to extend D's strings, unlike all C++ libs. Is there anybody who knows QString and QtLinguist with a view on this?

I don't know about QtLinguist, but for gettext-like translation engine, everything is powerful enough.

>> http://www.dsource.org/projects/dwt/
> 
> I should check that out some time.

ATM Windows-only and a wrapper GUI.

-eye

Ilya Minkov wrote:

[...]
> Theming, as in application-wide theming or OS-wide theming? On Windows and OS-X, wxWidgets applications inherit the system-wide theme automatically and without any extra code for the OS-standard widgets. On GTK systems, they inherit the GTK theme the same way. There exists a Metatheme for GTK which inherits the QT theme, so on Unixoid system a wxWidgets or GTK application can more-or-less match the whole OS look.

I did not know that. Nice.

> I think we also need a specialised documentation tool, tailored to the features of D, and featuring a sort of easily readable mark-up like reStructuredText, extended for property specification. As soon as i have some time i (finally) make a D version of COCO/R and then translate partial D grammar made by someone for ANTLR. On that basis, such a tool can be built.

A good documentation tool will be very valuable in every respect. I wish you time :-)

Bastiaan.

In article <cmnfd7$2ent$1@digitaldaemon.com>, Bastiaan Veelo says...

<snip...>

>
>> There is a very nice workgroup, which currently writes a GUI in D, which aims to be very D-licious and portable to different platforms in the end. They have chosen IBM SWT (a Java toolkit used by Eclipse) as their model. It is apparently in a very early phase.
>> 
>> http://www.dsource.org/projects/dwt/
>
>I should check that out some time.
>
>Regards,
>Bastiaan.

Please do check it out.  And if you have any time or energy to work on it, that would be most appreciated.  A great amount of DWT has been completed already... but some basic things like the event system still needs to be tinkered with before it will work.  Also, the structure of DWT still causes the dmd compiler to choke in somwhere (dmd goes into an "infinite" loop -- ie until it runs out of memory and crashes).  Tracing the problem has been very difficult.

Later,

John R.

In article <cmnl2e$2ogn$1@digitaldaemon.com>, Ilya Minkov says...

<snip>

>
>>> http://www.dsource.org/projects/dwt/
>> 
>> I should check that out some time.
>
>ATM Windows-only and a wrapper GUI.
>
>-eye

There are the beginnings of the GTK port in there also.  Some GTK bindings should be in one of the source directories. But, yes, the linux port is barely started.

I think you all might as well take a long, hard look at the truth:  D has no
future.  There once was a
language quite similar to D that had all the features one could ask for.  It
seemed like the perfect
sytems and application programming language -- high level with the ability to go
low level when
necessary.  Oh, it had garbage collection, generics, design by committe... you
name it.  That language
was called Modula 3.  It is now dead.  D aims for the exact same space as Modula
3, that is to say, D
aims to hide in one of the many crevices of computer history.  It's sad, really,
to see such hard work all
for naught.  You all might as well just give up now and start using C#.

Yours truly,
A Wise Friend

A Wise Troll wrote:

> That language was called Modula 3. It is now dead.
[...]
> You all might as well just give up now and start using C#.

In case anyone else has to look it up, "Modula 3" is
a Pascal-like language with a weird UPPERCASE syntax:

http://www.m3.org/

Seems to be open source these days:
http://www.elegosoft.com/cm3/

--anders

Hi Mr Gates,

Thanks for your post.  From now on I will listen only to microsoft, use only microsoft products, and will devote my life to the MS corportation.  My life is yours.


There is always naysayers.  A month before we put a man on the moon everyone said it couldn't be done.  Everyone thought the world was flat in 1480.  We thought the earth was the center of our universe before gailelo corrected us , and then got persecuted for it.

I really feel sorry for you , you'll never know what passion / love /  obsession is about.

Find something you love, and do everything you can for it.  Everything else is just filler.

Charlie


In article <cmrfgl$276n$1@digitaldaemon.com>, wisefriend@hotmail.cx says...
>
>I think you all might as well take a long, hard look at the truth:  D has no
>future.  There once was a
>language quite similar to D that had all the features one could ask for.  It
>seemed like the perfect
>sytems and application programming language -- high level with the ability to go
>low level when
>necessary.  Oh, it had garbage collection, generics, design by committe... you
>name it.  That language
>was called Modula 3.  It is now dead.  D aims for the exact same space as Modula
>3, that is to say, D
>aims to hide in one of the many crevices of computer history.  It's sad, really,
>to see such hard work all
>for naught.  You all might as well just give up now and start using C#.
>
>Yours truly,
>A Wise Friend
>
>