Re: Re: scrollbars [was: Re: really attracting developers]

[phil taylor]

On Tue, 2006-09-05 at 03:28 +0100, Nicolas Roard wrote:
> On 9/5/06, phil taylor <ptay1685@bigpond.net.au> wrote:
> > On Tue, 2006-09-05 at 00:51 +0200, Helge Hess wrote:
> > > On Sep 5, 2006, at 24:38, phil taylor wrote:
> > > > Can anyone (try to) explain the merits of the floating menus?
> > >
> > > You just need a single click and no drag to perform an arbitary
> > > (menu) action. You can easily detach the menu groups you need and
> > > thereby form some kind of "favorite menus".
> > >
> > > A floating menu is more like a toolbar (or many toolbars) though a
> > > toolbar wastes space in every single window (but has better locality
> > > in return).
> > >
> > > I think there are no absolute pros or cons for either of the
> > > approaches. Both have their merits. If you have ever used NeXTstep
> > > you will know that vertical menus are very nice, a look&feel is
> > > something hard to describe in words.
> > >
> > > Greets,
> > >    Helge
> >
> > Thanks.
> >
> > So the real advantage seems to come when you detach the lower level
> > menus and personalise the interface. But doesnt that use up a lot of
> > space? Do you have to do that each time the app is loaded?
> 
> Of course not. One of the good things with GNUstep apps is that all
> this stuff is persistant -- I close an application, I reopen it, and
> all the opened submenus come back where they were, and the different
> windows reopen at the same place too. Persistance is good... :-)
> 
> Secondly, the screen space they take is not very important -- first
> because you can obviously close them if you need, secondly because
> things that are not windows (ie, panels and menus) disappear
> automatically when you switch to another application.
> 
> Imagine that you are using TextEdit. You opened the font panel so you
> can easily play with font settings. You also have 2-3 submenus opened,
> that you moved somewhere on the screen where it is more convenient for
> your current use. You then click on GNUMail -- automatically the
> TextEdit font panel and the menus disappear, the only TextEdit thing
> left on the screen is the actual window containing your text; and
> GNUMail's own panels or menus appears.
> 
> That behaviour seriously help reducing the screen clutter.
> 
> > I am dissapointed that the GNUstep project is devoted to its UI design.
> > I had hoped the most important aspect was the API, not the look and feel
> > of the GUI. IT will never suit me. I HATE menus, especially cascading
> > ones.
> 
> Because you never used proper ones :-P
> 
> just kidding. I agree with you -- the most important thing is probably
> the API, not the UI. But the whole UI "experience" is important too,
> and if something is good, it's a bit stupid to want to throw it by the
> window, don't you think ?
> 
> Anyway, you do not have to use vertical menus if you don't like them.
> Just set the defaults NSInterfaceStyle to use horizontal menus, or use
> the EtoileMenu bundle.
> 
> Personally, I like vertical menus, I think they work brilliantly with
> big screens. On the other hand, horizontal menus (ala mac) work better
> on small screens. Horizontal menus also have the added "functionality"
> that it's easy to add things like a "system" menu (eg the Apple menu
> on Mac OS) or menulet (clocks, virtual desktop, battery, user
> switching,  sound, whatever) ; with vertical menus you can't really do
> that, so it means you need another place on the screen to put this
> kind of info/actions.
> 
> That's why on étoilé we finally settled on using horizontal menu, like
> OS X. Probably also because it's much easier to convaince people to
> use horizontal menu than vertical menu, and fitt's law is with you.
> But still, I love vertical menus :-) and optional vertical menus is
> certainly a good thing.

Is this étoilé project a fork of GNUstep? It looks interesting.

> 
> > What I would like is for the GNUstep api to be integrated with GTK+. Now
> > that would be something i would go for. But obviously from my
> > conversations on this mailing list, very unlikely to ever happen.
> 
> You are not very helpful :-)
> 
> You ask people to tell you what the UI is good for, as they seem to
> think it's not as crappy as you'd consider yourself; then you tell
> people that they value more the UI than the API (which they never
> said). Then the final conclusion is to "integrate GNUstep api to GTK+"
> ? are you joking ? That can't happen, not for political reasons
> (well.. not only..) but simply because it wouldn't work --
> philosophically and technically the two api are really different. In
> the end you'd need to redo/clone lots of work on either side, to end
> up with something that would be worse. Beside, a good reason OpenStep
> is that clean is because of Objective-C -- you'd need an OO language
> as dynamic as it.

I didnt really mean literally to integrate GTK+ and GNUstep api. I meant
to have the dynamic obj-c based GNUstep api but using a GUI paradigm
that looked like GTK+. In other words I want to be able to created a
GNUstep app that when you run it looks indistinguishable from an app
written using Glade, GTK+ and the Gnome api's.

Of course it is hard for to comment authoratatively about GNUstep since
I know so little about it. This is largely due to the difficulty with
obtaining information about it without having to wade through mountains
of documentation.

I have tried many times to get GNUstep installed and running but with
little success. Its easy to get hands on with Gnome to use as an end
user, but not so with GNUstep - at least in my experience. I could never
get the live cd to work properly.

If I install GNUstep on Debian (which im using now) the best I can do is
run the text editor and perhaps GNUmail. Both of them nice, simple and
harmless apps, that looks as appealing visually as a text based app on
an IBM mainframe (to me).

I get the impression that if I write an app with GNUstep it will look
like a GNUmail clone - not quite what I am after.

Obviously I might be completely wrong - but as I say it is hard to find
out anything, excepot maybe via this list, which is why I am here. So
far it looks like at this moment in time I am correct.

> 
> I really do not see any point in that. Particularly considering
> GNUstep works. One could argue about some kind of GNUstep theme
> piggybacking on GTK+ theme engines for doing the raw drawing, so that
> GNUstep apps could "mix" seamlessly into a GTK+/GNOME desktop, but
> that's about it... you'd need more things too for real integration...
> but that would/could be a good first step. Nothing prevent that, this
> idea was actually advanced many times, but nobody stepped up doing the
> job of splitting GNUstep into different "environment targets" (eg,
> GNUstep/KDE/GNOME/Windows). If you view GNUstep only as a kind of
> platform like wxwidgets, that would be, imho, the sensible path. It's
> probably not even that difficult (considering the features you'd need
> are actually here, just not too well divided into this idea of
> "environment targets"). But as always, nothing will change without
> actual volunteers doing the grunt work. Talk is easy, yada yada.
>