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
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
