Re: Spin slider widget, redux.

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Spin slider widget, redux.

Mark Crutch-2
I got it to build on my Ubuntu Mate 16.04 system. Here are my observations:

* 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.).

With a white background and 1px dark grey border this looks pretty good. It does, at least, then look like a single composite widget, rather than a group of separate widgets. I am seeing major redraw problems with the bar, however.

I'm not convinced by Alt to get into fine adjustment mode. A lot of Linux window managers use Alt-drag to move windows around by default - this is already a problem in some areas of Inkscape use, but having to work around it for every slider in the application would be a pain. Perhaps use Ctrl or Shift instead?

(I also notice that pressing Alt when already dragging sets the value to 0, rather than switching to "fine control" from the current position. Not a concern for this test, but worth bearing in mind for the final thing)

 
* Gtk::Scrollbar coupled with Gtk::Spinbutton:

I'm not keen on this one, as the cognitive dissonance in it looking like a scroll bar but not actually scrolling anything is a bit too much for my meagre brain to handle. Perhaps if CSS can make it look a little less scrollbar-like it might be worth pursuing, but otherwise I think it will confuse more than it helps.

 

* Gkt::ProgressBar coupled with Gtk::Spinbutton:

As you mention, has the potential to look pretty good with some CSS, but with the non-functioning progress bar at the moment it's hard to tell how nice it will be in use.
 


* Subclassed Gtk::Spinbutton:

Up there with the first one in terms of looks, but doesn't suffer the same redraw problems. Issues with the size of the text widget though, as you noted.

 

* Gtk::Scale coupled with Gtk::Spinbutton:


Not too bad once I added a white background and a border to make it look more like a single composite widget. Not as obvious as the ones with a full-height bar, though. This is probably very subject to the whims of your GTK theme, however, as the thumb on mine is nothing like the circle in your screenshots (mine's a rectangle, for a start).



IMO the first one comes pretty close to what I would like to see, if the redraw issues can be addressed. Otherwise the fourth one is the best (though with issues around the value field), with the fifth one following in third place.


Regards,

Mark

 

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Reply | Threaded
Open this post in threaded view
|

Re: Spin slider widget, redux.

Eduard Braun
Am 06.12.2017 um 17:02 schrieb Tavmjong Bah:
The five solutions, from top to bottom, are:

* Custom Gtk::Range widget couple with Gtk::Spinbutton:
* Gtk::Scrollbar coupled with Gtk::Spinbutton:
* Gkt::ProgressBar coupled with Gtk::Spinbutton:
* Subclassed Gtk::Spinbutton:
* Gtk::Scale coupled with Gtk::Spinbutton:

It's a bit hard to make a founded statement based on partially unfinished implementation (I assume many of those I'd consider unusable in the current form could be made to work reasonably well with CSS or minor code changes) so I'll try to comment mostly on the underlying functional aspects (although that's hard too without having a closer look at the actual implementation)... Anyway:
  • While I appreciate (4) for the approach at achieving something compact it seems riddled with functional issues - besides the problem of the mouse being "catched" by the numerical input while working on the ProgressBar (and vice versa) the dynamic change of the ProgressBar's witdh causes the relative position to change abruptly as the total length changes (so this would need to be disabled).
    Also the design is problematic (borders all around the ProgressBar - not sure how straightforward this would be to fix)
  • (2) might be OK if tuned with CSS but it lacks the "filling" effect of the slider, so not ideal in my opinion.
  • (5) looks solid, too (at least the CSS-tweaked version considering we want to add text) - questions would be: does it have any advantages over the remaining choices?
  • (1),(3)  look identical when tweaked with CSS but if you say (3) is more difficult to implement I don't see a reason to use it.
  • (1) seems to work (in principle) nicely considering functionality. Obviously the "slow scrolling" needs to be fixed to start at the current value and I'd also prefer a different modifier - likely Ctrl) but apart from that I don't see any obvious issues.
    However Design has some issues, for example I'd use use an arrow pointing up (but that's probably not important at this stage). What might be a more serious issue issue is the font rendering: For some reason the white font renders very badly. In your screenshots on Linux (where only grayscale anti-aliasing seems to be used) the text appears already really light and hard to read. On Windows (see attached), where subpixel anti-aliasing is used the text becomes even less legible (the anti-aliasing implementation might even be broken here). Maybe it can simply be tweaked away with CSS but maybe it's also a fundamental toolkit issue...

What I'm missing from all options:
I really liked the suggestion to re-use the current design but fix the existing issues, most prominently make the number input insensitive while manipulating the slider and require a single click (without dragging) to enable number input.
If I look at your designs all of them are made of less than 60% slider but over 40% of spinbutton. If I look into our toolboxes most of the sliders are only half as wide, though, which would result in about 20% slider (i.e. unusable) and 80% spinbutton (i.e. we could just drop the slider and use a spinbutton to start with). So *if* we want to continue using the proposed widgets in these places we still need to come up with a better design...

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-user

SpinButtons_no_CSS_Win10.png (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spin slider widget, redux.

Thorsten Wilms
In reply to this post by Mark Crutch-2
On 06.12.2017 17:02, Tavmjong Bah wrote:

> * 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.).

This one needs a border around the slider area.

As Mark noted, Alt is often used for window manager gestures, so use of
Ctrl and Shift (in that order, I'd say), is preferable.


> * 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.
This one does a good job in appearing as a single widget, but won't fly
if the width of the numerical input can't be dealt with properly.


I note that in all functional cases, the value jumps to the pointer on
mouse-down. That should be an alternative, the main mode should be just
"sliding" the value. That has been the norm; did I miss examples to the
contrary in recent closed software applications?


As Eduard points out, the width requirement of the horizontal - and +
buttons is problematic. What's wrong with a vertical arrangement? If you
feel adventurous, try the attached Python/GTK script to see another way
of offering stepping buttons.


--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-user

dynamic_scrollbar.py.bz2 (9K) Download Attachment