Byla vydána verze 4.0.0 programovacího jazyka Ruby (Wikipedie). S Ruby Box a ZJIT. Ruby lze vyzkoušet na webové stránce TryRuby. U příležitosti 30. narozenin, první veřejná verze Ruby 0.95 byla oznámena 21. prosince 1995, proběhl redesign webových stránek.
Všem čtenářkám a čtenářům AbcLinuxu krásné Vánoce.
Byla vydána nová verze 7.0 linuxové distribuce Parrot OS (Wikipedie). S kódovým názvem Echo. Jedná se o linuxovou distribuci založenou na Debianu a zaměřenou na penetrační testování, digitální forenzní analýzu, reverzní inženýrství, hacking, anonymitu nebo kryptografii. Přehled novinek v příspěvku na blogu.
Vývojáři postmarketOS vydali verzi 25.12 tohoto před osmi lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell on Mobile, KDE Plasma Mobile, Phosh a Sxmo.
Byla vydána nová verze 0.41.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 6.1 nebo novější a také libplacebo 6.338.2 nebo novější.
Byla vydána nová verze 5.5 (novinky) skriptovacího jazyka Lua (Wikipedie). Po pěti a půl letech od vydání verze 5.4.
Byla vydána nová verze 5.4.0 programu na úpravu digitálních fotografií darktable (Wikipedie). Z novinek lze vypíchnout vylepšenou podporu Waylandu. Nejnovější darktable by měl na Waylandu fungovat stejně dobře jako na X11.
Byla vydána beta verze Linux Mintu 22.3 s kódovým jménem Zena. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze, že nástroj Systémová hlášení (System Reports) získal mnoho nových funkcí a byl přejmenován na Informace o systému (System Information). Linux Mint 22.3 bude podporován do roku 2029.
GNU Project Debugger aneb GDB byl vydán ve verzi 17.1. Podrobný přehled novinek v souboru NEWS.
Josef Průša oznámil zveřejnění kompletních CAD souborů rámů tiskáren Prusa CORE One a CORE One L. Nejsou vydány pod obecnou veřejnou licenci GNU ani Creative Commons ale pod novou licencí OCL neboli Open Community License. Ta nepovoluje prodávat kompletní tiskárny či remixy založené na těchto zdrojích.
) 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: