Portál AbcLinuxu, 7. května 2025 22:40
Tímto článkem startuje další pravidelný seriál na AbcLinuxu.cz, který shrnuje novinky ve vývoji KDE za poslední týden. Jedná se o oficiální překlad KDE Commit Digest. V tomto díle popisuje Aaron J. Seigo novinky v Plasmě a dojmy z oslav vydání KDE 4.0 v komplexu Google. Navíc se naučíte, jak napsat vlastního e-mailového klienta za 10 minut.
Do plasmového panelu byla přidána funkčnost Taskbaru a KMenu z KDE 3.5, společně s prací na hodinách v Plasmě, včetně přesunu plasmoidu binárních hodin do kdereview. Zlepšení podpory anotací v Okularu (jehož jméno teď oficiálně začíná velkým písmenem). Základní podpora pro prohlížení obsahu chyby v přepsaném KBugBuster. Více exportních formátů (CSV, HTML, ...) pro Kalzium. Implementace CVS v KDevelop se přesunula do Model/View frameworku. Začátek podpory JavaScriptu v Kst pluginu. Zlepšení použitelnosti Konsole. Mailody je upravováno jako služba pro Akonadi. Plugin pro hledání mirrorů v KGet. Práce na IPv6 v KTorrent. Zlepšení barevné palety v KOffice. Optimalizace v KDevelop a NEPOMUK. Různé změny v KJS a KHTML. Podpora MPRIS v Dragon Player, společně s přesunem z playground/multimedia do kdemultimedia pro KDE 4.1. Kopete Bonjour protokol byl přesunut do kdereview. Kopie Qt v KDE SVN byla updatována na verzi kompatibilní s GPLv3.
Aaron Seigo hovořil o Plasmě a akci pořádané u příležitosti vydání KDE 4.0.0:
Vývoj Plasmy v současnosti zuřivě zrychluje, s důrazem na čištění kódu ve verzi 4.0. Za minulý měsíc bylo uzavřeno 145 chyb.
Graf nahoře ukazuje rostoucí podíl uzavřených chyb - šplhá dost solidním tempem. Následující obrázek (díky Simonu St Jamesovi!) ukazuje veškeré commity (green), jen ty týkající se kódu (červené) a ty, které se týkají Plasmy (žluté). Za poslední rok se commity týkající se Plasmy skutečně vyjímají, jak můžete vidět.
No a co všechno jsme vlastně udělali? Mimo opravování chyb po tunách jsme doplňovali chybějící vlastnosti do taskbaru, například více řádků oken (vše je krásně animováno) a "zobraz pouze okna z této plochy". Nahrávání ikon na ploše bylo výrazně upraveno, stejně jako výkon mnoha komponent Plasmy.
Nedávno byla přidána podpora skriptování pro DataEngines a Runners a počet plasmoidů narůstá. Pokračující vývoj pomáhá stabilizovat knihovny Plasmy. Například mě vůbec nenapadlo, kolik plasmoidů bude potřebovat udržovat přesně čtvercový tvar.
V průbehu této skvělé práce jsme také navštívili KDE 4.0 Release Event v Mountain View v Kalifornii. Díky Googlu za fantastickou pomoc při organizaci a financování, protože setkání bylo skutečně úchvatné. Prezentace byly živě vysílány do celého světa a nyní jsou dostupné na Google Video. Viděl jsem fotky z úvodní řeči na stěnách v německých hospodách, takže vím, že vysílání skutečně fungovalo.
Bylo báječné vidět tam oba typy lidí: jak hard core vývojáře (včetně vývojářů jádra), tak i členy komunity. Pro mě bylo hlavním zážitkem první karaoke vystoupení Patricka Volkderdinga a víno se značkou KDE (díky Celeste!), skutečně úžasní maskoti Konqi a Katie a naslouchání lidem kolem KDE, kteří přišli vyjádřit, jak moc těsně jsou s projektem svázáni.
Bylo to pro mě trochu hektické, jelikož setkání trvala až do noci. A to bylo pochopitelně přesně to, proč jsem tam byl: být na očích, spojit komunitu a udělat něco, co by bylo hodno takového vydání.
Bude to těžké překonat, ale zase nevydáváme 4.0 každý rok. Nicméně to to vypadá, že budeme na začátku každého roku dělat setkání KDE Americas - jako protiváhu setkáním Akademy uprostřed roku.
Ve speciálním článečku pro digest ukazuje Tom Albers z Mailody, "Jak napsat e-mailového klienta za 10 minut".
V současnosti vývojáři Mailody pracují na přepisu Mailody, aby fungoval jako Akonadi backend. Akonadi je desktopově nezávislá služba pro ukládání PIM informací [PIM Storage Service]. V zasadě funguje jako cache nebo proxy, chcete-li.
Na jedné straně do toho můžete dávat věci. To zajišťují aplikace nebo zdroje. Takovým zdrojem může být jednoduchý Maildir; Mailody pracuje na knihovně pro IMAP, zdroj z NNTP a tak dále. Na straně druhé poskytuje způsob, jak dostat data do aplikace, která je chce používat. A to ne pouze PIM aplikacím, ale například strigi může v datech jednoduše vyhledávat a nedávno jsem zahlédl někoho, jak se zajímá o SyncML.
Byli jsme (vývojáři Mailody) překvapeni, jak jednoduše lze zobrazit data v Akonadi. To, jak se tam dostanou, je mimo záběr tohoto článku, ale k tomu se vrátím později. Pro teď prostě budeme předpokládat, že data už v Akonadi jsou, například ze zdroje Maildir, který jednoduše čte e-maily, které máte ve formátu Maildir.
Teď si ukážeme, jak napsat e-mailového klienta, nebo raději, pro jednoduchost, čtečku e-mailů. Za prvé se podívejme, co je třeba pro základního klienta. Pokud se podíváme na tradiční klienty, zjistíme, že jsou obvykle sestaveny ze tří částí: potřebujeme náhled na složky na straně levé, zobrazení hlaviček zpráv vpravo a zobrazení těla zpráv vpravo dole.
Seznam složek. Složka je reprezentována v Akonadi typem Collection [kolekce]. Ty obsahují název, který má být zobrazen, vnitřní hodnotu, kterou můžete namapovat na váš zdroj, a věci jako počet nepřečtených zpráv. Akonadi nabízí funkce pro získání všech těchto Collection z daného zdroje, ale jde ještě dále, protože zároveň poskytuje modely a pohledy přípravené k použití.
Takže, takto vypadá hlavní widget:
{ QHBoxLayout *layout = new QHBoxLayout( this ); QSplitter *splitter = new QSplitter( Qt::Horizontal, this ); layout->addWidget( splitter ); mCollectionList = new Akonadi::CollectionView(); connect( mCollectionList, SIGNAL(clicked(QModelIndex)), \ SLOT(collectionActivated(QModelIndex)) ); splitter->addWidget( mCollectionList ); mCollectionModel = new Akonadi::CollectionModel( this ); mCollectionProxyModel = new Akonadi::CollectionFilterProxyModel( this ); mCollectionProxyModel->setSourceModel( mCollectionModel ); mCollectionList->setModel( mCollectionProxyModel ); }
To je všechno. Teď můžeme zobrazit seznam na levé straně. Pokud chcete vidět sloupeček nepřečtených zpráv a jejich celkový počet, použijte místo toho Akonadi::MessageCollectionModel. Proxy je v kódu proto, že Akonadi umožňuje pracovat s různými typy kolekcí. Může například udržovat informace o informacích z vcard. Protože nechceme tyto informace vidět v e-mailovém klientu (alespoň v tomto případě), můžeme do kódu přidat m_folderProxyModel->addMimeType("message/rfc822");
.
Další na řadě je seznam hlaviček. Akonadi poskytuje model i pro tuhle vlastnost. Ten může být aplikován na standardní QTreeView. Ale zřejmě chceme mít zprávy řazené podle vláken, aby bylo snadno poznat, které zprávy odpovídají na jiné. A zde máme seznam hlaviček:
QSplitter *rightSplitter = new QSplitter( Qt::Vertical, this ); splitter->addWidget( rightSplitter ); mMessageList = new QTreeView( this ); mMessageList->setDragEnabled( true ); mMessageList->setSelectionMode( QAbstractItemView::ExtendedSelection ); connect( mMessageList, SIGNAL(clicked(QModelIndex)), SLOT(itemActivated(QModelIndex)) ); rightSplitter->addWidget( mMessageList ); mMessageModel = new Akonadi::MessageModel( this ); mMessageProxyModel = new Akonadi::MessageThreaderProxyModel( this ); mMessageProxyModel->setSourceModel( mMessageModel ); mMessageList->setModel( mMessageProxyModel );
Zobrazení zpráv necháme jednoduché. Snad jste nečekali, že tohle bude kompletní e-mailový klient, ne?
mMessageView = new QTextEdit( this ); rightSplitter->addWidget( mMessageView );
Tak, to je základní zobrazení položek. Pochopitelně ještě potřebujeme implementovat dva sloty. CollectionActivated
zajistí, že budou zobrazeny správné hlavičky, pokud kliknete na Collection
. Pamatujte, že v našem případě termín Collection
znamená složku.
mCurrentCollectionId = mCollectionList->model()->data( index, CollectionModel::CollectionIdRole ).toInt(); mMessageModel->setCollection( Collection( mCurrentCollectionId ) );
Ostatní sloty ukazují správné zprávy, pokud kliknete na hlavičku. Ve skutečnosti to vytvoří KJob
pro získání hlavičky z Akonadi. Může se stát, že Akonadi nemá celou zprávu. Pro tento případ se zeptá zdroje na chybějící část a nakonec zavolá itemFetchDone
.
DataReference ref = mMessageModel->referenceForIndex( mMessageProxyModel->mapToSource( index ) ); ItemFetchJob *job = new ItemFetchJob( ref, this ); job->addFetchPart( Item::PartBody ); connect( job, SIGNAL( result(KJob*) ), SLOT( itemFetchDone(KJob*) ) ); job->start();
Možná jste zmateni použitím DataReference. Zpráva je reprezentována jako Akonadi::Item, která obdrží aktuální informace, například pomocí payload funkce. K odkázání se na konkrétní položku v kolekci je použit právě DataReference
, což je v podstatě unikátní ID. V našem případě můžete jako unikátní klíč použít jméno schránky v kombinaci s ID zprávy nebo uid.
Když data dorazí, můžeme je zobrazit uživateli:
ItemFetchJob *fetch = static_cast<ItemFetchJob*>( job ); if ( job->error() ) { qWarning() << "Mail fetch failed: " << job->errorString(); } else if ( fetch->items().isEmpty() ) { qWarning() << "No mail found!"; } else { const Item item = fetch->items().first(); mMessageView->setPlainText( item.part( Item::PartBody ) ); }
To je vše. Nyní máte základní čtečku e-mailů. Vsadím se, že to zabralo méně než 10 minut. Jak jistě pochopíte, tak přepsání stávajícího klienta pro použití s Akonadi představuje mnohem více práce. Ale je to legrace, odstraňovat většinu vlastního kódu (není to skutečný význam fráze 'požírání vlastních dětí'??) a nahrazovat to za prvky Akonadi.
Pochopitelně, pokud máte tento základ, chcete jej rozšířit tak, aby toho uměl více. Ale to můžete udělat velice snadno, například napsáním delegátu. Věřím, že vás tohle "how to" inspiruje buď k sepsání vlastního klienta, nebo k zapojení se do týmu Mailody či Akonadi.
Poznámka: předchozí úryvky kódu pocházejí z e-mailového klienta, který je součástí Akonadi. Můžete jej nalézt v KDE SVN. Jmenuje se Akonamail a napsal jej Bruno Virlet.
Post-KDE 4.0 příval commitů pokračoval tento týden s 3043 kousky. Část tohoto nárůstu může být vysvětlena návratem vývojových větví (po několika letech méně striktního vývoje), přičemž některé vlastnosti a opravy chyb jsou prováděny v trunk/
a pak backportovány do hlavní větve KDE 4.0, což způsobí dva commity pro jedinou změnu.
To však není všechno... je tu něco jiného, něco, co nemůžu podchytit pouhou statistikou. V současnosti to ve vývoji KDE skutečně vře. Živá atmosféra, která je zřetelná všude, od IRC po SVN.
Více commitů znamená více práce pro mě, ale rozhodně si nestěžuji.
Pozn. redakce: Další díly budou obsahovat i statistiky a zároveň se objeví na oficiálních stránkách KDE Commit Digest (součástí naší snahy bude i přeložení uživatelského rozhraní stránek).
Zapomněl jste ukončit to červené zvýraznění.Kde? Mám pocit, že obě oblasti jsou uzavřené.
pošli příkaz_X if (výstup_X není prázdný) then print výstup_X else print "tvůj systém je nahovno" filepší chování by imho bylo:
pošli příkaz_X if (výstup_X není prázdný) then print výstup_X else print "příkaz_X selhal, systém nepodporuje debugging threadů, máš ladicí informace k libpthread?" pošli příkaz_Y if (výstup_Y není prázdný) then print výstup_Y else print "příkaz_Y selhal" fi fiale ne, KDE tým má moc práce, takže když se přijde na to, že chyba je spíš na straně prostředí (a chybou KDE je, že se spoléhá na nějakou vlastnost prostředí, která nemusí být splněna), tak se z toho nemůže udělat enhancement wish, nýbrž chyba se musí označit jako INVALID, aby nám rostlo číslo ve statistice uzavřených chyb! blé
Mno, kdyz si to rozebereme -- v tebou zminenem bugu jde o to, ze ti gdb nedava dobry vysledek. a domnivas se, ze za to muze KDE, coz je IMHO pomerne odvazna predstava,domnívám se, že když KDE chce něco použít, mělo by si zkontrolovat, že to funguje, neboli jak už jsem řekl: "you can never ever rely on the assumption that the things work as expected; for example, if somebody writes code for opening a file, a check whether the operation went ok (so that the program does not crash on using a null handle) is a must and I bet you wouldn't argue"
Pak tam taky doporucujes, aby DrKonqi rikal uzivatelum, jak povolit debuggovaci symboly, coz je IMHO nerealne, nebot se to na kazdem distru dela uplne jinak. Takze jedine nejakym patchem primo od tve oblibene distribuce.to není tak úplně přesné - já bych byl rád, aby místo obecné hlášky o tom, že balíčky byly sestaveny způsobem, který neumožňuje vytvoření backtracu, řekl, co konkrétně mu selhalo ... jak to napravit, ať už si uživatel zjistí sám dostat tuto hlášku poté, co člověk poctivě šel podle návodu, a co si pomocí ručně puštěného gdb ověřil, že backtrace bez samých otazníků lze vygenerovat, je velmi frustrující ...
Tvuj nazor I am reopening the bug: in comment #2 you say "The posted backtraces should not be marked as useless though." - so, if there is a way to get an useful backtrace but drkonqi fails to do so, it's drkonqi's fault IMHO neni konzistentni -- Lubos rekl, ze by DrKonqi nemel tomu tracu rikat "na nic", ale ty z toho usuzujes, ze ma DrKonqi nejaky zpusob, jak ten platny backtrace vygenerovat.já to nevyvozuju z toho co řekl, ale z kontextu, desinterpretuješ tu větu - je to o tom, že DrKonqi právě ten funkční způsob nepoužívá, ačkoliv by mohl (jako alternativu ke svému defaultnímu způsobu), funkční způsob existuje
domnívám se, že když KDE chce něco použít, mělo by si zkontrolovat, že to funguje, neboli jak už jsem řekl: "you can never ever rely on the assumption that the things work as expected; for example, if somebody writes code for opening a file, a check whether the operation went ok (so that the program does not crash on using a null handle) is a must and I bet you wouldn't argue"Rozdil je v tom, ze funkce "otevri soubor" ma velice dobre definovane prostredky jak rict, ze se to nepodarilo, zatimco gdb neumi (AFAIK) oznamit "promin, neco ve mne shnilo, prikaz 'thread apply all bt' selhal, ale 'bt' by *mozna* mohlo -- s troochou stesti -- vyjit".
to není tak úplně přesné - já bych byl rád, aby místo obecné hlášky o tom, že balíčky byly sestaveny způsobem, který neumožňuje vytvoření backtracu, řekl, co konkrétně mu selhalo ... jak to napravit, ať už si uživatel zjistí sámBez za autory gdb, at to pridaji do gdb. DrKonqui to nemuze odnikud vydolovat.
já to nevyvozuju z toho co řekl, ale z kontextu, desinterpretuješ tu větu - je to o tom, že DrKonqi právě ten funkční způsob nepoužívá, ačkoliv by mohl (jako alternativu ke svému defaultnímu způsobu), funkční způsob existujeA jak se gdb chova, kdyz reknes `bt` programu, ktery ma vice vlaken?
Rozdil je v tom, ze funkce "otevri soubor" ma velice dobre definovane prostredky jak rict, ze se to nepodarilo, zatimco gdb neumi (AFAIK) oznamit "promin, neco ve mne shnilo, prikaz 'thread apply all bt' selhal, ale 'bt' by *mozna* mohlo -- s troochou stesti -- vyjit".to už trochu fantazíruješ, ne? - nebo snad funkce "otevři soubor" umí oznámit "... ale 'otevři soubor jinak' by *možná* mohlo -- s troochou štěstí -- vyjít"? btw, co se týče "velice dobře definované prostředky jak říct, že se něco nepodařilo" vs "neumí oznámit ..." - to snad nemyslíš vážně, že porovnat výstup, jestli náhodou není null, u otvírání souboru jde, ale zjistit, jestli náhodou není délka výstupního řetězce nulová, u komunikace s gdb nejde
WTF? DrKonqi nemůže odnikud vydolovat informaci, že mu příkaz "thread apply all bt" selhal? (a že možná příčina je chybějící debug pro libpthread?) proč meleš takové píčoviny?to není tak úplně přesné - já bych byl rád, aby místo obecné hlášky o tom, že balíčky byly sestaveny způsobem, který neumožňuje vytvoření backtracu, řekl, co konkrétně mu selhalo ... jak to napravit, ať už si uživatel zjistí sámBez za autory gdb, at to pridaji do gdb. DrKonqui to nemuze odnikud vydolovat.
A jak se gdb chova, kdyz reknes `bt` programu, ktery ma vice vlaken?kdyby ses namáhal přečíst si ten bugreport, tak by ses na to nemusel ptát, protože kompletní výstup gdb je v přílohách - tobě ovšem zjevně stačilo vybrat si pár vět, abys totálním vytrháním z kontextu mohl dokazovat, že uživatel toužící po tom, aby se program choval slušně, tj. měl korektně ošetřené možné chybové stavy a nelhal uživateli, je pitomec, kdežto vývojáři mají vždycky pravdu svatou ... ale že já jsem se vůbec namáhal prvotně reagovat, že hodnotíš věci nikoliv na základě fakt, ale podle toho, jestli je říká uživatel nebo vývojář, jsme viděli nedávno, když si kolega dovolil otřít se o Gentoo ...
ale ne, KDE tým má moc práce, takže když se přijde na to, že chyba je spíš na straně prostředí (a chybou KDE je, že se spoléhá na nějakou vlastnost prostředí, která nemusí být splněna), tak se z toho nemůže udělat enhancement wish, nýbrž chyba se musí označit jako INVALID, aby nám rostlo číslo ve statistice uzavřených chyb!Resp. reknu to jinak -- co mel DrKonqui udelat jinak, aby dostal platny backtrace? Myslim, ze pokud do toho bugreportu napises "ok, current way DrKonqui does it sucks, because it didn't work for me while this command when inside gdb worked", tak se opravy dockas.
Resp. reknu to jinak -- co mel DrKonqui udelat jinak, aby dostal platny backtrace?poté, co od příkazů
thread
a thread apply all backtrace
dostane pouze prázdný výstup, měl by zkusit backtrace
(bez toho thread), tím jsem vygeneroval backtracy v reportu přiložené, o kterých se Luboš vyjádřil, že tak úplně k ničemu nejsou (přesněji "The posted backtraces should not be marked as useless though.")
Myslim, ze pokud do toho bugreportu napises "ok, current way DrKonqui does it sucks, because it didn't work for me while this command when inside gdb worked", tak se opravy dockas.myslímže co a jak funguje je tam popsáno dostatečně ...
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.