new dev branch stuff

[Benedikt Meurer]

Brian J. Tarricone wrote:
> Benedikt Meurer wrote:
> 
>> My personal vision for Xfce was always to make it
>>
>>  (a) "just work"
>>  (b) "easy to use"
>>  (c) "lightweight"
>>  (d) "advanced" (this is least important, IMHO)
>>
>> Atleast the first 3 points imply that the core is small and easy to 
>> maintain, which isn't the case currently (I think I say that, as I was 
>> the one that tried to release the beast!).
> 
> the problem that i see is that a+b and d can be difficult to do at the 
> same time.  of course i guess this depends on what you mean by 
> "advanced".  if you mean that it's very flexible in that each user has a 
> host of options and can configure it to their taste, then it's somewhat 
> hard to make that "easy to use" (unless you expect the "must be easy to 
> use" users to not configure it really, and then it just becomes a matter 
> of sane defaults).  making something advanced in the sense of having 
> more configuration options is sometimes mutually exclusive with being 
> lightweight (though ultra-agreesive modularity and use of 
> runtime-loadable shared objects helps a lot here, though with a minor 
> perf penalty).
> 
> i dunno - i'm not sure where i'm going with this - i guess i don't 
> really understand exactly what you mean by these 4 criteria, and how you 
> feel they relate to and interact with each other.

What I mean by "just work" is quite easy to understand: Software should 
compile and run out-of-the-box on as many platforms as possible (with 
atleast minimum of popular Unix systems (BSD and Solaris) and most 
popular Linux systems). Its no problem if the maintainer itself has no 
access to such systems, just gimme a ring and I'll port it. But this 
implies that the software is well-designed, and that the upper layers 
don't make implications about the underlying system and such! This is by 
the way one area where KDE and Gnome always failed; I haven't seen a 
single Gnome/KDE release that didn't require patching for Unix (but I 
don't use Gnome/KDE regularly, so I might have missed the "just 
work"-release).

That brings me to "advanced": "Advanced" doesn't necessarily mean that 
you have a bunch of options in your software. Instead, from my point of 
view, a software is advanced, if it is well designed (well 
structured/layered) and well written. Advanced software is extensible, 
because the layers are independent of each other. That means, for 
example, I can change the functionality of one layer without touching 
any other part, because of well-thought interfaces. IIRC, many of us are 
working as software engineers in real-life and should know how important 
the points mentioned above are for successful software projects (this 
basicly applies to most areas of engineering). "Hacking" is quite 
popular in the OpenSource community, but that doesn't qualify it as a 
good software management technique.

"easy to use" is probably the most difficult part. Its even more 
difficult to tell what you mean by that term. Several people classify 
KDE or Microsoft Windows as "easy to use". In my opinion (and I'm not 
trying to speak as an Xfce dev now), thats simply not true. People think 
of KDE as being easy to use, because its pretty similar to what they 
already know, Microsoft Windows, which doesn't mean, KDE is "easy to 
use" in general, but only tell, that KDE is "easy to use" if you are 
used to the Windows user interface. The same applies to Microsoft 
Windows; it isn't "easy to use" in general, but "easy to use" for the 
people, because they have to use it in their daily jobs, etc. Don't get 
me wrong, I'm not trying to debase the KDE or Windows developers. They 
surely spent a lot of time for their projects. I'm just trying to 
clarify the term "easy to use". I'll give you a simple example: My 
mother is completely computer-resistant, and she had a lot of trouble 
getting used to the Windows system installed on my fathers PC; all she 
wanted was to surf the web and play mahjongg. She doesn't care about 
computer internals and in my opinion, she don't need to; and she often 
needed assistance when she sat down at my fathers computer. So I bought 
her an iBook for her birthday last year, and now she's finally able to 
browse the web (using Safari), read her emails, play games and even do 
some basic stuff with Finder. She can do all this of her own. Just 
because Aqua is "easy to use", *WITHOUT* the need of being used to 
computing already. And thats what I mean by "easy to use". People, that 
have never been used to "that computer thingy" should be able to use the 
software (basicly a "just works" on layer 8). Of course, I'm only 
referring to the desktop environment case now; for specialized software 
it isn't suitable to be "easy to use" for unrelated persons. (On a side 
note, I'm pretty much aware that quite a lot of people hate Aqua for 
various "geeky" reasons, and if think of posting a rant now, you have 
definetly missed the point in my explanation!).

Last but not least "lightweight": This is pretty easy to explain, now 
that I have explained the other terms. For me, "lightweight" doesn't 
mean, that it consumes less memory than xx MB. Thats completely stupid! 
For many applications, it can be very useful and "lightweight" to consum 
more memory (e.g. keeping data cached to avoid disk seeks, etc.). I 
think of "lightweight" as: fast startup (if the use case allows it) or 
atleast a smooth startup (which means, the application should be usable 
once you see the main window), good response time (applications should 
respond immediatly to button clicks, etc.) and few dependencies (this 
sometimes conflicts with "well-designed", esp. when you start to 
reinvent wheels, and here one needs to find a good balance).

>> With all the recent changes and ideas popping up, I thought it was 
>> time to ask if we still have a goal, or if we simply follow the 
>> tradition of KDE and Gnome (which would basicly mean for me, to 
>> re-think if its really worth to spend my spare time on Xfce).
> 
> bottom line: all software tends to grow in size as time goes on.  it's 
> inevitable.  all we can do is try to make it as modular and 
> well-designed as possible so that the size increase is manageable and 
> doesn't affect performance and memory footprint (too much).

Software doesn't grow autonomously. Its the maintainers that let 
software grow. Its up to the maintainer to decide what goes and what 
not. (BTW: from my experience, the most problematic code, that causes 
groth of complexity and maintaince, are bugfixes, because they are done 
quickly and often hacked up, without lot of thoughts, and (Brian, I'm 
pretty sure you know what I'm about to say now) its therefore very 
important to spent hours of thinking in the beginning!

But that wasn't the point.

>    -b

Hope that explains the questions I raised a bit,

Benedikt