Actually, the use of GTK HeaderBar and https://developer.gnome.org/gtk3/3.10/GtkWindow.html#gtk-window-set-titlebar doesn't require the use of GtkApplication, so there's no urgent need to nuke application.py.

Created attachment 261263 [details]
mockup

My thought is that some menu items need to be moved elsewhere in the UI:
- “Revert to saved” could become a full-fledged main toolbar button.
- "Export as archive" → “Gear” menu
- Detach/Attach viewer → Make it a button in the viewer’s toolbar
- Save snapshot of the current image → “Gear” menu
- Keyframe actions: they should be contextual anyway. Either in the effect
properties UI, or appearing temporarily in the timeline toolbar (to avoid
visual clutter).

- "Remove layer": kill the menu item, leave the contextual menu, and replace
the main interaction by “drag the layer out of the screen or into the media
library”?


I was left wondering about the relevance of using a GtkMenuButton instead of just letting GTK automatically overflow (create a dropdown menu) if it can't fit all toolbars items on the screen, but jimmac argues that:

> "It's better to design than let a toolkit overflow garbage you didn't want to make a decision on into a menu"

Hello Jean-François,

I'm really excited to work on this bug. Maybe we can talk about some recent changes in Gtk+, like GtkPopovers.

Maybe it'd be good to use symbolic icons at the header bar's icons.

While in the transition phase, we can let the menubar stay and remove items from it progressively.

Created attachment 271306 [details]
Initial design's toolbar implementation

This is how the current design's toolbar implementation would look like.
Note that I used symbolic icons

Created attachment 271307 [details]
Proposed implementation

Playing around with positioning and properties, I found this implementation really nice.
Again, I'm using symbolic icons. Using popovers on the gear menu would be amazing!
Please, any comments are really welcomed! We can evolute the idea to a shiny final implementation =)

Created attachment 271308 [details]
Minimal test application

The small program used to implement these screens.
Hope it would be useful!

Hi Georges, glad that you find this interesting!

The good news: most of the work is already done, so you don't have to go insane trying to figure this out :) I have a branch sitting around here https://github.com/nekohayo/pitivi/commits/headerbar
Testing & implementation review is welcome!


Some problems:

- That branch is a bit outdated, I need to rebase it. Lots of stuff happened underneath since then.

- There may be some other commits that Alexandru made in addition to those in my branch (related to keyboard shortcuts IIRC), I'd need to check that out to include them.

- Two of the other maintainers disagree with my approach of removing the deprecated GtkAction/GtkActionGroup in favor of what I consider a massively simpler approach for keyboard shortcuts, and are thus not in favor of merging it as-is... if you find a "better" way, this could help - I don't have much motivation (and time) to redo that part, especially since the reason why I did it that way was because I considered the GAction/GActionGroup stuff to be somewhat over-engineered.


This sounds like a case where you should discuss this with us on IRC ;) I may try to connect this week-end and spend time on this, but not sure when.

FWIW, the "headerbar" branch linked above in my personal repo has now been rebased to today's master, so at least it benefits from the cluttersink (the video actually shows) and the code doesn't conflict anymore.

Thanks!
I'll play around with the branch and see what I can do with it.

Hmm, maybe it's better for me, as a simple contributor, to wait for a concrete position from the development team.

Some thoughts on this:
- To get rid of the menubar+toolbar, items must be removed (duplication of functionality) or moved to somewhere else. I belive that adding a GearMenu is essential for it. My proposal:

AppMenu 
   /\
+-+  +-----------+
| New project    |
| Open project   |
| -------------  |
| Preferences    |
| -------------  |
| Help           |
| About          |
| Quit           |
+----------------+

GearMenu
   /\
+-+  +-----------------+
| Add a keyframe       |
| Previous keyframe    |
| Next keyframe        |
| Export current frame |
| ---------------      |
| Save project as...   |
| ---------------      |
| Project settings     |
+----------------------+

The other functionalities are already present as buttons.

Any suggestions?

The current headerbar branch already killed the menubar and migrated all the items as either contextual buttons (ex: popping out the viewer) or into a menubutton (aka "gear menu", except I chose an icon other than a gear ;)

I did not put anything into an "appmenu" because it would imply solving bug #693291 (which appears to be a can of worms) and because, frankly, I don't see the point nowadays.

I see the appmenu as a design experiment from the GNOME 3.4 era that failed to gain acceptance from both users and developers. It creates more usability problems than it solves, and I see the "menubutton in headerbar" approach as not only more discoverable, consistent and compatible with other environments, but also quite a lot simpler to implement. Splitting items across two types of global menus sounds like bad usability to me, in my humble opinion.

Oh, really, I compiled the wrong branch. Sorry!
I'll try to figure out how to readd action groups to the current work.
But maybe I'll try to fix bug #723061 first, it's more urgent.

Alright, filed a proper description of the issue that blocks a decision regarding this branch/bug report, if anyone is up for a challenge see bug #726370 ;)

Georges: I pushed the following commits onto master to avoid bitrot and further conflicts with your patches of the past few days, so you can rebase all your work onto master now and you'll have less cruft to deal with:

commit 17fee0c0802e5f4e7746b3afbed8ffc3fe0b9989
commit 02d34017bf658caed2d2e0cbad5156067cd088b4

The remaining "big commit" that ports to headerbar remains in the (updated) headerbar branch until we have solved bug #726370

So, may I just keep working on this branch?
Implement a whole interface that is GAction/GActionGroup *JUST* to prove it's better seem a huge waste of time and efforts for me.

Seems like this branch generated so much excitement that it was merged to master now after further reviews and the gaction stuff was implemented ;) so you can rebase/continue your work on master now if you want.