<br><br>On Sunday, January 14, 2018, Ralph Versteegen <<a href="mailto:teeemcee@gmail.com">teeemcee@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 14 January 2018 at 14:09, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div>I do think that keeping a logical separation between menus and special screens is important, even if they both end up using plankmenu features under the hood.<br><br></div>A homogeneous vertically scrolling menu is not the same thing as a potentially complex compound menu-like structure that allows cursor movement in multiple directions and might have sub-sections that scroll independently.<br></div></div></div></div></div></blockquote><div><br></div><div>But my objection is against plankmenus only being available in built-in/special menus. They ought to be available to people to use in their scripts and slice collections, as Menu slices. So if the distinction in menu types shouldn't be "between menus and special screens" but "between MenuDef (Menu Editor) menus and plank (Menu slice) menus".</div></div></div></div></blockquote><div> </div><div>Oh, I agree that plank menus should not be limited just to built in special menus. Yes, I just want MenuDef and plankmenys to reamain two different things. I think we are probably on the same page here and I am just stumbling a bit on terminology :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">MenuDef menus really define 3 types of things:</div></div><div class="gmail_extra"><div class="gmail_quote">1) the appearance of the menu, such as position, text color, item spacing, and the appearance of the menu items too</div><div class="gmail_quote">2) the 'logical' definitions of the items: captions, types/use actions, tag conditions, hide-if-disabled, close-menu-when-selected, etc<br></div><div class="gmail_quote">2.1) how the menu behaves: on close script, suspension of gameplay, no player control, open menu when closed, etc<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Plank menus defined as slice collections are a replacement for #1.</div><div class="gmail_quote">But they don't cover #2 (aside from fixed captions) or #2.1 at all. Instead, you have to use slice extra data and so on and write custom logic.<br></div><div class="gmail_quote">Menu slices/Menuitem slices need to cover #2, otherwise they're not really menus!</div><div class="gmail_quote">I think they should also cover #2.1, because I see no benefit to not doing that, and the implementation of #2 and #2.1 are totally intertwined anyway, so it would be extra work to *not* implement #2.1.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">That's what I mean by overlap between the menu types: sharing that logic.<br></div><div class="gmail_quote">In fact, currently MenuDef menus in general don't implement #2 and #2.1 at all, that stuff only works for in-game map-mode menus (which I'll call "custom" menus). MenuDef menus are used in Custom, and in battles, but the types and subtypes are only intended to accommodate custom menus and do nothing elsewhere, so even in battles the logic for tag conditions on menu items and so forth was all reimplemented. Would be nice if menu items had an option to call a FB callback (not exposed to users, obviously).<br></div></div></div></blockquote><div><br></div><div><br></div><div>I think I follow. And the callback is a cool idea. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><br></div>By the way, I don't know if I ever explained where the "plank" in plankmenu came from, or whether or not it is obvious.<br><br></div>My mental image was this:<br><br><a href="https://i.imgur.com/WZmhCSS.jpg" target="_blank">https://i.imgur.com/WZmhCSS.jp<wbr>g</a><br><br></div>...actually, this one probably does it better justice: <a href="https://i.imgur.com/BDea9XY.jpg" target="_blank">https://i.imgur.com/BDea9XY.jp<wbr>g</a><br><br></div>...or this I guess? <a href="https://i.imgur.com/unDp3At.png" target="_blank">https://i.imgur.com/unDp3At.pn<wbr>g</a> ;)<br></div></blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">A desperate act of last resort! A bridge to a new menu system was urgent! The final plank in the grand slicification scheme! <div><br></div><div>(Yes, obviously what was meant :)<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div> <br></div></div></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 13, 2018 at 4:34 PM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On 14 January 2018 at 05:42, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br><br>On Saturday, January 13, 2018, Ralph Versteegen <<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 13 January 2018 at 05:24, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>s/SliceLoadFromFile/load_plank<wbr>_from_file/ in my previous mail<br><br></div>Opps! ;)<br></div></blockquote><div><br></div><div>Wait a minute, I just finally noticed you switched to my spelling, and have been doing it for a long time!<br></div><div> </div></div></div></div></blockquote><div><br></div></span><div>Haha! It's a "thing" now :)</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 12, 2018 at 8:19 AM, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>Opps! I'll fix where I forgot to free the collection in SliceLoadFromFile<br></div>It looks like I am leaking the whole collection every time, even if the load succeeds.<br></div></div></div></blockquote></div></div></div></div></blockquote><div><br></div><div>Oh, I didn't even notice that bug! That wasn't what I meant.  The only way to check whether SliceLoadFromFile failed or not is to check if any slices were actually loaded... but if they didn't load, then the lookupslice will fail anyway, so that "if col = 0 then ..." does nothing<br></div><div> </div></div></div></div></blockquote></span><div>Oh! Right! I can fix that. The next check after that, for whether sl_plank_holder was found is good enough on it's own.</div><span><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div>I'm looking forward to learning more about template slices and menu slices. I'll probably have to read your writeup before I understand :)<br></div></div></blockquote></div></div></div></div></blockquote><div><br></div><div>Hmm, this is a long and unfinished writeup, and at the top I have notes to myself to firsr finish and email, or in merge in two other writeups!</div><div><br></div>Template slices is basically just hidden slices, ignored for almost all purposes (importantly, collision detection, so you can't click on them) but which are shown by default in the slice editor, tagged with [TEMPLATE]. Their main use is to replace plank collections. If you want to add a new menu item to a plankmenu, just clone a template slice (indexed with a lookup code), instead of loading a collection and copying over the plank. Conceivably you could have multiple item templates. So, this will let you see the whole menu while you edit the menu slice collection. <br></div><div class="gmail_quote">My branch: <a href="https://bitbucket.org/rbv/ohrrpgce/commits/d1963ff335e7afd8e82d12dd1d92df3251b2f6e8?at=templates" target="_blank">https://bitbucket.org/rbv/ohrr<wbr>pgce/commits/d1963ff335e7afd8e<wbr>82d12dd1d92df3251b2f6e8?at=tem<wbr>plates</a></div><div class="gmail_quote">(This turned out a bit messy, I wanted to try to clean it up)<br></div><div class="gmail_quote"><div><br></div></div></div></div></blockquote><div> </div></span><div>Okay, I follow. That seems like a good idea. I like it. I feel like I would use it.</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>As for the rest of it, let me just state this core crazy idea:<br></div><div>Replace menu handles and menu item handles with menu slice handles and menu item slice handles.</div><div><br></div><div>The "create menu" command would create *both* a new menu and a new menu slice, which appear to be exactly the same thing from the point of view of scripts. The handle it returns could be passed to any existing menu command, or used as a slice handle. Note that "create menu" fits the pattern for "create rect", "create text", etc.</div><div>Having both menus and menu slices and making them different things with different kinds of handles, and adding commands to convert from one to the other, seems totally unnecessary and harmfully confusing. Three different handle types for heroes is endless trouble.<br></div><div>Ditto for menu items: they also would become slices, but they would be different from other slice types in that they are always linked to a certain menu slice, must be a descendant of that slice, and can't be created independently. Typically they will have a single text slice child, and various existing menu and menu item command will have the effect of modifying that child.<br></div><div>We could either merge MenuDef and plankmenu entirely at a low level, or at a higher one (so MenuDef builds on top of plankmenu or vice versa, or an abstraction layer over the two).<br></div><div> </div></div></div></div></blockquote><div><br></div></span><div>That sounds like a difficult plan! I am not opposed, just saying it sounds hard. <br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br></div><div>I suppose having good unit tests for all the old menu scripting commands will make it significantly easier. I know we have a bunch, I'll have to go over them and see what is missing</div><div><br></div><div>If I understand correctly, the goal would be to re-implement menus as plankmenu-style slices, and to make MenuDef a backcompat wrapper around them. (Am I close?)</div></blockquote><div><br></div></div></div><div><div>Yes, it will be a lot of work.<br></div><div><br></div>All my talk
 about scripting handles is a distraction of course, the main idea 
is to only have one unified menu system as seen by scripts, rather than two.</div><div class="gmail_quote">Yes, loading a MenuDef menu could construct a plankmenu. That's the easy part. The hard part would be supporting script commands like "set menu text align", which would have to be rewritten to iterate over menu item slices, like plankmenus, unless they just destroy and recreate the menu (would be quite a cop-out).<br></div></div><div class="gmail_quote"><div>But if every plankmenu (menu slice) is also a MenuDef menu from the view of scripts, then each of the builtin menus like status should also support all the existing menu commands? Well, quite a lot of them won't make sense if the slice tree layout differs from the default MenuDef layout. I think it's OK if script commands like "set menu text align" just fail to do anything in that case; they would be specific to the subtype of menus built from a "real" MenuDef. Uh oh, looks as if we would effectively have two menu types anyway (*). (If we have two subtypes, then those script commands could maybe throw errors instead?)<br></div><div>Very similar is the problem of how to let you create menus in the slice collection editor - or whether you could only create a menu slice that way when editing the collection for a builtin or MenuDef menu.<br></div></div><div class="gmail_quote"><div><br></div><div>(*) The two subtypes I mean are that every (classic MenuDef) menu has a menu slice (aka plank menu), but not every menu slice has a MenuDef menu. This seems pragmatic.<br></div><div>But, even if there isn't complete overlap of the two, it would still be great to have as much overlap as possible. For example, it seems sane to make plankmenus part of the same focus system (menu stack) as existing menus.<br></div><div><div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br>---<br></div>James<br><br><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Fri, Jan 12, 2018 at 8:04 AM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On 12 January 2018 at 13:00,  <span dir="ltr"><<a href="mailto:subversion@hamsterrepublic.com" target="_blank">subversion@hamsterrepublic.co<wbr>m</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">james<br>
2018-01-11 16:00:45 -0800 (Thu, 11 Jan 2018)<br>
38<br>
load_plank_from_file() helper function<br>
---<br>
U   wip/plankmenu.bas<br>
U   wip/<a href="http://plankmenu.bi" rel="noreferrer" target="_blank">plankmenu.bi</a><br></blockquote><div><br></div></span><div>+ DIM col as Slice Ptr<br>+ col = NewSliceOfType(slSpecial)<br>+ SliceLoadFromFile col, filename<br>+ IF col = 0 THEN visible_debug "load_plank_from_file: unable to load slices from """ & filename & """": RETURN 0<br><br></div><div>This doesn't work:  if SliceLoadFromFile fails, it doesn't delete col.</div><div><br></div><div>I actually have a git branch where I was working on making SliceLoadFromFile return a new slice instead of modify an existing one. Which was a surprisingly large change. I don't remember why I didn't check that in; maybe it didn't seem worth the effort to finish it.</div><div><br></div><div>BTW, I have been working on changing the way that plankmenus work. I am getting rid of "plank" collections and instead using template slices parented directly to the menu slice collection. Oh... I didn't check in template slices yet either? Well, it's basically just another Slice bit which works very similarly to Slice.Visible. Well, after planks are gone maybe plank menus should be renamed... I have a suggestion: Menu Slices. As in, promote them to a new slice type so that they can be used by scripts too, not just from FB. I have a long writeup about this which I haven't finished yet...<br></div></div></div></div>
<br></div></div><span>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div><br></div></div>
</blockquote>
</div></div><br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div></div></div><br></div></div>
<br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org" target="_blank">ohrrpgce@lists.motherhamster.o<wbr>rg</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.org<wbr>/listinfo.cgi/ohrrpgce-motherh<wbr>amster.org</a><br>
<br></blockquote></div><br></div></div>
</blockquote>