Conversation
|
Merging this without merging the dependent PR in core. This has no side effects but changes some code paths that I want to make further additions to... |
|
Yep, tried it and it looks cool - needs additional work as you know 👍. |
|
In fact, even all the "uncrappifiy" work that I did on all of this heaven stuff, is far from being enough. I tried several times to finish this views thing and always came to the same conclusion: This stuff must be rolled up from the ground and be done in one piece. That's what I'm about to try. But actually, I think that I can predict, this will become another "big bummer" :) But hopefully not again a 40% code addition like the basic RM work (I still don't feel like it's working and missing half of what I planned to do) |
|
Let me just note, that the CentralUI module of libHeaven is a total mess. Even the guts of QMainWindow are more pleasant to dig around and fix... Actually, one cannot do anything without rearranging half of the code. This is clearly not the best concept I ever created... |
2 participants
This is the rivalling change for #18. Looking at it, it might be more a prerequisite. I don't think they will clash, but this one isn't fully finished yet.
What this does, is: Split the
Heaven::ViewDescriptorinto 2 classes. One of them is private and does the descriptor management now. It additionally keeps a checkableQActionfor every view. This action is checked when the view is visible and unchecked when not. When the user unchecks the action, the view is closed.Missing is still: When the user checks the action, the view shall appear. But actually, this requires some more work than I initially thought. So I'm probably again deferring a part of a libHeaven task for later.
@antis81 I think, that libHeaven has become an unloved stepchild of mgv lastly. Partially I have problems to remember what work I have begun and what is still completely not started. Add to that that the most concepts of libHeaven are (at least internally) very hard to grasp...