discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Chisnall
Subject: Re: Changes I've been thinking of...
Date: Thu, 8 Oct 2009 15:42:38 +0100


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]