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. > > _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
