Firma X zaslala předžalobní výzvu vývojáři projektu Nitter (Wikipedia), open-source alternativního frontendu k sociální síti X (ex-Twitter), a provozovatelům instancí jako XCancel, které umožňovaly číst příspěvky bez přihlášení, reklam a javascriptu. Údajně se dopouštějí „sběru dat“. Zdrojový kód Nitteru vývojář archivoval. Vývoj již dříve přerušil v roce 2024 po tehdejším omezení API X. X je dceřiná společnost SpaceXAI Elona Muska, provozující mj. kontroverzního chatbota Grok.
Bylo vydáno Ubuntu 26.04.1 LTS, tj. první opravné vydání Ubuntu 26.04 LTS s kódovým názvem Resolute Raccoon. Přehled novinek a oprav na Discourse.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal Zprávu o stavu kybernetické bezpečnosti ČR za rok 2025 (pdf). Incidentů ubylo, sofistikovanost útočníků roste.
Open source softwarový stack AMD ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán v nové major verzi 10.0. S ROCm.AI. Přehled novinek v aktualizované dokumentaci.
Finanční skupina Partners se stala minulou neděli obětí kybernetického útoku, při kterém se útočníci dostali k některým osobním údajům klientů. Společnost o tom informovala ve čtvrtek. Ujišťuje, že peníze klientů nejsou v ohrožení. „Kybernetický útok zasáhl část IT infrastruktury naší společnosti. Ihned po zjištění útoku jsme s pomocí externích bezpečnostních odborníků začali intenzivně pracovat na minimalizaci škod. Útočníci se
… více »Americká technologická společnost Meta Platforms se dohodla, že zaplatí až zhruba 18 miliard dolarů (asi 373 miliard Kč) za mimosoudní urovnání sporu o závislosti dětí na sociálních sítích a provede významné změny pro jejich používání mladistvými. Téměř tři desítky států USA firmu v roce 2023 obvinily z toho, že sítě Facebook a Instagram vědomě navrhla tak, aby u dětí vyvolávaly závislost, a zatajovala tyto dopady před veřejností. Firma se
… více »Byl publikován aktuální přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Blíží se vydání podporující čipy M3. Vývojáře lze podpořit na GitHub Sponsors a Open Collective.
Kancelářský balík LibreOffice byl vydán ve verzi 26.8. Mimo jiné vylepšuje typografii a kompatibilitu s formáty MS Office, více v poznámkách k vydání.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 26.8. Přehled novinek v poznámkách k vydání.
Byla vydána nová verze 23.1.0, tj. první stabilní verze z nové řady 23.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools, Libc++, Polly a Flang.
10.8.2007 17:55
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
jak bez X? To nejde ne?
Qtopia neni knihovna, ale platforma pouzivajici Qt/Embedded.Díky za opravu, doteď jsem si totiž myslel, že Qtopia je platforma i knihovna, takže jsem zas o něco chytřejší.
Jinak na to 'zahodit X' si staci najit Googlem jeden z tech asi milion pripadu, kdyz uz nekdo dostal tenhle napad driv.Ale já X nechtěl zahodit, já jenom chtěl upozornit na ten fakt, že by nebyl velký problém obě knihovny zprovoznit i bez něj.
10.8.2007 21:01
Josef Kufner | skóre: 70
10.8.2007 19:45
Jardík | skóre: 40
| blog: jarda_bloguje
11.8.2007 10:11
brk | skóre: 29
| blog: broukoviny
11.8.2007 14:42
Petr Tomášek | skóre: 39
| blog: Vejšplechty
To tady opravdu všichni souhlasí s tím, že vykreslování widgetů bez podpory X je výhoda?Podle toho komentáře se zdá, že s tím souhlasím? Mmm...
Staci si nastavit lehci tema (mene prechodu a obrazku) a RLE komprese zaruci velmi dobry vysledek.To je přesně to, čemu je potřeba se vyhnout. Dneska je uživatel zvyklý na to, že GUI aplikace pěkně vypadají a jsou interaktivní. Omezenost AJAXových aplikací zatím uživatelé tolerují, protože přístup odkudkoli tuto nevýhodu (zatím) vyváží, navíc AJAXové aplikace (nebo obecně tencí klienti) se používají na aplikace s jednoduchým GUI. Takže zatím to uživatelé tolerují. Ale „nastavte si jednoduché hranaté ošklivé téma“ rozhodně není marketingový hit, kterým přesvědčíte uživatele.
PS 2: A jake ty vyhody mi X server nabizi?
Doufam ze si nepletete X server a webovy prohlizecNepletu. Jenom si jaksi nemůžu nevšimnout, že se webový prohlížeč dnes často používá k tomu, k čemu byl zamýšlen X server. A používá se k tomu mimo jiné právě proto, že umí nakreslit třeba tlačítko a postarat se o něj komplet – na kliknutí zareagovat jeho překreslením ve zmáčknutém stavu, na získání focusu reagovat vykreslením rámečku atd. Webový prohlížeč ale není ten správný nástroj, který by tohle měl dělat – tohle je úloha právě pro X server (nebo nějakého jeho nástupce). Mimochodem, když jste takový zastánce obrázků – proč se někdo vůbec patlá s nějakými webovými stránkami a webovými aplikacemi v HTML? Vždyť by stačilo na serveru vše vyrenderovat jako obrázek a poslat to do prohlížeče, ne? Odpadly by problémy s různými nekompatibilitami prohlížečů. Aby bylo jasné, kam tím mířím, a abych zase nebyl podezírán ze záměny X serveru a webového prohlížeče – jaký je pro uživatele rozdíl mezi Thunderbirdem a Gmailem? Nechtěl by nakonec uživatel aplikaci, kterou bude mít dostupnou odevšad s nějakým minimálním vybavením (jako je Gmail), ale zároveň interaktivní a s propracovaným GUI, jako je (ehm, skoro) Thunderbird?
Antialiasing si aplikace stejne pocita sama, aspon u pisma.No právě, to je špatně. Co s tím pak má chudák X server dělat, když už to dostane zmršené od aplikace? To pak uživatel klidně může po X serveru chtít zvětšit (lupou) okno, ale když tam X server má jenom černé fleky s duhovými okraji, zpátky z toho nevyčaruje písmo, které by teď mohl vykreslit s daleko prokreslenějšími detaily.
Jenze X Server neni zadny vektorovy graficky server. Stara se o pixely tak mu aplikace musi ty pixely poslat, nebo poslat co se ma kde rasterizovat. Podle me by X server vubec nemelo zajimat, co se v dane aplikaci nachazi, to je ciste vec aplikace a tento obsah se muze menit.X Server je právě „podobojí“, část je vektorová (např. právě okna) a část bitmapová. Budoucnost je podle mne ve vektorovém GUI, a cesta „část vektorová, část bitmapová“ k vektorům přes plně bitmapový desktop mi připadá trochu zvláštní
11.8.2007 22:51
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Dá se to očekávat od Applu, Windows s tím budou muset přijít taky, tak by nemusel být Linux ten třetí vzadu, ne? První krok se povedl celkem dobře, ale aby to tím neskončilo…Naštěstí linux != KDE/Qt... (Vývoj gtk založeného na CAIRu mi v tomto příjde docela slibný...)
Naštěstí linux != KDE/Qt... (Vývoj gtk založeného na CAIRu mi v tomto příjde docela slibný...)To jsem rád, tenhle vývoj jsem nezaznamenal. Tak alespoň něco nadějného…
zjistit, pod krerym detskym oknem se momentalne nachazi kurzor mysi je pro toolkit naprosta malickostto je právě to, co si nemyslím, při větším počtu widgetů už se vyplatí použít nějaký rafinovaný algoritmus, zanedlouho bude také možné použít pro některé výpočty přímo grafickou kartu (ono už to možné je - viz. např. nejnovější počiny NVIDIE), k níž má přístup X server, takže by pak CPU nebylo vůbec zatěžováno, těchto výhod bychom bez X serveru jen těžko mohli v budoucnu využít
a co treba list view, tree view nebo dalsi komplexni widgety?Tam už musí počítat knihovna, to je pravda.
Pri vetsim poctu widgetu bude pro aplikaci vyhodnejsi, kdyz si je bude spravovat sama, protoze si ten algoritmus muze implementovat a optimalizovat pro sve potreby, neni tak?Není
Protože pak každá knihovna bude mít svůj algoritmus, který musí počítat naslepo (aniž by cokoli tušil o zobrazovacím zařízení nebo ostatních oknech). Zatímco X server má právě přehled o celém desktopu, takže dokáže daleko lépe určit, co je nutné kreslit a co ne. Navíc způsobu, jak dělat knihovny widgetů, není zas tolik, aby ty knihovní algoritmy byly nějak moc rozdílné. Takže ten optimalizovaný algoritmus by byl ve všech knihovnách plus mínus stejný – no a to může být rovnou v X serveru.
Není
- Predstavte si, ze by WWW prohlizec posilal kazdy TAG X serveru.
- Aplikace si prece muze zjistit informace o zobrazovacim zarizeni a pozadovanem vystupu (treba pismo pomoci FontConfig(u), bitova hloubka, rozliseni, DPI, ...)
Zatímco X server má právě přehled o celém desktopu, takže dokáže daleko lépe určit, co je nutné kreslit a co ne. Navíc způsobu, jak dělat knihovny widgetů, není zas tolik, aby ty knihovní algoritmy byly nějak moc rozdílné. Takže ten optimalizovaný algoritmus by byl ve všech knihovnách plus mínus stejný – no a to může být rovnou v X serveru.V dobe double-bufferu nema smysl urcovat, co je treba prekreslit a co ne, proste se pouzije double-buffer a aplikace o prekresleni ani nemusi vedet (viz nektere jine prispevky)...
Kdyby nebyl toolkit schopny urcit pod kterym detskym oknem je mys, tak nevim jak by fungovala treba propagace udalosti ( tu si uz resi toolkit sam, pokud vim:) )Pokud vim, tak nektere udalosti posila widgetum primo X server a toolkit je jen preklada na neco srozumitelnejsiho, pripade na zaklade nich generuje dalsi udalosti. Tento koncept je pekne videt na knihovne GTK, kde je kazdy objekt window X serveru obalen GdkWindow a u kazde widgety z GTK na pozadi stoji prave jiz zmineny GdkWindow. Je tam take patrne rozliseni udalosti, ktere jdou z X serveru - napr. expose-event a signálů, které už z X serveru nejdou, ale jsou syntetizovány na základě událostí X serveru - např. clicked.
No jo, ale ja myslim propagaci udalosti, ktera prisla z X serveru. Prijde mi treba udalost "Zmacknuta klavesa X" a dane okno ji nezpracuje (nechce ji), tak toolkit tuto udalost propaguje urcitym smerem dal do jinych oken (vetsinou asi rodic).Ano, vetsinou jde udalost smerem k rodici, jenze ja reagoval na nasledujici tvrzeni:
Kdyby nebyl toolkit schopny urcit pod kterym detskym oknem je mys, tak nevim jak by fungovala treba propagace udalosti ( tu si uz resi toolkit sam, pokud vim:) )Toolkit totiz pri "zmacknuti klavesy X" nepotrebuje vedet, nad kterou widgetou je mys, protoze mu staci vedet, ktera widgeta ma focus.
Toolkit totiz pri "zmacknuti klavesy X" nepotrebuje vedet, nad kterou widgetou je mys, protoze mu staci vedet, ktera widgeta ma focus.Mel jsem spis napsat, co kdyz zmacknu tlacitko mysi (treba rolovaci tlacitko), tady uz je to snad vice logicke:)
Mel jsem spis napsat, co kdyz zmacknu tlacitko mysi (treba rolovaci tlacitko), tady uz je to snad vice logicke:)Jenze, kdyz zmacknete tlacitko mysi nebo hybnete mysi, tak tu udalost te widgete nad kterou je ukazatel mysi posila opet X server. Jmenovite: button-press-event, button-release-event, pripadne motion-notify-event.
Ve Windows, kde pomalu každá druhá aplikace vypadá naprosto jinak a používá své vlastní skiny a thémata (místo systémových), opravdu musí straaašně záležet na sebemenším detailu
Linux (či FreeBSD) je oproti Windows v tomhle směru na tom přímo výborně.
Nechci aby to vypadalo, ze se zastavam Qt, ale mnohokrat jsem se dival do jejich zdrojaku a odvedli proste vybornou praci.
Ale samozřejmě, že to možné je kreslit prvky. Jen ten výsledek bude polofunkční a nebude zaručen nativní vzhled.Jenže ten výsledek je funkční už dnes, přijde mi, že se se mnou hádáte, aniž by jste Qt pod Windows zkusil (stačí nějaká Qt aplikace)
Jinak P.R. řeči (věřte mi, že je taky umím) ve stylu "firma X.Y. věnovala velké úsilí" jsou moc hezké, stejně tak jako "mají dávno hotové" a "odvedli výbornou práci". Nejsem s prominutím pitomec a Win API znám jako vlastní boty. Pokud Trolltech používá nativní "Windows podokna" (abych se tak trochu vyjádřil ve Vašem stylu, pak odvedli dobrou práci a bude to fungovat ke spokojenosti. Pokud si místo toho kreslí ve Windows vše do jednoho okna, pak sorry - vždycky to bude dřít. Můžete mi tu napsat tisíc stránek dalších P.R. řečí na Qt a Trolltech, ale budou to jen plané lži. Oblbujte si prosím jiné lidi.AAaaaano, samozrejme mate vzdycky pravdu a neco jako Qt udelate za tyden ze
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz #include [QApplication] // zavorky jsou umyslne upravene
#include [QPushButton]
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QPushButton hello("Hello world!");
hello.resize(100, 30);
hello.show();
return app.exec();
}
Ve Windows pokud vim NENI mozne, aby bylo tlacitko top-level okno, ale v Qt to jde. Pokud program zkompilujete a podivate se na nej pres Spy++, tak uvidite jen jedno HWND a to je vse. Netvrdim, ze vim vsechno, ale v teto konkretni veci jsem si na 100% jist.
take se loucim v teto diskuzi:_)
Pokud je pravda, co rikate, tak by Qt nemohlo ve Windows vypadat nativne. Jsem si 100% jist, ze bude vypadat nativne i kdyz bude systemove jen jendo top-level okno.Nebude. Javovský Swing řeší to samé – už existují témata, která emulují vzhled Windows nebo GTK. Jenže pořád, když se upraví téma nativních Windows nebo GTK, musí se upravit i to emulované téma. A hlavně – to že aplikace zapadne do nějaké platformy neznamená jen to, jak bude vypadat, ale i jak se bude chovat – tedy to feel z look-and-feel. Na Linuxu to nebude takový problém, tam je feel dáno použitým toolkitem, takže se liší aplikaci od aplikace, ale na Windows nebo MacOS je feel jednotné v celém systému. A obávám se, že konkrétně ve Windows některé specialitky nepůjde ani emulovat, protože jsou zadrátovány někde v systému a není k nim k dispozici veřejné API.
Tiskni
Sdílej:
