On Fri, Jul 24, 2009 at 2:31 PM, Martin Nordholts <ense...@gmail.com> wrote:
> On 07/24/2009 01:10 PM, Martin Nordholts wrote:
> > As convinced you are that your approach is better than mine, I'm equally
> > convinced my approach is better then yours.
> I would like to add that if the ongoing brush dynamics and tool options
> 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
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).
Gimp-developer mailing list