After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 118742 - can't edit/delete default assets
can't edit/delete default assets
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: User Interface
1.x
Other All
: Normal enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
: 347503 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-07-31 08:14 UTC by Jay Cox
Modified: 2018-05-24 10:53 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jay Cox 2003-07-31 08:14:36 UTC
The brushes pallet won't let you delete those useless brushes that ship
with the gimp.  I know you can edit the brushes path in the preferences
dialog to get red of them, but most beginners will have no idea.
Unfortunately changing the brush path will remove all the brushes even if
there were a few you wanted to keep.  (This goes for gradients and patterns
also)

RECOMMENDATION: gimp should copy (or ln -s?) the system brushes into
the users folder when it is launched for the first time.  Single
user systems will never miss the meg or two this takes. On
multiuser systems the admins can prune the system brush library.
Comment 1 Dave Neary 2003-07-31 09:31:16 UTC
Alternative (perhaps worse?) solution: create entries in the user's
brushes directory to say when a brush has been deleted. That is,
install continues as it does now, and when a user deletes a brush, a
file is created (or an entry is added to some kind of metadata file)
to say that the brush has been hidden. At startup, this file is read
before we go hunting for the system and user brushes. This also allows
a user to hide personal brushes if they want to without deleting them.

Just an idea...

Dave.
Comment 2 Raphaël Quinet 2003-08-04 17:44:11 UTC
We should avoid duplicating files if possible.  Copying the palettes
was already a bad idea (which should be fixed) and copying the brushes
is even worse because the animated ones can easily exceed 100KB.  I
maintain a copy of the gimp for several hundred users and that would be
a significant waste of disk space.  Most of these users do not use the
GIMP very often, but running it once would be enough to waste the disk
space.

I prefer the idea suggested by Dave: keep a list of brushes in a file.
Even better: keep only a blacklist.  By default, the blacklist is empty
(the file does not even have to be created).  When the user deletes a
system brush, it is added to the list.  This provides some advantages:
- For most users, the blacklist will not exist, saving a tiny bit of
  disk space and initialization time
- When the admin installs new brushes in the system directory, they
  will be visible to all users
- It is easy for the user to "un-hide" the deleted brushes by clearing
  the black list
Comment 3 Sven Neumann 2003-08-05 11:55:03 UTC
The palettes are no longer copied in the 1.3 series. All data files
are treated the same since they are all derived from the same baseclass.
Comment 4 Raphaël Quinet 2003-08-05 13:59:33 UTC
Yes, sorry about the palettes stuff.  I should have written: "which
had to be fixed".  ;-)

I thought about this problem a bit more during the night and I think
that the following solution is better: do not use a file containing
the metadata, because it could cause some problems if the user copies
files to and from his/her brushes directory (especially if they have
the same name as system brushes).  Instead, use empty (zero-sized)
files for each deleted brush.  The same technique could be used for
all other objects based on the GimpData class.

This simple trick would allow any object in the system directory to
be deleted by the user: a corresponding empty file would be created
in the user's private directory.  This could be done in
gimp_data_delete_from_disk() or in the higher-level routine
gimp_data_factory_view_delete_callback().  When loading brushes (or
other GimpData objects), an empty file would cause the object to be
registered as "hidden" or "deleted", so that the same object would
not be loaded from the other directories in the path ($gimp_data_dir)
and the object would not appear in the viewer.  Just like one can
replace one of the system brushes with a modified version by having a
file with the same name in one's private directory, it would be
possible to hide a system brush by creating an empty file with the
same name.

This would be nice for the user would could use a shell or any file
manager to copy or move files easily.  Copying files from another
user's private directory or from a previous release of the GIMP would
produce the expected effects.  And as with the solution that I
proposed earlier, any new brushes installed in the system directory
(by an additional package or a version upgrade) would be available to
all users without having to update some special files.
Comment 5 Sven Neumann 2003-08-15 10:19:14 UTC
I would rather like to solve this problem together with the problem of
categorizing data files. If GimpDataFactory would keep persistent
extra information about all data files, we could easily organize the
data in a tree and also hide user-deleted files.

Your proposal also has a severe problem: How do you identify files in
the system-wide directories? There might be several of them thus
filenames aren't unique.
Comment 6 Raphaël Quinet 2003-08-15 11:02:27 UTC
With my proposal, there is no need to identify the system directories:
the brush-path (or path for other GimpData objects) is followed as
usual.  If several files have the same name, then the first one found
is the one that is used.  If that file was empty, then any other files
with the same name will be hidden.  There is no problem if there are
several files with the same name: the first one takes precedence,
exactly as it happens now when there are several real (non-empty)
brushes with the same name.
Comment 7 Sven Neumann 2003-08-15 11:37:00 UTC
I don't think the files are currently handled as you describe. There
can be multiple files of the same name in the various directories of
the brush path and they will all be used.
Comment 8 Michael Natterer 2004-02-06 10:37:22 UTC
Several of the mentioned issues in this bug report have been
addressed by making the writable portion of the brush, pattern
etc. paths configurable separately and by fixing the 
questionable semantics of GimpData::writable by splitting
it in GimpData::writable and GimpData::deletable.
(See bug #133456).

The remaining (and main) issue of being able to "delete"
files from the read-only directories is IMHO clearly an
enhancement that would be nice to have for 2.2.
Comment 9 Dave Neary 2004-02-06 10:48:12 UTC
I like the idea of having a metadata file in ~/.gimp-1.3/brushes (or a
brushesrc in ~/.gimp-1.3) which contains a list of the brushes
available with a visibility flag. Deleting a brush would toggle the
visibility of the brush to false, and the brush would not appear in
the docs. The same system could be used for patterns, palettes,
gradients etc.

This has the advantage of not duplicating a bunch of data files, and
of requiring a fairly small amount of modification (this could mostly
be done, I think, in GimpData).

Cheers,
Dave.
Comment 10 Raphaël Quinet 2004-02-06 16:39:00 UTC
As I wrote in my previous comments, I prefer to avoid any metadata
files because they would prevent the user from copying and moving
files from these directories using a standard shell or file manager.
This would make it more difficult for a user who wants to copy some
brushes or patterns created by someone else (without being forced to
copy the whole metadata file from the other user when only some parts
of it are needed).

I prefer a solution that uses zero-sized files for marking the system
brushes that should be hidden, because that will allow the user to
copy and manage all objects easily: each object has its own file,
without requiring additional metadata.
Comment 11 Sven Neumann 2004-02-06 16:44:09 UTC
How do zero-sized files (what a weird idea) solve the problem of
renaming brushes, sorting them in categories and the other issues that
people are        having with GIMP's data files ?
Comment 12 Sven Neumann 2004-10-22 15:50:51 UTC
Bumping to the next development cycle since this will need some larger changes
to the GimpData infrastructure.
Comment 13 weskaggs 2006-06-16 15:37:41 UTC
Upgrading milestone from Future to 2.6.
Comment 14 Michael Schumacher 2006-07-14 18:38:57 UTC
*** Bug 347503 has been marked as a duplicate of this bug. ***
Comment 15 Martin Nordholts 2008-05-28 05:43:49 UTC
Not a crucial issue and no real progress in the last 3,5 years. Setting milestone to Future.
Comment 16 Martin Nordholts 2009-07-22 11:28:38 UTC
I don't see why we should complicate things, let's just copy the system-wide resources to the userdir, remove the system wide folder on the brush path and be done with it. As a high-end photo app our users will regularly deal with images that together take up orders of magnitudes larger dispspace than the copied resources, even when we add a larger set of default resources.

I plan to fix this for 2.8.
Comment 17 Sven Neumann 2009-07-22 22:51:31 UTC
See my comment on the mailing-list. Copying the resources to the user folder is waste of resources and will cause nothing but trouble. We have discussed this on the mailing-list several times.

With the new tags system in place it has become quite easy to implement the possibility to hide system brushes. Anyway, removing from the milestone until this has been discussed on the list (again).
Comment 18 olsen 2016-09-17 21:46:11 UTC
i would like to see progress on this... since i have TONS of brushes installed (from vast collections which increase functionality alot), i need to be able to mark and delete several brushes that i dont need. There are no tumbnails if you browse the directory the brush files are, so you need to manually delete one and one brush in gimp which is a tiring process.

there are some "aftermarket" programs like abrmate that i think try to solve this but it will only run on windows and development seems to have stopped. I can not imagine coding this into gimp will take much work since it would basically be like the "delete" function thats already there, but with the added option to mark several brushes (like you mark several files in a filebrowser) before you choose to delete them.
Comment 19 Jehan 2017-01-25 22:13:12 UTC
I believe this bug report could be generalized because the exact same problem is true for all kind of default resources which can't be edited nor deleted.
Updating the title.
Comment 20 GNOME Infrastructure Team 2018-05-24 10:53:10 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/48.