Re: FOSDEM Aftermath - the Hotel / Notes from preparing and giving my talk

[Truls Becken]

Lars Sonchocky-Helldorf wrote:
> - manual GNUstep installation from source is still not a no-brainer.
> Incomprehensible for a newbee with no idea about the concepts and structures
> of GNUstep (for instance the different domains). Despite I already did this
> some time ago I still had to think somewhat hard about certain details and
> read the several INSTALL files over and over again. You need to know quite a
> lot about GNUstep internals to understand what you're doing and what to do
> if something doesn't work. Luckily I also archive the discuss-gnustep and
> gnustep-dev lists and could look up things I vaguely remembered (mostly file
> system layout stuff). Also, Dennis Leeuw's build guide was of great help for
> me.

I could be wrong, but isn't this just ./configure; make; make install
in each of -make, -base, -gui, and -back, plus making sure to source
GNUstep.sh and to start gdomap on boot?

> - the need to have GNUstep.sh sourced to make gnustep-make work breaks sudo
> (despite having the sourcing of GNUstep.sh in my system-wide
> /etc/bash.bashrc). I used 'sudo su -' as a workaround but found that rather
> hackish. Maybe I missed something here

Try sudo -E

> - while I am on it: I find the right click behaviour of GNUstep (show the
> main menu under the mouse, like OPENSTEP) quite dated. Mac OS X / Cocoa has
> a context based menu on right click nowadays (like every other platform).
> Maybe we can make that configurable too (to cater both OPENSTEP heads who
> like the old behaviour and everybody else who expects a context menu): how
> about a default named GSSecondaryClickBehaviour?

Well, then the application would have to set up the menu for each
context. This is already possible, but not used extensively in the
NeXT tradition. Try right-clicking a file in GWorkspace for instance.
The application menu is shown where no context menu is set.

By the way, in NeXTstep this worked a little differently -
right-clicking *anywhere* on the screen whould show the menu of the
active application. Just a curiosity.

> - I noticed that at least when using the windows manager of Gnome (maybe
> other too, I didn't test this) the menus of apps in the background are not
> hidden of greyed out. So I often endet up with a pletora of menus hanging
> around, not knowing which one belongs to which application. Very confusing!
> I was told that Window Maker hides the menus of apps in the background but I
> think we should play well with other window manager (that aren't aware of
> GNUstep) too by being proactive. At least the menus of apps in the
> background should be dimmed

The menus and panels of inactive applications should be hidden. If
they are not, it's a bug. And yes, unfortunately there are lots of
problems like this unless one runs Window Maker (and even there it's
not entirely bug free).

> - there are other issues with window managers integration (that don't
> support GNUstep) for instance: the dock icons (are those square icons called
> like this?) running apps create interfere with the task bar of Gnome (and
> KDE): they overlap the task bar and the are placed all on top of each other
> (in the lower left corner)

Personally, I would really love a standalone Dock.app - not one that
takes the GWorkspace and AZDock approach, but a real one that
organizes the AppIcons that otherwise curl up in corner of the screen.

If you just want to get rid of the icons, you can do;

defaults write NSGlobalDomain GSSuppressAppIcon YES

- Truls