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

[Mark Grice]

OK, valid points. One thing I want to emphasize is that I am NOT
suggesting that GNUStep supports MDI. Lord forbid!

I don't think that is necessary for widespread adoption (Mac seems to
have done OK without it :-) But a single horizontal menu bar seems to
be the accepted practice of all non-Redmond users, and the direction
of Cocoa.

So.. maybe a good compromise would be dialog boxes and not widgets? I
can live with different widgets... (Maybe even some sort of a widget
editor where I can recreate the widgets used if I want to?)

But dialog boxes are a prime example of what would be better if it
were native. For example: Ubuntu has Samba, which allows me to get to
the windows drives on my network. It also allows me to view thumbnails
of the graphic images. Their file dialog box supports these out of the
box... As a developer, it would be nice if my file chooser
automatically gave these kinds of options to my end users. I am
assuming that the native GNUStep does not, because when I run the
examples, I can neither see thumbnails of images, nor can I access my
SMB files... But that may be ignorance on my part...



On Nov 13, 2007 9:05 AM, Nicolas Roard <nicolas.roard@gmail.com> wrote:
> 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
>