Re: [Gimp-developer] Should the checkerboard be linked to the window or to the image?
Hi, Carol Spears [EMAIL PROTECTED] writes: the same way you can change the padding color now. i would not have been able to imagine such an interface to the previews without all those new options for customizing your sessions. all this stuff is sane? You might not have noticed that we have started to remove options from the user interface. However you should be aware of the fact that we try not to add new options unless there's a very good reason for it. Actually the plan was to let the plug-in previews respect the settings from gimprc that already exist: (transparency-size medium-checks) Sets the size of the checkerboard used to display transparency. Possible values are small-checks, medium-checks and large- checks. (transparency-type gray-checks) Sets the manner in which transparency is displayed in images. Possible values are light-checks, gray-checks, dark-checks, white-only, gray-only and black-only. That would of course mean that the same settings apply to plug-in previews and to image windows. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Should the checkerboard be linked to the window or to the image?
On Thu, Sep 02, 2004 at 12:36:43PM +0200, Sven Neumann wrote: Hi, Carol Spears [EMAIL PROTECTED] writes: the same way you can change the padding color now. i would not have been able to imagine such an interface to the previews without all those new options for customizing your sessions. all this stuff is sane? You might not have noticed that we have started to remove options from the user interface. However you should be aware of the fact that we try not to add new options unless there's a very good reason for it. Actually the plan was to let the plug-in previews respect the settings from gimprc that already exist: (transparency-size medium-checks) Sets the size of the checkerboard used to display transparency. Possible values are small-checks, medium-checks and large- checks. (transparency-type gray-checks) Sets the manner in which transparency is displayed in images. Possible values are light-checks, gray-checks, dark-checks, white-only, gray-only and black-only. How hard would this be to implement? That would of course mean that the same settings apply to plug-in previews and to image windows. Which is the way it should be if we want to be consistant. -- [EMAIL PROTECTED] Friends help you move. Real friends help you move bodies. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Should the checkerboard be linked to the window or to the image?
Hi, David Odin [EMAIL PROTECTED] writes: Actually the plan was to let the plug-in previews respect the settings from gimprc that already exist: (transparency-size medium-checks) Sets the size of the checkerboard used to display transparency. Possible values are small-checks, medium-checks and large- checks. (transparency-type gray-checks) Sets the manner in which transparency is displayed in images. Possible values are light-checks, gray-checks, dark-checks, white-only, gray-only and black-only. How hard would this be to implement? It would involve two changes: (1) Add transparency-size and transparency-type properties to GimpPreviewArea and use them when drawing the checkerboard. (2) Somehow get the preferences to the plug-in. Step 1 should be pretty much straight-forward. The properties can be copied more or less directly from GimpDisplayConfig (app/config). Checkerboard rendering will become slightly more complex but I don't expect any noticeable slowdown. The code has still some room for optimizations anyway. There are two possibilities to implement step 2. Either we add a PDB API to access the checkerboard settings: gimp_gimprc_get_transparency_type() ?? gimp_gimprc_get_transparency_size() ?? or (and I'd prefer that), we pass these settings to the plug-in in the GPConfig message. This is a message that is sent to each plug-in when it is started. We handle this in libgimp and allow the plug-in to access the settings using a simple API. See for example gimp_show_tool_tips() or gimp_display_name(). Using the config message is definitely the prefered way of doing this but unfortunately we are completely braindead and didn't add any padding to the GPConfig struct :( However, there's still hope but things are becoming ugly now. Readers with a weak stomach, please leave now... The GPConfig struct contains an unused member which is gamma. This is a double and IIRC a double is guaranteed to be always 8 bytes. So we could remove gamma and replace it with two 32bit integers and use those for the transparency settings. We could even squeeze the transparency settings into less than 8 bytes and keep the remaining bytes for future use. Might become useful pretty soon, for example as a way to pass whether color management should be enabled or disabled. Can anyone think of better ways to do this? Are there any strong objections against the ugly hack I outlined above? Did I overlook something (like for example platforms where a gdouble is not 8 bytes)? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Should the checkerboard be linked to the window or to the image?
Hi, a short followup to myself... As outlined in my previous mail, the checkerboard settings for the preview should be taken from the gimprc when the preview widget is created. It would be nice though to have a way to change the checkerboard settings for the individual preview widget. I think a right-click menu in the GimpPreviewArea is the way to go here. Somewhat hidden but it would be an expert feature anway. Such a right-click menu would allow users to quickly change to a solid-colored background. As Carol outlined this can be useful if for example you are trying to find the best radius to blur a text layer. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Should the checkerboard be linked to the window or to the image?
On Thu, Sep 02, 2004 at 12:36:43PM +0200, Sven Neumann wrote: You might not have noticed that we have started to remove options from the user interface. However you should be aware of the fact that we try not to add new options unless there's a very good reason for it. well, no. i did not notice that options have been being removed. i guess i have been so bedazzled by the changes that i have only seen the 2.1 branch improving. also, i did not use many of those new customizable options (new for gimp-2.0) -- i found them when trying to document it. (i used gimp far too long without padding, for instance) thank you for considering that there might be different needs for previews and images. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Extending GPConfig (was: Should the checkerboard be linked to the window or to the image?)
Sven Neumann [EMAIL PROTECTED] writes:
or (and I'd prefer that), we pass these settings to the plug-in in the
GPConfig message. This is a message that is sent to each plug-in when
it is started. We handle this in libgimp and allow the plug-in to
access the settings using a simple API. See for example
gimp_show_tool_tips() or gimp_display_name().
Using the config message is definitely the prefered way of doing this
but unfortunately we are completely braindead and didn't add any
padding to the GPConfig struct :( However, there's still hope but
things are becoming ugly now. Readers with a weak stomach, please
leave now...
The GPConfig struct contains an unused member which is gamma. This
is a double and IIRC a double is guaranteed to be always 8 bytes. So
we could remove gamma and replace it with two 32bit integers and use
those for the transparency settings. We could even squeeze the
transparency settings into less than 8 bytes and keep the remaining
bytes for future use. Might become useful pretty soon, for example as
a way to pass whether color management should be enabled or disabled.
Can anyone think of better ways to do this? Are there any strong
objections against the ugly hack I outlined above? Did I overlook
something (like for example platforms where a gdouble is not 8 bytes)?
When looking at the struct:
struct _GPConfig
{
guint32 version;
guint32 tile_width;
guint32 tile_height;
gint32 shm_ID;
gdouble gamma;
gint8install_cmap;
gint8show_tool_tips;
gint32 min_colors;
gint32 gdisp_ID;
gchar *app_name;
gchar *wm_class;
gchar *display_name;
gint32 monitor_number;
};
I see two options:
- using the place gdouble gamma uses.
- using the two unused bytes after gint8 show_tool_tips.
I'd suggest we do both and change the struct to:
struct _GPConfig
{
guint32 version;
guint32 tile_width;
guint32 tile_height;
gint32 shm_ID;
gint8gimp_reserved_1;
gint8gimp_reserved_2;
gint8gimp_reserved_3;
gint8gimp_reserved_4;
gint8gimp_reserved_5;
gint8gimp_reserved_6;
gint8gimp_reserved_7;
gint8gimp_reserved_8;
gint8install_cmap;
gint8show_tool_tips;
gint8gimp_reserved_9;
gint8gimp_reserved_10;
gint32 min_colors;
gint32 gdisp_ID;
gchar *app_name;
gchar *wm_class;
gchar *display_name;
gint32 monitor_number;
};
Which should be binary compatible on all platforms.
ciao,
--mitch
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GPConfig (was: Should the checkerboard be linked to the window or to the image?)
On Thu, Sep 02, 2004 at 08:08:23PM +0200, Michael Natterer wrote:
struct _GPConfig
{
guint32 version;
guint32 tile_width;
guint32 tile_height;
gint32 shm_ID;
gdouble gamma;
gint8install_cmap;
gint8show_tool_tips;
gint32 min_colors;
gint32 gdisp_ID;
gchar *app_name;
gchar *wm_class;
gchar *display_name;
gint32 monitor_number;
};
I see two options:
- using the place gdouble gamma uses.
- using the two unused bytes after gint8 show_tool_tips.
I'd suggest we do both and change the struct to:
struct _GPConfig
{
guint32 version;
guint32 tile_width;
guint32 tile_height;
gint32 shm_ID;
gint8gimp_reserved_1;
gint8gimp_reserved_2;
gint8gimp_reserved_3;
gint8gimp_reserved_4;
gint8gimp_reserved_5;
gint8gimp_reserved_6;
gint8gimp_reserved_7;
gint8gimp_reserved_8;
gint8install_cmap;
gint8show_tool_tips;
gint8gimp_reserved_9;
gint8gimp_reserved_10;
gint32 min_colors;
gint32 gdisp_ID;
gchar *app_name;
gchar *wm_class;
gchar *display_name;
gint32 monitor_number;
};
Which should be binary compatible on all platforms.
Sounds good, and gimp_gamma should return 1.0 always (and be marked as
deprecated).
-Yosh
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ctrl / radio buttons
IMHO, ctrl key/radio button interaction could be improved for the color picker. When using Color Picker, ctrl currentlty toggles between Set Foreground Color and Set Background Color - which makes sense, but there are a couple of problems in how it is implemented. 1. The color picker dialog pops up on the first click and becomes the active window. While the color picker dialog is is the active window, the ctrl key does not toggle the the mode. 2. The Pick Only mode currently disables the ctrl key from changing modes. It would seem more consistent if the Pick Only mode would not disable the ctrl key from changing modes, but I can see the reasoning behind this (if someone bumps the ctrl key and doesn't know about the feature, maybe it should remain in pick only mode - but I think maybe we could remember which mode was without CTRL, and return to the appropriate mode when released to address that issue) This is tested on: GIMP2.0.4; GTK+2.4.3; Win2K,v5,sp6; and I don't know whether all of the problems occur under different configurations. Should this be reported as a UI bug? _-Ted Get your name as your email address. Includes spam protection, 1GB storage, no ads and more Only $1.99/ month - visit http://www.mysite.com/name today! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
