With some help from luisbg, I finally reworked and merged a 2-years-old patch of mine. It turned out to be less trivial than expected, because we had to change the settings backend to allow loading/reading configuration files at runtime for our dynamically-generated tab components. So, what the heck does this mean to you? Automatically saving and restoring the state of our dynamic detachable tabs/components. This is a nice improvement for those of you who want to spread the PiTiVi UI across multiple displays:
I’m also quite happy about a very nice contribution from Elad Alfassa to polish the rendering user experience. When the window is not currently focused, we now show a notification and play a sound (when pycanberra is available—where’s my introspection?) to tell you to put down that webcomic you were reading:
…and he reused the progress dialog to allow launching playback of the resulting file in your favorite video player:
There still is, of course, room for improvement in that progress dialog in general. I need to think about it a little bit, but feel free to offer suggestions or patches.
Other little things that have been fixed in Pitivi in the last few weeks:
- Activating (pressing the Enter key) the filename entry in the render dialog starts the render (for those who don’t care about rendering settings!)
- The timeline toolbar is now vertical and sports a slightly improved “Split” icon. It also does away with obsolete buttons. Hopefully, better icons for (un)grouping are on the way.
- Dogtail UI tests have been fixed.
- Tests for presets were improved and cruft from old integration tests was removed (about 1400 lines of code), thanks to aleb.
- The “contributing” page on the website has been reworked a bit to be clearer.
- The code now passes the 1.3 version of the PEP8 code style compliance checker.
- The clip previewer now works correctly while in fullscreen mode.
- I hear it can now be launched on FreeBSD (apparently we’ve got at least one such user 🙂
- The previously mentioned filtering in the import dialogs has been improved to use the system mimetypes instead of file extensions.
- The media library keeps itself sorted alphabetically as you import files (thanks to Alex Băluț), without any additional performance hit. It is possible to confuse the sorting a bit if you mix ascii filenames with japanese lolcat videos, but even a human would have trouble knowing which goes first in that situation.
- Various improvements have been done on the build script. It tries to avoid building glib, prefers building stable releases instead of checkouts of “master” everywhere, and is generally more resilient to failures. If you still experience issues with it, patches welcome!
You can check out my main website, find me on Twitter or Mastodon or subscribe to my YouTube channel.
Comments
12 responses to “Persistent tab states, render UX polish and other things”
These are very good news, thanks for the report.
Looking at the first pictures here is something i found eye-catching : the 4 buttons vertical toolbar takes a lot of usefull space (you always want more horizontal space when you work with timelines). There are many other places where it could sit : top-right or bottom-left for exemple are just full of empty space (i must admit that it may not be as much obvious/contextual as now though).
I don’t know the solution since i even didn’t play qith the UI, but i pretty sure that something can be done to not steal all that space. I’m also pretty sure that timeline horizontal space should be prioritized
What about a GUI option to auto-hide that toolbar ? Advanced user could use that whereas newbies could keep the default discoverable behaviour (which would be the default one)
why not put the tool-bar horizontally in the dark Gray area on top of the time-line, next to the “undo” “redo” “render” etc… buttons?
@Biel Bestué : with the default UI, the “undo” “redo” “render” etc… buttons toolbar is not “on top of the time-line”, see : http://doc.ubuntu-fr.org/_media/applications/pitivi.png?w=400
Therefore i guess we loose the contextual approach which would led to a less discoverable GUI.
But i guess that it could be a GUI option like the one i’ve suggested above
Maybe we could think about automatically moving the 4 buttons vertical toolbar into the main toolbar (using a vertical separator) when the user undock tabs at the point where the maintoolbar is “on top of the time-line” as Biel Bestué suggested.
It will be a nice improvement that would match that specific case.
Pros : still contextual, more space for the timeline (see my former “always prioritize the timeline” mantra)
Cons : introduce a change in the GUI regarding how tabs are ordered. I don’t think its really a drawback since it directly results from a user action, therefore it should not be perceived like a totally arbitrary move
Or we can think about an optimisation that would met all cases
The logic behind my choice to move the timeline toolbar from the bottom to the right is this:
I weighted that decision for quite a while (given that vertical toolbars are rather uncommon) and decided recently that this was the best course of action, after “dogfooding” this approach on myself for weeks.
The anecdotal result to confirm my hypothesis is that before, I had a tendency to always hide my pitivi toolbars to gain space on my laptop screen. Now, I don’t need to at all. They remain shown at all times. And then if you need even more space, you can use the fullscreen mode, which auto-hides the main toolbar.
Each option has a cost. I’m trying to do away with options that are not strictly and universally necessary, I do not want to re-add complexity that users shouldn’t have to care about 🙂 it should be said, however, that in the long term, what we will do with the main toolbar and the menubar remains an open question. It is a complex design workflow to think of, and I hope to find a solution eventually, perhaps with the help of the GNOME design team. The vertical timeline toolbar is only a piece of the puzzle.
Since you’re talking about ratios and so on, i will not write how bad is the empty space/full space ratio of that 4 buttons vertical toolbar, no. i won’t tell you that it’s 5:1 on the 1st capture and that you’re eating each timeline space to display a 4/5 empty toolbar. Writing that would sound ridiculus, therefore i will not write it 😉
BTW in your abstract model case (people with widescreens), how many use more than 2 A/V clips ?
You can’t compare in abstracto rare vertical space vs abundant horizontal space without asking what is the typical use on small vertical screens. I would be surprised if more than 2 A/V clips are used.
The “undocked” mode is not the default mode and user experience. And horizontally-speaking, you should be more worried about the big layer controls than a thin toolbar.
My so-called “abstract” model is based on:
I expect every user to use more than two clips on a timeline. When I do an edit, I use hundreds of clips… But then in that case, 42 pixels out of 1920 (or 2560) is the least of my worries.
The timeline is not the only widget of importance. It is the primary work area yes, but the other widgets (for configuring effects and whatnot) are already significantly starved for vertical space. When you want to work on any project that is more complex than a video of a cat on a skateboard, you inevitably end up with a ton of layers (at the very least for audio), and that means that vertical space is at a premium just as much as horizontal space, because again it ends up fighting for space with other container widgets.
Do the math. Calculate the screen area usage on 1280×720. A half-height vertical toolbar uses 1.6%, while a horizontal toolbar uses 6% of the screen space.
Again, the design may evolve when the other parts of the UI evolve too, but I want to wait for the rest of the pieces of the puzzle to fall in place first. Having one and only one toolbar to do everything is a possibility, but it brings a bunch of usability problems along. Still, I never said the current approach will stay like this til the end of the century 🙂
Ok and since you have detachable panels, would it be difficult to be able to drag the 4 buttons toolbar to change from a vertical to an horizontal toolbar (remember GNOME 2 panel ?) without complexying the code too much? Or do you see a non technological reason to allow user to rearrrange panels and not that toolbar ? With 2 clips i could decide to put it at the bottom, with more clips i could drag it to the right side.
Much simpler : Having a setting (even hidden) to let the user hide the 4 button panel and providing him with corresponding contextual menu entries…
Pitivi gets better and better but…..
I couldnt get the ?new build script to get passed the pyhton header stage. Is this anything to do with Arch linux python2 or am I still missing another/header package?
Best wishes to all.
Come to the IRC channel and we’ll be better able to help you with that…
“you should be more worried about the big layer controls than a thin toolbar.”
I think i undersatnd what worries me, it’s having both : i feel a little bit claustrophobic.
I don’t know why i’ve pointed the right bar at first : maybe because i’m from a country where reading is from left to right, therefore i’m far less tolerant to a bar that sits at the right side of the screen. As you pointed out it worries me much more than the left bar. Even if it’s irrational it doesn’t meen it’s not relevant if this feeling is share, i don’t know about this particular point. But i know that hate that damn right bar 😉
The other perfect contextual place where these buttons could sit would be the place where the zoom ruler is at present.
Just think one minute of possibilities if the buttons where moved to that place (without considering at fisrt place where we should put the ruler).
All these command column panel would be deidacted to tracks.
It could benefit from an autohide feature (like the GNOME 3.0-3.4 notification area) which would mean that you would have the whole horizontal space for playing with tracks. Each axe (vertical and horizontal) would save space : no more horizontal bottom control bar (like you did with your latest developpements) and, also solved is the space used by the big layer controls.
What about the zoom ruler ? I don’t know, but it wasn’t so large before you get that big layer controls therefore i imagine it could be reduced. Would it be possible to have voth (buttons and ruler) at that place ?
Bonus : every controls at the same place, your mouse is happier
antistress: there are constraints resulting from our combination of goocanvas and GTK. An eventual move to clutter or webkit for the canvases will allow different things. I’ll have to take your ideas into account when we get to that point and when we eventually do a major redesign (which the vertical toolbar wasn’t).