[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:       marcel partap <mpartap () gmx ! net>
Date:       2010-02-06 8:25:38
Message-ID: 4B6D2782.4020007 () gmx ! net
[Download RAW message or body]

On 03/02/10 06:47, Aaron J. Seigo wrote:
> 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
Might be. In this situation there are several options: drop advanced
feature, make it invisible by default, allow switching off.
I very strongly believe the last one is the best option. A great many of
people never crawl into advanced settings and sub-sub-menus. Exposing
functionality is a great way of providing opportunities for people to
leverage advanced features and increase productivity - and a huge
challenge to make it still usable. Making it hidden by default is of
course the easier path, which obviously is favored by most of the people
driving KDE4 forward.

> kde3 got it wrong too often.
Not so sure. When i started using it - it was a wonderful break from
windows. Almost every time i had an intuition about applying an
operation in a certain context, even while trying i discouraged myself
not to expect this from the software - only be to be pleasantly
surprised by the fact it indeed would work this way.
Can't nail it down to specifics, but with KDE4 this impression certainly
has reversed a good bit.

> where there have been lots of lacking features it's almost always
> been because things were being rewritten.
Fully aware of that. I'm following the SVN code since KDE4 beta times.

> 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.
Yes, and that was not the core point of my criticism. The attitude is
the problem.

> 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.
Might well be, but i have the impression that kde3's defaults often made
more sense to my usage pattern. In any way, very often there is no way
to customize the interface in a way it would best fit my wishes.

> 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.
I'm not a feature-facist - sometimes it makes sense to deprecate
functionality in favor of something better. The attitude with which the
software is being developed has a great influence on this though. Right
now, KDE's driven forward by people who want to make it 'easier to use'.
Of course that can't be considered an invalid motivation - and indeed i
appreciate very much that there are people who put great effort into
work on this important piece of free software. KDE3 development however
was driven by die-hard technologists scratching their own itch,
resulting in more 'advanced' UI decisions.
With KDE4, UI choices everywhere are made into the direction - less
crowded interface = better. And i simply disagree very strongly. IMHO
the design goal should be to expose as much information and
functionality as possible on the interface, while still keeping it sane
and usable. Accomplishing this is of course much harder than slimming
the interface down by hiding stuff.

Some examples of things gone wrong:
1) plasma panel
- the settings.. mode? is really, really ... weird
- usefulness still lacks behind kicker, despite all the plasmoids.. will
those little hide buttons ever be implemented?
- notification system is light years away from the (fan fiction) mockups
that have been put on kde-look several years ago, right now it's mainly
annoying
- still no LCD clock x)
2) transfer dialog
- surely information like the transfer rate is sooo advanced it HAS to
be hidden by an incredible aesthetic 'more' button.
- the default size is too small. no way to see the full URL. Instead of
wrapping it into multiple lines, it is blemished by an ellipsis, making
it impossible to simple copying it. The dialog can't be resized,
although i believe this has been fixed few days ago.
3) dolphin
- features implemented in a dolphin-only way, not shared with beloved
konqueror (yes i know its not intentional but a symptom of the
scratch-own-itch model.. still)

> 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.
Well i get your reasoning, but i know how FOSS works, and my annoyance
is purely about the attitude.

> ime, it's easy to remove features and it's easy to cram features in.
Of course it is easier to remove them, no? And getting a full-featured
AND usable GUI right upstream makes a lot more sense than leaving it to
individuals downstream to 'enrich' their UI, because it's simply less
likely to happen, which means wasted productivity potential.

> 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.
Making it an unmaintainable, unusable mess? oic that'd explain..
just kiddin ;-p

> i hope you're providing patches to that end to some of the software.
i would love to because i often have ideas how to improve this and that
and i know it would be the right way to do it myself. Unfortunately, i
lack time, coding skill and discipline to do so, which i am very
dissatisfied with, but...

> what SUCKS!(tm) is that when we achieve "features while still making
> it work efficiently" people then complain that we've removed
> features.
'Course complaining sucks, on both ends.

> 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"
i don't know what a knee-jerk is, but i hope i have made at least my
subjective reasoning a bit clearer.

> 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.
Well of course i mean those who do. Back in the time, those were a
bigger fraction of the kde user herd. Naturally, the user base has grown 
and typical user requirements have shifted. But imho it is harder to 
make a usable interface with all the features exposed and lightening the 
UI from there is a downhill battle... The approach taken is showing the 
negligence towards these users.

> 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.
If you prefer simplistic interfaces over advanced ones, you are not part
of the group i was labeling 'die hard power users'. Of course i have to
admit 'people who prefer advanced over simple UI' would have been a
better term to choose.

> 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
Well i was not trying to dump emotions, but rather inform about the fact
the situation is causing emotions, and why. No offense intended, at all.
If anyone is feeling flouted, please accept my apology.
> rather uncalled for: this is a technical project, not a pottery
> class.
I don't get the remark but i have no reason to contradict this
statement, l0ol ;)

> but in the meantime, you can make everyone else's lives annoying and
Like the millions of people that read kde-core-devel..
> also ensure that we waste time and lose marketshare through such
> moaning and gnashing of teeth. how does that make any sense to you?
Well, of course simply pouring blame is not my intention, but to
contribute my own perspective and criticism of how things are currently
running in order to steer up creative flux. And sorry, kde-core-devel 
threads having a direct influence on 'market share' is purely fictional.

>>> 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.
Taken my statement out of context, your pun might make sense. But i was
specifically referring to the situation: we have a 'file open' dialog,
intended purpose is to choose a file for opening. So should that be the
only possible operation? Should the file objects that are displayed have
less capabilities than in a pure file browser? Don't think so.
Even windows doesn't do that (while gnome goes over the top with it).

>> - 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.
Obviously if it is unfit for the purpose, it would simply be
unacceptable. How does providing a fully operational context menu in
file dialogs qualify for that?
The UI should expose all functions related to the intended purpose - but
still allow (i.e. via a contect menu) other operations which are not
directly visible. No rename/delete/move buttons in a 'file open' dialog 
- of course not!

> 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.
Well why would i use an unfit tool? I certainly wouldn't mind however if
my normal fork and knife would have extra features, *as long as they
don't interfere with the main purpose of the tool*.

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

> 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.
Yes, very much so. But why can i not cut, rename, copy a file while
within the file open dialog? How does excluding this functionality help
the usability of this dialog?
How does putting a more button into transfer dialogs which hides the
number of objects being operated on help usability?


> 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!)
Ah well so there's a bug in KDE3 and KDE4 does it much better, GREAT.
Doesn't improve on what KDE4 is not so good at.

> 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.
Very good! Am i supposed to write things that work and look great in an
email if i want to criticize something? Yes experience shows playing 
nice might open the gates for criticism but this, as you have stated 
before, is a technical project and we should be able to have an 
objective discussion about the software without such social engineering 
tactics.

> 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)?
Actually, as you have just made clear, the new file dialogs are so good
that one might not want this behaviour. I reckon this integration can be
turned off by an appropriate setting, right?

> you know what i *can't* do in the kde4 one?
nah.. actually, despite the impaired context menu, i'm quite pleased
with its current status!

> 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 :/)
eek zombie bug ;)

> 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)
never missed it but will appreciate whenever it gets in
> 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.
The detailed tree view's not bad for that, however i see why one would
like to have a distinct folder tree. If it is hard to implement now,
maybe the related interfaces can be improved so that it gets easier.

> 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.
What's this? How does excelling at most things improve what one fails at?

> 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.
Why would we compare scores, when it's about specific bits of
functionality? This code is not a democratic system, in which you do
exactly that: compare accumulated scores. We have more flexibility than
that. (BTW that's why i believe the open source approach would provide a 
much better political mechanism than elections.. but that's OT ;)

> 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.
So what's all the fuss about? Where did i state that i want back KDE3's
file dialog? The only thing i want back from KDE3 is kicker ^^

> as such, i humbly submit that your measurements of the two file
> dialogs do not reflect reality
My intention never was such a useless comparison. Might be that my
generalization "the biggest strength of KDE3: provide all possible
functionality everywhere plausible" was a bit too broad if the KDE3 file
dialog indeed didn't allow to rename files. Simply can't remember though.

> nor do they match what our true goals are, namely: powerful software
> that is still maintainable and doesn't look like crap.
Fully in line with what i think should be done. The issue is your
definition of 'looking like crap'. Who in his right mind would demand
that software looks like crap. But i don't think a software that exposes
(most of) its available functionality meets that definition - as long as
care is taken to keep it usable.

best regards,
marcel.
[prev in list] [next in list] [prev in thread] [next in thread]