Fókusz sorrend (tab index order) GTK3 vs. GTK4

GTK3:

Egy GList-be felveszed a widgeteket abban a sorrendbe, amelyben a fókuszsorrendet szeretnéd, és meghívod a listára a gtk_container_set_focus_chain függvényt:

GList *widget_list = NULL;
widget_list = g_list_append(widget_list, desc_field);
widget_list = g_list_append(widget_list, name_field);
widget_list = g_list_append(widget_list, pwd_field);
gtk_container_set_focus_chain(GTK_CONTAINER(new_row->view), widget_list);

Ez eddig szuper, csakhogy GTK 3.24-től a gtk_container_set_focus deprecated.

Hogy oldod meg GTK4-ben?

Csinálsz egy eseménykezelőt minden egyes widgethez, amiben megnézed, honnan jött a fókusz, majd focus_out_event hatására továbbadod a következő widgetnek. Én értem, hogy megváltozott a layout management (vagy mi), és most már minden widget (lehet) egyben container is, de azért erre jó lett volna valami épkézláb megoldás. Vagy hogy kell az ilyet szépen megoldani GTK4-ben?
Ahogy látom nem én vagyok az első, aki reklamál miatta [1] [2].

( asch v | 2022. 03. 31., cs – 11:01 )

Sajnos segíteni nem tudok csak annyit jegyeznék meg, hogy nem is volt olyan régen amikor még a GTK2-t sírtuk vissza. Már a nosztalgia sem a régi :-)

Mondjuk azt erős kijelentés levonni ennyiből, hogy „még rosszabb”. Igen, ez kellemetlen, de máshol is van bőven wtf. Azzal a tapasztalattal mondom ezt, hogy kódoltam Gtk 2.x-ben, 3.x-ben és Qt-ban.

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

ennyiből

"Ennyiből", lol. Mert ez "csak" "ennyi". Igaz, hogy OP szerint ekkora baromság még a GTK3-ban sem volt, de hát "ennyiből" - hogy egy teljesen alap dolgot, ami eddig működött, sikerült úgy "átszervezni", hogy ennél agyhalottabb megoldást keresve sem lehetett volna találni rá - nem lehet levonni, hogy ez még rosszabb. Én kérek elnézést.

Oldschool Computer - http://oscomp.hu

Ismered a GTK+? Használtad már programozásra? Megnézted, hogy ez miért alakult így? Amúgy szerintem is kellemetlen ez, de egyetlen dologból nem vonhatsz le következtetést az egész projektre.

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

Ismered a GTK+? Használtad már programozásra?

Hallod, nem...

Megnézted, hogy ez miért alakult így?

Mert a gnómosok "interface nácik" és ideológiák mentén fejlesztenek. Ez mindig is így volt.

Amúgy szerintem is kellemetlen ez, de egyetlen dologból nem vonhatsz le következtetést az egész projektre.

Nem egyetlen dologból vontam le, hanem az elmúlt évek tendenciájának ismeretéből, meg ebből a facepalm-deluxe kategóriás interface-redesign-ból, de nyugodtan levonhatnék következtetést egyetlen dologból is. Ki tiltja meg?

Oldschool Computer - http://oscomp.hu

Az Gnome, ez meg GTK. Azért a kettő nem ugyanaz, még ha kéz a kézben járnak is, és nagy az átfedés a fejlesztők közt. A GTK javára legyen mondva, hogy azért eléggé ügyeltek a visszamenőleges kompatibilitásra. Vannak olyan 15-20 éves kódok, amik a mai napig változtatás nélkül vagy minimális változtatással lefutnak.

A gtk_container_set_focus_chain esetében az a fura, hogy csak úgy elvágták a dolgot, mindenféle alternatíva nélkül úgy, hogy még a 3 to 4 migrációs doksiban sem írnak róla egy árva karaktert sem, és az API referenciában sincs róla semmi. Az is érdekes lesz, amikor majd a Cinnamon és az Xfce átáll GTK4-re, mert a menubarral kapcsolatos widgetek is megszűntek, csak a popover marad. Cinnamonék implementálhatnak saját menü widgetet.

Hogy a Gnome milyen design döntéseket hoz, az megint más kérdés. Egy részük szerintem teljesen jó, de vannak olyanok, amik érthetetlenek és értelmetlenek. Például, hosszú viták voltak arról, hogy lehetne egy váltógombot tenni a Nautilusba és a FileChooserDialog-ba, amivel lehetne váltani a kattintható path bar és a beírható location bar között. Ez a vita is el lett kaszálva, és azóta sincs a felületre kivezetett megoldás, úgyhogy marad a Ctrl-L, ami nem túl intuitív.

A GTK javára legyen mondva, hogy azért eléggé ügyeltek a visszamenőleges kompatibilitásra. Vannak olyan 15-20 éves kódok, amik a mai napig változtatás nélkül vagy minimális változtatással lefutnak.

Viszont a GTK3 nem támogat jópár olyan beállítási lehetőséget/korábbi feature-t, amit a GTK2 még támogatott: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901021 Ez sajnos nem éppen a visszamenőleges kompatibilitás kategóriába esik... Sz*rk: A wikipedián is benne van a cikkben, hogy nem igazán jeleskedtek a backward-compatibility terén a srácok.
Arról nem is beszélve, hogy a GTK3 mekkora resource-impact a GTK2-höz képest, illetve, hogy mennyi egyéb problémát okozhat. A VICE C64 emulátor a 3.3-as verzióval átállt GTK3-asra és onnantól kezdve egészen a 3.5-ig a grafikus felület használata a hang bebugzását/akadását eredményezte. (https://vice-emu.sourceforge.io/NEWS és még mostanra sem javították ki az összes ilyet, csak a nagyját.)

A gtk_container_set_focus_chain esetében az a fura, hogy csak úgy elvágták a dolgot, mindenféle alternatíva nélkül úgy, hogy még a 3 to 4 migrációs doksiban sem írnak róla egy árva karaktert sem, és az API referenciában sincs róla semmi. Az is érdekes lesz, amikor majd a Cinnamon és az Xfce átáll GTK4-re, mert a menubarral kapcsolatos widgetek is megszűntek, csak a popover marad. Cinnamonék implementálhatnak saját menü widgetet.

Zseniális... Elég sok mindent újra kell majd akkor írni, amikor átállnak a projektek.

Hogy a Gnome milyen design döntéseket hoz, az megint más kérdés. Egy részük szerintem teljesen jó, de vannak olyanok, amik érthetetlenek és értelmetlenek. Például, hosszú viták voltak arról, hogy lehetne egy váltógombot tenni a Nautilusba és a FileChooserDialog-ba, amivel lehetne váltani a kattintható path bar és a beírható location bar között. Ez a vita is el lett kaszálva, és azóta sincs a felületre kivezetett megoldás, úgyhogy marad a Ctrl-L, ami nem túl intuitív.

Dehát szinte minden path/location bar-ral rendelkező programban ott van valamelyik szélen a kis váltógomb; még a 100 000 éves KDE3-as Dolphinban is ott volt már.

Oldschool Computer - http://oscomp.hu

Viszont a GTK3 nem támogat jópár olyan beállítási lehetőséget/korábbi feature-t, amit a GTK2 még támogatott

Igen, ellenben a GTK3 támogat jópár olyan lehetőséget, amit a GTK2 nem :)

Ha megnézzük, hogy a linkelt bugtrackeren miket kifogásol a szerző a Chromium GTK3-as port kapcsán:

- it uses `dconf`
- existing GTK2 themes cannot be used in GTK3 
- existing GTK3 theme is clearly not designed to be used on a PC
- has no bitmap font support
- The most concerning is that GTK3 is mainly developed by RedHat

Szerintem ezek közül a GTK2 témák nem-támogatása illetve a bitmap fontok nem-támogatása az, ami valóban probléma. Ezzel szemben miket tud a GTK3, amiket a GTK2 nem?

- teljesen Cairo alapú hardvergyorsított, vektorgrafikus rendering
- CSS támogatás
- Wayland backend
- Vsync
- multi-touch támogatás
- egy rakat új widget, a libhandy/libadwaita révén többek közt reszponzív megjelenés (egyik kedvencem a GtkNotebook újításai)

Ezek pedig:

- gtk-button-images
- gtk-enable-mnemonics
- gtk-icon-sizes
- gtk-menu-bar-accel
- gtk-menu-bar-popup-delay
- gtk-menu-images
- gtk-menu-popdown-delay
- gtk-menu-popup-delay
- gtk-show-input-method-menu
- gtk-show-unicode-menu
- gtk-toolbar-icon-size
- gtk-toolbar-style
- gtk-visible-focus
- gtk-alternative-button-order

Szerintem ezek tipikusan azok a dolgok, amiknek a kezelését nem szabad a fejlesztő kezébe adni. Úgy lenne jó, ha ezek központilag, egyetlen helyről állíthatók lennének, és a programok kötelezően és egységesen alkalmazkodnának hozzá. Az más kérdés, hogy a Gnome erre nem biztosít lehetőséget, ez nagy hiba.

Arról nem is beszélve, hogy a GTK3 mekkora resource-impact a GTK2-höz képest, illetve, hogy mennyi egyéb problémát okozhat.

Szerintem itt a Gnome-os tapasztalat beszél belőled. Önmagában a GTK3 egyáltalán nem resource-impact, sőt, megkockáztatom, hogy a hardveres renderelés miatt még kevesebbet is dolgoztatja a procit, mint a GTK2.

A VICE C64 emulátor a 3.3-as verzióval átállt GTK3-asra és onnantól kezdve egészen a 3.5-ig a grafikus felület használata a hang bebugzását/akadását eredményezte.

Ez biztos, hogy a GTK3 miatt van? Elméletileg nem szabadna, hogy a kettőnek köze legyen egymáshoz.

Dehát szinte minden path/location bar-ral rendelkező programban ott van valamelyik szélen a kis váltógomb; még a 100 000 éves KDE3-as Dolphinban is ott volt már.

Igen, vannak olyan funkciók, amik hiánya azért nehezen emészthető meg, mert ezeket nem nehéz implementálni, nem növelik jelentősen a kódbázist, stb... mégsincsenek.

Szerintem ezek közül a GTK2 témák nem-támogatása illetve a bitmap fontok nem-támogatása az, ami valóban probléma.

Ez csak egy része a problémáknak.

teljesen Cairo alapú hardvergyorsított, vektorgrafikus rendering

Cairo support a GTK2-ben is van.

CSS támogatás

Ez meg a nagyon nem kellett volna kategória...

Wayland backend

És normálisan működő és elterjedt Wayland implementáció van már, hogy ennek a feature-nek értelme is legyen? :( (Ha van, akkor nem szóltam.)

Vsync

? A VSync mióta a grafikus toolkit feladata?

A többi meg (multi-touch, reszponzivitás) inkább mobilon fontos.

Az más kérdés, hogy a Gnome erre nem biztosít lehetőséget, ez nagy hiba.

Jó, hát vannak más desktop környezetek is, amik GTK3-at használnak, szóval ez legyen a GNOME baja.

Szerintem itt a Gnome-os tapasztalat beszél belőled.

Az kizárt. Sose használtam GNOME-ot. (Oké, 2008-ban két hétig.) Xfce-et pár hónapig, amúgy meg KDE3-at világéletemben. Belőlem itt a GTK3-as alkalmazások tapasztalata beszél.

Önmagában a GTK3 egyáltalán nem resource-impact, sőt, megkockáztatom, hogy a hardveres renderelés miatt még kevesebbet is dolgoztatja a procit, mint a GTK2.

Hát, én nem ezt tapasztaltam, hanem azt, hogy ha van egy program, amiből van GTK3-as és GTK2-es verzió, akkor a GTK3-as nemcsak, hogy sokkal lassabb, de bugzik is: villog, akad, stb. Még PC-n is, de RPi-n kész gyötrelem volt a default GTK3-as desktopot (Pixel?) használni, ment is fel az LXDE.

Ez biztos, hogy a GTK3 miatt van?

Igen. Olvasd el a changelogot:

** GTK3 fixes
-------------

- Almost all causes of stuttering / audio glitches when interacting with the UI
have been resolved.

GTK2 vagy SDL alatt ez nem jelentkezik.

Elméletileg nem szabadna, hogy a kettőnek köze legyen egymáshoz.

Elméletileg a rendszer sebességét sem volna szabad visszafognia, de csinálja, ez tapasztalat (ld. fentebb: RPi vs. Pixel (?)).

Igen, vannak olyan funkciók, amik hiánya azért nehezen emészthető meg, mert ezeket nem nehéz implementálni, nem növelik jelentősen a kódbázist, stb... mégsincsenek.

Hát, erre mondtam, hogy a GNOME-nál ideológiai alapon fejlesztenek. :(

Oldschool Computer - http://oscomp.hu

Cairo support a GTK2-ben is van.

Van, de csak a widgetek egy része gyorsított. Ahhoz, hogy az egész hardvergyorsított legyen, túl nagy átalakításokra lett volna szükség (részben épp emiatt kapott új főverziószámot).

Ez meg a nagyon nem kellett volna kategória...

Jó az, hidd el. A CSS lassan egy olyan univerzális nyelv lesz, amit az informatikusok többsége "beszél", legalább alapszinten. Sokkal egyszerűbb a témázás, ha nem kell megtanulni úgy leírónyelvet, hanem lehet alkalmazni az eddig megtanultakat. Illetve az is jó dolog, hogy van egy rakat előre definiált CSS osztály, amit lehet használni a widgetekre.

És normálisan működő és elterjedt Wayland implementáció van már, hogy ennek a feature-nek értelme is legyen? :( (Ha van, akkor nem szóltam.)

Kinek mi a normális. A legtöbb X-es programmal kompatibilis, jól működő Wayland implementáció már évek óta van.

? A VSync mióta a grafikus toolkit feladata?

Bocs, úgy értem, hogy az ablakkezelő (compositor) által kezelt vsync-hez képes alkalmazkodni a GTK, így simább lesz a megjelenítés.
Erre gondoltam, csak nem fejtettem ki :)

Hát, én nem ezt tapasztaltam, hanem azt, hogy ha van egy program, amiből van GTK3-as és GTK2-es verzió, akkor a GTK3-as nemcsak, hogy sokkal lassabb, de bugzik is: villog, akad, stb.

Hogy RPi-n bugos, azt el is hiszem. A GTK3-nak kell egy normális GPU, normálisan implementált OpenGL. Ez RPi-n nem feltétlenül áll rendelkezésre.
Asztali gépen én nem tapasztaltam hibákat.

Hát, erre mondtam, hogy a GNOME-nál ideológiai alapon fejlesztenek. :(

Én nem ezt mondanám...
GTK2 esetén az volt a trend, hogy "tegyünk bele mindent, amire a programozónak szüksége lehet, és majd ő eldönti, hogy mit akar használni belőle". A GTK3 fejlesztésénél viszont egy átgondoltabb, alaposabban tervezettebb hozzáállás volt jelen, ott azt mondták, hogy "a saját (sokkal kötöttebb) szempontjaink szerint fogjuk áttervezni a GTK-t, és ti alkalmazkodtok hozzá...". Most ezt lehet ideológiáknak nevezni, de szerintem egyáltalán nem baj, ha nincs minden megengedve a fejlesztőnek, hanem fogják a kezüket, és van, ami vezeti őket. Egyáltalán nem lenne baj az sem, ha mindenki, aki olyan UI-t tervez, ami várhatóan Gnome környezetben fog futni, elolvasni a Gnome human interface guidelines-t. Ha nem is tartja be az ember minden pontját (mert természetesen nem kötelező), de mindenesetre sokat lehet tanulni az ilyenekből.
Az én kedvencem ilyen témában az Elementary OS HIG-ja, szerintem ez egy jól átgondolt, okosan összerakott doksi.

Ahhoz, hogy az egész hardvergyorsított legyen, túl nagy átalakításokra lett volna szükség (részben épp emiatt kapott új főverziószámot).

Ezt még érteném, csak sajnos ennek ellenére lassabb lett az egész.

Jó az, hidd el.

Nem tudok hinni. Meg ráadásul 20 éve vagyok webgányer is, úgyhogy, ha valaki, akkor én tudom, hogy a web mennyire kerülendő...

Kinek mi a normális. A legtöbb X-es programmal kompatibilis, jól működő Wayland implementáció már évek óta van.

Nekem az, ha nem bugos és nem bloated. A Weston bugos és bloated is. A Clayland nem, de azt használja bárki is?

Bocs, úgy értem, hogy az ablakkezelő (compositor) által kezelt vsync-hez képes alkalmazkodni a GTK, így simább lesz a megjelenítés.
Erre gondoltam, csak nem fejtettem ki :)

Dehát VSync alapú double buffering már a GTK2-ben is volt. Mi volt akkor a GTK3-as VSync-ében az újdonság?

Hogy RPi-n bugos, azt el is hiszem. A GTK3-nak kell egy normális GPU, normálisan implementált OpenGL. Ez RPi-n nem feltétlenül áll rendelkezésre.

Oké, de miért volt lassú is? Az, hogy a helyi OpenGL implementáció bugos és ezért szétesnek az ablakok, az érthető, de mitől fogja meg az egész rendszert?

Asztali gépen én nem tapasztaltam hibákat.

Én sajnos de. Olyan glitchy volt az egész, villogott, nem renderelt újra részeket, akadt, fagyott, lagzott és sokkal lassabb is volt, mint a GTK2.

de szerintem egyáltalán nem baj, ha nincs minden megengedve a fejlesztőnek, hanem fogják a kezüket, és van, ami vezeti őket

Szerintem meg de. Az ilyen mentalitás, hogy dedósként kezelik a fejlesztőket, vezet oda, hogy egyre rosszabbak lesznek a programok.

Oldschool Computer - http://oscomp.hu

Ezt még érteném, csak sajnos ennek ellenére lassabb lett az egész.

Megfelelő hardver esetén nem lassabb, és itt "megfelelő" alatt nyugodtan érthetsz minden olyan GPU-t, ami kb. 2010 óta kijött.

Nem tudok hinni. Meg ráadásul 20 éve vagyok webgányer is, úgyhogy, ha valaki, akkor én tudom, hogy a web mennyire kerülendő...

Nekem is van webes tapasztalatom, épp ezért örülök neki, hogy CSS alapú a GTK témázás. Plusz egy dolog, amit nem kell nulláról tanulnom.

Dehát VSync alapú double buffering már a GTK2-ben is volt. Mi volt akkor a GTK3-as VSync-ében az újdonság?
   

Mármint mire gondolsz? Arra, amikor fix 24 fps-en renderelt a GTK? :)
Én nem tudom, mi volt előtte, amiről én beszélek, arról itt a levél: https://mail.gnome.org/archives/wm-spec-list/2013-January/msg00000.html
Érdemes megnézni a linkelt blogot és annak az előző részeit, abból látszik, mennyire nem egyszerű dolog ez.

Én sajnos de. Olyan glitchy volt az egész, villogott, nem renderelt újra részeket, akadt, fagyott, lagzott és sokkal lassabb is volt, mint a GTK2.

Ilyet csak akkor tapasztaltam, amikor VNC-en vagy NX-en keresztül csatlakoztam a gépemre, máskor nem. Pedig van egy ezeréves Dell laptopra telepítettem Fedorát. Lassúnak lassú volt, de ilyen bugokat nem tapasztaltam, mint ahogy egyik másik gépemen sem.

 

 

Megfelelő hardver esetén nem lassabb, és itt "megfelelő" alatt nyugodtan érthetsz minden olyan GPU-t, ami kb. 2010 óta kijött.

2012-es a gépem és mire a GTK3 bejött, egyszer már volt benne kártya cserélve.

Mármint mire gondolsz? Arra, amikor fix 24 fps-en renderelt a GTK? :)

Nem, arra, hogy volt benne lehetőség arra, hogy double buffert használj, ami VSync-re swappelődik.https://mail.gnome.org/archives/gtk-devel-list/2003-March/msg00137.html

Ilyet csak akkor tapasztaltam, amikor VNC-en vagy NX-en keresztül csatlakoztam a gépemre, máskor nem. Pedig van egy ezeréves Dell laptopra telepítettem Fedorát. Lassúnak lassú volt, de ilyen bugokat nem tapasztaltam, mint ahogy egyik másik gépemen sem.

Ez mindenféle hálózati csatlakozás nélkül, helyben volt lassú és bugos.

Oldschool Computer - http://oscomp.hu

( sinexton | 2022. 03. 31., cs – 11:23 )

Szerkesztve: 2022. 03. 31., cs – 11:26

Sajnos ahogy telik az idő és folyik a fejlesztés, egyre több igényt terveznek a projektek kielégíteni, ezért egyre nő a komplexitás, ami miatt egyre több az eredetei koncepciót érintő módosítás, ami miatt egyre mélyebben kellene újra írni az alapoktól, ami miatt egyre több a szőnyeg alá seprés.

A komplexitás egy bizonyos szint felett nem kezelhető elégségesen az addigi szinten. Főleg ha minél többen dolgoznak a projekten és minél kevesebb az átfedés a fejlesztők által ismert know-how és kompetencia halmazokban.

Mi a megoldás? Mesterségesen alacsony szinten tartani a komplexitást úgy, hogy ha elrobban, akkor nem adunk hozzá extra feature-t. Ezt kellene megérteni. Inkább keveset tudjon a megoldás, de azt jól és a kód is kezelhető maradjon.

Ennek ellene megy a divat és a piacba programozott motivációs faktorok. Szintén ellene kell menni. Csak ezt nem merik megtenni sokan. Főleg a nagy cégek operálnak kozmetikai dolgokkal illetve implementálnak újabb feature-öket folyamatosan módosítgatva a megoldást, mely így nem tud eléggé stabilizálódni. Ennek ellen kell menni és más marketing pontokat keresni.

Ebben is van igazság. Én a Windowsra szoktam azt mondani, hogy az már "over engineered". A Gnome-mal kapcsolatban szerintem alapvetően egy jó döntés az, hogy alapkonfigurációban kevesebbet tud, mint a többi asztali környezet. Ha ez az ára annak, hogy a Gnome az egyik legstabilabb DE mai napig, akkor ez egy jó döntés. Így legalább van erőforrás a hibák javítására és az optimalizálásra. Ez utóbbival egyébként elég jól állnak szerintem.