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

Re: Bloat: XML, GUI design (was: Re: [OT] Gnome configuration (was: Re: Congrats! [gnome font rendering]))



#include <hallo.h>
* Colin Walters [Fri, Jan 17 2003, 08:13:52PM]:
> > You can use XML for seldomly used
> > applications, but not for such important things. Hell, compare "set
> > antialias=1" with the monster we are talking about 
> 
> Of course, the configuration file is more complex that just setting a
> boolean value or two.  You can match font names and do different stuff
> depending on conditional values, specify blank characters, multiply
> fonts by matricies, and other stuff I probably don't know about.

Fine. And do you really think, XML is perfectly human readable for
manual editing? I doubt. And if it is not meant for manual editing, what
is the point of making such bloat around of few values? Sure, I would
also use XML for applications you need once a week since the parser does
most probably exist for your $LANGUAGE, but not for end user
application. No wonder that even primitive applications need several
seconds (read: billions of CPU cycles) to start, if every programmer
takes the way easy for him, not the most efficient one. Fontconfig's
solution seems to be a binary cache. So what is the benefit from using
XML then?

> > - 8..9 times of the
> > code size. It is already to much for a single boolean value. Where
> > should all this end? In a 10Ghz machine with DDR5000 RAM, using 90% of
> > the CPU time to parse the useless metadata?
> 
> Your assertion is absurd, and you know it. 
> Using XML solves some real issues that happen in the real world, like
> character set handling (one of MY pet peeves), 

Use Unicode. Means no additional code in best case.

> representing highly structured data (like the matrices above), 

There are still compacter ways to represent it.

> allows automatic document structure verification (see fonts.dtd),

Please, now you begin with FUD. We talk about configuration files, not
complicated documentation format.

> and has tons of standard tools to manipulate it.  

Easy for programmer, but efficient?

> There are other ways to solve these problems, sure...but the
> fontconfig author choose a perfectly sensible way to solve them.

And that is what I mean. Simple to code, expensive to parse, best to
continue having the reputation of "fascinating, plattform-independent
but unacceptable slow". For example, average Windows XP installations
starts faster than average Gnome (subjective, personal experience), not
counting the time that Linux kernel needs. So what is the goal behind of
bloating a GUI that should behave smooth and fast?

> Frankly I am disappointed in you, Eduard; I thought you would be above
> pointless ranting.

So what, I do not care. I am getting disappointed with more things
happening in the project now. There few key developers that have control
over the system and became selfish or inflexibel over time. Stopping
every active development, intentionally or not. Unwilling to realize
that the project is slowing down, and alternative ways are needed.
Unwilling to give up some tasks and let others do the job, even if they
have not enough motivation to continue to work actively on their tasks.
But try to bring anything new or critisize, you will be either ignored
or get a "shut-up-stupid-newbie-I-know-better" mail.

The bullshit happening among upstream developers have been described
by Emile.

Look at the current release scheme idioticy. We try to synchronize
lots of different Debian projects and upstream development, but this
does NOT work good with release periods taking 2 years. Forget it. Woody
was a good warning, but Sarge seems to following its example. Instead of
releasing two Debian versions (Woody in August-October 2001, Sarge one
year later), we failed completely. Now, Woody is a mixture of outdated
(read: unsupported by upstream) package versions, or unstable betas, and
in one year, we will have the same discussions as in spring 2002, having
the same problems with software museum, shipped as STABLE distribution
with even more known upstream bugs, fixed by every other distribution
years ago (except of Debian, of course), not supporting any modern video
card, etc. 

So, this mail became now a summarry of random worries, now feel free to
lynch me on -private.

Eduard.
-- 
Diagnose? Erklärungen? Reproduzierbare Lösungen? Sowas wollen nur
Leute, die von EDV nichts verstehen.



Reply to: