[Top][All Lists]

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

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

From: icicle
Subject: Re: Changes I've been thinking of...
Date: Thu, 8 Oct 2009 18:08:13 +0200
User-agent: Internet Messaging Program (IMP) H3 (4.0.4)


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.


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 :)


reply via email to

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