Rebuilding The Tools Palette

[OpenXTalkPaul]

So I'm working on yet another rebuild of the Tools palette. This time I'm working more from the bottom up.

I'm not working entirely from scratch, I'm basically devolving the current tools scripts to better understand how it all works currently and then building back up from there.
So...
Each of these IDE library handlers returns an array of object info / properties:
revIDERunEditTools()
revIDEClassicControls()
revIDEWidgets()
revIDEGraphics()
revIDEGraphicTools()
revIDEPaintTools()
revIDEPaintToolControllers()
You can take a peek at the contents of these arrays from the message box like so:
put ArrayToJSON( revIDERunEditTools(), true, true )
But it's much easier to look at if you use the Tree View widget (as used by the property inspector).

So my main goals for this right now are:
1) separate the button/object types into 4 tabs (card).
2) Have the palette be resizable and have the icons reflow their positions to fill the size of the palette.

So I created a test stack, copied the 'classic controls' button group for revTools, embedded the images and relinked the button, wrote scripts to reflow buttons position. After repositioning the stack then snaps to the new rect of the reflowed button grop in a sort of rubber-band effect.

The only problem I'm having is that I can't 'palette this stack', because (and I just now realized this) stacks in palette mode can not be resized! So I either have to have normal sized titlebar/window decorations, OR I could create my own window controller/decorations and hide the sytsem's window decorations.

This makes me start thinking about that 'Window Controller' widget I've imagined that adheres to the window of the stack it's placed on to and automatically hides the OS window decorations. We need something like that for the Emscripten version of the engine anyway (The Emscripten Engine has no OS window manager available, all stacks have no decorations).

Here's an little proof of concept preview of the way I wanted the Tools to work, it's only the classic controls but it's functional as a Tools palette:

Tools Redo 3.oxtstack

(1.38 MiB) Downloaded 5 times

UntitledH.png (72.18 KiB) Viewed 300 times

Untitled.png (72.13 KiB) Viewed 300 times

Untitled 2.png (69.51 KiB) Viewed 300 times

Untitled 3.png (101.95 KiB) Viewed 300 times

[richmond62]

Back to the Future.

I was mucking around with the revTools palette in RunRev 2 when I was in Scotland (about 21 years ago).

No, you cannot resize a palette.

So you 'unpalette' your palette just before you resize it, and then, 'quick as a flash', palettise the thing again.

After all when you set the revTools palette to go from 2 columns to 4 columns wide that must be what happens.

On the silly Android phone: give me a couple of minutes to get upstairs to a computer and I'll fling you some code.

[richmond62]

OK: got a bit distracted, but here we are:
-

Screenshot 2024-04-24 at 22.27.55.png (59.87 KiB) Viewed 287 times

-
note use of

Code: Select all

lockScreen

[OpenXTalkPaul]

Back to the Future.

I was mucking around with the revTools palette in RunRev 2 when I was in Scotland (about 21 years ago).

No, you cannot resize a palette.

So you 'unpalette' your palette just before you resize it, and then, 'quick as a flash', palettise the thing again.

After all when you set the revTools palette to go from 2 columns to 4 columns wide that must be what happens.

On the silly Android phone: give me a couple of minutes to get upstairs to a computer and I'll fling you some code.

Oh yeah, that's another option, thanks for the suggestion / stack.

It would also probably be good to script a little more control over the resizing too, like so that it only changes to sizes that are multiples of the buttons width or heights, and programmatically sets the stacks max width and max heights so the user can't resize the stack to ridiculous large size only for it to snap back to like a 256x512 window.

Maybe add a little animation of transition to the new size if that's not too much more work.

I was also thinking if these were all SVG based images, they would scale much better, then we could allow user to make their tools palette have 'big-buttons' (like those giant TV remotes for old people with failing eye site).

[OpenXTalkPaul]

No, you cannot resize a palette.

Scratch all of that, the documentation is wrong! Palettes stacks can be resizable.
I thought I had done that before and I was right, the revSVGGlyphsBrowser stack is a resizable (in one direction) palette.
The trick is to set the stacks resizable property after setting the stack's 'style' (mode) property to palette.

[richmond62]

the documentation is wrong!

What? Only about that?

Coo: how much isn't either 'wrong', wrong, WRONG, or off in the left field with the armadillos?

The trick is to set the stacks resizable property after setting the stack's 'style' (mode) property to palette.

That's fantastic information: thank you very much.

HOWEVER, I wonder why

Code: Select all

on openStack
   palette "Squeeze"
   set the resizable of stack "Squeeze" to true
end openStack

does NOT palettise the stack.

[richmond62]

Of coure what you described works if it is in the script of a button in the stack, but I have never found a way to
lauch a main stack as a palette.

I set up a button in my stack "Palettise" with this code:

Code: Select all

on mouseUp
   palette "Squeeze"
   set the resizable of stack "Squeeze" to true
end mouseUp

And clicking on that button does what it should.

But this script in the stack:

Code: Select all

on openStack
   send "mouseUp" to btn "Palettise"
end openStack

does not work, nor does:

Code: Select all

on openCard
   send "mouseUp" to btn "Palettise"
end openCard

which seems odd.

[OpenXTalkPaul]

Here's a new version as a resizable palette

Tools Redo 4.oxtstack

(1.38 MiB) Downloaded 3 times

Needs some behavior work, changing the stack height but not width should snap back to previous size since that should not reflow the icon positions.

[OpenXTalkPaul]

HOWEVER, I wonder why

Code: Select all

on openStack
   palette "Squeeze"
   set the resizable of stack "Squeeze" to true
end openStack

does NOT palettise the stack.

shouldn't that line be:
palette stack "Squeeze"
or
palette this stack
or maybe
palette me -- if used in a stack script

Also you can set the stack's style property to "palette", I'm not sure if that can be used to a different effect in some way, other than that is a property while the other is a command that sets that property.

[tperry2x]

the documentation is wrong!

What? Only about that?
Coo: how much isn't either 'wrong', wrong, WRONG, or off in the left field with the armadillos?

Well, I can't get this to work - so I guess that's wrong in the dictionary too?

mergScreenSetBrightness.png (22.7 KiB) Viewed 192 times

[richmond62]

Since when was LC able to muck around with an operating system's settings?

Where did you find this?
-

Screenshot 2024-04-26 at 20.31.28.png (283.57 KiB) Viewed 168 times

-
I cannot find ANY reference to mergeScreenSetBrightness anywhere: looked at the OXT Lite Dictionary, looked at the LC 963 Dictionary, searched the internet.

[tperry2x]

I'll elaborate further later this evening, after my kids are asleep, but this is in the "Quick Dictionary" which is buried in unused dictionaries, but links into the same sql dictionary database as the others.

More on that later...

[richmond62]

Here's a list of all Monte Goulding's mergeEXT externals:

https://livecode.com/merging-with-mergext/

I think you will find that almost all of them are targeted at iOS, and not desktop systems.

There is no mention of mergeScreenSetBrightness.

If that is something contained in one of the externals mentioned I would hazard a guess it is only functional on iOS.

----

Bear in mind several things:

1. It is 2 hours later than Norfolk round these parts.

2. I am 62 and totally shagged out after 9 to 7 at work, so off for what round here counts as an early bed ( 9 pm) and round your parts counts as ludicrous ( 7 pm).

I'll check back tomorrow.

[tperry2x]

Here's a list of all Monte Goulding's mergeEXT externals:
https://livecode.com/merging-with-mergext/
I think you will find that almost all of them are targeted at iOS, and not desktop systems.
There is no mention of mergeScreenSetBrightness.

Yes, this is targeted at iOS, but my point is what if someone is building a stack on their computer for iOS (I stumbled on this as I was looking at iOS support earlier today).

If that is something contained in one of the externals mentioned I would hazard a guess it is only functional on iOS.

It doesn't mention it's only available as part of an external, and I don't have those externals installed either.
However, it should still be able to be typed in a script editor without causing an error - it should be ignored silently if the platform isn't iOS, surely? Or should not be in the dictionary if the mergExt isn't present?

Bear in mind several things:
1. It is 2 hours later than Norfolk round these parts.
2. I am 62 and totally shagged out after 9 to 7 at work, so off for what round here counts as an early bed ( 9 pm) and round your parts counts as ludicrous ( 7 pm).
I'll check back tomorrow.

Yeah, there's no rush. We aren't paying for an instant response from a helpdesk or anything.

I did look into this a bit further. Bear in mind that these screenshots will look a bit alien as you won't have this exact quick dictionary (It's something I've been refining in v1.04 of OXT lite), but it's based on TerryL's one:

--Quick Dictionary v1.4, Terry Little, ©10/2022

First, I wanted to check that it's reading the same sqlite database as the main dictionary does:

check-database-path.png (245.14 KiB) Viewed 154 times

(which it is).

As mentioned, it is indeed an iOS thing - but if I were relying on this developing my stack for iOS, on my computer, I'd at least want it to return something meaningful rather than a script error.

quick-dictionary.png (65.08 KiB) Viewed 154 times

As an aside, if you are wondering why the over-exaggerated orange shaded area (which I'm guessing you are) - this is like Apple's old "Spotlight" shaded menuItem, and is so you can minimise (iconify it of sorts). It tucks itself at the bottom of the revMenubar stack, in the centre of the 'Dictionary' button - wherever that may be.

minimised.png (16.26 KiB) Viewed 150 times

The 'Orange' isn't hard-coded - It uses your tool hilite colour set in the preferences too.

[OpenXTalkPaul]

Or should not be in the dictionary if the mergExt isn't present?

Any .lcdoc file in the Docs build folder is parsed and put into that Dictionary sqlite DB, so if it's there it doesn't neccisarily mean the external should present only means that the .lcdoc file from the external/extension was present when the Dictionary was built.

I thought I removed most of the doc entrees that were only relevant to the Commercial Edition / externals.

[OpenXTalkPaul]

Tools Redo 5.oxtstack

(1.49 MiB) Downloaded 4 times

Representing the weekends work

Just a little progress.
The layout is not set in stone, but currently my idea is this...

There will be four tools buttons in a section at the top:
1) paint: brush/spray/etc. 2) graphics: line/rect/circle/etc. 3) Run-Browse 4) Edit-Move

Then a section bellow that that will contain any tools or related tool-controller things in that category, for example for graphics it will have the line draw tool, the drag-droppable shapes (square, circle, round-rect, polygon, etc.), and polygon-sides selector, round-rect corner radius selector, fore/backColor select swatches, etc. I was thinking the selected tool icon in the tool section at top could change for Paint/Graphic to reflect the Tool that is selected in this second section, for example if you change Tool from Brush to Pencil, it would also update/change the tool icon at the top for Paints tools.

And lastly an omni-present objects section which would contain one continuous list of ALL available placeable objects, both the Classic Objects (first in list), AND any Widgets that are installed.

I see no reason to keep 'classic' objects in a separate list from widget objects, they're all scriptable objects you can add to your stacks, right?

[tperry2x]

I like this, and it's certainly coming along really well.
It takes a long time to unpick everything from the revTools stack doesn't it.

I don't know if you might want to take anything from my fixed version, but you will be more than welcome to use any bits from the v1.04 of OXT Lite when I release that.

I like the approach of holding the alt key to make stacks editable on open. The only thing I'd suggest is this could perhaps be triggered accidentally (I know we have accessibility readers and software on various computers where I work, which utilise the alt-key for pretty much control of opening windows and such). It's probably a very niche case, and won't affect most users / devs in OXT heavy, but what about a preference in OXT heavy that says something like "Upon opening stacks, allow them to be edited while holding the alt key."

I have a small suggestion re this, perhaps set the cantmodify property too:

allow.png (157.47 KiB) Viewed 77 times

But yes, I do like it - great work. Certainly an improvement over the mono tools version. It's a shame the widgets aren't shown in colour. Can OXT/LCC not read colour SVGs at all? I thought TerryL revised the drawing library to allow that?

I see no reason to keep 'classic' objects in a separate list from widget objects, they're all scriptable objects you can add to your stacks, right?

I don't know to be honest - I mean, the dictionary and such makes a clear distinction between 'classic controls' and 'widgets' but they are all essentially 'tools'. I think if we put them together in the palette without any distinction, we could just simply refer to them as what they are: 'tools' and the objects they create as 'instances' perhaps?
But then everything else, including the inspector, the application browser/project browser, documentation and other bits would also probably need redoing to update the name.

[OpenXTalkPaul]

I like the approach of holding the alt key to make stacks editable on open. The only thing I'd suggest is this could perhaps be triggered accidentally (I know we have accessibility readers and software on various computers where I work, which utilise the alt-key for pretty much control of opening windows and such). It's probably a very niche case, and won't affect most users / devs in OXT heavy, but what about a preference in OXT heavy that says something like "Upon opening stacks, allow them to be edited while holding the alt key."

I have a small suggestion re this, perhaps set the cantmodify property too:

Yes, definitely, it's annoying because that keeps going back to palette mode on its own, I think I had can't modify toggling and in the "Start Center" and that SVG Glyphs palette. Ultimately I only put it there for my/our convenience for working on a palettes, and not really meant for end user.

It's a shame the widgets aren't shown in colour. Can OXT/LCC not read colour SVGs at all? I thought TerryL revised the drawing library to allow that?

I'm not familiar with any mods Terry has made to the drawing library, but I certainly would be interested in looking at it.

LCC / OXT has had color SVG support integrated into the Image 'classic' control since v9.0 (I think ?, whenever that drawing library was added).
Before that was added there was a community made Color SVG widget made that worked in v8. I think that widget version should be added back in too because you can use regular SVG XML tags with that (not just "d=" path strings), where as the drawing library 'compiles; SVG into some sort of ready-to-render binary format that I no of no way to de-compile back to SVG.

The Image control's SVG support, it could be either Cairo or Skia that renders SVG into the image control, both libraries support SVG, so I'm not sure which does the rendering in that context.

Important to note that the SVG specification is not 100% supported, for example text tags are not rendered, so you have to "create outlines" to turn your text into a path string instead.

[OpenXTalkPaul]

I don't know to be honest - I mean, the dictionary and such makes a clear distinction between 'classic controls' and 'widgets' but they are all essentially 'tools'. I think if we put them together in the palette without any distinction, we could just simply refer to them as what they are: 'tools' and the objects they create as 'instances' perhaps?
But then everything else, including the inspector, the application browser/project browser, documentation and other bits would also probably need redoing to update the name.

I tend to think of any of the revTools palette items that invoke the grab cursor and are placed onto a card (vs. being drawn or painted or being a selection tool) and that the engine can reference with the keyword 'control(s)' or the synonym 'part' (which was HyperCard's ambiguous keyword for referencing them) as 'script 'objects'. Incidentally 'scriptObject' is how they're referred to in Extension Builder lang as far as the variable data type.

The graphics objects currently in the Tools palette are placed as objects, you drag-drop place them, but they could, and maybe should, act like 'tools', like their paint tools equivalent, to be live-rendered while mouse is still down and redraw-updating of the object, sizing in realtime to the users liking. The 'line' tool creates graphic object 'lines' in this "draw-to-place" manner ( the 'tool' way). I'd like to implement that same behavior for circles, round-rects, etc. too. and maybe add an additional shape or two.

I wasn't planning to intermingle 'classic' and widget objects, the classics will come first and then the widgets, which is the opposite of the way it is in revTools, but I wasn't planning to insert a divider line either.

Another option I considered was a toggle button, which would switch between exclusively 'classic' controls, and exclusively widget controls. That matches up to a goal of eventually including a set of substitutes for many of the classic controls (custom check boxes, slider, progressbar, etc.). I was also thinking of using a scrolling list in a group for widgets list, since you could potentially have 1000 widgets ("by CHRISTMAS!!!" )

I don't think much of anything in the dictionary would need to be changed for any of this? The 'revTools' palette has evolved several times before. I mean I'm mostly just rearranging the layout and hopefully fixing a few problems while I'm at it.

[OpenXTalkPaul]

"Officially" though, 'The tool' function returns one of the following tool names:
browse, pointer, button, field, scrollbar, graphic, image, player, select, pencil, bucket, brush, eraser, spray can, rectangle, line, round rect, oval, polygon, curve, regular polygon, dropper
...followed by the word "tool"
Note: as you said, widgets are basically the only items in revTools not listed as a 'tool'.
The glossary definition of 'Tool' says this:

A mode that lets you perform specific actions (such as selecting objects or drawing lines) when you click in a stack window.
Also, the icon (in a palette of tools) you click to select a tool.

Looking up 'control' keyword:

Use the control keyword in an object reference.
A control is any object that can be placed on a card: a button, field, scrollbar, image, graphic, player, EPS object, or group.

Note: 'control' entree also has no mention of widgets at all, even though they can be referenced as 'control' (or 'part')
A quick test with one widget on a card:
put the name of control 1 of the topstack -- or put the name of part 1 of the topstack
puts: widget "SVG Icon"
put the kind of part 1 of the topstack
puts: com.livecode.widget.svgpath

If we had started from scratch I would've argued that the 'tools' are:
browse, pointer, pencil, bucket, brush, line, eraser, spray can, select, dropper, and the geometric shapes
(and Hypercard had a bitmap-text paint tool too) ...while the rest are controls/parts/scriptObjects.

I just now realized that the 'line tool', which is the pixel-paint version of the line drawing, is completely missing from the revTools palette. There is presently only the graphic object version of a 'line tool'.
You can invoke the missing tool from the message box:
set the tool to "line tool"