Byla vydána (Mastodon, 𝕏) nová stabilní verze 2.10.38 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Google zveřejnil seznam 1220 projektů od 195 organizací (Debian, GNU, openSUSE, Linux Foundation, Haiku, Python, …) přijatých do letošního, již dvacátého, Google Summer of Code.
Na základě DMCA požadavku bylo na konci dubna z GitHubu odstraněno 8535 repozitářů se zdrojovými kódy open source emulátoru přenosné herní konzole Nintendo Switch yuzu.
Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.1.0. Po devíti letech od vydání předchozí verze 3.0.5. Doména dillo.org již nepatří vývojářům Dilla.
O víkendu probíhá v Bostonu, a také virtuálně, konference LibrePlanet 2024 organizovaná nadací Free Software Foundation (FSF).
Nová vývojová verze Wine 9.8 řeší mimo jiné chybu #3689 při instalaci Microsoft Office 97 nahlášenou v roce 2005.
Coppwr, tj. GUI nástroj pro nízkoúrovňové ovládání PipeWire, byl vydán v nové verzi 1.6.0. Zdrojové kódy jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
Byla vydána dubnová aktualizace aneb nová verze 1.89 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Vypíchnout lze, že v terminálu lze nově povolit vkládání kopírovaného textu stisknutím středního tlačítka myši. Ve verzi 1.89 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-1 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Byla vydána verze 1.78.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Na oficiálním blogu projektu Wireshark vyšla zpráva o přechodu na Qt. Tento program vždy tradičně používal GTK+, ale potýká se s nedostatky GTK+. Už teď je možné si Qt GUI nainstalovat, ale teprve se na něm pracuje.
Tiskni Sdílej:
"...potýká se s nedostatky GTK+" Vývojáři Wiresharku zmiňují přesně jeden nedostatek: špatný stav portu GTK+ na OS X, pro který chtějí kvůli poptávce Wireshark dělat. To je celé.
Na iOS zatim bohuzel pokud vim, chybi podpora pro QML.
existuje komunitní port pro Tizen.To je pomerne nedavna vec, tlaci se to tam navzdory Intelu a Samsungu par lidi a dokud to bude mit v rade veci treba polovicni framerate oproti EFL, ruzove to nevidim.
Skiny pro aplikaci bych viděl jako nevýhodu - aplikace má zapadata do prostředí.To znie ako keby takú základnú vec skiny pre Gtk+ nevedeli. Každopádne mne vyhovuje, keď môže nastaviť to, čo potrebujem (v mojom prípade napr. farbu XFce panelu a tlačidiel na ňom na tmavší odtieň, ako majú ostatné okná).
Kdysi dávno (před začátkem vývoje Gtk3) v Canonicalu uvažovali postavit nový Gnome desktop nad QT. Není to problém, Qt se dá "skinovat" do úplně jiného vzhledu. Byla by to paráda, ubyla by půlka knihoven.. Jenže pak se rozhodli pro vývoj Gtk3 .. :(Toto zní jakoby měl Canonical nějaký vliv na vývoj GTK+. Jenže vzhledem k tomu, že nemá v upstreamu GNOME a GTK+ žádné vývojáře, je jeho vliv prakticky nulový. A samozřejně, že se Canonical rozhodl postavit svoje prostředí na Qt/QML. Ubuntu je jako primárně GTK+ distro už jen dočasně.
Na tabletu/mobilu Gtk nikdo nepoužívá.To je pravda. A Qt na tom neni o nic lepe. Blackberry jde do haje, a Sailfish a Ubuntu Phone se jeste nedostaly do pozice, kdy by vubec mohli rici, ze z toho haje vylezly. O zbytku, kde QML/Qt hraje treti ligu vedle nativniho toolkitu, nema smyslu vubec mluvit.
A copak se za par cyklu asi stane s GDK X backendem, az bude Wayland default...?
Taky tak. Vždycky když to používám tak z toho mám takovej divnej pocit. Když nad tím přemýšlím, tak celkově v poslední době těch Qt aplikací používám víc a víc Vůbec su poslední dobou s Linuxovým desktopem s KDE spokojenej. Momentálně mám uptime 29 dní, bez restartu KDE, padání nějaké aplikace, podivnejch grafickejch artefaktů a podobnej věcí. Prostě všechno krásně funguje
Tak tak , éra GTK zkončila u gtk2 a s nástupem gtk3 už všichni stejně přecházejí na QT. Nejde ani tak o KDE4 , když QT bude modulární tak stačí pár knihovniček a například na LXDE pojede hezkej shark a zabere to jen pár mega bez bordelu. http://www.youtube.com/watch?v=FIs5YqzS4Bc
skončila
Klamať je hriechMomentálně mám uptime 29 dní, bez restartu KDE, padání nějaké aplikace, podivnejch grafickejch artefaktů a podobnej věcí. Prostě všechno krásně funguje
Tak se to přejmenuje na GNOME toolkit
To, že na Windows si aplikace přibalí každá svou verzi Qt není problém Qt, ale problém Windows, resp. absence správy balíčků.Ne, to je problem vyvojaru SW, kteri nepouzivaji nativni toolkity.
jediny skutecne nativni toolkit na Windows je Win 32 APIPresne tak, a chodi i to na Linuxu .
Na Linuxu se to dela taky tak.Svatá pravda. Na Linuxu se taky „cizí živly“ snaží prasit, jak se dá, a používat postupy mimojiné naučené z Windows.
Moc bych nad vyuzivanim Qt nejasal. Uz jednou kousnul odprodej Nokii, kterou nasledne zariznul MS. Ted ji drzi a vyviji ciste komercni Digia, porad se prodava komercni licence a je otazka jak moc dobre, protoze to muze mit vliv na odstaveni prostredku pro dalsi vyvoj.
Imho na forknuti a vylepsovani tady neni potencial. Qt3 a KDE3 budiz prikladem.Btw. souhlas s kritikou C++ a to jak ho v tom frameworku ohli jako zatazeni mechanismu signalu a slotu.
Qt je ted pod open governance,Komicke je jak Digia tohle interpretuje podle toho s kym mluvi.
Takze ano, pokud to pusti Digia, bude to horsi.Nemyslim, ze to pusti.
Pokud umre BlackBerry, bude to horsi.Umre, s temihle prodeji neudrzi platformu, a nebo dopadne jako vyrobce marginalnich reseni.
Ted ji drzi a vyviji ciste komercni Digia, porad se prodava komercni licence a je otazka jak moc dobre, protoze to muze mit vliv na odstaveni prostredku pro dalsi vyvoj.Kam lidi chodí na názor, že se Qt neprodává. Viděli jste vůbec někdy finanční výsledky býv. Trolltechu?
Je mozne ze v QT existuji dva ruzne widgety, ktere implementuji metodu stejneho jmena, ktera neni zdedena od spolecneho predka.Pokud vím, tak tohle by se s QWidgety většinou stávat nemělo, od toho tam jsou takové ty různé QAbstract... věci.
Myslim ale, ze mas spis problemy s C++ jako takovym nez s QT.to je vic nez pravdepodobne, c++ me nijak nevoni, svet je ale zly a musim s tim pracovat. rad se ale dovim vice. Jestli jsem ty navrhy ohledne dedicnosti a toho ucebnicoveho pristupu spravne pochopil, tak udelam nasledujici. Nejdrve odvodim myWidget z QWidgetu. V tom napisu ty me virtualni metody. Pote odvodim z myWidgetu ty ostatni widgety, napr scrollarea->frame->label. Zopakuji vicemene to same, co udelali vyvojari Qt s temi vlastnimi widgety. A v tech konkretnich odvozenych widgetech pak implementuji ty konkretni metody. Je to takhle mysleno? Jen pro upresneni. Jsou jine toolkity, kde odvodim myWidget z nejakeho konkretniho , ktery je jiz soucasti toolkitu a v nem realizuji me metody. Tyto metody pak mohu pouzit v jakekoliv casti programu, aniz bych musel delat _cast_. Ten toolkit mi dava nejakou obecnou metodu k dispozici, pomoci ktere jine metody vyvolam. To je podle me inzenyrsky pristup.
Typicke reseni z OOP ucebnice je, aby myLabel a myButton meli stejneho predka myWidget, ktery nastav_pos_x() implementuje, tudiz pak neni potreba hadat, jestli je to pointer na jedno nebo na druhe, ale staci udelat dynamic_cast (nebo qobject_cast, jak bylo zmineno, ale ten je o neco pomalejsi nez standardni casty) na myWidget*