The Export spec should be augmented to handle an important usecase

View: New views
5 Messages — Rating Filter:   Alert me  

The Export spec should be augmented to handle an important usecase

by Omari Stephens-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

The spec is here:
http://gui.gimp.org/index.php/Save_%2B_export_specification#exporting_files

Quick version:
The default export path needs a settings switch for whether the original file
path (number 3) is higher-priority than the most-recently-used paths (numbers 1
and 2).  This would support the use-case where input and output files are
associated by directory, but you may open multiple input files at once.

Detailed version:
My photo-storage hierarchy looks like .../photos/(date)/(filenames).
Whenever I modify an image, I save it to .../photos/(date)/pp/(original
filename) — "pp" means "post-processed"

Now, I open two images in gimp from different dates using my image viewer.  I
edit them, and then try to save them.  The first one works fine.  When I go to
save the second file, however, I end up (by default) in a directory associated
with the first file.  Furthermore, because I was in the image viewer (and not
the command line), I often have _no idea_ what the directory is that I now need
to manually navigate to.

In the case where I open a couple (>=3) images in a row from different
directories, this means that I have to re-find the images in the image viewer,
mentally remember the directory names, then manually navigate to the appropriate
directories in the export dialog.  Suffice it to say, this is more of a
roadblock than a workflow.

On the other hand, there are other situations where I want all the photos to end
up in one place.  For instance, when I post-process photos for a blog post, they
will all end up in .../photos/pblog/(year-month)/(post title)/ .  Thus, it seems
like both ways of handling this default ([1, 2, 3] priority as well as [3, 1, 2]
priority) are viable and useful.  This is why I suggest having a setting to
switch between the behaviors.

--xsdg

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: The Export spec should be augmented to handle an important usecase

by Omari Stephens-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

UI powers that be: any ideas/status on this?

--xsdg
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: The Export spec should be augmented to handle an important usecase

by peter sikking :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Omari Stephens wrote:

> UI powers that be: any ideas/status on this?


having thought about it quite a bit, here are some jots:

as Omari pointed out himself, it is a tug of war of different
use cases and it depends on what just happens to be worked on,
what the right default is for any given user. what is right
may change a couple of times per hour of use.

any solution can only be in the Export file-dialog, I agree on that
with Tobias and other people who discussed this on irc.

I would like to have had some widgets in the file dialog that
not only navigated to alternative destination folders
(of imported file when there is one at all, of saved xcf if
there is one at all, does not need to be the case, right?) but also
set that as the 'default destination policy override'.

but it is impossible/the hack of the month to put widgets in
a gtk file dialog I was told. and I do not think it is worth it,
the hack of the month.

so the next best thing is for GIMP to populate the Places column
(also used in the 'Save in folder' pop-up), with:

dir of of the imported file that started this file (when there is one);
dir of last saved xcf of this file (when there is one)
last 5 dirs exported to (hell why not)

now I would like to know how these (dynamically) added Places
turn out in the dialog. then we can talk about 5 last dirs for Save...

     --ps

         founder + principal interaction architect
             man + machine interface works

         http://mmiworks.net/blog : on interaction architecture



_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: The Export spec should be augmented to handle an important usecase

by Liam R E Quin :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Sat, 2009-07-25 at 15:22 +0200, peter sikking wrote:
[...]
> but it is impossible/the hack of the month to put widgets in
> a gtk file dialog I was told. and I do not think it is worth it,
> the hack of the month.

It's only software... gtk+ could be changed, no?


--
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org www.advogato.org

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: The Export spec should be augmented to handle an important usecase

by Michael Natterer :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Sat, 2009-07-25 at 11:24 -0400, Liam R E Quin wrote:
> On Sat, 2009-07-25 at 15:22 +0200, peter sikking wrote:
> [...]
> > but it is impossible/the hack of the month to put widgets in
> > a gtk file dialog I was told. and I do not think it is worth it,
> > the hack of the month.
>
> It's only software... gtk+ could be changed, no?

The problem is not to put widgets into the GTK+ file dialog
(we are already doing this and there is API for it).

The problem is that these widgets live in another process
(in the plug-in), and cross-process embedding is not properly
supported on all platforms, and it's a hack, and and and...

Read: not worth it.

ciao,
--mitch


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer