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

[Riccardo Mottola]

Hi,

 

- I was quite satisfied with the Argus Hotel. My room was clean (also 
the bath room), breakfast was o.k., some people at my floor did party 
a little bit on saturday night (but not that much that I had to go 
out and give them a bollocking … ;-))

I found it OK too. Especially the double room with Richard was convenient.

- Sadly, the GNUstep packages in Debian/Ubunbtu are somewhat out of 
date (this alone wouldn't have troubled me) and buggy: A simple drag 
and drop action from DBModeler to Gorm wasn't possible with the 
available packages - that tells me we need more testing when doing a 
release.

That is a "historic" problem: people that continue to care about Debian packages and check them are needed. Those people should also report back possible problems to the authors. Having stuff in the debian bug tracker is not that big of help for "upstream" as they call it.

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

Well, here there are many choices and I would on purpose not deal too much with it if not with a good guide: if you compile from sources you are a developer: if you don't know how to use configure, make and sudo, then sorry, I'm not interested in helping you, really. This holds of course when packages are well done.

Apart from that, if you have debian get all the dependencies for you and then install your apps(without overwriting the existing apps, but installing "from scratch" starting from core) it is veryeasy: ./configure && make install works for whole core. I do it all the time. It works for me on gentoo, debian, netbsd, openbsd, freebsd and (partly, using stuff from sunfreeware) on solaris. YOu can isntall in the system domain or in the local domain: it will work both ways.

THe only problem is when you mix up stuff, you shouldn't have something installed twice. Although, with the recent make changes and options, you can even do that, but it gets more complicated, obviously: freedom comes at a price.

 

- 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

Depends on your sudo configuration, if it retains the ENV variables or not. You will loose usually LD_PATH for security reasons. However, if you "make" as user and then just install as root, it usually works.

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

Please no. Conext-menus are bad design. Full stop. Every action you can do should be available elsewhere. Given that, a context-menu can be a shortcut (but you should absolutely not rely on them). Having them readily available leads to design choices where you need them. I just think about terrible Mac and Windows apps.

However, context menus are possible on GNUstep too: just use latest GNUmail. If there is a context menu, you get that one, if not, you get the full menu.

We have our UI behaviour and I don't see a good reason to modify it here: it leaves everything possible, but guides you in a certain design, which is good.

- 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

In WindowMaker it usually works - barren you hit a bug with focus -. It works with some other windowmanagers too. It appears that the Gnome WM is a bit pesty, we had NSPopUpButton problems too, but they should be fixed in SVN by Fred.

- I got several minor crashes and malfunctions during my talk for 
which I will open bug reports if those are reproducible (the 
developer apps are generally usable but a little bit wonky here and 
there)

Please try to isolate them and report them. Especially if they affect other apps they need to be fixed. Check that they happen on svn trunk, since you already have that.

- My general idea was to show a simple app I prepared before and then 
do an all live demo of developing a similar simple database 
application using DBModeler, Gorm, ProjectCenter and PostgreSQL 
because I thought this will be more interesting than just showing 
some slides (I was so naive!) and a real "acid test" and proof on 
GNUstep (it was, kind of).

I share your idea, but do the ACID test at home and be able to use the slides in case. Also if you see you have problems, skip. You lost audience...

It also of cours tells you that some error messages in the application should happen earlier!

- So slides aren't all bad (as I thought in my "youthful 
foolishness"): You can explain things in a concentrated form that 
way, better than just with words, hands and obscure live action on a 
screen. Meanwhile I think that I'll mostly show slides next time and 
limit the demo parts to short spans which are non repetitive (like 
creating one entity after each other is) and illustrate only the 
central concepts.

 

Yes, I get your point, what I tried this time was to have the slides showing everything and then do an (optional) demo later. I don't say it was the perfect solution, I should ask the audience... those who attended! Slides give you a good continuity, a predictability for the presenter... and eye contact with the audience.

--- Riccardo