On 7 Oct 2009, at 22:12, ici...@mail.cg.tuwien.ac.at 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
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
