What I'm adding, and what I'm planning next...

[tperry2x]

My point is, like the issue you have which I've corrected for the brush tools and such - the polygons won't save either if you let them create their own image object.

[OpenXTalkPaul]

That's the achilles heel of Linux app dev I think,

Depends on your outlook. I mean, choice is always a good thing in my opinion.

on macOS (x+) you know Objective C runtime is going to be present, like wise with Windows APIs

Kind of, until either of them pull things from their system without notice (which we know they do).

I'm all for more choices for end users, but from a dev perspective it would help to have a solid foundational baseline to work from. For the past 25 years or so you can be sure some base set will be present (NS NextStep stuff, CoreFoundation), even with the newer Swift language there's plenty of CoreFoundation, Cocoa/CocoaTouch being used. I believe the Win32 APIs are still in Win11, and have been since Win95 if I'm not mistaken. They've basically piled on new app frameworks like Universal Windows Platform (UWP) on top. Sure they can just drop support for anything they like, but not without risk of loosing some user / dev base. They usually give plenty of warning, like when Apple dropped classic Carbon APIs everyone knew that was coming well in advance.

The problem of trying to read a GTK theme is the version of GTK can vary, and what about systems that are using some alternate path to store their themes at?

I thought of a method for linux such as this perhaps:

swatch.gif
system-colour.oxtstack
Script is in the button.

Edit: I couldn't help feeling there was another easier way, and I think there is:
Simply:

Code: Select all

put the hiliteColor

alt-method.png
system-colour-v2.oxtstack

Method 1: gets the TEXT selection color on macOS 11, I think we more want he systems object focus color.
Method 2: works but as you've noted pixel sampling with mouseColor triggers that user permisions request on macOS > 10.11+
Here's a variation on method 2 that uses export snapshot:

Code: Select all

local tSampFld

on mouseup
   put "samplefield" into tSampFld
   show fld tSampFld
   send samplePt2 to me in 1 second -- could make delay less
end mouseup

on samplePt2
   select line 1 of fld tSampFld
   put the top of fld tSampFld -10 into tTop
   put the left of fld tSampFld +40 into tLeft
   set the screenmouseloc to tLeft + the left of this stack,tTop + the top of this stack + the height of fld tSampFld /2
   -- import snapshot from rectangle (the rect of fld tSampFld) of window (the windowID of this stack)
   export snapshot from rectangle (the rect of fld tSampFld) of window (the windowID of this stack) to tSnapshot as jpeg
   create image "Snap"
   set the text of image "Snap" to tSnapshot
   -- put it into tSnapshot
   --import snapshot from the selectedObject at size 100,100
   put the imageData of image "Snap" into tPixelData
   -- put the imageData of tSnapshot into tPixelData
   delete image "Snap"
   put 1202  into tOffset
   put byteToNum(byte tOffset+0 of tPixelData) into tRed
   put byteToNum(byte tOffset+1 of tPixelData) into tGreen
   put byteToNum(byte tOffset+2 of tPixelData) into tBlue
   put tRed,tGreen,tBlue into tSampCol
   hide fld tSampFld
   --
   put tSampCol into fld "result"
   set the backgroundcolor of graphic "swatch" to tSampCol
end samplePt2

on clearswatch
   put "" into fld "result"
   set the backgroundcolor of graphic "swatch" to ""
end clearswatch

That works on macOS 11 and doesn't seem to trigger the permissions request on my system.
I'm not convinced about the color accuracy with this method particularly not in darkMode as it seems seems to blend the color with the background color and the sampled RGB values then looks slightly darker.

I don't know, it's doesn't seem like too much to check a few different locations for GNOME,MATE,etc. for existence of a theme file. It may be a bit more work, but it would be a less hacky solution than creating object, selecting it and then sampling pixels.

Found on SO:

Setting is /org/gnome/desktop/interface/gtk-theme for GNOME and Unity and /org/mate/desktop/interface/gtk-theme for MATE. You can use dconf-editor to look at settings like these. It will show you the current value and the system default value.

You can also use the dconf command-line tool. dconf read /org/gnome/desktop/interface/gtk-theme will show you the current value.

System themes are stored in /usr/share/themes/. This is the system-wide equivalent of your ~/.themes/ directory. The directory matching the name of the value of your dconf setting is your current gtk theme.

[tperry2x]

Found on SO:

Setting is /org/gnome/desktop/interface/gtk-theme for GNOME and Unity and /org/mate/desktop/interface/gtk-theme for MATE. You can use dconf-editor to look at settings like these. It will show you the current value and the system default value.

You can also use the dconf command-line tool. dconf read /org/gnome/desktop/interface/gtk-theme will show you the current value.

That's great for GNOME and Unity, but what about the others? (KDE, Cinnamon, Budgie, LXQt, LXDE, XFCE, Deepin... etc). Plus the dconf editor does not come as standard in a lot of distros, so you can't rely on it being there. (because user choice )
This is kind of why I thought it was best just to let the user choose their own colour scheme from a popup.

System themes are stored in /usr/share/themes/. This is the system-wide equivalent of your ~/.themes/ directory. The directory matching the name of the value of your dconf setting is your current gtk theme.

But - you can also put themes in ~/.themes in Linux and have the default theme loaded from there. (It does not have to reside in /usr/share/themes of course), so when reading the name of the theme that is set (however that's done), you'd in theory need to check both locations?

[tperry2x]

Continuing on from 'What I'm planning next', Overclockedmind had mentioned in the past that sometimes the tools palette might overlap other windows, even when OXT / LCC is in the background.
I can get it to do this on MacOS at the moment (if I really try and confuse it), and on some of the various Linux distros I test on. I can also get LCC 9.x to do it too.

Windows seems unaffected by this and hides the palettes as it should when OXT isn't in the foreground. (at least here on Windows 10 - will test on Win 11 too).

So, I've added an option in the prefs that hides the tools (and message box if it was open) palettes when the IDE goes into the background:

hider.png (4.15 KiB) Viewed 290 times

Demo of it in action in the upcoming v1.04 here.

[micmac]

Two requests.

1. Option in prefs to choose between “Pointer” and “FingerHand” for Browsing.

2. If you have a stack window that fills the entire screen (except menubar, Mac) then when you open Project Browser it opens on top of the other window as expected. Then if you click on the stack window – it goes in front – which is also expected.
But if you now want to see the Project browser again, now behind, then you have to go to the Tools Menu and the first close the Project Browser and then open it again.

The problem occurs because the Project Browser is invoked by a toggle menu (with a checkmark).
Seccondly, when you close and open the Project Browser it resets itself.

If it appeared in the Window Menu the problem would go away.

Thanks

Mic

[OpenXTalkPaul]

That's great for GNOME and Unity, but what about the others? (KDE, Cinnamon, Budgie, LXQt, LXDE, XFCE, Deepin... etc). Plus the dconf editor does not come as standard in a lot of distros, so you can't rely on it being there. (because user choice )
This is kind of why I thought it was best just to let the user choose their own colour scheme from a popup.

It's like Pokémon, gotta collect them all! I think that supporting ALL of these Window Managers would not be nearly as many as there are Poké monsters. There's maybe less than 10 the are most commonly used. And keep in mind we're really only interested in reading like four RGB values (FG, BG, text selection, and object focus colors).

LXQt (since I just installed Lubuntu in a vm)... that use Qt (obviously), and has an appearance config file that has the foreground / background / section colors we're after. In addition to Qt, Lubuntu ALSO has GNOME / GTK configs present, because lots of apps will still have been built to use GTK 'widgets' instead of Qt's. I've been irritated by this in the past when I've tried to change system appearance on Linux distros but some apps won't use the system's appearance. LXQt appearance themes are done with Qt, but an individual app may have been written using GTK so it uses those settings instead.

There's really only two widely used GUI widget toolkits (not counting version differences like GTK2 vs GTK3/4) that are used in Linux world, GTK and Qt. It's up to an app / appearance theme dev to pick one. A good distro should probably have both frameworks pre-installed and would have matching theme files for both toolkits. A window manager's themes will most likely be using one of those two (unless it's using something less common like GNUStep). For example KDE Plasma, like LXQt, uses Qt for appearance configuration, their config files may be in a a different location, but those files are basically going to have same contents to parse.

So we could collect a list of all of the relevant file paths from all of those (KDE Plasma, Cinnaminon, Deepen, etc.) and write a script that iterates through the list checking for 'if there is a file tAppearanceInfoFilePath' until it finds one. Or maybe it could check for what Distro is running and use the appropriate path.

Of course it is a lot easier to let the IDE user set the colors, and one might actually want the IDE to have an appearance that is distinctly different from the system-wide appearance theme. I just think the IDE should try to pick up the system theme colors by default, on new installs or when revPrefences file is reset. That's how I was planning to do it for macOS/Cocoa. If it doesn't find any appearance color info then it would use some all-back default colors.

Maybe that is lot of work for something trivial / purely cosmetic, I don't know.

[tperry2x]

If it appeared in the Window Menu the problem would go away.

Ah, okay - makes sense.
I've implemented your 2nd request. That's done, and is a very good idea:

added-to-wd-menu.png (19.78 KiB) Viewed 244 times

It now lists if project browser is open. I thought while I was there it would make sense to list the Message Box if it was open, and also the Tools palette if that was ever obscured (not that it should be possible).

Your second suggestion, about making the hand and arrow a preference - I'll look at that now.

[OpenXTalkPaul]

If it appeared in the Window Menu the problem would go away.

Ah, okay - makes sense.
I've implemented your 2nd request. That's done, and is a very good idea:
added-to-wd-menu.png
It now lists if project browser is open. I thought while I was there it would make sense to list the Message Box if it was open, and also the Tools palette if that was ever obscured (not that it should be possible).

Your second suggestion, about making the hand and arrow a preference - I'll look at that now. I'll also have it so the icon changes on the Tools palette respectively...

These are both a couple of the things that have long annoyed me but I never got around to doing anything about them.
IMO ALL of the IDE UI stacks (except for revMenuBar) should appear in the Window Menu. For example, Extension Manager also has this same issue where you have to deselect the menu item check or otherwise close the stack, and then reopen it to get the window to come to the front again.

Maybe the IDE stacks could be separated from user opened files by a divider line in the widow menu.

Again the Project Browser needs work on a few other window refreshing fixes too. I've frequently had to close that window and then re-open it to get the objects list to update.

I'd also like to second the request to allow using the the Arrow 'Run' cursor instead of the Finger link cursor.
I do love the nostalgia factor of it (so much so that I previously created a SVG icon version of the Hypercard finger cursor), but when HyperCard/xTalk first came to be it was a much different time. Since then Web Browsers took over as the 'hyper media' standard and the finger cursor has become pretty much exclusively used for hyper-text links, so it does seem out of place in present day.

[tperry2x]

I'd also like to second the request to allow using the the Arrow 'Run' cursor instead of the Finger link cursor. ... it does seem out of place in present day.

I was going to say that I kind of like the pointing hand as the default - I know it's only a small thing, but it does serve as a visual reminder that you are in the IDE, rather than it being the generic one-size-fits-all boring cursor that the rest of the OS uses.
Something a bit different, just to set the IDE apart from any other app.

But I do like things to be under user control if possible, so yes - I like the option of being able to set the arrow as the default too. Having things as options and configurable should be what this is all about in my opinion.

I was also just about to mention that the hand tool isn't used anywhere else, but then I pointed to a link in firefox and...

cursor-is.png (18.81 KiB) Viewed 235 times

I mean, it's fairly simple to do I think.
To go to the arrow as default:

Code: Select all

set the defaultcursor to (the id of image "com.livecode.tool.Browse.icon.png" of stack "revTools")

To go to the pointing hand as default:

Code: Select all

set the defaultcursor to 0

So this can be a simple toggle in a preferences window.

[OpenXTalkPaul]

I'd also like to second the request to allow using the the Arrow 'Run' cursor instead of the Finger link cursor. ... it does seem out of place in present day.

I was going to say that I kind of like the pointing hand as the default - I know it's only a small thing, but it does serve as a visual reminder that you are in the IDE, rather than it being the generic one-size-fits-all boring cursor that the rest of the OS uses.
Something a bit different, just to set the IDE apart from any other app.

But I do like things to be under user control if possible, so yes - I like the option of being able to set the arrow as the default too. Having things as options and configurable should be what this is all about in my opinion.

Maybe could add a large purple Arrow to let you know that xTalk "Thinks Different"(ly) from other apps. It's just that over the past three decades the Finger cursor has become exclusively asociated with text / hyperlink in my mind.

Yes I like options, options are good.
In fact want to be able to use all of the OS provided cursors too!

BTW, running xTalk on web (OXT Emscripten / HyperSim) I've had to use the standard cursors available via web browsers API, which are the same as the ones provided by the OS. The 'set cursor' syntax does not work in the web engine.

[tperry2x]

Option in prefs to choose between “Pointer” and “FingerHand” for Browsing.

Hi Mic,
Just to let you know I've added this too. It will appear in v1.04 of OXT Lite when it's ready.
Many thanks.

in-prefs.png (3.07 KiB) Viewed 217 times

[micmac]

You are so fast, Tom!

Thanks a lot

Mic

[tperry2x]

Given the large number of changes/improvements/sortings-out that you have implemented in your up-coming version I would expect it to be called 1.1 to indicate just that, and not 1.04.

Thank you, but I feel these are only small improvements really. A few visual tweaks, but it's about restoring functionality where possible.
I'd probably do a version-jump to 1.1 when (if?) I get the player tools and browser working on Linux. I mean, I can make them work while saving hundreds of MB off the size of the IDE, however I then have the issue as how to 'embed' these in the linux standalones, how to get the standalones to use those embedded methods after they are created, and the issue of compatibility (although that seems to work out-of-the-box, as the stacks don't fail to open - the linux 'player' and linux 'browser' just render as standard buttons).

Anyway, something else I just added - which is an annoyance that's bugged me:
When you bring up the message box, in standard 'single line' mode - it never has the text of the field selected.
So, now it does select that when it's opened or when the 'single line' mode is switched to:

mb-select.png (17.92 KiB) Viewed 206 times

[tperry2x]

The next thing on my list, is this. Sliding palettes, which I really hate.
If you make a new stack. Put something on it, an object like a button.
Bring up a stack inspector palette, and make sure it's deliberately in the way where an alert dialog is about to appear.

Then, close the stack so it triggers the "Do you want to save..." message.
The stack inspector will 'slide' (for want of a better term) out of the way (example here). I really want to remove that. Sliding dialogs and things give me motion sickness

[tperry2x]

Again the Project Browser needs work on a few other window refreshing fixes too. I've frequently had to close that window and then re-open it to get the objects list to update.

I'm just poking around in the project browser, (I was adding a manual refresh icon at the top-left), at first glance, I wondered where the widgets were that show in the 'Application Browser':

refresh-proj-browser.png (115.12 KiB) Viewed 186 times

They are there - but the application browser doesn't show them in any kind of hierarchy:

or-is-it-this.png (101.98 KiB) Viewed 186 times

There also seems to be quite a few old properties left in the project browser:

props.png (70.94 KiB) Viewed 181 times

Quite frankly, the project browser behavior script looks a bit of a nightmare.

convoluted.png (264.26 KiB) Viewed 177 times

I think it's fair to say it's overly complex and it was going to be one of my jobs to rewrite it. Rather than base it on anything existing though, I think I may come up with an entire new one from scratch. This is another big job though, and one I was putting off.