"Leslie P. Polzer" <[email protected]> writes: >> I would like to ask for agreement on how we specify selected/disabled >> (and hidden) panes for render-menu. In my trees they were specified by >> uri-token, not the human-readable name. I had a very good reason for >> that: it's consistent, it's precise, and I didn't have any issues with >> menu items that have names with non-ASCII characters in them. Things >> worked fine, but now as I transition to the latest weblocks-dev I find >> that things are broken again. >> >> Could we please agree that all render-menu arguments (except for the car >> in option cells) use tokens, not names? Is this a problem for anyone? > > This doesn't seem like a lack of agreement to me. I fully concur in > that we should identity panes by their token name. If that's not the > case then it needs to be fixed. > > What changeset/code are you referring to, exactly?
I am not quite sure, I can't track it down. However, in my tree the changeset: fa8ad2d04f4aea6935b756acf2d397529c69a8e0 navigation system rewrite: first attempt introduced this change to src/snippets/menu.lisp: - (target (cdr option)) - (pane-selected-p (equalp (attributize-name (car option)) selected-pane)) + (target (or (cdr option) "")) + (pane-selected-p (equalp target selected-pane)) You can see that target (an uri-token) is being compared to selected-pane. The corresponding [PATCH 21/62] navigation system rewrite: first attempt (commit 1311: 81a736409736) does something different: - (pane-selected-p (string-equal (attributize-name (car option)) - (attributize-name selected-pane))) + (target (or (cdr option) "")) + (pane-selected-p (equalp (attributize-name (car option)) + selected-pane)) Here (attributize-name (car option)) is being compared with selected-pane, which I think is not the right approach. I don't know where the disparity comes from. --J. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
