Byla vydána (𝕏) nová major verze 17 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností i s náhledy a videi v oficiálním oznámení.
Sovereign Tech Fund, tj. program financování otevřeného softwaru německým ministerstvem hospodářství a ochrany klimatu, podpoří vývoj FFmpeg částkou 157 580 eur. V listopadu loňského roku podpořil GNOME částkou 1 milion eur.
24. září 2024 budou zveřejněny zdrojové kódy přehrávače Winamp.
Google Chrome 125 byl prohlášen za stabilní. Nejnovější stabilní verze 125.0.6422.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Textový editor Neovim byl vydán ve verzi 0.10 (𝕏). Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Byla vydána nová verze 6.3 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.15.
Dnes ve 12:00 byla spuštěna první aukce domén .CZ. Zatím největší zájem je o dro.cz, kachnicka.cz, octavie.cz, uvycepu.cz a vnady.cz [𝕏].
JackTrip byl vydán ve verzi 2.3.0. Jedná se o multiplatformní open source software umožňující hudebníkům z různých částí světa společné hraní. JackTrip lze instalovat také z Flathubu.
Patnáctý ročník ne-konference jOpenSpace se koná 4. – 6. října 2024 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytváří všichni účastníci, se skládá z desetiminutových
… více »Program pro generování 3D lidských postav MakeHuman (Wikipedie, GitHub) byl vydán ve verzi 1.3.0. Hlavní novinkou je výběr tvaru těla (body shapes).
Programátori sa často hrajkajú s GUI. Viem to, lebo aj ja som to robil, kým som robil pod X-i. To je však zlý prístup - GUI netreba navrhovať. Užívateľ si ho neskôr može jednoducho a rýchlo navrhnúť sám.
Základom všetkých GUI toolkitov a builderov, ktore som videl je presný návrh rozloženia. Zadefinujeme si okno, do neho správcov rozloženia a rôzne kontaineri a potom tlačidla a ...
Teraz mám iný návrh. Postup tvorby frontend vrstvy bude rovanaký. Definujeme pre vstupy akcie, ktore narabajú so vstupnymi dátami. Stalačenie tlačidla -> doClickedOK(), písanie do inputboxu -> regenerateTitle(char*)
Tu sa treba zastaviť. Naša aplikacia vie robiť všetko čo treba, len užívateľ nevie akcie vyvojať. My však pre užívateľa nenamodelujeme GUI, ale definujeme vlastnosti, ktoré musia ovládacie prvky mať, aby ich vedel užívateľ použiť.
Takze povieme [prvok, ktory vie explicitne vyvolať doClicked()]
, [prvok, ktorý vie primať ľubovoľný text a pri zmene textu volá regenerateTitle()]
.
Ďalej však treba definovať skupiny prvkov, dôležitosť prvkov v skupine, priradzovať popisy, atď. Nás proste nezaujíma, ako bude aplikačné GUI vyzerať. To nech rozhodne GUI engine podľa nejakých desktop-enviromentálnych šablôn. Hlavne aby vedel volať naše akcie so správnymi dátami.
Mňa teraz nezaujíma, či by popis bol v externom súbore v špecialnom formáte, alebo by sa narábalo s funkciami, objektami, atď.
Plynie z toho jedna významná výhoda. Užívateľ by dostal možnosť meniť, cele rozloženie GUI a GUI ako také. Niektoré prvky by fungovali rovnako dobre ako combobox, aj ako radio-button, ako na jednom okne, tak na inom okne, ak sa užívateľovi nepáči, zmení. Dôležitá je však úspora casu.
UPDATE: Oprava tagu <code> na </code>, pardon.
Tiskni Sdílej:
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!)
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!
[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...
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...