Old 08-02-2019, 11:48 AM   #1
WestDCCS
Human being with feelings
 
Join Date: Jul 2019
Posts: 3
Default Left docker not expanding to full window height

I was following a tutorial on YouTube which demonstrated how to put the master volume fader into a docker on the left so that it is always available to monitor and change if necessary. Following the tutorial, I was able to easily put the master volume in the left docker and it took up the full screen. However, I was working to make a few changes and somehow I changed it.

When the mixer is open and docked, it takes up the full bottom of the window and no matter what I do, I cannot get the master to go into the full height of the right docker. Also, it doesn't matter what I place in the left docker, it will not allow a full height element in it at all. Is there a way to wipe out the docker settings entirely and restart? I'm pretty much just getting started, so if I need to do a full reset of all the settings, that'll be fine as well.

Thanks!
WestDCCS is offline   Reply With Quote
Old 08-02-2019, 11:49 AM   #2
WestDCCS
Human being with feelings
 
Join Date: Jul 2019
Posts: 3
Default

Also, the right docker is working fine.
WestDCCS is offline   Reply With Quote
Old 08-02-2019, 12:00 PM   #3
heda
Human being with feelings
 
heda's Avatar
 
Join Date: Jun 2012
Location: Spain
Posts: 5,410
Default

Try double clicking the borders of the docker
heda is offline   Reply With Quote
Old 08-02-2019, 08:37 PM   #4
WestDCCS
Human being with feelings
 
Join Date: Jul 2019
Posts: 3
Default

Awesome! That fixed it. Exactly what I needed!
WestDCCS is offline   Reply With Quote
Old 09-15-2019, 02:41 PM   #5
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 733
Default

Quote:
Originally Posted by heda View Post
Try double clicking the borders of the docker
Wow, hallelujah!

This is not really discoverable. I believe most users will just attempt to drag the dockers to various positions to find the different possible expand sizes.

I just spent 20 minutes trying to unfuck my layout and was just in the process of rage-recording a video on how broken the docking system is[*] only to discover the magic of double clicking at the point where the mouse cursor turns to a resize icon. I feel a more discoverable system would benefit Reaper.

[*] And it is broken when it shows the target dock position is full height but when you drop it it's not.
tack is online now   Reply With Quote
Old 09-21-2019, 07:58 AM   #6
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 12,431
Default

Any suggestions for a “more discoverable” system?
Justin is offline   Reply With Quote
Old 09-21-2019, 10:52 AM   #7
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 733
Default

Quote:
Originally Posted by Justin View Post
Any suggestions for a “more discoverable” system?
I'll make several references to Visual Studio Code, which I think has one of the best docked grid systems out there (at least nowadays). Of course, Code provides an arbitrary panel grid while Reaper has a fixed 4-edge system. But I think there are still things we can learn from it in terms of usability.
  1. Make docker panel draggability more discoverable by providing a visual cue when the mouse is hovered over the gutter. The most obvious solution is to change the mouse cursor to the drag hand. (VS Code does this.) This is one area I was confused about early on, because I was dragging only tabs as they were the most discoverable thing. I didn't realize at first panel gutters were also draggable. Likewise, changing the mouse cursor when hovering over tabs might also be good to indicate it's an interactive element. (VS Code does this too.)
  2. Indicate drop targets not as a thin blue rectangle, but as a translucent box that will show, before dropping, exactly how the panel dimensions will be. Refer to VS Code's behaviour here. And don't lie, like in my video.
  3. Allow resizing panel heights (for left/right dockers) or widths (for top/bottom dockers) by dragging panels along various positions of an edge (even if it's their current edge). Obviously if there are no adjacent dockers then it can only ever be full height. But when there are adjacent dockers, it should be possible to discover different regions where the docker will panels have different sizes. By adding a notion of an "inner" and an "outer" drop target in the opposite dimension, you can both improve discoverability while handling more sophisticated layouts.

The sketch below describes better what I mean. It should be easy enough to extrapolate the horizontal panel scenario from this.

This combined with the first two suggestions above (improving discoverability of docker draggability by means of a different mouse cursor for the gutter, and using a translucent box to exactly show the panel's resulting dimensions while dragging), I feel would be a big improvement on the current docker UX.


Last edited by tack; 09-21-2019 at 12:16 PM.
tack is online now   Reply With Quote
Old 09-21-2019, 11:12 AM   #8
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 24,749
Default

Quote:
Originally Posted by Justin View Post
Any suggestions for a “more discoverable” system?
Tooltip?
__________________
If it requires a null test to find it, it is by definition minuscule.
karbomusic is online now   Reply With Quote
Old 09-21-2019, 11:16 AM   #9
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 733
Default

Quote:
Originally Posted by karbomusic View Post
Tooltip?
I don't think that would have helped my frustration. Tooltips are nice when you understand there is an interactive element and want to learn what it does. There is a delay before the tooltip appears so it requires some intention.

In my case, I wouldn't have expected a tooltip along the edge of a panel or bothered to wait for one because I already understood exactly what it did: resize the panel.

Of course, I was wrong, because double clicking that border also did a magic thing. But you first have to know that there's something special about that UI element to wait for the tooltip. And that's why it wouldn't improve discoverability.
tack is online now   Reply With Quote
Old 09-21-2019, 12:17 PM   #10
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 733
Default

I realized I missed a couple scenarios in my sketch. I've updated the image in my earlier post.
tack is online now   Reply With Quote
Old 09-21-2019, 01:38 PM   #11
karbomusic
Human being with feelings
 
karbomusic's Avatar
 
Join Date: May 2009
Posts: 24,749
Default

Quote:
Originally Posted by tack View Post
I don't think that would have helped my frustration. Tooltips are nice when you understand there is an interactive element and want to learn what it does.
For that one unknown, when you mouse over to resize, if it says "do x to extend fully", it's giving you feedback while trying to use it. I always look for tool tips just like I always right-click - too many gems in too many apps to not make those an explicit habits IMHO. We might also weigh amount of work involved, if we get too fancy it may get back-burnered out of necessity.
__________________
If it requires a null test to find it, it is by definition minuscule.

Last edited by karbomusic; 09-21-2019 at 01:57 PM.
karbomusic is online now   Reply With Quote
Old 09-21-2019, 02:07 PM   #12
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 733
Default

Quote:
Originally Posted by karbomusic View Post
We might also weigh amount of work involved, if we get too fancy it may get back-burnered out of necessity.
Yes that's always the risk. While not as good as improving discovery through dragging (which is how users will naturally attempt to rearrange their panels), a tooltip is better than nothing. (Though unfortunately perhaps only marginally for the reason I provided earlier.)
tack is online now   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 05:12 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.