October 12, 2009
Yigal Chripun wrote:
> On 12/10/2009 07:33, Jeremie Pelletier wrote:
>> Jérôme M. Berger wrote:
>>> Jeremie Pelletier wrote:
>>>> I agree however that GTK being in C is rather annoying, C is a great
>>>> language but GUIs is one area where OOP really shines.
>>>
>>> Note that Gtk *is* object oriented despite being in C...
>>>
>>> Jerome
>>
>> It's a sorry hack, you have to use casts everywhere you'd rely on
>> polymorphism in D or C+ and its harder to remember, read, code,
>> maintain, and doesn't have any performance gains over C++, the explicit
>> struct pointer in C is the implicit 'this' in C++ and non-virtual
>> methods can be optimized as direct calls with no vtbl indirections.
>>
>> I tried gtkD and I don't like using an OOP layer on top of a C interface
>> because that adds overhead for the exact same features, most good GUI
>> libraries should abstract the platform anyways so GTK is usually only
>> seen there and not in user code.
>>
>> It's still more fun to use than the Windows' windowing API, which
>> doesn't even support layout objects such as boxes and grids, now that's
>> total pain!
> 
> what about MS' WPF? It has all the bells and whistles of modern UI, doesn't it?

Isn't that just a pretty layer on top of win32/com? I now only use native toolkits as backends for my gui abstraction layer, using this would only add a level of indirection and make no sense.
October 12, 2009
On Mon, 12 Oct 2009 19:18:41 +0400, Jeremie Pelletier <jeremiep@gmail.com> wrote:

> Yigal Chripun wrote:
>> On 12/10/2009 07:33, Jeremie Pelletier wrote:
>>> Jérôme M. Berger wrote:
>>>> Jeremie Pelletier wrote:
>>>>> I agree however that GTK being in C is rather annoying, C is a great
>>>>> language but GUIs is one area where OOP really shines.
>>>>
>>>> Note that Gtk *is* object oriented despite being in C...
>>>>
>>>> Jerome
>>>
>>> It's a sorry hack, you have to use casts everywhere you'd rely on
>>> polymorphism in D or C+ and its harder to remember, read, code,
>>> maintain, and doesn't have any performance gains over C++, the explicit
>>> struct pointer in C is the implicit 'this' in C++ and non-virtual
>>> methods can be optimized as direct calls with no vtbl indirections.
>>>
>>> I tried gtkD and I don't like using an OOP layer on top of a C interface
>>> because that adds overhead for the exact same features, most good GUI
>>> libraries should abstract the platform anyways so GTK is usually only
>>> seen there and not in user code.
>>>
>>> It's still more fun to use than the Windows' windowing API, which
>>> doesn't even support layout objects such as boxes and grids, now that's
>>> total pain!
>>  what about MS' WPF? It has all the bells and whistles of modern UI, doesn't it?
>
> Isn't that just a pretty layer on top of win32/com? I now only use native toolkits as backends for my gui abstraction layer, using this would only add a level of indirection and make no sense.

No, IIRC, it doesn't rely on Win32 API at all:

Wikipedia quote:
> Designed to remove dependencies on the aging GDI subsystem, WPF is built on DirectX, which provides hardware acceleration and enables modern UI features like transparency, gradients and transforms.
October 12, 2009
On Mon, 12 Oct 2009 12:58:56 +0400, language_fan <foo@bar.com.invalid> wrote:

> Sun, 11 Oct 2009 09:39:32 -0500, Ellery Newcomer thusly wrote:
>
>> Denis Koroskin wrote:
>>> On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
>>> <newshound1@digitalmars.com> wrote:
>>>
>>> If anyone is interested and is willing to test and/or help, I will
>>> gladly share my code.
>>
>> Oooo.. You should put that on dsource or somewhere. Hacking D sounds
>> like a lot more fun than hacking C++. I wouldn't mind helping out on
>> this one.
>
> Wow, I am pretty sure I have already seen a D port of dmd on dsource. Was
> there a good reason to start yet another port of it?

I know about DParser, but it's somewhat outdated, incomplete and doesn't support code generation. It also diverged from DMD quite a lot so fixing it would be quite hard (I, too, plan to make it more D-ish - get rid of casts, replace void* "Array"s with type-safe equivalents etc - but not until it is 100% ready).

I just believe rewriting it from scratch will be plain faster. I can also test the code much easier - if it produces exact same binary then it works correct.
October 12, 2009
Denis Koroskin wrote:
> On Mon, 12 Oct 2009 19:18:41 +0400, Jeremie Pelletier <jeremiep@gmail.com> wrote:
> 
>> Yigal Chripun wrote:
>>> On 12/10/2009 07:33, Jeremie Pelletier wrote:
>>>> Jérôme M. Berger wrote:
>>>>> Jeremie Pelletier wrote:
>>>>>> I agree however that GTK being in C is rather annoying, C is a great
>>>>>> language but GUIs is one area where OOP really shines.
>>>>>
>>>>> Note that Gtk *is* object oriented despite being in C...
>>>>>
>>>>> Jerome
>>>>
>>>> It's a sorry hack, you have to use casts everywhere you'd rely on
>>>> polymorphism in D or C+ and its harder to remember, read, code,
>>>> maintain, and doesn't have any performance gains over C++, the explicit
>>>> struct pointer in C is the implicit 'this' in C++ and non-virtual
>>>> methods can be optimized as direct calls with no vtbl indirections.
>>>>
>>>> I tried gtkD and I don't like using an OOP layer on top of a C interface
>>>> because that adds overhead for the exact same features, most good GUI
>>>> libraries should abstract the platform anyways so GTK is usually only
>>>> seen there and not in user code.
>>>>
>>>> It's still more fun to use than the Windows' windowing API, which
>>>> doesn't even support layout objects such as boxes and grids, now that's
>>>> total pain!
>>>  what about MS' WPF? It has all the bells and whistles of modern UI, doesn't it?
>>
>> Isn't that just a pretty layer on top of win32/com? I now only use native toolkits as backends for my gui abstraction layer, using this would only add a level of indirection and make no sense.
> 
> No, IIRC, it doesn't rely on Win32 API at all:
> 
> Wikipedia quote:
>> Designed to remove dependencies on the aging GDI subsystem, WPF is built on DirectX, which provides hardware acceleration and enables modern UI features like transparency, gradients and transforms.

Oh, I need to look into that!
October 12, 2009
On 10/12/09 14:11, language_fan wrote:
> Mon, 12 Oct 2009 14:02:11 +0200, Jacob Carlborg thusly wrote:
>
>> On 10/12/09 04:14, Chad J wrote:
>>> Too bad we can't just make programs switch between GUI backends at will
>>> ;)
>>
>> Why not have a GUI toolkit available on almost all platforms that uses
>> native controls just like DWT?
>
> The list of native platforms SWT supports is this:
>
> Win32
>    WPF (under development)
> AIX, FreeBSD, Linux, HP-UX, Solaris:
>    Motif
>    GTK+
> Mac OS X:
>    Carbon
>    Cocoa
> QNX Photon
> Pocket PC
>
> As a FLTK2, Qt 3.x, Qt 4.x, Swing, and (forked) Harmonia user I fail to
> see how SWT is more native than the ones I develop for. All SWT
> applications look weird, unthemed, and have horrible usability issues in
> the file open/save dialogs. DWT brings another level of cruft above the
> "lightweight" SWT and performs badly.

As a said previously SWT is more native because it uses the native GUI library available on the current platform, for windows (before vista) win32, osx cocoa and on linux gtk. It doesn't decide how a button should look, it doesn't try do draw a button that is similar to the natives, it just call the native library to draw the button.

I don't know what you mean by "unthemed" but if you refer to that applications on windows don't get the winxp look you have the same problem if you create the application in c++ or c and uses win32. It's caused by an older dll is loaded as default and to get the winxp look you have to request it to load the newer dll with a manifest file. Welcome to dlls.

If you have problems with the open/save dialogs in SWT either you will have the same problem in other native applications because it uses the native dialogs or there's a bug in SWT.

DWT doesn't add any extra levels that SWT doesn't have. In fact it removes one, the jni wrappers. DWT is a complete port of SWT to D, with only native code.

October 12, 2009
On Mon, Oct 12, 2009 at 3:39 AM, Don <nospam@nospam.com> wrote:
>
> Are you talking about FF 3.5? It's a really poor product. Crashes all the time, has some terrible UI misfeatures. I'm really amazed they shipped it in that condition.
>

I will gladly join in on the FF3.5 bashing. What a piece. EXTREMELY unresponsive, uses 3-4 times as much memory as FF3, flash videos don't play without hiccuping every five seconds, and it would just go into infinite loops or something and become completely unresponsive. I actually downgraded to 3.0 and it was like a new browser again! :P
October 12, 2009
Mon, 12 Oct 2009 18:54:25 +0200, Jacob Carlborg thusly wrote:

> On 10/12/09 14:11, language_fan wrote:
>> Mon, 12 Oct 2009 14:02:11 +0200, Jacob Carlborg thusly wrote:
>>
>>> On 10/12/09 04:14, Chad J wrote:
>>>> Too bad we can't just make programs switch between GUI backends at will ;)
>>>
>>> Why not have a GUI toolkit available on almost all platforms that uses native controls just like DWT?
>>
>> The list of native platforms SWT supports is this:
>>
>> Win32
>>    WPF (under development)
>> AIX, FreeBSD, Linux, HP-UX, Solaris:
>>    Motif
>>    GTK+
>> Mac OS X:
>>    Carbon
>>    Cocoa
>> QNX Photon
>> Pocket PC
>>
>> As a FLTK2, Qt 3.x, Qt 4.x, Swing, and (forked) Harmonia user I fail to see how SWT is more native than the ones I develop for. All SWT applications look weird, unthemed, and have horrible usability issues in the file open/save dialogs. DWT brings another level of cruft above the "lightweight" SWT and performs badly.
> 
> As a said previously SWT is more native because it uses the native GUI library available on the current platform, for windows (before vista) win32, osx cocoa and on linux gtk. It doesn't decide how a button should look, it doesn't try do draw a button that is similar to the natives, it just call the native library to draw the button.

The problem is, 99% of win32 users use the win32 gui toolkit on win32, 99% of osx users use cocoa, but on Linux/BSD maybe about 40% use gtk+. It is not The native toolkit to use. I do not even have it installed on my system.

> I don't know what you mean by "unthemed" but if you refer to that applications on windows don't get the winxp look you have the same problem if you create the application in c++ or c and uses win32. It's caused by an older dll is loaded as default and to get the winxp look you have to request it to load the newer dll with a manifest file. Welcome to dlls.

I mostly work on *nixen. The unthemed means that I do not have *any* gtk+ libraries installed anywhere so it defaults to the ugly default theme. To me gtk+ does not have the native feel as I never see any application written in it. Like I said, I only use { FLTK2, Qt 3.x, Qt 4.x, Swing, and (forked) Harmonia}. I am sorry if you have trouble reading that. Whenever an application comes with its own (statically linked) gtk+ libs, it will look bad. I do not have any "control panel" to change the look and feel of the gtk+ applications.

> 
> If you have problems with the open/save dialogs in SWT either you will have the same problem in other native applications because it uses the native dialogs or there's a bug in SWT.

Look, this is what I get on Win32:

http://johnbokma.com/textpad/select-a-file-dialog.png

on Linux:

http://www.matusiak.eu/numerodix/blog/wp-content/uploads/20050710- kdefilechooser.png

on Java:

http://www.dil.univ-mrs.fr/~garreta/docJava/tutorial/figures/uiswing/ components/FileChooserOpenMetal.png

You can probably see something that I have started to call 'consistency'. Almost the same buttons and layouts on every platform. I immediately know how it works. The same design has been there since Windows 95, if I recall correctly. This is what many people have learned to live with.

Now every time I see a gtk+/swt/dwt application I wonder where the heck that unintuitive terrible piece of cr*p came:

http://book.javanb.com/swt-the-standard-widget-toolkit/images/0321256638/ graphics/14fig03.gif

Native? It might very well use native binaries on my platform, but the native feel ends there.
October 12, 2009
language_fan wrote:
> Mon, 12 Oct 2009 18:54:25 +0200, Jacob Carlborg thusly wrote:
> 
>> On 10/12/09 14:11, language_fan wrote:
>>> Mon, 12 Oct 2009 14:02:11 +0200, Jacob Carlborg thusly wrote:
>>>
>>>> On 10/12/09 04:14, Chad J wrote:
>>>>> Too bad we can't just make programs switch between GUI backends at
>>>>> will ;)
>>>> Why not have a GUI toolkit available on almost all platforms that uses
>>>> native controls just like DWT?
>>> The list of native platforms SWT supports is this:
>>>
>>> Win32
>>>    WPF (under development)
>>> AIX, FreeBSD, Linux, HP-UX, Solaris:
>>>    Motif
>>>    GTK+
>>> Mac OS X:
>>>    Carbon
>>>    Cocoa
>>> QNX Photon
>>> Pocket PC
>>>
>>> As a FLTK2, Qt 3.x, Qt 4.x, Swing, and (forked) Harmonia user I fail to
>>> see how SWT is more native than the ones I develop for. All SWT
>>> applications look weird, unthemed, and have horrible usability issues
>>> in the file open/save dialogs. DWT brings another level of cruft above
>>> the "lightweight" SWT and performs badly.
>> As a said previously SWT is more native because it uses the native GUI
>> library available on the current platform, for windows (before vista)
>> win32, osx cocoa and on linux gtk. It doesn't decide how a button should
>> look, it doesn't try do draw a button that is similar to the natives, it
>> just call the native library to draw the button.
> 
> The problem is, 99% of win32 users use the win32 gui toolkit on win32, 99% of osx users use cocoa, but on Linux/BSD maybe about 40% use gtk+. It is not The native toolkit to use. I do not even have it installed on my system.
> 
>> I don't know what you mean by "unthemed" but if you refer to that
>> applications on windows don't get the winxp look you have the same
>> problem if you create the application in c++ or c and uses win32. It's
>> caused by an older dll is loaded as default and to get the winxp look
>> you have to request it to load the newer dll with a manifest file.
>> Welcome to dlls.
> 
> I mostly work on *nixen. The unthemed means that I do not have *any* gtk+ libraries installed anywhere so it defaults to the ugly default theme. To me gtk+ does not have the native feel as I never see any application written in it. Like I said, I only use { FLTK2, Qt 3.x, Qt 4.x, Swing, and (forked) Harmonia}. I am sorry if you have trouble reading that. Whenever an application comes with its own (statically linked) gtk+ libs, it will look bad. I do not have any "control panel" to change the look and feel of the gtk+ applications.
> 
>> If you have problems with the open/save dialogs in SWT either you will
>> have the same problem in other native applications because it uses the
>> native dialogs or there's a bug in SWT.
> 
> Look, this is what I get on Win32:
> 
> http://johnbokma.com/textpad/select-a-file-dialog.png
> 
> on Linux:
> 
> http://www.matusiak.eu/numerodix/blog/wp-content/uploads/20050710-
> kdefilechooser.png
> 
> on Java:
> 
> http://www.dil.univ-mrs.fr/~garreta/docJava/tutorial/figures/uiswing/
> components/FileChooserOpenMetal.png
> 
> You can probably see something that I have started to call 'consistency'. Almost the same buttons and layouts on every platform. I immediately know how it works. The same design has been there since Windows 95, if I recall correctly. This is what many people have learned to live with.
> 
> Now every time I see a gtk+/swt/dwt application I wonder where the heck that unintuitive terrible piece of cr*p came:
> 
> http://book.javanb.com/swt-the-standard-widget-toolkit/images/0321256638/
> graphics/14fig03.gif
> 
> Native? It might very well use native binaries on my platform, but the native feel ends there.

I get an entirely different file dialog on win7, and my gnome dialog on ubuntu looks nothing like the screenshot you linked.

This is the win7 dialog:
http://i.msdn.microsoft.com/Dd758094.Libraries_CommonFileDialog%28en-us,VS.85%29.png

This is close to what I have on ubuntu:
http://blogs.gnome.org/mortenw/wp-content/blogs.dir/26/files/2009/02/file-dialog2.png

I have no Qt or KDE on both my linux installs (ubuntu 9 and a cross linux from scratch), the GUI looks smooth and works great, using the latest gnome 2.6 libraries.

Why don't you install GTK+? You can't whine about applications built for gnome looking ugly if you don't have gtk installed, it can live pretty well alongside Qt, I used to do that until i switched to gnome after 2.6 was released.
October 12, 2009
Mon, 12 Oct 2009 13:54:53 -0400, Jeremie Pelletier thusly wrote:

> language_fan wrote:
> I get an entirely different file dialog on win7, and my gnome dialog on
> ubuntu looks nothing like the screenshot you linked.
> 
> This is the win7 dialog: http://i.msdn.microsoft.com/Dd758094.Libraries_CommonFileDialog%28en-
us,VS.85%29.png

This is pretty good in my book.

> This is close to what I have on ubuntu: http://blogs.gnome.org/mortenw/wp-content/blogs.dir/26/files/2009/02/
file-dialog2.png

Yuck.

> 
> I have no Qt or KDE on both my linux installs (ubuntu 9 and a cross linux from scratch), the GUI looks smooth and works great, using the latest gnome 2.6 libraries.
> 
> Why don't you install GTK+? You can't whine about applications built for gnome looking ugly if you don't have gtk installed, it can live pretty well alongside Qt, I used to do that until i switched to gnome after 2.6 was released.

I have little desire to embrace inferior technologies. Attempting OOP on C is ridiculous, it should be called POOP. It is a personal choice. Besides FLTK2/Qt work pays well enough. I also have no time for desktop environment wars, tyvm. GTK+ != Gnome, as you well might know. I simply have no reason to install libgtk* since no package depends on them.
October 12, 2009
On 10/12/09 19:41, language_fan wrote:
> Mon, 12 Oct 2009 18:54:25 +0200, Jacob Carlborg thusly wrote:
>
>> On 10/12/09 14:11, language_fan wrote:
>>> Mon, 12 Oct 2009 14:02:11 +0200, Jacob Carlborg thusly wrote:
>>>
>>>> On 10/12/09 04:14, Chad J wrote:
>>>>> Too bad we can't just make programs switch between GUI backends at
>>>>> will ;)
>>>>
>>>> Why not have a GUI toolkit available on almost all platforms that uses
>>>> native controls just like DWT?
>>>
>>> The list of native platforms SWT supports is this:
>>>
>>> Win32
>>>     WPF (under development)
>>> AIX, FreeBSD, Linux, HP-UX, Solaris:
>>>     Motif
>>>     GTK+
>>> Mac OS X:
>>>     Carbon
>>>     Cocoa
>>> QNX Photon
>>> Pocket PC
>>>
>>> As a FLTK2, Qt 3.x, Qt 4.x, Swing, and (forked) Harmonia user I fail to
>>> see how SWT is more native than the ones I develop for. All SWT
>>> applications look weird, unthemed, and have horrible usability issues
>>> in the file open/save dialogs. DWT brings another level of cruft above
>>> the "lightweight" SWT and performs badly.
>>
>> As a said previously SWT is more native because it uses the native GUI
>> library available on the current platform, for windows (before vista)
>> win32, osx cocoa and on linux gtk. It doesn't decide how a button should
>> look, it doesn't try do draw a button that is similar to the natives, it
>> just call the native library to draw the button.
>
> The problem is, 99% of win32 users use the win32 gui toolkit on win32,
> 99% of osx users use cocoa, but on Linux/BSD maybe about 40% use gtk+. It
> is not The native toolkit to use. I do not even have it installed on my
> system.
>
>> I don't know what you mean by "unthemed" but if you refer to that
>> applications on windows don't get the winxp look you have the same
>> problem if you create the application in c++ or c and uses win32. It's
>> caused by an older dll is loaded as default and to get the winxp look
>> you have to request it to load the newer dll with a manifest file.
>> Welcome to dlls.
>
> I mostly work on *nixen. The unthemed means that I do not have *any* gtk+
> libraries installed anywhere so it defaults to the ugly default theme. To
> me gtk+ does not have the native feel as I never see any application
> written in it. Like I said, I only use { FLTK2, Qt 3.x, Qt 4.x, Swing,
> and (forked) Harmonia}. I am sorry if you have trouble reading that.
> Whenever an application comes with its own (statically linked) gtk+ libs,
> it will look bad. I do not have any "control panel" to change the look
> and feel of the gtk+ applications.
>
>>
>> If you have problems with the open/save dialogs in SWT either you will
>> have the same problem in other native applications because it uses the
>> native dialogs or there's a bug in SWT.
>
> Look, this is what I get on Win32:
>
> http://johnbokma.com/textpad/select-a-file-dialog.png
>
> on Linux:
>
> http://www.matusiak.eu/numerodix/blog/wp-content/uploads/20050710-
> kdefilechooser.png
>
> on Java:
>
> http://www.dil.univ-mrs.fr/~garreta/docJava/tutorial/figures/uiswing/
> components/FileChooserOpenMetal.png
>
> You can probably see something that I have started to call 'consistency'.
> Almost the same buttons and layouts on every platform. I immediately know
> how it works. The same design has been there since Windows 95, if I
> recall correctly. This is what many people have learned to live with.
>
> Now every time I see a gtk+/swt/dwt application I wonder where the heck
> that unintuitive terrible piece of cr*p came:
>
> http://book.javanb.com/swt-the-standard-widget-toolkit/images/0321256638/
> graphics/14fig03.gif
>
> Native? It might very well use native binaries on my platform, but the
> native feel ends there.

Of course it will look strange when you use an application built on a toolkit it isn't built for. Will have to wait for a Qt version.