Nu fick jag ju lite press på mig att faktiskt visa upp något, så här kommer den hemliga funktion 3 (det kommer att bli ett antiklimax för dom flesta tror jag) Skrev att funktion 3 var påväg i mitt förra inlägg: Att utveckla en fönsterhanterare till Linux & nu har jag suttit & knåpat lite på den Så funktion 3 är en inbakad version av HTCondor, eller ja, snarlikt koncept, dock kör jag utan schemaläggare eller kö, allt körs "live", ej distribuerat/klustrat (än), en dator åt gången per process nöjer jag mig med just nu. Man kan också beskriva den som "x11vnc" fast utan vnc delen & bara input injection delen, jag är en flitig användare av x11vnc MEN mitt stora problem är att ifall jag använder lösningar baserad på frambuffer så funkar det skitdåligt då jag ofta sitter på 4g & 3g uppkoppling med väldigt tvivelaktig uppkoppling & begränsad bandbredd, då är det inte så roligt att hålla på & polla från en framebuffer & slösa bort den lilla bandbredden man har & eftersom x11vnc ändå implementerar en injection lösning för input så varför skicka framebuffer när man lika gärna kan köra hela fönstret lokalt & bara skicka kommandona till remote datorn som kör den relevanta processen ändå? Det blir mycket "billigare" bandbreddmässigt att bara dela input + data (return från remote process) istället för framebuffer Funktion #3 hör ihop med funktion #2, all data är delad mellan alla datorer (om inte data-policyn säger annat men då får man hålla koll på att den processen man kör inte använder osyncad data, rörigt förklarat, går in mer på policy i framtiden), detta gör att alla "remote" processer körs lokalt men kan flyttas mellan vilken dator som helst, det spelar egentligen ingen roll på vilken dator en process körs på, processen går att nå från vilken dator som helst (hade ju underlättat om man kunde använda samma PID på alla datorer så man slipper mappa olika PID som är "samma" process mellan dom olika datorerna, har någon en lösning på att tvinga fram en PID så säg till) Så kör jag ett program lokalt, tex "Writer" så fungerar allt precis som det gör på alla datorsystem, programmet öppnas & startar diverse processer. Medan programmet körs kan jag välja att programmet skall köras på en annan dator i nätverket, all data från processen sparas i ett "middleware", sen spawnas (eller använder en befintlig process om den finns tillgänglig & "tom") en likvärdig process på remote host:en (en annan dator i nätverket alltså), den nya processen mappas till den processen som sparades (middleware agerar som en translator mellan olika men samma process (hur illa förklarar jag egentligen? )) & därefter kopieras all process data till denna nya processen på remote host:en. X öppnar inget fönster på remote host:en utan endast en dolt process då ett fönster inte behövs, detta är som sagt ingen VNC lösning Förväxla inte detta med X över nätverk heller, inte samma sak Därefter skickas all interaktion med det lokala fönstret till remote processen (fönstret körs fortfarande lokalt till skillnad från VNC lösningar men skickar viss userinput (ej musrörelser & endast interaktion med GUI:t som resulterar i ny data) till den externa datorns process & därmed kan den externa datorns processorkraft användas istället) (Liten demonstrations-film, filmen är rätt suddig, körde skräpet i en VM på macOS där jag kör en skalad upplösning, glömde av att ändra, så macOS skapar någon obskyr upplösning för att visa 1920xXXXX, så när jag spelade in skärmen via macOS så blev filmen i upplösningen 3686x2304 såååååå, jag, det blev som blev, hoppas det är okej, spelade in typ 10ggr innan skiten slutade krascha så vill inte göra om) Edit igen: I filmen nämnde jag (tror det var denna jag nämnde det i) att webbläsaren också går att köra remote, det stämmer inte riktigt, det GÅR men det är för tillfället inte användbart, kör man remote så går det inte klicka på länkar, har inget sätt att få tillgång till länkarna & skicka data emellan processerna, i mina egna program skickas datan till remote-processer vid UI:event, men skit samma, man kör inte webbläsare remote ändå, eller jag har inte kommit på någon vettig anledning att göra det iaf Varför? Enkla svaret är lätt tillgång till andra datorer i nätverket, istället för VNC, SSH eller andra lösningar, förenklad delning av data. Tex jag jobbar ofta på min bärbara som går på knäna när jag kompilerar stora projekt, här är det superenkelt att flytta över kompileringen till en annan dator i nätverket så jag kan jobba vidare lokalt utan att störas av resurserna kompileringen kräver Encoding är ett annat svar, eftersom all lagring är syncad (med den policyn jag kör nu) så är det lätt att dela upp jobb mellan dom datorerna man har tillgänglig om man vill, finns ju andra (bättre) lösningar som är klustrade, tex Compressor & jag tror Adobe också har något liknande, men licenskostnad & ibland krånglig setup osv, man kan komma undan med att bara skicka iväg lite ffmpeg jobb istället Andra saker när den lokala datorn inte har resurser nog (få CPU kärnor & för lite ram), kör det remote på en biffigare dator istället Till skillnad från VNC lösningar såsom x11vnc så kopplar man inte upp sig till ett remote fönster utan man kan flytta en process mellan alla datorer man har tillgängliga, programmen är alltså INTE låst till en dator på sättet som VNC lösningar används till Tusen andra användningsområden (visar lite andra exempel såfort jag knåpat ihop lite relevantare program). Många (alla) användningsområden finns det redan lösningar på men har alltid viljat ha det inbakat direkt i OS:et Känns som jag behöver gå igenom systemet mer genomgående framöver, tror inte jag förmedlade dess styrkor tillräckligt bra i detta inlägget

Har kört Linux lite av & till dom senate 15 åren, lite hat-kärlek, senaste åren har jag dock börjat köra det lite mer & framförallt börjat gilla tiled-WM såsom i3 & bspwm & är numera inte jättelångt från att köra dom som main, kör mestadels Ubuntu + i3 nuförtiden (utöver macOS då) Jag har 3 funktioner som jag ända från det att jag upptäckte Linux första gången till dagens datum hela tiden har hoppats på att någon skulle implementera men verkar inte som om någon kommer göra det, så dags att kavla upp armarna & utveckla dessa på egen hand istället Kommer bara utveckla fönsterhanteraren i Debian & kommer bara se till Debian distros stöds då det i princip bara är dessa jag använder men bör vara kompatibelt med det mesta, får se Funktion 1: En slags "Viewport scroll" så ens arbetsyta består av en virtuell yta som är bredare än skärmen man använder, så, när man sitter på en liten skärm, tex på en bärbar så kan man placera sina program/fönster sida vid sida på samma sätt som med en ultrawide skärm, sen antingen använda tangentbords-genvägar eller trackpad för att scrolla i sidled. Man kan också placera dessa strategiskt så man, hmm, ser mer än vad man ser när man glor på en statisk skärm, går inte förklara, kanske syns på videorna, eller får nog göra en separat film för att förklara, men går öka sin produktivitet om man lägger upp sina fönster med lite tanke bakom...aja Jag är medveten om att detta inte är något som många är ute efter, kanske t.om ser krångligt ut & saknar funktion, men när jag arbetat med det så tycker jag det fungerat smidigt, tex när man har flera dokumentationer öppna & flera IDE fönster öppna samtidigt, slipper man öppna massa tabbar å skit, bara att hoppa mellan fönstrena istället & slipper man ha flera fönster stackade ovanpå varandra också Tiled med gaps (trasig margin dock, skall fixas) "Exposé" liknande funktion där man ser en överblick över hela sitt virtuella område, virtuella ytan är 10ggr bredare än skärmens fysiska upplösning, finns "Spaces"/"Workspaces" också så 10ggr bredare per "workspace", så ganska mycket yta att placera sitt skräp på, får att få plats med dessa fönster som demonstreras här med ett mer traditionellt upplägg så skulle man behöva lägga alla fönster ovanpå varandra, mycket lättare (när jag testat iaf) att komma åt det man vill komma åt när inte allt skräpa är staplat på varandra...svårt att göra det rättvisa på bild & video men sidoscrollen är faktiskt ganska smidigt. (nej, trackpad är inte ett krav, bara att tabba fram till sitt fönster, klicka på app ikonerna i "menubar":en längst upp i mitten eller scrolla med tangentbordet) Funktion 2: Kommer inte beskriva den i text här, gjorde en video tidigare idag (skitdåligt filmat, hatar min röst, tror min röst hörs, satte ljudet på mute när jag redigerade filmen då jag hatar att höra min röst men antar att filmen har ljud, låter skitlöjlig & hatar att vara med på film så själva demonstrationen är inte direkt imponerande men tror det framgår rätt tydligt vad funktionen är ändå) Detta är en funktion som jag sett fram emot VÄLDIGT länge, jag skiftar dator flera gånger per dag & hatar att synka GIT, positionera fönster & skit, jag vill bara sätta mig framför datorn & börja precis där jag slutade, oavsett vilken dator jag för tillfället använder Hatar att höra min röst :S Funktion 3: Lite hemlig just nu, håller på & utvecklar den nu men hoppas kunna visa upp ett demo om ett par veckor Framtiden & mini FAQ: Beror lite på, om någon här ens är intresserad av denna projektloggen, tänkte att folk som är intresserade också kunde komma på någon idé eller förslag; något ni saknar i operativsystemet/skrivbordsmiljön/fönsterhanteraren ni använder nu så säg gärna till så får vi se om den går att implementera Ni kanske också tänker att "Fan, *suck*, ännu en fönsterhanterare", & ja, jag håller med, för tillfället kommer jag fortsätta utveckla denna skrivbordsmiljön/fönsterhanteraren men det är bara för att testa lite olika idéer, se om det fungerar som det är tänkt så till en början kommer det vara en egen fönsterhanterare, dock hoppas jag, när denna börjar bli klar kunna implementera åtminstone funktion 1 & 2 i i3 istället, har kollat i i3 dokumentationen & det kan vara svårt att implementera dessa funktioner, speciellt funktion 2 då det inte är helt uppenbart hur man skall plocka ut datan från programmen men förhoppningsvis går det att lösa på något sätt, vi får se! Kommer inte lägga upp detta projektet på github (eller liknande) eller dela med mig av koden nu till en början (har gjort det på tidigare projekt & trots att jag säger till personer upprepade gånger att koden inte ens har alfa-status & jag inte kommer agera support så dyker det upp massa folk ändå & tjatar om support & annat skräp, sen klagar på när det inte fungerar & hur instabilt det är (no shit, det är ju inte ens avsett att användas annat än som experiment), har inte tid med det). Kanske om några månader när jag fixat en lättare installations-process kan jag nog dela med mig koden & lägga upp på GIT, men då krävs det att personen förstår vad detta projektet är, kommer aldrig vara avsett att köras på sin main & kommer inte ha någon support överhuvudtaget, detta är mest ett experiment & hobby För tillfället är detta tiling + float. Tanken är att aldrig behöva använda mus men självklart går det om man vill Varför? Kul grej bara, skönt att ha ett avbrott mellan dom mer seriösare grejerna man utvecklar, har börjat störa mig på hur tungrodda många operativsystem/fönsterhanterare är nuförtiden, känns bara ivägen & skapar frustration, kommer fokusera mest på att underlätta för oss programmerare så detta kommer bli en fönsterhanterare för programmerare & folk som skriver mycket Tidsplan? Ett evighetsprojekt antagligen, detta handlar om år. Detta kommer inte vara något jag jobbar fulltid med så kommer fokusera mest på dom projektet som ger mig tak över huvudet & mat för dagen, vilket detta projektet inte göra. Men kommer åtminstone försöka få till synbara uppdaterar minst 1 ggr i veckan