Toplevel

[richmond62]

There is a way to bring a stack to the front of a series of stacks using topLevel, but there is no apparent way of ending a stack to the back, behind all other open stacks ['bottomLevel'].

As topLevel is NOT really a way of bringing a stack to the front, just a way of making it the currently editable stack, a 'bottomLevel' is just a fantasy.

I wonder if stacks can be assigned layers exactly like other objects inwith OXT?

[tperry2x]

I'm not sure. I've never found any documented function to trigger that.

The only way I can think of doing it is:

Locking the screen,
Get the number of currently open windows
Repeating for however many there are
Open each window (even though they are already open) which effectively moves them to the top
End repeat loop
Open the window you want at the frontmost level
Unlock the screen


Sorry this is in sudo-code.
I'm trying to type this on a phone currently, so don't have the benefit of OXT to hand.

[richmond62]

Maybe one way to keep everything in front of one particular stack is to palettise them, and then unpalletise them?

[tperry2x]

I'm not sure.
Perhaps Paul can comment on this, as I think he has first-hand knowledge of what I'm about to allude to.
(I say that as I think he fixed it in the RC3 version of OpenXTalk).

Under Xubuntu, running XFCE, you get this weird effect that I can only describe as "Window focus Juggling".
It only occurs when both the message box is shown and also the inspector palette at the same time. They both continuously try to fight to palettise themselves and flicker continuously. Meanwhile the CPU usage goes through the roof. (like a race condition).

I'll see if I can get a demo of this happening when I'm back at that test machine tomorrow.
I'd like to understand why / how this happens, and why it only seems to affect some distros. Never seen it happen on Windows or Mac (or even on MX-Linux, my main daily use machine). It only seems to happen on XFCE & Ubuntu-based distros as far as I can tell.

This doesn't happen in the RC3 version, so I'm assuming Paul found a way to squash this bug? (I'd love to know how).
This is the reason I think making palettes and top-leveling every stack might have strange effects on some systems.

[OpenXTalkPaul]

I'm not sure.
Perhaps Paul can comment on this, as I think he has first-hand knowledge of what I'm about to allude to.
(I say that as I think he fixed it in the RC3 version of OpenXTalk).

Under Xubuntu, running XFCE, you get this weird effect that I can only describe as "Window focus Juggling".
It only occurs when both the message box is shown and also the inspector palette at the same time. They both continuously try to fight to palettise themselves and flicker continuously. Meanwhile the CPU usage goes through the roof. (like a race condition).

I'll see if I can get a demo of this happening when I'm back at that test machine tomorrow.
I'd like to understand why / how this happens, and why it only seems to affect some distros. Never seen it happen on Windows or Mac (or even on MX-Linux, my main daily use machine). It only seems to happen on XFCE & Ubuntu-based distros as far as I can tell.

This doesn't happen in the RC3 version, so I'm assuming Paul found a way to squash this bug? (I'd love to know how).
This is the reason I think making palettes and top-leveling every stack might have strange effects on some systems.

Damn, I remember working on that issue, but I can't really remember what I did in there to fix it, but yes the problems do seem to be related to certain stack window modes meets certain Linux window managers. I believe it's something in one of the behavior scripts?
IIRC around the same time I was also trying to resolve some problems on macOS where the tools and message box move themselves to try not to obscure the revMenuBar ( I changed it so they can overlap now, let the user put windows wherever they want), the main issue was sometimes it wouldn't prevent overlapping window but it did offset the mouse pointer position by like 22 pixels (what the height of the MenuBar was) so you clicked at one button but the IDE selected a different button.
On the Linux side I was using XFCN / Xubuntu at the time, but I went back to Ubuntu Studio with KDE Plasma (which the Dictionary stack works just fine with). I had much wierdness on Elementary OS (Pantheon) where I'd get these fantom windows when an extension (Browser Widget) overlays its drawing over top of the stack window. The Dictionary Stack would do this but the Extension 'Store' (OXT Extension Repo) tab of Extension Manager was better behaved, so that could be a clue. It probably is related to which compositor that a Window Manger is using. X org seems to be on its way out (after decades), and I was thinking maybe this is Wayland that's the root of the issue as many Linux devs move to using that in their WMs?
It would be good make a collection of issues with various Linux Distros/Window Managers looking for commonalities between the ones with the problems, and also a list distros/wms that are known to be compatible. We could use a test stack that puts stack windows into all the different possible modes (Modeless, Modal, etc.).

[OpenXTalkPaul]

There is a way to bring a stack to the front of a series of stacks using topLevel, but there is no apparent way of ending a stack to the back, behind all other open stacks ['bottomLevel'].

As topLevel is NOT really a way of bringing a stack to the front, just a way of making it the currently editable stack, a 'bottomLevel' is just a fantasy.

I wonder if stacks can be assigned layers exactly like other objects inwith OXT?

This is typically the job of the OS's window manager. On macOS objC cocoa you can do all sorts of manipulating windows and window collections (like list even windows opened in other apps or minimize all windows). In fact the OXT macOS native tools library does some of that already. That's how darkMode can change the a windows frame on an individual window basis. That only helps if you're on macOS. I'm sure on Windows and Linux Gnome have similar APIs that could be tapped into.

[richmond62]

This is a right pain in the bum.

If there were a way to work out a series of stacks' "layers" one could bring them forward and send them backward in all sorts of very useful ways.

I wonder, however, if, while this may not be possible with a few free-standing stacks, if it might be possible with a main stack and its substacks?

[tperry2x]

Damn, I remember working on that issue, but I can't really remember what I did in there to fix it, but yes the problems do seem to be related to certain stack window modes meets certain Linux window managers. I believe it's something in one of the behavior scripts?
IIRC around the same time I was also trying to resolve some problems on macOS where the tools and message box move themselves to try not to obscure the revMenuBar ( I changed it so they can overlap now....
...It probably is related to which compositor that a Window Manger is using.

This is using the XFCE window manager, with Xubuntu desktop. Compositing turned on.
I have observed two issues.

The first is if you have a new stack window open, then open the inspector, you can't bring window focus on anything except the inspector window (clicking on the main window immediately switches window focus back to the stack inspector):

cant-click-wd-with-inspector-open.gif (126.96 KiB) Viewed 3666 times

However, I've noticed this is ONLY if the stack inspector is shown. If the card inspector or button inspector is shown, then the issue doesn't occur.

The second issue:
With the inspector palette open, inspecting the stack, AND the message box open:

window-juggling.gif (73.51 KiB) Viewed 3666 times

This is what I referred to as 'Window juggling' where it continuously tries to gain focus on the stack inspector window. This is perhaps the most annoying bug, because the CPU use goes through the roof (fans come on).
Again, if the inspector is switched over to inspecting a card or a button, then this doesn't happen. So I'm thinking it's something to do with the stack inspector behaviour? Why it's only apparent on this combination of distro is anyone's guess.

These issues I can only replicate under this combination of distro and window managers. It seems fine under Caja window manager and MX-Linux.

I'll check through the various behaviours to see what might be causing the issue, but it's a hard bug to squash. This happens on both my OXT Lite 0.91 and OXT Lite 0.92 builds. It also occurs in a fresh (unedited) install of Livecode community 9.6.1 and 9.6.3, so I think it's a problem that has always existed - not something I've introduced in my edits.

It would be excellent if you could point me more in the direction of what you'd edited Paul, that would be highly appreciated, so I can work that into a fix before releasing OXT Lite 0.92, which I planned to do mid-week. This is one of the biggest roadblocks to that at the moment (as Ubuntu-based linuxes with XFCE are an often used combination)

Just to confirm, the exact same application (copied from Xubuntu that has the problem) and running on MX-Linux does not show the issue (all windows can be focused as you'd expect, and nothing 'fights' to gain focus with the stack inspector and message box open). The CPU use is also barely ticking over:
https://youtu.be/ww2P4nodm9M

[richmond62]

Perhaps it is good to remember that the Linux 'offerings' of 'that company in Edinburgh' have always been second-class goods compared with the Macintosh and Windows versions.

Several long-time contributors to the LC forums have nagged, and nagged, and nagged about getting the Linux versions up to par, with little obvious movement, and never a sensible response.

Having written that, I should point out, with the notable exception of the Dictionary, I have never had any obvious problems with LC and Xubuntu or Debian + XFCE, beyond, in 32-bit Debian 12 + XFCE, the messageBox being 'ungettable at'.
-

Screen Shot 2023-10-01 at 12.18.53.png (235.14 KiB) Viewed 3646 times

-

will gracefully degrade in feature set

apart from the fact that whoever wrote that has crappy grammar:

'will gracefully degrade its feature set' [which tells us buckets about their sloppy attitude towards a lot of things]

'gracefully' . . . LOL

And, although my screenshot is from the LC 963 documentation, exactly the same paragraph is 'there' in the LC8.1.10 Dox: and, frankly, I cannot be bothered to check further back.

What is signal about the documentation is that it carefully sidesteps mentioning by name any distro that LC Linux WILL work on 100% satisfactorily: and they even expect people to pay money for software with that disingenuous behaviour!

Last time anyone bothered to check, LC central were performing "quality control" for Linux on Ubuntu 16.04 which is the same vintage
as MacOS 10.12 'Sierra'.
-

wcfields.jpg (16.92 KiB) Viewed 3642 times

[FourthWorld]

LC's Linux command-line app, LC Server, is reasonably well maintained, as it's needed for their build system and their OnRev hosting service. Changes made there generally also show up in the Linux desktop build.

But I can't recall the last time I saw work on Linux-specific GUI issues, at least not since their two strongest internal Linux advocates, Frazier Gordon and Dr Peter Brett, left the company several years ago.

As the list of known issues with LC on Linux desktop systems grows, personally I've come to regard it as "unofficially deprecated". I use it where it works, and have no expectations where it doesn't.

Of course I'd love to be proven wrong with a strong update that addresses issues with more recent Linux distro versions. But until I see that, I only see what I see, and plan accordingly.

Fully (and at those point irrevocably) committed to a proprietary-only business model, I can't really blame them.

Most LC direct revenue comes from Mac folks, and most downstream end-user revenue comes from Windows.

Linux users famously and strongly prefer software that is both free of proprietary encumbrance and also free of cost.

Exclusively-proprietary dev tools are a rarity everywhere these days, more so every year since the '90s, before FOSS took over the dev landscape, back when proprietary tools like HyperCard, Director, Toolbook, and Flash were the norm.

Trying to make a living selling a proprietary dev tool in 2023 is an uphill battle. The results are observable.

I consider the low prioritization of Linux GUI fixes an understandable business triage.

--

This is a part of why web-native dev tools have become an ever bigger part of my workday. Add in how much work browser vendors do for us to handle the ever-increasing requirements for app packaging, and the unparalleled ease of deployment needing nothing more than a URL, I've come to see the web as the 21st century fulfilment of HyperCard's 1987 promise.

There is only one scripting language preinstalled on all GUI devices: JavaScript. It ain't going away. Even LC devs increasingly rely on it; see the widgets like Charts that are JS libraries requiring an embedded browser instance.

Free. Open. Standard. Ubiquitous.

As the years have progressed, every reason I'd come up with to avoid putting JS front and center in my workflow have fallen away.

[richmond62]

"unofficially deprecated"

I feel very sorry for anyone who shells out 338 Euros for something that is that shaky; especially as LC don't bother to point that out.
-

Screen Shot 2023-10-01 at 18.32.51.png (167.83 KiB) Viewed 3628 times

-
If, as you claim, most of LC's revenue come from Macintosh and Windows users, surely it might be more honest to just remove the Linux option altogether?

Mind you, LiveCode is a company from whom, unfortunately, I have come to regard as fairly dishonest, or at the very least of making claims which they are not capable of fulfilling:

The latter represents an initial start towards a sustained effort to create a next-generation visual editor.

I can confirm that this first open source version will carry the 6.0 version number.

https://web.archive.org/web/20130609134 ... -progress/

10 years later they are still BANGING ON about "a next-generation visual editor": and, funnily enough, I, for one, donated money to their Open Source Kickstarter in the expectation of 'a next-generation visual editor' inwith, say, 6 months.

So: having, frankly, written all sorts of stuff for the 2103 Kickstarter (most of which did not manifest), why anyone should trust them in respect of any other claims [c.f. A.I.], I just don't know.

It would be interesting to know why Frazier Gordon and Dr Peter Brett left the compnay [although LC still deploy the 'ghost' of Frazier Gordon on their website:
-

Screen Shot 2023-10-01 at 18.55.41.png (1.06 MiB) Viewed 3625 times

-
https://livecode.com/services/

[FourthWorld]

"unofficially deprecated"

I feel very sorry for anyone who shells out 338 Euros for something that is that shaky; especially as LC don't bother to point that out.

Why should they be obligated to present the personal opinion of one user?

If, as you claim, most of LC's revenue come from Macintosh and Windows users, surely it might be more honest to just remove the Linux option altogether?

Because it runs well enough that many of us continue to use it daily.

None of the platforms have complete feature parity in LC, and all software from all vendors always has bugs.

Anyone using their time productively will evaluate any tool from any vendor, and adopt it into their workflow where it fits their particular needs.

I use LC where it's a good fit. I use other things where they're a better fit.

The only audience I see expecting a single language to be the best at all possible things is the one that stopped learning new languages 35 years ago when HyperCard premiered.

Most devs I meet under 50 are polyglots who freely move from tool to tool as project requirements dictate.

So: having, frankly, written all sorts of stuff for the 2103 Kickstarter (most of which did not manifest), why anyone should trust them in respect of any other claims [c.f. A.I.], I just don't know.

Yet despite the vast universe of options the entire rest of the world has been using to drive the 21st century's software revolution, you've chosen to remain dependent on their work a decade later.

My own life became much simpler after adopting a rule suggested years ago by a friend: Do not complain about anything to which you need not subject yourself.

YMMV

[richmond62]

you've chosen to remain dependent on their work a decade later

Funny.

I just have never bothered to mention my work with HyperNext, Visual BASIC, or any of the other things I have recourse to from time to time.

My 'Devawriter Pro' no-longer remains dependent on LiveCode for the simple reason that there are what we could call "one-and-a-half" OXT versions thanks to the very hard work of 3 developers.

It is ONLY dependent on xTalk in the sense that to 'port' it to another programming language would be far, far more trouble than it is worth.

I am dependent on LiveCode for my EFL programs I make for my 2 language schools: but as LC 8.1.10 provides ALL that I will ever require there, it is really not relevant to this discussion.

I am over 50: but, unlike some over-50 year olds, I am not inflexible to the extent that I cannot flex when it is required. At present my software requirements require no flexing whatsoever: but, being aware of possible future flexing requirement I devote a large part of my 2 month Summer holiday each year to exploring the basics of other programming arrangements than xTalk so I can get up to a moderate speed when and if.

AND if LC or OXT, or both of them, were to vanish of the face of the earth tomorrow it would not bother me at all, as the existing versions of LC and OXT I have access to fulfil almost all my needs at present: just as, paradoxically, BBC BASIC from 1983 fulfils another of my requirements.

Because it runs well enough that many of us continue to use it daily.

Indeed, as do I.

BUT what I wrote was NOT about who is, or who isn't, or who might be using a Linux version of LiveCode; it was about the company's behaviour over the last 10-odd years in respect of its customers and donors: including it pushing a Linux version which, last time it was mentioned, they were checking against a 2016 version of Ubuntu, which is:

1. Extremely out of date.

2. Only one variant of one of the 4 dominant types of GNU-Linux (Debian).

I wonder, for the sake of argument, what sort of noise from LC central there would have been if someone had pointed out that LiveCode crashes on Red Hat ; probably very little compared with the stuff about Sonoma.

[richmond62]

Hello, Richard.

Here's a really odd 'syndrome': it is where 2 characters have a conversation that takes place on 2 different forums at the same time
with bits of it on either one or the other, and the real puzzle is to know which bits to fit to which other bits. . .

I do hope you are having at least as relaxing a weekend as I am having.

Best, Richmond.

[FourthWorld]

I do hope you are having at least as relaxing a weekend as I am having.

Thank you. Yesterday was board game design, today is software design. A rainy day in Los Angeles lends itself well to monkish tasks.

At some point we might trade notes about board games. Are you a member on BoardGameGeek.com?

May the remainder of your weekend continue well...

[richmond62]

The second layout for Hexagonal chess, after Glinski's, was worked out by me in 1978: I do not know who mentioned it in the Wikipedia article.

Currently looking for a way to market a game that is a modified Hnefatafl: most of it, in various incarnations, is 'there' on Boardgamegeek.

Also; subjecting a slew of 11-12 year olds to 'Bigamy chess', thought up by me after a sleepless night about a month ago. The "poor darlings" now have to write a compare & contrast essay between it and standard European chess.
-

BigamyChess.png (64.51 KiB) Viewed 3592 times

-
Note as it uses a 9x9 board the Knight and the Bishop are exchanged on one side.
-

Elephant.png (27.08 KiB) Viewed 3592 times

-

Queen.png (14.48 KiB) Viewed 3590 times

-
The 2 Queens have restricted moves.

Pawns can ONLY move 1 square in their first move: they promote at the back line. Castling is permitted.

[tperry2x]

Getting back on topic, I'd hoped to observe the fixes in RC3 (linux) to this problem on Ubuntu.
Unfortunately, it's not fixed in RC3 either:

RC3_notfixed_A.gif (244.79 KiB) Viewed 3571 times

(With just the inspector open, trying to click the empty new stack).

RC3_notfixed_B.gif (260.43 KiB) Viewed 3571 times

(With the message box and inspector open, the error is even worse).

So, back to the drawing board for anyone trying to find a fix.
(Just thought I'd post that if anyone else was looking inside the RC3 for help and a fix)

[richmond62]

'Getting back on topic' . . . And just why, forbye, would a body speir eftir that?

And, the topic is to do with layering stacks on a desktop.

Window focus is not the original topic, though it is connected, and a problem.

As I know that LC 963 and Xubuntu DO work together I would suggest you use Xubuntu as your target system as with the enormous 'eco-system' that is the GNU-Linux world you need to conquer it one hill at a time.

Ran LC 963 on Xubuntu 23.10 beta last night: I didn't see any obvious problems there.

[tperry2x]

...I would suggest you use Xubuntu as your target system...

The glitching behaviour shown above IS using Xubuntu.
If you have the inspector open, and the message box, and a new project - try clicking between all three and see if you are getting that juggling behaviour...
Anyway, I've fixed it and will post an update in my changes list soon.

05_fixed_window_juggling.gif (121.98 KiB) Viewed 3554 times

[richmond62]

The glitching behaviour shown above IS using Xubuntu.

Blast.