Tabby Cats

[richmond62]

I have been messing about with some overlays in the cardScripts:
-

Screenshot 2024-05-11 at 23.59.02.png (43.45 KiB) Viewed 1007 times

-
And windowShape does the rest.

[tperry2x]

Hmmm. Not how I wanted to do it regarding the window masking, because having to set it as an image is a bit clunky. But I suppose needs must for the benefit of MacOS users.

Your mouse buttons are the wrong way around by the way.

Screenshot_2024-05-11_22-21-14.png (95.32 KiB) Viewed 1001 times

But contrary to what it says here, I switch tabs with the right mouse button and drag the wd around with the left.

[richmond62]

Yes, I got the instructions the wrong way round.

Long day here . . .

Oh, wait a minute, I was using my left-handed ergonomic mouse.

[tperry2x]

I'm really annoyed by the blends issue. That's really thrown a spanner in the works.
That's supposed to be the benefit of using LCC/OXT - "write once, deploy anywhere". But it's more like "write once, go back and edit multiple times because of quirks here and there, try try and try again until you find a workaround to get close to what you wanted".

Anyway, here's a tweaked v5 version for anyone on MacOS

tabs-5.oxtstack

(15.03 KiB) Downloaded 70 times

tabs-5.png (226.2 KiB) Viewed 997 times

[richmond62]

write once, deploy anywhere

Quite possibly was true about 10-12 years ago.

However I can say that writing Runtime Revolution 2.0 standalones for Ubuntu 4.10 'Warty Warthog' on a Mac was, at best, well, warty; mainly because it turned out that any sound files embedded in a stack when transferred to the Ubuntu target systems played at double speed; so, imagine kids trying to learn ESL by listening to the Smurfs on Crack Cocaine: I ended up having to 'stretch' the sound files to double length so that on the Ubuntu target they would come out sounding normal.
-

dSmurf.jpg (9.01 KiB) Viewed 979 times

-
The LC people develop almost exclusively on Macintosh boxes.

I believe that 'things' cross-platform-wise have gone wonky because of a number of factors:

1. LC really didn't bother to do much re testing over on various Linux targets.

2. Apple, increasingly (possibly post Steve Jobs) didn't give a flying 'fudge' about anyone else (unless of course they wanted to develop stuff for Mac only using Apple programming interfaces so that Apple could then milk them like milking was going out of fashion).

3. The 'hiccups' that are becoming increasingly apparent cross-platform-wise are things that LC see as marginal at best.

So, although Windows seems, on the surface, to have been neglected by LC, their current offering may be best used on Windows, and only on Windows (i.e. not trying to be clever and do the 'cross-platform' thing).

[tperry2x]

A good example of that is currently some weirdness with databases. Works on Linux and Windows, but just won't work on the Mac in the same way, which I just don't know why. I can even run the entire IDE in Wine on the mac and get reliable database behavior without the errors. Just seems to be something specific to the mac engine and how it handles the connection (?)

Windows is by far from immune to these issue too. RevCopyFile is broken - raises a UAC unhandled permissions error, the titlebars of windows in the IDE to not respect the rest of the OS theme. The classic controls are drawn as Windows 7/10 ones on Windows 11...
(list)

Certainly, being cross-platform is great when it works. Otherwise it just leaves developers cross.

[richmond62]

What is obvious, despite RR/LC largely being developed on MacOS, is that one cannot state something like:

"The IDE on MacOS is the bottom line."

As some things work on MacOS that don't on Linux, and so on.

This makes things very difficult because if we had a "bottom line target" we would know in what way we had to 'trim our sails'.

Anyway, as we all should be well aware

write once, deploy anywhere

is really nothing more than a load of advertising nonsense.

I have just spent 30 minutes removing Haiku from a 'spare' PC I have (No LC version ever ran on either Haiko or BeOS), and spent another 30 minutes saying extremely rude things trying to get FreeBSD to install in a meaningful way (something I did not manage), and am now installing Devuan Daedalus with XFCE 'just because it's there'.

LC versions often 'go fudgey' on ReactOS . . .

[tperry2x]

...some things work on MacOS that don't on Linux, and so on.

And vice-versa of course, as mentioned above with the database and the fact that the to-fix-list is a lot longer on the Mac than Windows or Linux. (not saying they are necessarily easier fixes, but they are nonetheless broken). That list does look a bit daunting, but things are at least getting crossed off slowly.

[TerryL]

@ Richmond. I've read the tab panel button looks very different on Mac compared to Win and Linux.

Could you please post a side-by-side image of the same basic tab button from the three platforms for comparison? Could we make a more uniform appearance or is it an engine thing? Terry

[richmond62]

I am afraid I cannot:

1. No access to Windows.

2. Currently no access to MacOS as away from home with a Linux laptop.

[tperry2x]

tabs-comparison.png (50.19 KiB) Viewed 857 times

Please note: Linux will use whatever theme you have selected in your appearance settings.
The tabs are a 'Classic Control' so their appearance is (for want of a better word) 'emulated' under MacOS and Windows

This kind of links into something Paul was just mentioning, so I'll link that here to tie things together

[OpenXTalkPaul]

tabs-comparison.png
Please note: Linux will use whatever theme you have selected in your appearance settings.
The tabs are a 'Classic Control' so their appearance is (for want of a better word) 'emulated' under MacOS and Windows

This kind of links into something Paul was just mentioning, so I'll link that here to tie things together

As you can see here, the tab button controls do conform to some degree to which OS version 10.9 or 10.15 as far as styling the controls to the OS 'theme' . But again, macOS doesn't really have 'themes' other beyond variations on Dark/Light and user's content highlight colors), so I think there is something a little more nuanced going on in the engine below the surface. When dark mode was added with macOS 10.14 Mohave is really when the classic controls started lacking. The System fonts also changed font family around some version (maybe 10.12?).

[OpenXTalkPaul]

I think the change in that method for making an stack widow mask using a "paint mode" to punch through a window probably...
1) never should have been able to work on any platform, you don't want a paint to effect the solidity of the fill of the background window layer that the fill sits on top of. Control of the window layer 'backing store' should IMO belong to the system's Window Manager. Furthermore, having been a Photoshop user for decades now, these paint modes work close to what I would expect as far as 'darken only','exclusion', etc.
and
2) probably stopped working the that way on macOS around when Apple started to do some funky things with NSwindows 'backing store' to allow parts of a window to be backed by transparency with blur effects using NSVisualEffectvVew: https://developer.apple.com/documentati ... effectview
which is all part of Apples master plan to iOSify the macOS and syncs up with iOS's UIVisualEffectvVew:
https://www.kodeco.com/16125723-uivisua ... ng-started.
I believe Mac windows started to have this effects views with macOS 10.10 (Yosemite).

By the way, some time ago I did make an experimental XTension Builder module that creates a new NSwindow and backed with the NSVisualEffectvVew transparent blur thing just to explore how this works. It's very likely possible to take this further and apply it to our stack windows, at which point I would probably would add it to 'macOS native tools' lib, as I did with the 'Unified Titlebar' window mode (great for saving a few pixels of screen-realestate).

3) Likewise it probably stopped working on that way on Windows OS for much the same reason, when Microsoft followed Apples trend lead and introduced the 'Aero' look to Windows as seen here: https://en.wikipedia.org/wiki/Windows_A ... xample.png

I also would think that method might also cause problems on Linux if it was mixed with a something window manager such as 'Compiz' that has eye-candy compositing window effects (which I do love).

Bottom line for me is that I would avoid using that paint-mode mask method for maximum compatibility reasons.

[OpenXTalkPaul]

Since I mentioned it...
Here's that XTension Builder experiment creating an NSVisualEffectView window:
https://github.com/PaulMcClernan/OpenXT ... ffectView/
There's a screenshot in there that shows the effect (slightly):
https://github.com/PaulMcClernan/OpenXT ... Window.png
Notice the blurry transparency of the windowsill the background blending though to the front window.

[tperry2x]

I think the change in that method for making an stack widow mask using a "paint mode" to punch through a window probably never should have been able to work on any platform,

I'm not entirely convinced (see further down)

you don't want a paint to effect the solidity of the fill of the background window layer that the fill sits on top of.

You might. As a knockout mask. From what I can gather, this may have been intentional because I think that ink mode existed before the windowshape property did, so it might just be that Windowshape took over from that ink.

Control of the window layer 'backing store' should IMO belong to the system's Window Manager.

True, although there's plenty of examples of programs that modify the window manager for their own methods - Kaleidoscope on MacOS classic was a great example, and various system extensions back then that did all sorts of weird effects with the window manager (Gravite, Greg's Buttons, PowerWindows, RainbowWindows etc)... then later Kaleidoscope, then much later than that on OSX - all the haxies made by unsanity). It was around this time that messing around with the window manager was considered 'fair game', so I don't think this was unintentional at all. I remember a demo of it being used in a stack - a bit like kiosk mode on an iPad these days, so that the user couldn't interact with anything outside of the stack - but could see the desired content "through it". I definitely don't think it was unintentional.

Furthermore, having been a Photoshop user for decades now, these paint modes work close to what I would expect as far as 'darken only','exclusion', etc.

Ditto, as before I got into computer tuition, Apple, and now ICT support, - I worked for 9 years in reprographics (back with Photoshop 7 and CS1). We used to do loads of 4-colour process work with Indigo printers and offset-litho machines. We used to use Quark (and later InDesign 2.0) - the knockout options in the OXT/LCC IDE (particularly the name of this see-through ink "blendSrcOut" would imply to me that it's a blended effect, and takes the Source (the window) and knocks it Out). We used to use something like that all the time as Macromedia Freehand had the exact same colour mode back then too. And it did exactly the same thing. The idea was that you wouldn't have to sit and create clipping masks by drawing points. You could just have a new layer, filled with this ink and it would knock out things such as hair when blended alpha channels weren't a thing. (Otherwise is was a hard mask area like a transparent gif, as opposed to a transparent PNG).

probably stopped working the that way on macOS around when Apple started to do some funky things with NSwindows 'backing store' to allow parts of a window to be backed by transparency with blur effects using NSVisualEffectvVew

No doubt. I know they were a bit cheesed off with people being able to modify things to the extent they could. This is why a MacOS program called 'Flavors' was internally derided by Apple. They hated it so much, but for a while it was a game of cat-and-mouse with the developer making it work and Apple releasing patches to stop it working. They hated the fact that it could interfere with the graphics overlay layer and change the window appearance (think Kaleidoscope for MacOS 10.7). It finally died a death in 10.8 when Apple changed their rendering mode for windows, and a lot of this was to stamp out hacks like this from being possible.

By the way, some time ago I did make an experimental XTension Builder module that creates a new NSwindow and backed with the NSVisualEffectvVew transparent blur thing just to explore how this works. It's very likely possible to take this further and apply it to our stack windows, at which point I would probably would add it to 'macOS native tools' lib, as I did with the 'Unified Titlebar' window mode (great for saving a few pixels of screen-realestate).

I really like that by the way
Pretty cool effect.

Likewise it probably stopped working on that way on Windows OS for much the same reason, when Microsoft followed Apples trend lead and introduced the 'Aero' look to Windows

Yes. Do you remember for a while you could theme Windows XP to anything you wanted. Officially I mean, without any third-party programs and not by replacing various Windows shell programs in C:\Windows (which is still possible, but you have to swap components around) - which of course break after a major windows update (of which there are many).
It's all about 'cohesive branding' - that's the buzz-word they use for it. They want it to all look corporate and don't like the user to have the degree of customisation as it ends up not resembling their product. It is very frowned upon by windows devs and Microsoft - probably in exactly the same way Apple hated it too.

I also would think that method might also cause problems on Linux if it was mixed with a something window manager such as 'Compiz' that has eye-candy compositing window effects (which I do love).

I used to love Compiz. Is that still going? I thought that was completely discontinued as unsupported now?

Bottom line for me is that I would avoid using that paint-mode mask method for maximum compatibility reasons.

I have - I'm using the custom WindowShape method since discovering it was flawed (Friday the 10th or Saturday the 11th I think..), but yes - All the tabs examples after that used the windowShape method.

[OpenXTalkPaul]

Yeah, I remember even early on with Apple, macOS 7 I think, you could have custom window shapes with 1-bit masks, but IIRC that could be done with Res-Edit editing a 'WIND' resource or something like that, which the Mac Toolbox read and then use with its Window manager (originally stored in ROM I believe), this is back when 'color' typically meant 256-color swatches of colors palette, then in the early-mid-90s Apple Introduced Appearance Manager just before macOS 8 came out (which then included it) that expanded this sort of capability and allowed for custom window appearances like that cool 'dark' one and the super-goofy 'Gizmo' theme. I vaguely remember spending some time trying to making my own theme. But that was still handled by the OS window manager, basically it allowed to replace it's resources (which you could probably still do if you REALLY wanted to), including the window frame mask(s) (they're like '9-slice' images).

I'm not sure if Kaleidoscope used Appearance Manager in carbon or a different method? I also remember some themes not looking so hot when run in Mac OS X's 'classic''s in that mixed windowing mode, that would combine Carbon windows with Cocoa windows. Probably because then Quartz (which replaced Display Postscript used in NeXTStep) was handling the compositing.

Anyway, when Steve Jobs came back to be in charge I'm sure he told them to stop allowing that sort of thing. As I undertand it that was also what he didn't like about HyperCard because users could create UIs that didn't conform to having a cohesive appreance throughout the OS, admittedly there were some really bad child amateur UIs in some HyperCard stacks out there (but that's in part because its Engine was neglected for years). And yet this was around the time that everyone started using custom window shapes for MP3 player software (WinAmp,SoundJam/iTunes 1.x, etc.). I think that was really good for that soft of software. Even Adobe started using Masks in the splash screens.

I'm good with a paint mode that can make transparent regions on IT's surface, both in an window frame OR in the image's container-view layered on top of the window, but the image box sits on a layer on top of something else (the window manager created surface of the window), it's contents should not effect what's underneath it only allow it to show through it.
If the alpha 'paint' is meant to mask the window's shape, then the mask should be passed to the OS Window Manager's standard method for doing that (if it has one, I think most do). You could then have a transparent image on top of that transparent widow, the window's transparent 'hole' I suppose, but the Window manager would handles blending it (perhaps adding some effect like blur of its own). That's how I think it would work, its subjective I suppose.
My guess is that the way its sets the WindowShape uses the method for that most appropriate for the particular OS.
And at least we know that still works cross-platform (it did get a little wonky on macOS but was fixed before 9.6.3 IIRC).

Anyway, probably because our Engine is a direct decendent of MetaCard (and NOT HyperCard), and so began it's life on Unix-based OSes by Sun Micro, HP Unix, etc. It was probably originally based around XLib / X-Windows APIs, with some Display Postscript support (the reason the Engine still has an 'EPS object' control ). The Linux engine is directly related there, so I guess it makes sense that it would still work on Linux as far as X.org compatibility.

On NeXT there was another Unix xTalk, HyperSence, which abandoned the Card/Stack metaphor long ago.
That went a different path, became a scriptable 'testing suite', now called 'Egg Plant'. Still uses an xTalk.

Compiz I think became dormant years ago (not 100% certain), but I've seen the same sort of effects that can be enabled in certain Window Managers (I think KDE added 'built-in' support for similar effects, and I've seen Distros with Compiz effects already wired in (so maybe there's forks of it?).

Didn't LC go on about supporting '9 slice images' quite some time ago?
I'll have to test that out, should start a new thread to discuss that though.

[richmond62]

I am a "true believer" in windowShape insofar as I know that whatever I do with it the result in what our friends in the North term "deploy everywhere" (pause for chuckle and to remind myself I have ordered a RISCOS computer to be delivered to Mother to collect in August) means that it will behave itself 'identically' (note single quotes) on Linux, Windows, and Macintosh, while Inks/Blends can go "all smushy".

JOIN NOW! THE CHURCH OF WINDOWSHAPE!

Full-blown cult: kinky hairstyle, kinky diet, and most important of all: kinky shapes

After a short time in this cult we guarantee you'll be all bent out of, err, windowshape.

[OpenXTalkPaul]

Oh good a convert!

One last thought... taking that printing pre-press analogy further, my position is that an Ink should NOT eat through the substrate like acid. The substrate is often, not always, paper, but could be transparent plastics ).

OK I'm done.

[tperry2x]

...an Ink should NOT eat through the substrate like acid. The substrate is often, not always, paper, but could be transparent plastics ).
OK I'm done.

I wasn't going to comment. (I'm already a windowShaper). But...
You know like in screen printing? Where you use dev and fixer to retain parts of an image on a silk screen. The rest you use an acid etch to remove the parts you want the ink to show through? Exactly like that.

Okay, I'm done too

[OpenXTalkPaul]

You know like in screen printing? Where you use dev and fixer to retain parts of an image on a silk screen.

All too well... one morning decades ago, after a night out drinking, I accidentally swallowed a mouthful of fix while trying to get a pump working on an aging film processor! Reaction time too slow. My coworker was like 'fugetta bout it, the same stuff is in some salad dressings' (and I'm pretty sure he was right about that ... anyway I'm still alive).