Re: Changes I've been thinking of...

[icicle]

Hi!

> While I think the wiki is a good idea, it's not a substitute for an
> official project page, which needs to say:
>
> - This project is alive.
> - This project is shiny.
> - This project is actively used by some people.

I'm with you there :)

> > As much as I love GNUstep base, I do not like GNUstep gui. Don't get
> >  me wrong, I still burst in tears of agony if I have to use another
> > GUI library than GNUstep gui, because everyone still treats GUI as
> > code, even C# and WindowsForms. GNUstep gui still lacks in
> > polishing. Using a graphical GNUstep application on Gnome/KDE/Xfce
> > ist still a pain because:
>
> I don't completely disagree here.  I think -gui has improved a huge
> amount in the last year, mostly due to Fred's work.  Nicolas, Fred
> and  Quentin worked a bit on live resizing at the Étoilé hackathon,
> which  makes things look a lot more modern.  Things are still slower
> than  they should be and we need to do some profiling to work out why
> that is.

Currently I don't work that much with gui, all I need is a window with
an OpenGL context and in some cases an additional window with some
settings. I am still using the art backend as I had issues with cairo
(window and contents didn't display correctly, black polygons all over
the place), but I am still using Ubuntu 8.04, so maybe the cairo
package is rather outdated.

What comes to my mind regarding GNUstep applications is that for a long
time now my perception is that Gorm is the only serious GNUstep
application. It works, it does it's job and it is maintained. No other
GNUstep application fulfilling those criteria comes to my mind.

> There are also some plainly embarrassing bugs, like the fact that
> underlining still doesn't work.  Much of the text system code is in
> need of an overhaul, because it's currently a mess of premature
> optimisation that none of the current developers actually understands.

Ouch.

> > Another issue is code quality. For example, the code in GNUstep back
> >  is one hell of an ugly mess. I had to touch it, but I felt a chill
> > running down my spine in doing so. Everything in XGServerEvent and
> > associates looks like a mass of hacks piled on top of each other.
> > It's such a chaos, I do not want to touch it anymore in fear of
> > breaking somthing completely unrelated.
>
> Back also frightens me.  At the hackathon, I talked to Fred a bit
> about refactoring it so that, long term, all that -back will do is
> create drawing contexts and handle events.  We will then use a
> CoreGraphics implementation, probably based on Opal (which was just
> copyright assigned to GNUstep, I believe) to handle drawing using
> Cairo.  This would let us use the same drawing code on X11, Win32 and
>  on any of the other platforms Cairo supports (e.g. Zeta, OS/2,
> DirectFB), with just a small amount of new code for turning the
> platform's native events into NSEvents and for calling the cairo
> functions for creating graphics contexts.

Sounds reasonable :)

> > Additionally I really dislike the coding style, not because it's not
> >  mine, but because it fails to make the code more readable. On the
> > other hand, there was code by Fred which looked really ok, so maybe
> > it's just about using the coding style in a sane way.... All I
> > wanted to say is, that it's not that easy to start hacking inside
> > the GNUstep core libraries.
>
> Completely agree.  Good coding conventions are picked because they
> make things that are wrong look wrong or generate compiler errors /
> warnings.  The GNU coding conventions were picked by selecting at
> random various bits from all existing coding conventions in the hope
> that that would make everyone happy.  They are a horrible mash of
> things.  The indenting style is horrible, for example, and only works
>  if you have your editor set up in exactly the same way as RMS;
> mixing  tabs and spaces for indenting is one of the most stupid ideas
> I've  ever seen.  The convention of putting a space after function
> names and  before the open bracket makes code harder to read because
> it makes it  difficult to tell without reading the context that
> something is an  argument list rather than a subexpression.  In fact,
> almost everything  about the GNU coding conventions looks painfully
> stupid to anyone with  a basic understanding of how the human visual
> system works, but as an  official GNU project we are stuck with it.

I didn't know you have to stick to the GNU coding guidelines if you are
an official GNU project. Now I understand all the people complaining
about gcc being unreadable...

> > > 3) Improve our ability to market ourselves in general.
> > Yep. IMHO Distributed Objects alone is one hell of a feature, making
> >  it worth to use Foundation just because of that.
>
> Yup, DBUS is a horribly hacky clone of DO and people seem to get
> excited about it.  DO could be a killer feature, if more people were
> aware of it.

I do love Foundation because it provides me with a lot of stuff which I
need every day. I do not have to care about strings, I do not have to
care about file management, all the containers are pretty simple to use
(and they are heterogeneous), I do have distributed objects, I do have
the notification center for message passing, and so on and so forth. I
am really a lot faster with coding if I am allowed to use Objective-C
and GNUstep base. I even did port the physically based renderer at
university, which currently is developed on Mac Os X, in 2 days to the
fat 4 socket opteron machine running Ubuntu server. All I had to do was
to create the makefiles and resolve some ix86 vs x86_64 issues (long vs
int). Kudos to Nicola for implementing "-j" support in GNUstep make;
doing make -j 16 is a lot of fun, seeing the huge renderer being
compiled in 15s!!!!!! And rendering images for publications in a couple
of minutes instead of hours. There are some people who owe you for
making that possible.

On to my experience with GNUstep while writing my own OpenGL rendering
engine. Foundation helped me a lot, but gui/back really was in my way.
I thought about switching to glfw because of:
1. NSOpenGL was broken
2. I did not know how to setup my update/render loop without timers (I
do not want to have fixed timesteps)
3. I did not know how to track all NSEvents (I need to know which keys
are currently pressed, for mouse and keyboard)

I did solve all of these problems, but it was frustrating. Regarding
(1) I hacked around in back to fix the most gruesome NSOpenGL
shortcomings. Regarding (2) and (3) I subclassed NSApplication and
overwrote the event loop, which was possible only because of me having
access to the original NSApplication source code, on Mac OS X I would
be screwed. (1) was a GNUstep specific problem, while (2) and (3) are a
general problem, so this is not about ranting against GNUstep.


> > A modern look wouldn't hurt, too. You could talk to the Etoile
> > people if you need fancy images from a GNUstep based desktop :)
>
> Gregory has been working on theming a bit recently and, last time we
> spoke, he was planning on making it possible for GSTheme to load the
> Camaelon theme bundles, letting us remove Camaelon from Étoilé.
> There  was also some talk of moving Jesse's Narcissus theme from
> Étoilé to  GNUstep.

Hopefully at the start of next year I will be done with university
completely, so I could find time to hack around in GNUstep/Etoile :)

Cheers
TOM