On dom, 2011-09-18 at 16:39 +0200, Fred Kiefer wrote:
I played around with that code and have it basically working now. This
version has about the functionality that our current in-window menu
support in gui provides, but it is very likely to break the existing
themes that offer extended support for this.
I could now either put that code into a branch where nobody would be
using it. Or commit it to gui trunk and have other fix the remaining
issues with that code.
I think is better in a branch, while we test this and try to solve the
remaining problems.
These are mainly in the tracking code, that has
become so complicated that I wont dare to touch it.
I wrote some of that code. So I can check this.
There we sometimes
use the menu representation of the main menu, and this of course wont be
correct any more. The actual used menu view wont be accessible from the
main menu any more, as each window will use its own one.
If this is fixed and all the themes work again, then the next step may
be done. in my opinion this would be the introduction of a new class
GSMenuRepresentation that stands between the NSMenu and the NSMenuView.
The main purpose of that class would be to hold the window we currently
store in the NSMenu. Instead of the two windows NSMenu would have two
GSMenuRepresentations one for the standard and one for the transient
display. That class would delegate most of the operations on to the menu
view. The important point here is not to use this class where it isn't
needed. We should try to avoid any internal knowledge of the menu
representation in gui (and even more in user code). That way we make it
a lot easier for themes to replace the actual menu display implementation.