Building NEW 'Classic' Controls

[OpenXTalkPaul]

I would suppose the ONLY real difference between a new 'classic' control and a control that has been assembled from a group of other controls is that the former cannot be ungrouped: I am not convinced that is a good thing.

And you'd be entirely wrong about that!
1) How do you 'ungroup' the image data of an icon used on a 'classic button' from the button? You can't. I have written scripts that can, but it's not as simple as you might think it is. As I'm sure you already know, the actual image used as the icon must be stored elsewhere in seperate 'image control'.
2) Do you not see the button's roundRect path and styled font text are pulsing slightly, while separately it's also spinning a rather large 24bit image with alpha channel inside of it? And it's 'non-blocking' while doing all of that. You can click on it and it does things without interrupting the animation. There is simply no way to do this sort of thing with 'classic' button, or even the 'classic image' control.

Moreover, this 'button' could be made to store its icon in a 'text' (or 'imageText'?) property the way a classic 'Image' control can, unlike a 'classic button' which only contains imageIDs for images that are located elsewhere.

It could be made to render the image inside of a compound path so you could have your image clipped inside of a star shape (for example), in fact I have already done that in one of my earlier experiments with widgets and images. See that 'card deal' animation posted earlier in the thread? That image, along with the roundRect 'SVG path' it's being rendered inside of, are being skewed and distorted on the canvas from changing values of a large set of properties I built into that widget. The animation was actually a simple XTscript that was setting the properties on the widget on a timer.

Also as mentioned, unlike 'classic' controls, Widgets are modules and so are external to the Engine. You can do iterative development on them, making small changes without having to recompile the engine(s) on all the platforms and release a new distribution just for people to be able to try a new widget or new version of a widget control. In some respects that makes Widgets somewhere in between creating a composite group of custom control, and editing a classic control in the Engines VC++ source and recompiling.

You can also still group widgets with other controls if you like, I've often done that to use 'SVG icons' widget as icons grouped with a button underneath.

One very real difference is that you reference a 'classic button' as a 'button' (or 'btn' for short) in script, while widget objects are referenced as 'widget' (or 'wgt' for short).

[OpenXTalkPaul]

'Groups' in OXT are somewhat like a 'blank control' basically a transparent rectangle object that has a property which stores references to controls that are to be treated as members within the group. As far as I can tell that really does sum up what their functionality is. Yes, there maybe some other advantages for rendering scrolling content, for using them to set colors and font properties of a whole group of controls at once via the mechanism of inheritance, for applying graphic effects to a bunch of controls simultaneously, but their main use is creating groups of controls and allowing them to be scripting them as if they were a single composite unit.

BTW, I'm pretty sure you can create a new blank generic 'control' using the syntax 'create control "My Control'. Try it out. It will probably display as a gray rect, the same way as if you'd try to 'create EPS "My Postscript Object" which hasn't been functional since MC/RR ran on Unix based OS.

Grouped 'custom controls' are more like Widgets than any of the other 'classic controls' are.
I've imagine you could make a widget that behaved much like a group, moving a list of controls (via its scripting bridge) whenever the Widget control is moved, but I don't know of any way that it would be able to clip (as in a 'bounding' box) its virtual 'contents' if the contents are external to it's bounding rect, the way group controls can. I don't think I'll be spending any time on that specific idea (a New 'Classic' Control 'Group' widget). Widget controls can of course can be used in a Group like any other control.

That's not to say that I am at all against creating custom controls as group controls, I have several custom controls built like that that I keep around.

If we were to do our own take on 'script-widgets' built from 'classic controls' based group objects in a stack, I was thinking it could still use the same packaging/delivery system as Extensions. When you install your script-widget package it simply moves the included stack with your custom control into a 'Custom Control Objects' folder that could be scanned by a tool like @Skid 's custom control palette, and for each custom control stack could have an associated icon and documentation file included which could be displayed in such a palette.

I've imagined having the revObjectLibrary be more like that, currently an Object Library is just a stack, with objects, some descriptive text, and a snapshot being stored on each card of that stack. It could be so much more useful as part of the IDE if that could stay open like a secondary 'Tools' palette, but one that you can drag-drop from and add custom objects/groups to readily.

[OpenXTalkPaul]

Making some progress on Not-Classic Button, it can already be set to look very much like a plain old un-styled (classic) button.

NewBtn0.png (75.35 KiB) Viewed 4355 times

Or could have custom styling like "blue steel" (yes, that is a Zoolander reference)
Note: that the shadow effects are coming from it being inside a group that has shadow effects applied, I haven't added that to the Widget itself yet, but I could make it generate its own shadow / gfx, and allow for optional graphic fx on each element within "New Button" like a separate shadow for the the text label.

NewBtn1.png (301.41 KiB) Viewed 4355 times

Here's button with radial gradients, the first pict is regular, the second is highlighted (reverses the blend)

SatMornLook.png (39.37 KiB) Viewed 4355 times

SatMornLookHilited.png (40.12 KiB) Viewed 4355 times

[richmond62]

AND are you doing that completely inwith OXT or using 'outside methods'?

[OpenXTalkPaul]

AND are you doing that completely inwith OXT or using 'outside methods'?

It's using libSkia which is embedded internally in the Engine, nothing external to the engine is needed ( exception if a specific Font is desired, obviously that needs to be installed for the label to look the same, which is the same as 'classic' button), these are not OS 'Native Layer' controls created via FFI, if that's what you mean.

[OpenXTalkPaul]

I'm intentionally having the pixel icon setting mechanism for this 'button' widget's icon behave a bit different then the classic control 'button' in that for setting its icon you don't use imageID of an image in an 'image' control that is located elsewhere (in an icon library or in a subStack or wherever). Since I'm building this my way, I have it so that the icon can set by a image file or from 'the text' of an image, like an 'image' control' can, cutting out the middle man. 'The text' of an image is it's image data in its original image file format such as PNG or JPG.

This is different than 'classic' button in a couple of respects:
1) It means you set the image in the button widget, that is rather then 'set the icon of button "mybtn" to imageID' you would instead either

Code: Select all

 set the iconImageText of widget 'mybtn' to tImageFileData 

-- or --

Code: Select all

set the iconImageFilepath of widget 'mybtn' to tImageFilePath

The property names are tentative. These property names are not yet set in stone since no one is making use of this currently, I'm open to suggestions, should I just use standard 'the filename' rather than iconImageFilepath? I'm also planning to allow for vector SVG Paths to be used as/or with icons that are pixel based, the very long specific names currently are so I can keep track of which 'Icon' is being handled. I'm also going to have to allow different icons for highlight and hover states too right?
I may also add support for setting the icon image from ImageIDs too, just for the sake of feature parity to 'classic' button.

2) Once an Icon image is set, the widget stores the original filepath AND the image text/data into its property array. This is the same method use to store images that are embedded into stacks in our classic 'image' controls (as opposed to a 'reference controls' that only contains a link to an external file). Everything needed to re-make this 'button' is included in the widgets property data, nice and encapsulated, and the icon image can still be easily exported back to an image format file (png, jpg,etc.), in fact it's easier to do that with an Icon used in 'classic button'

Currently an images used as Icon is automatically rendered scaled to fit a 32x32 pixels rectangle, but I intend to offer precise control of sizing and positioning, along with sensible presets based on standard icon sizes 32x32,64x64,128x128 etc.

Screen Shot 2024-08-27 at 9.38.47 AM.png (77.46 KiB) Viewed 3894 times

[richmond62]

In what way is that actually an advantage over the 'usual way'?
-

Screenshot 2024-08-27 at 17.35.45.png (215.55 KiB) Viewed 3892 times

[OpenXTalkPaul]

In what way is that actually an advantage over the 'usual way'?

Why are those two cropped differently in their outer white space?

You're actually embedding the image into the Widget like you can with an Image Control, versus linking a Button Control to a separate image control by image ID, that may actually have come from an external location on disk, perhaps from a different stack file (like the Icon Libraries that come with the IDE).

Have you ever needed to get the image'text' or filename of an icon from a button control that was pulled in from who knows where (perhaps an IDE theme folder) ? If you have then you know there's a difference, and you'll likely need to use the syntax 'resolve image tImageID' to locate where that image actually came from.

With this you just put the iconImageText from the widget into a file URL and you have an image file png with that image, no resolving imageIDs or file paths involved.
I just tried it out from the message box:

Code: Select all

open file "~/test.png" for binary write; get the iconImageText of widget "Button"; write it to file "~/test.png";close file "~/test.png"

Screen Shot 2024-08-27 at 1.16.46 PM.png (37.35 KiB) Viewed 3885 times

As I mentioned, unlike classic control button, I'm fully in control of the way this new button widget works, without any need for recompiling the engines. I can add 'Icon Gravity' with the additional ability to offset x,y with sub-pixel precision for extremely accurate placement of the image and the text label. And add things like implement vector masking for the image (image inside various shapes), multiple auto image-resize presets, and it could be made to store multiple versions at different resolutions the way Apple's CoreImage/NSImage does (for those extra tiny versions that need manual artistic tweaking). I suppose it could even have layers like Photoshop/GIMP, perhaps a fade-out/in icon switching effect and other cosmetic effects. The point is this opens up many possibilities to do things differently.

[OpenXTalkPaul]

Here's a stack with the 'button widget' module embedded into it as a custom property, which can load then that module before opening the card, then it creates a new instance of that button widget.

This is only the module that getting loaded temporarily (until the end of the IDE session) into memory, meaning the Dictionary and the Property Inspector metadata for the widget is NOT getting loaded. Its a proof of concept for making Demos of a Widget without the Widget being pre-installed.

StackWithEmbeddedModule.oxtstack

(21.03 KiB) Downloaded 59 times

[richmond62]

Because the right-hand one is the source image for the button the left.

[OpenXTalkPaul]

Because the right-hand one is the source image for the button the left.

Exactly, the one on the left can't exist in that state without also including the one on the right. This widget-Button can. Eventually it will be able to move the icon to where ever you like in relation to the bounding round-rectangle, so you could offset the image down a few pixels so guys head isn't just about getting cropped off and the text moved up a few half-pixels so that it sits above those green shadows.

I'd appreciate it if someone would try my stack with embedded Widget module I posted, preferably on another platform and/or with some other build of the IDE. This should work with ANY LC 9.x+ based IDE, but It's a bit hacky. You can't see all of the properties of the widget in Property Inspector when only the byte-code module is loaded this way, because the meta data needed for that is not also being loaded, It is when you load the full .lce extension package for the widget but I'm not doing that here. I've only embedded the byte code module part of it, look at the size of the stack that includes the module, it's all less than 50kb worth of data.

[richmond62]

I'd appreciate it if someone would try my stack with embedded Widget module I posted, preferably on another platform and/or with some other build of the IDE.

Sometimes you have to be careful what you ask for:

OXT Lite 1.07, MacOS 12 . . .
-

Screenshot 2024-08-28 at 17.32.44.png (117.15 KiB) Viewed 3836 times

-
OK, OK, OK . . . after "long and profound thought" I'll load it.

[richmond62]

Richmond is definitely a spoilt kiddo as he wants to be able to do the sort of things he's done with 'normal' buttons
in the lower stack in the screenshot:
-

Screenshot 2024-08-28 at 17.42.09.jpg (168.25 KiB) Viewed 3831 times

-
Maybe that's possible with the widget button, but it was not obvious from its preferences palette.
-

Screenshot 2024-08-28 at 17.45.33.png (290.41 KiB) Viewed 3831 times

-

Code: Select all

on mouseDown pButtonNumber
   if there is a widget "Test" then 
      set the iconImageText of widget "Test" to the text of image 1
   end if
end mouseDown

Aha: but still no GRAVITY.

[richmond62]

Ouch, ouch, ouch:
-

Screenshot 2024-08-28 at 17.50.42.png (375.02 KiB) Viewed 3828 times

-
1. The image should either be imported/set in the button:

1.1. as a scaled and scaleable image (i.e. resize the button and the image resizes), or

1.2. at its original size.

[richmond62]

I'd just as lief use an image as a button:
-

Screenshot 2024-08-28 at 18.04.55.png (126.79 KiB) Viewed 3826 times

[OpenXTalkPaul]

Yes that's all because its a work in progress, IcongGravity has not yet been implemented in this widget (but there's at least one Widget out there I can borrow the code from), currently it just tries to center the combined rect of Icon (left ;gravity') plus the width of text with some margin set.

Also, as I explained, that Demo stack is ONLY LOADING THE BYTECODE MODULE (the .lcm module file), which means it's NOT going to have the IDE niceties of AN ACTUALLY INSTALLED EXTENSION , no METADATA for the Property Inspector is loaded, no Syntax Entries or Guide is added to the dictionary. It's just the bitcode module, just enough to get our custom control into memory so we can use it.

This gets technical...

Like classic controls, widgets are created from 'the templateWidget'. In a Widget's 'OnCreate' handler if you 'put my scriptObject into tMe' you will see it currently thinks 'me' is the templateWidget (rather like being a parent 'class' object in OOP terms), it's not until its 'OnOpen' handler is triggered that it becomes a reference to its own unique new object (an object instance in OOP terms). Which brings me to the caveat to temporarily loading a widget byte code module this way.

All 'Control' Instances are place on a card and rendered into rects. That 'control' instance is actually a combination of the template object's properties PLUS an array of properties for that specific type or kind of control, Properties can effect what is being drawn into the rect. So the way it works with widgets is that when you open a stack file any instances of a widget used in the stack are read into memory so they can be used. The problem is that my script that loads the module is in the stack itself so it's already past the point where it would've scanned for widget instances in the stack. The module gets loaded alright, but it still does not render any instances of the Widget on the card (the objects are there but blank, un-rendered). If you let the module load, then close the stack and immediately re-open it the Widgets are rendered because the module was already loaded when the stack file was being opened. The bottom line to all of this (TL;DR) is that you can get around that by scripting the creation of new Instances of the newly loaded module onto the card, without reopening the stack, which is how my demo stack there does.

I was thinking this could be a good way to quickly distribute test stacks of a widgets that you guys can try out without actually installing anything, and you can use your choice of IDE distro. BTW, this method works great for small Library extension modules since there's not rendering to be done with those modules.

I just tested this myself on Xubuntu on old netbook thing.
Which brings me to another point to this, here's my stack created on Mac BigSur but now on Linux with XFCE:

Screenshot_2024-08-27_11-37-16.png (14.9 KiB) Viewed 3817 times

I changed the defaults textColor for Button controls to be black for label text, it was necessary for macOS to use 'Native Darkmode', because our 'Button' control is NOT a real Apple NSButton object. However, as Tom has mentioned, the Buttons DO behave differently on different platforms, for Linux it correctly inherits the appearance theme's foreGround/BackGround colors, that's not the case for buttons on macOS. Now with that in mind look at Widget-Button, it looks mostly identical to how it looked on macOS (maybe a different Font), that's one of the big advantages in my opinion.

Yes you could make Button look like whatever in GIMP/Photoshop and import it into a Image Control and then add mouseUp/Down handlers and script an image to behave like a button to some degree, I've gone that route plenty, but a Widget can do a bunch more if you code it to, adjusting roundRadius for example, within the confines of the IDE, nothing else needed. And another thing it's not just classic 'Button' that has these hard-coded-into-the-engine issues, there's similar problems of inconsistency in other 'classic' controls, like slider controls which look really weird on with dark XFCE theme, and tab-button-panels look quite a bit different depending on the platform.

[richmond62]

Yes that's all because its a work in progress

Not wishing to be bitchy (which of course means I am about to be bitchy): how l-o-n-g is your MAJOR work-in-progress- going to, supposedly, progress until you release a functional 'thang'?

Please do NOT be like 'the people across the road' who keep promising and then NONE of those promises ever manifest themselves.

Code: Select all

a Widget can do a bunch more if you code it to

Oh, quite: but IFF OXT is to continue being the grandson of HyperCard it should NOT be code-only for fairly basic 'twiddles'.

[OpenXTalkPaul]

1. The image should either be imported/set in the button:

1.1. as a scaled and scaleable image (i.e. resize the button and the image resizes), or

1.2. at its original size.

Why not have ALL of those? I could add an enum prop 'the iconScaling' : 25%, 50%, original, 150%, 32x32px, 64x64,128x128, extra-crispy, etc.

[OpenXTalkPaul]

Yes that's all because its a work in progress

Not wishing to be bitchy (which of course means I am about to be bitchy): how l-o-n-g is your MAJOR work-in-progress- going to, supposedly, progress until you release a functional 'thang'?

Code: Select all

a Widget can do a bunch more if you code it to

I plan to work on one control at a time, releasing each 'new-classic' until I have a complete set.
I don't know how long it will take, as my play time is always too short, but I do already have some very good starting points pre-made from community or myself, for just about a complete set minus 'Player Control' (which is more like a complicated 'Native layer' thing). My slider control works well (horizontal or vertically), but needs more properties implemented. The 'Button' control however may be the most diverse in that it has a lot of different 'styles' to cover (and I just found missing in action 'Oval' style in the classic Button)

It could be much quicker if some more people would learn Builder enough to help me work on them.

But anyway, I may not even wind up doing as complete replacement set, and the 'classic' controls will still be there if you prefer to use those. I would prefer not to have to adjust any graphics depending on the platform appearance it's running on. Also different Linux Window Managers the engine does weird things with 'classic' controls, like on XFCE changes the buttons toggles highlight status on every mouseMove while the mouse is down, even when the screen is locked.

[richmond62]

My MAIN CRITICISM (and, of course there are other ones) of LCB widgets is the lack of 'messaboutability' via prefs palettes compared with 'classic' controls.