Re: [Lmuse-developer] maybe rewrite muse?

[Florian J. <flo...@we...>]

Am 15.11.2011 23:39, schrieb Robert Jonsson:
> Hi Florian,
>
> just a quick one, trying to keep up ;)
>
> 2011/11/15 Florian Jung<flo...@we...>:
>    
>> Hi
>>
>> muse keeps showing bugs which are somewhere between strange and totally
>> weird... i really think muse's code design is, well, "not very good".
>>
>> i think, especially the move to qt4, but also just developing muse on
>> introduced several pieces of code where race-conditions would appear, or
>> where previously made assertions were broken.
>>
>> what do you think of kind of rewriting muse from scratch?
>> of course, not completely: i'm sure we can reuse most code, but we maybe
>> should really tear it all down, and build it up again. that way, we can
>> identify and fix most, if not all, places where wrong assumtions were
>> made (for example, that "closing-windows-aren't-deleted-in-time" thingy
>> we had recently).
>>
>> muse's internas are pretty complicated, i hope you'll agree with this.
>> but i don't think that they HAVE to be that complicated. i think orcans
>> namespaces are a first step to this, but we should separate muse more
>> and more into smaller pieces, like "sequencer", "file loading/saving
>> engine", "single midi editors", "audio drivers", which are _completely_
>> abstracted from each other. they aren't currently (at least not
>> completely); for example, the midi editors access the sequencer more or
>> less directly ("is the song still playing"? "what's the current
>> position" via song->cpos() etc). if we can abstract all that with
>> signals, slots or similar techniques, i think we can muse a lot simpler
>> and cleaner. and thus, we make the danger of such bugs much smaller.
>>
>> i know that my proposal is a pretty radical one, and actually it's not a
>> proposal but just a suggestion. i'm pretty sure that there's a less
>> radical way with the same effect.
>> but i'd like to discuss this: how can we "rescue" muse's design?
>>      
> Rewrite as in starting over is something we would never have the
> strength for, but that isn't what you want I think.
> Yes, MusE, as most bigger projects, are in need of restructuring to
> keep it vital. I know Tim has over time done several simplifications
> to the internals and now Orcan's namespaces are a good step forward in
> structuring things.
> Personally I don't believe in doing radical changes, but starting to
> break out structures where such are called for I think would be a good
> thing, for the code and for finding bugs.
>
> I'm not entirely sure what bugs you are referring to with cpos though.
> Sure it's accessed through a global pointer but have we really had any
> bugs with that?
>    
we had no bugs with it. it's just unclean that everything is reading 
that cpos variable, instead of being informed.

i think we should make muse consist of single small parts which also can 
work without the rest.
that would allow us to completely rewrite, say, the sequencer engine 
without having to touch the rest at all.

that is, do true encapsulation on muse.



also, in muse there are lots of large commented out code parts, and 
unused files.

could we please definitely remove them?
either during the release phase now, or immediately after it (i'm for 
NOW), someone like tim or you, robert, has to go through all (ALL) 
files, and decide whether the commented out code (that includes a) 
commented out large passages, b) #if 0 constructs, c) commented out 
single code lines, d) /* commented out parameters */) in there are still 
needed. if not, remove them. if yes, hrm, well. actually this should not 
be the case. the only reason for this might be that there was a critical 
change, and we want to keep the old code around as well in case of 
failure. but that's what svn is for!
just checkout an earlier revision, and you have the code again!

is there any other reason for commented out larger passages of code? or 
for files which are not used?


for unused file, i propose to either erase them if they're not needed at 
all, or to move them over to some "old files" directory, so one clearly 
sees "this file is not used".

i've often the problem that i want to fix some widget, but i don't know 
whether i want to fix the widgets/foo.cpp or the awl/foo.cpp file.




about the restructurations:
i don't think that "fix it as you pass by" will work. real structural or 
design changes require large bunches of changes to almost all files in 
muse. that isn't a "do it while you're at it" thing.

maybe after releasing muse2, we should sit down, write down everything 
muse must be able to do, create a _completely new_ design (oriented but 
not restricted to the current design), and then we go it through line by 
line. each class, each code file which does not behave as the new design 
says will be adapted to do so. i hope that this will create a much 
cleaner muse while keeping the changes and work effort as small as possible.

do you have different ideas, or anything to discuss about mine?

greetings
flo

> Regards,
> Robert
>
>