Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dock the Properties frame to fill the left edge of the screen #876

Closed
N3WWN opened this issue Sep 7, 2017 · 17 comments
Closed

Dock the Properties frame to fill the left edge of the screen #876

N3WWN opened this issue Sep 7, 2017 · 17 comments
Labels
💡 enhancement This issue describes an improvement, enhancement, or feature request for OpenShot

Comments

@N3WWN
Copy link
Contributor

N3WWN commented Sep 7, 2017

I change several properties on all of my clips a lot and would like to be able to dock the properties frames on the left (or right) side of the screen, filling it vertically.

Right now, as far as I can tell, it can be undocked, or docked to the left/right/above/below the Project Files, Video Preview or timeline frames, but only at the height of those frames.

@DylanC DylanC added the 💡 enhancement This issue describes an improvement, enhancement, or feature request for OpenShot label Sep 18, 2017
@peanutbutterandcrackers
Copy link
Contributor

@ferdnyc - Perhaps you could even fix this thing up, good sir? I have seen that the toolbar can be docked vertically to fill the entire frame. If the properties tab could also inherit from the toolbar's parent class, perhaps it would be possible to dock the toolbar the way it is currently docked and also dock it to fill the entire vertical screen at the same time? Any thoughts?
Since virtually everything is keyframe-able in OpenShot, I think it is worth having the properties bar able to be docked to fill the entire screen (vertically) so that the user can see all the parameters currently being interpolated...

@ferdnyc
Copy link
Contributor

ferdnyc commented Mar 20, 2018

You know, it's funny. I actually tried to implement this last week, because I had exactly the same idea.

Unfortunately, at least with my limited knowledge of the Qt layout system, it doesn't appear to be possible with the current OpenShot UI. The horizontal divider that splits the window in half is the highest-level UI element on the canvas. There's a container above it, where widgets can be docked side-by-side horizontally, and there's a container below it, where the timeline is fixed in the center, and other widgets can be docked left, right, or below the timeline. (It's actually possible to dock something full-width below the timeline. Which might be handy if OpenShot ever added an audio-level meter widget, or something like that, but currently I can't come up with any practical use for that dock position.)

Near as I can tell, those are the only layout options. It's surely possible to change that, but AFAICT it would require rewriting the entire main-window interface layout from the ground up.

@ferdnyc
Copy link
Contributor

ferdnyc commented Mar 20, 2018

I have seen that the toolbar can be docked vertically to fill the entire frame.

Huh. Until you mentioned it I hadn't noticed that. OK, so the divider is the second-highest-level UI element.

Toolbars are a fairly specific UI element, though (QToolBar), much like the menu (QMenu) and statusbar (QStatusBar), which also escape the horizontally-split container. I can't imagine the Properties list could be implemented as a toolbar. And it doesn't appear that the QDockWidget containers that all of the float-able UI elements are formed of can escape their horizontally-split layout grid. Those containers are already defined as being allowed to go "anywhere dockable", which apparently covers the positions they'll allow themselves to be dragged to.

<widget class="QDockWidget" name="dockProperties">
   <property name="floating">
    <bool>false</bool>
   </property>
   <property name="allowedAreas">
    <set>Qt::AllDockWidgetAreas</set>
   </property>
   <property name="windowTitle">
    <string>Properties</string>
   </property>
   <attribute name="dockWidgetArea">
    <number>1</number>
   </attribute>

@ferdnyc
Copy link
Contributor

ferdnyc commented Mar 20, 2018

Yeah, the issue appears to be that the Qt "Main Window template" OpenShot's UI is based on, which they also use for many of their own applications, has a rather frustrating quirk.

QMainWindow is a toplevel container widget, a quick way to assemble application UIs because it consists of a menubar, toolbar(s), and a statusbar (all optional), plus one central canvas for assembling the application interface. The canvas area is surrounded by four expandable docking anchors called Left-,Right-,Top-, and BottomDockWidgetArea.

Any QDockWidget can be docked into any one of those areas (or restricted to certain ones), and multiple docked widgets can share the DockWidgetArea in various ways. Which means you can, for example:

  1. Dock a QDockWidget in the LeftDockWidgetArea, then
    1. dock a second QDockWidget so it occupies the same space (in which case they become tabs you can switch between),
    2. dock a second QDockWidget above/below it (in which case they split the vertical area), or
    3. dock a second QDockWidget to its left/right (in which case they split the horizontal area).

Each DockWidgetArea is resizable parallel to its "gravity". (So, vertically for top/bottom, horizontally for left/right.) Anytime multiple QDockWidgets share a DockWidgetArea, a resize handle appears between them to adjust how the space is distributed among them. The top half of the OpenShot window is (in Advanced view) actually just three QDockWidget containers sharing the TopDockWidgetArea, docked alongside each other and distributed horizontally.

However, Qt very, very frustratingly appears to give TopDockWidgetArea and BottomDockWidgetArea first priority for expansion, above LeftDockWidgetArea and RightDockWidgetArea. So if you want a QDockWidget to occupy the entire vertical window space when docked to the LeftDockWidgetArea, that seems to require leaving TopDockWidgetArea and BottomDockWidgetArea completely empty. The moment you dock something into either one of those two spaces, it'll expand to full width and anything in LeftDockWidgetArea or RightDockWidgetArea will shrink vertically.

If there's any way to override that, I haven't yet discovered it. And getting rid of the QMainWindow layout means losing the base layout for the application, including all of the built-in features it provides (like the toolbar, menubar, statusbar, and dock areas), and having to reconstruct those by hand from base widgets. Perhaps there's a way to create a toplevel template based on QMainWindow, but favoring expansion of the vertical dock spaces over the horizontal ones, but I wouldn't even know where to begin.

@ferdnyc
Copy link
Contributor

ferdnyc commented Mar 20, 2018

...Now, all that being said, while you can't dock the Properties list to the left edge of the window, there's nothing stopping you from floating it and just resizing it to the full height. 😁

@ferdnyc
Copy link
Contributor

ferdnyc commented Mar 20, 2018

Aha! It is possible. And actually fairly simple.

However, since giving the LeftDockWidgetArea control of the top-left window corner would mean that left-docked widgets cold only be full-height, and would always push the widgets in the TopDockWidgetArea out of the way, the existing OpenShot layout would be impossible to achieve after that adjustment.

So if this were to be done, I think it would require implementing an entirely new, separate View mode ("Sidebar", perhaps, or something like that), along with the necessary code to switch between "Sidebar" and the existing layouts ("Simple" and "Advanced"). It can't just be a simple matter of making the Properties widget draggable to the left edge in "Advanced" view, unfortunately.

All of which means I'm still very much in favor of the idea, and not opposed to doing it, but... as I said last time I suggested a major change to the code, "probably not this month, at least."

@peanutbutterandcrackers
Copy link
Contributor

Whoa. I am always amazed by how much you know and research. Awesome!

While we're at docking and stuff, is it possible to take care of the white sides when the docks are undocked? The white line/border on the left. Or maybe some other way to make it look even better? Just curious if you have any ideas (and maybe PRs to fix it, soon).
screenshot from 2018-03-21 10-37-25

Also, I'll be looking forward to seeing this feature implemented. Would be super helpful for users like me that make extensive use of keyframes.

@ferdnyc
Copy link
Contributor

ferdnyc commented Mar 21, 2018

Huh. I hadn't noticed that either. (Then again, I hardly ever undock panels, just rearrange them.) I definitely see it here, too, though. It's probably just a stylesheet thing, I can't imagine it'll be that hard to sort out.

As much as I hate to do this to you, can you file a new issue for that? It'll let me flag that separately as a reminder, since the original issue here isn't going to be as quick a fix.

@N3WWN
Copy link
Contributor Author

N3WWN commented Mar 21, 2018

Hmm.... popping the Properties frame out and manually filling the screen (vertically) is an okay solution, and the popped out frame is remembered between launches of OpenShot, but the main window doesn't retain it's size/position, so I have to resize the main window every time I launch the app.

@ferdnyc
Copy link
Contributor

ferdnyc commented Mar 21, 2018

Really? That's strange, the code is there to store the main window geometry. (And that code must be running, because it's right next to the code that stores the dock positions/state.)

On my system (Linux Fedora 27 x86_64), if I drag OpenShot into a corner of the screen, float a dock alongside it, select File → Quit, and then re-launch OpenShot, everything comes back in the same place as when I closed it, including the main window.

(Only annoyance is that the floated dock widget, unlike the main window, seems to sometimes end up popping under other windows on the screen. Maybe we need some sort of explicit "raise all" at the end of UI setup, for floated-dock situations. Or something to ensure that main-window raises are always propagated to floating dock widgets, because in some quick testing right now it doesn't appear that they are.)

...Anyway, all that aside, point is that in OpenShot 2.4.1 the main window does store geometry between sessions, for me. Maybe it's a difference in our environments? What's your OS / version / anything-else-you-can-think-of?

@N3WWN
Copy link
Contributor Author

N3WWN commented Mar 21, 2018

Hmmmm... that is interesting! My system is Fedora 25 x86_64 running the current nightly build (OpenShot-v2.4.1-52-g3e8b00a-59-686-x86_64.AppImage).

I'm doing the same: Pop out the Properties frame, put it all the way to the left and vertically fill the screen and resizing the main window to fill the rest of the screen. File → Quit and relaunch has the main window maximized (not full screen) again and I have to shrink it.

Popped out Properties:

openshot - popped out properties - 180321

Then, after File → Quit and relaunch:

openshot - main windows maximized - 180321

Anything else I can check that may play part in the geometry persistence ?

Thanks!

@ferdnyc
Copy link
Contributor

ferdnyc commented Mar 22, 2018

Hmmm. It's coming up maximized? That may be significant. More on that in a second.

Yeah, for the most part I can't convince OpenShot to do that. I even tried with the 2.4.1 release AppImage, and everything was the same there. However I lay out the window(s), prior to File → Exit, on launch they mostly go back to the same positions.

(Sometimes things are shifted around by a few pixels, which makes me think there might be some minor errors in some size/offset math, or incorrect assumptions about decoration sizes, but as I said it's only a few pixels.)

That works if I relaunch the same OpenShot I was running before, and it works if I switch between my installed /usr/bin/openshot-qt and src/launch.py from the source tree, or vice versa — they respect even each other's placements.

The only time it didn't follow the stored geometry was if I ran the AppImage after having run either /usr/bin/openshot-qt or src/launch.py — if the AppImage tries to load settings saved by the a different OpenShot, it tosses the stored main-window dimensions, for whatever reason, though it keeps the dock placements. (The AppImage is fine relaunching with its_own_ stored geometry, though.) But even then, the window didn't come up occupying the entire screen. It came up in only the upper-left quarter, at I guess what must be its nominal "default" size. So I don't think you're seeing that.

Let's see, things to rule out. Well, I'm running Gnome Shell in an X.org session, using Nvidia proprietary display drivers. So, if you're using Wayland, that'd be a prime suspect.

But here's one other thing you can try: Insstead of exiting with the main window sized to full height and like 90% width, try shrinking it down in both dimensions, and then moving it to the lower-right corner of the screen. File→Exit with that configuration, and then try re-launching OpenShot.

It's a long shot, but I know there's a Mutter preference, default enabled IIRC, that tells it to auto-maximize "nearly-maximized" windows (especially ones along the top edge of the screen). If Gnome Shell is respecting that preference, that could be what's maximizing your window. So, storing a smaller window would keep auto-maximization from messing with your geometry, if indeed it is. And then you can try switching that setting off. 😁

@ferdnyc
Copy link
Contributor

ferdnyc commented Mar 24, 2018

Since I kind of buried you in stream-of-consciousness there, @N3WWN , I just wanted to pull out my suggestion so it didn't get lost in my own blather. Give this a try:

Instead of exiting with the main window sized to full height and like 90% width (as it appears you've been doing, from the screenshot), try shrinking it down in both dimensions, and then moving it to the lower-right corner of the screen. File→Exit with that configuration, and then try re-launching OpenShot.

It's a long shot, but I know there's a Mutter preference, default enabled IIRC, that tells it to auto-maximize "nearly-maximized" windows (especially ones along the top edge of the screen). If Gnome Shell is respecting that preference, that could be what's maximizing your window. So, storing a smaller window would keep auto-maximization from messing with your geometry, if indeed it is. And then you can try switching that setting off.

@N3WWN
Copy link
Contributor Author

N3WWN commented Mar 30, 2018

Hi @ferdnyc ! I wanted to follow up with this after some testing. I think that you're right about shrinking the main window a bit more in order to not start maximized at the next launch.

This somewhat defeats the purpose of maximizing the application and won't work in full screen.

It looks like the code could be modified to support multiple layouts. If I get chance today, I'll take a peek at this...

@ferdnyc
Copy link
Contributor

ferdnyc commented Mar 30, 2018

Hi @ferdnyc ! I wanted to follow up with this after some testing. I think that you're right about shrinking the main window a bit more in order to not start maximized at the next launch.

This somewhat defeats the purpose of maximizing the application and won't work in full screen.

Oh, but you can turn that "feature" off, if that's the issue. Just navigate to /org/gnome/mutter/auto-maximize in dconf-editor, or gsettings set org.gnome.mutter auto-maximize false. You should be able to make the window as big as you like and have it restore at the same size.

It looks like the code could be modified to support multiple layouts. If I get chance today, I'll take a peek at this...

It already does support multiple layouts — and uses them! "Simple" and "Advanced" (in the View > Views menu) are the two existing window layouts for OpenShot. All that's needed is to add a third, and have all of the layouts make the appropriate calls to QMainWindow.setCorner() when switching, so that dock maximization is configured appropriately for that layout.

@N3WWN
Copy link
Contributor Author

N3WWN commented Apr 2, 2018

@ferdnyc Sorry, what I was talking about, as far as multiple layouts, was in reference to your earlier post:

However, since giving the LeftDockWidgetArea control of the top-left window corner would mean that left-docked widgets cold only be full-height, and would always push the widgets in the TopDockWidgetArea out of the way, the existing OpenShot layout would be impossible to achieve after that adjustment.

@peanutbutterandcrackers
Copy link
Contributor

Closed via #2490

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💡 enhancement This issue describes an improvement, enhancement, or feature request for OpenShot
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants