On Fri, Jul 24, 2009 at 2:31 PM, Martin Nordholts <enselic@xxxxxxxxx> wrote:
Actually, this is the key point of this discussion and IMHO the RIGHT WAY(TM) to solve this. Editing resources during use should not require write access. Saving the changes should. Use tweaking should be a different level action than actual editing. Its extremely annoying if use level tweaking messes up your resource. If there's quiet auto saving, that should go away. Edit action should be available for writable ones and Duplicate & edit(possibly a quiet one) for non-writable ones and should be different from tweaks you can save in tool presets.
Both solutions on the table suck now. Copying system resources to the user would create two copies, on a single user system. in a system with A LOT of users, like a large family, say 5 users, would multiply the resources 5 times and say the head of the family likes to install resources system wide so the family can just use them... Or a better case. Small business has a set of "corporate" resources they want to be available to all the users of the terminal server. Those resources can be quite big. Copying them is a bad idea.
Using tags to hide system brushes does not simply solve the problem of editing not writable resources.Hiding an edited system resource is pointless. However, using a Hide operation for any brush allowing user to organize his/her brushes and only offering delete for writable ones does solve the organization problem. If mass hide is possible, the issue of getting them out of the way is solved.
I think the time would be better spent making the resource tweaking independent from the writabillity of the resource than on either of those proposals(Tag to hide resources will be needed anyway if we want to auto-hide obsolete resources, so getting that done would be needed anyway).
On 07/24/2009 01:10 PM, Martin Nordholts wrote:I would like to add that if the ongoing brush dynamics and tool options
> As convinced you are that your approach is better than mine, I'm equally
> convinced my approach is better then yours.
redesign discussions end with a solution where editing of actual brush
files is not necessary, then this whole discussion is obsolete. But as
long as that file writability matters for resources, then what we have
now is broken and needs to be fixed somehow.
Actually, this is the key point of this discussion and IMHO the RIGHT WAY(TM) to solve this. Editing resources during use should not require write access. Saving the changes should. Use tweaking should be a different level action than actual editing. Its extremely annoying if use level tweaking messes up your resource. If there's quiet auto saving, that should go away. Edit action should be available for writable ones and Duplicate & edit(possibly a quiet one) for non-writable ones and should be different from tweaks you can save in tool presets.
Both solutions on the table suck now. Copying system resources to the user would create two copies, on a single user system. in a system with A LOT of users, like a large family, say 5 users, would multiply the resources 5 times and say the head of the family likes to install resources system wide so the family can just use them... Or a better case. Small business has a set of "corporate" resources they want to be available to all the users of the terminal server. Those resources can be quite big. Copying them is a bad idea.
Using tags to hide system brushes does not simply solve the problem of editing not writable resources.Hiding an edited system resource is pointless. However, using a Hide operation for any brush allowing user to organize his/her brushes and only offering delete for writable ones does solve the organization problem. If mass hide is possible, the issue of getting them out of the way is solved.
I think the time would be better spent making the resource tweaking independent from the writabillity of the resource than on either of those proposals(Tag to hide resources will be needed anyway if we want to auto-hide obsolete resources, so getting that done would be needed anyway).
--Alexia
_______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
