Known Bugs

[OpenXTalkPaul]

Nice! I love discovering stuff like that that's undocumented (or became lost to history as with the 'EPS control').

BTW, since we're on the subject of Property Inspector, the graphics effects editor has bug where the stack popup with the sliders that control the effects get all discombobulated after editing the FX settings and then reopening that editor stack again, until you click OK to close again and then reopen that pop-up stack which then displays the sliders normally again. I haven't investigated this properly yet, but I'm guessing probably something like not updating some custom property which effects that stack's layout in certain situations.

Are you supporting Widgets with your new Property Inspector?

[tperry2x]

Yes, I'd noticed that. It also really ramps up the cpu use like crazy when doing that.

I'm recreating it, so I'm sure I can work that out near the time. In fact, I did already make a stack that can do all the effects and drop shadows and stuff, without the high cpu use. I'll have to dig that out.

The reason I'm recreating the inspector is to:

• unpick the ide and it's ties to the inspector

• Simplifying it, and deobfusicating it

• Making it faster and more efficient

• Bug fixing (as there are quite a few)

• Prevent the 'window focus juggling' once and for all on all linuxes

• Squash the 'sliding effect' it displays occasionally.

...but it's early days. It's why I wanted to get v1.04 released before I started making sweeping changes to the core of the IDE. As you've very rightly mentioned before, it's so interwoven that this is bound to break a lot - so better to do that on a new point release I was thinking.

I'd love to support widgets - you mean for things the user might add, like the rotate text widget - something like that?

The inevitable question I would have would be how to support things like that.
I'm thinking of an addons / widget tab in my inspector that I could use to add widget support. I assume you are thinking about the built-in widgets and being able to support those initially, which I think it should do.
That tab (or at least the controls in the group on that card) are going to have to be fully dynamic I'm guessing, whereas the classic controls are easier as their properties which can be set are always the same.

[OpenXTalkPaul]

I'd love to support widgets - you mean for things the user might add, like the rotate text widget - something like that?

The inevitable question I would have would be how to support things like that.

Yes, I mean like extension builder module widgets.

I'm working on newTools so I'm having too support them on the IDE object list/control level too.
They are just like the classic controls except that unlike classic controls they all have the same "widget" type property but have the additional property of 'kind' which returns the module's reverse-DNS identifier (org.openxtalk.widget.piano for ex.), so there is one extra layer identifying what sort of object/part/control the selectedControl or 'the target' is.
revIDEWidgets() returns an array containing everything about all of the loaded Widget extensions, the properties exposed, and it includes what property inspector editor to use for each property (text,integer, boolean, etc.).
To get the properties that are set on 'the selectedObject' if it's a widget type, you can use:
export widget "SVG Icon" to array tArray -- which contains it's 'kind' and its set properties, and also it's 'state' which is like the widget equivalent of getting 'the properties' for classic controls.
Here's a demo using the SVG Icon Widget:

WidgetInfos.oxtstack

(104.28 KiB) Downloaded 7 times

[OpenXTalkPaul]

I just found a better (in that it's already part of the IDE) method in the revIDE library handlers for getting the widgets props list:
revIDEExtensionProperties takes a Widget rDNS ID 'kind' and returns an array for the kind's available properties.
Example:

Code: Select all

put the keys of (revIDEExtensionProperties("com.livecode.widget.treeView"))

Also for getting the available handlers in an extension module (Widgets or Libraries) which is what is contained in those .lci 'interface' files I found this snippet posted by Mark Wieder, UNTESTED:

Here's how I'm getting the handlers currently:

Code: Select all

/**
* find the extension interfaces folder
*/
private function modulesLocation
   return specialfolderpath("engine") & "/Toolchain/modules/lci/"
end modulesLocation

/**
* given a module name
* return a list of its public handlers
*/
function widgetAvailableHandlersOfModule pModule
   local tFile
   local tContents
   
   put modulesLocation() & "com.livecode." & pModule & ".lci" into tFile
   put url ("file:" & tFile) into tContents
   filter tContents with "*handler*"
   return tContents
end widgetAvailableHandlersOfModule

because note that revIDEspecialFolderpath("engine") returns nothing on linux.

mwieder
VIP Livecode Opensource Backer

For reading/editig a widget's 'defaultScripts' file I found this snippet from HH (R.I.P):

put "/Users/admin/Documents/My OpenXTalk/Extensions/community.livecode.hermann.graphicswidget.1.0.0" into tFolder
put revIDEExtensionFetchDefaultScript(tFolder)

So we can edit tFolder/support/defaultscript.livecodescript with a texteditor and revIDEExtensionFetchDefaultScript(tFolder) loads it.

[tperry2x]

That is great information, and I'll squirrel that away for future use. It will definitely be handy and I'll likely make some example stacks based on it - I have a few ideas of stuff I can add in the stack examples using some of this.

However, here's where I've probably made life harder for myself.
I'm scripting my new properties inspector to not only work with OXT Lite / OXT, but I also want it to work with my IDE (tIDE) where there is no revIDE stack, so I can't use revIDEExtensionProperties.

Not being deliberately difficult, but my version has to have no dependencies on the revIDE stack (because there's isn't a rev*[anything] stack, or an [anything].livecode stack either)

So a lot of it I'm having to write my own, but it's educational at the very least, and it does mean that I'm also able to unpick the IDE at the same time. Plus, I also find running through the revIDE stack quite a slow method because it has to traverse that function, pass the variables into the handler for each prop, look up the reverse identifier, read the file to see if it has that property, evaluate to see if the property can be set, read the status of the property, return it, send it back through the handler, then relay it to the inspector... That's a very round-the-houses method of checking if a property is set.

I'm also not entirely convinced if this jumping between various stacks, frontscripts and backscripts, is causing some of the window-palette-juggling I see on Linux.

Essentially I'm using a custom function to check the properties applied to the selected object, then return them directly to my inspector. This way I'm using about 3 steps instead of about 9.
It doesn't sound like a huge difference, but it results in a lightning-fast inspector which doesn't inter-link into any other stacks. It also doesn't depend on any reverse identifiers as it cycles through the selected object's properties. Example of button inspect function:

Code: Select all

function checkProp tBtn,tStack,tProp,tPropObj
   if there is a btn id tBtn of stack tStack then
      if tProp is "" then exit checkProp
      put the tProp of btn id tBtn of stack tStack into tIsTF
      if there is a btn tPropObj of cd 1 of this stack then enable btn tPropObj of cd 1 of this stack
      return tIsTF
   end if
end checkProp

*card 1 of this stack is tab 1 of the inspector
The tabs won't change, so this should be okay. This is probably for my own amusement, but I'm coding this to also work on my zig-compiled engine where there are no such thing as reverse-identifiers. (I'm not using that property identifier method at all. It's all pulled from the engine directly, which is faster, as it's all embedded in there already - I just reference it through xTalk script directly.)

[OpenXTalkPaul]

That is great information, and I'll squirrel that away for future use. It will definitely be handy and I'll likely make some example stacks based on it - I have a few ideas of stuff I can add in the stack examples using some of this.

However, here's where I've probably made life harder for myself.
I'm scripting my new properties inspector to not only work with OXT Lite / OXT, but I also want it to work with my IDE (tIDE) where there is no revIDE stack, so I can't use revIDEExtensionProperties.

Not being deliberately difficult, but my version has to have no dependencies on the revIDE stack (because there's isn't a rev*[anything] stack, or an [anything].livecode stack either)

So a lot of it I'm having to write my own, but it's educational at the very least, and it does mean that I'm also able to unpick the IDE at the same time. Plus, I also find running through the revIDE stack quite a slow method because it has to traverse that function, pass the variables into the handler for each prop, look up the reverse identifier, read the file to see if it has that property, evaluate to see if the property can be set, read the status of the property, return it, send it back through the handler, then relay it to the inspector... That's a very round-the-houses method of checking if a property is set.

I'm also not entirely convinced if this jumping between various stacks, frontscripts and backscripts, is causing some of the window-palette-juggling I see on Linux.

Essentially I'm using a custom function to check the properties applied to the selected object, then return them directly to my inspector. This way I'm using about 3 steps instead of about 9.
It doesn't sound like a huge difference, but it results in a lightning-fast inspector which doesn't inter-link into any other stacks. It also doesn't depend on any reverse identifiers as it cycles through the selected object's properties. Example of button inspect function:

*card 1 of this stack is tab 1 of the inspector
The tabs won't change, so this should be okay. This is probably for my own amusement, but I'm coding this to also work on my zig-compiled engine where there are no such thing as reverse-identifiers. (I'm not using that property identifier method at all. It's all pulled from the engine directly, which is faster, as it's all embedded in there already - I just reference it through xTalk script directly.)

I'm all for making things as snappy as possible, and we certainly don't need to stick with the systems as they were handed to us...
You could copy any relevant handlers from the revIDE stack into your PI stack and then modify to your liking. Or you could write your own handlesr that do the same sorts of things (the Widget handlers just read those small .lci file that every extension generates and adds to the IDE when it's loaded/installed).

But since the revIDE library (along with all of the other IDE libraries) is loaded into memory at IDE startup I can't see that significantly taking any more time than having it in the same stack or a sub-stack of the same stack. It seems fast enough for me to retrieve the list of applicable properties for a selected Widget. The 'classic controls' properties are all stored in tab-delimited plain text files which are files that the IDE has to read on startup (which can easily be modified, so its not necessarily a static set of props). The Tools palette reads Widget array in a very similar manner to the way 'Classic controls' are read in from an Array (in fact revTools combines them into one list for its repeat loop).

I understand your goals with new Inspector, but I also think that it will cause some headaches, particularly if the Prop Inspector went back to being a completely static UI stack. Personally I want to keep supporting widgets, which pretty much means the inspector must remain dynamic. I suppose there could be a separate dynamic 'Widget' iInspector, but that seems a bit redundant. Bottom line is that not having a way to edit Widget properties certainly would a deal breaker for me.

I think that some of lag in the IDE might happen because there's too many messages being sent /received.
But I think you will likely still want your Inspector to subscribe to 'IDE messages' or something similar, so that it knows about things like the Screens/Monitors 'desktop' dimensions changed, or a new stack being created/loaded, which could trigger a selectedObject changed message, which could then invalidate some information displayed in your palette, etc., etc.

I spent quite a bit of time on that QuarkXpress-like text/object palette, which was mostly a subset of the Prop Inspector stack (I guess that's my way of exploring the underlying stuff too), but split out into its own palette. Similarly I made a separate object 'Alignment' stack (because I was annoyed by having to keep clicking to get to that tab in Inspector over and over again). Even just dealing with 'classic' controls without any IDE library, it will still have to do a lot of figuring out what sort of object the user has selected, it could be a button, it could be an image, it could be a selectedText chunk, etc. I'll have to upload the latest version of that stack later so that you can take a look at it, it might help.
I don't think I used any revIDELibrary (only subscribed to a couple of IDE messages), IIRC I had it iterated over 'the controls' in 'the selectedObjects', and get 'the properties' of a control. However 'the properties' and 'the customProperties' do not work with Widgets.

You might also care to read this doc, from when the Prop Inspector was rewritten to support widgets, it has some info about classic controls properties too and how the Prop-Inspector's templates are setup to work.
https://github.com/livecode/livecode-id ... spector.md

Or you can go your own way.
Personally, I think they've crammed too much stuff into these palettes.
Like the object alignment section that I made that into a separate palette.

[tperry2x]

I'm all for making things as snappy as possible, and we certainly don't need to stick with the systems as they were handed to us...

This was my thoughts on it too.
Although I still have to get my inspector to recognise a few things (as I say, it's early days yet), but you can see the speed difference with mine on the left and the LCC one on the right.

inspector-speed-comparison.gif (394.87 KiB) Viewed 119 times

It seems fast enough for me to retrieve the list of applicable properties for a selected Widget. The 'classic controls' properties are all stored in tab-delimited plain text files which are files that the IDE has to read on startup (which can easily be modified, so its not necessarily a static set of props).

Very true, but nobody would be modifying the IDE classic controls during normal use. And arguably, if they were, they'd be savvy enough to update a few property reading calls too. (In fact, modifying the classic controls in any way would break stack compatibility when those modified controls were saved. The standalones / runtimes would also need updating as they wouldn't understand how to read any modified properties too), so I don't think modifying the classic controls would be the approach I'd recommend anyone should do, not unless they are able to also recompile the runtimes to match. (including any mobile ones too).

The Tools palette reads Widget array in a very similar manner to the way 'Classic controls' are read in from an Array (in fact revTools combines them into one list for its repeat loop).

I think combined with all these back-and-forwards, jumping between various functions, reading things in arrays, splitting the arrays into items and variables are where the delays are happening. It seems like an awful lot of extra work the IDE is having to do.

I understand your goals with new Inspector, but I also think that it will cause some headaches, particularly if the Prop Inspector went back to being a completely static UI stack. Personally I want to keep supporting widgets, which pretty much means the inspector must remain dynamic.

Me too. I certainly don't want to drop any functionality, quite the opposite eventually, so I'm thinking a tab which is dynamic for widgets is probably the best approach. That can be loaded from the widget's individual custom properties it might have set.

Bottom line is that not having a way to edit Widget properties certainly would a deal breaker for me.

As above, I think that if you could knock up a demo of reading widget properties as a stack, then it would be something I can get my head around.

I think that some of lag in the IDE might happen because there's too many messages being sent /received.
But I think you will likely still want your Inspector to subscribe to 'IDE messages' or something similar, so that it knows about things like the Screens/Monitors 'desktop' dimensions changed, or a new stack being created/loaded, which could trigger a selectedObject changed message, which could then invalidate some information displayed in your palette, etc., etc.

Yes - and that's something else missing from my engine. There's no concept of subscribing to messages as of yet. I'd also like to have a broadcast function that can send the message to all objects if they can receive them, but that's on the wish list on the top shelf of ideas at the moment.

...I was annoyed by having to keep clicking to get to that tab in Inspector over and over again).

That is the intrinsic design issue with having these on tabs. You've hit the nail on the head. Although you want to save screen space for smaller screens, at the same time you also want as many controls shown as possible so you don't have to play the annoying game of clicking through tabs constantly.

Even just dealing with 'classic' controls without any IDE library, it will still have to do a lot of figuring out what sort of object the user has selected, it could be a button, it could be an image, it could be a selectedText chunk, etc. I'll have to upload the latest version of that stack later so that you can take a look at it, it might help.

That would be great. All examples of how this works in practice would be appreciated, something I can take apart and dissect for my own purposes. It would be useful to anyone following along too.

I don't think I used any revIDELibrary (only subscribed to a couple of IDE messages), IIRC I had it iterated over 'the controls' in 'the selectedObjects', and get 'the properties' of a control. However 'the properties' and 'the customProperties' do not work with Widgets.

That's a pain, and is exactly where I reached a bit of a road-block when it came to dealing with the properties of widgets.

You might also care to read this doc, from when the Prop Inspector was rewritten to support widgets, it has some info about classic controls properties too and how the Prop-Inspector's templates are setup to work.
https://github.com/livecode/livecode-id ... spector.md

That's certainly one to sit and work through - but not exactly light reading

Or you can go your own way. Personally, I think they've crammed too much stuff into these palettes. Like the object alignment section that I made that into a separate palette.

This is the thing - there's a lot of info to try and fit in. Especially on smaller displays as I mention above. But I think having loads of palettes to spawn can be equally as confusing, which is where tabs work well. Is it more annoying to have to click through multiple tabs than to remember which palette you need to open to find a control? (and what about if those extra palettes also have tabs on too (like the message box for example), you'd end up with about 4 or 5 clicks to get to the checkbox, rather than one)... however, open to ideas as I honestly am not sure of which approach is best at the moment.

[OpenXTalkPaul]

the speed difference with mine on the left and the LCC one on the right.

OK, first off the bat, the one on the right is doing some additional actions there, isn't it? It's resizing the stack's window, and it also looks like it's hiding the stack and then showing it again after the resize. Which is a more expensive operation of screen-area updating, involving both the OS's window manager and the engine to re-render the contents (visible card area) of the stack's window. Considering that, then your stack visually updating faster doesn't surprise me. Less screen updating is good... (although, I was just now about to add a similar method to merge my SVGIcon Glyphs browser stack, and my Unicode Font Glyphs/Emoji browser stack into tabs of the same stack.)
Would need to do actual speed test of the underlying scripts in milliseconds over a series of repeating the same action to really compare the speeds of different methods, particularly if that's going to be some justification for dropping support for something.

Personally, if I was going to drop the Extension Builder stuff I'd probably just go back to work off of v7 base because at least there was Unicode support, and there a Raspberian build of the Engine for that version (I love the whole concept of RPi / cheap SoC boards), plus Mac 32bit support (and might be possible to shoe-horn a v6 PowerPC engine into back into it's standalone builder). That's been a discussion for a 'OXT Retro' build. The problem with v7 Engine is that people complained v7 Engine was slower than v6 (and it was slower at processing blobs of text in particular, by a lot).

But for sure the less screen updating is good for a responsive feel to the UI. When designing user interface Custom Controls or Widgets you must consider such things as when exactly to redraw things (and with Extension Widgets they don't draw anything unless you code it to do so).

[OpenXTalkPaul]

Open to ideas as well.
How about reveal 'flippers' triangles to expose more of palette as desired? I was planning on using one or two of those to allow show/hide of various groups of available objects in OXT New Tools palette with a single click. There should be a pre-scripted flipper control included in the revObjectLibrary (which I'd also like to also turn into a more readily accessible palette).

I also like the idea of having palettes that can (optionally) adhere themselves to a side of the screen. It's very common to have palettes in these positions in single-window / fullscreen UIs, and of course it makes sense to keep tool palettes out of the work area as much as possible.

Screen real-estate becomes increasingly import the less of it you have available, but I can remember working on 17 x 11 inch paper sizes documents on a screen that was a 512 × 342 pixels (not to mention 1-bit / black & white only), so I know it can be done, but obviously it is the design problem.

HOWEVER, now in the days of Hi-DPI screens, we can 'set the scaleFactor of myStack to 0.80' to use 20% less screen space for a palette (and hopefully everything renders nicely at that new scale).

The Text-Xpress palette idea I was designing was (mostly) for formatting the selectedText chunk. The property inspector doesn't do that on a text-chunk level. Currently the inspector can only set the textFont, textColor, etc. text properties on the control level (most likely a field object or button). This palette can do either or both, so the idea wasn't quite the same as splitting out something that existed into its own palette.