Idea for new main menu item
This could also be go in the developer's mailing list, but since that seems relatively inactive, and there is also a "user" aspect to this discussion, I'll start it here.
Sparked by this post http://musescore.org/en/node/14629#comment-50627, I have come to think there are certain things that might currently seem to be best done via a plugin, but that perhaps should better be done within the program itself. A number of these form an identifiable category of features that could be roughly described as "things that operate on a whole selected region and have a fairly profound effect on the score". The feature discussed in the aforementioned thread - a diminution / augmentation facility - falls into that category. I think the export and import plugins belong to that same category. I think the existing "Transpose" facilities, which currently lives in the Notes menu, probably belongs in this new category as well.
So my idea is that there could be a new top level menu "Transformations" (or whatever) that was designed to be a place where these types of features would live. Putting them in their own dedicated menu makes sense to the user, I think. But it also might make sense architecturally, as these operations could conceivably all share similar data structures and a core "loop through all notes in selection performing the following operation" algorithm. It could be architected in a way that was almost plug-in like, in that a programmer could go in and add functionality there with minimal fear of introducing problems elsewhere. His changes to the application source would be isolated to that one file, with some assurance that while the feature might or not might actually work, at least he was not breaking anything else. In that sense, it is like writing a plugin, but the advantage would be full access to the applications regular objects and methods.
I see this as a big advantage to me personally, but probably to other programmers as well who might be considering the possibility of getting into the code but are still rather afraid of having to really understand the entire architecture before getting started, and then still never really being sure if anything we add might break something else.
But if it were just about that, it wouldn't be worth it. As stated up front, I also think it makes sense from a user perspective to have a single menu from which these types of transformation can be applied, and I think there are already a good handful of candidates for populating that menu.
Comments
I'm not sure I understand how it would be decided which things wold belong under "transformations" and which ones would be better left as plug-ins? It also seems to me that a "transformation" facility would be useful to plug-in developers as well as developers of MS core code.
In a related vein, I have seen quite a few posts describing the plug-in framework as lacking certain capabilities and, sorry to hijack this thread, but it makes me wonder why the plug-in framework is so limited? Is there a strategic thought or goal that guides what capabilities the plug-in framework should have?
In reply to I'm not sure I understand how by mtherieau
Good questions. As for why the plugin framework is limited, I might guess that it's because the core program architecture has been a moving target, but I suspect it,s also wrapped up in the answer to the question of what "belongs" as a plugin versus in the program itself.
There are several drawbacks to implementing something as a plugin. One is that it takes extra work for people to install. Another is that plugins are not easily localizable (eg, translating the labels in a dialog box). Another is that they run slower. Another is that having a lot of them installed causes MuseScore to load more slowly. They also can't be assigned jeyboard shortcuts.
So to me, it's the things you think lots of people would want access to without needing to go thru hoops that make sense to have in the program itself. Whereas special purpose things only of interest to a few can stay plugins. Actually making that determination is a judgement call, of course, but that's how I personally would be trying to decide. Plus, of course, the practical aspect that some things just *can't* currently be done as plugins.
In reply to Good questions. As for why by Marc Sabatella
Well, it is not that hard to localize a plugin (as you know I did it for "Batch Export"), This is just not (yet!) intregated into the translation server.
In reply to I'm not sure I understand how by mtherieau
The framework as it exists today was put in place by Werner during the 0.9.6.x series. There are two reason why it hasn't evolved very much:
The current status: Werner is busy stabilizing the core but has no time to for the framework. So if anyone would be interested to pick this up, feel free.
In reply to Framework status by Thomas
No promises, but I think this is something I may be to help with at some point. Biggest hurdle for me is still finding the time and disk space to get a build environment going.
In reply to No promises, but I think this by Marc Sabatella
On my Windows 7 (32-bit) environment:
Source code takes ca. 350 MB
A locally compiled debug version takes ca. 1.5 GB
Qt SDK takes ca. 800 MB*
On my Ubuntu 11.10 (also 32-bits):
Source code takes ca. 180 MB
A locally compiled debug version takes ca. 1.2 GB
Qt SDK takes ca. 520 MB*
In both cases, a handful of other MB's is needed for collateral tools like cmake, JACK (on Win) and so on.
* Qt SDK disk occupation depends upon the features installed; roughly speaking the above figures refer to an installation with everything for C++ / desktop, but nothing for the other languages / platforms.
(Qt SDK includes much more than the 'simple' Qt libraries needed for compiling MuseScore, but according to my experience it is worth using)
Hoping it might be useful to know,
M.
In reply to Some data about disk space by Miwarre
Useful indeed. Does that figure for the "Qt SDK" include the C++ compiler and its libraries as well? I currently have under 5GB free on both of my partitions and am continually going into cleanup mode to keep at least that much free just for general operation. When I installed Qt and saw it take up almost 1GB by itself, I figured I was in for trouble.
But I do have an external 60GB drive I could use just for builds. Heck, I could even use a flash drive, I suppose.
In reply to Useful indeed. Does that by Marc Sabatella
Come now Marc, storage is (or at least was until recently) quite cheap. Upgrade!
As for the external drive (USB?), just make sure the drive letter doesn't change as the compile will complain loudly (and fail) if it does.
Regarding the flash drive, compiling will be much slower! But at least large flash keys (16, 32Gb) are reasonably cheap now. (I wonder when SSD will take over the mechanical drive market.)
In reply to Come now Marc, storage is (or by schepers
FWIW, upgrading the drive in my laptop is a possibility, but so is buying a new laptop, as this one is old and has other weaknesses. The possibility of buying a Mac specifically so I can play with development of iBooks textbooks and other development for iOS has also occurred to me, but that's a bigger investment (of money *and* time, as I've never used MacOS and will have to deal with that learning curve). So I've got some bigger issues to resolve in my mind before making any investment in hardware.
Thanks, though, for the heads up on the drive letter issue and flash drive speed. I now remember this being pointed out last year when I first started toying with the idea. I knew there was a reason I didn't just install the build environment then!
In reply to Framework status by Thomas
Totally understand lack of time and more pressing priorities and it's actually a relief to hear that, as I was wondering whether the functionality available to plug-ins was limited by intention. I am very interested in helping out in this area but would first need to come up to speed in how the current frameworks "works" ;-)
I just stumbled across this topic through a link from an issue found by an issue tracker search inspired by this post . Remarkably, I've been gathering similar thoughts over the past few days, and have been planning to start a new discussion about some menu rearrangements. I'll still do that, but I'll drop this thought off here as early preview: I definitely think "Tools" (currently a semi-hidden sub-menu of "Edit") should be its own menu, and I think that "Transpose" belongs there as well. I.e., I came up with the same idea entirely on my own.