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

Sat Jan 13 16:34:23 PST 2018

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-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/20180114/346328e7/attachment.html>