[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    [Bug 187683] The Styles docker doesn't follow established
From:       Jan Hambrecht <jaham () gmx ! net>
Date:       2009-03-24 23:05:59
Message-ID: 20090324230559.2B2F215C94 () immanuel ! kde ! org
[Download RAW message or body]

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@kde.org
To unsubscribe please visit:
https://mail.kde.org/mailman/listinfo/koffice
[prev in list] [next in list] [prev in thread] [next in thread]