Review Request: Add "Open With" actions to KFileDialog context menu [via KDirOperator]

[Marco Martin]

On Sat, Feb 6, 2010 at 9:25 AM, marcel partap <mpartap at gmx.net> wrote:
> 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

or getting them lost in utterly meaningless details decreasing
productivity, unless the passed months studying the interface. when
the exposed functionality is visually invisible and when is -real-
functionality, when is a choice between almost identical features with
a slightly different behavior, is just noise. example? you mention one
here! (see below about panel arrow buttons)

> challenge to make it still usable. Making it hidden by default is of

an huge fields of mini buttons, switches and knobs can't be. end of
the challenge

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

i liked kde3, but it always lacked style, decision and personality.
couldn't decide between two almost identical way to do something? just
put a configuration option! and yes, kde4 reversed this trend a bit
and i'm sooo happy about that.

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

this is unfortunate, but at the same time can't be avoided. the wished
off 100 people are different to each other, and is almost impossible
to be able to make options to accomodate everyone, is just the typical
solution to make everyone happy, that in the end makes almost nobody
really happy, giving something that is really clonky to everybody.

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

there are features that don't need UI at all, we must try to indentify
all of those, and eliminate all the ui that is in fact redundant.
example? size of anything, windows, panels, icons...
no need at all to have windows where you putpixel sizes, just resize
the darn thing. like the size of Dolphin sidebar icons.

>
> Some examples of things gone wrong:
> 1) plasma panel
> - the settings.. mode? is really, really ... weird

yes, is still not executed in the best way, but is exactly trying to
accomplish that, to reorder applets, just drag them around, to add a
new one just drop one here, to resize the panel, drag some kind of
handle, if it has a problem, its weirdness is in the sense that there
is still too much chrome.

> - usefulness still lacks behind kicker, despite all the plasmoids.. will
> those little hide buttons ever be implemented?

this is the exact example i was talking about about redundant
features. that arrow button was used to hide the panel, to save screen
space.
we can do that already, there is "autohide" and "windows can cover".
I agree that they are indeed different things. but they are just
different ways to achieve the same thing.
The way with the little arrows is a "manual" one, that adds an useless
level of interaction more over a normal autohide panel.
> - 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

in trunk is quite different, the only way to make it less annoying
would be to not make notifications at all :)

> - still no LCD clock x)

this is look, not functionality, using a normal font gives you the
exact same info.
giving how easy is to write a widget and how many third party ones are
on kdelook if there is not an lcd clock (i don't know, maybe there
could be one) means that wasn't imporant enough and we did indeed a
good thing to dump it.

> 2) transfer dialog
> - surely information like the transfer rate is sooo advanced it HAS to
> be hidden by an incredible aesthetic 'more' button.
this is where there is still configurability, you can have the old
individual dialogs if you want

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

remove complexity without removing too much functionality is terribly hard

> 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

again rich ui != functionality

> 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

of course it is.
a configuration option means two different code paths that will have
to be separately maintained, otherwise it's granted that the non
default ones will break.
i find really really hard to even remember that some or another option
exists at all, let alone maintaining it in a working state.
if among developers there is nobody that wants to actually -use- and
keep working a given feature really shouldn't be there. (we learned
our own lesson with different activities for each virtual desktop, was
one of the most asked features, got in, but now is one of the major
pains to keep sane)

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

here decision are been made, and poor decisions give poor quality, and
this indeed influences market share

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

if it's called 'file open' there is a reason, maybe that you use it
for hmm, open files?
yes, if it would have an hidden asteroids clone would be nice, but
defies its being a 'file open' dialog

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

well, a swiss army knife to be as portable and as versatile had to do
some tough choices.. so the knife and fork are too little, too short
handle but too fat because it has to keep the other tools...
how it transposes in our software? take konqueror...
in a web browser if i click over an image i want to simply open the
image without having to leave the browser window, because right now
i'm reading a document..
a file manager however is a totally different tool, when i'm using it
i'm not "reading a document" so if i click on a file i expect it will
be opened in a suitable app, either to be viewed or edited, depending
to the type of file, and a web browser behaviour, trying to embed a
preview, is simply deadly annoying there.
there are dozens of this little annoyances in konqueror due to its
attempt to be a web browser, a file manager and an universal previewer
all in one 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.

exactly a bug of "unmaintained feature" i was talking before, every
thing buried deep is doomed to become so

>> 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
> [...]
>> 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 scrapping and redesigning an enormous piece of code just to put a
feature that has very little, if any gain? great priorities :)

>> 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 and is not democratic also because if there is nobody willing
to mantain a piece of code it won't get in, no matter how many people
want it :)

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

wouldn't work, because mayority of people don't have the foss guy
mentality, but is indeeed, 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.

if you ignore all the studies and listen only to you personal opinions, yes.
if you can come up with something like what you say and -validate- it
by doing real testing great, would be an extraordinary achievement,
but until then, we can only follow the most accepted canon of "not
looking like crap" to make it not "looking like crap"

Cheers,
Marco Martin