[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Review Request: Add "Open With" actions to KFileDialog context
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2010-02-03 5:47:43
Message-ID: 201002022147.44768.aseigo () kde ! org
[Download RAW message or body]

On February 2, 2010, marcel partap wrote:
> This always has been the biggest strength of KDE3: provide all possible
> functionality everywhere plausible. 

it was also a major blocker for many. there is ballance to be struck, kde3 got 
it wrong too often.

> With KDE4, the opposite direction has been taken - simplicity is now
> considered the sane default 

you've misinterpreted what's going on. 

where there have been lots of lacking features it's almost always been because 
things were being rewritten. example: the file views in konqueror/dolphin/file 
manager. they were rewritten because of Qt4's model/view. during that process 
there were fewer features. the goal wasn't fewer features, however, and as 
development has continued that can be quite obviously seen.

usually where it _seems_ there are fewer features there are actually the same 
or more because those features are actually presented more ergonomically. the 
recent "oh no, gwenview has fewer configuration widgets in the config dialog 
means it has fewer features" stupidity was a great example of failing to grasp 
this. gwenview in kde4 has more features than in kde3.

sometimes features have indeed been dropped. often this is to make way for 
features deemed (wrongly or rightly) as more desirable, sometimes it is 
because those features are simply not considered valuable enough to warrant 
keeping.

the latter is the overwhelming *minority* situation.

unfortunately, because people are attempting to analyze the situation without 
knowing what is the causal factors in each case they are ending up with 
incorrect generalizations that lead to incorrect arguments being made and 
people such as yourself getting annoyed without reason and then sharing that 
annoyance with us, the people writing the software.

which SUCKS!, imho ;)

> - which SUCKS!, imho. 

> It is always easier to
> take features out than to cram everything in and still make it work
> efficiently (while looking good).

ime, it's easy to remove features and it's easy to cram features in.

ime, it's hard to add features without making the whole thing an 
unmaintainable, unusable mess. and that's what we are trying to achieve. i 
hope you're providing patches to that end to some of the software.

what SUCKS!(tm) is that when we achieve "features while still making it work 
efficiently" people then complain that we've removed features. when you do a 
feature comparison, we find that isn't the case. yet people still complain. 
and by "people" i mean "people who used KDE1/2/3 and now are reacting in a 
knee-jerk fashion"

> To me, this adaption of the Win/Mac/GNOME attitude is a great loss to
> KDE. 

you're mistaken as to what we've adopted.

> Screwing the die-hard power users in favor of 'joe user' might not
> hurt the market share, but it surely raises averse emotions in some.

we aren't screwing the die-hard power users. you are doing yourself far too 
much of a kindness to say that all, or even most, die-hard power users like 
the kind of interfaces that were found throughout KDE3 software. 

i, btw, am a "die hard power user" (as are many of my close friends, some of 
whom use a Free O/S, many of whom do not (sadly :)) and do not count myself in 
your broad generalization.

as for raising emotions, i agree that it does. that some people choose to dump 
this on us is really an unfortunate choice (it results in nothing good) and is 
rather uncalled for: this is a technical project, not a pottery class.

> Alas, we seem to be in the minority so not much hope this direction will
> change.

but in the meantime, you can make everyone else's lives annoying and you can 
also ensure that we waste time and lose marketshare through such moaning and 
gnashing of teeth. how does that make any sense to you?

> > it at least doesn't match the stated purpose of these dialogs.
> 
> Well who cares about the intended purpose of the dialog

indeed, why shouldn't my bicycle also be an ice cream maker? how useful, as i 
often bike on hot sunny days.

> - if i see files
> anywhere, i *expect* to have the *freedom* of applying any file
> operation i might deem fit.

you have expectations that are unlikely to be fulfilled. we could put every 
possible operation someone might deem fit in there and then it would be an 
awesome tool to do anything ... except what it's actually meant for.

i invite you to eat your dinner for the next month with a swiss army knife. 
they sure are useful tools, but they make shitty day-to-day knives when the 
point of the tool is to actually cut your food.

of course, a dinner knife that doesn't have a handle or lacks a cutting edge 
is similarly useless.

and a dinner knife makes for a pretty survival tool.

it's about finding the right mix for the context.

> Not being able to do that always is a great
> cause of annoyance. See GTK file dialogs, for really bad example... ^^

we offer a lot more functionality, and more importantly sane arrangement of 
navigational systems, than gtk+ file dialogs do or have. nobody is interested 
in copying that approach.

btw, in kde3 could the file dialog change the size of the icons in the view? 
("humorously" the option is buried in the context menu in kde3, but it doesn't 
actually work!)

why did the kde3 file dialog have only two view types instead of the four we 
have now?

why didn't it show automatically in the sidebar very well (if at all)?

where were the file preview thumbnails?

why were the bookmarks in the sidebar not available from konqueror or the 
kmenu?

why couldn't you decide where the file name should be relative to the icon?

why wasn't there an 'Add new.." ability?

where was the option to have (the rather more efficient) breadcrumb widget?

why isn't "show hidden files" in the context menu?

why do the icons in the sidebar only have "small" or "large" as options 
instead of filling whatever space i give them?

why, when i view properties of a directory, don't i get a nice bar graph 
showing me the usage?

these are all things the kde 4 file dialog does that the kde 3 one doesn't or 
does much more poorly. 

why does a kde3 app always use the kde file dialog even when it's running on a 
completely different platform (preventing it from blending in with the rest of 
the environment)?

you know what i *can't* do in the kde4 one?

i can't always use F10 as a shortcut (this is a bug, not an intention feature; 
it's also a bug that came up a few times in kde3 and which i personally fixed 
once or twice; it's back :/)

i can't set folders to not be first in the sort order. (debatable; dolphin has 
it, but the file dialog doesn't; probably should be added back to the kde4 fie 
dialog, just haven't gotten to it)

i can't have a separate tree of folders to the side of the file list. this is 
intentional and perhaps the only feature i can see where there could be 
disagreement based on difference in tastes. i can tell you that not having it 
makes the code much more sane to maintain and when we asked around the users 
it wasn't a commonly used feature.

so, sum up the things the kde3 file dialog doesn't do (12). sum up what the 
kde4 one doesn't do (3, of which 1 is a bug, 1 is a feature not added yet but 
which almost certainly will and one that won't). compare. 

for a final score we could add in "which one looks less jumbled". but let's 
assume that we're talking only functionality and don't care about elegance.

winner is quite obviously the kde4 file dialog. to make this all the more 
ironic, this discussion is about a feature that kde3 didn't have either.

as such, i humbly submit that your measurements of the two file dialogs do not 
reflect reality nor do they match what our true goals are, namely: powerful 
software that is still maintainable and doesn't look like crap.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
[prev in list] [next in list] [prev in thread] [next in thread]