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

[Marco Martin]

On Sunday 07 February 2010, marcel partap wrote:
> On 06/02/10 18:31, Marco Martin wrote:
> > or getting them lost in utterly meaningless details decreasing
> 
> Utterly meaningless details - like those the more button in transfer
> dialogs is hiding? (which btw uses more space)
> 
> > productivity, unless the passed months studying the interface. when
> 
> my proposal doesn't necessarily mean that most users will end up with a
> more complicated interface? it's just about trying to integrate
> functionality into the interface upstream and get it usable in complex
> form - slimming it down from there can hardly make it less usable.
> 
> > 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)
> 
> noise for some, pleasant feature for others. see reasoning below.
> 
> > an huge fields of mini buttons, switches and knobs can't be. end of
> > the challenge
> 
> Really? Then please xplain to me how THIS
> http://images.google.com/images?q=propellerheads+reason&imgsz=l
> can possibly accord with THIS
> http://www.google.com/search?hl=en&q="ease+of+use"+"ease+of+use"+propellerh
> eads+reason+-site:propellerheads.se ?

this is a professional tool targeted to a very defined niche of professionals: 
musicians, sound engineers etc.
It does one thing (even if a BIG "thing") and it does it well, but as a 
professional tool is almost 
impossible to use it without spending weeks trying to figure out what all that 
stuff does, or taking a formal trainig.

Now, most of KDE software is instead very generic. a file manager is not 
anywhere in the same category of Reason.

> > 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.
> 
> Well so might happen you (and many others) are, i (and possibly others)
> am not. The thing is, before the choice was there to please either side,
> now often there is no choice. Thanks for backing my criticism ;)

no thanks, i prefer something that has a bit of spinal chord even if i don't 
always agree the decisions made rather than something that couldn't decide 
anything by its own ;)

> >> 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
> 
> Of course it can be. With infinite time and resources, EVERYTHING can be
> accomplished ;)

apart from the fact that i don't believe that exactly everything is just a 
matter of resources, time and resources is exactly what we're lacking most :p

> > 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.
> 
> Although this is a factual risk, it does not have to be the case. There
> can be advanced configuration options managed by 'UI display profiles'
> that bring order into the chaos. And distributions could leverage them
> to 'ease down' the KDE interface for their target groups, feeding back
> the created 'UI display profiles' upstream.
> 
> > 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
> 
> But those settings correspond to variables. And why not leave the option
> to set them manually? Cleverly implementing the settings in a way that
> it is available but not in an obstrusive, cluttering way. Should have
> been the work area of the KDE usability group, but they seem to share
> the 80%/20% obsession - which corresponds to the 'drop the corner cases'
> mentality.
> 
> >> 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
> 
> As much as i can remember, kicker did all that in a much saner way.
> Haven't used it since years but still miss its coherence and plain
> usefullness.
> 
> > 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.
> 
> For you its useless, for others it's a means of _control_ over their
> desktop. If you don't strive to be in full control, great. But i am
> missing the option, because i mostly like having the panel visible, only
> sometimes i need the screen estate it takes.
> The current options leave a use case gap that wasn't there before,
> that's the point.

and is a really thin use case, vs "yes i want mys panel to be always there" or 
no.
besides, as Plasma is done by a bunch of small plugins, writing a panel 
containment with said arrow in it would be quite easy. If there are enough 
people that want it somebody could eventually come up with said panel.
still didn't seen it tough.

> > in trunk is quite different, the only way to make it less annoying
> > would be to not make notifications at all :)
> 
> ..i am on trunk since years and imho it's still ugly and not very
> usable. Maybe there's a branch aside from trunk where it's different
> that you are using, i don't know.

"ugly" is subjective
no, is just trunk and the difference is simply that now they will never ever 
take too much screen

> >> - still no LCD clock x)
> > 
> > this is look, not functionality, using a normal font gives you the
> > exact same info.
> 
> Functionality, yes, LCD clock, no. Of course it's trivial to write it
> and even i could probably do it within an hour or so, so yes i blame
> myself for not doing that. And no i've never looked for different
> plasmoids to do that because such a great and trivial feat should be in
> the base clock.
This is again very subjective.
Forcing a debatable option (because doesn't have real functionality) on 
everyone when is as you noted, is sooo easy to replace te clock altogeter 
doesn't make really sense.
In this sense, plasma is the most configurable thing ever existed, the fact is 
is not configurable in the same way tings were before, because was a way that 
led to overcomplicated and unmantainable things. Thre are totally different 
and crazily configurable taskbars, clocks and even a notification system out 
there, that are feasible -only- because __we don't have to maintain all of 
that stuff__

Third party plugins are really the only way to go if you want extreme 
configurability -and- simplicity

> Amongst other things like a font preview, and an APPLY
> BUTTON. I hereby promise to implement those things after my exams.

the apply button unfortunately isn't there not for some strange design 
decision, but for a bug that makes it not working.
If we'll be able to figure out something to fix it we'll be happy to give it 
back.

> >> 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
> 
> Misunderstanding. Because i dislike the new notifications, i have turned
> them off, and the 'traditional dialog' is what i am criticizing. Have a
> look at it and read my statement again, you'll see what i mean.

uh, the traditional dialog is perfectly resizable to accomodate any url there.
perhaps is a bug of an old revision?

> 
> > 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.
> 
> that's to broad a statement. Often it is about numerical variable
> values, or auto layout widgets. Also, code complexity can be tackled

those are usually the ones where is most avoidable to put specific ui for 
this, like icon sizes, but yeah, sometimes is necessary some hook somewhere to 
access it (probably most of the times only because nobody could think about an 
elegant enough solution to solve it ;)

> with proper in-code documentation (something especially core KDE lacks a
> bit imho) and diverging code paths should always be minimized by
> structural optimization anyways..

+1 here

> > i find really really hard to even remember that some or another option
> > exists at all, let alone maintaining it in a working state.
> 
> well maybe there should be a page on techbase to 'schedule things for
> restructerung' - and more in-code documentation. Last time i tried to
> dive into kwin's code and grok the inner drag-n-drop workings, i only
> narrowly escaped mad-cow-like mind alteration ^^
> 
> > here decision are been made, and poor decisions give poor quality, and
> > this indeed influences market share
> 
> yes but i guess aaron was more referring to my attempt of starting a
> flamewar ;)
> btw i didn't mean it that way, i'm just honestly worried about the
> usability dilution trend in KDE4.

yeah, on arguments where one is really passionate about is easy to sound "too" 
passionate at the point being silly, yes, both of us sounded a bit like that, 
but is an argument I'm really passionate,  we end up wanting the same thing, 
KDE being more useful and appealing.
It's the -how- to do so that unfortunately is a totally diverging path ;)

> > if it's called 'file open' there is a reason, maybe that you use it
> > for hmm, open files?
> 
> can't remember proposing the opposite, did i?
> 
> > yes, if it would have an hidden asteroids clone would be nice, but
> > defies its being a 'file open' dialog
> 
> not necessarily? if the option is hidden somewhere? That's really beside
> the point though of displaying file objects with same file capabilities
> everywhere.

well, about this point in particular, is the goal is "coherence of 
representation" of the same thing I think i can even agree on it, yes that 
patch in particular could make sense.
However, the file open dialog is not my baby, so i can at most give an advice 
or a patch, but will always respect what the mantainer decides, even if i 
disagree. this is a fundamental point for me ;)

>[...]
> 
> Yes, and there would be a simple solution to this problem: an option to
> never open files (even if they have an embeddable kpart) if opened from
> a file view.
>
> > 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.
> 
> Yes, and they certainly could all be solved there, one by one.

would be happy t be proven wrong, but no, most of them are really structural, 
solvable only by making the app behaving so much differently when in 
filemanager or web browser mode that there will no difference with having two 
separate applications.
if you go further you'll even have toolbars and other ui bits that change 
completely when you go from a web tab to a file tab. at this point is simpler 
to have a browser and a filemanager in the same window with kwin tabbing.

> > exactly a bug of "unmaintained feature" i was talking before, every
> > thing buried deep is doomed to become so
> 
> If it is undocumented and there is no better system to track
> deficiencies like this, yes. Maybe this example is not so much a reason
> to remove little-used functionality, but to document it better and have
> a more versatile tool of tracking TODO/FIXME aspects in the software?

documentation or not, fixme or not, sometimes different part just have an 
interaction between them that you didn't expect (yeah, software is complex, 
surprise) and you often end up that fixing a part breaks another

> >> 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 :)
> 
> Well i'm not even proposing it! But if it is as difficult to implement
> now, clearly there must be SOMETHING (i have no clue what) wrong!
> 
 I don't know that code either, but when you design a lblrary you always have 
the challenge to keep the design simple, comprehensible and maintainable vs 
the flexibility to be able to do anything you want.
If this one wasn't seen as a valid use case when designing it, because not 
felt useful or because is too complex for a very very little gain, as a result 
it becomes difficult to accomplish that use case with the given library.
It's sot something necessarily wrong, it's just hitting a corner case very 
hard, doing a quick cost/benefit reasoning, and then movin on.

> > 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"
> 
> But how does the result of studies that look at the ease of use for
> computer illiterates (or the 80% bulk) and repeatedly find: less UI
> elements = easier to use interfere with my argument that upstream KDE
> should also get a 'rich advanced UI mode' right, which can be reduced
> f.e. by 'UI profiles', which might be worked out by downstream distros?

problem with profiles is that n basic users use a diferent subsets s some of 
them will have to falback to the advanced mode anyways. i don't think "modes" 
are the way to go.
For some applicatios the key is third party plugins, with plasma is easy 
because all what you see is basically a plugin that can be pulled out and 
changed with what pleases you. For other applications this road won't be 
really feasile (and no, with our current technology an extreme approach like 
firefox wont be really feasible because it pretty much requires the whole ui 
to be written in xml+javascript ;))

What should be done everywhere is to identify what is really 
"functionality" opposed to cosmetic or slight different behavioural options.
Also distinguish what belongs to that type of app and what doesn't is 
important, i thik it's the reasonong also behind even very complex commercial 
tools, reason, for how complex it is, i guess it has only sond mnipulation, 
mixing and sequencing functionalities, i don't really expect to find an image 
editor in it.

Cheers,
Marco Martin