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

Ralph Versteegen teeemcee at gmail.com
Mon Jan 15 07:35:32 PST 2018 

On 16 January 2018 at 04:22, Ralph Versteegen <teeemcee at gmail.com> wrote:

>
>
> 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.
>

Also, the slices for a MenuDef menu would include a template slice used for
adding new menu items.


>
> 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.
>

If you could do all these scripted edits to the slices of a menu, it seems
reasonable to allow editing the slice collection in the Menu Editor
directly. That's something for the future. Afterall, you can't edit textbox
slices in Custom.


>
>>
>>
>>> 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-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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20180116/fcb7fda6/attachment-0001.html>

More information about the Ohrrpgce mailing list