m-7761
commented
5 years ago EDITED: In the last few days I've been working on TextureWidget and ModelViewport.
I'm ripping out the Qt parts, simply because I can't use them, since I don't have the headers. These are complicated classes. But I think it will be an improvement to replace the QEvent parts with neutral code, that will enable them to be separated from the Qt code.
In that way the UI windows that use these components should translate their events into neutral ones. My UI framework doesn't use data-structures (as event parameters) so how I write it should be sufficient.
I've also developed a base class I called ScrollWidget to get the parts of these classes that are identical under one roof. I personally don't like the overlay buttons, but they still have to talk to UI buttons either way if they were removed... like the zoom buttons are already outside of the classes.
I think it's much easier to implement the view area as a single window. Currently Model has a system called ContextT that is unnecessary if they share the area, and it doesn't help anything to have multiple (arbitrary numbered) Tool::Parent objects. That system generates new OpenGL texture IDs for every viewport... which means the textures are also duplicated in video memory. So that's a real bad system, that should probably be pulled out, just to simplify. It wouldn't be necessary if the contexts were created to "share lists" either. Which is the default or only available behavior anyway for some vendors. Like Nvidia I believe shares texture IDs like it or not. In that case ContextT is unnecessary.
Other than this, I've not changed the core code much, except to remove most instances of std::list. I think it can probably be cut back to a few actual queues. Before "move-semantics" were added to C++ list was kind of helpful to avoid destruction of large objects. But I've been using the new range-based for-loop in my new code, in which case the resulting code will be C++11. I'm pretty conservative about adopting C++11 features, but it's been around for a while, and I want to use it for my project at the application level anyway.
I think list is the likely source of reported instances of the editor freezing up that aren't legit bugs.
There are various MM3D_EDIT blocks throughout the "mm3dcore" code.
It's not used consistently, meaning that, if it were not "defined" the code simply won't compile.
It could be removed... however, the Model class is pretty crazy. If you look in this data, you'll see that it's not really storing anything pertaining to the model. Instead it's storing states for things like TextureWidget and TextureCoordWin.
I would say that the UI and Model code is inseparable in its present state. I can't say if it's worthwhile to try to break up Model, but I can confidently say that there is no modularity. At minimum I can see it having an alternative UI that interacts with Model identically, but uses a different package to realize the UIs.
In that case, in the very least, the "Tool" and "Command" parts should be abstracted away from the UI component. The TextureWidget and ModelViewport classes should be pure OpenGL classes, that don't relate to the UI component. That is to say, they should just execute OpenGL. They shouldn't derive from a window object.