I’ve gone ahead and developed a patch to keep the toolbars / tearoffs and a method to toggle them in full screen (via the ‘Window’ menu). It also keeps the settings with the session’s options.
If you want to download and apply the patch and try out (and give feedback), you can go here:
IF there is a bug that I’ve introduced, understand this is a un-offical patch to the development stream. It might never be added to any of the branches, but is a small patch for a small feature that some people might like!
BTW> thanks to Paul for pointing at the files and speeding up my time spend hacking the code… I am NOT a GTK programmer and can get away with hacking most C/C++ code with no problems!
just a question: my audio computer is down so i can’t look at it to see for myself.
i haven’t used fullscreen mode before, but i like to have the main ardour window and the mixer window on two different desktops (in metacity or compiz). does the fullscreen mode work with this sort of setup? ie can i have the main window fullscreen on one desktop face and the mixer fullscreen on another? what about when using two monitors? can you make the windows fullscreen on each head?
If the screens have Xinerama extensions and the environment (gnome/kde) recognizes the two displays… full screen (F11) snaps to the window that the Editor is MOST/MORE in … (if between to windows, the screen it occupies more of).
I’ve done that for a while… Mixer in one window (still has the window manger border around it) and the editor in another window (and yes with more monitors) qjackctl in another monitor and the mixer (envy24control) in the fourth window.
hallo, i just applied the patch into the svn-ongoing-rev2507, and it seems that the patch is working good, at least i did not recognize any new artifacts caused by applying the patch.
but who knows, me do not, there might be some reason, why the patch is not accepted/applied to the code.
there is a issue in the bug tracker0001646, so perhaps it would make sense to attach the patch there too - so some more people could have a look on it.
this is because i think that the functionality which come with the patch is actually very useful, so we should not drop it away - if possible.
nowhiskey, thanks for testing it out on svn-ongoing-rev25* … If it does break, it will usually kick out some rejected files which are easy to fix. (2.0.5 -> 2.1 had one rejected and took 30 seconds to fix) Just leave a note here or contact via IRC.
I will continue to maintain this patch for my use as I find it useful too. I took some short cuts in the code (generates some minor [momentary, additional] CPU usage over what it could be doing, JUST during screen redrawing adding/removing the tearoffs) and could/should go back and smooth it out. But this hack was just that. If it gets adopted, I’d expect that it would require a little more code to make polished.
Did you ever post it to the mantis issue? I haven’t had time to work on Mantis recently, but I don’t remember seeing a patch for this in the issues on this topic.
It was a feature patch… and I never did post it… my mistake. I could attempt to update it, but as 3.0 is coming closer – not sure it’s really necessary. It allowed for keeping the “tearoffs” (the tool bars with buttons and such) in F11 mode (and made it an option in the menus). The patch was fairly simple and I guess it would still apply (would have to manually adjust/read the patch and find/make the same changes).
Only work around is to make the tool bar (aka tearoffs) float, then F11 [full screen] then re-dock.
I’ll need to check out a good rev # for 3.0 (and which branch) and look into it. I THINK I can do that w/o any help. (dunno much about 3.0, been using 2 for a while).
I believe (compiling now) I have a working patch for 2.8.4 (not that hard to update)… Testing now, but I do think that perhaps the menu “words” should be changed to something like “Keep toolbars when maximised/F11” (or something to that effect). I think the “Keep Tearoffs” is cryptic as the magic is from an if statement inside Editor::maximise_editing_space () that calls mouse_mode_tearoff->set_visible (true); tools_tearoff->set_visible (true); … I didn’t pick that Text randomly, only haphazardly!
Well it still works, but have noticed something interesting, perhaps intentional!?
There are two locations that list “Maximise Editor Space F11”, one is under View and other is under Window … If this is by choice, then perhaps it has a reason. I put the menu item back where it was originally (under View) but naturally went to Window to find the option. I can add in both places, but perhaps these (Maximise, keep tearoffs [under a better bit-o-text]) should ONLY appear under one!?
it took me a little while to figure out that the menu option WAS where I put it, just not where I thought that I put it and hence the discovery of two places… Again perhaps a mute point until I look at some rev for 3.0.
I currently use fluxbox as my window manager, and I can do this without a patch. Just hit alt=f11 and any program goes fullscreen but still includes the menus. Works with both the editor and MIxer.
There are slight differences, but yes it is possible to go full screen with various window managers. One difference in going full screen IN Ardour is that you have the option to drop the tool bar (or with this patch, add it back in). Also when you go full screen from Ardour, the window decoration (title bar on top, outline around sides) are lost, which gain you a little more space as well and the app “sticks” to the screen (can’t drag it to another screen as easily).
Just small little things.
At this point, I need to determine the text (of which I think “Toolbars when Maximized” works best) and if the menu option for maximized should possibly be removed from the View menu… I’ll chat w/ Seablade and las and punch the idea around.
Sorry to duck out on you earlier… I am in the middle of a huge headache of a small production(Go figure) and am jumping in and out these days. I was right before final rehearsal earlier today when I was trying to get MTC working right and was in a huge hurry as a result.
@Seablade: Not a problem and guessing the time of year, it’s to be expected!
I think that I should provide two patches, one to clean up (remove the F11 option from Window and leave under View) and 2nd to put the F11+Keep Toolbars when Maximized. That way each can be reviewed independently.
I’ve gone ahead and done some polishing (reorganising the View/Window menus) and added the Keep Toolbars as two separate patches … as well as providing the feature as a patch against the original code (very minimal, only View, menu changes).
I think the changes to View/Window will meet with approval. I chatted w/ las about what should go where and I removed the option to Maximise from Window and leave in View, but only after moving that menu item to top (same place as it was under Window) and added some separators to make it more pleasing to view the View menu.
Try both the view_window-reorder-2.8.4.patch.txt THEN keep-toolbars-with-reorder-2.8.4.patch.txt, and I think you’ll agree… The only thing left is the consistent spelling of Maximise/Maximize/Maximised/Maximized (of which I left intentionally the way it is to draw attention).
I still need to get a rev of 3.0 and port the feature as a patch there. 3.0 will throw me a little bit I am sure!
and got rev 6398 and started compiling (not sure if I have all the requirements satisfied, but I think waf would have told me otherwise)
and got an error:
…/libs/pbd/pbd/signals.h:35:16: error: ‘boost::signals2’ has not been declared
…/libs/pbd/pbd/signals.h:35:37: error: expected initializer before ‘UnscopedConnection’
…/libs/pbd/pbd/signals.h:36:16: error: ‘boost::signals2’ has not been declared
…/libs/pbd/pbd/signals.h:36:37: error: expected initializer before ‘Connection’
…/libs/pbd/pbd/signals.h:37:16: error: ‘boost::signals2’ has not been declared
[…]
…/libs/pbd/pbd/signals.h:262:28: error: ‘_signal’ was not declared in this scope
…/libs/pbd/pbd/signals.h: In member function ‘void PBD::Signal4<R, A1, A2, A3, A4>::connect(int&, const int&, PBD::EventLoop*)’:
…/libs/pbd/pbd/signals.h:268:10: error: ‘_signal’ was not declared in this scope
…/libs/pbd/pbd/signals.h: In member function ‘bool PBD::Signal4<R, A1, A2, A3, A4>::empty() const’:
…/libs/pbd/pbd/signals.h:275:33: error: ‘_signal’ was not declared in this scope
In file included from …/libs/pbd/pbd/destructible.h:23,
from …/libs/pbd/pbd/statefuldestructible.h:24,
from …/libs/pbd/pbd/command.h:25,
from …/libs/pbd/command.cc:20:
…/libs/pbd/pbd/signals.h: In member function ‘int PBD::Signal0::operator()() [with R = void]’:
…/libs/pbd/pbd/destructible.h:30: instantiated from here
…/libs/pbd/pbd/signals.h:103:22: error: ‘_signal’ was not declared in this scope
Waf: Leaving directory `/home/dx/src/svn/ardour3.0-6398/build’
Build failed
-> task failed (err #1):
{task: cxx command.cc -> command_1.o}
Either this is a known flaky rev point or I got something wrong… I still need SOMEBODY to tell be a rev point to start at/from so I know I have a good REV starting point!
(HINT HINT HINT, aka I need a reply on this, I wasn’t as obvious before!)
