Hi Flo. I think your MDI proposal would certainly make it easier for Windows users to get accustomed with Muse/ Linux quickly as it would as you said make Muse behave as Cakewalk and other popular seq's do. Functionally I would need to use it first to see if I would use it at all. I've used Muse like it is for so long; I doubt I would change. Could you create a POC in experimental easily first to try? Good to see you rattling the cage tho again ;). best, g.
----- Reply message -----
From: "Florian Jung" <florian.a.jung@...>
Subject: [Lmuse-developer] UI design.
Date: Mon, Jul 25, 2011 10:06 pm
>> 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?
actually, i indeed meant that, but... [see below]
>> 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...
i also like the idea of being able to switch around between MDI and SDI.
i think this will not be too complicated, see even more below.
> (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.)
i cannot agree completely. indeed, if it's not possible to make the
child window cover the whole screen (except the area with the menu and
the toolbars, as the child hasn't got them any more), then and *only
then* MDI sucks.
but that is possible (and my plans are to make it possible), with a
maximized child window, you have (almost) exactly the same situation as
with a maximized pianoroll in current muse.
this of course requires that the arranger (and all other elements in the
main window) can be hidden, so that the main window *only* consists of
title bar, menu bar, toolbars and "children window's space".
why did it fall out of favor with you? with which kind of application?
i also don't like "over-MDI-ing", using MDI on every app. but there are
applications where this kind of MDI (not delphi's kind of) is a good
solution. and i think, a sequencer is one of these apps.
you may not conclude from a single negative experience with MDI (where
MDI probably wasn't the right choice) that MDI is generally bad.
quote: "I find always managing and fussing with the child windows is
sometimes a pain."
well, if you want to simply maximize one and forget the others, this is
one click in MDI. not a pain
if you want to arrange them, for example two windows which should be
above/below each other, having the same height, then this is even easier
with MDI than with SDI. in an MDI app, you maximize the main window,
then choose "windows" -> "arrange" -> "however this is called in
english", and you have them arranged as you wanted them to.
in an SDI app, this is much harder, because the SDI app doesn't really
know about the area you want to use for arranging. most SDI apps don't
offer that function at all.
> There is a third option. Ah, sorry maybe /this/ is what you had in mind... ?
it wasn't, but i was thinking about this as well (i used C++ Builder)
> 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.
this also sounds good, *if and only if* "maximizing" (by the small
button in the title bar) a child window does NOT make it cover the "main
menu toolbar window".
what lazarus does is IMHO *not* good (for muse; it's indeed good for
lazarus ;) ). when maximizing a unit, this unit covers the whole screen,
covering the toolbar-menu-main-window.
in lazarus' case this is good, because when writing source code, one
does not need component library buttons and whatnot. in muse's case it's
bad, because when editing in the pianoroll, you do need the toolbars,
like "select tool".
but i think that this is probably much more complicated to code than a
MDI environment, and i cannot see a real advantage (but also no
disadvantage except the complexity) over the MDI style.
the only advantage of the delphi-style over the MDI style may be that it
allows you to put windows from external synths more flexibly over the
screen... but this has to be weighted with the difficulty to code that
of course, IF delphi-style (with the restriction i made: that the main
win is "uncoverable" and behaves similar as a panel) can be done easily,
i'd prefer delphi style, because it then has no disadvantage and a
(tiny, but existent) advantage.
> 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? ...
the concept below assumes that the arranger is moved to its own window,
behaving similar to pianoroll, scoreeditor etc.
when creating menu buttons (i mean "file", "edit" etc. with that) and
toolbars, we are getting some pointer to the created stuff. we'll have
to store these pointers in some list<QMenu*> menulist or list<QToolbar*>
toolbarlist; each window owns such a pair of lists.
in SDI mode, we add them to the window's menu/toolbar spaces, and we're
done. no actual change happens
in MDI mode, we do NOT add them to these spaces.
in MDI mode, when some child window gets activated ("brought to top"),
the main window clears its menu/toolbar space, adds the "global menus"
like "File", "Global settings", then iterates through the current
window's menulist, and adds each pointer in there to it's own [the main
win's] menu. then it does the same thing with the current window's
this has the advantage that it allows switching between MDI and SDI
easily (and with few coding effort)
actually, every window still has it's own menu and toolbar. it just
doesn't show them, but gives them instead to the main window (of course,
only when active)
at all others, including robert ;)
even if you don't have much time for muse at the moment: please take
yourself a bit time to think about this topic (doesn't take too long,
does it?). if you have (reasonable ;) ) doubts, or suggestions how to
improve them, *now* is the time to tell us them. not in two weeks ;)
Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property that
has been used successfully in hundreds of IBM storage optimization engage-
ments, worldwide. Store less, Store more with what you own, Move data to
the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
Lmuse-developer mailing list