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

Ralph Versteegen teeemcee at gmail.com
Mon Jan 15 07:43:48 PST 2018 

On 16 January 2018 at 04:35, James Paige <Bob at hamsterrepublic.com> wrote:

>
>
> On Monday, January 15, 2018, 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.)
>>
>
> That is pretty much all I meant. I want people to continue to be able to
> edit a simple menu without knowing or caring about all the other stuff it
> is capable of because it is really a plankmenu under the hood -- and I
> never thought you were trying to remove that, I was just clumsily saying I
> thought it was important :)
>

OK, I guess we are on the same page then. I thought maybe you meant having
separate script commands for the two menu types, or not giving menu slices
all the same 'behavioural' options.

Also, interesting, I notice that "swap menu items" can swap between
different menus. I had forgotten that. Something to keep in mind.
Strangely, there's no way to just move a single menu item to a different
menu.

>
>
>>
>>  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.
>>
>> Yes that all sounds reasonable
>
>
>
>> 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.
>>
>>
> That should be fine. If someone removes the box, then not being able to
> change the box's color is expected
>
>
>
>>
>>>
>>>> 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-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/812f45a6/attachment-0001.html>

More information about the Ohrrpgce mailing list