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.
.
Ve světle minulých rozhodnutí týmu gnome se ale javascriptu příliš nedivím, jen mě to utvrzuje v přesvědčení, že vývojáři gnome už ztratili poslední zbytky soudnosti.Naopak. Javascript neni spatny jazyk, podporuje radu hezkych technik, nema zadnou platformu ani runtime knihovnu a tak neduplikuje systemove knihovny, je k dispozici nekolik implementaci, ma standard, krasne se integruje s GObjects a ma velkou uzivatelskou bazi. Knihovny a kod, kde je treba rychlost se v tom psat nebudou, ale pro jednoduche aplikace a GUI, proc ne?
A ted koukni na statistiky ne pro GitHub, ale pro desktopove aplikace na linuxu.Userbase hraje vyznamnou roli, ostatne aktivni vyvoj stovek gnome shell extension potvrzuje, ze je to dobra volba.
Userbase hraje vyznamnou roliNo shit!
ostatne aktivni vyvoj stovek gnome shell extension potvrzuje, ze je to dobra volba.Tak to bych asi tu svou mel stahnout. PS: Pro Shell extensions pouziti javascriptu chapu - uz kvuli primocaremu monkey patching.
Pro Shell extensions pouziti javascriptu chapu - uz kvuli primocaremu monkey patching.Prave, vsak ty "aplikace" v js budou take stejne jednoduche pitomosti, nic sloziteho v tom nikdo psat nebude. Znovu, problem neni jazyk, ale vyvojove tooly, pouzitelne IDE chyby jako sul, a dokumentace.
Ano, Vala je na to lepsi. Ale JS? To snad ne.
Ostatně, co proboha dobrého může vzejít z jazyka jehož podstata je, že se někdo nechce naučit C++?Tady zas někdo něco nepochopil :).
Ve srovnání s ním je C++ sto let za opicema.Neni. Je to jen jazyk s jinym urcenim. Ostatne stacilo by udrzovat gtkmm. Je sice hezke, ze nejaky jazyk integruje lepe GObject model, ale prichazite pak o spoustu znovupouzitelneho existujiciho kodu a limituje pocet lidi schopnych v tom psat a hlavne opravovat chyby. Uprimne doufam, ze Vala zapleveli Gnome code base co nejmene, stacila mi zkusenost s gnome-dvb-daemon.
Neni. Je to jen jazyk s jinym urcenim.Nemyslím si, že by to mělo souvislost s určením.
Uprimne doufam, ze Vala zapleveli Gnome code base co nejmene, stacila mi zkusenost s gnome-dvb-daemon.Mně osobně na to stačí existující dynamické jazyky v lepším případě s nějakou šikovnou optimalizací, když proto bude důvod a někdo to udělá. Backend se dá vždycky napsat v céčku, tady jde spíš o to, že na hraní si s UI není céčko podle mě úplně nejvhodnější.
Rikam kacir. Uz si odvazuje dokonce popirat modernost C++ i ve verzi ISO 14882/2011.Ty zkoncis na te hranici drive nez jsem si myslel.Neni. Je to jen jazyk s jinym urcenim.Nemyslím si, že by to mělo souvislost s určením.
Mně osobně na to stačí existující dynamické jazykyJenze Vala je kompilovany jazyk, tedy za predpokladu ze ti valac vygeneruje kompilovatelny kod, takze jsme jinde.
Rikam kacir. Uz si odvazuje dokonce popirat modernost C++ i ve verzi ISO 14882/2011.Ty zkoncis na te hranici drive nez jsem si myslel.Pravděpodobně :).
Jenze Vala je kompilovany jazyk, tedy za predpokladu ze ti valac vygeneruje kompilovatelny kod, takze jsme jinde.To je pokryto ve zbytku odstavce.
Prostě jsem ty gnome-dvb-věci někaj nedonutil k funkčnosti. Přitom DVB mi jelo v xine, jelo mi i v MPlayeru, jelo mi i ve VLC a nakonec i v Kaffeine, u kterého jsem zůstal. Ale v Totemu s pluginem, a gnome-dvb ani náhodou.
gnome-dvb-daemon Ono to někomu i funguje?Prave ze moc ne, nebo respektive jen velmi kratkou chvili. Tak jsem uvazoval od debugovani, pouziti Vala byl klacek pod nohy, debugovani generovaneho humusu uz klada a tak jsem zacal pouzivat mplayer.
bral bych kvalitní C++ místo toho asi tak přibližně... hned.Nemyslím si, že by výběr mezi C++ a GObjectem (ať už v C nebo v dynamickém jazyce) byl tak jednoznačný, aby šel vyřešit kategorickou odpovědí. Ale každému, co jeho jest.
Jde mi o gobject proti nativnímu C++ modelu. Očividně se někdo rozhodl opačně, ale už je to dávno a při zpětném pohledu mi přijde, že se ty přínosy nedostavily.Mám na to jiný názor.
Vala hezky ukazuje, že je poptávka po jazyce ve stylu C++Není to jen deformace, že pro člověka, který byl odkojen na C++ je cokoli s objektovou notací „ve stylu C++“?
(což už C++ dávno není) se všema problémama a vyrábí pořád ten céčkový gobject kód.Jak sám píšeš, C++ bylo taky často implementované formou preprocesoru, ale u něj ti to zjevně nevadí.
Že se jde stejnou cestou jako KDE s Qt a QML taky o něčem svědčí. Akorát to KDE tam má už tři roky náskok...Nemám k dispozici chronologii obou projektů, takže ani nevím, který z nich byl první v tom, čemu říkáš „cestou jako KDE s Qt a QML“.
Ale Gnome má za sebou technologie které neoslní, KDE je má mnohem lepší.Nějak za tím KDE až tolik zásadně lepších technologií nevidím.
že by výběr mezi C++ a GObjectem (ať už v C nebo v dynamickém jazyce) byl tak jednoznačnými nedavaly smysl. Rikal jsem si, ze je to pozdni dobou, ale ted to neni lepsi
.
Znovu, problem neni jazyk, ale vyvojove tooly, pouzitelne IDE chyby jako sul, a dokumentace.Java + SWT (nativní GUI komponenty)
Nastesti uz ani moc ne, python v desktopu pomalu vymira a to je jen dobre. Je pravda, ze s prichodem gobject-introspection se situace zlepsila, ale to, co bylo s PyGtk2 a kopou bindingu na vsechno, byla velice spatna situace.
primárně webová technologieUz davno nejen webova technologie.
a za druhé stabilitou API třeba mozjs zrovna neoplývá.(a) nikdo nemluvi o integraci mozjs do aplikace, to vas zde nemusi palit, (b) ECMAScript ma mezinarodni standard, (c) existuje vice implementaci js, nic nebrani pouzit casem treba V8.
hlavně funkční desktopovou aplikaci v JS a nemyslím tím pí.ačinky typu file previewer.Nikdo vam nebrani psat treba v tom C, ale na tyhle jednoduche π-covinky je js dobra volba.
Nedokážu si představit, že někdo napíše standardní a hlavně funkční desktopovou aplikaci v JS a nemyslím tím pí.ačinky typu file previewer.Proc by to neslo? Primarne jde u desktopovych aplikaci o knihovny. A ta knihovna je uplne stejna jako kdyz to pises z C. Neznam aktualni stav JS bindingu, ale predpokladam, ze pokud to ma byt oficialni jazyk, tak se hodne rychle dostane na 100% stav.
C++ knihovna gtkmm se zda mrtva.Proč si tohle autor příspěvku myslí? Docela by mě to zajímalo, uvažoval jsem o gtkmm pro jeden projekt...
Jsou to posledni vykriky do tmy, AFAIK to maintainuje par lidi z Openismu (nebo jine male firmicky), kteri to potrebuji pro sve (komercni) projekty. Stejne jako skomira OS X backend v Gtk+. Ale nikdo uz to nebere seriozne a ani moc aplikaci v tom napsanych neni. Plus tu mame stejny problem s manualnimi bindingy (nebo uz se snad dali na g-i?).
Doted jsem patril mezi fanousky GNOME, i pres vsechny zmeny co se za posledni dobu odehraly, ale toto uz je moc.
... a nebo se ta dokumentace za posledni rok zlepsila.
Kazdopadne, predpoklad ze to mapovani je transparetni a budou ti stacit docs k C knihovne GObject je sice krasny, ale dost brzo si uvedomis, ze to tak bohuzel neni.
A co treba FreePascal
.
Opet problem s bindingy.
Oh, pekne, pravda, ze s FPC uz jsem dlouho nedelal a naposledy jsem opravoval gtk2 bindingy rucne.
To by za chvíli mohli začít psát i enterprise aplikace v jazyku určeném pro pračky a podobné spotřebiče.Tim mate na mysli co? Pise se to v C/C++, to je podradny jazyk a zadne enterprise aplikace se v tom nepisi? Ti vyrobci musi dat na tu pracku dva roky zaruku, u rady embedded zarizeni treba osum let se sankcemi za pripadne skody.
. Timto smerem to nepujde. Ta zprava jen rika, ze JavaScript bude jazyk prvni kategorie pro Gnome, vedle treba C. Takze aplikakce si muzete napsat v C, pouzit kombinaci C a JS (binding) ci u jednoduchych veci jen ten JS, ale volba je jen na vas.
Nevim jak je to u JS Gnomackych aplikaci, ale obecne s GObject se pouziva asynchronni model. Nepredpoklada se, ze v JS bude nekdo psat cely kod aplikace, backend by mel byt v necem rychlejsim a tam by mely byt i vypocetni thready. Na jednoduchou GUI aplikaci navic povetsinou staci existujici objekty z glib. Plus, zakladni poucka, na GUI sahat pouze z jednoho threadu!
Na jednoduchou GUI aplikaci navic povetsinou staci existujici objekty z glib.Tak hlavně ještě z nějakého toho toolkitu, GTK+ nebo Clutteru.
nm-applet, na to, že to je relativně jednoduchej GUI front-end, má dost šílenej zdroják. Zabýval jsem se nápadem napsat ekvivalent pro Qt, ale když jsem to viděl, rychle jsem si to rozmyslel...
nm-appletu by asi nějaké to odlehčení neškodilo.
Nicméně takovej nm-applet, na to, že to je relativně jednoduchej GUI front-end, má dost šílenej zdroják. Zabýval jsem se nápadem napsat ekvivalent pro Qt, ale když jsem to viděl, rychle jsem si to rozmyslel...KDEčkáři nějaký applet mají, ne?
nm-appletu by asi nějaké to odlehčení neškodilo.Pokud si dobře pamatuju, tak nm-applet je napsaný zrovna v céčku. A navíc je to takové nechtěné dítko tím, že ho nepoužívá ani Gnome ani KDE.
KDEčkáři nějaký applet mají, ne?Jo, v KDE je, ale Qt != KDE a krom toho je to Plasma applet. Sám o sobě je celkem dobře zpracovanej, ale já nemam rád Plasmu jako celek...
Pokud si dobře pamatuju, tak nm-applet je napsaný zrovna v céčku. A navíc je to takové nechtěné dítko tím, že ho nepoužívá ani Gnome ani KDE.Je napsanej v C, ve stylu "spaghetti with meatballs"
A co teda používáš ty pro ovládání NM?
Je napsanej v C, ve stylu "spaghetti with meatballs"No já mam gnome shell a doufám, že k tomu brzo začnu používat buď nmcli nebo alternativu.A co teda používáš ty pro ovládání NM?
Je napsanej v C, ve stylu "spaghetti with meatballs"Já jen že tématem bylo, zda je JS vhodný pro GUI aplikace a zda JS funguje na principu asynchronního zpracování přes GMainLoop.A co teda používáš ty pro ovládání NM?
Samotný Gnome Shell je z velké části napsán v JS.Taky to podle toho vypadá.
Tiskni
Sdílej: