Re: [Lmuse-developer] .musePrj and .MusE

[John C. <j4s...@bi...>]

On Sunday 07 December 2003 04:43 pm, Robert Jonsson wrote:
> Sunday 07 December 2003 18.20 skrev Mathias Lundgren:
> > Evenin' fellas!
> >
> > I think I found one of the things that has kept bugging me since my first
> > day using MusE. While playing around with the config-file (.MusE) and
> > adding shortcuts to it, I never got MusE to actually find the
> > <shortcut>-tag in ~/.MusE after saving the configuration. Puzzled I was,
> > and finally I realized that it also depends on the project. If there's an
> > old project-file (== .musePrj has entries) .MusE is not used but the
> > projectfile's configuration values instead. Removing .musePrj causes muse
> > to go for the config-values of ~/.MusE, not the one in the particular
> > project.
> >
> > I realize it might be good to have some config-values saved with the
> > project, but I really don't like the way it's handled today... It has
> > caused me a lot of problems and confusion, and I'm sure other ppl as
> > well. So what do we do about this (not that it is any panic about this, I
> > think there are other things with higher priority, but in the future)?
> >
> > Here are a few ideas:
> > 1) Move a lot of things out of the project-files to make muse go for
> > global values in .MusE instead.
> > 2) First load the project file, then overwrite the values with those from
> > .MusE (I'm afraid this will be messy)
> > 3) Skip opening of last opened project and always load ~/.MusE-values on
> > startup. (the easiest way, IMHO. Perhaps it's necessary to ignore a few
> > of the project-specific config-values as well...)
>
> I'm not that fond of autoloading projects anyway, so settling for 3 would
> not be a problem for me anyway...
>
> The contents of the .musePrj file appear in the "Load Recent" menu choice,
> right?
> This is in my opinion "good enough" to make it easy for the user to load
> the last project(s) they worked on.
>

I'm on a new project more often than not. Autoloading is inconvenient for me.
MuSE doesn't crash enough to make autoloading a good thing. It would be good 
as an option.
IMO all the studio setup and interface related stuff should go in .Muse and 
that file should be an optional include in the .med files.

I'm looking at a .med file... the printer definition.. That's a pretty good 
example of something that's local in scope. The background wallpaper...
Another example. If it isn't window layout or control data it should be 
in .MuSE.