CEGUIColourPicker

[Ident]

i only need load, i ve to fix something on my project then i ll start implementing this widget for my project test-wise

[Kulik]

I don't have any data to support my concerns but I think it will be slow. The fact that the texture size isn't going to change isn't exploited at all in load AFAIK. The texture is pretty much recreated in setTextureSize (at least in OpenGL). One solution would be to alter setTextureSize and make it early exit if the size is the same. That would leave the data there though and I have no idea if someone is relying on that.

Imagine someone is sliding one of the fancy colour sliders and you have to quickly redraw the whole texture. Significant lock ups won't be cool in this scenario.

[Ident]

Actually I don't know how to update a texture in OpenGL without sending the height and width when doing this. I don't think it makes any difference if the height and width do not change, and you update it or if they change and you update it, really. The only overhead would be if upon creating a texture the texture ID on the GPU wouldn't be registered at that point but only if loading textures from local memory (and there also deleted) but this would in general be the wrong way to do it, so if its done that way atm. it needs to be changed anyways and if it's not it fits anyways. D3D / DirectX might be different but I am not sure about that. As for Ogre and Irrlicht, they cannot do it differently internal as they are just wrappers for OGL / DX anyways.

[Ident]

I am nearly done making the "layout" for the widget in the looknfeel.
After that i will have to implement functionality, some basic functionality I already got, and the picker texture creation, colour space conversions, etc., I use from my old project with some changes.

- There will be a ColourPicker widget (the one you will only use), a ColourPickerWindow (widget that is used to make a popup window and change colour attributes or pick a colour etc.) and a FrameColourRect which is basically just a framed window with a colour applied inside.
- I will make it possible to change a property for every colour picker to have a shared or non-shared ColourPickerWindow (true/false)
- If shared, the colour picker will use the same ColourPickerWindow (the one that pops up when clicking on the colour) as other ColourPickers. So if someone would for whatever reason want to re-layout this thing, they could use a different ColourPickerWindow for every ColourPicker. The changes for the colour picker window look should be applied via the defined functions/properties (for example to change the font colours, font types, etc.) so this will be done completly internally. The alternative is to define a new widget for the ColourPickerWindow in the looknfeel, however it will have to have the same child widget types with the same names, so the ColourPicker C++ code can actually refer to them....
- If you want to customly define a ColourPickerWindow, there is a Property in ColourPicker that defines the widget type to be used for this window.

If you wanna change the style of the ColourPicker / ColourPickerWindow, this should be done in the layout or in your program code upon creation, via the appropriate functions. If done via layout, I will make that the ColourPickerWindow is created as desired (shared/nonshared) and then apply the appropriate style according to the set properties in the ColourPicker. Else the functions for this can be used directly.

I will make the shared/non-shared ColourPickerWindow managment with an std::map and the created names will have a prefix like "__auto_" and add the ColourPickerWindow widget name, i.e. "ColourPickerWindow" to that and finally add static unsigned int number which will be increased for every automatically created ColourPickerWindow. This should make the window names quite unique and generic. Of course the system might fuck up if someone has the genius idea to create some millions of ColourPickers with non-shared ColourPickerWindows or to name his new window __auto_ColourPickerWindow_1, but whoever does this fully deserves to have his program fuck up .


For the next 2 weeks I will have to make a break on this because of uni stress. I just wanted to write this summary before that, also in case I might forget how i planned stuff .

Oh as for now I plan to make a Lab and a HSB picker inside the ColourPickerWindow.

[MarkR]

Just for interest, will the ColourPicker be able to configure the transparency, too?
Besides that, great idea and I would be too glad to use it in my software
I always was too lazy to implement a colour picker, so you currently have to choose the colors 'manually' by typing their AARRGGBB values in my overlay (http://ts3overlay.r-dev.de).
Not very user-friendly, but it works... Somehow... ^^

[Ident]

Hmmm, it makes basically not much sense in a colourpicker to have a alpha value. It is not part of any colour models or colour spaces because mostly you dont have "alpha" in nature, and if you have it has no connection to the "colour" itself. The colour is untouched. All you need for alpha is a slider.
It would be possible to add that, also i could add a background picture underlying the colour picker, so you see the transparency there, too (a white-grey checker is most common for that to make the alpha visible, with white background the colour would just be whitened and you have no feedback for the eye on that)


I could make the Alpha value optional but you have to consider the layout has always got to be able to adapt to that and it has to be prepared for that as a whole.

I will think about adding alpha when i have finished the rest. It is actually just a slider and a field by itself, but for visualization i will have to add a lot of other stuff, also i will need to offer more function in c++ code and events and and and...

I will think about it

[MarkR]

Perfect I was also thinking about such a white/gray checker.
You're absolutely right, that you normally won't need the alpha value at all, however in my case, this is mandatory.
Having a alpha-incapable colour picker would in any case be more comfortable than the current way of typing the AARRGGBB string, but a solution where you pick the color in one dialog and then modify the alpha value somewhere else would seem like a half-ready solution in my case, so if you decide not to implement the transparency, I could imagine you wouldn't be too angry if I'd implement that by myself, would you? xD

[Ident]

So the colour picker was >50% finished by last month, however I could not really do much progress this month and it has some serious performance issues which I could not solve yet. The Lab colour picking works quite well. I have not implemented the HSB one yet. The only thing which is a problem now is the performance regarding the creation of the texture to pick on. I considered making a shader and computing the picking texture in real-time inside the shader, which will likely work a lot faster, but I would have to do all the shader stuff for all renderers i fear (DX, Ogl, irrlicht) which seems a lot of overhead. Also i would prefer it just worked on CPU

I don't even know why it is so slow? what is so bad about 260*260 * approx.30 mathematical operations, pfft. Stupid computers.

If my uni wasn't so challenging I could put more time into this, once I will have time I will try to make progress on this to finish it asap.

Expect the release date of the colour picker to be exactly between the release dates of Diablo 3 and Duke Nukem Forever.

[Ident]

Duke Nukem Forever was released a recently and the Diablo 3 release is getting closer, i m under serious pressure now.(That's how jokes can backfire on you, guys! Take care!).

I only have to make handlers input changed for LAB edit boxes now, and then i can add the HSB colour space stuff. Most of the colour picker is finished and nice to use already, the HSB colour picker will be the biggest upcoming part.

I hope when i m done, this can easily be integrated into cegui, as well as it is now integrated into the cegui library project on my computer.

I think i have never shown a picture of it yet, here it goes:


background of colour picker is semi transparent, thats why this stuff is there

[Ident]

added alpha


Think it is 98% finished now

[Mikademus]

Very nice! Is it going into 0.7.x or is is it intended for 0.8 only?

[Ident]

Depends on how it will be integrated. CE wants to put it into an additional library together with some other things.

Currently i use 0.7.x for this colour picker, i just added the code files i needed to the CEGUI base library, but i think eddie doesn't want have this in the CEGUI base, but instead prefers to add it as part of this additional library that i mentioned before.

I consider the picker basically finished, there is only maybe some cleanup and documentation to do, but i fixed all the bugs that were left.

[Ident]

CE started integrating the colourpicker into 0.8x

So there wont be an official 0.7.5 release

If anyone super-urgently needs it for 0.7.5 i can try providing my additional files, but you will have to edit the cegui project file accordingly and compile it yourself, unless you use VS2010. Because of the extra effort i would recommend waiting for 0.8x if possible

[Mikademus]

It will be a nice and welcome addition to 0.8! Now we only need someone to start working on a replacement for the Tree widget and 0.8 will be truly outstanding!

[Ident]

colourpicker is now in 0.8 branch, there is also a demo. It is in the CommonDialogs library and the demo is the CommonDialogs library, for everyone who wants to use it.

I also made some changes so the conversion functions and colour types (HSV, CIELab, RGB) can be used directly in your program if you include the header.