A Windows utility

@Jmv38 very cool!

@jmv38 Thank you. Now it is I have been able to start your examples

Just added a version with streetView.

Too bad google limits the access to street view to 1000/hour (and maybe less)… After playing a while, they stopped send me the images. You’ll experience this too i guess.
Edit: my 17 year old son just taught me how to solve it: off/on the internet box changes the ip adress => bingo! Streeview works again.

Amazing Jmv38 !

Street view is a nice addition! Didn’t think of that!

[jaw drops]

.@ignatz thanks. (that was the expected effect :)) :smiley: )

Adding functionnalities and reworking, i will change the root name of classes and tabs and images saved to a common root that will not be a problem with your own names. The rules should be:

  • short name.
  • a name that you is not likely to be used in your programs for other purposes.
    So i thought of:
    1/ “WTK” meaning “Windows Tool Kit”.
    2/ “JMV38” meaning “My Ego Is Bigger Than Your Ipad”. :wink:
    3/ “TK” meaning “tool kit”. A short one, but maybe not specific enough?
    4/ “CTK” meaning “Codea Tool Kit”.
    5/ “WFC” windows for codea.
    Any suggestion? What would you vote for?

ok, i’ll follow the vast majority of voters after this hot and interesting debate, and will go for “WFC”. Starting with a W is good because this stuff will stick at the end of the list. For those of you interested, my next step will be to make the library very easy to integrate into any project. At the first release i had not really used it from the ouside, and, although the library works, the integration process is at least uneasy, and surely doesnt fit in the “codea spirit”.
I’ ll also have a look at Cider2 library just published by @Aciolino, to check if there is some commonality between the 2 libraries. If the overlap is too big, and the performances equivalent, i might just stop this project. Cheers.

just had a look a Cider2 short video. Actually, the spirit of Cider2 is a bit different from the one i follow: Cider2 helps to built an interface with careful design of where the objects are placed, which is very good. I am targetting more at having the fastest possible way to build an interface: just by printing things (text, image, buttons) into a container (windows) without having to worry about where they are placed exactly, but being satifyied of the final result, thanks to a few simple presets (alignment, columns). This gives less control on the output, but more time to concentrate on other aspects of the app.

Also I have taken great care to have high FPS and no memory crashes, which led me to an architecture choice based on spriting pre-drawn images, different from Cider1 (drawing all details each time), and Cider2 (meshes? tbc. I avoided meshes with scroll bars, that can create too big texture images and then lead to memory crash). Spriting pre-drawn images is much faster than drawing it all each time, but takes more memory.
But not as much as meshes, and the performance is only a little less, because there are not so many images to sprite, and they are small. Meshes dont take memory per se, but when you want to make a window with a mesh, you must allocate the memory for a texture of the window size (also for the empty regions). And maybe 2xmore if you want it to be scrollable. This is a problem on my iPad1.
In my library, only the window bar and frame (the decoration) is made from a mesh, which enable the texture to be very small but can be extended on the screen to any size without FPS or memory cost.

So there might be some room for the 2 libraries, because they have different goals and use different technical compromises.

@Jvm38, I agree with your thoughts on the underlying architectures of all three projects, they are all different…my main goal for Cider2 was screen based control, layout and data editing, targeting business-like features. Definitely not going after fast and lean; more like ‘business-driven’ prototyping.

One of the cool things I saw in Cider1 was drag and drop, which was, to me, the primary use. I just finished that in Cider2 along with persistence, so that a person can design a screen and reuse it without doing any code, then load that later, once again without code. Once the implementation of the controls is needed, a single module gets edited to perform those functions (currently called UDF).

Your goals are very different, but if there’s anything useful, please let me know!

Thank you for your comment. Sure i’ll let you know if i can hack something from Cider2! I dont want to re-invent the wheel…

@Jmv38… I’ve been playing with your Windows builder and it is… Awesome!! I especially like the stand-alone version (because it doesn’t have the tutorial popping up). I only have one question:

Is there a way to ‘fix’ the order that the windows are displayed from back to front? For instance, you have a ‘Big_Image’ window and then you put your ‘Direction’ buttons on top (which is in its own window). If I long-press the Big_Image window (to adjust its parameters, it becomes the front window and covers the Direction buttons. From that point, I can’t access the Direction button’s window to bring it to the front without moving the Big_Image window out of the way.

Therefore, I have a problem resizing the Big_Image window to fill the screen while still placing the direction buttons on top of it. The only way I found to do it is to resize the big window and then go into the editor and cut and paste the Direction window’s parameters to a spot below the Big_Image window’s parameters.

Maybe you could add a button that would allow us to cycle through the windows–in case one gets hidden. But I’d also like the option to keep a window (such as a background image) always at the back and another window (such as control buttons) always on top.

Thanks for the positive feedback. Concerning windows order, I agree, i had the same problem. I will implement a z-level that can be set from the settings. This should fix it.

z-order is great, until you have to handle modals :slight_smile:

.@aciolino what do you mean?

Modal dialogs vs non modal dialogs are tricky because modals don’t play nicely when it comes to touch - they steal all touches by design. It’s … Interesting.

It’s interesting to look at different takes on UI’s. It would not be a problem if there was several different to choose from. I’ve made some different versions as well, first tried with one that was quite similar to QML, but the propagation of values made it a bit too slow. But you could write relations between the UI elements, which made it quite convenient, like “prev.right” to align to the sibling element, or “parent.w” to refer to the width of the parent.

scene = UI.Item({},
        UI.Rect({w="200", x="b2.x",y="b1.y/2",
                 color=color(100, 183, 91, 255)},
            UI.Image({image="Planet Cute:Character Boy",
        Button({id="b1", text="Up", y=100, x=10}),
        Button({id="b2", text="Right", x="prev.right", y="prev.y"}),
        Button({id="b3", text="Reset", x="b1.x", y="b1.top"})
local h = scene:id("b1")
h.onClicked = function ()
    tween(.2, h, {y=200+h.y})

Now I’ve removed some of that magic in UI code to make my UI faster. :slight_smile:

What you could do \to keep it fast is to assign a parent variable, and then change your x=“prev.right” code to x=self.parent.right (no quotes). Similar concept and less manipulation/processing to get to the source value. Now, in your example of b1.top, you’d have to have an instance of b1 before the assignment, and I think that’s where your QML processing was helpful.

I’m doing something similar to your scene example, except that I serialize it as JSON to load/save, as I didn’t have a framework like QML as a parameter.