On July 24, 2011 05:01:30 pm Tim E. Real wrote:
> On July 24, 2011 11:07:09 am Florian Jung wrote:
> > Am 22.07.2011 22:51, schrieb Tim E. Real:
> > > I read the proposals. Pretty radical. Not quite sure what to make of
> > > them.
> > is this more a "i'm not sure if we should change all this, even though i
> > can imagine how it'll look like", or a "i cannot imagine how this should
> > work. but if it does, it's okay"?
> Was confusion, see below.
> > > Did you know that you can right-click on any toolbar area and turn off
> > > any toolbars you don't need? And thanks to Robert, MusE remembers the
> > > configuration.
> > i know, but that's not enough; and, btw, wasn't it me who made muse
> > remember the toolbar config ;)? (or did i "only" fix this?)
> Oops my mistake. Well it's great no matter.
> > > I don't have a big problem with space. I can have the Arranger and
> > > Pianoroll windows side-by-side, wide-screen monitors are the norm these
> > > days. Usually I tend to focus on working inside one particular window,
> > > not two at a time. When I'm done with the Pianoroll, I switch to the
> > > Arranger, and vice-versa.
> > with my changes, you'll still be able to do that. but i'll also be able
> > to work with three windows on my small screen ;)
> > > But I will say this:
> > > 1) Some of the toolbars are still much too tall. The old MusE-1
> > > toolbars were much more compact than these ones. After the move to Qt4,
> > > there's some unfinished business for example in Toolbar1 constructor -
> > > a FIXME for the height, which I tried real hard but just couldn't seem
> > > to tame. 2) The Arranger minimum width needs to be reduced - I think
> > > it's hard-coded somewhere.
> > > 3) The Arranger needs a few MORE toolbars - not less - such as a Colour
> > > toolbar, and certainly a toolbar (or menu) for finely adjusting
> > > parts, such as lengths and positions - this is sorely needed ASAP!
> > > 4) The Arranger's "Arranger" toolbar (the one with Cursor, Snap, Length
> > > etc.) is much too long and should be split into two.
> > such splits should be done at more locations; also, is it possible to
> > "lock" the toolbars somehow (that is, remove their grips and make them
> > un-movable)?
> Mm, maybe doable, sounds unusual, not sure how complicated...
> > > I don't think permanently removing toolbars or menus is a good idea.
> > > They are liberally redundant in the various windows simply to make it
> > > easy, so you don't have to switch back and forth among different
> > > windows. The Transport toolbars for example are always within reach,
> > > even though there is a separate Transport window. I have moved all my
> > > Transport toolbars to the left panels rather than the top panels, and
> > > it's great. Unobtrusive.
> > well, removing them now is indeed a bad idea. but with my changes,
> > making all windows children of the main window, maximizing the children
> > will NOT hide the main window. they'll be, instead, inside the main
> > window. when also the changes removing the toolbars and menus are
> > applied, this will not be space-inefficient
> Ah, I see. So you mean the app becomes what we call MDI
> (Multiple Document Interface) where all (or most) windows become
> children (inside) of the Arranger window?
> If so, no wonder I couldn't quite get your proposals!
> Yep, certainly if we go MDI then all child menus and toolbars are
> There are advantages to MDI, my personal preference is separate windows.
> If you look at say KDevelop-3, I think it had the option of both
> interfaces. I wonder how hard it would be to do that here...
(Er, that may have been KDevelop-2...)
'Pure' MDI, that is one window with every other window inside of it,
fell out of favour with me years ago. Here in a sequencer I can't see
us doing it. (The main window sometimes wastes lots of space if the child
windows don't completely fill the parent, then part of the parent is covering
your desktop. I find always managing and fussing with the child windows is
sometimes a pain.)
There is a third option. Ah, sorry maybe /this/ is what you had in mind... ?
It's MDI functionality, but without the main window covering the desktop.
I think this was popularized by Borland Delphi and C++ Builder.
On Linux, check out Lazarus, the free Delphi clone. Been around for years,
guaranteed to be in your repo. Observe the user interface!
(Delphi's Property Editor behaviour is my all-time favourite. I mentioned
before that it'd be nice to make MusE's track list and trackinfo/mixer panel
behave like that - for multiple selected tracks and parts. I digress...)
In the case of MusE, all menus and all toolbars are *moved* to a separate
window and *that* window becomes the 'Main' window - a slim window
more akin to a task bar which usually sits at the top of desktop, but can
of course be moved around and shrunk and sized.
All other windows such as the Arranger and Pianoroll *lose* their menus
and toolbars, and their Title Bars shrink thus making the windows more like
'Tool Windows' (the exact name escapes me - you know what I mean.)
In such a user interface, it is certainly possible to move the 'child' windows
on top of (or behind) the 'Main' window, but it's usually unlikely to be done
because the 'Main' window is usually slim enough that 99% of the time
all other windows sit below it (or around it) - similar to an unobtrusive
task bar as I mentioned above.
The 'Main' window's menu and toolbars would definitely have to become
somewhat context aware. Some toolbars would appear/disappear when
you switch windows. Or not. Thoughts on that? ...
OK, I can dig it now. If /this/ is what you had in mind, keep talking!
For comparison, I noticed Qt4 Designer is a pure MDI app, but allows the
various 'Viewers' to moved outside the main window, but not forms.
But at least the Property Editor behaviour is of course similar to Delphi.
Do check out Lazarus.
> > my proposed changes only make sense when applied completely. only making
> > the wins children wastes space, because of redundant toolbars and menus
> > only removing the toolbars and menus makes muse less usable because you
> > indeed have to switch between windows
> > but when doing both at the same time, you'll not waste space, and also
> > will not have to switch between windows.
> Wow, interesting. Wonder how hard that would be. The 'unified' menu and
> toolbars would have to be 'context' aware - depending on which window
> has the current focus, as you mention below.
> > > And specifically, the various Edit menus operate subtly different from
> > > each other. I don't think we can 'unify' them into one menu in the
> > > Arranger. This is important for example when I get around to
> > > implementing Pianoroll controller graphs Cut, Copy and Paste etc. I
> > > looked at this before, and it may require some unique, tricky coupling
> > > with the Pianoroll Edit menu.
> > i'd let the edit menu always show the edit-controls for the currently
> > active child window. this is a bit apple-style, you know, one large menu
> > bar on top of the screen which is always the menu for the currently
> > active window. there are indeed scenarios where this apple-style really
> > sucks (for example, the normal "desktop" scenario). but sequencers are
> > definitely a scenario where it helps. you never need to have quick
> > access to some inactive window's menu in muse; so these menus can or
> > even should vanish to offer more usable working space.
> > > Let's see if anyone else has a response to these proposals.
> > @others: yep, please discuss this :)
> > but please consider the whole thing, and not its atomic changes. each
> > change for itself either wastes space or makes muse more complicated to
> > use. only all changes together make muse really better.
> > and, in case you're not really convinced, please tell me whether you
> > think that these changes are generally bad or that you just can't
> > imagine how it would like. that is "no, forget it" or "hrm, implement it
> > in some branch and we'll see".
> Oh, no, it's interesting and desirable. If we can switch between
> interfaces like KDevelop-3 that would be fantastic.
> I hope you're not setting yourself up for a lot of work.
> Do you want to attempt such a task? Maybe try in Experimental as a
> proof of concept?
> I have no plans to touch these GUI areas for now, I'm mostly in the 'guts'
> right now, unfinished stuff I started etc. and part border drawing.
> > greetings
> > flo