new dev branch stuff

[Brian J. Tarricone]

Benedikt Meurer wrote:

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

yeah, i know.  i was more talking about the other ones.

> 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.

ok, then this is where i misunderstood.  i thought you meant by 
"advanced" that it should be ultra-geeky and super-configurable, and you 
can do whatever the hell you want with it.  like gnome 1.4, without the 
bad UI and bad design.  so yeah, i can agree with what you're saying 
about "advanced", and that it's certainly not at odds with being "easy 
to use" or "just work[ing]".

though, as an aside, i tend to take umbrage with the part about working 
as software engineers in real life.  since when was that a prerequisite 
for being a good software engineer?  and since when did "professional 
software developer" start implying "good software engineer".  i know 
plenty of good and bad so-called "professional" software engineers, and 
plenty of good and bad OSS hackers.

> "easy to use" is probably the most difficult part.

agreed, especially in something like a desktop environment.  if you have 
a specific application, you can taylor it to how people that would use 
it tend to think.  but a DE, in theory, should appeal to everyone.  in 
practice, of course, that can't work, since some people find things 
intuitive that others think looks like a page from a m.c. escher book.

for the record, i don't like aqua.  and yes, i recognise why that has 
nothing to do with what we're talking about ^_~.

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

good, i'm with you here.  i personally think that "lightweight" does 
include the general idea of saving memory when you can, but perceptible 
performance should always have a higher priority, and it's acceptable to 
sacrifice RAM for speed.  dependencies i think of as "not my problem".  
for practical concerns, i *do* worry about them, but i see that as more 
of a distro/packaging issue.  if the distro isn't willing to package my 
dependencies and make it easy for the user to install them, then the 
user isn't going to (easily) be able to run my software.  i can live 
with that.  sometimes i like reinventing the wheel for the experience 
("hey, i've never coded anything like that before; let's learn how to do 
it"), but tested, mature implementations are always preferable, if 
available.  at the same time, i'd prefer not to drag in a huge 
multi-function utility library just for one small part of it.  i tend to 
prefer to just import the code in question directly into my tree in that 
case (yes, after i drop gtk 2.2 support for xfmedia [0.7.0 probably], 
i'll ditch libexo-lite and use the shared library).

>>> 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.

yes, and some of this will always be driven by user demand.  if the 
maintainer really honestly doesn't care if the users use his/her 
software or not, then this isn't an issue.  as long as there are users, 
there will be feature requests.  as long as there are feature requests, 
there will be some that get implemented.

> (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!

ok, ok, xfdesktop's menu is a mess.  i coded the parser at 3am one 
morning after reading a spec i didn't like, and i really had no idea 
what i was doing.  i hate it, and i wish i had had time to rewrite it or 
just use your menu system instead.  but i didn't, so blah.  moral of the 
story: don't code when you're overtired, and extra hours of hacking 
something into submission to make it work are no substitute for some 
well-thought-out up-front design.

    -b