Ideal D GUI Toolkit

[Michel Fortin]

On 2013-05-21 12:31:53 +0000, "Diggory" <diggsey at googlemail.com> said:

> On Tuesday, 21 May 2013 at 12:12:12 UTC, Jacob Carlborg wrote:
>> On 2013-05-20 22:40, Diggory wrote:
>>> UI toolkits are a lot of work but they're not as unreasonably big as
>>> everyone seems to be suggesting... I've written a couple myself in a
>>> procedural language using Direct3D to draw everything. Had all the
>>> standard controls, various layout options, even a syntax highlighted
>>> code editor, clipboard interaction, keyboard focus, etc.
>> 
>> I think you underestimate what's needed and the controls people want to 
>> have. Did you have date picker, color picker, support for 
>> internationalization, field formatters and so on.
> 
> I had support for custom dialogs, drawing etc. and file dialogs were 
> built in so it was possible to create your own color picker, etc. in a 
> very few lines of code. The way it was designed, custom field 
> formatters were trivial. The point is we don't need to have a date 
> picker and color picker and every other control built in, at least not 
> initially. All we need is an easily extensible framework with the 
> simple controls, and then we can add more complicated controls as they 
> are requested. Once the framework is in place it will be very easy for 
> many people to contribute and everything will get done much more 
> quickly.

Not at all. It's the reverse.

Once the framework is in place, you'll have what you need to put 
buttons and fields in a window and work with them. Then comes the hard 
part.

Good luck trying to create a common ground API for table views on Mac, 
GTK, KDE and Windows. If you want to offer an API to manipulate the 
data in the table view, you'll likely need to reimplement the whole 
thing yourself. That's a *huge* amount of work and a pile of details 
will most likely be off (scrolling, selection behaviour, drag & drop). 
Or you can try to piggy-back on the platform table view widget, but 
then you're limiting the API to the lowest common denominator.

Then look at toolbars and the customization panel for toolbar items. Or 
text views, including styling text, adding links and images inline with 
the text, supporting selections (where some platforms support disjoint 
selection), enabling and controlling spell-checking and autocorrection 
(native at least on OS X).

Then comes the platform-standard UI conventions and controls. On OS X 
for instance you have popovers, sheets (alerts attached to windows), 
segmented controls (multiple buttons attached together), multiple 
layouts for buttons including a specific button style for help buttons, 
application-specific menu bar on OS X and window-specific everywhere 
else, the color picker is always a non-modal floating palette on OS X 
but not on other platforms, preference windows instantly apply their 
settings on OS X (and have no OK button), not on other platforms. 
Standard keyboard shortcuts are quite different between platforms too. 
Each convention not followed will make your app look a little out of 
place.

And even if you could create the perfect abstraction layer, it'll be a 
nightmare to write something with it. In theory it'll work everywhere, 
but in practice you still need to specify different platform-specific 
things for each control to make them look at home, perhaps using 
slightly different layouts. Then you need to test it on all platforms, 
and when you hit a bug you'll need to find out if the bug lies in your 
application, the platform's code, or the abstracted intermediary GUI 
layer.

I'm not saying it's impossible to do, just that it'll require a 
gigantic effort going beyond the simple window-button-field concepts 
into more featureful widgets and trying to emulate platform-native 
behaviours and layouts. And don't forget that you'll be chasing 
multiple moving targets. GUI concepts are still evolving, and each 
platform is changing things slightly differently these days.

That said, there's plenty of value in having a drawing API capable of 
showing a window, and perhaps some buttons and menus, for prototyping 
things. Perhaps you could build a widget API for games that'd work on 
top of that, as games usually don't use native controls that much. But 
I can tell that creating an abstraction layer around native widgets 
won't take you very far. Just try the table view thing if you want to 
convince yourself. Or toolbars.

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca/