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

[Aaron J. Seigo]

On Monday, November 15, 2010, Pau Garcia i Quiles wrote:
> On Mon, Nov 15, 2010 at 10:24 AM, Cyrille Berger Skott
> 
> <cberger at cberger.net> wrote:
> > On Sunday 14 November 2010, Aaron J. Seigo wrote:
> >> 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.
> > 
> > Would it be possible to save it as read-only ?
> 
> Do you mean saving as 0400 when saving to /tmp/kde-$login? Sure, it's
> a possibility and looks like a good idea.

experience from similar behaviour with email attachments and kmail says this 
is highly annoying, and if it can be avoided that would be great..

> The attached patch to trunk implements my proposal (it does not do
> Cyrille's read-only yet) . Given Aaron's reaction, I'm not committing
> it.
> 
> Aaron, could you please elaborate on what you suggest? I do not really
> understand when you propose to save the screenshot,

> what filename to
> show on the window caption and when to show "[modified]".

* show [modified] when it isn't saved. this is consistent with every other app 
out there.

* show the filename as it is now; i really don't think anyone gets confused 
that it has been saved immediately after ksnapshot is started just because 
there is a name on the window. that caption does help communicate what it 
would get named by default, however

> Something
> like my original message but with your workflow would be nice.
> Currently KSnapshot is, IMHO, broken and totally unintuitive and I'd
> like it to be fixed for 4.6.

repeating that doesn't change the truth of it. :) i understand you feel it is 
broken. i don't. i don't think that the window caption is, in the least, 
anything that needs touching.

what could be improved is the autosave handling when passing the image off to 
another application. it is quite impossible to know whether the application 
benefits from having the file in a location the user can find easily again or 
not. the application could, for instance, simply be a script that uploads to 
flickr, in which case it's like any of the kipi plugins. so trying to get 
clever and have different behaviours is just going to lead to inconsistency 
(sometimes it does A (e.g. if it's a kipi plugin), sometimes it does B (e.g. 
if it is an application) without always getting it "right" anyways.

moreover, if the work flow is different based on something like "it's a kipi 
plugin or not" many/most users will simply not get why (implementation 
differences like "this is a plugin, this is an executable" are details that 
most are unaware of; try explaining it to average users sometime). this will 
lead to ksnapshot feeling "unreliable" or "confusing", exactly what you are 
trying to make it not :)

i also don't want to see a file dialog in the work flow, otherwise there is 
_no point_ to the "open with" shortcut feature: it's hardly any faster at that 
point.

what needs to be asked is what part of that worflow is failing and _why_. if 
the issue is that it is hard to find the file after the user is done 
manipulating it, one then needs to ask  if that is because:

* it is stored in a strange location (e.g. tmp)
* any location that isn't explicitly stated the user will be unfindable

note that applications, such as krita, do let you see where the file is being 
saved to. it may be enough to simply autosave the snapshot into the user's 
home dir, e.g. into the Pictures directory.

still, i'm not even sure where this "it's confusing and broken" is coming 
from. do we have bug reports about this? user studies?

-- 
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/20101115/5be2d353/attachment.sig