On 2013-05-21 12:31:53 +0000, "Diggory" <digg...@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.for...@michelf.ca
http://michelf.ca/
