[Kde-graphics-devel] Re: KSnapshot filenames workflow

[Aaron J. Seigo]

On Sunday, November 14, 2010, Pau Garcia i Quiles wrote:
> On Sun, Nov 14, 2010 at 9:37 AM, Aaron J. Seigo <aseigo at kde.org> wrote:
> > On Wednesday, November 10, 2010, Pau Garcia i Quiles wrote:

> Regarding not showing the name at all, that's exactly the same
> behavior every other application in KDE (and any other operating
> system I know) behaves: when you create a new document in Krita,
> KWord, Kate, etc, there is no filename in the window caption because
> you have not saved yet. I am just adopting the same workflow in
> KSnapshot: when you take a new screenshot, it's like your clicking
> "New" in Kate; Kate shows "untitled" at the window caption and when

people who use ksnapshot tend to use it for the same thing repeatedly. the 
reason for picking _the same name_ and showing it _in the window title_ is 
based on _common usage_. reverting that is only going to put us back to where 
we were years ago. don't.

this is a prime example of the "wisdom" of the new contributor against the 
real wisdom of the long term maintainer. one is based on pure, but ephemeral, 
logic and the other is based on what people really, actually do.

> >> 2. When Send To... implies an action which only needs the file
> >> temporarily (for instance, KIPI plugins: e-mail, upload to Facebook,
> >> print, etc), save to /tmp (same as now). When Send To... is for a
> >> permanent storage (for instance: edit with Krita, edit with
> >> KolourPaint, etc), ask the user to save the file to some place, to
> >> make sure he knows where to look for next week.
> > 
> > a) that's the job of the tool that opens the image
> 
> In order to open the screenshot, you need to save it to a file and
> pass the filename to the tool that opens the image.

obviously, and i provided a medium solution to that.

> > b) it's impossible to know which tools this will be appropriate for
> 
> Actually, I'm using a very simple heuristic:

which is completely meaningless because it relies on internall knowledge. to 
the general user a "kipi plugin" and an "executable" are indistinguishable. 
such a "simple huristic" is complete black magic to the average user. as such, 
it is a mistake.

> > c) this would render the biggest benefit of the feature, namely a quick,
> > easy and no-interuption mechanism to get to editting the file, moot
> 
> In my opinión, a quick "save as" dialog when you are going to use a
> tool in which you are going to spend some time is not too cumbersome.

and you are wrong. every interuption shown the user is a burden. this is not a 
debatable point, but a fact of usability. 

> In any case, you can just press 'q' (quick save), then Send To...
> Krita. Screenshot will be saved to permanent storage and no 'save as
> dialog' will be shown.

all of which is a series of hidden features, which means it is a workflow 
based not on common usage but expert usage. both can coexist, but expert usage 
must NEVER make common usage worse. which is what you are suggesting.

> > if the issue is that people are losing the image because it's in a temp
> > dir somewhere, then just autosave it to a sensible location (e.g. the
> > "images" directory set for the session) with a unique name.
> 
> I don't really like that. If KSnapshot saved every screenshot I take
> and upload it to facebook, send it via e-mail, etc, I'd need a 2 TB
> drive only for screenshots :-) 

you need to realize that you are the exception, not the norm. designing for 
the ecxeption makes our software suck for just about everyone.

> I don't discard this, though. I'm
> committing the new workflow tomorrow, let's see how people like it.

as one of the 2 maintainers of ksnapshot, let me say: please don't

more pointedly, if you commit it, i will, with matainer's rights, simply 
revert it.

let's work towards consensus rather than "commit becasue i can".

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-graphics-devel/attachments/20101114/0964d4ee/attachment.sig