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

[Pau Garcia i Quiles]

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:
>> Hello,
>>
>> Recently I have been adding some features to KSnapshot and I have
>> noticed the workflow is a bit counterintuitive in regards to:
>> - The behavior when you open KSnapshot (a snapshot is taken but it's
>> not available to Send To... actions)
>> - Archive naming and autoincrement, filename shown in the window
>> caption (sometimes the window caption makes you think the screenshot
>> has already been saved while it has not)
>>
>> If you are using 4.5.3 or older and wondering what is this "Send
>> To...": it's the new name for "Open With...". With the addition of
>> KIPI actions, "Open With..." made little sense for printing,
>> e-mailing, uploading to Facebook, etc
>>
>> Maybe it's me, maybe I don't grasp the current workflow, or maybe it
>> is broken. If you feel the 4.5.3 workflow is the right one, please
>> comment.
>>
>> The workflow I'm proposing introduces two fundamental changes:
>>
>> 1. Never show the proposed filename in the window caption because it
>> leads the user to think the screenshot has been automagically saved.
>> Instead, show "unsaved screenshot" when the picture has not been saved
>> yet, and keep the proposed filename internal for the Save As...
>> dialog.
>
> where is the evidence of this confusion? i think it's fine to append a
> notification of unsaved status (btw, take a look at KDialog::setCaption, it
> accepts a "modified" flag), but not showing the name at all? not sure there's
> any point to that.

The confusing part is this, in 'Saving' in my original mail:

3. After saving, window caption shows the new proposed filename and
preview window shows the preview for the just-saved screenshot. It no
longer says "[modified]" next to the filename.

It is absolutely counter-intuitive: if I'm being shown a filename and
it does not say 'modified', 'unsaved' or anything like that, user
would expect that file to be already saved. Yet that filename does not
exist at all.

BTW, the 'modified' flago of KDialog::setCaption was already being
used, that's exactly how "[modified]" was/is being shown

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
you type anything it shows "untitled [modified]", when you click "New
snapshot" KSnapshot will show "untitled [modified]". Same behavior.

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

Currently, once the user opens the image in say, Krita, the window
caption in Krita shows a filename ("myfile78.png"), which leads the
user to think picture was saved to a proper (i. e. it won't disappear
when I reboot) location. Losing data is undesirable, IMHO.

But maybe there is a way to call external applications (Krita, Gimp,
etc) without a file to open yet pass the picture and I don't know it?

> b) it's impossible to know which tools this will be appropriate for

Actually, I'm using a very simple heuristic:

* If it's a KIPI plugin, save to a temporary location because the
image won't be needed anymore when the KIPI plugin execution is done.

* If it's not a KIPI plugin, then it's a KService found via
ServiceTrader when looking for image/png handlers, or is "Another
application":
  - Service trader returns tools like Krita, KolourPaint, etc, which
look like "I'm gonna enhance/annotate my screenshot" to me, therefore
probably user wants to keep the image
  - If it's "Another application", then save, because we have no idea
what the user will do and it's always better to keep an unneeded image
than to reboot and find your picture (which you probably spent some
time editing) is no longer there.

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

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.

> 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 :-) I don't discard this, though. I'm
committing the new workflow tomorrow, let's see how people like it.

Thank you for your feedback.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)