RSS/Atom feed Twitter
Site is read-only, email is disabled

The Export spec should be augmented to handle an important usecase

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

6 of 6 messages available
Toggle history

Please log in to manage your subscriptions.

The Export spec should be augmented to handle an important usecase Omari Stephens 08 Jul 18:36
  The Export spec should be augmented to handle an important usecase Tobias Ellinghaus 08 Jul 20:37
  The Export spec should be augmented to handle an important usecase Omari Stephens 21 Jul 09:27
   The Export spec should be augmented to handle an important usecase peter sikking 25 Jul 15:22
    The Export spec should be augmented to handle an important usecase Liam R E Quin 25 Jul 17:24
     The Export spec should be augmented to handle an important usecase Michael Natterer 30 Jul 09:43
Omari Stephens
2009-07-08 18:36:47 UTC (over 15 years ago)

The Export spec should be augmented to handle an important usecase

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

Tobias Ellinghaus
2009-07-08 20:37:20 UTC (over 15 years ago)

The Export spec should be augmented to handle an important usecase

Am Mittwoch, 8. Juli 2009 schrub Omari Stephens:

[...]

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.

What about providing some kind of pre-populated drop down box in the export dialog with both alternatives, so you can quickly select one of those or just use the dialog the way it currently works.

The box could be filled like this:

If you select either one of the first two entries, that one becomes the default in subsequent exports. So if GIMP ships with and you export to , the next time you open the dialog it will default to .

To make the whole thing unobtrusive it could be reduced to a little triangle next to the path at the top of the dialog which gives the list when clicked. Well, I guess that's the way drop down boxes work. :-)

I hope this makes some kind of sense.

Tobias

Omari Stephens
2009-07-21 09:27:33 UTC (over 15 years ago)

The Export spec should be augmented to handle an important usecase

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

--xsdg

peter sikking
2009-07-25 15:22:36 UTC (over 15 years ago)

The Export spec should be augmented to handle an important usecase

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

Liam R E Quin
2009-07-25 17:24:06 UTC (over 15 years ago)

The Export spec should be augmented to handle an important usecase

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?

Michael Natterer
2009-07-30 09:43:37 UTC (over 15 years ago)

The Export spec should be augmented to handle an important usecase

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