[Digikam-devel] [Bug 110514] Enhanced selection, refactored histogram

[Alex Gontmakher]

Caulier Gilles wrote:
>Le Samedi 13 Août 2005 10:00, Alex Gontmakher a écrit :
>>>Alex, please place these comment on B.K.O. I suspect a B.K.O server
>>>shutdown when you have sent this mail.
>>
>>Ouch. Can't find it in my Sent: folder :(
>
>Yes. it's important. Look like Alfons is alive in your B.K.O thread (:=))).
>Cool...

I'll look again

>>>I have _the_ solution about blended histogram implementation : using
>>>sidebar in image editor instead image proprerties dialog (we removing
>>>blended histogram feature from IE)
>>
>>Good. I actually thought along these lines as well. Thought you guys
>>preferred the transparent one...
>
>Blended histogram is an inerressing way but temporally for 0.7.x serie.
>Normally SideBar integration on Image Editor have been planed during 0.8.x.
>This way isn't limited to display histogram, but all image properties field
> : file properties, Album properties, Exif, histogram, Comments & tags, and
> others like IPTC and XMP (under implementation by Renchi and another
> contributor - planed for 0.8.1 normally)

I don't like how it goes. I've started one change, and just refactored
a bit along the way. I would like to have the current change finalized and
committed before doing anything else (for instance, before moving the
Histogram
to the sidebar). When it is committed, it will be a clean baseline to
continue with.

>>Ok, with the way I refactored it, the changes to remove the transparent
>>histogram from the Canvas should be minimal (and the amount of code to
>>add it to the sidebar should be reasonable too).
>
>Yes. Take a look in digikam/sidebar.cpp implementation, it's based on
>KMultiTabBar. I think we must just re-implemnted on a SideBar dedicaced to
> IE without album database depencies. Warning this code must running with
> showfoto, and this one isn't liked with libdigikam.lo (showofoto is
> independant of digikam like this).
>
>SideBar come from Joern. I CC him if you want more information about.
>
>>Now two things:
>>1. I think that most editing functions could be done via the sidebar
>>(not unlike Photoshop Album). Maybe the plugins can be convinced to go
>>there instead of just adding menus.
>
>In a second time, like with 0.8.x serie for other editing options, and
> perhaps with DigikamImagePlugins during 0.9.x. In a first time we need to
> have a stable implementation displaying Image properties dialog tab... If
> we have more time perhaps Comments & tags dialog, but i'm not sure. It's an
> important changes, take a care (:=)))

I don't think it's that important whether it goes into 0.8 or 0.9 - but
it is
important to do it cleanly. So, I'd propose concentrating on one change
at a time,
getting it done and only then going on to another.

This way, things will behave much better. For example, I think we should
first
make both the Histogram widget and the Canvas's histogram use the same code
for histogram rendering, and maybe even make all the pieces that depend on
rectangle selection (like the Crop plugin, Red-Eye plugin etc) use the
same rectangle
selection code, and only then we should do such changes as moving the
Histogram
to a sidebar.

>>2. If (when) X supports transparent windows, it can be a nice touch to
>>let the sidebar windows undock, and become half-transparent.
>
>I love this idea. We need to take a look about KDE theme implementation for
>that.

Well, currently, if I understand correctly, X does not support
semi-transparent
windows (the semi-transparent menus do not count. They are rendered once
using the contents of the screen beneath them. I doubt they would
refresh as soon
as the window beneath changes). But I'd like to find out I'm wrong on
this one.

>>>Using SideBar is easy. It already used in digikam 0.8.0 main window for
>>>search features. SideBar solves too this wish :
>>>
>>>http://bugs.kde.org/show_bug.cgi?id=109817
>>>
>>>We continue this discution on B.K.O
>>>
>>>Gilles
>
>A nice day
>
>Gilles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20050813/da2674e3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gsasha.vcf
Type: text/x-vcard
Size: 175 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20050813/da2674e3/attachment.vcf>