From: Florian J. <flo...@we...> - 2011-04-14 19:46:33
|
Am 14.04.2011 20:58, schrieb Tim E. Real: > On April 14, 2011 02:03:07 pm Florian Jung wrote: > >> Hi >> >> as my score editor now can handle multiple staves, changing clef, >> merging staves, removing staves (try right-click, middle-click, or >> left-clicking-drag-and-drop on the "preamble" (the thingy containing >> clef, timesig and keysig)), i now want to give muse more menu entries. >> > Awesome work. Looking very, ahem, 'sharp'. > Nice work with the multiple part support. > > thanks :) >> i want the following entries: >> >> * open new score window, draw all selected parts into one staff >> * open new score window, draw all selected parts in their own staves >> * use existing window (let the user select it), draw all selected >> parts into one staff >> * use existing window (let the user select it), draw all selected >> parts in their own staves >> >> do you think these entries are reasonable? >> > Absolutely. Whatever you think is required for the flexibility if it can't > be combined further. > > >> and do you think that some of them should be more or less prominent (for >> example, "new win, all in their own staves" as menu entry, and the rest >> only reachable via submenus)? i don't think that. >> > I would probably group all four of them in a submenu under the 'Score' > Edit menu entry, for neatness. Similar to the Mastertrack entry. > When I beefed up cloning, the Edit menu gained 3 new 'Clone' entries, > which admittedly I know gave it a bit of 'menu-creep'. But those are > more like global functions so I felt they'd be best off prominently shown. > > If there is one item you think would be used much more than the other 3, > it'd be nice if clicking 'Score' could activate something on its own > AND still have a submenu. But if I recall how menus work, that might > not be possible. > this would be really cool. the folks at #qt in freenode told me, that every submenu is actually only a QAction, which is responsible for displaying a submenu. this means, when i store the QMenu::addMenu's return value (which is QAction*), i can connect that QAction's trigger with my slot -> this is possible. >> and, i need to know something about muses interna again ;) >> for implementing this, my ScoreEdit windows must get unique names. >> first, how should i let the user input these? and second, how can i >> store them? >> and, i need functions which list all available score windows by name, >> and functions which get me a particular score win (to map the user's >> click in the "use existing win" menu to some pointer i can operate with) >> >> what do you suggest? i think there's nothing comparable in muse so far, >> is there? >> > Ooh, tough one. Don't think we have anything like that now. > Are you sure you want the user to input these names? > Or if they could be automatically generated would that be OK? > Mostly the editors just passively display the currently edited part name + > track name in the title bar. But is that enough to uniquely identify your > windows? Maybe not. > i don't think that the part's or track's names will do. and even if they did, that wouldn't simplify stuff for me as developer, but makes stuff more complicated for me as user. > I gather you want these names because of the unique joining of various > parts together in your windows. So track name + part name not good enough. > yeah. when i open some parts in one score window, called "My Staff", and then i notice "ah, i also need part FOO", then i can right-click on FOO, and select "open in existing window -> 'MyStaff'", and voila ;) > I recall you spoke of this naming early on. > Hmm. You might have to make this from scratch. Thinking some more... > > ----- > PS. You can give a global speed boost, in your songChanged handler by > ignoring certain SC_ types - or rather, only responding to the ones you need. > SC_MIDI_CONTROLLER is definitely one to ignore if unneeded. > thanks, i note this in my TODO list. > It is sent repeatedly as a midi controller knob/slider is adjusted. > (Although, thinking about this the other day, it should probably have > its own midiControllerChanged signal, and songChanged really ought > to be reserved for slow, occasional changes.) > yep, that's true and i think some parts of muse (for example, my score editor when working on large pieces) could maybe benefit from some information about the parts, tracks and ticks which have changed. for example, when changing a note in measure 3, then my score editor actually only has to recompute measures 3 and 4. > (I need to remember to try to use specific xxxChanged signals rather > than use songChanged signals when possible, I've always found songChanged > a bit cumbersome, lacking information about who sent what. > Also - we have nearly run out of 32-bit SC_ values!) > > I guess you'll add a menubar at some point? At least we need the undo/redo > toolbar. Oh yes, and of course lots of buttons for notes etc. > yeah, i will, when the staves-stuff is done. however, i don't want to add tons of buttons. first, i'm working at a rather small screen and i hate tons of buttons ;) i like keybindings (ctrl+click, ctrl+mid-click), and mouse-buttons ;) second, there will never be buttons for notes, because my score editor lets you "pull" the note to its desired length. also, my score editor doesn't let you decide whether you draw a dotted quarter or a quarter tied to an eighth or an eigtht tied to a quarter. that would be suitable for musescore. > Some score editors have tons of buttons. > we won't need them > Anyway, Orcan and I can help with the menu/toolbars if required. > that would be nice; i'll tell you when i'm starting with that toolbar stuff, okay :)? > Thanks. Tim. > > >> greetings >> flo >> > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer > > flo |