Bug 270168

Not reproducible.

run kdebugdialog and turn on "digiKam" debug space.

In a console, run digiKam and look debug trace. All image editor plugins are loaded at startup ? 

Gilles Caulier

Good Evening Gilles,

I did what you asked, but I can not select or copy the output in 
console. It is about 20.000 signs. How do we communicate this?  Do you 
refer to kipi plugin? I saw a bunch loaded. Where should I look for 
specificly.

Rinus

On 05-04-11 19:38, Gilles Caulier wrote:
> https://bugs.kde.org/show_bug.cgi?id=270168
>
>
> Gilles Caulier<caulier.gilles@gmail.com>  changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |caulier.gilles@gmail.com
>
>
>
>
> --- Comment #1 from Gilles Caulier<caulier gilles gmail com>   2011-04-05 19:38:22 ---
> Not reproducible.
>
> run kdebugdialog and turn on "digiKam" debug space.
>
> In a console, run digiKam and look debug trace. All image editor plugins are
> loaded at startup ?
>
> Gilles Caulier
>

Select all trace using Edit/Select All menu (Konsole) and copy and paste content to a text file. Attach it to this entry...

Gilles Caulier

Unfortunately refuses the select command to function. Is there in linux 
a dos like command  such as ¨digikam >> dk.doc¨ or some sort of solution?
On 05-04-11 22:10, Gilles Caulier wrote:
> https://bugs.kde.org/show_bug.cgi?id=270168
>
>
>
>
>
> --- Comment #3 from Gilles Caulier<caulier gilles gmail com>   2011-04-05 22:10:10 ---
> Select all trace using Edit/Select All menu (Konsole) and copy and paste
> content to a text file. Attach it to this entry...
>
> Gilles Caulier
>

Created attachment 58625 [details]
starting digikam output in console

It is not complete. it looks console has insufficient memory to hold all output.

Created attachment 58626 [details]
output while performing action from ¨select tool¨ menu

Created attachment 58627 [details]
output in console while quiting digikam

There is no image editor plugins trace here.

Can you take a screenshot of Image Editor "Color" menu entry actived ?

Same for "Enhance" and "Transform" menu entries ?

Gilles Caulier

On 06-04-11 12:23, Gilles Caulier wrote:
> https://bugs.kde.org/show_bug.cgi?id=270168
>
>
>
>
>
> --- Comment #8 from Gilles Caulier<caulier gilles gmail com>   2011-04-06 12:23:32 ---
> There is no image editor plugins trace here.
>
> Can you take a screenshot of Image Editor "Color" menu entry actived ?
>
> Same for "Enhance" and "Transform" menu entries ?
>
> Gilles Caulier
>

The screenshots I sent was probably not what you ment and of no use at 
all. This video is showing the problem in detail.

Rinus


On 06-04-11 12:23, Gilles Caulier wrote:
> https://bugs.kde.org/show_bug.cgi?id=270168
>
>
>
>
>
> --- Comment #8 from Gilles Caulier<caulier gilles gmail com>   2011-04-06 12:23:32 ---
> There is no image editor plugins trace here.
>
> Can you take a screenshot of Image Editor "Color" menu entry actived ?
>
> Same for "Enhance" and "Transform" menu entries ?
>
> Gilles Caulier
>

Video ? Where ? Please use bugzilla web interface. Do not respond by mail directly...

Gilles Caulier

Created attachment 58630 [details]
showing the behavior of edit menus

I attached the video at the bug file Gilles. Does it provoke any 
thoughts about the problem?

Rinus

On 06-04-11 14:11, Gilles Caulier wrote:
> https://bugs.kde.org/show_bug.cgi?id=270168
>
>
>
>
>
> --- Comment #11 from Gilles Caulier<caulier gilles gmail com>   2011-04-06 14:11:04 ---
> Video ? Where ? Please use bugzilla web interface. Do not respond by mail
> directly...
>
> Gilles Caulier
>

I cannot reproduce it under Linux, but under MACOSX, yes...

It's probably due to Qt4 version which are different

Gilles

Huh? I am running digikam on two different machines (linux ubuntu pc´s) 
on both it shows this behavior.

desktop command ¨digikam --version¨ output = Qt 4.7.0
laptop    command ¨digikam --version¨ output = Qt 4.7.2

Does that mean that I need a different version of Qt?
Please do not respond too criptic. I feel sometimes like a 4 year kid in 
the cockpit of a concorde, being asked to fly to ...

Rinus

On 09-04-11 08:31, Gilles Caulier wrote:
> https://bugs.kde.org/show_bug.cgi?id=270168
>
>
> Gilles Caulier<caulier.gilles@gmail.com>  changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>               Status|UNCONFIRMED                 |NEW
>       Ever Confirmed|0                           |1
>
>
>
>
> --- Comment #14 from Gilles Caulier<caulier gilles gmail com>   2011-04-09 08:31:51 ---
> I cannot reproduce it under Linux, but under MACOSX, yes...
>
> It's probably due to Qt4 version which are different
>
> Gilles
>

On my Linux, Qt 4.6.1
On my Mac, Qt 4.7.1

Gilles Caulier

The view uses the "activated()" signal to trigger an action. Under Linux, this usually corresponds to a single click. Now there are obivously cases where this indeed does not work. I will test with setting KDE to double click behavior, perhaps this reproduces the problem.
It's a bit of a special case because the view is embedded into a menu, which probably closes after a single click.

Marcel,

Embedding this action in a popup view from Tool bar is not very elegant. Editor Canvas is half hided.

All other photo tools use sidebar to propose lead action to perform on image. If i'm not too wrong Gwenview already use this way.

There is an entry in B.K.O about this subject, in Image Editor component... 

What do you think to host you view in current "Versionning" side bar in editor, as a new tab ? This sidebar must be renamed of course, as "Filters" for ex. It's explicit because it host versionnable actions + already applied versionned actions...

What do you think about this idea ?

Gilles Caulier

Marcel,

Look this entry about actions in sidebar :

https://bugs.kde.org/show_bug.cgi?id=174070

Gilles Caulier

The motivation was to be enable quick action selection from the toolbar offering a better overview then the menus can do. Of course, this implementation was a "suggestion" waiting for feedback. 

I though along these lines:
- imagine the menu bar is gone
- offer a lot of screen real estate to get a good overview over available tools
- selection by as few clicks as possible
- do not crowd the toolbar

If it is a sub-tab in a specific sidebar, it would be even more hidden than in the menus.
I could imagine a dedicated sidebar tab which hosts the settings if a tool is active, and the selection view if no tool is active.

I ´m not sure if I am supposed to comment but anyway a few thoughts.
you say :¨this implementation was a "suggestion" waiting for feedback. ¨ 
As far as it concerns me it is a wondeful idea, it just has to function, 
thats all it takes. The fact that anything you need is just there where 
you expect it, (and if you don´t  know where to find it you can 
immediatly see it in the clear overview of the ¨select tool¨) makes dk 
very productive and sets dk apart from a few other well known 
applications. What you state in the middle section of your remarks is a 
bit too cryptic to me, I can not figure out what you ment, but where you 
say: ¨imagine the menu bar is gone¨ in favour of working space, that 
scares me. My recent experience with Ubuntu 11.04 and unity 2D with no 
clou where to look or click is very trendy but not productive. Where the 
masses took the wrong direction, we have to think twice.

This being said, the remarks from Gilles are probably more important 
than mine, but it is too cryptic to me, I have not the slightest clou 
what he is saying, so I can not comment on that.

Rinus
On 09-04-11 17:31, Marcel Wiesweg wrote:
> https://bugs.kde.org/show_bug.cgi?id=270168
>
>
>
>
>
> --- Comment #20 from Marcel Wiesweg<marcel wiesweg gmx de>   2011-04-09 17:31:57 ---
> The motivation was to be enable quick action selection from the toolbar
> offering a better overview then the menus can do. Of course, this
> implementation was a "suggestion" waiting for feedback.
>
> I though along these lines:
> - imagine the menu bar is gone
> - offer a lot of screen real estate to get a good overview over available tools
> - selection by as few clicks as possible
> - do not crowd the toolbar
>
> If it is a sub-tab in a specific sidebar, it would be even more hidden than in
> the menus.
> I could imagine a dedicated sidebar tab which hosts the settings if a tool is
> active, and the selection view if no tool is active.
>

> As far as it concerns me it is a wondeful idea, it just has to function, 
> thats all it takes. The fact that anything you need is just there where 
> you expect it, (and if you don´t  know where to find it you can 
> immediatly see it in the clear overview of the ¨select tool¨) makes dk 
> very productive and sets dk apart from a few other well known 
> applications.

Thanks

> but where you 
> say: ¨imagine the menu bar is gone¨ in favour of working space, that 
> scares me. 

We really dont mean to cut the menu bar.
I just assume there are users who dont the menu bar or the context menu, unless told and shown how to do it.

> 
> This being said, the remarks from Gilles are probably more important 
> than mine, but it is too cryptic to me, I have not the slightest clou 
> what he is saying, so I can not comment on that.

No worries.

New discovery concerning this issue might be helpfull to fix

If I highlight an icon in ¨select tool¨ (( which is not easely done 
(because ¨arrow key¨ navigation has issues here too) first click ¨select 
tool¨ second: click ¨icon of choise¨ ,  now ¨icon of choise¨ is selected 
but ¨select tool¨ window disappears, than click ¨select tool¨ again))  
finaly press ¨enter¨ and there you are, so there is obvious a link 
between icon and function.

regards,
Rinus


On 12-04-11 22:04, Marcel Wiesweg wrote:
> https://bugs.kde.org/show_bug.cgi?id=270168
>
>
>
>
>
> --- Comment #22 from Marcel Wiesweg<marcel wiesweg gmx de>   2011-04-12 22:04:36 ---
>
>> As far as it concerns me it is a wondeful idea, it just has to function,
>> thats all it takes. The fact that anything you need is just there where
>> you expect it, (and if you don´t  know where to find it you can
>> immediatly see it in the clear overview of the ¨select tool¨) makes dk
>> very productive and sets dk apart from a few other well known
>> applications.
> Thanks
>
>> but where you
>> say: ¨imagine the menu bar is gone¨ in favour of working space, that
>> scares me.
> We really dont mean to cut the menu bar.
> I just assume there are users who dont the menu bar or the context menu, unless
> told and shown how to do it.
>
>> This being said, the remarks from Gilles are probably more important
>> than mine, but it is too cryptic to me, I have not the slightest clou
>> what he is saying, so I can not comment on that.
> No worries.
>

Git commit 6b0c83af7e100117c9eb75e6b41a5b83da05c229 by Gilles Caulier.
Committed on 15/04/2011 at 15:04.
Pushed by cgilles into branch 'master'.

when an action is selection from menu view, close menu.
CCBUGS: 270168

M  +5    -2    utilities/imageeditor/editor/editorwindow.cpp     
M  +6    -6    utilities/imageeditor/editor/editorwindow_p.h     

http://commits.kde.org/digikam/6b0c83af7e100117c9eb75e6b41a5b83da05c229

Note :

My last commit do not fix the problem. I close the menu when a tool have been selected.

I can reproduce the problem under Windows (KDE 4.5.4) and MacOSX (KDE 4.6.2)

Under Linux, KDE 4.4.5 now, problem is not reproducible.

This is probably due to KDELibs, and especially this different KCategoryDrawer class :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/utilities/imageeditor/editor/editorwindow_p.h#L311

Gilles Caulier

Git commit 95a62117a9b5b9579e75d5eb51a91a26a39464c7 by Marcel Wiesweg.
Committed on 16/04/2011 at 16:08.
Pushed by mwiesweg into branch 'master'.

Simply react on clicked(), skip platform-dependent activated(). Does it work on other OS?

CCBUG: 270168

M  +1    -4    utilities/imageeditor/editor/editorwindow.cpp     

http://commits.kde.org/digikam/95a62117a9b5b9579e75d5eb51a91a26a39464c7

Gilles, regarding your commit: Is there an additional problem on some OS that the menu is not closed but stays open after a click?
After any click, it should activate the clicked tool and close.

Marcel,

Your last commit work perfectly now under Windows (KDE 4.5.4) and MACOSX (KDE 4.6.2)

But her under linux (KDE 4.4.5) menu is not closed after action selection. It due probably of KCategoryDrawerV2 used instead V3 (look editorwindow_p.h)

Gilles Caulier

I have once again added the clicked->close connection to work around this behavior. Normally, Qt makes sure that any click will close the menu.

Yes, now it work too under KDE 4.4.x

Gilles

Thanks for all the hard labor Gilles, Marcel ea. Looking forward to the next beta.
Rinus

(In reply to comment #30)
> Yes, now it work too under KDE 4.4.x
> 
> Gilles