A simple WTK you can use for editors and such. Code and documentation here. The version there is probably newer than the one in this demo cart.
Mouse interaction only, except for text fields.
Wow, would be very useful for my debugging tools.
I'll try to integrate it in my picotool/p8tool workflow. I'll probably fork the code.
UPDATE: done! https://github.com/hsandt/PICO8-WTK/tree/p8tool
Instead of global variables, functions and tables are local, and only the most important ones are exported.
Now you can download a copy of the repo or add it as a submodule to your project, and require("wtk/pico8wtk") then build your project with p8tool.
Note that the master branch of my fork is the same as the original, only the p8tool branch adds export.
(you can also use the original script and directly use the global vars, but symbols like "label" will be set as global variables, so you should avoid using them)
Oh, neat. Sorry, I didn't even notice that before. I finished the game I was making and started a new one, so I've been working on this again. Probably gave you a fair bit more work to do.
There's still a bit more I want to do. I've got a text field widget almost done, and I'd like to rework spinners a bit so they can be used as simple text lists. That would mainly entail setting a function or table to convert numbers to strings.
Beyond that, I was thinking of redoing constructors. The current method of just passing a few arguments to the function is a bit inconsistent and doesn't extend well. I don't know if there's a standard way of doing this sort of thing in Lua, but I was thinking of passing in a table of settings, like:
local btn=button.new{
x=4,
y=16,
label="a button",
on_click=do_whatever,
color=11
}
|
Or I could go even further and make something similar to QML:
local p=panel{
x=8,
y=8,
checkbox{
x=2,
y=2,
name="cb1",
label="some setting"
},
checkbox{
x=2,
y=8,
name="cb2",
label="another setting"
}
}
|
Of course, anything like that would break backward compatibility. I don't know if anyone cares about that or not.
I'd like to rename some stuff, too. This was the first thing I ever did in P8, and I misjudged how big an issue the character limit would be, which is why there are several single-letter variable names. Knowing better now, I'd like to change those. Again, compatibility, probably no one cares. If anyone does, let me know.
Nice, but ... does it work with touch-screen ? I, like you, was intrigued by the possibility of writing carts that would only accept the mouse.
Yet, touch-screen technology seems to be different than a mouse - does it work in your program ?
Don't know. If P8 processes mouse and touchscreen events the same way, it should work. I don't think it does, but I don't have one to test with.
Interesting... For the text field, you want to add a virtual keyboard or an up/down letter selection? (as on arcade games' high-score screen, for the "ENTER YOUR NAME" input)
I understand your approach for the new constructors. A declarative-style syntax would be useful to build predetermined widgets quickly. I mostly create widgets dynamically though, so I wouldn't use it too much but for the basic properties.
Passing a table gives more flexibility in argument order anyway, you can skip some and add an optional one without passing "nil, nil, nil, my_option". If you make this consistent and more convenient everywhere, I don't mind losing retro-compatibility. But I'll have to be more explicit on all my constructions (not that I care about token count anymore... I've already exploded it, but somewhat it's ok for me because I strip all debug widgets for game release; it may be more of an issue for other devs, though).
Actual keyboard input for the text field. Those are done now, as well as the arbitrary text display for spinners. Haven't done anything with constructors yet, but I'll probably get to that sometime soonish. Should probably update the demo after that.
Oh, using the mouse devkit for keyboard input too, I see. I was wondering how to have custom input if not exporting a browser version + bridging JS.
I have peeked into the code but I haven't tested the text field yet. I'll probably integrate it when I make a level editor (so the user can name levels).
Hi again!
I noticed the make_label (now _wtk_make_label) used in checkbox.new does not support all usual label properties, color in particular. My checkbox label defaults to black and it's hard to read on a dark background. Apparently the argument is simple so you can check if it's a function, an icon, etc. But maybe by checking if it's a table or not, it would also be possible to support the generic label properties?
Also, do you want to make a new demo cartridge demonstrating the new features?
I have a demo app for my own WIP framework (https://github.com/hsandt/pico-boots-demo) which uses PICO8-WTK, but it's meant to demonstrate the features of the framework itself, so not all the features of WTK may be shown.
clicked in the enter text field and hit backspace, exited the program entirely and loaded previous webpage.
... ???
Looks like it's not your fault. Something the @zep needs to fix. You can't hit BACKSPACE inside a cart, at least for Firefox as it exits the cart and loads the previous internet page.
Yep, but it needs to go further than that. It should also not be possible to send the backspace key to the browser even if you are NOT reading the key at the time - so it could be buffered in.
This changes things with my calculator project. I'll add the "," key as an additional option to backspace.
The demo's been updated, though I forgot to take a new screenshot.
If the label argument is a table, it assumes it's already a widget, i.e. that you've given it label=label.new{...} or some such. I could add a metatable check to verify that and create a label if not, but I wonder if it's worth the tokens.
I could also add some global config options, e.g. label.default_color. I don't know if that would be a problem with your modifications, though.
Another thing I was thinking of doing is splitting up the file so individual widgets could be #included or not. Seems simpler than figuring out which parts you can delete safely.
OK, I'll try making my own label then.
I also noticed that panels don't support transparent background. Could we use a special color -1 or 16 to indicate we don't want to draw the background of a panel? In this case i only use the panel to make elements draggable.
Sure. I made it a style; use style=panel.trans (or style=0), and it'll be invisible.
[Please log in to post a comment]
