Re: Clash of the Titans, GNUstep alongside GNOME

[Richard Frith-Macdonald]

On 26 Nov 2005, at 15:27, Nicolas Roard wrote:

> On 11/26/05, Rogelio M. Serrano Jr. <rogelio@smsglobal.net> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 2005-11-26 14:22:25 +0800 Thom Cherryhomes
> > <thom.cherryhomes@gmail.com> wrote:
> >
> >
> > > it is worth noting that YES, a colour change would go part of the  
> > > way
> > > to avoid the clash, but it doesn't solve some of the
> > > (1) the BIG APPICON THAT DOESN'T FIT ANYWHERE
> >
> > Of course its not intended to live in a taskbar nor is it aware of
> > taskbars. Its meant to be big so you see it. a lot of small icons in
> > taskbar can become confusing. Same as the windows taskbar with 20
> > small icons. I just cant find what im looking for.
>
> The point is, it's perfectly fine if you're running WindowMaker,  
> but it
> should disappear in *any* other situation / window managers / desktop
>
> For example, I'm using a "gnustep" desktop, but at the moment I use
> Metacity + GWorkspace + GWorkspace shelf. Damn, huge stupid icons
> clashing with my "OPENSTEP 4" setup.. :-)
>
> Of course that's the same problem if you want to run a GNUstep app
> (say, GNUMail) within KDE or GNOME.
>
> Basically, the appicon should disappear with other windowmanagers.

I think you should have the OPTION of having the app icon disappear  
(actually, I thought you already did ... but perhaps it's gone or  
doesn't work reliably).  I don't believe it should do it by  
default ... the icon is too useful for that.

I also think it would be nice to have an app which would manage  
appicons (sort of like a dock ... a panel containing the appicons of  
all running gnustep apps and allowing you to organize/manage them  
when running in a gnustep-hostile window manager).

I don't know if you have used the windows backend recently, but it  
now pops up an alert panel the first time you use an app, which asks  
whether you want to use GNUstep/NeXTstep style window borders and  
appicons or native window borders and the taskbar.  This then sets  
user defaults accordingly (and doesn't ask again unless you remove  
the user defaults).  It also inserts something in the standard info  
panel to let you call up this option again if you change your mind.

To my mind, this is a thoroughly good thing ... and should probably  
be done by the X backends too.
It keeps the standard default look and feel.
It lets you easily change to work with the 'native' environment
it doesn't keep intruding once you have set things up
It's easy to change your mind later

> - first, people trying GNUstep apps will likely do it first in their
> usual environment;
> if GNUstep apps play well with it, it can be an incentive for them to
> really try
> a GNUstep desktop (if they don't play well, it'll be more "hm, not
> really interesting, move on, nothing to see")
> - second, even you are probably running other X11 apps (mozilla,
> firefox.. ?) within your GNUstep desktop; better integration will
> help.. and if we provide *good* apps (imho what we should try to
> harvest, that's another thing that bring users ;-) it's likely that a
> sizeable fraction of people will want to run them alongside their
> normal desktop, and won't want to switch completely to WindowMaker --
> eg just for run GNUMail, even if GNUMail is excellent... and more
> GNUstep apps used overall will improve our situation, even if they
> aren't run "within a gnustep desktop"
>
> - third, we *NEED* the integration anyway, because I don't think  
> you can
> actually achieve anything on GNUstep/Windows if those integration
> problems aren't
> fixed -- it will be difficult to convaince all Windows users to switch
> to a GNUstep desktop, don't you think ? And fixing those on Windows
> (ie providing the right
> options / hooks) will help (or will solve) the possible integration
> problems with KDE/GNOME.

Yes ... but I suspect people are worried and overreact to the  
suggestions of changing things ... of course we DON'T want to change  
things to remove all that's good about the NEXT designed GUI, but  
that's what it often sounds like when people start complaining about  
lack of 'integration' with a 'native' interface.
This is why I'm concerned that we should -
1. keep the current interface as default
2. provide themes for the other interfaces
3. make switching VERY easy
4. try to make things interoperate as well as possible even when we  
are not using themes to make things match.