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
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?
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?
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, 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 Wed, Sep 01, 2004 at 06:51:46PM -0700, Carol Spears wrote: > On Thu, Sep 02, 2004 at 03:37:29AM +0200, Sven Neumann wrote: > > Hi, > > > > Carol Spears <[EMAIL PROTECTED]> writes: > > > > > perhaps no checkerboard could also be considered? > > > > It would have to be optional and I cannot imagine a sane user > > interface for this. Can you? > > > scanners? what does this have to do with scanners? > > heck, sometimes you cannot see the image on the image even > i read this wrong the first time and thought you were talking about something else (not even scanners). user interface. you can set in preferences that previews dont show the checkerboard for transparency. this new gimp is so full of interface options -- padding color and window stuff. that is why your comment was confusing to me. 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? carol ___ 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 03:37:29AM +0200, Sven Neumann wrote: > Hi, > > Carol Spears <[EMAIL PROTECTED]> writes: > > > perhaps no checkerboard could also be considered? > > It would have to be optional and I cannot imagine a sane user > interface for this. Can you? > scanners? what does this have to do with scanners? heck, sometimes you cannot see the image on the image even carol ___ 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, Carol Spears <[EMAIL PROTECTED]> writes: > perhaps no checkerboard could also be considered? It would have to be optional and I cannot imagine a sane user interface for this. Can you? 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 Wed, Sep 01, 2004 at 11:41:35AM +0200, David Odin wrote: > > Anyway we have to be consistent here. So, I would like to know what > you (especially artists) do prefer: > > - keep the checkerboard fixed to the drawable for images and previews. > - have the checkerboard fixed to the window for images and previews. > when i saw this being discussed on the irc, i was thinking about another option. depending on the preview size, the checkerboard can make the transparent image difficult to see (like a text layer where the font is fairly fine and the color is black, for instance) and i instantly imagined that it might be easier to have solid backgrounds for previews. a background color that could be changed on the fly depending on what sort of image you are working on. even if the previews get "bigger" as seem to be planned, it seems like not having checkerboard in a bigger preview would still be a nice option. even after you can zoom in on previews. and really, it might be the only way to tell the difference between the preview and the image depending on how big and nice they (the previews) continue to become. perhaps no checkerboard could also be considered? carol ___ 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, Christopher Curtis <[EMAIL PROTECTED]> writes: > I personally like the image preview fixed-checkerboard method, at > least on the preview. I don't know how well it would translate onto > the main canvas. I don't think doing it differently in the preview and on the image window is an option at all. Consistency is the most important aspect of an user interface. 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?
Sven Neumann wrote: It would still be interesting to hear about people's preferences. So please ignore my technical comments and tell us what which behaviour you would prefer from a user's point of view. I personally like the image preview fixed-checkerboard method, at least on the preview. I don't know how well it would translate onto the main canvas. However ... wouldn't this question be better directed at the user list? rgds, Chris ___ 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: > - have the checkerboard fixed to the window for images and previews. > > Imho, the later is nicer, but Sven told me it could make the scrolling > and panning of the main image window much slower. It wouldn't affect the plug-in previews since there we redraw the full preview on scrolling anyway (this implementation detail could change though). In the image window however I expect a very noticeable slowdown for scroll operations. What we are doing in the display code is to use gdk_scroll_window(). This is most easily explained using an example: Say you scroll 10 pixels to the right. What happens is that we copy the content of the window 10 pixels to the left using a screen-to-screen blit. This is usually implemented as an operation that is performed entirely on the graphics card so it uses almost no CPU cycles. Only an area of 10 pixels width actually needs to be redrawn. If we would decouple the checkerboard from the image, we'd have to redraw the whole image display on every scroll operation. Only if we would let the graphics card do the composition onto the checkerboard, we could consider to link the checkerboard to the window. Modern graphics card are able to do that but GDK lacks an API to use that functionality and there are also certainly people using GIMP on older hardware which doesn't do alpha compositing in hardware. It would still be interesting to hear about people's preferences. So please ignore my technical comments and tell us what which behaviour you would prefer from a user's point of view. 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?
David Odin wrote: But I liked the old behaviour (having the checkerboard fixed to the window) since it really shows that the checkerboard isn't part of the drawable as soon as you pan or scroll the preview, and such, the transparency is more obvious. Anyway we have to be consistent here. So, I would like to know what you (especially artists) do prefer: - keep the checkerboard fixed to the drawable for images and previews. IMO it also makes it more obvious that scrolling and panning really happens - something that mignht be important for the users if thei mage has large parts that are transparent. > - have the checkerboard fixed to the window for images and previews. > > Imho, the later is nicer, but Sven told me it could make the scrolling > and panning of the main image window much slower. That would be an additional problem then. Michael -- The GIMP > http://www.gimp.org| IRC: irc://irc.gimp.org/gimp Wiki > http://wiki.gimp.org | .de: http://gimpforum.de Sodipodi > http://sodipodi.sf.net | IRC: irc://irc.gimp.org/sodipodi ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
