[Ohrrpgce] SVN: james/9958 load_plank_from_file() helper function

Ralph Versteegen teeemcee at gmail.com
Mon Jan 15 07:22:42 PST 2018 

On 15 January 2018 at 10:15, James Paige <Bob at hamsterrepublic.com> wrote:

>
>
> On Sunday, January 14, 2018, Ralph Versteegen <teeemcee at gmail.com> wrote:
>
>>
>>
>> On 14 January 2018 at 14:09, James Paige <Bob at hamsterrepublic.com> wrote:
>>
>>> 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.
>>>
>>> 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.
>>>
>>
>> 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".
>>
>
> 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 :)
>

I don't think we're actually in agreement yet. I'm not sure quite what you
mean by a logical separation, although as I already said, it seems logical
to have two subtypes of menu. (This would make extra sense if we have two
different editors for them: the Menu Editor, and the Slice Collection
Editor, which is a difference that I couldn't yet figure out how to
remove.) I see "homogeneous vertically scrolling menu" as just a particular
layout of slices.
Suppose we add Menu slices which use the plankmenu code for cursor
movement. And that MenuDef menus are converted to slices, constructing a
slice tree rooted by a Menu slice.
Well, then even if the two types of menus are treated quite differently
from a scripting perspective, I could just write a script to edit the
slices for a MenuDef menu, giving its grid slice (assuming we use one) two
columns instead of one. And it would work. Any other rearrangement of the
menu item slices would also work.

Note that if MenuDef menus are built on top of plankmenus, then they will
no longer use MenuState, because that *is* specific to homogeneous linear
menus. Instead, they'd switch to PlankState. I don't think we actually need
top, first, last, etc, for anything. (I'll be happy with that, it'll fix
one graphical glitch I couldn't fix.) Menu items will still be ordered, by
depth-first order of their slices, so "next menu item" works. And menu
items will still have a "true slot", which will still be stored in the
MenuDef as the original order. Any disabled and hidden menu items will be
made invisible and moved to the end of their siblings.

But as I said before, there could be a problem with commands that affects
menu appearance, such as "set menu boxstyle". That command would edit a
rectangle slice with a certain lookup code. If the slice was deleted, the
command will do nothing.


>
>
>> MenuDef menus really define 3 types of things:
>> 1) the appearance of the menu, such as position, text color, item
>> spacing, and the appearance of the menu items too
>> 2) the 'logical' definitions of the items: captions, types/use actions,
>> tag conditions, hide-if-disabled, close-menu-when-selected, etc
>> 2.1) how the menu behaves: on close script, suspension of gameplay, no
>> player control, open menu when closed, etc
>>
>> Plank menus defined as slice collections are a replacement for #1.
>> 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.
>> Menu slices/Menuitem slices need to cover #2, otherwise they're not
>> really menus!
>> 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.
>>
>> That's what I mean by overlap between the menu types: sharing that logic.
>> 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).
>>
>
>
> I think I follow. And the callback is a cool idea.
>
>>
>>
>>>
>>> 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.
>>>
>>> My mental image was this:
>>>
>>> https://i.imgur.com/WZmhCSS.jpg
>>>
>>> ...actually, this one probably does it better justice:
>>> https://i.imgur.com/BDea9XY.jpg
>>>
>>> ...or this I guess? https://i.imgur.com/unDp3At.png ;)
>>>
>>
>> A desperate act of last resort! A bridge to a new menu system was urgent!
>> The final plank in the grand slicification scheme!
>>
>> (Yes, obviously what was meant :)
>>
>>>
>>>
>>> On Sat, Jan 13, 2018 at 4:34 PM, Ralph Versteegen <teeemcee at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 14 January 2018 at 05:42, James Paige <Bob at hamsterrepublic.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Saturday, January 13, 2018, Ralph Versteegen <teeemcee at gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 13 January 2018 at 05:24, James Paige <Bob at hamsterrepublic.com>
>>>>>> wrote:
>>>>>>
>>>>>>> s/SliceLoadFromFile/load_plank_from_file/ in my previous mail
>>>>>>>
>>>>>>> Opps! ;)
>>>>>>>
>>>>>>
>>>>>> Wait a minute, I just finally noticed you switched to my spelling,
>>>>>> and have been doing it for a long time!
>>>>>>
>>>>>>
>>>>>
>>>>> Haha! It's a "thing" now :)
>>>>>
>>>>>
>>>>>>
>>>>>>> On Fri, Jan 12, 2018 at 8:19 AM, James Paige <
>>>>>>> Bob at hamsterrepublic.com> wrote:
>>>>>>>
>>>>>>>> Opps! I'll fix where I forgot to free the collection in
>>>>>>>> SliceLoadFromFile
>>>>>>>> It looks like I am leaking the whole collection every time, even if
>>>>>>>> the load succeeds.
>>>>>>>>
>>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>> I'm looking forward to learning more about template slices and menu
>>>>>>>> slices. I'll probably have to read your writeup before I understand :)
>>>>>>>>
>>>>>>>
>>>>>> 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!
>>>>>>
>>>>>> 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.
>>>>>> My branch: https://bitbucket.org/rbv/ohrr
>>>>>> pgce/commits/d1963ff335e7afd8e82d12dd1d92df3251b2f6e8?at=templates
>>>>>> (This turned out a bit messy, I wanted to try to clean it up)
>>>>>>
>>>>>>
>>>>> Okay, I follow. That seems like a good idea. I like it. I feel like I
>>>>> would use it.
>>>>>
>>>>
>>>>>
>>>>>
>>>>>> As for the rest of it, let me just state this core crazy idea:
>>>>>> Replace menu handles and menu item handles with menu slice handles
>>>>>> and menu item slice handles.
>>>>>>
>>>>>> 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.
>>>>>> 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.
>>>>>> 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.
>>>>>> 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).
>>>>>>
>>>>>>
>>>>>
>>>>> That sounds like a difficult plan! I am not opposed, just saying it
>>>>> sounds hard.
>>>>>
>>>>
>>>>> 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
>>>>>
>>>>> 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?)
>>>>>
>>>>
>>>> Yes, it will be a lot of work.
>>>>
>>>> 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.
>>>> 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).
>>>> 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?)
>>>> 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.
>>>>
>>>> (*) 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.
>>>> 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.
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>> ---
>>>>>>>> James
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jan 12, 2018 at 8:04 AM, Ralph Versteegen <
>>>>>>>> teeemcee at gmail.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 12 January 2018 at 13:00, <subversion at hamsterrepublic.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> james
>>>>>>>>>> 2018-01-11 16:00:45 -0800 (Thu, 11 Jan 2018)
>>>>>>>>>> 38
>>>>>>>>>> load_plank_from_file() helper function
>>>>>>>>>> ---
>>>>>>>>>> U   wip/plankmenu.bas
>>>>>>>>>> U   wip/plankmenu.bi
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> + DIM col as Slice Ptr
>>>>>>>>> + col = NewSliceOfType(slSpecial)
>>>>>>>>> + SliceLoadFromFile col, filename
>>>>>>>>> + IF col = 0 THEN visible_debug "load_plank_from_file: unable to
>>>>>>>>> load slices from """ & filename & """": RETURN 0
>>>>>>>>>
>>>>>>>>> This doesn't work:  if SliceLoadFromFile fails, it doesn't delete
>>>>>>>>> col.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> 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...
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Ohrrpgce mailing list
>>>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>>>>> amster.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Ohrrpgce mailing list
>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>>> amster.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Ohrrpgce mailing list
>>>>> ohrrpgce at lists.motherhamster.org
>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Ohrrpgce mailing list
>>>> ohrrpgce at lists.motherhamster.org
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Ohrrpgce mailing list
>>> ohrrpgce at lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>
>>>
>>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20180116/164dc531/attachment-0001.html>

More information about the Ohrrpgce mailing list