Review Request: Add "Open With" actions to KFileDialog context menu [via KDirOperator]
Aaron J. Seigo
aseigo at kde.org
Wed Feb 3 05:47:43 GMT 2010
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
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
> To me, this adaption of the Win/Mac/GNOME attitude is a great loss to
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
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
why did the kde3 file dialog have only two view types instead of the four we
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
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
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
More information about the kde-core-devel