Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

[Aurimas Juška]

On Jan 17, 2008 7:45 PM, William Skaggs <[EMAIL PROTECTED]> wrote:
>
> 2) If they are stored in a separate database, keyed by file
> names, then there is a great danger of losing the linkage
> between tags and object.  If, for example, the user renames
> the directory holding some brushes, all of the tags for those
> brushes will be lost.  The only way to prevent this sort of
> thing from happening is to make sure that all operations
> on resource files are mediated by Gimp (or some new
> utility program) that will make sure to keep the tags in
> sync with the data files.  If for some reason a user's tags
> database gets corrupted, it will be a major disaster.
>
I don't see any disaster. Here is one possible solution: store some
sort of checksum (let's say, MD5) together with filename in the
database.
Let's say user renames file. If new filename is found with the same
checksum, simply change the filename in database and that's it -
you've got completely correct database once again.
This could be a little more tricky at runtime (scan in background?),
but not a disaster, really.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

[William Skaggs]

From: peter sikking [EMAIL PROTECTED]

> chiming in here (getting back to speed). [...]

Peter!  Great to hear from you again!

I absolutely agree about the virtues of a tagging system, but
I fear that the difficulties are not being appreciated well enough.
Here, for example, is just one of the problems:

Problem: should tags be stored as part of a data file, or in a
separate tags-database?

1) If they are stored as part of the data file, then this calls for
a new file format for every sort of gimp resource object, and 
changing tags calls for file system operations.

2) If they are stored in a separate database, keyed by file
names, then there is a great danger of losing the linkage 
between tags and object.  If, for example, the user renames
the directory holding some brushes, all of the tags for those
brushes will be lost.  The only way to prevent this sort of
thing from happening is to make sure that all operations
on resource files are mediated by Gimp (or some new
utility program) that will make sure to keep the tags in
sync with the data files.  If for some reason a user's tags
database gets corrupted, it will be a major disaster.

There are many other issues of the same sort, which I don't
believe have been thought through.

The bottom line is that introducing tag-based resource
organization is like setting up a virtual, non-hierarchical
file system.  The ordinary file system may be weak in
comparison, but it is extremely robust, and users know
how to manipulate it.  A new tag-based file system can't
possibly be robust until it has had an extensive testing
period, and therefore exposes a user to the worst of all
disasters:  a corrupted file system.

The solution I favor is to build a tag-based system *on
top of* a filesystem-based system.  That way:

1) The tag-based system can be built gradually, instead
of being imposed all at once on a flat set of files.

2) The user can manipulate files using ordinary filesystem
operations without fear of wrecking gimp.

3)  A naive user who doesn't understand tags will still be
able to use Gimp without having to learn about tags at
the very beginning.

4) A corrupted tags database will still be very bad, but won't
make Gimp completely unusable.

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

Re: [Gimp-developer] proposal for managing resources such as brushes , gradients, etc

[peter sikking]

Scott wrote:

> The whole
> 'tags' idea is fine too, but if I understand what is being said there
> would only be one tag per brush.

nah, that is the same as sticking them in folders.
the power of tags is that you can associate as many
concepts with a resource as you like. and find it
back via as many ways.

 --ps

 founder + principal interaction architect
 man + machine interface works

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



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

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

[Scott]

On Thu, Jan 17, 2008 at 05:39:29PM +0100, peter sikking wrote:
> There are some traits that make Bill's idea obsolete. First one
> is the hierarchical organisation of resources. A tagging system
> allows multiple ways to find a resource again (instead of a unique
> one) by attaching many different properties to it (a single brush
> can be: small, ragged, subtle, project XYZ, project ABC, old skool).
> And this can only encourage reuse of a resource.

Okay, if there are multiple tags enabled, that is great! Just call one
of them 'workspace' if you want. Just so long as there is an easy way
to set/unset a tag, both by browsing the whole set, or by just
browsing within a tag. And a nice way of selecting the current tag,
possibly with unions (all of the project ABC tags plus all of the old
skool tags that aren't already included in ABC, plus the subtle tags
that are in XYZ minus the subtle tags in ABC...) - then if the
selection could be given a new 'project DEF' tag. I drool.

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

Re: [Gimp-developer] proposal for managing resources such as brushes , gradients, etc

[Scott]

On Thu, Jan 17, 2008 at 08:37:34AM +0100, Sven Neumann wrote:
> 
> > And, to repeat, even if there is tags support, there must be,
> > at least from the user's point of view, something like a workspace --
> > a set of brushes that are immediately available.
> 
> Sure. That is the set of brushes that match the currently selected tag.
> That would be the name of the project you are currently working on, or a
> category that describes the kind of brushes that are currently needed.
> 

As a user, I have been following this thread with interest. The
workspace idea certainly made a great deal of sense to me. The whole
'tags' idea is fine too, but if I understand what is being said there
would only be one tag per brush. So say I have a set of brushes I have
tagged as 'funky', another one as 'staid', another as 'workhorse'. But
maybe the project I am currently working on wants one from each
category. So, using the tags, I pick the 'funky' one I want, then the
'staid' one, maybe two 'workhorses', etc. and move (link, copy) them
into the workspace, where they are instantly available during the
duration of the project. Done with the project, delete the workspace
(or just some of its brushes, depending), start on the next one. I
don't know anything about gimp programming, but I can't imagine this
would involve extra fs-access as was mentioned as a negative; wouldn't
the workspace just consist of pointers to the actual brushes?

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

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

[peter sikking]

Hi all,

chiming in here (getting back to speed).

There are some traits that make Bill's idea obsolete. First one
is the hierarchical organisation of resources. A tagging system
allows multiple ways to find a resource again (instead of a unique
one) by attaching many different properties to it (a single brush
can be: small, ragged, subtle, project XYZ, project ABC, old skool).
And this can only encourage reuse of a resource.

see:  topic 6. organise brushes, palettes, gradients in  
categories.

Also, having to 'tank' the resources in and out of the "workspace" is
a  waste of time, especially if you do 5 or more different graphics
jobs in a single day. Architecturally it feels a thousand times better
to have 'zero-conf': all the resources (say brushes) are 'just there',
and click a few tags (that match your needs) to narrow that down to
the dozen or so to start working.

Also the mentioning of both the file system and the preferences
(aka. the graveyard of any good idea) makes that a couple of
alarm bells go off here. There is no need for that.

William Skaggs wrote:

> Here is the idea:
>
> 1) You have a "workspace", holding the brushes that you are currently
>interested in using.  The brushes shown in Gimp's brush picker are
>those that belong to the workspace.  The user has complete control
>over the contents of the workspace -- anything in it can be edited
>or deleted.  The workspace is saved from session to session, and
>automatically loaded at startup.
>
> 2) You have a set of extra folders, specified in Preferences.  The
>brushes in these folders don't automatically belong to the
>workspace.  To get at them, you invoke a Brush Chooser, which pops
>up showing a list of brush folders, and a view, which can be either
>a list or a grid.  Clicking on a folder causes the contents to be
>displayed in the view.  Double-clicking on a brush in the view
>causes it to be loaded into the workspace.  Once a brush has been
>loaded into the workspace, it stays there until you delete it.
>
> 3) You can also use the Chooser to save a brush from the workspace
>into the currently selected folder, assuming you have write
>permission there.


 --ps

 founder + principal interaction architect
 man + machine interface works

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



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

Re: [Gimp-developer] proposal for managing resources such as brushes , gradients, etc

[Devin Watson]

I'm sorry to jump in on this so late.  I was working on a new GIMP 
Plug-In Registry.  It had been put on pause by me because of certain 
life-altering events. 

At one point I had put forward the idea of a backend XML-RPC or SOAP 
connectivity service that would allow GIMP to access the repository data 
sources and use it for direct installation of the resources within the 
Plug-In Registry.  I envisioned something like a Plug-In Explorer 
interface in GIMP that would facilitate search and automated installation.

If this is still a viable idea, let me know.  I would love to jump 
back in and finish a new GIMP Plug-In Registry and also do this.  I 
think this would give GIMP a very powerful leg up in adoption by the masses.

___
Best Regards,

Devin Watson



Sven Neumann wrote:
> Hi,
>
> On Thu, 2008-01-17 at 01:50 +, William Skaggs wrote:
>
>   
>> These are interesting ideas, but they are fantasies at this point.
>> The whole tags thing is a fantasy at this point.  There is no
>> infrastructure in Gimp to support it, so everything would have
>> to be written from scratch.  That's months of work for somebody
>> with strong Gimp skills, even if a complete specification existed,
>> which is not the case.  Who is going to do it?
>> 
>
> There is a lot of infrastructure for this already. If someone wants to
> start working on this, just let me know and I will take my time to
> explain what needs to be done. I might even get to it myself.
>
> Even though the current development cycle is already quite far along, we
> could still get the infrastructure for tags implemented along with
> on-demand loading of data files. That would allow us to do the changes
> to the user interface as soon as 2.6 is released.
>
>   
>> And, to repeat, even if there is tags support, there must be,
>> at least from the user's point of view, something like a workspace --
>> a set of brushes that are immediately available.
>> 
>
> Sure. That is the set of brushes that match the currently selected tag.
> That would be the name of the project you are currently working on, or a
> category that describes the kind of brushes that are currently needed.
>
>
> Sven
>
>
> ___
> Gimp-developer mailing list
> Gimp-developer@lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
>
>
>   
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] proposal for managing resources such as brushes , gradients, etc

[Sven Neumann]

Hi,

On Thu, 2008-01-17 at 01:50 +, William Skaggs wrote:

> These are interesting ideas, but they are fantasies at this point.
> The whole tags thing is a fantasy at this point.  There is no
> infrastructure in Gimp to support it, so everything would have
> to be written from scratch.  That's months of work for somebody
> with strong Gimp skills, even if a complete specification existed,
> which is not the case.  Who is going to do it?

There is a lot of infrastructure for this already. If someone wants to
start working on this, just let me know and I will take my time to
explain what needs to be done. I might even get to it myself.

Even though the current development cycle is already quite far along, we
could still get the infrastructure for tags implemented along with
on-demand loading of data files. That would allow us to do the changes
to the user interface as soon as 2.6 is released.

> And, to repeat, even if there is tags support, there must be,
> at least from the user's point of view, something like a workspace --
> a set of brushes that are immediately available.

Sure. That is the set of brushes that match the currently selected tag.
That would be the name of the project you are currently working on, or a
category that describes the kind of brushes that are currently needed.


Sven


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

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

[Sven Neumann]

Hi,

On Wed, 2008-01-16 at 20:42 +, William Skaggs wrote:

> This mixes together two separate issues.

No, it doesn't. Absolutely not.

> Tags are, as I have already agreed,
> an excellent way of doing a search mechanism.  They don't get rid of the
> need to have a workspace, though.  Suppose I want to switch back and
> forth between five very different brushes.  Must I remember and select
> a set of tags each time I switch?  That would be very unpleasant.

You don't need a set of tags, you need exactly one tag. That is not more
information than you need to remember and select with your approach.
Still tags are a lot more elegant, simpler to implement and it
eliminates the need for storing duplicate files and for doing file
system operations.


Sven


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

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

[William Skaggs]

From: Sven Neumann [EMAIL PROTECTED]

> Right. We have discussed this in the past and we have come up with a
> simple and IMO very good solution that has several advantages over the
> approach that you are suggesting now. The solution is to allow tags to
> be assigned to data files. This allows the same data file to show up in
> several categories and it makes it easy to search for certain files.
> This is also the solution that is approved by the UI team. Please, by
> all means, let's not introduce something as obsolete as the system that
> you are suggesting now.

This mixes together two separate issues.  Tags are, as I have already agreed,
an excellent way of doing a search mechanism.  They don't get rid of the
need to have a workspace, though.  Suppose I want to switch back and
forth between five very different brushes.  Must I remember and select
a set of tags each time I switch?  That would be very unpleasant.  No,
whether or not there is a tag-based search system, there still needs to
be a way for the user to maintain a workspace holding a limited set of
arbitrarily chosen brushes.

  -- Bill


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

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

[Sven Neumann]

Hi,

On Wed, 2008-01-16 at 17:03 +, William Skaggs wrote:

> This problem has been discussed several times in the past, and
> proposals have been made about how to address it.  I have been
> thinking about it recently, and have come up with a somewhat
> different, and I believe simpler approach, which I have begun to study
> experimentally.

Right. We have discussed this in the past and we have come up with a
simple and IMO very good solution that has several advantages over the
approach that you are suggesting now. The solution is to allow tags to
be assigned to data files. This allows the same data file to show up in
several categories and it makes it easy to search for certain files.
This is also the solution that is approved by the UI team. Please, by
all means, let's not introduce something as obsolete as the system that
you are suggesting now.


Sven


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

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

[William Skaggs]

From: Akkana Peck [EMAIL PROTECTED]

> You didn't mention fonts, but your idea would work equally well for
> managing an unweildy list of fonts. If there was a way to add
> hierarchies into the workspace, we could even solve the much-
> discussed problem of font categorization (these are my script
> fonts, these are my cartoon fonts, ...)

I don't know how hard it would be to do something like this for
fonts.  There are some important differences between the way
Gimp handles fonts internally, versus things like brushes and gradients.

Concerning hierarchies, I think it would probably be a bad idea to 
have them in the *workspace*, where the whole concept is to be
able to find what you want quickly while you are working -- but it 
would certainly be nice to be able to have a hierarchical organization 
in the other resource folders.

More generally, it would be nice to have some kind of search 
capability, potentially based on a "Tags" database of the sort
that Sven has suggested some time ago.  Using tags to find
a resource with specific properties is potentially quite a bit
more powerful than depending on hierarchical organization.

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

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

[William Skaggs]

>>  At the level of programming, the only relatively difficult thing is to
>>  create the GimpDataChooser widget. Even this is simple in principle,
>>  although complicated in practice because it involves a lot of rather
>>  complex Gimp code. I have been experimenting with writing a Chooser,
>>  and I believe I have gotten through the hardest part, although there
>> is quite a bit of refinement needed.
>
>Why bind it into gimp? This tool could be totally independent of GIMP runtime 
>wise. All that would be need on gimp side is support for using gimp-remote to 
>trigger reloading of resources. All other management could happen outside 
>GIMP. Functions needed to read and write gimp conf should be easily portable 
>from gimp code.
>
>--Alexia

That's true in principle, but building a separate executable that uses
a major part of the Gimp object system would be a much larger 
change.  I don't think that proceeding the way I have suggested
would make it any harder to separate the functionality in the
future -- and in any case it must easily be available from inside
Gimp.

By the way, the functions needed to *show* resources are not
easily portable from the Gimp code -- this requires creating
a GimpDataFactoryView, which brings a major part of the
internal Gimp object system into play.

  -- Bill

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

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

[Akkana Peck]

William Skaggs writes:
> 1) You have a "workspace", holding the brushes that you are currently
[ ... ]
> 2) You have a set of extra folders, specified in Preferences.  The
>brushes in these folders don't automatically belong to the
>workspace.  To get at them, you invoke a Brush Chooser, which pops
[ ... ]
> 3) You can also use the Chooser to save a brush from the workspace
>into the currently selected folder, assuming you have write
>permission there.

Nice! As you say, that would really encourage the creation of new
brushes, patterns and gradients because it would be so much easier
to use them.

You didn't mention fonts, but your idea would work equally well for
managing an unweildy list of fonts. If there was a way to add
hierarchies into the workspace, we could even solve the much-
discussed problem of font categorization (these are my script
fonts, these are my cartoon fonts, ...)

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

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

[Alexia Death]

> At the level of programming, the only relatively difficult thing is to
> create the GimpDataChooser widget.  Even this is simple in principle,
> although complicated in practice because it involves a lot of rather
> complex Gimp code.  I have been experimenting with writing a Chooser,
> and I believe I have gotten through the hardest part, although there
> is quite a bit of refinement needed.

Why bind it into gimp? This tool could be totally independent of GIMP runtime 
wise. All that would be need on gimp side is support for using gimp-remote to 
trigger reloading of resources. All other management could happen outside  
GIMP. Functions needed to read and write gimp conf should be easily portable 
from gimp code.

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