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

[Wolfgang Lux]

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.

In my experience, the best choice for installing GNUstep from source  
is to start with gnustep-startup and use its ./InstallGNUstep script.

> I then finally decided to do a install into the System domain to  
> replace what came with Ubuntu (but retain the somewhat good  
> integration into the 'Applications' menu of Gnome)
>
> - I found no way how I would determine what Frameworks/Libraries  
> are required for a given gnustep-make based project/application  
> (since there's no configure phase) and whether those are already  
> installed.
>
> - 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

  sudo sh -c ". $GNUSTEP_MAKEFILES/GNUstep.sh; make install"

Might be worth an alias in your .bashrc if you do it often :-)

> - later I had to fight a nasty half-offscreen menu (the title of  
> the main menu of DBModeler was offscreen). I found no intuitive way  
> to get it back on screen (I tried - for instance - alt-drag, a way  
> to grab an usual window anywhere and move it then). I don't know if  
> it would be a better idea to automatically "fix" menu positions  
> when an application starts (I've heard some people place the menus  
> offscreen deliberately to get them out of the way and use the right  
> click to get them on demand) or to have a modifier key drag to move  
> the menu by grabbing it anywhere. Maybe we should have even both -  
> combined with some defaults, let's say
>
> defaults write GSAutoFixMenuPositions false
>
> to switch that behaviour off (standard should be 'on' or 'true' to  
> help the newbees)

With respect to the offscreen menu you should probably file a bug  
report (unless it has been fixed in the meantime).

> - 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?

If you run GNUstep apps with the NSMenuInterfaceStyle set to  
NSMacintoshInterfaceStyle, you no longer get the main menu on a  
secondary mouse click. In fact, you get no menu at all then, since  
nobody so far has cared to set up default (context) menus for those  
views where OS X does provide a context menu (at least NSTextView and  
the private toolbar viewer class).

> - 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

You have been told wrongly. GNUstep is responsible for hiding the  
menus of apps running in the background and this should work  
regardless of your window manager (it should work even without a  
window manager). If it doesn't work for you, file a bug report.

> - 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)

Yes, indeed. I find that behavior annoying, too.

> - the integration of dev apps (ProjectCenter, Gorm, GDL2) could be  
> a little bit tigher. For instance:
> * Currently ProjectCenter creates project templates which contain  
> a .gorm file in an outdated version. When you start using  
> that .gorm file in Gorm without re-saving it first you might  
> experience a crash when dragging some GDL2 stuff into it.

Another case where a bug report is apt.

> * ProjectCenter doesn't provide a template for GDL2 apps. I  
> handcrafted one for my talk, which is not included in  
> ProjectCenter, but I have to make a copy of it manually and run a  
> very simple bash script over it that renames particular files and  
> changes some files' contents accordingly. Worked for the moment but  
> doesn't make the best impression in a talk in which I wanted to  
> show the ease of developing with GNUstep.

Regards
Wolfgang