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.
> * 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.
> 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!
(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!
Thank you for your bug report or feature suggestion. The "KOffice" application suite is no longer maintained, and all tickets are now closed. We recommend to switch to the "Calligra" application suite, which has replacements for all unmaintained KOffice applications: - KWord was replaced with Calligra Words - KPlato was replaced with Calligra Plan For more information, see http://en.wikipedia.org/wiki/Calligra_Suite (This is an automatic message from the KDE bug triaging team)