[Bug 187683] New: The Styles docker doesn't follow established interaction rules

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

           Summary: The Styles docker doesn't follow established
                    interaction rules
           Product: koffice
           Version: unspecified
          Platform: Compiled Sources
        OS/Version: unspecified
            Status: NEW
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: koffice@...
        ReportedBy: zander@...


Version:            (using Devel)
Installed from:    Compiled sources

The docker has some odd issues

* The gradient option shows a combobox. But that widget doesn't behave like a
combobox.
Unlike any combobox clicking on the content section will apply the current
selection and you can only change the selection by clicking on the little
arrow.
I suggest to use the concept that people learned in plasma and the web;
clicking on the combobox will open it and only when the user accepts the (new)
item in the list will it be applied. (allowing esc to back out).

* When I am in solid color editing mode I see a big button with a tiny color
patch and next to that a very small button with an arrow.
This kind of looks like a combobox again and in that regard it has the same
interaction problems as the above.
Instead I suggest to have a normal size color botton and next use a normal
toolbutton next to it to popup the color selector widget.  This is in line with
common usage of the widgets we use here.

As I'm too lazy to open another bugreport;
* The even-odd fill and the winding fill buttons seem to have no functionality.
* The border editing mode should disable buttons like the gradient one since
they are useless then.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
____________________________________
koffice mailing list
koffice@...
To unsubscribe please visit:
https://mail.kde.org/mailman/listinfo/koffice

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


Jan Hambrecht <jaham@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jaham@...




--- Comment #1 from Jan Hambrecht <jaham gmx net>  2009-03-24 23:14:49 ---
> * The gradient option shows a combobox. But that widget doesn't behave like a
> combobox.
> Unlike any combobox clicking on the content section will apply the current
> selection and you can only change the selection by clicking on the little
> arrow.
> I suggest to use the concept that people learned in plasma and the web;
> clicking on the combobox will open it and only when the user accepts the (new)
> item in the list will it be applied. (allowing esc to back out).

The click on the content section was implemented to _not_ force the user to
open the combobox and choosing the gradient if they just want to appply the
currently displayed gradient. Not using a button was done to save some space
and because there are alreday a lot of buttons present.

>
> * When I am in solid color editing mode I see a big button with a tiny color
> patch and next to that a very small button with an arrow.
> This kind of looks like a combobox again and in that regard it has the same
> interaction problems as the above.
> Instead I suggest to have a normal size color botton and next use a normal
> toolbutton next to it to popup the color selector widget.  This is in line with
> common usage of the widgets we use here.

It is actually a toolbutton with a the color popup action set.

>
> As I'm too lazy to open another bugreport;
> * The even-odd fill and the winding fill buttons seem to have no functionality.
> * The border editing mode should disable buttons like the gradient one since
> they are useless then.

Well they have functionality but only for path shapes (and derived shapes), as
only these have the fillrule property.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
____________________________________
koffice mailing list
koffice@...
To unsubscribe please visit:
https://mail.kde.org/mailman/listinfo/koffice

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





--- Comment #2 from Thomas Zander <zander kde org>  2009-03-24 23:43:35 ---
> The click on the content section was implemented to _not_ force the user to
> open the combobox and choosing the gradient if they just want to appply the
> currently displayed gradient.

Ah, yes. I see the issue. You want to save a click for the common case.
I do think that the result is actually not an improvement as the normally
harmless click on a combobox is now causing a commit in the docker that
otherwise would purely be innocent.

I'm not sure what the perfect solution here is, but I would like to suggest we
follow the expected interaction rules of known widgets.  If we stop being
consistent with other similar looking widgets, we just hurt the users.

> Not using a button was done to save some space
> and because there are alreday a lot of buttons present.

Yeah, makes sense. Though I think the solution is not perfect yet and I would
honestly think an extra button is better than having an out of place widget
(interaction wise).

> > Instead I suggest to have a normal size color botton and next use a normal
> > toolbutton next to it to popup the color selector widget.
> It is actually a toolbutton with a the color popup action set.

Interestingly, it doesn't look like one. I don't know what was done to make it
look so much thinner, but it looks really odd.  I noticed it looks quite
different under oxygen than under other styles (we want to support all, I
believe).
So I would suggest making it *look* like a default qtoolbutton as that leads to
least surprises.

> Well they have functionality but only for path shapes (and derived shapes),
> as only these have the fillrule property.

Would it be possible to hide the buttons if those shapes are not in the
selection?  I believe that would help in applications like KWord where for
various usecases path shapes are never touched. Just text and image shapes.

Thanks!

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
____________________________________
koffice mailing list
koffice@...
To unsubscribe please visit:
https://mail.kde.org/mailman/listinfo/koffice

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





--- Comment #3 from Jan Hambrecht <jaham gmx net>  2009-03-25 00:05:56 ---
(In reply to comment #2)

> > The click on the content section was implemented to _not_ force the user to
> > open the combobox and choosing the gradient if they just want to appply the
> > currently displayed gradient.
>
> Ah, yes. I see the issue. You want to save a click for the common case.
> I do think that the result is actually not an improvement as the normally
> harmless click on a combobox is now causing a commit in the docker that
> otherwise would purely be innocent.
>
> I'm not sure what the perfect solution here is, but I would like to suggest we
> follow the expected interaction rules of known widgets.  If we stop being
> consistent with other similar looking widgets, we just hurt the users.
>
> > Not using a button was done to save some space
> > and because there are alreday a lot of buttons present.
>
> Yeah, makes sense. Though I think the solution is not perfect yet and I would
> honestly think an extra button is better than having an out of place widget
> (interaction wise).

As for 2.1 there is going to be a style tool handling all this i think it
should be handled then.

>
> > > Instead I suggest to have a normal size color botton and next use a normal
> > > toolbutton next to it to popup the color selector widget.
> > It is actually a toolbutton with a the color popup action set.
>
> Interestingly, it doesn't look like one. I don't know what was done to make it
> look so much thinner, but it looks really odd.  I noticed it looks quite
> different under oxygen than under other styles (we want to support all, I
> believe).
> So I would suggest making it *look* like a default qtoolbutton as that leads to
> least surprises.

You have to talk to boemann about this, as this is the KoColorPopupAction which
he implemented.

>
> > Well they have functionality but only for path shapes (and derived shapes),
> > as only these have the fillrule property.
>
> Would it be possible to hide the buttons if those shapes are not in the
> selection?  I believe that would help in applications like KWord where for
> various usecases path shapes are never touched. Just text and image shapes.

Sure.

>
> Thanks!

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
____________________________________
koffice mailing list
koffice@...
To unsubscribe please visit:
https://mail.kde.org/mailman/listinfo/koffice