Xubuntu +

[richmond62]

Happy New Year . . . and if I wake up sometime after I hit the sack at a ridiculous time of night here, I'll have a look at your work.

[tperry2x]

Oh yeah!!! hahaha
Happy new year everyone.

[OpenXTalkPaul]

7 am New Years day here, I went to bed at like 12:30

Happy New Year guys!

[richmond62]

Right: let's get critical.
-

Screenshot 2025-01-01 at 14.36.17.png (41.37 KiB) Viewed 1681 times

-
Aha: so a bit of "fakey-wakey" as my younger son said when watching a man in a suit administering artificial insemination on a farm.
-
It took me a few ticks to work out that what you have done is completely ignore the "inherent" window furniture of a stack.
-

Screenshot 2025-01-01 at 14.43.25.png (104.82 KiB) Viewed 1681 times

-
So my first question is going to be:

1. How are you going to restrict access in the Properties Palette to the inherent window furniture?

1.1. Is that necessary or desirable?

Certainly, this looks a bit odd:
-

Screenshot 2025-01-01 at 14.47.28.png (101.46 KiB) Viewed 1680 times

-
and could throw an end-user right out of kilter.

[richmond62]

Screenshot 2025-01-01 at 14.37.07.png (40.42 KiB) Viewed 1679 times

-
This is odd as I expected when I deselected 'title bar' the title bar would disappear, when what did happen was that the title only disappeared.
-
All the rest of the options worked once one accepted the idea of your group + group as faux window-bar and controls at the top of the card.

Of course, anyone wanting to position objects on the card via code would have to take into account that the faux window-bar takes up "real estate" at the top of a card.
-

Screenshot 2025-01-01 at 14.53.20.png (54.38 KiB) Viewed 1678 times

-

Screenshot 2025-01-01 at 14.54.28.png (66.44 KiB) Viewed 1675 times

-
Lumpy Custard at the moment, I'm afraid.

[tperry2x]

So to address this, I've had to fake it. This is what myself and Paul have talked about above.
(I mean, there's no other way of doing it) - but it can actually just be a single group that gets created (aside from the window resizer). - so not exactly CPU intensive, and yet easy to manage. - plus an end-user can mess about with that group if they want to change the spacing between the buttons (or even the graphics of the buttons themselves) etc.
This gives us yet another advantage, since these buttons aren't customisable by the user if using standard window controls currently.

We have had to ignore completely the built in window buttons. Hence why they are hidden, and hence why they do not look like anything native to the OS at present. They are designed as replacements, not as additional buttons, so the idea is the standard OS ones won't be shown.

Having said that, the buttons could pick up on the systemversion and platform, and load in relevant window buttons to match the OS (MacOS and Windows at least). These button images can be kept in the revIcons stack (along with the rest).

The inspector palette needs redoing anyway.
My idea is a revised inspector would do the same things these buttons on the card do presently.

So, I propose either building these buttons into the inspector, or changing the inspector accordingly (keeping the drop-down list) - yet always hiding the OS window titlebar, and faux-faking them. The questions is how this would work on a standalone. I'm assuming it would, as long as the stack was told to set the decorations of this stack to none. (so you don't end up with a double titlebar like you'd turned back on via the inspector in your screenshot).

These control buttons are only placed on the card because the inspector currently lacks them

[tperry2x]

All the rest of the options worked once one accepted the idea of your group + group as faux window-bar and controls at the top of the card.

Jolly good. Thanks for testing.

Of course, anyone wanting to position objects on the card via code would have to take into account that the faux window-bar takes up "real estate" at the top of a card.

True, but this is easily remedied by always ensuring that group is the topmost.
It actually gives us an advantage, in as much as it can be customised further. And 0 is 0 on every OS. (MacOS measures 0 coordinate differently than Windows or Linux). Not just that, but you can choose to hide that grey drag bar and you can also choose to hide the window title.

Lumpy Custard at the moment, I'm afraid.

I will heat up and stir more, so it's not lumpy. Eventually, the idea is you won't think twice about eating the custard. I think Paul's idea of hiding the window decorations is sound, if it means it deals with focus issues, and optionally (if we don't try and copy the window graphics of the underlying OS) it also allows us to have a unified theme across all platforms. (like Godot for example, where that IDE uses it's own theme)

[richmond62]

you won't think twice about eating the custard

Having had the dubious benefits of attending one state school (aged 5 to 11) and 3 private schools, and in all 4 the "privilege" of having to eat school custard (and, in the last private school case the "privilege" of sleeping in a dehumanising dormitory of 48 beds with ancient horsehair mattresses); you will NEVER get me to eat custard.

Just thinking about school custard makes my gorge !@#$%^.

BUT, as you may have already worked out, 'Lumpy Custard' in the context of your work is 100% metaphorical.

a unified theme across all platforms

Is a wonderful and admirable goal!

Just so long as no custard is involved.

[richmond62]

Screenshot 2025-01-01 at 15.32.32.png (65.02 KiB) Viewed 1653 times

-
You are under NO obligations to retain the 'custardy' graphic object present in this stack.

[tperry2x]

That's all good. I've changed it slightly so that if a user wants to hide the window's title text, yet keep the dragbar - they can.

In my view, the window controls should remain if they are disabled (and should simply be disabled). The way that they currently work on MacOS and Linux on the native window manager - in as much as the buttons are then always in the same place - just dimmed. (saves a user hitting the wrong button if they aren't paying attention).

wd-test-D.png (12.56 KiB) Viewed 1649 times

wd-test-D-light.png (12.16 KiB) Viewed 1627 times

wd-test-D.oxtstack

(16.86 KiB) Downloaded 59 times

The custard is now runny, in as much as the faux controls now come to the front:

custard.png (14.91 KiB) Viewed 1636 times

If anyone is wondering, the light and dark mode requires no scripting here, because it's automatic - being linux and being inherited from the system theme.

[richmond62]

I do feel that the CONTRAST between you ENABLED and DISABLED blobs is insufficient:
-

furniture.png (52.04 KiB) Viewed 1617 times

-
That does NOT mean I am advocating faux Apple blobs, just calling for more marked contrast.
-

yours.png (82.75 KiB) Viewed 1616 times

-
Ubuntu blobs:
-

Screenshot 2025-01-01 at 17.45.07.png (32.93 KiB) Viewed 1615 times

[richmond62]

Screenshot 2025-01-01 at 18.29.05.png (76.43 KiB) Viewed 1607 times

-
Buttons at top-left are Non-Functional.

[tperry2x]

I do feel that the CONTRAST between you ENABLED and DISABLED blobs is insufficient:
That does NOT mean I am advocating faux Apple blobs, just calling for more marked contrast.

Now the difference between enabled and disabled buttons is clearer:

wd-test-E.png (13.38 KiB) Viewed 1605 times

Edit: Paul had also asked for a mini version, for small palettes:

mini.png (12.03 KiB) Viewed 1598 times

[richmond62]

Giving your 3 images an outerGlow makes quite a difference:
-

Screenshot 2025-01-01 at 19.19.36.png (42.39 KiB) Viewed 1603 times

-

Screenshot 2025-01-01 at 19.21.09.png (42.85 KiB) Viewed 1603 times

-

Screenshot 2025-01-01 at 19.21.54.png (40.48 KiB) Viewed 1602 times

-
Quite why your stack contains 7 graphics called "custard" escapes me.

[tperry2x]

Quite why your stack contains 7 graphics called "custard" escapes me.

I'm trying to convert you!

[richmond62]

Mind you, tapioca was even worse.

https://kidsofthe50sand60s.com/2016/03/ ... d-they-go/
-

frogsSpawn.jpg (93.89 KiB) Viewed 1588 times

[OpenXTalkPaul]

Window Commands
____________________________________________________________
open stack
modal stack
modeless stack
topLevel stack
palette stack
option stack
pulldown stack
popup {stack | button} [at location]
drawer stack {[at] left | bottom | right} [{of | in} parentStack] [aligned [to] {left | right | top | bottom | center}]
sheet stack -- sheet stack "revTools" in stack "revMenuBar"
compact stack "Untitled 1"
go [{visible | invisible}] [to] card [of stack] [{as mode |in [a] new window|in window}]

mobilePick & mobilePickDate are mobile only but are like Oracle Media Objects 'pickList' or similar (old) desktop UI list-pick dialog windows
mobilePick optionList1, initialIndex1 [, optionList2, initialIndex2 ...] [, style ] [, button] [, view]
mobilePickDate [style] [, current] [, start] [, end] [, step] [, buttons]

Window related Properties
____________________________________________________________

set the windowManagerPlace to {true | false}
set the raisePalettes to {true | false}
set the hidePalettes to {true | false}
set the raiseWindows to {true | false}
set the windowBoundingRect to left, top, right, bottom
set the longWindowTitles to {true | false}
set the documentFilename of stack to filename
set the destroyWindow of stack to {true | false}
set the destroyStack of stack to {true | false}

set the style of a {stack|window} to ...o ne of the following:
"topLevel": editable window
"modeless": modeless dialog box, cannot be edited, can use only Browse tool
"modal": modal dialog box, can use only Browse tool
"palette": palette window, cannot be resized or edited, can use only Browse tool
set the decorations of stack to {controlList|WDEF|default|empty}--"title,minimize,maximize,close,menu,system,noShadow,metal"
set the iconic of stack to {true | false} ----- Minimizes Window, BUT ONLY if window has 'minimize' decoration
set the startupIconic of stack to {true | false}
set the systemWindow of stack to {true | false}
set the windowShape of stack to {imageID | 0}
set the maskPixmapID of image to {empty | windowID}
set the closeBox of stack to {true | false}
set the minimizeBox of stack to {true | false}
set the zoomBox of stack to {true | false}
set the resizable of stack to {true | false}
set the userModify to {true | false} -- no effect, for hypercard 'compatibility'
set the cantModify to {true | false}
set the cantAbort of stack to {true | false}
set the cantDelete of {card | group | stack} to {true | false}
set the modifiedMark of stack to {true | false}
set the ignoreMouseEvents of stack "Notification" to true
set the draggable of stack to {true | false}
set the dynamicPaths of stack to {true | false} -- may be sort-of related
set the fullscreen of stack to { true | false }
set the scaleFactor of stack to percentageOfSize
set the acceleratedRendering of stack to { true | false }
set the alwaysBuffer of {stack | image | player} to {true | false}
put the screen of stack
set the metal of this stack to {true | false} -- DEPRECATED since LC v6.7, was a mac-only style anyway
set the liveResizing of stack to {true | false} -- DEPRECATED since LC v8

get the mode of stack:
Use the mode property to determine how the user can interact with the stack.
Mode 0: closed but loaded - stack window is closed, but the stack is still in memory, has this mode if its destroyStack property is set to false and the stack has been opened, then closed.
Mode 1: editable window - opened and displayed in an editable window, has this mode if its style is "topLevel" or if it was opened with the topLevel command.
Mode 2: non-editable window - opened and displayed in a normal window, but is not editable. A stack has this mode if its style is "topLevel" or if it was opened with the topLevel command, and the stack's cantModify property is set to true.
Mode 3: modeless dialog - opened and displayed as a modeless dialog box. A stack has this mode if its style is "modeless" or if it was opened with the modeless command
Mode 4: palette opened and displayed as a palette. A stack has this mode if its style is "palette" or if it was opened with the palette command.
Mode 5: modal dialog - opened and displayed as a modal dialog box, has this mode if its style is "modal" or if it was opened with the modal command.
Mode 6: sheet- opened and displayed as a sheet, has this mode if it was opened with the sheet command. (If the sheet command was used on a platform other than OS X, the stack is displayed as a modal dialog box instead of a sheet. In this case, its mode is 5.)
Mode 7: pulldown stack menu - opened and displayed as a pulldown menu, has this mode if it was opened with the pulldown command, or if it is the menuStack of a button whose style is set to "menu" and whose menuMode is set to pulldown.
Mode 8: popup stack menu - opened and displayed as a popup menu, has this mode if it was opened with the popup command, or if it is the menuStack of a button whose style is set to "menu" and whose menuMode is set to "popup".
Mode 9: option stack menu - opened and displayed as an option menu, has this mode if it is the menuStack of a button whose style is set to "menu" and whose menuMode is set to "option".
Mode 10: submenu in a stack menu - opened and displayed as a cascading menu, has this mode if it is the menuStack of a button whose style is set to "menu" and whose menuMode is set to "cascade".
Mode 11: combo box stack menu - opened and displayed as a combo box, has this mode if it is the menuStack of a button whose style is set to "menu" and whose menuMode is set to "comboBox".
Mode 12: collapsed - opened but has been collapsed (Mac OS), iconified (Unix), or minimized (Windows).
Mode 13: drawer - opened as a drawer beside another window. Stack has this mode if it was opened with drawer command.

If two stacks with different modes are open, the stack whose mode property is lower takes precedence when determining which stack is the topStack. This means, for example, that menu items (such as 'Object → Stack Properties') that act on the current stack may not be able to operate correctly with a stack whose cantModify is set to true (and whose mode is therefore 2) as long as another, modifiable stack (mode equal to 1) is open.

Related IDE handlers
____________________________________________________________
revIDEEditableStacks()
revIDEStackIsIDEStack( pLongIDofStack )
revIDEStackNameIsIDEStack("revTools") -- returns true, revIDEStackNameIsIDEStack("Tools") = false

revChangeWindowSize newWidth, newHeight [, anim [, cardNumber [, totalTime]]]

[OpenXTalkPaul]

to 'minimize' a stack's window that does not have any decorations it must first be given the appropriate decorations:
in the message box:

Code: Select all

lock screen; topLevel stack "revTools";set the iconic of stack "revTools" to true

[tperry2x]

to 'minimize' a stack's window that does not have any decorations it must first be given the appropriate decorations:
in the message box:

Code: Select all

lock screen; topLevel stack "revTools";set the iconic of stack "revTools" to true

Thank you Paul, that's very helpful - and seems to work a lot better:

minimise.gif (225.94 KiB) Viewed 1553 times

wd-test-F.oxtstack

(16.15 KiB) Downloaded 57 times

Edit: Ah, not quite as simple. Just tested on OSX 10.9 > MacOS 10.15.
MacOS and Windows behave a little differently.
On MacOS, If I minimise the stack like in my demo video above, purely using your script above Paul, I have found the stack can randomly reappear. It seems to pop back up at random sometimes, so I have a conditional handler to detect the platform, and if it's mac, run my stack hiding handler AFTER the minimise is done. This seems to work as a two-pronged approach. The other issue on MacOS, is because MacOS doesn't have a window list panel (like Linux or Windows), you have to go to the "Window Menu", choose another stack (such as "Tools", then choose the stack again with the faux window buttons in to get it to reappear). I'm wondering if I can use one of your plugins here Paul for MacOS, in some way - so a mini-version of the window appears in the MacOS dock somehow?

On Windows, it does minimise the same way as on Linux (stays minimised), however it minimises to the system tray area (with small icons) - not into the taskbar, so you again have to use that "Window" list menu to toggle to another stack, then choose the stack with the faux buttons again to get it to appear.

I also found a bug on Windows (Microsoft Windows I mean) where the maximised window is positioned incorrectly (windows 10), so have put in a conditional fix to remedy that too.

Now I just have to look at the revMenubuilder stack and find out how it moves the stack content downward to accommodate an in-stack menu on Windows and Linux. My thinking was to see how it does it, as I'll need to do the same to add the faux window buttons to stacks.

[OpenXTalkPaul]

Of course, anyone wanting to position objects on the card via code would have to take into account that the faux window-bar takes up "real estate" at the top of a card.

This is true, but it's also becoming somewhat common for 'utility' or 'HUD' style windows to have custom 'symbolic' ('material design' sort of 1-color SVG icons) button controls mixed in with what was traditionally (window manager controlled) the 'title bar' area of a window.

In recent macOS versions there is a NSWindow property 'unified titlebar' that basically puts the buttons and title into an overlay (or is it underlay?) in a windows content area, but not restricting othr content from being added in that area. I included a handler in 'macOS Native Tools' extension so you can try it out (from it's included demo stack) if you're on macOS (10.14+, I think). If you're using that window style option you, the programmer, are responsible for ensuring you do not overlap your content with the title bar / decorations (that's Apple's programming not mine). In my opinion it's worth the minor trouble to reclaim about 22-24 pixels of screen real-estate.

I don't think it's very different than when 'menu groups' are created inline in a stack window's content area (with the exception of macOS normally having menus as part of the system's global menu, but even that can also be changed via engine property).