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

[Nicolas Roard]

Hi Fred,

On Nov 15, 2007 9:00 AM, Fred Kiefer <fredkiefer@gmx.de> wrote:
> Nicolas Roard wrote:
> > On Nov 13, 2007 2:16 PM, Mark Grice <markjoel60@gmail.com> wrote:
> >> 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...
> >
> > Yes, file chooser should use the native one.
>
> I don't agree here. Using native file chooser or other common dialog
> panels will be break the look and feel of a GNUstep application. OK, you
> may not like this look and feel, but at least within an application it
> should be consistent.

In that particular case, you'd break the feel, not the look -- the
rest of the UI would supposedly use theming to match the host
platform.

> Using native dialog panels would also inhibit the
> accessory view mechanism, not that we are doing that great with it
> currently.

Yes, we'd break the accessory views. But as you said, it's not really
used by applications, and I think in the case of file dialogs it
probably is better to keep the consistency with other applications on
the system than to keep consistency within the app itself.
It could evidently and easily be a choice as well -- you could choose
to distribute your app using native dialogs or not.

> It would be fairly easy to add native dialog panels on windows, but how
> would you do it on Unix systems? We have different ones for KDE and
> Gnome, other environments don't even provide a shared one. What kind of
> consistency would we gain by using a KDE (or QT) file chooser in a Gnome
> environment?

Obviously my main target here would be GNUstep on Windows, where such
integration would really be great for GNUstep (and frankly I think
would help tremendously attracting developers).

GNUstep integration on linux is much less important I think, but I do
believe that some people would like to have their GNUstep app
integrated as much as possible within their KDE environment or their
Gnome environment (imagine a company standardising on ubuntu, with
some custom apps done in gnustep -- it would obviously make sense for
them to have the gnustep apps looking/feeling as much as possible the
same as a gnome app).

I'm not saying we should _only_ use "native" file dialogs -- because
then we'd have the problem of deciding what's a "native" dialog on
platforms that use more than one toolkit -- as you say, a KDE file
chooser in GNOME would be pointless.

What I'm simply advocating is having the choice to use native dialogs
rather than the GNUstep ones :)
Eg, load a bundle that will provide native dialogs facilities, a
bundle implementing Win32 dialogs, or KDE dialogs, or GNOME dialog,
etc.

We don't lose anything, just become a tiny bit more flexible and
useful for users/developers that don't want a full GNUstep environment
but want to use a GNUstep app along "native" apps.

Now, although I guess it could be doable to simply write a bundle that
replace with categories or poseAs the existing classes, there's
possibly a couple of things we can do to the actual code to simplify
things -- I don't know, the best test would be to try adding a native
dialog and see what are the problems :)

> What we could try to do is move the gui code for these dialog panels
> into NIB files (or Gorm files if you are a bit old fashioned :-) and
> thereby offer the opportunity to replace them with layouts more suited
> for the current environment. Anybody interested in taking this task? It
> will be a great chance to learn more about Gorm.

Well... that certainly would be good anyway for gnustep (I actually
had the impression the dialogs we had were already put in nibs at some
point ?), but it would only partially answer the problem -- eg you'd
have maybe a look closer to the native dialogs, but without the feel !
and I think it's the actual worst solution we can do, because if you
have a dialog that /looks/ like a native dialogs but doesn't behave
like one, it's going to be _really_ annoying.

For instance, some (native) file dialogs provides you with:
- favorites
- network access
- previews
- etc.

Are we going to implement all that in subtly different ways each time
? and how do you get access to the favorites ? etc.
Basically at this point I think it would be better to use directly the
native file dialog.

-- 
Nicolas Roard
"La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est
quand il n'y a plus rien à enlever." -- Antoine de St-Exupéry