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 133456 - brush renaming only works for VBRs
brush renaming only works for VBRs
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Data
git master
Other All
: Normal normal
: 2.0
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2004-02-05 00:56 UTC by david gowers
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description david gowers 2004-02-05 00:56:53 UTC
VBRs i can edit, rename, save, and hit refresh -- they stay renamed.
GBR/GIHs i can rename, but when i hit refresh they go back to their old name.
am i doing this wrong, is there another way to rename? or is this a bug really.
Comment 1 Sven Neumann 2004-02-05 01:22:39 UTC
You can only rename brushes that are writeable. I must admit though
that the implementation here is flaky. You shouldn't be able to edit
the name of a non-writeable brush (palette, gradient, ...).
Comment 2 david gowers 2004-02-05 04:57:25 UTC
i don't see how that can be the problem: i only have one brushes directory, which is set writeable in preferences, and all my brushes are chmoded 644 and owned by the same user i run gimp as('neo' / 501).    incidentally, i came across something strange. i gather it occurrs due  to recent changes in GimpData, since only my latest few builds have it.: when i duplicate a gradient, editing the duplicate is disabled. i can doubleclick on it to put it in the gradient editor, but i cannot change the name* or the colors/segments etc.. after some random actions  (doubleclicking on gradients, trying to edit ones that i can edit,   rightclicking despite it doing nothing) i generally get to edit the new duplicate.    if this is my error, can you explain how/why ? i just select the gradient i want and hit the duplicate button, then doubleclick on the new gradient.  i'll file this as a bug if you can confirm.
Comment 3 Dave Neary 2004-02-05 16:34:23 UTC
Could you specify OS and version details, please? 

Dave.
Comment 4 Michael Natterer 2004-02-05 21:13:27 UTC
We don't need OS details. It's a simple bug and the fix
is as easy as:

      /*  if we can't save, we are not writable  */
      if (! GIMP_DATA_GET_CLASS (data)->save)
        data->writable = FALSE;

Will commit a fix later.
Comment 5 Michael Natterer 2004-02-05 22:17:29 UTC
Well, it was not so trivial. Fixed in CVS:

2004-02-05  Michael Natterer  <mitch@gimp.org>

	Disallow editing of data objects which have no save functionality.
	Also fixed the misassumption that "deletable" is always equal to
	"writable". Fixes bug #133456.

	* app/core/gimpdata.[ch]: added a "deletable" property which is
	always equal to "writable" except when the data class does not
	implement GimpData::save() (then deletable may be TRUE but
	writable is always FALSE).

	* app/gui/brushes-menu.c
	* app/gui/gradients-menu.c
	* app/gui/palettes-menu.c
	* app/gui/patterns-menu.c
	* app/widgets/gimpdatafactoryview.c: look at data->deletable when
	setting the sensitivity of the "Delete" buttons and menu items.

	* app/widgets/gimpdatafactoryview.c
	(gimp_data_factory_view_tree_name_edited): rename the data
	only if it's writable and restore the old name otherwise.

	* app/widgets/gimpdataeditor.c: no need to look at data->internal
	for figuring if the data is editable, data->editable is enough.

	All files above: s/writeable/writable/g

	* app/widgets/gimpbrusheditor.c (gimp_brush_editor_set_data):
	simplified.