was: [GSoC] Container proposals by Ishan and Christian

To preventing losing this thread, I have created a new one ...
Additional, I've added a license column on the GuiLibraries-table on the wiki.

So, let me summarize my thoughts, why I think a good Gui library is important for the D community.
I'm working for an enginge builder company. Our product is mainly mechanical, but also has a software part, which is created and maintained by a 16 (and growing) man team. Our softwareproduct is mainly server-side and timecritical, written in C++/MFC and very old. We've decided to create it new from scratch. As a member of the design team of this new project I've tried to inturoduce D for this. But it was impossible to assure the others. The main counter-argument was the lack of a good D-Gui library, though the main part is serverside, but the client-side GUI have to be written in the same language.

This were the requirments for the GUI library:
- Corss-platform (Win/linux)
- not just a port, but adjusted to the language
- mostly written in this language, so you can easy debug the lib,
  this means no wrapper library, just system libraries
  (Though gtk+ on linux would hold as a system library so GtkD for linux would be OK, but not on Windows!
- obviously suitable license for a commercial product

Unfortunately All known GUI-libraries for D fails on this requirments
So the choice has fallen to C++/Qt

I would like to fill this gap and create a really good D GUI library

Any thoughts, comments ... ?


°Matthias

Am 04.04.2011 23:27, schrieb Matthias Pleh:
> was: [GSoC] Container proposals by Ishan and Christian
> 
> To preventing losing this thread, I have created a new one ... Additional, I've added a license column on the GuiLibraries-table on the wiki.
> 
> So, let me summarize my thoughts, why I think a good Gui library is
> important for the D community.
> I'm working for an enginge builder company. Our product is mainly
> mechanical, but also has a software part, which is created and
> maintained by a 16 (and growing) man team. Our softwareproduct is mainly
> server-side and timecritical, written in C++/MFC and very old. We've
> decided to create it new from scratch. As a member of the design team of
> this new project I've tried to inturoduce D for this. But it was
> impossible to assure the others. The main counter-argument was the lack
> of a good D-Gui library, though the main part is serverside, but the
> client-side GUI have to be written in the same language.
> 
> This were the requirments for the GUI library:
> - Corss-platform (Win/linux)

Don't forget Mac OSX.
Also note that on Linux there are two widely used toolkits, GTK and Qt,
and that QT is better in emulating GTK than the other way round (you can
let GTK use the current QT theme or something, but it'll still use the
GTK filepicker etc. QT's GTK emulation is better and uses the real GTK
filepicker).

> - not just a port, but adjusted to the language
> - mostly written in this language, so you can easy debug the lib,
>   this means no wrapper library, just system libraries
>   (Though gtk+ on linux would hold as a system library so GtkD for linux
> would be OK, but not on Windows!
> - obviously suitable license for a commercial product
> 
> Unfortunately All known GUI-libraries for D fails on this requirments So the choice has fallen to C++/Qt
> 
> I would like to fill this gap and create a really good D GUI library
> 
> Any thoughts, comments ... ?
> 
> 
> °Matthias

I don't know if wee need yet another GUI library.
Are you sure Qt and DWT aren't good enough?

Cheers,
- Daniel

Am 04.04.2011 23:34, schrieb Daniel Gibson:
> Am 04.04.2011 23:27, schrieb Matthias Pleh:
>> was: [GSoC] Container proposals by Ishan and Christian
>>
[snip]
>>
>> This were the requirments for the GUI library:
>> - Corss-platform (Win/linux)
>
> Don't forget Mac OSX.
I just listed the requirments in our company, but you're rigth. We must support at least the three main platforms Win/linux/OSX

> Also note that on Linux there are two widely used toolkits, GTK and Qt,
> and that QT is better in emulating GTK than the other way round (you can
> let GTK use the current QT theme or something, but it'll still use the
> GTK filepicker etc. QT's GTK emulation is better and uses the real GTK
> filepicker).
that's true

>
[snip]
>
> I don't know if wee need yet another GUI library.
I have not said, that it must be create a completly new library.
We just have to find out, what are the requirments for the D community, and how can we achieve that.
Whe have mainly 4 options:
- support an existing project and help to meet our requirments
- fork an existing project and advance it to our requirments
- port a library from another language and advance it, to meet better
  the D coding style
- create a new library (which also can be based on a older abandoned
  project)

> Are you sure Qt and DWT aren't good enough?
As I mentioned in my post, I couldn't assure the others. Not every decision-maker base his decisions on pure technical arguments, sometimes it's just his gut feeling or the cleaning lady's advice, who knows :)

°Matthias

Am 04.04.2011 23:51, schrieb Matthias Pleh:
> Am 04.04.2011 23:34, schrieb Daniel Gibson:
>> Am 04.04.2011 23:27, schrieb Matthias Pleh:
>>> was: [GSoC] Container proposals by Ishan and Christian
>>>
> [snip]
>>>
>>> This were the requirments for the GUI library:
>>> - Corss-platform (Win/linux)
>>
>> Don't forget Mac OSX.
> I just listed the requirments in our company, but you're rigth. We must support at least the three main platforms Win/linux/OSX
> 
>> Also note that on Linux there are two widely used toolkits, GTK and Qt, and that QT is better in emulating GTK than the other way round (you can let GTK use the current QT theme or something, but it'll still use the GTK filepicker etc. QT's GTK emulation is better and uses the real GTK filepicker).
> that's true
> 
>>
> [snip]
>>
>> I don't know if wee need yet another GUI library.
> I have not said, that it must be create a completly new library.
> We just have to find out, what are the requirments for the D community,
> and how can we achieve that.
> Whe have mainly 4 options:
> - support an existing project and help to meet our requirments
> - fork an existing project and advance it to our requirments
> - port a library from another language and advance it, to meet better
>   the D coding style
> - create a new library (which also can be based on a older abandoned
>   project)
> 
>> Are you sure Qt and DWT aren't good enough?
> As I mentioned in my post, I couldn't assure the others. Not every decision-maker base his decisions on pure technical arguments, sometimes it's just his gut feeling or the cleaning lady's advice, who knows :)
> 
> °Matthias

Maybe your company could help the DWT or QtD guys?
Getting something stable out of that would most probably not take as
long as developing your own cross-platform GUI toolkit.
Furthermore many people are already familiar with SWT and Qt, so they
wouldn't have to learn another toolkit for D.

Cheers,
- Daniel

El 04/04/2011 23:51, Matthias Pleh escribió:
> Am 04.04.2011 23:34, schrieb Daniel Gibson:
>> Am 04.04.2011 23:27, schrieb Matthias Pleh:
>>> was: [GSoC] Container proposals by Ishan and Christian
>>>
> [snip]
>>>
>>> This were the requirments for the GUI library:
>>> - Corss-platform (Win/linux)
>>
>> Don't forget Mac OSX.
> I just listed the requirments in our company, but you're rigth. We must
> support at least the three main platforms Win/linux/OSX
>
>> Also note that on Linux there are two widely used toolkits, GTK and Qt,
>> and that QT is better in emulating GTK than the other way round (you can
>> let GTK use the current QT theme or something, but it'll still use the
>> GTK filepicker etc. QT's GTK emulation is better and uses the real GTK
>> filepicker).
> that's true
>
>>
> [snip]
>>
>> I don't know if wee need yet another GUI library.
> I have not said, that it must be create a completly new library.
> We just have to find out, what are the requirments for the D community,
> and how can we achieve that.
> Whe have mainly 4 options:
> - support an existing project and help to meet our requirments
> - fork an existing project and advance it to our requirments
> - port a library from another language and advance it, to meet better
> the D coding style
> - create a new library (which also can be based on a older abandoned
> project)
>
>> Are you sure Qt and DWT aren't good enough?
> As I mentioned in my post, I couldn't assure the others. Not every
> decision-maker base his decisions on pure technical arguments, sometimes
> it's just his gut feeling or the cleaning lady's advice, who knows :)
>
> °Matthias

Why do you say "it must be a completely new library"? Why don't the existing ones fit?

I last week tried gtkD, both on Linux and Windows. Quite nice, only I don't really like how it looks on Windows, that it can't use the native controls. And then there is QtD and wxD (from wxWidgets) both using native controls.

Anyway I think I know what you mean by "the D coding style". All those are direct ports/bindings that retain their original style and don't really take advantage of D's facilities.

For instance, in gtkD (QtD probably too, haven't looked at it), classes have classic functions for accessing and modifying "properties", like window.setTitle("Find"); w=window.getWidth(). But D provides real @properties. That could be improved to window.title = "Find"; w=window.width; Etc, etc.

The use of properties, delegates for event handlers, D's Unicode strings, etc. could certainly be improved in libs like those. But anyway they have done a great job in providing D with working GUI APIs.

Am 05.04.2011 00:14, schrieb Daniel Gibson:
> Maybe your company could help the DWT or QtD guys?
> Getting something stable out of that would most probably not take as
> long as developing your own cross-platform GUI toolkit.
> Furthermore many people are already familiar with SWT and Qt, so they
> wouldn't have to learn another toolkit for D.

You have missed the point. For our company the decision is made. We already use C++/Qt now.
But I really like the D programming language and I use it for all my private projects. So I think, we, as the D community, should create a modern D GUI library entirely written in D.

Am 05.04.2011 00:35, schrieb Alvaro:
> El 04/04/2011 23:51, Matthias Pleh escribió:
>> Am 04.04.2011 23:34, schrieb Daniel Gibson:
>>> Am 04.04.2011 23:27, schrieb Matthias Pleh:
>>>> was: [GSoC] Container proposals by Ishan and Christian
>>>>
>> [snip]
>>>>
>>>> This were the requirments for the GUI library:
>>>> - Corss-platform (Win/linux)
>>>
>>> Don't forget Mac OSX.
>> I just listed the requirments in our company, but you're rigth. We must
>> support at least the three main platforms Win/linux/OSX
>>
>>> Also note that on Linux there are two widely used toolkits, GTK and Qt,
>>> and that QT is better in emulating GTK than the other way round (you can
>>> let GTK use the current QT theme or something, but it'll still use the
>>> GTK filepicker etc. QT's GTK emulation is better and uses the real GTK
>>> filepicker).
>> that's true
>>
>>>
>> [snip]
>>>
>>> I don't know if wee need yet another GUI library.
>> I have not said, that it must be create a completly new library.
>> We just have to find out, what are the requirments for the D community,
>> and how can we achieve that.
>> Whe have mainly 4 options:
>> - support an existing project and help to meet our requirments
>> - fork an existing project and advance it to our requirments
>> - port a library from another language and advance it, to meet better
>> the D coding style
>> - create a new library (which also can be based on a older abandoned
>> project)
>>
>>> Are you sure Qt and DWT aren't good enough?
>> As I mentioned in my post, I couldn't assure the others. Not every
>> decision-maker base his decisions on pure technical arguments, sometimes
>> it's just his gut feeling or the cleaning lady's advice, who knows :)
>>
>> °Matthias
>
> Why do you say "it must be a completely new library"? Why don't the
> existing ones fit?
No, see above, supporting an existing library would also fit.

>
> I last week tried gtkD, both on Linux and Windows. Quite nice, only I
> don't really like how it looks on Windows, that it can't use the native
> controls. And then there is QtD and wxD (from wxWidgets) both using
> native controls.
>
> Anyway I think I know what you mean by "the D coding style". All those
> are direct ports/bindings that retain their original style and don't
> really take advantage of D's facilities.
Yes exactly. The argument by others was, that a community which is not able to create their own library, coded in their own style, will not survive.

>
> For instance, in gtkD (QtD probably too, haven't looked at it), classes
> have classic functions for accessing and modifying "properties", like
> window.setTitle("Find"); w=window.getWidth(). But D provides real
> @properties. That could be improved to window.title = "Find";
> w=window.width; Etc, etc.
>
> The use of properties, delegates for event handlers, D's Unicode
> strings, etc. could certainly be improved in libs like those. But anyway
> they have done a great job in providing D with working GUI APIs.

Don't get me wrong. GtkD perfectly meets my personal taste and I would have used this library for our project. But others are more cautios and have really strong requirments for such a projects (Note, this is one big project with much more than 500.000 LOC), so we _already_ have choosen C++/Qt !!

I think other companies will have similar decision. So, I think, to help D to get more accepted in the buisiness world, one requirement would be a good GUI library.

°Matthias

On 2011-04-04 15:41, Matthias Pleh wrote:
> Am 05.04.2011 00:14, schrieb Daniel Gibson:
> > Maybe your company could help the DWT or QtD guys?
> > Getting something stable out of that would most probably not take as
> > long as developing your own cross-platform GUI toolkit.
> > Furthermore many people are already familiar with SWT and Qt, so they
> > wouldn't have to learn another toolkit for D.
> 
> You have missed the point. For our company the decision is made. We
> already use C++/Qt now.
> But I really like the D programming language and I use it for all my
> private projects. So I think, we, as the D community, should create a
> modern D GUI library entirely written in D.

Feel free to do that if you want, but I think that most people around here would agree that your time would be better spent improving the existing GUI toolkit bindings - such as qtd or dwt. A _lot_ of time and effort goes into making a truly solid and complete GUI toolkit. Why duplicate all of that work? There's just too much else that needs to be done for D. And even if we _want_ duplicate that work with a GUI toolkit which is completely written in D, you'd need a large team to develop it properly. And given the general difficulties in getting contributors for the various major D projects, I rather doubt that you're going to manage that.

So, do whatever you want, but I really don't think that developing a new GUI toolkit for D is really the best use of your time. There's plenty of other stuff that needs doing which would be of greater value.

- Jonathan M Davis

I've been slowly writing one of my own too. Used it to write one real app, but that's all so far, and I only add functions as I need them, so it's pretty minimal.

What I did to get a faster start is to tie it into Qt, with an
escape valve into qt if needed (also let me use Qt Designer!)
 while having some D niceties like property syntax, connecting signals
 to anonymous delegates, etc.

(For this app, I tried QtD first, but it kept crashing on Windows, and I didn't have time to spare to fix it myself. Besides, qtd is a huge set of libraries to distribute. Qt is big enough already, didn't want to double the download by including qtd too.)


An approach like this might be good for your project too.

Oops, forgot to tell what the approach actually was!

The Qt part is written in C++ and compiled into a dll. The D part links to this and passes messages to it across a series of extern(c) functions.

Some messages are pretty high level and others are low level - whatever I needed to get the app working with a minimal of C++.