Re: [Gimp-developer] Script proposed for inclusion in gimp 2.6
Hi, On Tue, 2008-08-05 at 15:51 -0500, Chris Mohler wrote: I might be wrong, but it appears to me that everything that Apply Image does can be done using layers. It's just another way of using layer modes and it seems quite akward to use an extra dialog for that. Except for one thing: layers don't print out as solid. As far as I can see the result of Apply Image is a layer. I'm not suggesting that this be implemented anytime soon - but it would be nice to have better channel mixing abilities once GIMP is using GEGL for composition... Now we are getting to a point. So your post is not actually about Apply Image, but about missing channel mixing abilities. It would help if you could point out exactly what it is that you can't do in GIMP. Otherwise we will never enhance the channel mixing abilities, using GEGL or not. As far as I can see the point you are trying to make is that GIMP doesn't allow you to use channels for layer blend operations. I've tried to reproduce your example using channels and layers and indeed it appears impossible. I can easily copy a spot channel to a new layer by dragging it from the channels to the layers dialog, but the result will be the grayscale channel. Perhaps it would help if we would change that so it creates an RGBA layer that represents the spot channel. This layer would be filled with the channel spot color and the grayscale mask of the channel would be transferred to the layers' alpha channel. Does that make any sense? Would such a change break other workflows? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Windows - Image display actions potential improvement
The attached patch allows you to open several images, assign keyboard
shortcuts to them, and these shortcuts will persist, so that if you
assigned '1','2','3' to the first, second, and third image, you could
continue to switch between the first, second, and third opened image
with 1, 2, and 3.
Because of the caveat below, this is currently no better than
associating the actions directly with display IDs, rather than
associating the actions with indices into the list of displays.
Caveats :
*Currently implemented in a hackish way
*Does not cope properly with closing images -- it breaks all the
actions following and including the closed image.. So say you closed
image #3, and you had already opened a 4th and 5th, the actions for 3,
4, and 5 would break.
I'm unclear as to the exact cause of this. Does anyone here know?
Index: app/actions/windows-actions.c
===
--- app/actions/windows-actions.c (revision 26398)
+++ app/actions/windows-actions.c (working copy)
@@ -171,21 +171,114 @@
windows_actions_image_notify (display, NULL, group);
}
+static int windows_display_get_index (GimpDisplay *display)
+{
+ gint index = gimp_container_get_child_index (display-gimp-displays, GIMP_OBJECT (display));
+/* gint nchildren = gimp_container_num_children (display-gimp-displays);*/
+ return index;
+
+}
+
+static GimpDisplay *windows_display_get_nth (GimpContainer *displays, gint index)
+{
+ gint nchildren = gimp_container_num_children (displays);
+
+ if (index = nchildren)
+return NULL;
+
+ return GIMP_DISPLAY (gimp_container_get_child_by_index (displays, index));
+}
+
+static void windows_display_update_action (GimpActionGroup *group, GimpAction *action, GimpDisplay *display)
+{
+ const gchar *uri;
+ gchar *filename;
+ gchar *basename;
+ gchar *escaped;
+ gchar *title;
+
+ if (display == NULL)
+{
+ g_object_set (action,
+viewable, NULL);
+return;
+}
+
+ uri = gimp_image_get_uri (display-image);
+
+ filename = file_utils_uri_display_name (uri);
+ basename = file_utils_uri_display_basename (uri);
+
+ escaped = gimp_escape_uline (basename);
+ g_free (basename);
+
+ title = g_strdup_printf ([%d] %s-%d.%d, GPOINTER_TO_INT (g_object_get_data (G_OBJECT (action), index)),
+ escaped,
+ gimp_image_get_ID (display-image),
+ display-instance);
+ g_free (escaped);
+
+ g_object_set (action,
+label,title,
+tooltip, filename,
+viewable, display-image,
+context, gimp_get_user_context (group-gimp),
+NULL);
+
+ g_free (filename);
+ g_free (title);
+}
+
+
static void
windows_actions_display_remove (GimpContainer *container,
GimpDisplay *display,
GimpActionGroup *group)
{
GtkAction *action;
+ gint index = windows_display_get_index (display);
+ gint num_children = gimp_container_num_children (display-gimp-displays);
gchar *action_name = g_strdup_printf (windows-display-%04d,
-gimp_display_get_ID (display));
+num_children);
+ /* Step unu complete! (always remove the highest numbered action) */
+
+ /* find the relevant index by looping through the ActionGroup, finding the action with matching 'display' data-item */
+
+ if (index == -1)
+{
+ /* nun index will always be -1 when a display is being removed -- by the time this function is reached, it is no longer in the active displays list */
+ g_warning (index == -1!);
+ return;
+}
+ g_warning (WAdr:Index == %d Nch == %d, index, num_children);
action = gtk_action_group_get_action (GTK_ACTION_GROUP (group), action_name);
+ /* Step du: adjust all following actions when an action is removed. */
+
if (action)
-gtk_action_group_remove_action (GTK_ACTION_GROUP (group), action);
+{
+ gint i;
+ g_free (action_name);
+
+ for (i = index; i num_children-1; i++ )
+{
+ GimpAction *action2;
+ gintnextindex;
+ action_name = g_strdup_printf (windows-display-%04d, i + 1);
+ /* XXX move all index/display object_data back one slot */
+ action2 = (GimpAction *) gtk_action_group_get_action (GTK_ACTION_GROUP (group), action_name);
+ nextindex = GPOINTER_TO_INT (g_object_get_data (G_OBJECT (action2), index));
- g_free (action_name);
+ action_name = g_strdup_printf (windows-display-%04d, i);
+ action2 = (GimpAction *) gtk_action_group_get_action (GTK_ACTION_GROUP (group), action_name);
+ g_object_set_data (G_OBJECT (action2), index, GINT_TO_POINTER (nextindex));
+ windows_display_update_action (group, action2,
+
Re: [Gimp-developer] Script proposed for inclusion in gimp 2.6
I like this idea. I would use it frequently. In fact, I would suggest calling it Duplicate Visible in the menu, and also adding it to the buttons at the bottom of the layers dialog with a description of Duplicate visible layers as single new layer on mouse-over. As far as real estate on the bottom of the layers dialog goes, I would eliminate the raise/lower layer buttons I don't ever use them since it is easier to drag the layer itself to the new location than to select the layer with one mouse click and then find and click on the raise/lower button. -- View this message in context: http://www.nabble.com/Script-proposed-for-inclusion-in-gimp-2.6-tp18831803p18856989.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Duplicate Visible (was: Script proposed for inclusion in gimp 2.6)
Hi, On Wed, 2008-08-06 at 11:31 -0700, vabijou2 wrote: I like this idea. I would use it frequently. In fact, I would suggest calling it Duplicate Visible in the menu, and also adding it to the buttons at the bottom of the layers dialog with a description of Duplicate visible layers as single new layer on mouse-over. It would be easy to add this. I would even add it as a core function, not as a script, as it is much easier to implement in the core. I am not sure about the name though. Duplicate Visible doesn't quite hit it. Perhaps someone has a better idea? As far as real estate on the bottom of the layers dialog goes, I would eliminate the raise/lower layer buttons I don't ever use them since it is easier to drag the layer itself to the new location than to select the layer with one mouse click and then find and click on the raise/lower button. I often use the up/down buttons. Clicking a button is much easier than doing drag and drop. We would need to do some user observations to decide this. Without such data I'd vote for keeping the buttons. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Font Preferences needs to give user power over system fonts path
Font preferences allows the user to add custom paths to font directories. The system fonts are included by default but are not viewable/removable by going to File Preferences Folders Fonts Even though the fonts found in /usr/share/fonts are included in Gimp's font selections, they cannot be seen in the font preferences (list of paths). I have suggested a feature be added giving user control over the system fonts. If you are a GIMP developer, please let me know what you think of this by posting to bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=546344 The proposed feature request will give control over system fonts from within GIMP, so that the user could chose to turn them off if preferred. In turn this will allow power users to have full control over the fonts displayed in GIMP. -komputes ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Font Preferences needs to give user power over system fonts path
komputes wrote: Font preferences allows the user to add custom paths to font directories. The system fonts are included by default but are not viewable/removable by going to File Preferences Folders Fonts Even though the fonts found in /usr/share/fonts are included in Gimp's font selections, they cannot be seen in the font preferences (list of paths). Hi IMO letting the user have full control of what fonts that is available in GIMP completely aligns with the product vision [1]. I think the bug report is valid and should be reopened. Best regards, Maritn Nordholts [1] http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
