[Digikam-devel] [PATCH] use a QListBox rather than a set of radio buttons for b&w plugin

[Guillaume Laurent]

I'd like to request permission to commit the attached patch (I have svn commit
access). It replaces the radio buttons used in the b&w plugin by a QListBox,
which makes it much easier to rapidly go through the various possible
effects. Note that the 'what's this' info is still handled correctly.

--
Guillaume.
http://www.telegraph-road.org

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

Le Samedi 29 Avril 2006 11:01, Guillaume Laurent a écrit :
> I'd like to request permission to commit the attached patch (I have svn
> commit access). It replaces the radio buttons used in the b&w plugin by a
> QListBox, which makes it much easier to rapidly go through the various
> possible effects.

Witch avantage provides QListBox instead QRadioButton. Actually, the radio
buttons group have the focus when the dialog is displayed and you can choose
the right effetc using up/down keyboard keys.

> Note that the 'what's this' info is still handled
> correctly.

What's wrong in the current implementation about this point ?

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Guillaume Laurent]

On Saturday 29 April 2006 13:35, Gilles Caulier wrote:
> Le Samedi 29 Avril 2006 11:01, Guillaume Laurent a écrit :
> > I'd like to request permission to commit the attached patch (I have svn
> > commit access). It replaces the radio buttons used in the b&w plugin by a
> > QListBox, which makes it much easier to rapidly go through the various
> > possible effects.
>
> Witch avantage provides QListBox instead QRadioButton. Actually, the radio
> buttons group have the focus when the dialog is displayed and you can
> choose the right effetc using up/down keyboard keys.

In general, radio buttons are not meant to represent a list of more than 3 or
4 choices. When using the mouse, they are harder to aim at than list choices
(you can click "between" two buttons, or too far to the right, you can't with
list items).
Also giving focus to the button group doesn't really help, as it doesn't keep
in sync with mouse clicks : if you click on one of the buttons, and then use
the arrow keys, the button which gets activated isn't the one next to the one
you clicked on as you would expect, and you have to use the space bar to
actually select it.

Finally, another improvement I'd like to make whenever I have the time is to
let the user create and store his own channel mixer settings. Radio buttons
wouldn't cope with that.

> > Note that the 'what's this' info is still handled
> > correctly.
>
> What's wrong in the current implementation about this point ?

Nothing, what I meant is that I took care that the 'what's this' info is still
working with my patch (not completely trivial given that QListBoxItems aren't
QWidgets).

--
Guillaume.
http://www.telegraph-road.org
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Guillaume Laurent]

Any further input on this one ? OK to commit ?

--
Guillaume.
http://www.telegraph-road.org
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

Le Lundi 01 Mai 2006 11:42 AM, Guillaume Laurent a écrit :
> Any further input on this one ? OK to commit ?

Well, i'm not favorable. In the future, I will separate B&W Color Filter
options and Change Tonality options using a new tab. For these last one, i
will add a new option to set the color to use with tonality algorithm. Also,
the B&W and Tonlaity filter will be used at the same time if you want.

In other words, the actual options availalble with the radio button will be
decomposed to 2 settings area.

Also, i have talk about this subject with some digiKam users using IM this
week end. The current Radio button sounds good...

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

> In other words, the actual options availalble with the radio button will be
> decomposed to 2 settings area.

nice ! but i don't understand why it is an argument against the listbox
? why not two listboxes ?

> Also, i have talk about this subject with some digiKam users using IM this
> week end. The current Radio button sounds good...
>

IMHO i also prefer the listbox as it used to be, because it is easier to
use the keybord to quickly test which filter is the best for your picture.

my 2 cents.

Julien
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

Le Lundi 01 Mai 2006 10:29 PM, Julien Narboux a écrit :

> > In other words, the actual options availalble with the radio button will
> > be decomposed to 2 settings area.
>
> nice ! but i don't understand why it is an argument against the listbox
> ? why not two listboxes ?
>
> > Also, i have talk about this subject with some digiKam users using IM
> > this week end. The current Radio button sounds good...
>
> IMHO i also prefer the listbox as it used to be, because it is easier to
> use the keybord to quickly test which filter is the best for your picture.
>

In trunk the plugin give the keyboard focus to the radio button list at
startup. If you use up/down keys, you can test options like QListBox.

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Guillaume Laurent]

On Monday 01 May 2006 14:51, Caulier Gilles wrote:

> In other words, the actual options availalble with the radio button will be
> decomposed to 2 settings area.

As Julien said, I don't see how that prevents you from using a listbox... may
be I don't understand what you have in mind.

> Also, i have talk about this subject with some digiKam users using IM this
> week end. The current Radio button sounds good...

I suggest they try the listbox scheme first and see what they prefer, you
should too. This w-e I just did about a dozen of b&w shots using my listbox
patch, it's really much smoother than the radio buttons.

Another improvement would be to display several filter results at the same
time so you can more easily compare between them, rather than just seeing one
effect at a time.

--
Guillaume.
http://www.telegraph-road.org
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Guillaume Laurent]

On Monday 01 May 2006 23:20, Caulier Gilles wrote:
>
> In trunk the plugin give the keyboard focus to the radio button list at
> startup. If you use up/down keys, you can test options like QListBox.

As I said, this doesn't really work and is thrown off as soon as you try using
the mouse.

--
Guillaume.
http://www.telegraph-road.org
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Guillaume Laurent]

On Tuesday 02 May 2006 00:02, Guillaume Laurent wrote:
>
> Another improvement would be to display several filter results at the same
> time so you can more easily compare between them, rather than just seeing
> one effect at a time.

Since the QListBox can do that, I gave it a try. Here's a modified version of
my previous patch which displays a thumbnail of the applied effect. See
attached screenshot for a better idea.

BTW, if I may make a code style comment, the following construct :

if (foo)
    delete foo;

is not necessary, 'delete 0' is a no-op, so just 'delete foo' will work just
as well.

--
Guillaume.
http://www.telegraph-road.org

[Gilles Caulier-2]

Le Mardi 09 Mai 2006 12:27 AM, Guillaume Laurent a écrit :
> On Tuesday 02 May 2006 00:02, Guillaume Laurent wrote:
> > Another improvement would be to display several filter results at the
> > same time so you can more easily compare between them, rather than just
> > seeing one effect at a time.
>
> Since the QListBox can do that, I gave it a try. Here's a modified version
> of my previous patch which displays a thumbnail of the applied effect. See
> attached screenshot for a better idea.
>

Accepted. In this case, the QListBox have a sence for me.

It's possible to have the same preview into Color Autocorrection tool ?
(:=)))...

> BTW, if I may make a code style comment, the following construct :
>
> if (foo)
>     delete foo;
>
> is not necessary, 'delete 0' is a no-op, so just 'delete foo' will work
> just as well.

Yes, this is the story of an old code (:=)))...

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Guillaume Laurent]

On Tuesday 09 May 2006 01:40, Caulier Gilles wrote:

> Le Mardi 09 Mai 2006 12:27 AM, Guillaume Laurent a écrit :
> > On Tuesday 02 May 2006 00:02, Guillaume Laurent wrote:
> > > Another improvement would be to display several filter results at the
> > > same time so you can more easily compare between them, rather than just
> > > seeing one effect at a time.
> >
> > Since the QListBox can do that, I gave it a try. Here's a modified
> > version of my previous patch which displays a thumbnail of the applied
> > effect. See attached screenshot for a better idea.
>
> Accepted. In this case, the QListBox have a sence for me.

Thanks. I took the liberty to commit a couple of tweaks :

- a small (5 pixels) margin around the items
- make the items larger (otherwise the differences between the various
green/red... filters are very hard to see)
- make the listbox stretchable vertically

> It's possible to have the same preview into Color Autocorrection tool ?
> (:=)))...

I can try :-)

--
Guillaume.
http://www.telegraph-road.org
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

Le Mardi 09 Mai 2006 01:40 AM, Caulier Gilles a écrit :

> Le Mardi 09 Mai 2006 12:27 AM, Guillaume Laurent a écrit :
> > On Tuesday 02 May 2006 00:02, Guillaume Laurent wrote:
> > > Another improvement would be to display several filter results at the
> > > same time so you can more easily compare between them, rather than just
> > > seeing one effect at a time.
> >
> > Since the QListBox can do that, I gave it a try. Here's a modified
> > version of my previous patch which displays a thumbnail of the applied
> > effect. See attached screenshot for a better idea.
>
> Accepted. In this case, the QListBox have a sence for me.
>
> It's possible to have the same preview into Color Autocorrection tool ?
> (:=)))...

I have completed some optimizations in svn. Please take a look before to
update Auto Color correction (if you want to do)...

Gilles





_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Guillaume Laurent]

On Tuesday 09 May 2006 10:36, Caulier Gilles wrote:
>
> I have completed some optimizations in svn. Please take a look before to
> update Auto Color correction (if you want to do)...

OK, much simpler indeed. However I'd set the smoothScale to 256,256 for the
thumbnail, 128,128 looks a bit too small here (it may depend on the
resolution though, I have 1600x1200... perhaps make it configurable ?)

--
Guillaume.
http://www.telegraph-road.org
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Dnia wtorek, 9 maja 2006 11:14, Guillaume Laurent napisał:
> On Tuesday 09 May 2006 10:36, Caulier Gilles wrote:
> > I have completed some optimizations in svn. Please take a look before
> > to update Auto Color correction (if you want to do)...
>
> OK, much simpler indeed. However I'd set the smoothScale to 256,256 for
> the thumbnail, 128,128 looks a bit too small here (it may depend on the
> resolution though, I have 1600x1200... perhaps make it configurable ?)

Better try to guess screen resolution and set size of thumbnail
appropriately. Configuration could be made somewhere in configuration
files, definitely no need to clutter GUI with that.

m.

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

On Tuesday 09 May 2006 11:14, Guillaume Laurent wrote:
> On Tuesday 09 May 2006 10:36, Caulier Gilles wrote:
> >
> > I have completed some optimizations in svn. Please take a look before to
> > update Auto Color correction (if you want to do)...
>
> OK, much simpler indeed. However I'd set the smoothScale to 256,256 for the
> thumbnail, 128,128 looks a bit too small here (it may depend on the
> resolution though, I have 1600x1200... perhaps make it configurable ?)

How about coupling the size to the icons size in Album view?
I one prefers bigger/smaller icons, due to hires screen, bad eyes
or personal preference, one case assume that this for the preview
icons too.

Achim
>
> --
> Guillaume.
> http://www.telegraph-road.org

--
  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
                                      -- [hidden email]
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

Le Mardi 09 Mai 2006 11:14 AM, Guillaume Laurent a écrit :
> On Tuesday 09 May 2006 10:36, Caulier Gilles wrote:
> > I have completed some optimizations in svn. Please take a look before to
> > update Auto Color correction (if you want to do)...
>
> OK, much simpler indeed. However I'd set the smoothScale to 256,256 for the
> thumbnail, 128,128 looks a bit too small here (it may depend on the
> resolution though, I have 1600x1200... perhaps make it configurable ?)

No need a new configuration here. Like Achim said we can using album item size
configuration for that. A new configuration can be confuse for end users
because there are already a lot of settings in digiKam. We must take a care.

Here on my laptop (1024x768), 256x256 thumbs size is too large. This is why i
have set a fixed 128x128 size.

But, in all case, i recommend you to wait users feedback from B.K.o or ML
before to use album configuration. If we need to do, it will be easy.

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Dnia wtorek, 9 maja 2006 11:14, Guillaume Laurent napisał:
> On Tuesday 09 May 2006 10:36, Caulier Gilles wrote:
> > I have completed some optimizations in svn. Please take a look before
> > to update Auto Color correction (if you want to do)...
>
> OK, much simpler indeed. However I'd set the smoothScale to 256,256 for
> the thumbnail, 128,128 looks a bit too small here (it may depend on the
> resolution though, I have 1600x1200... perhaps make it configurable ?)

I have 1152x864 and found 128,128 a bit too big. Changed in source for
96,96 and feel better - more images to compare in scroll box. Don't have
to see details, rather compare feeling of picture. But 96 in my
resolution is ca. 1/9 of height, for you it would be 133. No matching
rule here :(

Apart from that: great feature and it would be fantastic to see it in
similar plugins.

m.

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

Le Mardi 09 Mai 2006 09:37 PM, Mikolaj Machowski a écrit :

> Dnia wtorek, 9 maja 2006 11:14, Guillaume Laurent napisał:
> > On Tuesday 09 May 2006 10:36, Caulier Gilles wrote:
> > > I have completed some optimizations in svn. Please take a look before
> > > to update Auto Color correction (if you want to do)...
> >
> > OK, much simpler indeed. However I'd set the smoothScale to 256,256 for
> > the thumbnail, 128,128 looks a bit too small here (it may depend on the
> > resolution though, I have 1600x1200... perhaps make it configurable ?)
>
> I have 1152x864 and found 128,128 a bit too big.

And me 1024x768, and 128x128 is the minimal size to see some differences
betwen effect preview, else the image is too small...

> Changed in source for
> 96,96 and feel better - more images to compare in scroll box. Don't have
> to see details, rather compare feeling of picture. But 96 in my
> resolution is ca. 1/9 of height, for you it would be 133. No matching
> rule here :(
>
> Apart from that: great feature and it would be fantastic to see it in
> similar plugins.

Yes, but let's Guillaume finalize the code. After we can create a shared
widget for that in digikam/libs/widgets/imageplugins...

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gerhard Kulzer]

On Tuesday 9 May 2006 11:14, Guillaume Laurent wrote:
> On Tuesday 09 May 2006 10:36, Caulier Gilles wrote:
> > I have completed some optimizations in svn. Please take a look before to
> > update Auto Color correction (if you want to do)...
>
> OK, much simpler indeed. However I'd set the smoothScale to 256,256 for the
> thumbnail, 128,128 looks a bit too small here (it may depend on the
> resolution though, I have 1600x1200... perhaps make it configurable ?)

Gilles and Guillaume,
I'd like to inject again my wish here for separating the filters
(neutral...yellow) from the coloring (sepia...platinum) so as the coloring
can be applied as a second action on top of the filtering. Then we would need
two of those boxes. If looked at the code myself, but I feel not quite up to
that.

Can also wait for later release.

Gerhard
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel