OpenXTalk Forums

I don't want to discourage the current direction of your experiments but.. I was thinking this would be used for IDE windows that are problematic (at least with XFCE or problematic Linux window managers), rather than replacing all stack windows decorations with custom ones by default (alhough there can certainly be some advantages to doing that). This is after all (so far) only a window focusing problem on Linux distros using certain components, and for mobile and web where there is no traditional window manager. My default is to not fix something if it isn't broken.

OpenXTalkPaul wrote: ↑Wed Jan 01, 2025 10:25 pm This is after all (so far) only a window focusing problem on Linux distros using certain components, and for mobile and web where there is no traditional window manager. My default is to not fix something if it isn't broken.

I know exactly what you mean, however I'd really like a unified appearance between Linux, Windows, and MacOS as much as possible. As you know, I've always been aiming for that.

My latest idea is to not have the minimise actually minimise to any system tray, dock, panel, [other windowmanager method] - as they are all different, but instead - have the minimised window appear as a vertical tab on the right-hand of the screen like so:
Then you'd click it to restore.

tperry2x wrote: ↑Wed Jan 01, 2025 11:14 pm I'd really like a unified appearance between Linux, Windows, and MacOS as much as possible. As you know, I've always been aiming for that.

My latest idea is to not have the minimise actually minimise to any system tray, dock, panel, [other windowmanager method] - as they are all different, but instead - have the minimised window appear as a vertical tab on the right-hand of the screen like so:

or-this.png

Then you'd click it to restore.

hah, that's cool, reminds me of the old macOS classic window 'tabs' that were folder windows transformed into folder 'tabs' along the bottom of the screen (I think there was a 3d part thing that did them vertically along either side of the screen.

I was thinking for IDE Palettes I would want them to hide themselves away when the IDE is not the foreground app, and they would not be listed in a window listing things (like Dock or Panel), like with raisePalettes = true, they should act like they're linked together part of a single layer.

It would be really cool to have a built-in 'Dock', specially for mobile or web stacks where there is no system.

I would also like consistency in GUI across platforms, and yes the custom decorations could support different themes that match the OS theme. I also like apps that take advantage of OS provided features (like with macOS Dock there can be custom badge/labels, tile-images, dock-menus.

OpenXTalkPaul wrote: ↑Thu Jan 02, 2025 12:00 am It would be really cool to have a built-in 'Dock', specially for mobile or web stacks where there is no system.

I would also like consistency in GUI across platforms, and yes the custom decorations could support different themes that match the OS theme.

Yes, that's what I was thinking.
Although this does add extra complication, as in - that faux minimise button method is fine in a stack when it's in the IDE. But what about when it's a standalone? - When you make a standalone app / program, the minimise method probably needs to revert to the standard method (as in, minimise the same way other programs do - so that a standalone minimises the same as other programs)...

Nothing is ever simple. I still think it's worth looking at though.
I think my approach will be the following:

• I'll work on methods to make the faux-minimise button work as expected, so that you don't have to search for a minimised stack in the "window" menu (MacOS and Windows)

• I'll add the vertical 'tab manager' to the IDE (again, as an option) - so none of this is set in stone, and people can turn the ability to use tabbed minimised windows on or off as they want.

edit: now have minimising on Microsoft Windows and MacOS minimising, not natively, but in-IDE tab method.

Of course I wonder if some sort of bug report to Ubuntu/Xubuntu central might help.

https://help.ubuntu.com/community/Repor ... nchpad.net

Of course this depends on whether you are:

1. "Just" doing what you're doing because Ubuntu/Xubuntu decided to play 'silly buggers' with OXT Lite.

or

2. You are using this event as a justification to attempt something more global.

If you find that #2 is too much of an uphill struggle . . .

richmond62 wrote: ↑Thu Jan 02, 2025 11:44 am "Just" doing what you're doing because Ubuntu/Xubuntu decided to play 'silly buggers' with OXT Lite.
or
You are using this event as a justification to attempt something more global.

A bit of both. The silly window issues with 'buntus at the moment are what caused me to look at this, however I've wanted a unified IDE for a long time. (This also deals with the issues with the wrong colour window titles in the IDE in Microsoft Windows - when set to dark mode) -- which I was going on about ages ago.

This version , makes vertical window tabs when the window is minimised. Tested this version on MacOS and Windows, which made me find some more issues...

Having just inflicted some more headaches on myself by testing on Windows and MacOS, I'm now up to version H.
It at least works the same on all three platforms (yay!) I forgot about the MacOS menubar offset for one! Not sure where that small black line is creeping in from, but that's the only real fly-in-the-ointment between all three platforms at the moment So, with version H, I now have something that works as a 'window manager' on Linux, Windows and MacOS.

Just made a standalone with these faux window decorations, and can confirm it's working well there too.

Edit: something else I just did was to rename the objects so a user has less chance of picking these names (so they don't conflict) - but my idea is these wd controls will be included in a new stack anyway if turned on, so that's not such an issue. (just trying to make sure I try and cover everything)...

I also just realised there's no toggle for the resize control, so added that too: I've moved all the scripting that the user would immediately see, out of the card.
So now, my focus turns to the revMenubar to see how it enlarges the stack, (although I have an idea of how to do this...)

This just adds (or subtracts, depending on button choice), 25px from the top edge of the stack and moves all items accordingly across all cards.
I thought I could use it when toggling space in stacks for the faux-window-controls. (The idea is it'll be a toggle in the prefs) if that makes sense.
And, so to follow on from that - this stack demonstrates how the faux controls could be toggled: