Re: FOSDEM and beyond (next stable release of base)

[Richard Frith-Macdonald]

On 9 Feb 2010, at 13:48, Quentin Mathé wrote:

> On a somewhat related matter, the next Étoilé release (initially planned for 
> January but which won't probably happen before March) will require new 
> releases of every gnustep core modules (base, gui, back and make). We will be 
> ready once:
> - we have an Étoilé theme ready based on the new GNUstep theming (Eric is 
> currently working on that)
> - our horizontal menu support is fully merged back into GNUstep (mostly means 
> deleting code on our side and tweaking GNUstep to let us customize the menu 
> more in-depth… e.g. menu title view. I have started to work on that)
> - getting NSImage drawing methods work exactly as they do on Mac OS X (when 
> the coordinates are flipped), see bug report #27782. I have a more recent 
> patch which is probably more correct, fix extra issues I discovered in the 
> meantime but which currently only works with Cairo and needs to be cleaned.
> - gnustep-make detects the runtime version and exports a variable, which can 
> be checked in GNUmakefiles, plus an identically named -D flag to support 
> conditional #import in the headers. e.g. GNU_RUNTIME_VERSION=2 or 
> RUNTIME_VERSION=gnu2. We discussed that a bit with Nicola at FOSDEM. The idea 
> is to have the possibility to check whether we use libobjc or libobjc2 
> without having to resort to parsing the version number of libobjc.so.x in 
> every project, where we build files conditionally based on the runtime 
> version, or where we import this header: 
> <http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Frameworks/EtoileFoundation/Headers/runtime.h>.
> 
> The last important thing is that the next Étoilé release will require the 
> Cairo backend. Which means, packaging Étoilé would be much easier if GNUstep 
> makes Cairo its default backend for the next gnustep-gui/back release.
> 
> Any comments? Does that sounds feasible to have a GNUstep unstable release in 
> March/April?

Well, only doing a new unstable release of base is my direct responsibility 
(there's no problem with that), but the others all sound reasonable to me, 
though there may be quite some work to do still on theming.

I would really like to see theming be usable by designers (people wanting to 
produce nice looking themes), not just for integration with 'native' systems 
like mswindows or gnome.  The latter *needs* coding while the former is much 
better done avoiding coding, so we really want to try implementing support for 
all the recent (code-based-theme-oriented) changes in Thematic.app, and if 
necessary change them to be more friendly for non-code themes.  Eric may 
already be doing that (I haven't tracked the recent changes).
However ...this is really only an issue if you are worried about the theme API 
changing ... if it's OK for Etoile to track any changes then there's no issue 
to worry about.

Polished horizontal/in-window menu support is great.

NSImage drawing fixes are also great to have.

I expect Nicola can sort out the gnustep-make changes, so that only leaves 
making cairo the default backend... that one might be contentious as Cairo is 
quite new still, and not trusted by some (actually, when I tried to use it last 
week it failed to draw any images at all ... so I'm currently using art).  In 
particular I recall Fred (who wrote it) saying it wasn't ready a while back.  
He might have changed his mind by now though.  Anyway, he should be able to 
give you a definitive answer on this.