From 7b4509468d782f857c3132f8f883188cec2519af Mon Sep 17 00:00:00 2001 From: David Walter Seikel Date: Thu, 3 Apr 2014 05:26:47 +1000 Subject: More Widget and Squeal ramblings. --- ClientHamr/GuiLua/skang.lua | 53 +++++++++++++++++++++++---------------------- 1 file changed, 27 insertions(+), 26 deletions(-) (limited to 'ClientHamr/GuiLua') diff --git a/ClientHamr/GuiLua/skang.lua b/ClientHamr/GuiLua/skang.lua index d20d122..67df94b 100644 --- a/ClientHamr/GuiLua/skang.lua +++ b/ClientHamr/GuiLua/skang.lua @@ -883,7 +883,7 @@ client. Mostly it all happenes automatically through the ACLs. Bouncer is the Java skang security manager, it extended the Java SecurityManager. Lua has no such thing, though C code running stuff in a sandbox does a similar job. Fascist is the Java security supervisor, -again should go inot the C sandbox. +again should go into the C sandbox. Human is used for authenticating a human, Puter for authenticating a computer, Suits for corporate style authentication, and they all @@ -926,7 +926,7 @@ access to the module. --[[ TODO - NOTE that skang.thing{} doesn't care what other names you pass in, they all get assigned to the thing. + NOTE that skang.thingasm{} doesn't care what other names you pass in, they all get assigned to the Thing. Widget - @@ -934,7 +934,7 @@ access to the module. of creating widgets via introspection. Should also allow access to widget internals via table access. Lua code could look like this - - foo = widget.label(0, "0.1", 0.5, 0, 'Text goes here :") + foo = widget('label', 0, "0.1", 0.5, 0, 'Text goes here :") -- Method style. foo:colour(255, 255, 255, 0, 0, 100, 255, 0) foo:hide() @@ -945,23 +945,14 @@ access to the module. foo.look('some/edje/file/somewhere.edj') foo.help = 'This is a widget for labelling some foo.' - For widgets with "rows", which was handled by Stuff in skang, we could - maybe use the Lua concat operator via metatable. I think that works by - having the widget (a table) on one side of the concat or the other, and - the metatable function gets passed left and right sides, then must - return the result. Needs some experimentation, but this might look like - this - - - this.bar = this.bar .. 'new choice' - this.bar = 'new first choice' .. this.bar - - Widgets get a type as well, which would be label, button, edit, grid, etc. - A grid could even have sub types - grid,number,string,button,date. B-) + A grid could even have sub types - grid,number,string,button,date. A required widget might mean that the window HAS to have one. Default for a widget could be the default creation arguments - '"Press me", 1, 1, 10, 50'. - skang.thing('foo,s,fooAlias', 'Foo is a bar, not the drinking type.', function () print('foo') end, '', '"button", "The foo :"' 1, 1, 10, 50') + skang.thingasm{'myButton', types='Button', rectangle={1, 1, 10, 50}, title='Press me', ...} + + skang.thingasm('foo,s,fooAlias', 'Foo is a bar, not the drinking type.', function () print('foo') end, '', '"button", "The foo :"' 1, 1, 10, 50') myButton = skang.widget('foo') -- Gets the default widget creation arguments. myButton:colour(1, 2, 3, 4) -- Use generic positional / named arguments for widget to, then we can do - @@ -975,7 +966,18 @@ access to the module. quitter = skang.widget(nil, 'button', 'Quit', 0.5, 0.5, 0.5, 0.5) quitter:action('quit') - coordinates and sizes + For widgets with "rows", which was handled by Stuff in skang, we could + maybe use the Lua concat operator via metatable. I think that works by + having the widget (a table) on one side of the concat or the other, and + the metatable function gets passed left and right sides, then must + return the result. Needs some experimentation, but it might look like + this - + + this.bar = this.bar .. 'new choice' + this.bar = 'new first choice' .. this.bar + + + coordinates and sizes - Originally skang differentiated between pixels and character cells, using plain integers to represent pixels, and _123 to represent @@ -1000,8 +1002,8 @@ access to the module. Another idea for relative numbers could be to have a coord object with various methods, so we could have something like - - widget:bottom(-10):right(5) -- 10 pixels below the bottom of widget, 5 pixels to the right of the right edge of widget. - widget:width("12") -- 12 characters longer than the width of widget. + button:bottom(-10):right(5) -- 10 pixels below the bottom of button, 5 pixels to the right of the right edge of button. + button:width("12") -- 12 characters longer than the width of button. Squeal - @@ -1010,26 +1012,25 @@ access to the module. database stuff for now, but should keep it in mind. For SquealStuff, the metadata would be read from the SQL database automatically. - squeal.database('db', 'host', 'someDb', 'user', 'password') -> Should return a module. + squeal.database('db', 'host', 'someDb', 'user', 'password') -> Should return a Squeal Thing. local db = require 'someDbThing' -> Same as above, only the database details are encodode in the someDbThing source, OR come from someDbThing.properties. db:getTable('stuff', 'someTable') -> Grabs the metadata, but not the rows. db:read('stuff', 'select * from someTable'} -> Fills stuff up with several rows, including setting up the metadata for the columns. - stuff[1].field1 -> Is a Thing, with a stuff in the stuff metatable, that was created automatically from the database meta data. + stuff[1].field1 -> Is a Thing, with a proper metatable, that was created automatically from the database meta data. stuff:read('someIndex') -> Grabs a single row that has the key 'someIndex', or perhaps multiple rows since this might have SQL under it. stuff = db:read('stuff', 'select * from someTable where key='someIndex') stuff:write() -> Write all rows to the database table. stuff:write(1) -> Write one row to the database table. - stuff:stuff('field1').isValid = someFunction -- Should work, all stuff[key] shares the same stuff. - stuff:isValid(db) -> Validate the entire stuff against it's metadata at least. - window.stuff = stuff -> Window gets stuff as it's default stuff, any widgets with same names as the table fields get linked. + stuff:stuff('field1').isValid = someFunction -- Should work, all stuff[key] share the same Thing description. + stuff:isValid(db) -> Validate the entire Thing against it's metadata at least. + window.stuff = stuff -> Window gets stuff as it's default 'Keyed' table, any widgets with same names as the table fields get linked. grid.stuff = stuff -> Replace contents of this grid widget with data from all the rows in stuff. choice.stuff = stuff -> As in grid, but only using the keys. widget.stuff = stuff:stuff('field1') -> This widget gets a particular stufflet. widget would have to look up getmetatable(window.stuff).parent. Or maybe this should work some other way? - In all these cases above, stuff is a table that has a Thing metatable, so it has stuff. - It is also a Stuff. + In all these cases above, stuff is a 'Keyed' table that has a Thing metatable, so it has sub Things. Should include some way of specifyings details like key name, where string, etc. getmetatable(stuff).__keyName getmetatable(stuff).__squeal.where -- cgit v1.1