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

James Paige Bob at hamsterrepublic.com
Sat Jan 13 17:09:56 PST 2018 

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.

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 ;)


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/ohrrpgce/commits/d1963ff335e7afd8e
>>> 82d12dd1d92df3251b2f6e8?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-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/20180113/6a575aec/attachment-0001.html>

More information about the Ohrrpgce mailing list