Forum Index
 » 
Developer Forums
 » 
Scripting
LUA_LUA_MUIeeeeeh
  • Moderator
    Kronos
    Posts: 2329 from 2003/2/24
    O.k. here is what I've tried sofar:

    - took the source for os.module and replaced all "os" with "test"
    - added "t_" in front of all function-names

    -> compiled without issues

    - copied to "ibs:lua/" (also tried" mossys.libs/lua")

    1st line of script: " require 'test'"

    ->
    Code:
    lua: Work:module_test/test.lua:1: module 'test' not found:
            no field package.preload['test']
            no file '/usr/local/share/lua/5.3/test.lua'
            no file '/usr/local/share/lua/5.3/test/init.lua'
            no file '/usr/local/lib/lua/5.3/test.lua'
            no file '/usr/local/lib/lua/5.3/test/init.lua'
            no file './test.lua'
            no file './test/init.lua'
            no file '/usr/local/lib/lua/5.3/test.so'
            no file '/usr/local/lib/lua/5.3/loadall.so'
            no file './test.so'
    stack traceback:
            [C]: in function 'require'
            Work:module_test/test.lua:1: in main chunk
            [C]: in ?


    Seems that LUA only knows a fixed number of modules listed in "package".

    LUA docs itself want me to either do a .dll (would that work???) or compile my own LUA with my module linked to it (not really an option).

    [ Edited by Kronos 09.11.2019 - 11:15 ]
  • »20.06.19 - 17:46
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    polluks
    Posts: 806 from 2007/10/23
    From: Gelsenkirchen,...
    Hmm, this is the output of Lua not LuaX...
    Pegasos II G4: MorphOS 3.9, Zalman M220W · iMac G5 12,1 17", MorphOS 3.18
    Power Mac G3: OSX 10.3 · PowerBook 5,8: OSX 10.5, MorphOS 3.18
  • »20.06.19 - 18:33
    Profile
  • Moderator
    Kronos
    Posts: 2329 from 2003/2/24
    *facepalm*

    So that actually works.....


    Thats for always starting LUA-scripts from inside a C-App


    *facepalm*
  • »20.06.19 - 18:39
    Profile
  • Moderator
    Kronos
    Posts: 2329 from 2003/2/24
    Preliminary result (ported from AROS not yet 100%)

    LUALUAMUIeeeeeehhhh

    [ Edited by Kronos 12.09.2019 - 14:59 ]
  • »12.09.19 - 12:59
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    polluks
    Posts: 806 from 2007/10/23
    From: Gelsenkirchen,...
    Well done! :-)
    zuluwget.i386-aros.lha works
    ZuluWget.png
    Pegasos II G4: MorphOS 3.9, Zalman M220W · iMac G5 12,1 17", MorphOS 3.18
    Power Mac G3: OSX 10.3 · PowerBook 5,8: OSX 10.5, MorphOS 3.18
  • »15.09.19 - 19:59
    Profile
  • ASiegel
    Posts: 1376 from 2003/2/15
    From: Central Europe
    Very cool!
  • »16.09.19 - 10:17
    Profile
  • MorphOS Developer
    jacadcaps
    Posts: 3111 from 2003/3/5
    From: Canada
    While using MUI from Lua is cool, I'd go for the proper OO approach Lua is capable of. It shouldn't be too hard to allow subclassing with Lua.

    You generally need a BOOPSi dispatcher that will perform a lookup of the MUIM_ value in lua class' metatable to determine whether a method was overloaded or not. You'd have to parse mui.h in order to find which method belongs to which class too, etc. A bit of work but doable.

    This is generally how ObjectiveC MUI was implemented - its code is actually in large parts generated with OO lua that internally has a class corresponding to each supported MUI class.
  • »16.09.19 - 11:32
    Profile Visit Website
  • Moderator
    Kronos
    Posts: 2329 from 2003/2/24
    Lets not go overboard....

    The whole thing started with an attempt to have scripted objects in SteamDraw. These do work in principle but are rather limited without some basic GUI.

    1st thought was to have SteamDraw supply some basic objects (Buttons,Cycles and so on), but then I remembered that Krashan had planned some MUI module way back. So I googled and found nothing, I looked into the CVS wether there might have been something alpha committed before he went 68k, again nada....

    Well, not nada at all as I found your ObjC generating LUA code taking me a moment to figure out what that was all about ;)

    So I thought about doing it myself and came up a few principle designs when some more googling revealed Zulu.....

    Zulu is quite close to what I thought about, so a port seemed the logical choice.

    It is also very small and straightforward to use for anyone with basic MUI experience.

    It does use some basic OO (as in all MUI objects being of one class seen from LUA) and I see no problem expanding it further.

    I also have a parser for mui.h at hand (part of MMamM) which I could adapt to autogenerate the header like LUA scripts.

    Going full in with making a wrapper for MUI (like yours for ObjC) is something I don't plan, cos for the scope of LUA scripts one can either handle writing "classic" MUI-makro-maddness or is better of using a GUI-creator (also part of my project bucketlist).


    ->

    Will see if I can add subclassing and mcc support
    Might add another module for (cyber)graphics, maybe based on amilua (also AROS)
  • »16.09.19 - 16:31
    Profile
  • Moderator
    Kronos
    Posts: 2329 from 2003/2/24
    Been busy over the WE (at AmigaMeeting20 in Neumünster) and got this to share:

    LUA_LUA_MUIeeeeeehhhh02.png

    That fat empty space is an overloaded area class that changes the it's size in the MUIM_AskMinMax method.

    Not 100% satisfied with the current API, so no release right now.

    Also had to do some code to access C-Structs in LUA which will come handy in the "abox.module" I might do next (just for being able to use (Cyber)Graphics function in MUIM_Draw). This would allow LUA to use all OS libraries, excluding anything requiring binary code (hooks, creating filesystems or libraries etc) amd DOS stuff still using BCPL stuff.

    Will provide enough rope to hang yourself, won't come with a prebuild gallow!
  • »21.10.19 - 11:59
    Profile
  • Moderator
    Kronos
    Posts: 2329 from 2003/2/24
    I hope to have the general API figured out so if there are any complaints/suggestions now is the time:

    Code:


    abox = {}
    abox.Types = {{"ULONG",4},{"LONG",4},{"APTR",4},{"STRPTR",4},{"UWORD",2},{"WORD",2}}


    mui.MUI_MinMax =
    {	
    	name = "MUI_MinMax",
    	{"WORD", "MinWidth"},
    	{"WORD", "MinHeight"},
    	{"WORD", "MaxWidth"},
    	{"WORD", "MaxHeight"},
    	{"WORD", "DefWidth"},
    	{"WORD", "DefHeight"}
    }
    mui.MinMax =
    {	
    	{"WORD", "MinWidth"},
    	{"WORD", "MinHeight"},
    	{"WORD", "MaxWidth"},
    	{"WORD", "MaxHeight"},
    	{"WORD", "DefWidth"},
    	{"WORD", "DefHeight"}
    }

    mui.MUIP_AskMinMax =
    { 
    	name = "MUIP_AskMinMax",
    	{"ULONG","MethodID"}, 
    	{"APTR","MinMaxInfo"}
    }


    mui.opSet =
    {
    	name = "opSet",
    	{"ULONG", "MethodID"},
    	{"APTR",  "ops_AttrList"},
    	{"APTR", "ops_GInfo"}
    }

    mui.TagItem = 
    {	
    	name = "TagItem",
    	{"ULONG", "ti_Tag"},
    	{"ULONG", "ti_Data"}
    }

    mui.OM_NEW        = 0x101
    mui.OM_DISPOSE    = 0x102
    mui.OM_SET        = 0x103
    mui.OM_GET        = 0x104
    mui.OM_ADDTAIL    = 0x105
    mui.OM_REMOVE     = 0x106
    mui.OM_NOTIFY     = 0x107
    mui.OM_UPDATE     = 0x108
    mui.OM_ADDMEMBER  = 0x109




    This is how C-structures will look from the LUA side, obviously most of this code would be in a separate (autogenerated) file, but for now it's in my test-script.

    Code:

    function areaamm(cl,obj,msg)
    	muip = struct.new(msg,mui.MUIP_AskMinMax)
    	amm = struct.new(amma,mui.MUI_MinMax)	
    	amm.MinHeight = 100
    	amm.MinWidth = 100
    	amm.DefHeight = 110
    	amm.DefWidth = 150
    	amm.MaxHeight = 500
    	amm.MaxWidth = 500
    	
    end


    The MUIM_AskMinMax method for my class. "cl" is just the C-pointer and of no use as of now, "obj" is the LUA-muiobj (userdata containing the C-pointer), "msg" is again just the C-pointer but I hope to change that before release.

    1st line of code creates a userdata-object of type "struct" pointing to the address of "msg" and being described as MUIP_AskMinMax. This step will be eliminated.
    "amm" is again a userdata object pointing to the MUI_MinMax field in "msg".
    The following lines directly manipulate the values there (at the same address as a C function would do, so no need to write anything back or so). Now proper MUI-code would do "amm.MaxWidth = amm.MaxWidth +500" but it's good enough for now.

    Code:

    area_dis = {{mui.MUIM_AskMinMax,areaamm,mui.PreSuper,areaamm,mui.MUIP_AskMinMax},
    		{mui.OM_SET, areaset,mui.PreSuper,mui.opSet}}


    The dispatcher, as simple as gets, last part not (yet) used (see above). The mui.PreSuper is something that might go away depending on how costly calling "DoSuperMethod()" from LUA might turn out to be.

    Code:

    	a_class = mui.createcostumclass(mui.MUIC_Area,area_dis,area_data)
    	area = mui.new(a_class, mui.MUIA_String_Contents,"bababba" )


    Create a class and object. "area_data" not yet implemented and obviosly no point in sending MUIA_String_Contents to an Area object, but it does work when baseclass is MUIC_String.



    [ Edited by Kronos 09.11.2019 - 11:16 ]
  • »09.11.19 - 10:11
    Profile
  • Moderator
    Kronos
    Posts: 2329 from 2003/2/24
    Fenster01.png

    Doesn't look like much, but this is the 1st sign of life for the abox.module:

    Code:


    function areadraw(cl,obj,msg)
    	rp = area:asset("rp")
    	width = area:asset("mwidth")
    	height = area:asset("mheight")
    	top = area:asset("mtop")
    	left = area:asset("mleft")
    	bottom = area:asset("mbottom")
    	right = area:asset("mright")
    	rp:Move(left,top)
    	rp:Draw(right,bottom)
    end


    Still plenty to do, in the end I expect to have 3 modules:

    mui.module all that was in the AROS version plus support for subclassing
    abox.module some GFX funcztions wrapped around objects (RastPort) plus a generic LibCall later on
    cdata.module access C Structs and Arrays from LUA (the Struct class is part of the mui.module atm)

    I've also written a parser for mui.h and the "muistructs.lua" file is already useable (I'm still using the AROS supplied ones for functions and definitions).

    Edith:
    I've also changed the type of "msg" passed to a method, it is now a "Struct" object as defined in the dispathcer declaration.

    [ Edited by Kronos 30.12.2019 - 18:43 ]
  • »30.12.19 - 17:41
    Profile
  • Moderator
    Kronos
    Posts: 2329 from 2003/2/24
    Oh and big mistake in the code-snip, I used the global "area" instead of the local "obj" passed to the areadraw().

    Changed it, still works ;)
  • »30.12.19 - 17:45
    Profile