Native widgets (was: Re: So, honestly, is GNUStep a viable development option?)

[Nicolas Roard]

On Nov 13, 2007 1:37 PM, Mark Grice <markjoel60@gmail.com> wrote:
> B) Native widgets. Why not? I used to work for Neuron Data about 15
> years ago. We had a product called Open Interface that provided a
> cross-platform GUI. It was great when we started -- a superset of all
> windowing environments... but we couldn't keep up. Critical mass was
> against us. Our developers kept telling us that there was no way to
> use native toolkits then... suddenly... there was. It made a
> difference. Now if I opened a file dialog box it looked like everyone
> else's. That is HUGE to a user. I can't emphasize it enough...

It's not that is it impossible to achieve, but it would bring little
value; bear with me...
The reason why people say we can't support native widgets is because
of our architecture -- everything displayed by a gnustep app is done
through the toolkit (obviously), in a vector form, and with a common
widget ancestor.

Implementing native widgets could possibly be done by having one
window per widget that would be remapped at the right position; but 1)
it's rather inefficient 2) it would also need quite some work to work
around the native widgets so that we'd still work with them following
the gnustep api (I mean, sure for a button it's easy, but what about
NSTableView ? you'd end up reimplementing half of NSTableView logic as
a wrapper around a native tableview widget, and it likely may not even
be doable because of lack of capacities from the native widgets). It
would break any consistency -- how to inherits from a native widget to
specialize it ? And what to do when a gnustep widget does not have an
equivalent on the platform (eg, NSBrowser) ?

So really, native widgets... not such a good idea.

But on the other hand, we should strive for platform integration, if
GNUstep's goal of beeing a cross-platform api wants to be met (sure,
there's a school of thought saying we could just be exactly the same
on any platform, and that may be true or good enough for some use
cases,  but I do believe the majority of developers and users would
love more integration with the host platform).

As explained above, using "native" widgets is not a good idea -- it
would be a tremendous effort for nothing much more than getting a
WxWidgets clone, with important loss of consistency and capacities.
But what we can /easily/ do is to use theming facilities to at the
very least integrates better visually -- and on Windows for instance,
there is a theming api ready to be used for just this kind of case.
And theming can be a bit more than a different look -- swapping
scrollbars position (from left to right) is doable as well (there was
a bundle that did that), etc.

To be thorough, there IS some widgets/facilities where we indeed
should use the native ones, like the file chooser, etc. , but they are
more an exception than the rule.

So for me the proper route is to 1/ use host theming api (when
present) to integrate visually 2/ use native widgets for a few
selected things like the file chooser 3/ pasteboard integration ...

Note that this is _exactly_ what NeXT did with OpenStep for Windows.
It's not a perfect solution but it's a good compromise.

-- 
Nicolas Roard