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

[marcel partap]

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"+propellerheads+reason+-site:propellerheads.se
?


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

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

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

>> - 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. Amongst other things like a font preview, and an APPLY 
BUTTON. I hereby promise to implement those things after my exams.

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

>>> 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
yes you're somewhat right, but complexity wasn't the subject in that 
statement.

> again rich ui != functionality
no, most times the functionality is there.
rich ui = feature accessibility

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

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

> 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, 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...
As i tried to emphasize before, i am NOT proposing to compromise on the 
main use case / 80% usage pattern, But there is a hell lot of space to 
allow more advanced UI interacting without doing that.

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

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

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

> 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 :)
Well someone has to CODE it, that's much more of a hurdle. And the next 
hurdle is for maintenance: poorly documented contributed code.

>> 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 :)
Not needed, majority of computer users does not have FOSS mentality and 
it still works. But yes, OT 8p

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

regards, marcel..