Hi all,
I've taken into account all the feedback and have developed a little test program that shows of a number of solutions to replacing the Gimp Spin Scale widget.
A gzipped tar file of the source code is attached so that you can try out the solutions (should be trivial to compile on Linux if you have the Gtk3 libraries). Not all of the solutions fully work as I didn't take the time to make them... but you should be able to get a feel for them. If you run in debug mode (see README) you can interactively add CSS. I've include an example CSS file you can paste into the debug window (ignore the colors, they were just for experimenting).
I've also attached PNGs of the widgets with and without the extra CSS.
The five solutions, from top to bottom, are:
* Custom Gtk::Range widget couple with Gtk::Spinbutton:
This is my current favorite. It works quite well, methinks. Use the 'Alt' key to get into fine adjustment mode. It was rather simple to implement. Could be refined further (add styling properties, rounded corners, etc.).
* Gtk::Scrollbar coupled with Gtk::Spinbutton:
Works rather well, but doesn't show as well the current value. Using a narrow "slider" prevents it from covering up the text (text not implemented yet). I didn't know it before, but if one clicks on the slider and doesn't move for a second or two it enters into a fine- adjustment mode.
* Gkt::ProgressBar coupled with Gtk::Spinbutton:
CSS can get this looking pretty good but some extra work has to be done as the ProgressBar doesn't have an "adjustment", the class that actually handles tracking a value. The Gtk::Spinbutton actually contains a ProgressBar but while one can style it via CSS one can't directly access it and it overlaps the numerical entry part of the SpinButton (this is how the Gimp widget works).
* Subclassed Gtk::Spinbutton:
This is essentially a modified version of the Gimp widget but it has some major flaws as one cannot access the underlying widgets (ProgressBar, Buttons). In this example, the built in ProgressBar is disabled and new code that simulates a narrower ProgressBar has been added. I could not fine a good way to calculate how much narrower the new bar needs to be to not overlap the numerical entry part. Also, when dragging the bar it is easy to highlight the numerical text. The code to do all this is pretty messy.
* Gtk::Scale coupled with Gtk::Spinbutton:
CSS can make this look reasonable. Reducing the size of the circle will prevent it from covering text (text not implemented yet). Gtk::Scale also has a fine-adjustment mode accessed the same was as for a scrollbar.
Tav
At the end there is a tweak for the one I like.
We also need to add a class to the widget box when activate the widget to put in it by css a active state with box-shadow, like the one I remove for spin buttons.
############################CSS TO DEBUG MODE######################## /* You can type here any CSS rule recognised by GTK+. You can temporarily disable this custom CSS by clicking on the “Pause” button above.
Changes are applied instantly and globally, for the whole application. */
/*First hide less liked*/
#MySpinScale4{ opacity:0; } #MySpinScale3{ opacity:0; } #MySpinScale2{ opacity:0; } #MySpinScale1{ opacity:0; }
/*add padding for better look*/ box{ padding:10px; } box box{ padding:0px; }
/*tiny*/ spinbutton, entry, button { min-height: 2px; padding: 2px; margin: 0; }
/*my winner*/
#MySpinScale5 { background: #fff; border:#999; border-style:solid; border-width:1px; border-radius:3px; }
#MySpinScale5 spinbutton { background-color: #fff; border-color:#eee; border-width:0 0 0 1px; border-radius:0 3px 3px 0; box-shadow:none; } #MySpinScale5.activeNotWorkingJet { box-shadow: 0 0 0 1px #8080FF; } #############################################################
Cheers, Jabier.
On Wed, 2017-12-06 at 17:02 +0100, Tavmjong Bah wrote:
Hi all,
I've taken into account all the feedback and have developed a little test program that shows of a number of solutions to replacing the Gimp Spin Scale widget.
A gzipped tar file of the source code is attached so that you can try out the solutions (should be trivial to compile on Linux if you have the Gtk3 libraries). Not all of the solutions fully work as I didn't take the time to make them... but you should be able to get a feel for them. If you run in debug mode (see README) you can interactively add CSS. I've include an example CSS file you can paste into the debug window (ignore the colors, they were just for experimenting).
I've also attached PNGs of the widgets with and without the extra CSS.
The five solutions, from top to bottom, are:
- Custom Gtk::Range widget couple with Gtk::Spinbutton:
This is my current favorite. It works quite well, methinks. Use the 'Alt' key to get into fine adjustment mode. It was rather simple to implement. Could be refined further (add styling properties, rounded corners, etc.).
- Gtk::Scrollbar coupled with Gtk::Spinbutton:
Works rather well, but doesn't show as well the current value. Using a narrow "slider" prevents it from covering up the text (text not implemented yet). I didn't know it before, but if one clicks on the slider and doesn't move for a second or two it enters into a fine- adjustment mode.
- Gkt::ProgressBar coupled with Gtk::Spinbutton:
CSS can get this looking pretty good but some extra work has to be done as the ProgressBar doesn't have an "adjustment", the class that actually handles tracking a value. The Gtk::Spinbutton actually contains a ProgressBar but while one can style it via CSS one can't directly access it and it overlaps the numerical entry part of the SpinButton (this is how the Gimp widget works).
- Subclassed Gtk::Spinbutton:
This is essentially a modified version of the Gimp widget but it has some major flaws as one cannot access the underlying widgets (ProgressBar, Buttons). In this example, the built in ProgressBar is disabled and new code that simulates a narrower ProgressBar has been added. I could not fine a good way to calculate how much narrower the new bar needs to be to not overlap the numerical entry part. Also, when dragging the bar it is easy to highlight the numerical text. The code to do all this is pretty messy.
- Gtk::Scale coupled with Gtk::Spinbutton:
CSS can make this look reasonable. Reducing the size of the circle will prevent it from covering text (text not implemented yet). Gtk::Scale also has a fine-adjustment mode accessed the same was as for a scrollbar.
Tav
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Tav,
Hopefully others can chime in with more feedback, but just wanted to say thanks for tackling it! Looking forward to seeing it in trunk.
Bryce
On Wed, Dec 06, 2017 at 05:02:32PM +0100, Tavmjong Bah wrote:
Hi all,
I've taken into account all the feedback and have developed a little test program that shows of a number of solutions to replacing the Gimp Spin Scale widget.
A gzipped tar file of the source code is attached so that you can try out the solutions (should be trivial to compile on Linux if you have the Gtk3 libraries). Not all of the solutions fully work as I didn't take the time to make them... but you should be able to get a feel for them. If you run in debug mode (see README) you can interactively add CSS. I've include an example CSS file you can paste into the debug window (ignore the colors, they were just for experimenting).
I've also attached PNGs of the widgets with and without the extra CSS.
The five solutions, from top to bottom, are:
Custom Gtk::Range widget couple with Gtk::Spinbutton:
This is my current favorite. It works quite well, methinks. Use the
'Alt' key to get into fine adjustment mode. It was rather simple to implement. Could be refined further (add styling properties, rounded corners, etc.).
Gtk::Scrollbar coupled with Gtk::Spinbutton:
Works rather well, but doesn't show as well the current value. Using
a narrow "slider" prevents it from covering up the text (text not implemented yet). I didn't know it before, but if one clicks on the slider and doesn't move for a second or two it enters into a fine- adjustment mode.
Gkt::ProgressBar coupled with Gtk::Spinbutton:
CSS can get this looking pretty good but some extra work has to be
done as the ProgressBar doesn't have an "adjustment", the class that actually handles tracking a value. The Gtk::Spinbutton actually contains a ProgressBar but while one can style it via CSS one can't directly access it and it overlaps the numerical entry part of the SpinButton (this is how the Gimp widget works).
Subclassed Gtk::Spinbutton:
This is essentially a modified version of the Gimp widget but it has
some major flaws as one cannot access the underlying widgets (ProgressBar, Buttons). In this example, the built in ProgressBar is disabled and new code that simulates a narrower ProgressBar has been added. I could not fine a good way to calculate how much narrower the new bar needs to be to not overlap the numerical entry part. Also, when dragging the bar it is easy to highlight the numerical text. The code to do all this is pretty messy.
Gtk::Scale coupled with Gtk::Spinbutton:
CSS can make this look reasonable. Reducing the size of the circle
will prevent it from covering text (text not implemented yet). Gtk::Scale also has a fine-adjustment mode accessed the same was as for a scrollbar.
Tav
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi all,
First, let me thank all of those who have given feedback! I've got an updated demo taking into account as much of the feedback as possible. A few of the changes:
* Shift replaces Alt to trigger slow-mo mode. * Slow-mo updating glitches fixed. * Order of drawing bar/text changed to give cleaner text. * Improved (and more realisitic styling). * Added a pure Gtk::SpinButton widget for reference (at bottom). * Fixed build instructions.
Some work that still needs to be done:
* Custom styling. I've tried two approaches and can't get either to work (and believe me, I've tried):
* Add custom color styling to a widget (I can add an integer property but nothing else).
* Access the styling of the child widgets in the SpinButton, especially the progress bar widget. I could then use those values for styling the custom progress bar.
* A few modifications are needed to handle right-to-left layout.
From my own experience and from feedback, I am inclined to replace the
Gimp Spin Scale widget with the top-most option. This has a reasonable performance and relatively simple code (20% of the number of lines compared to gimpspinscale.c). The second from bottom is also quite nice (slow-mo mode is triggered by holding the mouse down without moving for a second; it has 10% of the number of lines compared to gimpspinscale.c).
Tav
Hi Tavmjong.
Whats your opinion in change the container type from "Widget" to "Box" or other container you prefear.
https://stackoverflow.com/questions/41344241/gtkmm-c11-how-to-create-a-custo... http://ptomato.name/advanced-gtk-techniques/html/custom-container.html
Cheers, Jabier.
On Mon, 2017-12-11 at 13:35 +0100, Tavmjong Bah wrote:
Hi all,
First, let me thank all of those who have given feedback! I've got an updated demo taking into account as much of the feedback as possible. A few of the changes:
- Shift replaces Alt to trigger slow-mo mode.
- Slow-mo updating glitches fixed.
- Order of drawing bar/text changed to give cleaner text.
- Improved (and more realisitic styling).
- Added a pure Gtk::SpinButton widget for reference (at bottom).
- Fixed build instructions.
Some work that still needs to be done:
- Custom styling. I've tried two approaches and can't get either to
work (and believe me, I've tried):
* Add custom color styling to a widget (I can add an integer property but nothing else).
* Access the styling of the child widgets in the SpinButton, especially the progress bar widget. I could then use those values for styling the custom progress bar.
- A few modifications are needed to handle right-to-left layout.
From my own experience and from feedback, I am inclined to replace the Gimp Spin Scale widget with the top-most option. This has a reasonable performance and relatively simple code (20% of the number of lines compared to gimpspinscale.c). The second from bottom is also quite nice (slow-mo mode is triggered by holding the mouse down without moving for a second; it has 10% of the number of lines compared to gimpspinscale.c).
Tav
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Am 11.12.2017 um 13:35 schrieb Tavmjong Bah:
Hi all,
First, let me thank all of those who have given feedback! I've got an updated demo taking into account as much of the feedback as possible. A few of the changes:
- Shift replaces Alt to trigger slow-mo mode.
Any reason for preferring Shift to Ctrl? Personally I'd consider Ctrl more intuitive (i.e. if I even tried a modifier key to control functionality of a widget, it would be Ctrl, not Shift) and I think others felt the same way. I assume you have a reason, I just have not heard it yet (but you seem to avoid Ctrl by all means ;-) ).
- Slow-mo updating glitches fixed.
Partially confirmed. There is still an issue if one clicks into the slider (-> value jumps to cursor position), then holds down Shift and starts moving the mouse (-> value jumps back to old position).
- Order of drawing bar/text changed to give cleaner text.
Confirmed, much more legible now.
- Improved (and more realisitic styling).
Confirmed (with spinbutton.css) except for 4th and last option where the large margin/padding on top and bottom of the slider still look a bit strange. One might think about making the background of the slider match the background of the numerical input (i.e. white) to achieve an overall more pleasing look; then again having a grayish background for the slider helps differentiate the slider area from the numerical input, so might not be a bad thing after all.
From my own experience and from feedback, I am inclined to replace the Gimp Spin Scale widget with the top-most option. This has a reasonable performance and relatively simple code (20% of the number of lines compared to gimpspinscale.c). The second from bottom is also quite nice (slow-mo mode is triggered by holding the mouse down without moving for a second; it has 10% of the number of lines compared to gimpspinscale.c).
I agree, the top one still seems to be the easiest to use. While UI of the of the second from bottom is OK, too (bullet hides the text, though) personally I don't get the slow-mo mode (same as with the second from top): When activating this mode there is still a small area "in the middle" that scrolls quickly when moving the mouse and moves around making it very unpredictable; when moving the mouse cursor far away it simply scrolls with continuous (very slow) speed.
What I'd still appreciate is some feedback on my earlier question: How do we intend to use this new spin slider widget? It obviously is not suitable as a direct replacement for the spin sliders we currently use in toolboxes due to the larger horizontal width requirement (the old widget was already too wide with gtk3/Adwaita). Do we drop the widget from these locations and use it only in the places were we have enough space available? Do we make the spin sliders wider (which would result in many controls becoming inaccessible if we do not require 21:9 screens)? Do we drop Adwaita and start "doing our own thing"?
Personally I don't see an easy option with the current designs. I actually tried to stack the +/- buttons again which could be realized with CSS (see the win32 theme for an example - you can select it from the "Visual" tab of the gtk inspector) but even then we still do not really gain enough space (and the gtk-devs were not wrong: the buttons become tiny). So maybe it's time to re-think spin slider widgets in toolboxes from the start and I'd say we should brainstorm this before finalizing on any design, otherwise we might just need to start over again once we realize the new widget did not gain us anything except a GPLv2+ licensing...
Best Regards, Eduard
On Tue, 2017-12-12 at 20:09 +0100, Eduard Braun wrote:
Am 11.12.2017 um 13:35 schrieb Tavmjong Bah:
Hi all,
First, let me thank all of those who have given feedback! I've got an updated demo taking into account as much of the feedback as possible. A few of the changes:
- Shift replaces Alt to trigger slow-mo mode.
Any reason for preferring Shift to Ctrl? Personally I'd consider Ctrl more intuitive (i.e. if I even tried a modifier key to control functionality of a widget, it would be Ctrl, not Shift) and I think others felt the same way. I assume you have a reason, I just have not heard it yet (but you seem to avoid Ctrl by all means ;-) ).
No particular reason... I'll switch it to Ctrl (by popular demand).
- Slow-mo updating glitches fixed.
Partially confirmed. There is still an issue if one clicks into the slider (-> value jumps to cursor position), then holds down Shift and starts moving the mouse (-> value jumps back to old position).
I'll look into this...
- Order of drawing bar/text changed to give cleaner text.
Confirmed, much more legible now.
- Improved (and more realisitic styling).
Confirmed (with spinbutton.css) except for 4th and last option where the large margin/padding on top and bottom of the slider still look a bit strange.
One might think about making the background of the slider match the background of the numerical input (i.e. white) to achieve an overall more pleasing look; then again having a grayish background for the slider helps differentiate the slider area from the numerical input, so might not be a bad thing after all.
From my own experience and from feedback, I am inclined to replace the Gimp Spin Scale widget with the top-most option. This has a reasonable performance and relatively simple code (20% of the number of lines compared to gimpspinscale.c). The second from bottom is also quite nice (slow-mo mode is triggered by holding the mouse down without moving for a second; it has 10% of the number of lines compared to gimpspinscale.c).
I agree, the top one still seems to be the easiest to use. While UI of the of the second from bottom is OK, too (bullet hides the text, though) personally I don't get the slow-mo mode (same as with the second from top): When activating this mode there is still a small area "in the middle" that scrolls quickly when moving the mouse and moves around making it very unpredictable; when moving the mouse cursor far away it simply scrolls with continuous (very slow) speed.
What I'd still appreciate is some feedback on my earlier question: How do we intend to use this new spin slider widget? It obviously is not suitable as a direct replacement for the spin sliders we currently use in toolboxes due to the larger horizontal width requirement (the old widget was already too wide with gtk3/Adwaita). Do we drop the widget from these locations and use it only in the places were we have enough space available? Do we make the spin sliders wider (which would result in many controls becoming inaccessible if we do not require 21:9 screens)? Do we drop Adwaita and start "doing our own thing"?
The advantage of CSS is we don't need to drop Adwaita to do our own thing... we can override part of the Adwaita theme. I plan on making the +/- buttons narrow by default.
I've done a search through the GUI and have found that the GimpSpinButton occurs in the following places:
* Objects dialog:
Included via the SimpleFilterModifier widget.
Note: Opacity is handled by a hand-rolled Scale and SpinButton combo.
The SimpleFilterModifier widget should be replaced by the CompositeSetting widget which includes the SimpleFilterModifier widget and a SpinScale widget for opacity.
* Layers dialog:
Included via the CompositeSettings widget.
Note: There are two instances of the CompositeSettings widget here which is strange as the CompositeSettings widget can handle both.
* Fill-Stroke dialog:
Included via the CompositeSettings widget.
* Filter Effects:
Included in various primitive sections via the SpinScale and DualSpinScale widgets. The labels inside the GimpSpinScale widgets are left blank and instead are put in a separate label widget in front of the SpinScale and DualSpinScale widgets. This could be changed to save space.
BTW, There is a spin-slider widget that is still in our code base but hasn't been used since 0.48. It is what the filter effects used then.
I don't see any particular case where we are seriously space constrained but if necessary we can replace the SpinScale by a simple SpinButton.
Personally I don't see an easy option with the current designs. I actually tried to stack the +/- buttons again which could be realized with CSS (see the win32 theme for an example - you can select it from the "Visual" tab of the gtk inspector) but even then we still do not really gain enough space (and the gtk-devs were not wrong: the buttons become tiny). So maybe it's time to re-think spin slider widgets in toolboxes from the start and I'd say we should brainstorm this before finalizing on any design, otherwise we might just need to start over again once we realize the new widget did not gain us anything except a GPLv2+ licensing...
I would be happy to entertain a better solution but in the meantime I'll go ahead with replacing the GimpSpinScale widget now. While it may not be an optimal solution, it is better than what is there now.
Tav
Best Regards, Eduard
Am 13.12.2017 um 15:13 schrieb Tavmjong Bah:
The advantage of CSS is we don't need to drop Adwaita to do our own thing... we can override part of the Adwaita theme. I plan on making the +/- buttons narrow by default.
I thought about that as well, but I realized it's not as easy as it might look initially:
* Modifying part of the CSS quickly leads to inconsistencies in the UI. For example if we change the spinbutton in the new slider widget it will look dissimilar to normal spinbuttons, so we should probably change those, too, and with them probably other buttons/entries and sooner rather than later we end up with *a lot* of custom CSS that will be hard to maintain, especially with the second point in mind: * How can we ensure compatibility with system/custom themes? If we restyle our widgets we easily override CSS from other themes. For example the spinbutton CSS from the test program already broke the win32 theme I was experimenting with and I doubt other themes are more robust...
The only solution I could come up with (and it's not satisfying): Pick one theme (that's about as much as we can maintain) and force Inkscape to use it. Are there any alternatives I overlooked?
I've done a search through the GUI and have found that the GimpSpinButton occurs in the following places:
Objects dialog:
Included via the SimpleFilterModifier widget.
Note: Opacity is handled by a hand-rolled Scale and SpinButton
combo.
The SimpleFilterModifier widget should be replaced by the CompositeSetting widget which includes the SimpleFilterModifier widget and a SpinScale widget for opacity.
Layers dialog:
Included via the CompositeSettings widget.
Note: There are two instances of the CompositeSettings widget here
which is strange as the CompositeSettings widget can handle both.
Fill-Stroke dialog:
Included via the CompositeSettings widget.
Filter Effects:
Included in various primitive sections via the SpinScale and
DualSpinScale widgets. The labels inside the GimpSpinScale widgets are left blank and instead are put in a separate label widget in front of the SpinScale and DualSpinScale widgets. This could be changed to save space.
BTW, There is a spin-slider widget that is still in our code base but hasn't been used since 0.48. It is what the filter effects used then.
I don't see any particular case where we are seriously space constrained but if necessary we can replace the SpinScale by a simple SpinButton.
What about: * tweak toolbar * pen toolbar * calligraphy toolbar * spray toolbar * eraser toolbar * fill toolbar
All of those use the GimpSpinScale, too, and these were the places where I think we actually *are* seriously space constrained. With Adwaita the toolbars are crowded, if not working full screen, many toolbars do not fit and widgets are hidden behind the arrow button to the right which I find extremely inconvenient to use.
Personally I don't see an easy option with the current designs. I actually tried to stack the +/- buttons again which could be realized with CSS (see the win32 theme for an example - you can select it from the "Visual" tab of the gtk inspector) but even then we still do not really gain enough space (and the gtk-devs were not wrong: the buttons become tiny). So maybe it's time to re-think spin slider widgets in toolboxes from the start and I'd say we should brainstorm this before finalizing on any design, otherwise we might just need to start over again once we realize the new widget did not gain us anything except a GPLv2+ licensing...
I would be happy to entertain a better solution but in the meantime I'll go ahead with replacing the GimpSpinScale widget now. While it may not be an optimal solution, it is better than what is there now.
I fully agree that we should move forward eventually and resolving the licensing issue and designing a new widget is much appreciated. If you think we can tailor the widget to resolve the functional concerns in hindsight that's fine by me. With my "respect" for gtk I was just afraid your work might go to waste if we ended up redesigning some aspect of the widget again...
Regards Eduard
Inkscape's speed/increment modifier convention is currently:
Alt = slower increment Shift = faster increment No modifier = normal (default) increment
We should definitely keep this consistent wherever it's possible to do so.
My 2p. -C
On Tue, Dec 12, 2017 at 7:09 PM, Eduard Braun <eduard.braun2@...173...> wrote:
Am 11.12.2017 um 13:35 schrieb Tavmjong Bah:
Hi all,
First, let me thank all of those who have given feedback! I've got an updated demo taking into account as much of the feedback as possible. A few of the changes:
- Shift replaces Alt to trigger slow-mo mode.
Any reason for preferring Shift to Ctrl? Personally I'd consider Ctrl more intuitive (i.e. if I even tried a modifier key to control functionality of a widget, it would be Ctrl, not Shift) and I think others felt the same way. I assume you have a reason, I just have not heard it yet (but you seem to avoid Ctrl by all means ;-) ).
- Slow-mo updating glitches fixed.
Partially confirmed. There is still an issue if one clicks into the slider (-> value jumps to cursor position), then holds down Shift and starts moving the mouse (-> value jumps back to old position).
- Order of drawing bar/text changed to give cleaner text.
Confirmed, much more legible now.
- Improved (and more realisitic styling).
Confirmed (with spinbutton.css) except for 4th and last option where the large margin/padding on top and bottom of the slider still look a bit strange. One might think about making the background of the slider match the background of the numerical input (i.e. white) to achieve an overall more pleasing look; then again having a grayish background for the slider helps differentiate the slider area from the numerical input, so might not be a bad thing after all.
From my own experience and from feedback, I am inclined to replace the Gimp Spin Scale widget with the top-most option. This has a reasonable performance and relatively simple code (20% of the number of lines compared to gimpspinscale.c). The second from bottom is also quite nice (slow-mo mode is triggered by holding the mouse down without moving for a second; it has 10% of the number of lines compared to gimpspinscale.c).
I agree, the top one still seems to be the easiest to use. While UI of the of the second from bottom is OK, too (bullet hides the text, though) personally I don't get the slow-mo mode (same as with the second from top): When activating this mode there is still a small area "in the middle" that scrolls quickly when moving the mouse and moves around making it very unpredictable; when moving the mouse cursor far away it simply scrolls with continuous (very slow) speed.
What I'd still appreciate is some feedback on my earlier question: How do we intend to use this new spin slider widget? It obviously is not suitable as a direct replacement for the spin sliders we currently use in toolboxes due to the larger horizontal width requirement (the old widget was already too wide with gtk3/Adwaita). Do we drop the widget from these locations and use it only in the places were we have enough space available? Do we make the spin sliders wider (which would result in many controls becoming inaccessible if we do not require 21:9 screens)? Do we drop Adwaita and start "doing our own thing"?
Personally I don't see an easy option with the current designs. I actually tried to stack the +/- buttons again which could be realized with CSS (see the win32 theme for an example - you can select it from the "Visual" tab of the gtk inspector) but even then we still do not really gain enough space (and the gtk-devs were not wrong: the buttons become tiny). So maybe it's time to re-think spin slider widgets in toolboxes from the start and I'd say we should brainstorm this before finalizing on any design, otherwise we might just need to start over again once we realize the new widget did not gain us anything except a GPLv2+ licensing...
Best Regards, Eduard
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Am 15.12.2017 um 16:11 schrieb C R:
Inkscape's speed/increment modifier convention is currently:
Alt = slower increment Shift = faster increment No modifier = normal (default) increment
We should definitely keep this consistent wherever it's possible to do so.
My 2p. -C
And where can I find a control in Inkscape that follows this "convention"? If we have a convention I'm totally fine with sticking with it, I'm just not aware of any (and if there is none I personally prefer Ctrl over Shift over Alt). If there is a convention it first of all needs proper documentation, so a) devs are aware of it and have a chance implementing it and b) users will have a chance of being aware of it and use it.
The only related thing I could find: While moving objects around and doing similar tasks we sometimes allow:
* No modifier = default increment * Alt = move by 1 pixel instead of default increment according to keys and mouse reference However this does not only seem to be problematic now that we use mm as default units, it also does not seem to work as advertised: When pressing Alt the change is relative to the current zoom level instead, so it might well be larger as the default increment without modifier * Shift = increase amount by 10 (can be used in any combination)
Maybe you were referring to that? With the confusing behavior it's hardly a convention either, though...
If in the end we really have no convention it might be a good time to think about one!
Best Regards, Eduard
I always felt this Alt/Shift thing was a convention - Ctrl always *restricts* (direction, angle), Shift is for *large steps* (scale, move), and Alt is for *small steps*. This pattern repeats for inset, outset, moving objects, nodes, scaling various things, see https://inkscape.org/en/doc/keys092.html
So Alt for small steps is totally logical to me.
On Linux, to be able to use Alt+Click and many other shortcuts, you need to deactivate Alt as a Window management key anyway (admittedly, that's not nice, we have an extra FAQ item for it...), so I don't really see a new issue here. Alt+Click is even more important than small steps in some slider, and it's only available when you change your window management settings.
Maren
Am 15.12.2017 um 20:00 schrieb Eduard Braun:
Am 15.12.2017 um 16:11 schrieb C R:
Inkscape's speed/increment modifier convention is currently:
Alt = slower increment Shift = faster increment No modifier = normal (default) increment
We should definitely keep this consistent wherever it's possible to do so.
My 2p. -C
And where can I find a control in Inkscape that follows this "convention"? If we have a convention I'm totally fine with sticking with it, I'm just not aware of any (and if there is none I personally prefer Ctrl over Shift over Alt). If there is a convention it first of all needs proper documentation, so a) devs are aware of it and have a chance implementing it and b) users will have a chance of being aware of it and use it.
The only related thing I could find: While moving objects around and doing similar tasks we sometimes allow:
- No modifier = default increment
- Alt = move by 1 pixel instead of default increment according to keys and mouse reference However this does not only seem to be problematic now that we use mm as default units, it also does not seem to work as advertised: When pressing Alt the change is relative to the current zoom level instead, so it might well be larger as the default increment without modifier
- Shift = increase amount by 10 (can be used in any combination)
Maybe you were referring to that? With the confusing behavior it's hardly a convention either, though...
If in the end we really have no convention it might be a good time to think about one!
Best Regards, Eduard
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Am 15.12.2017 um 22:58 schrieb Maren Hachmann:
I always felt this Alt/Shift thing was a convention - Ctrl always *restricts* (direction, angle), Shift is for *large steps* (scale, move), and Alt is for *small steps*. This pattern repeats for inset, outset, moving objects, nodes, scaling various things, see https://inkscape.org/en/doc/keys092.html
So Alt for small steps is totally logical to me.
But that's exactly my point: It's not working like that (it's only - wrongly? - documented like that)! If I open Inkscape at the then default zoom level of (35%) the Alt key causes *larger* steps. Personally I've actually given up using modifiers to move objects as I found it to be unpredictable and typically set numerical values manually when I need precise positioning and can't use snapping for some reason.
All the color sliders (probably the most used ones?) do not allow any control at all. Numerical inputs (i.e. plain spinbuttons) do not allow any control at all.
If we make this a convention (and try to follow it) I'm fine with it, but I hate inconsistent UI that is said to follow conventions that people only *think* exist (because they somehow got used to the quirks) but basically does whatever it wants in most cases leaving users who actually try with logic out in the rain.
The "Ctrl restricts movement" is a valid argument and I would like if it could be adapted for sliders (e.g. 10% steps in a 100% slider or 16/32 steps in 256 value slider).
On Linux, to be able to use Alt+Click and many other shortcuts, you need to deactivate Alt as a Window management key anyway (admittedly, that's not nice, we have an extra FAQ item for it...), so I don't really see a new issue here. Alt+Click is even more important than small steps in some slider, and it's only available when you change your window management settings.
I'm not sure what you're saying here? As an ignorant Windows user I'm hearing "most Linux users are not able to use the Alt key anyway, so why bother? those who figure out how to make it usable can probably figure out what it does, too"... If it really is that hard to get it working - should we really rely on it for central functionality we want to add to a new widget?
Maren
Am 15.12.2017 um 20:00 schrieb Eduard Braun:
Am 15.12.2017 um 16:11 schrieb C R:
Inkscape's speed/increment modifier convention is currently:
Alt = slower increment Shift = faster increment No modifier = normal (default) increment
We should definitely keep this consistent wherever it's possible to do so.
My 2p. -C
And where can I find a control in Inkscape that follows this "convention"? If we have a convention I'm totally fine with sticking with it, I'm just not aware of any (and if there is none I personally prefer Ctrl over Shift over Alt). If there is a convention it first of all needs proper documentation, so a) devs are aware of it and have a chance implementing it and b) users will have a chance of being aware of it and use it.
The only related thing I could find: While moving objects around and doing similar tasks we sometimes allow:
- No modifier = default increment
- Alt = move by 1 pixel instead of default increment according to keys and mouse reference However this does not only seem to be problematic now that we use mm as default units, it also does not seem to work as advertised: When pressing Alt the change is relative to the current zoom level instead, so it might well be larger as the default increment without modifier
- Shift = increase amount by 10 (can be used in any combination)
Maybe you were referring to that? With the confusing behavior it's hardly a convention either, though...
If in the end we really have no convention it might be a good time to think about one!
Best Regards, Eduard
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Am 15.12.2017 um 23:36 schrieb Eduard Braun:
Am 15.12.2017 um 22:58 schrieb Maren Hachmann:
I always felt this Alt/Shift thing was a convention - Ctrl always *restricts* (direction, angle), Shift is for *large steps* (scale, move), and Alt is for *small steps*. This pattern repeats for inset, outset, moving objects, nodes, scaling various things, see https://inkscape.org/en/doc/keys092.html
So Alt for small steps is totally logical to me.
But that's exactly my point: It's not working like that (it's only - wrongly? - documented like that)! If I open Inkscape at the then default zoom level of (35%) the Alt key causes *larger* steps.
- It doesn't for me ... ? Opened Inkscape with new document, drew rectangle, switched to select tool, used Alt+Arrow > small steps, used Shift+Arrow > big steps. Maybe we have discovered a new Windows-only bug? Or which functionality/shortcut did you try?
Personally I've actually given up using modifiers to move objects as I found it to be unpredictable and typically set numerical values manually when I need precise positioning and can't use snapping for some reason.
- I use Alt+arrows as well as Shift+arrows happily. But of course, for me they work ;-)
All the color sliders (probably the most used ones?) do not allow any control at all. Numerical inputs (i.e. plain spinbuttons) do not allow any control at all.
If we make this a convention (and try to follow it) I'm fine with it, but I hate inconsistent UI that is said to follow conventions that people only *think* exist (because they somehow got used to the quirks) but basically does whatever it wants in most cases leaving users who actually try with logic out in the rain.
- I understand (and feel similarly, consistency is great :) )
The "Ctrl restricts movement" is a valid argument and I would like if it could be adapted for sliders (e.g. 10% steps in a 100% slider or 16/32 steps in 256 value slider).
On Linux, to be able to use Alt+Click and many other shortcuts, you need to deactivate Alt as a Window management key anyway (admittedly, that's not nice, we have an extra FAQ item for it...), so I don't really see a new issue here. Alt+Click is even more important than small steps in some slider, and it's only available when you change your window management settings.
I'm not sure what you're saying here? As an ignorant Windows user I'm hearing "most Linux users are not able to use the Alt key anyway, so why bother? those who figure out how to make it usable can probably figure out what it does, too"... If it really is that hard to get it working - should we really rely on it for central functionality we want to add to a new widget?
- It's that I don't consider the slider extra tricks as important as Alt+Click for normal use (there's no simple replacement for Alt+Click, but there's a number entry for the slider) - so, I mean, we are already making it hard for users to access important functionality, what's this in comparison?
It is already problematic now (it's not Linux directly, but some window management systems that use Alt+Click for moving windows, maybe Alt+Drag also doesn't work by default, but not sure), and those who need advanced functionality will have that setting changed already. It seems to be an issue with other graphics applications as well (e.g. Blender and Maya seem to be affected by this choice, too).
Those who haven't changed the setting (or don't know about it) will miss out on both functions (or even more), yes. Usually, people notice when they want to select an object that is below another one, after reading documentation. And yes, that's sad... But it's hard to change that shortcut after the fact...
I personally find the consistency more important here - but I understand if you don't agree.
Maren
Maren
Am 15.12.2017 um 20:00 schrieb Eduard Braun:
Am 15.12.2017 um 16:11 schrieb C R:
Inkscape's speed/increment modifier convention is currently:
Alt = slower increment Shift = faster increment No modifier = normal (default) increment
We should definitely keep this consistent wherever it's possible to do so.
My 2p. -C
And where can I find a control in Inkscape that follows this "convention"? If we have a convention I'm totally fine with sticking with it, I'm just not aware of any (and if there is none I personally prefer Ctrl over Shift over Alt). If there is a convention it first of all needs proper documentation, so a) devs are aware of it and have a chance implementing it and b) users will have a chance of being aware of it and use it.
The only related thing I could find: While moving objects around and doing similar tasks we sometimes allow:
* No modifier = default increment * Alt = move by 1 pixel instead of default increment according to keys and mouse reference However this does not only seem to be problematic now that we use mm as default units, it also does not seem to work as advertised: When pressing Alt the change is relative to the current zoom level instead, so it might well be larger as the default increment without modifier * Shift = increase amount by 10 (can be used in any combination)
Maybe you were referring to that? With the confusing behavior it's hardly a convention either, though...
If in the end we really have no convention it might be a good time to think about one!
Best Regards, Eduard
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Am 16.12.2017 um 01:24 schrieb Maren Hachmann:
Am 15.12.2017 um 23:36 schrieb Eduard Braun:
Am 15.12.2017 um 22:58 schrieb Maren Hachmann:
I always felt this Alt/Shift thing was a convention - Ctrl always *restricts* (direction, angle), Shift is for *large steps* (scale, move), and Alt is for *small steps*. This pattern repeats for inset, outset, moving objects, nodes, scaling various things, see https://inkscape.org/en/doc/keys092.html
So Alt for small steps is totally logical to me.
But that's exactly my point: It's not working like that (it's only - wrongly? - documented like that)! If I open Inkscape at the then default zoom level of (35%) the Alt key causes *larger* steps.
- It doesn't for me ... ? Opened Inkscape with new document, drew
rectangle, switched to select tool, used Alt+Arrow > small steps, used Shift+Arrow > big steps. Maybe we have discovered a new Windows-only bug? Or which functionality/shortcut did you try?
I compared Arrow (without modifier) and Alt + Arrow. The modifier-less variant resulted in smaller steps (0.529 mm) than the variant with Alt (0.756 mm). Holding Shift additionally will multiply by ten in both cases (i.e. 7.559 mm and 5.292 mm respectively).
The problem (or at least the behavior that always confused me) is that the variant with alt changes with the zoom level (i.e. at 70% zoom instead of 35% zoom I get 0.378 mm steps which is exactly half the step size from above). I'd have to look into the code to understand what is going on here, but Alt + Arrow certainly does not seem to move "by one px". If I had to guess it might mean "1 px on the monitor" but that seems like a pretty arbitrary value that will not likely relate to any lengths in the document...).
Personally I've actually given up using modifiers to move objects as I found it to be unpredictable and typically set numerical values manually when I need precise positioning and can't use snapping for some reason.
- I use Alt+arrows as well as Shift+arrows happily. But of course, for
me they work ;-)
All the color sliders (probably the most used ones?) do not allow any control at all. Numerical inputs (i.e. plain spinbuttons) do not allow any control at all.
If we make this a convention (and try to follow it) I'm fine with it, but I hate inconsistent UI that is said to follow conventions that people only *think* exist (because they somehow got used to the quirks) but basically does whatever it wants in most cases leaving users who actually try with logic out in the rain.
- I understand (and feel similarly, consistency is great :) )
The "Ctrl restricts movement" is a valid argument and I would like if it could be adapted for sliders (e.g. 10% steps in a 100% slider or 16/32 steps in 256 value slider).
On Linux, to be able to use Alt+Click and many other shortcuts, you need to deactivate Alt as a Window management key anyway (admittedly, that's not nice, we have an extra FAQ item for it...), so I don't really see a new issue here. Alt+Click is even more important than small steps in some slider, and it's only available when you change your window management settings.
I'm not sure what you're saying here? As an ignorant Windows user I'm hearing "most Linux users are not able to use the Alt key anyway, so why bother? those who figure out how to make it usable can probably figure out what it does, too"... If it really is that hard to get it working - should we really rely on it for central functionality we want to add to a new widget?
- It's that I don't consider the slider extra tricks as important as
Alt+Click for normal use (there's no simple replacement for Alt+Click, but there's a number entry for the slider) - so, I mean, we are already making it hard for users to access important functionality, what's this in comparison?
It is already problematic now (it's not Linux directly, but some window management systems that use Alt+Click for moving windows, maybe Alt+Drag also doesn't work by default, but not sure), and those who need advanced functionality will have that setting changed already. It seems to be an issue with other graphics applications as well (e.g. Blender and Maya seem to be affected by this choice, too).
Those who haven't changed the setting (or don't know about it) will miss out on both functions (or even more), yes. Usually, people notice when they want to select an object that is below another one, after reading documentation. And yes, that's sad... But it's hard to change that shortcut after the fact...
I personally find the consistency more important here - but I understand if you don't agree.
Maren
Maren
Am 15.12.2017 um 20:00 schrieb Eduard Braun:
Am 15.12.2017 um 16:11 schrieb C R:
Inkscape's speed/increment modifier convention is currently:
Alt = slower increment Shift = faster increment No modifier = normal (default) increment
We should definitely keep this consistent wherever it's possible to do so.
My 2p. -C
And where can I find a control in Inkscape that follows this "convention"? If we have a convention I'm totally fine with sticking with it, I'm just not aware of any (and if there is none I personally prefer Ctrl over Shift over Alt). If there is a convention it first of all needs proper documentation, so a) devs are aware of it and have a chance implementing it and b) users will have a chance of being aware of it and use it.
The only related thing I could find: While moving objects around and doing similar tasks we sometimes allow:
* No modifier = default increment * Alt = move by 1 pixel instead of default increment according to keys and mouse reference However this does not only seem to be problematic now that we use mm as default units, it also does not seem to work as advertised: When pressing Alt the change is relative to the current zoom level instead, so it might well be larger as the default increment without modifier * Shift = increase amount by 10 (can be used in any combination)
Maybe you were referring to that? With the confusing behavior it's hardly a convention either, though...
If in the end we really have no convention it might be a good time to think about one!
Best Regards, Eduard
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Am 16.12.2017 um 01:47 schrieb Eduard Braun:
I compared Arrow (without modifier) and Alt + Arrow. The modifier-less variant resulted in smaller steps (0.529 mm) than the variant with Alt (0.756 mm). Holding Shift additionally will multiply by ten in both cases (i.e. 7.559 mm and 5.292 mm respectively).
- Ah. Yes, Alt / Shift modified movements are screen pixels, and get finer when you zoom in, and rougher when you zoom out, while arrow movements move by a set amount of document pixels (that you can change in the settings). That's true (but doesn't change the relationship between Alt + Shift). And it also appears inconsistent - but inconsistent to make things more convenient... if that makes any sense.
It is documented correctly: https://inkscape.org/en/doc/keys092.html#d0e2698
Maren
Am 16.12.2017 um 01:59 schrieb Maren Hachmann:
Am 16.12.2017 um 01:47 schrieb Eduard Braun:
I compared Arrow (without modifier) and Alt + Arrow. The modifier-less variant resulted in smaller steps (0.529 mm) than the variant with Alt (0.756 mm). Holding Shift additionally will multiply by ten in both cases (i.e. 7.559 mm and 5.292 mm respectively).
- Ah. Yes, Alt / Shift modified movements are screen pixels, and get
finer when you zoom in, and rougher when you zoom out, while arrow movements move by a set amount of document pixels (that you can change in the settings). That's true (but doesn't change the relationship between Alt + Shift). And it also appears inconsistent - but inconsistent to make things more convenient... if that makes any sense.
Not really, sorry... It's one of the "quirks" which makes Inkscape unnecessarily hard to use for the uninitiated. While I'm a proponent of pixels as document units I really don't think screen pixels are ever a useful measure for manipulating objects in the document.
I can understand the potential need for absolute movements and relative movements depending on zoom level but in both cases it should be proportional to document units. In the latter case the relative amount should be something like 1/zoom_level * document_units (e.g. at 100% zoom level Alt+arrow would move by 1 mm if document units are set to mm and at 1000% zoom level Alt+arrow would move by 0.1 mm. If document units are changed to px at 100% zoom level Alt+Arrow would move by 1 px, etc.).
Does anybody think this would be a bad idea (I almost don't dare to ask, but the current behavior gives me the shivers...)?
It is documented correctly: https://inkscape.org/en/doc/keys092.html#d0e2698
It does not mention anywhere pixels in the Alt-case are actual screen pixels (it only mentions they are *not* screen pixels in the case without modifiers - which I believe makes most people assume the same for the Alt-case where it's plain wrong)... At some point I realized that this must be the reason for the "inexplicable" behavior but without guessing it remains a mystery in my opinion.
Maren
Am 16.12.2017 um 03:09 schrieb Eduard Braun:
Am 16.12.2017 um 01:59 schrieb Maren Hachmann:
Am 16.12.2017 um 01:47 schrieb Eduard Braun:
I compared Arrow (without modifier) and Alt + Arrow. The modifier-less variant resulted in smaller steps (0.529 mm) than the variant with Alt (0.756 mm). Holding Shift additionally will multiply by ten in both cases (i.e. 7.559 mm and 5.292 mm respectively).
- Ah. Yes, Alt / Shift modified movements are screen pixels, and get
finer when you zoom in, and rougher when you zoom out, while arrow movements move by a set amount of document pixels (that you can change in the settings). That's true (but doesn't change the relationship between Alt + Shift). And it also appears inconsistent - but inconsistent to make things more convenient... if that makes any sense.
Not really, sorry... It's one of the "quirks" which makes Inkscape unnecessarily hard to use for the uninitiated. While I'm a proponent of pixels as document units I really don't think screen pixels are ever a useful measure for manipulating objects in the document.
I can understand the potential need for absolute movements and relative movements depending on zoom level but in both cases it should be proportional to document units. In the latter case the relative amount should be something like 1/zoom_level * document_units (e.g. at 100% zoom level Alt+arrow would move by 1 mm if document units are set to mm and at 1000% zoom level Alt+arrow would move by 0.1 mm. If document units are changed to px at 100% zoom level Alt+Arrow would move by 1 px, etc.).
Does anybody think this would be a bad idea (I almost don't dare to ask, but the current behavior gives me the shivers...)?
- Me... I like the current behaviour, because it allows me to move by the smallest visible distance, and that's often what I want (but I like how your suggestion is consistent). But probably that question should be asked in a different thread on the user mailing list, because you could get some more representative feedback from the user base.
It is documented correctly: https://inkscape.org/en/doc/keys092.html#d0e2698
It does not mention anywhere pixels in the Alt-case are actual screen pixels (it only mentions they are *not* screen pixels in the case without modifiers - which I believe makes most people assume the same for the Alt-case where it's plain wrong)... At some point I realized that this must be the reason for the "inexplicable" behavior but without guessing it remains a mystery in my opinion.
- Mhm, now that you say it, I can see how it can be confusing. I've just inferred the intended meaning, when I encountered it while translating the document. But we can make that better now, whatever way it will be :) (thanks to all the work you invested into the docs repo).
Maren
Maren
participants (6)
-
Bryce Harrington -
C R -
Eduard Braun -
Jabier Arraiza -
Maren Hachmann -
Tavmjong Bah