Re: problem with gtk+ colorselector
Hi, Nick Lamb [EMAIL PROTECTED] writes: On Sun, Feb 04, 2001 at 04:45:58AM +0100, Sven Neumann wrote: The colorselector has already undergone a major overhaul in the HEAD tree. The color previews as well as all sliders are now global to all color selector notebooks so all selectors should behave identically. Have a look at http://sven.gimp.org/files/color_selector_1_3.png for a screenshot. Yeah, but there's some odd bugs or features with it. Firstly when you're not using the "Gimp" selector (we should find better names) you can still see the radio-buttons which control it - they just don't react. Odd. They are set insensitive which should IMHO be feedback enough. If you can think of a better place for the toggle buttons, let us know. Secondly the "GTK+" tab resizes oddly the first time you look at it, then it's fine, but too small the next time. If we can't get it working right we should write our own circle+bar selector instead of fudging it. Yes, indeed. We have hidden almost every widget in the GTK+ colorselector and we had to do it from an idle callback. This broke size allocation. We should kick the GTK+ color selector and write a simple circle+bar as you suggested. What does the GTK+ selector bring to the party anyway? The reason was that many other places (plug-ins, gradient editor) in The GIMP used to use the plain GTK+ colorselector, so it should also be available in the main color selector. Since we plan to use the new combined selector everywhere, the circle-shaped GTK+ selector is not really necessary anymore. GTK+-2.0 replaces it with a triangle colorselector anyway, so if we want to keep that circle thing, we have to put the code into Gimp. Salut, Sven
Re: problem with gtk+ colorselector
On Sunday, 4 Feb 2001, Nick Lamb wrote: What does the GTK+ selector bring to the party anyway? Nothing: it's a "demo" piece of code showing how to interface your colour selector to the GIMP module API. The point being that there is no actual colour selector code there, since it's all in GTK, so the module API is clearer. It's useful to programmers, not artists :) You can always check the "load inhibit" button in the module browser, if you don't like it. Austin
Re: problem with gtk+ colorselector
Hi, "Uwe Koloska" [EMAIL PROTECTED] writes: This isn't in sync with the behaviour of the other selectors. There you always have the comparison with the color you want to change! If you click on the fg-color you can watch your changes in contrast to the old color. It's of very limited use, to see the changes in contrast to a color you have chosen before. OK, I think I see your point now. Therefore the gimp colorselectors behaviour has to be changed or that of gtk+. The colorselector has already undergone a major overhaul in the HEAD tree. The color previews as well as all sliders are now global to all color selector notebooks so all selectors should behave identically. Have a look at http://sven.gimp.org/files/color_selector_1_3.png for a screenshot. If someone finds a simple fix for this (minor) problem in gimp-1.2 we should consider applying it to the stable version. Salut, Sven
Re: problem with gtk+ colorselector
On Sun, Feb 04, 2001 at 04:45:58AM +0100, Sven Neumann wrote: The colorselector has already undergone a major overhaul in the HEAD tree. The color previews as well as all sliders are now global to all color selector notebooks so all selectors should behave identically. Have a look at http://sven.gimp.org/files/color_selector_1_3.png for a screenshot. Yeah, but there's some odd bugs or features with it. Firstly when you're not using the "Gimp" selector (we should find better names) you can still see the radio-buttons which control it - they just don't react. Odd. Secondly the "GTK+" tab resizes oddly the first time you look at it, then it's fine, but too small the next time. If we can't get it working right we should write our own circle+bar selector instead of fudging it. What does the GTK+ selector bring to the party anyway? Nick.
Re: problem with gtk+ colorselector
Hi, "Uwe Koloska" [EMAIL PROTECTED] writes: I have found a very annoying problem with gimps gtk+ colorselector. Since I don't use it normally, it came into my eye after installing digipencil. Because the testprogramm that come with gtk+ shows the right behaviour, it maybe there is a problem with the gimp inheritance of this widget. The problem: I click on the foreground color (black) and choose the gtk+ selector. Close the color selector. Then click on the background (white) and the two labels under the colorcircle are filled with black and white (from the left) Very well noticed. My first problem was that I was unable to change the foreground color. But this was a problem with the value. The circle shows a color but this color has no value, so it was always black ... The circle alone is not sufficient to choose a color. There has to be a way to change the colors value. But I guess you found that out pretty soon. And the behaviour I described above seems to be related to this. The gtk+ colorselector seems to display the color that was chosen the last time. This is probably due to the fact, that the color selector isn't destroyed after choosing a color. If you leave the selector open and doubleclick on the other color (back- or foreground) you can see this clearly. The GTK+ colorselector does indeed remember the color last choosen so you are able to see the contrast between the new color and the one you started with. Now to the point: Where's the problem?? Salut, Sven
