Xubuntu +

[richmond62]

Hmm;
-

prob.png (27.54 KiB) Viewed 1938 times

[richmond62]

Totally hosed after the latest update: flashing focus, blocking other apps: only way 'out' is to logout.

[tperry2x]

So, strangely enough, this is actually one of those bugs I can replicate here. This happened to me after Xubuntu did an automatic update and a restart. Then the IDE started acting weird.

I now get the same window issue as you, when I show an inspector. It's fine up until the point I bring up any inspector window: (same as your screenshot)

a.png (74.32 KiB) Viewed 1932 times

Despite the whole thing going haywire when I popped open an inspector, things remained responsive, just that the focus stealing and window juggling was in full effect - as was an outline of the inspector window - stuck on the screen:

xubuntu-wierdness.gif (967.64 KiB) Viewed 1921 times

Just to be clear, I had 1.09 with all the updates applied, working fine before the automatic update of Xubuntu and a spontaneous restart.

Like you, the only way I had out of it was either to force quit or log out of the session.
Which brings me onto the session options.
These two are offered by xubuntu, but I suspect something has been updated which has made the IDE incompatible.

b.png (17.91 KiB) Viewed 1932 times

So, thought I'd try with adding a standard 'gnome-session' to the same affected machine:

c.png (74.83 KiB) Viewed 1932 times

I'm offered a choice of display manager. I'm going to select GDM as it's older and probably more compatible with the IDE.

e.png (10.86 KiB) Viewed 1932 times

installs...

f.png (44.16 KiB) Viewed 1932 times

After a reboot for good measure, I'm given these options of a session choice at the login screen:

g.png (19.94 KiB) Viewed 1932 times

I choose "Gnome on XOrg"

So, same machine - same hardware - no issues with the inspector - which makes me think something changed in the xubuntu session when an upgrade happened, which made it a non-runner.

h.png (192.07 KiB) Viewed 1932 times

Just going to confirm my theory by attempting to run a vanilla version of LCC 9.6.3 in the updated xubuntu session, and see if the inspector has issues there too...

[tperry2x]

Can confirm that a vanilla LCC 9.6.3 install to the same machine, after the XUbuntu session had updated, also causes issues:

i.png (142.02 KiB) Viewed 1930 times

The only way out of this for me is a force quit or a restart.
I'll see what I can do to combat it, and have a look as to what actually got updated recently in XUbuntu. That might give me a clue as to what it doesn't like. It's interesting it's as soon as I call up an inspector, so it's probably related to the same-old-same-old window juggling issue.

Certainly, my recent updates haven't tweaked any window modes, so I don't think it's that.

On my 'daily-driver' Linux, which is MX - I have a fully updated v1.09 and have no issues whatsoever with the inspectors at the moment (no window focus issues, and no window-juggling issues):

daily-driver.png (117.68 KiB) Viewed 1930 times

Which also makes me think it's some kind of XFCE / XUbuntu default session issue after an update from one of those components.

[tperry2x]

To test it further, I thought - what if I take an old version of 1.09 - and load that up in the updated XUbuntu session?

wd-jugging-old.gif (91 KiB) Viewed 1917 times

This time, my CPU usage climbs to 100% and nothing can be clicked. I can't even log out or force quit. I have to manually reboot the machine with the power button.

Edit: confirmed that I can log back in to the "Gnome on XOrg" session, and run 1.09 of this old version of OXT Lite absolutely fine. So I'm pretty sure it's an incompatibility that has happened after a system update. (running the older version of 1.09 would seem to confirm to me that it's not something I've caused in a recent update - not something I've 'hosed').

I guess, leave it with me....

[tperry2x]

I've been fruitlessly playing with xubuntu, or more precisely: (ubuntu default desktop session) all morning, but to no avail.

I have my doubts about xubuntu at present.

Despite weighing in at over 10GB installed, the "minimal" distro doesn't even seem to be able to open the default browser:

hmm.png (85.41 KiB) Viewed 1873 times

So, I thought I'd install firefox:

snapd.png (58.78 KiB) Viewed 1873 times

At which point snapd crashed.

I had enough, and installed "mate-desktop-environment".
Logged out, logged back in using that desktop environment instead, and OXT Lite 1.09 (202412231952) runs without a hitch.

mate-desktop.png (118.48 KiB) Viewed 1873 times

The best solution I can offer at the moment, is to put up an alert if an incompatible desktop environment is detected:

possible-alert.png (35.11 KiB) Viewed 1873 times

I did have a post about the state of desktop-OS, and how this seems to be headed south at the moment. This post is not meant to be a mini-distro-review, but illustrates why distro choice (or rather desktop session choice) matters. The engine does not agree with something that's changed in the default 'buntu desktop session, but shows how easily it can be broken by an update to a library or something.

[tperry2x]

Which then, brings me back to the "Linux flavours that DO" post.

[richmond62]

Were that possible on my machines at my school I would do that; but it just isn't, so I shall disable the check for updates (luckily none of them have been updated for 6 months), and leave them with the Xubuntu they have.

[tperry2x]

I shall disable the check for updates (luckily none of them have been updated for 6 months), and leave them with the Xubuntu they have.

I'm hoping this isn't a permanent thing, and is just down to a temporary issue with the ubuntu desktop. I can't put my finger on exactly what is causing it, which is annoying, but the result of my testing seems to be switching desktop-session to almost anything else seems to rectify it. Hopefully it's just a temporary bug, as being community-maintained, I'm sure it'll get spotted and picked up on. The whole xubuntu thing seems very unstable at the moment, as the ubuntu-desktop also kept logging me out and quitting unexpectedly. It's not a distro I would use to showcase the virtues of Linux to anyone at the moment.

I would stay on the 6+ month-old version too, at least until whatever was updated recently gets rectified.

[richmond62]

Well: to be honest I only noticed it when I installed the NEW XFCE 4.20 . . .

[OpenXTalkPaul]

KDE Plasma (in Ubuntu Studio). which I believe is built on the Qt UI framework (and not GTK that the LC docs suggest to use), was the most stable I've used as far as window juggling issues (and the Browser Widget seemed to work a little better on Plasma too). I know Plasma has this legacy reputation as being more resource intensive than XFCE but from what I understand Plasma has become better in that regard than XFCE in recent years. I just don't like that with Plasma the 'rounded corners' themed windows are actually square (and it's noticeable sometimes), that has nothing to do with OXT though.

See the thing about Linux is that, while there are a lot of choices, there's a lot of similar choices (usually forks of the same parent project), and there aren't many great choices (in my opinion).

[tperry2x]

KDE Plasma (in Ubuntu Studio). which I believe is built on the Qt UI framework (and not GTK that the LC docs suggest to use), was the most stable I've used...Plasma has become better in that regard than XFCE in recent years.

Yes, I'm a huge fan of KDE in general. (see testing screenshots folder). KDE Plasma does benefit from being run on newer hardware, but can have proper rounded corners - depending on theme used.

OXT Lite 1.06 Linux KDE Dolphin C.png (592.88 KiB) Viewed 1768 times

[OpenXTalkPaul]

KDE Plasma (in Ubuntu Studio). which I believe is built on the Qt UI framework (and not GTK that the LC docs suggest to use), was the most stable I've used...Plasma has become better in that regard than XFCE in recent years.

Yes, I'm a huge fan of KDE in general. (see testing screenshots folder). KDE Plasma does benefit from being run on newer hardware, but can have proper rounded corners - depending on theme used.

It's subtle but with some (mac-lookalike) dark mode themes I've seen a hint of the actual window rectangle corners just outside of the rounded corners of the window shape, that could just be a poorly edited theme corner part I suppose.

So I did some testing with the window focus juggling madness tonight and found a related interesting quirk.
On a whim, from the message box I opened the Tools palette to 'drawer mode':

Code: Select all

drawer "revTools"

which, like menu stack menus, does not really work quite right, the way the used to, but it does do something...
It opens the stack without any Title bar or window frame, and to my surprise it was functional and did NOT constantly try to steal window focus! I could use the Tools palette AND type in the message box with no focus juggling!
So to test that out further:

Code: Select all

set the decorations of window "revTools" to "title,close"

Boom, window focus madness is back! Remove title bar decorations again the prolem goes away.
I can move the Tools palette by setting its topLeft from the messageBox, and the Tools option menu works fine with this mode.

So... now I'm thinking this could be a good fix... we make our IDE palettes NOT have any System window decorations at all, and instead we build our own custom palette frames that are more fully managed by the IDE and not the OS!
I think there would be other benefits beyond helping with problem Linux distros...
For palettes I always disliked that some 'modern' OSes do not have a small utility-window style frame, with a smaller title bar (like macOS7+ has had ) differentiated from a document type-style window. It's better for conserving screen real-estate for more work space. Plus it would really help if someone were to use the IDE palettes in a Mobile or Web App where there is no desktop window manager

[richmond62]

we make our IDE palettes NOT have any System window decorations at all, and instead we build our own custom palette frames that are more fully managed by the IDE and not the OS!

That would be marvellous as it would add to the 'cross-platforminess' of the IDE.

Were OXT to become an almost self-contained eco-system it might mean increased portability.

[tperry2x]

...I did some testing with the window focus juggling madness tonight and found a related interesting quirk.
On a whim, from the message box I opened the Tools palette to 'drawer mode':

Code: Select all

drawer "revTools"

It opens the stack without any Title bar or window frame, and to my surprise it was functional and did NOT constantly try to steal window focus! I could use the Tools palette AND type in the message box with no focus juggling!

I really like the idea of this. Sounds really promising. I'll have to do some experimentation later this evening

Edit: Initial test (drawer everything!!)

drawer-everything.png (336.78 KiB) Viewed 1752 times

A couple of issues come up though. The first being that if you drawer the message box, you can still click on it, but it seems to lose focus - you can't run anything you'd typed. I could get around that by including a 'run' button to the right of the single line message box field.

The other issue is that it instantly makes stacks unresizeable, for example, with the "App Browser" I have open in that screenshot, I lose the ability to resize it.

Thirdly, if I drawer the inspector window, that seems to work - but upon clicking on the active user stack, the revInspector is "undrawed" for want of a better word (I assume it's just being reloaded each time) which would make sense as to why it then doesn't have a drawer any more.

Point 4: With multiple things drawed, the answer and alert dialogs become 'pop-unders' - so that they annoyingly appear underneath other windows.

PoInt 5: How do you effectively 'minimise' a window to whatever taskbar/panel/dock you might have, when trying to do it via a button control on the stack? I ask - because we'd need a way to do this when we come to draw our replacement window controls for everything. I'd also like these to pick up on the system theme - but that's easy enough. The IDE can grab snapshots with PNG masks of whatever the controls are at IDE bootup time.

Don't see these as negatives. I'm keen to work around them, as having this draw option is the best news I've had for a long time, and I'm keen to use it.

[OpenXTalkPaul]

Edit: Initial test (drawer everything!!)
drawer-everything.png

'drawer' was just the thing that made me realize that when a window has no frame it is no longer subject to this Window manager's odd behavior. You can do that without the 'drawer' command by setting the window decorations to empty or by using a 'windowShape' (probably).

A couple of issues come up though. The first being that if you drawer the message box, you can still click on it, but it seems to lose focus - you can't run anything you'd typed. I could get around that by including a 'run' button to the right of the single line message box field.

The message box might be a special case, this may not be a total solution for some windows that need to be in a certain 'editable' mode to work.

The other issue is that it instantly makes stacks unresizeable, for example, with the "App Browser" I have open in that screenshot, I lose the ability to resize it.

That's the down-side. Window moving and resizing are the sort of thing the system's Window manager normally takes care of automagically. If when we cut the WM out of the picture by removing the window frame, then it's up to us to implement those things. But that is not too difficult to do. In fact for the Playground stack ( Emscripten engine already has no window manager available), I used Bernd Nigermann's 'Yosemite Window Maker' IDE plugin (and then tweak it a little ) to create the 'fake' window frames for the MC palettes that I put in there. I used only the top part of the frame to have something to move the palettes around by.

Thirdly, if I drawer the inspector window, that seems to work - but upon clicking on the active user stack, the revInspector is "undrawed" for want of a better word (I assume it's just being reloaded each time) which would make sense as to why it then doesn't have a drawer any more.

Point 4: With multiple things drawed, the answer and alert dialogs become 'pop-unders' - so that they annoyingly appear underneath other windows.

Hmm, I only tested doing this with Tools pal, because that seemed to be the biggest offender of the focus stealing, With 'drawer' the window seems to become a always-on-top (systemWindow) window, so there may be a better way to do this than using drawer that does not make the stack window into an always-on-top window. I'm pretty sure that when you remove a window's frame, that is what effectively cuts the System's Window Manager out of the equation. So again, maybe just set the decorations to empty (or use a windowShape).

PoInt 5: How do you effectively 'minimise' a window to whatever taskbar/panel/dock you might have, when trying to do it via a button control on the stack? I ask - because we'd need a way to do this when we come to draw our replacement window controls for everything. I'd also like these to pick up on the system theme - but that's easy enough. The IDE can grab snapshots with PNG masks of whatever the controls are at IDE bootup time.

I was thinking the IDE palettes would have their own, non-platform specific mini-frames, like just a thin bar across the top of the palette for moving and a generic sort of close-window or minimize-window buttons. But now I'm not sure if iconifyStack (minimize window command) works on Linux ( I assumed it did, but it list 'Unix' in the docs.

[OpenXTalkPaul]

we make our IDE palettes NOT have any System window decorations at all, and instead we build our own custom palette frames that are more fully managed by the IDE and not the OS!

That would be marvellous as it would add to the 'cross-platforminess' of the IDE.

Were OXT to become an almost self-contained eco-system it might mean increased portability.

Yes, I'd love that, make the IDE more portable, more fully into a self-contained Virtual Machine. I've said it before and I'll say it again, the xTalk/xCard thing is already much like a high-level abstraction of OS APIs underneath (or even in ROM), the engine is essentially a 'VM'.

If such a xTalk VM could be a bit like the SmallTalk VMs, Lively kernel (https://webpages.tuni.fi/livelykernel/l ... /index.htm) with themeable 'Morphic Windows & GUI elements, where it's almost to a point where it could be whole operating system onto itself,...I think that would be awesome, particularly in regards to survival in an ever changing computing landscape and currently tightening security sand-boxing.

WAY back in the day, I actually played around with the idea of 'HyperCard as operating system', I even created vector-art set for files, folders, apps, font suitcases, etc. and made them into a 'dings' font (called McFindRFont) and used that to render file lists in card fields. The REAL LY tricky bit is that I then made a copy of HyperCard app, and changed it's 4-CHAR Creator Code to be 'FNDR', then I replaced the actual Finder with it in a COPY of the macOS system folder on floppy (or ZIP disk), reboot to that disk and you get no Finder at all instead the OS boots directly into HyperCard! Effectively HyperCard becomes the system's 'shell' / File Manager. I did a lot of weird experiments on my mac512KE back when in 'Multi-Finder' times (System 6, but worked with Sys7 too IIRC). Pre-Multi-Finder the mac OS could only run a single program at a time (unless you count 'Desk Accessories', which were sort of mini-applets), so this makes perfect sense. Removing the Finder freed up super valuable memory (my Mac512KE originally had only 2.5 MEGABYTES of RAM, I remember paying $200 to go up to 4MB, lol).

I'd like to try something like that but with Linux kernel instead of mac System 7, I've probably mentioned before (I do recall Richard saying something like 'no one needs another Linux Distro'). Someday I'm going to spend some time really looking into building a Linux distro from the ground-up.

[tperry2x]

Someday I'm going to spend some time really looking into building a Linux distro from the ground-up.

Have you tried the LFS (Linux from scratch) information? It's not a quick read, but it is certainly comprehensive.
I've built a Linux 'distro' with just enough OS to show the current time and date. (Yes, there's a theme emerging here). I did it to work as a bootable USB which ran on a projector (32MB). (It was used during school exams to show the current date & time on a large screen, so that they knew how much time they had left running of the exam.

Looking at our 'windowing system', the minimise and maximise commands currently elude me. The IconifyStack is the message sent to the IDE when a standard window control is clicked, but there seems to be no way to actually enact that from script (I would be grateful if someone knows how, without using xDoTool as it has to work cross-platform across all 3).

I'd bundle the IDEWDTitleDraw into a function, so that it can be called when an IDE window loads (with certain windows excluded from it) - but it allows us for a themed titlebar too. (I did a neutral grey one for light/dark mode), I did an OXT Lite and OXT Heavy themed one too

Of course, this could also be customised by the user too. Don't have to use the OSX-esque buttons - it's just what I had to hand (I used my brushed-metal stack as a template).

multiple-wds.png (17.21 KiB) Viewed 1706 times

You could be as generic as you'd like:

generic.png (18.15 KiB) Viewed 1697 times

On stack resizing, I just noticed the window resizes in realtime on Linux. I don't think it does in MacOS and in Windows.
The dictionary says:

The resizeStack message is sent after the resizing is finished. This means that you cannot prevent a stack's size from being changed by trapping this message.

This is not the case on Linux - the resizeStack message is sent during the resizing, continuously, so that you can indeed trap the message on Linux to prevent the size being stretched past a certain point. (The dictionary entry is incorrect).

Here's also a version with controls, so you can turn off various buttons for window controls, and enable/disable the resizer:

generic-b.png (10.82 KiB) Viewed 1677 times

[tperry2x]

Also discovered another issue if you hide the window control buttons. (Don't know if this is the case on MacOS and Windows, yet to test it).
If I hide the built in windowmanager's (close, min, max) buttons - it has the side effect that the window cannot be dragged off the screen. By that, I mean no part of it can be dragged off the screen (off the visible screenrect).

Why does that matter? Well I was trying to fake a way of minimising the window, mainly because of this affirmation by ChatGPT:

meh.png (32.07 KiB) Viewed 1662 times

That messes me up, because I was going to send the window to some far-flung screen rect offscreen, so that it appears in the system tray / linux panel for open windows. And yet, can be clicked on to bring it back... no matter, will have to think of a plan-c...

[tperry2x]

Right, here's something that at least seems to work (tested on Linux), but I need to test on MacOS and Windows:
The minimise, maximise, resize and options are now all working as far as I can tell. I don't know how this plays with the MacOS dock. I may need some custom code to show a minimised window there. I'm saving that for another day.

wd-resizers-typeC.png (9.88 KiB) Viewed 1656 times