Unexpected multiple save actions behaviour

Bug #381091 reported by Nadia Alramli
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Phatch
Fix Released
Medium
Stani

Bug Description

If you add multiple save actions the resulting behaviour is unexpected.
Let's say I'm executing the following actionlist:

{'actions': [
             {'fields': {'In': u'<folder>_phatch1/<subfolder>'},
              'label': 'Save'},
             {'fields': {'In': u'<folder>_phatch2/<subfolder>'},
              'label': 'Save'},
             {'fields': {'In': u'<folder>_phatch3/<subfolder>'},
              'label': 'Save'}],
 'description': u'Describe here the action list.'}

The resulting images will be written to:
<folder>_phatch1/
<folder>_phatch2/phatch1/
<folder>_phatch2/phatch2/phatch1/

If you remove <subfolder> from paths the resulting images will be written to:
<folder>_phatch1/
<folder>_phatch2/
<folder>_phatch3/

After some debugging I think I know the cause of this behaviour. <subfolder> is calculated like this:
info[_t('subfolder')] = dirname[len(info[_t('folder')])+1:]

But when an image is saved, its location info (or dirname) changes to the new save location. After the first save the dirname becomes <folder>_phatch1/ and as a result subfolder will be phatch1

Revision history for this message
Stani (stani) wrote :

Good point!

Actually this is a design decision what to do with variables (such as width, height, folder, type, ...) during multiple saves. I've been thinking already about this during Phatch 0.1

I thought of three strategies:

1) keep old, prefix new
- keep the variables of the original source file with the original names
- add the variables with the prefix "new." to the newly saved files

2) prefix old, keep new
- store the variables of the original source file with the prefix "source.", "base." or "old."
- keep the variables of the original source file with the original names

3) index variables with suffix
- original variables gets suffix ".0"
- second saved file gets suffix ".1"
(of course variables without suffix are still valid and than we should decide if it is the latest or the first file)

Maybe my preference is 3, but I am curious to hear your opinions.

What do you expect when in one action list you save 3 times with different sizes in percentages (like for icons)? I think it needs to be of the last save otherwise features like text offset with % will be broken.

I'll post this issue to discuss it on our mailing list (Some patience, I'm just waiting for Robin to register).

Changed in phatch:
assignee: nobody → stani (stani)
importance: Undecided → Low
status: New → Confirmed
Stani (stani)
Changed in phatch:
importance: Low → Medium
Revision history for this message
radioking (radioking) wrote :

You could add a flag that sets variables "sticky", indicating that the reference-variable should be the one from initial image.

Additionally you could add a "chain"-flag. This way actions needing variables refreshed after every action get along.

Stani (stani)
summary: - unexpected multiple save actions behaviour
+ Unexpected multiple save actions behaviour
Revision history for this message
Stani (stani) wrote :

As this is a design decision, I want to leave it for the end. We could come back on this before releasing Phatch 0.2

Changed in phatch:
status: Confirmed → Triaged
Revision history for this message
Stani (stani) wrote :

I'll change the behaviour that phatch does not change the path variables. This makes everything 100% predictable. In case a filename is needed from a previous save action, they can be just copied and pasted from the fields anyway.

Changed in phatch:
status: Triaged → In Progress
Revision history for this message
Stani (stani) wrote :

Fix committed in bazaar. It will be available with next PPA update.

Changed in phatch:
status: In Progress → Fix Committed
Stani (stani)
Changed in phatch:
milestone: none → 0.2.1
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.