Byla vydána nová verze 4.8 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Apple container dospěl do verze 1.0.0. Jedná se o open source nástroj pro spouštění linuxových kontejnerů na macOS postavený nad containerization. Napsaný je v programovacím jazyce Swift a optimalizovaný pro Apple silicon.
Bylo vydáno Eclipse IDE 2026-06 aneb Eclipse 4.40. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Asterinas (GitHub) je v Rustu napsané jádro operačního systému poskytující s jádrem Linux kompatibilní ABI. Vydána byla verze 0.18.0. První distribucí postavenou nad jádrem Asterinas je Asterinas NixOS. Nejedná se o oficiální projekt NixOS a nemá nic společného s NixOS Foundation.
Podrobně byla rozebrána kritická zranitelnost v nf_tables (CVE-2026-23111). Další lokální eskalace práv na Linuxu. V upstreamu byla zranitelnost již v únoru opravena. Ve zdrojovém kódu stačilo odstranit 1 vykřičník.
Evropská komise (EK) nařídila americké společnosti Meta, že musí znovu umožnit bezplatný přístup konkurenčním obecně zaměřeným asistentům umělé inteligence (AI) k WhatsAppu a tento přístup musí zachovat až do ukončení antimonopolního šetření. Opatření je dočasné a má zabránit vážnému a nevratnému poškození konkurence na rychle rostoucím trhu s obecnými AI asistenty. Meta uvedla, že se proti rozhodnutí odvolá.
Společnost Anthropic představila AI modely Claude Fable 5 a Claude Mythos 5. Claude Fable 5 je první model třídy Mythos určený pro běžné použití.
Byla vydána nová stabilní verze 3.24.0, tj. první z nové řady 3.24, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Přehled novinek v poznámkách k vydání.
Na čem pracují vývojáři v Rustu napsaného mikrokernelového unixového operačního systému Redox OS (Wikipedie)? Byl publikován přehled vývoje za květen. Vypíchnout lze nový scheduler EEVDF nebo port desktopového prostředí Xfce na Redox OS.
Upozornění pro uživatele Asahi Linuxu: Neaktualizujte macOS na verzi 27 Golden Gate! Apple změnil detekci spouštěcích oddílů. Po aktualizaci oddíl s Asahi Linuxem nevidí. Snad je to jenom chyba.
) odvolavky na pomenovane prvky gui. Tie glade subory moze uzivatel pokojne editovat pomocou glade-2.
Neviem ale o tom, ze by sa o to niekto pokusil, asi o tom ani skoro nikto spomedzi tych par sto uzivatelov nevie...
Lenže stále povieš 'Tlačidlo', nie 'Niečo, čo pošle jeden signál'. niekomu vadí rozloženie tlačidial v Gnome, niekomu rodielnosť GUI toolkitov a ich stále zmeny (ext. link).
Preto ja chcem vytvoriť len popis prianí na GUI. Ten sa dá prehnať nejakým AI (rule engine, fuzzy logik). (Napríklad!)
)
Je tu filozoficky problem - spolupraca s GUI (alebo niecim inym) nie je jednoducha.
- Bud ju spravis tak aby vedela "vsetko" a bude tym padom zlozita a bude obsahovat podobne konstrukcie ako volania nejakeho GUI API
- Alebo spravis nejaku uroven abstrakcie - bude to prehladnejsie, jednoduchsie, ale nutne obmedzene co do funkcnosti.
Dobrý postreh! Ale nechcel som hneď rozmýšlať 'ako to imlementovať', alebo 'ako to bude fungovať', chcem len _rozmýšlať_...
Takto by mohol vyzerať externy format:
[recommended] 'Gnome dialog template';
[komponents] 'but' {
[send-signal] 'OK';
[send-signal] 'Cancel';
[send-signal] 'Wait';
}
[komponents] {
[store-text][on-change-signal] 'message';
[return-index][dynamic] 'category combo';
}
[group][linear please] {
[safe] 'but'.'Wait';
[unsafe][default] 'but'.'OK';
[unsafe] 'but'.'Cancel';
}
[group] {
'category combo' [note] 'Vyberte si kategoriu';
[default] 'message' [note] 'Sem zapíšte text';
}
[signals] {
'but'.'OK'.[send-signal] = 'doOK()';
'but'.'Cancel'.[send-signel] = 'doCancel()';
'but'.'Wait'.[send-signal] = 'doWait()';
'message'.[on-change-signal] = 'updateTitle()';
}
Takto kod v C:
GUI_dialog* d;
void initGUI(char** loaded_kategories) {
d = GUI_load("gui.conf");
GUI_dynamicData(d, "category combo", loaded_kategories);
GUI_makeActual(d);
}
void doOK() {
server_send(GUI_get(d, "message"));
}
void updateTitle() {
if(is_well_formed(GUI_get(d, "message"))) {
printf("recipient will be happy!\n");
} else {
printf("recipient will be unhappy!\n");
}
}
Vsimnite si, ze v externom formate o rozlozeni nehovorim, len odporucam, skupinky a sablonu. V kode sa z inicializaciou a obsluhou GUI nehram.
Ale to nieje dolezite!
Teda - nie ze by som vsetkemu rozumel...
Skusim napisat, ako som to pochopil:
[recommend] doporucuje vseobecny mechanizmus, ktorym sa ma vyrobyt GUI z doporuceni [komponents] definuju casti GUI - formulare a dialogy, [group] urcuje layout [signals] signal bindingPovedal by som, ze by bolo uzitocne oddelit tieto veci: - definiciu interface aplikacie - (na to sa bezne pouziva IDL) - rozlozenie gui (analogia k html alebo xml) a jeho napojenie na aplikaciu - styl/tema/skin (analogia k css) GUI prostredie potrebuje vsetky tri veci, zatial co napr. tie AI skripty len tu prvu. Taketo rozdelenie je obvykle. Mozno blizsie k tomu co navrhujes by bolo nedefinovat rozlozenie gui, ale len pomenovat prvky gui a ich prepojenie na aplikaciu a potom nadefinovat samotne gui, ktore by sa odvolavalo na tieto pomenovane prvky. Priklad:
- mam funkciu "doOK()": void doOK();
- Na jej obsluhu potrebujem button, pomenujem ho "OKbutton":
Button OKbutton
bind OKbutton.clicked -> doOK()
- Mam formular 1 obsahujuci OKbutton
<form name="formular_1">
<button name="OKbutton" label="OK"/>
<button name="Cancelbutton"/>
</form>
- Mam styl pripadne obsahujuci lokalizovane retazce:
button.OKbutton {color:red;}
button.Cancelbutton {label:"Zrus";}
Dobre, postupujes logicky! Lenze definujes vzhlad. Ja chcem len funkcnost. Zabudni na moje 1-urovnove [vsetko]. Ponechaj v popise len obsahy oboch [komponents] a zostane:
[send-signal] 'ok'; [send-signal] 'cancel'; [send-signal] 'wait'; [store-text][on-change-signal] 'text' [note] 'Vyberte si kategoriu'; [return-index][dynamic] 'category' [note] 'Sem zapíšte text';
send-signal vysle signal, ked si ho uzivatel vyberie. engine vzycajne vyberie tlacidlo.
store-text drzi text od uzivatela zvycajne inputbox.
return-index vrati index vyberu radio-buttony, combobox
dynamic obsah urci app. (definovane polozky, alebo rozsahy...)
...
Nikdy nepoviem [button], alebo farba, tento v lavo, tento v pravo. Ja chcem totiz usporit cas a sekundarne definovat dost abstraktny model na to, zby sa dal pouzit v GTK, QT, NCurses, ale aj konzole!
Nechcem hovorit o farbe, velkosti, polohe. Len o tom ako som ja schopny prijmat signaly a data, nech sa user, ako to chce. Podme na to __abstraktne.
Mozno by sme sa mohli o tom viacej pobavit, ak by s chcel... a mozno rozsirit nejaky uz funkcny projekt/vlastny projekt...
Teda na konzolu (ak mas na mysli nieco na sposob "Proceed ? [Y/n] :", tak na to by som sa uz asi fakt vykaslal... Zmysel to ale mozno predsa len ma - pre postihnutych (napr. nevidiacich). SWING v jave by vraj mal byt schopny nejak tymto stylom komunikovat (pomocou hlasoveho rozhrania), ale nikdy som to nevidel.
To co si napisal hore je v podstate deklaracia signalov s nenapadnymi doplnkami (napr. [note]), ktore na jednej strane pomahaju vyrobit gui, ale na strane druhej na skutocne zobrazenie gui nestacia (a to je predpokladam pointa).
Ako to gui teda vlastne vznikne ?
Vytvori ho na zaklade hintov nejaky genialny algoritmus ?
Alebo bude definovane v dalsom subore ?
V praxi asi oboje - pocas vyvoja aplikacie sa vykasles na GUI a nechas automatiku, nech nejake vyrobi. A ked uz ides odovzdat program zakaznikovi, tak este narychlo zlepis nejake krajsie GUI, vyfarbis ho na ruzovo a mame to!
Mam dalsie napady, ale nechcem to tu prilis zahltit.
Je to zaujimava debata, rad v nej budem pokracovat.
Co sa tyka nejakeho projektu, mozme to zvazit, ale teraz mam tri nekonecne projekty (na ktorych robim len vo volnom case) a nestiham.
Ak to myslis vazne, mal by si pozistovat co a ako robia ostatni.
Ked som chcel ziskat prehlad v tom co sa deje, jednoducho som presiel vsetky projekty (v jednej kategorii) na freshmeate. Je to sice typicky niekolko sto, ale ide to pomerne rychlo a nakoniec najdes mozno 5 naozaj zaujimavych.
Uz som spominal glade a mozillu. Z mozilly by si mohol zobrat XPCOM.
To je ta komponentova architektura, interface sa opisuje pomocou IDL.
Alternativy su Orbit v gnome, nieco dalsie velmi podobne je v OpenOffice. Mozno ti to bude pripadat prilis zlozite (mne to tak pripada), ale stoji to za uvahu.
Mozilla ma tiez celkom prepracovane GUI definovane v XML a poprepajane s komponentami pomocou javascriptu. Zas tak velmi do toho nevidim, ale myslim ze je to dobre vidiet aspon pre inspiraciu.
Inac - nebolo by zle najprv si overit koncepciu. Dajmetomu napisat nejaky skript (ja pouzivam python), ktory by vyparsoval tu definiciu signalov a vygeneroval by rozhranie. Ako format doporucujem XML
a parsovat pomocou DOM - usetris vela casu pri vyrobe parsera.
Tiez nie je zle zoznamit sa s API viacerych GUI a ich moznostami. Na povrchu vyzeraju podobne, ale koncepcne riesia mnohe veci rozdielne.
SourceForge je dzungla, hlavne ta ich dokumentacia.
Ale nie je to nakoniec take zlozite - aj ked mohli to spravit aj jednoduchsie. Najprv sa musis prihlasit, napisat im popis projektu, jeho nazov a licenciu. Oni to odsuhlasia - pomerne rychlo - tak do troch dni, ale mozes to cakat uz na druhy den. Detaily si uz nepametam, prihlasoval som sa tam niekedy pred dvoma rokmi...
IMHO dost cudne je uploadnovanie - posielas to tam cez FTP do spolocneho adresara a potom to cez webove rozhranie zaregistrujes a presunie sa to tam kde to ma byt.
Radšej pobím v Perle, ale to je nepodstatné, aj tak, by som rád vyrobil niečo takéto:
parser modul: XML ASCII Binary
| | |
štrukturálny model
|
layout modul: múdri aloritmus
| | |
GUI backend: QT KDE ...
To je však hudba budúcnosti a možno absoltne zlý návrh...
sourceforge.net: zaujíma ma mailing-listu a tiež,či nepodporujú niečo iné ako CVS... ja by som radšej Darcs...
Tiskni
Sdílej: