Thanks for the reply, virtual internalPathChanged () will be cool! I would also like to ask you to give a little time to WMenu, because in some cases it is not working properly, for example, select (-1, false) in the same internalPathChanged () in my opinion is not correct, because the first menu item is selected, only if it is have empty pathComponent(). Also, there are problems with the emitting of a signal internalPathChanged () by select (), it is not emitted in all cases when it should. This is related to the procedure call selectVisual() and then it called twice (first time on a signal, the second of the method select()) is alarming, because previous internal path from WMenu be the same as the current one.
WCompositeWidget at a specific internal path is interesting! We look forward to! Best regards, Aleksey 2010/5/18 Koen Deforche <[email protected]>: > Hey, > > I need some reflection time on the patch and the main problem. > Basically, I am not sure if people will expect that depending on the > state of your submenu, you will want the link to the menu item and > submenu to have a different path and meaning associated with -- unless > you also update the label each time ? With internal paths, it always > helps to reflect on how a web spider will see your site, or a browser > without JavaScript support. And I believe this should be as consistent > as possible (no links that change meaning depending on not-so-obvious > other state). > > That said, making internalPathChanged() virtual does provide alot of > added flexibility, and the semantics of this method are quite clear, > so I am inclined to do this. But does that provide enough flexibility > since your patch changes WMenu and WMenuItem at various places ? > >> Well, first of all I do not do submenu's like how the examples do, I >> needed more control, so in each WMenu I have a container, in that >> container I have another WMenu if necessary (and so forth if >> necessary). Those containers are subclassed from some generic logic >> of my things that handle that with an internalpathchanged. >> >> In my opinion, internalPathChanged callbacks really need to be >> changed. Instead of just handling every single path change, they >> should register to a certain part in the hierarchy. It could easily >> be handled very efficiently internally by a tri-tree. Hmm, would you >> accept a patch if I committed such a change? > > I have been thinking of this problem too -- and my solution so far (in > a branch) is to be able to deploy a WCompositeWidget at a specific > internal path, and then have a virtual method which is invoked only if > the internal path changes at that level. I think this is very similar > to your solution ? > > Regards, > koen > > ------------------------------------------------------------------------------ > > _______________________________________________ > witty-interest mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/witty-interest > ------------------------------------------------------------------------------ _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
