Was I too hasty?

High again? Well - Keef.
So ... technically ...

And yea ... working with Sublime-Text in i3 isn't all that great. I mean - it's a little buggy, the tabs won't move properly from window to window sometimes. It's something with how the containers are setup. I would have to study the container tree and it's mechanisms more thoroughly. I suspect that once two windows are too far down separate trees, the WM somehow gives up or whatever.

I mean - so far I haven't ventured down that road, so ... I'm mostly just hoping for the best while vaguely remembering the shortcuts.

On Sublime's end it'd be great if they could expand their feature-set by allowing users to 'mark' certain windows. It'd make it easer for me to find which window is to contain what. I mean, in Windows I knew vaguely which file corresponded to which set - and because there weren't any issues moving tabs ... that was enough. Yet, having a specifically labeled Window ... that'd make it perfect. I mean, that's a thing I also struggled with in Windows. Like ... alt tabbing through like ... 5-10 open windows, I eventually stopped using alt-tab altogether. But it also makes managing the workspace a mess. But yea, habits and muscle memory would grow ontop of that ... and ever so often I'd just start a new mess.


Butt yea. So - only halfway there. The Libra part. Well. If I'm perfectly honest ... that was the thing I've been staring at before going on this venture; And hence, I suppose, I'm also ... still making true on the "having failed" aspect of this. So - eventually some things have to be changed still. The big problem I see now that I haven't really had on my radar before is the matter of reading out screen data to know where to place the window. Like, I want the Metabar - although that's not quite right either - to be on the left side of the screen. And somehow placing it on screen 2 doesn't work like it should while setting up fullscreen on screen 2 works. I don't know.
Is that i3 ... being like ... nope: Workspace one is on Screen 1?

Anyway. I also have noticed that SDL3 has removed that aspect. So, now you only specify height and width and let the Desktop/WM handle the rest. And ... using SDL2 so gives us more control, but it's not really ... useful much. I mean - I don't want this to end like Gimp. But it shouldn't matter as Lumberjack should have like it's own Window Manager of sorts? Which doesn't work ... if the Access Units interact with the system directly.


And so ... there's this peculiar thing now called UnitCANVAS. Anyway. So, it exists apart from the System - sortof - and is to collect ... now a different kind of frame. This one now being more specific to Libra.

Now - one issue with this system is that it's ... kindof built like an OS but also not, in the sense of how Windows work. That was my first ... let's call it 'dink' (something that eventually leads up to a facepalm moment) ... where - Window, Rendering Context, Device and all that ... they're like all solved by SDL_CreateWindow ... where, logically sometimes a Window is an SDL Window (Native Window) - while other times the Window would be an internal Window (Native Fullscreen Window / Libra GFX Frame). So, that was a bit of a ... dinky thing.
Also - screens versus Access Units. These are two separate ... 'ways'. One way is to cycle through the units and the other is to cycle through the screens. Then the question is if there's only one Unit Context to be considered per screen (Fullscreen) or if they have to be layered.

And I'm worried that this is one of those instances where ... there isn't really a middle ground.

There is however a saving grace to this. It's one of those relatively small, easy and harmless things that shouldn't be a huge problem to set up and yet I'd be staring at it like it came from outer space. So, maybe this is where I get into this stage of my work. I pick up on some idea that kind of resembles what I want here - and hope that it fits. And at a certain point of complexity, every solution that isn't a mess can look elegant and genius.

But yea. As it stands - using Create__ScreenAccess is going through a lot of functions that kind of don't do very much. It's not entirely necessary and there should be ways to boil that backend down into one function - but more to the point the Libra Unit should be taking the front row in the XS Unit, of course, as prescribed, and then we only need a language to communicate with it in a system independent way.
So, eventually something like "Primary Screen" and "Right of" or "Left of" (or above/below) has to come in, then some detachment from pixel values into a more universal and comprehensive ... grid. That's where the UnitCANVAS should do the trick.

However. There's like a special trick that I've been working on for my game - which then happened to slip into the idea of what Libra should be, so it makes sense here. And to that end I'll have to ... either help myself with some ... setup hack. I mean, I'm probably not going to work much on ... some automatic setup or config files just yet. And it makes sense that one might possibly want to hardcode their system settings into their framework. OK ... so, that's one thing to be working on.


Well. So, the idea then is to 'feed' the UnitCANVAS rather than have it be screenspace at large. The logic is that the Canvas maps the unit - which may be ... silly. Like, what do I want? Being uncertain I'd just roll with it - fill out the units and worry about the screen stuff later. Hmm ... sounds familiar.


Which means ... I'll first have to go ... see what I can do in terms of what I had on mind ... and then second guess its existence. Well.
I was thinking: Perhaps I should chill out a bit. First. Wait for my dope - I'm worried it'll take a few days. ... Hmm. Anyway. So, ... I guess ... with this said I can ... take it easy for a bit. Peace.