From: Paul G. <dr...@gm...> - 2007-11-07 20:52:45
|
> Do you mean pop-out like VeSTige interface? > Basically. We can have model/view separation, sure. For example, instrument for the > model, instrumentView for the view. But you can't have > knobView/knobModel. knob is a GUI concept. The model shouldn't care > about knobs, sliders... graphical controls. You already have > automatableObject for the model. I agree, knobView/knobModel is bad. Thats why we will have automatableModel (the new automatableObject, it will inherit from model). Then, we have automatableView. This is basically where the model/view marriage stops. However, there will be a knobView and a perhaps a sliderView and spinBoxView that are derived from automatableView. These subclasses actually handle the presentation. The choice of subclass (i.e: knob vs slider) is determined by the programmer who writes the specific instrumentView (ie, lb302InstrumentView). Of course, all polymorphic stuff can still happen. For example, there *could* be a view for lb302InstrumentView that uses all sliders instead of knobs, but this is a bad idea. Maybe someday themes can define custom views for instruments; just a possibility. Does this sound reasonable to you? One of the big advantages of defining the model/view at this level is that the instrument developer doesn't need to worry about connecting his/her gui events themselves. Plus, we get a separate signal/slot for each parameter/widget, so it can optimize painting and rendering. If I had to write my own model/view for LB302, I know I would just make one signal/slot for anythingChanged() because I'm lazy. Of course, the instrument developer *would* have to "wire" events that are not handled by the widgets. For example, maybe someone decides to make the KICK plugin animate each time a note is played, they would have to do their own model/view separation for the kicked() signal. Ok, we add some sort of configuration setting. Anyway, the single > instrumentTrack window is a usability problem, very little to do with > performance. We could discuss this after the model/view split. > Yes the split sounds like a good idea, regardless of how it is eventually used. Something is a burden on performance, Maybe it isn't instrumentTrack view. All I know is LMMS consumes 100% CPU on my box, even when it is idle. (but only when the window is visible) > Then, if the main problems are memory and loading time, there are other > simpler options that should be tried before, namely image loading. So I > think we should use the style sheet feature to get pixels and colors out > of the code before doing any model/view split. > What is this style-sheet you are talking about? Is each instrument supposed to have a style sheet? This doesn't make sense... or are you saying a single style sheet for each "theme"? Sounds interesting never the less . Looking forward to your input, Paul |