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

[David Chisnall]

On 7 Oct 2009, at 22:12, address@hidden wrote:

> Hi!
>
> > 1) improve our website.  It's been the same for years and doesn't
> > reflect our progress.
>
> IMHO the GNUstep wiki main page currently is more informative than  
> the plain www.gnustep.org front page. The wiki does a good job of  
> showing project progress, too.

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.

Currently the site says to me:

- This project was alive once.
- It's based on a thing people thought was shiny once.

> > 2) improve GNUstep's default theme as well as theming in general.
> > While I know some people will respond negatively to changing the
> > default theme from a NeXT-like look to something more modern, I
> > believe it's one way for us to spark interest in the project is to
> > update it's look.   The current look should always be available, but
> > not necessarily the default.
>
> 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.

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.

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

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

When we designed the Étoilé coding standards, we made sure that every  
one of our style guidelines could be justified.  Given the number of  
novice contributors who have contributed changes to core parts of  
Étoilé, I'd say they work well.  Unfortunately, every time I submit a  
diff in a sane coding style, someone goes and reformats it in GNU  
style.  I even find my own code difficult to read when it's been  
reformatted in the GNUstep style, so it's not surprising other people  
find it difficult.

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

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

David

-- Sent from my PDP-11