GNOME Bugzilla – Bug 118742
can't edit/delete default assets
Last modified: 2018-05-24 10:53:10 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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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 ?
Bumping to the next development cycle since this will need some larger changes to the GimpData infrastructure.
Upgrading milestone from Future to 2.6.
*** Bug 347503 has been marked as a duplicate of this bug. ***
Not a crucial issue and no real progress in the last 3,5 years. Setting milestone to Future.
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.
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).
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.
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.
-- 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.