FOSDEM 2025:Qtのハイライト
3月 07, 2025 by Qt Group 日本オフィス | Comments
Diclaimer: 私たちの代理としてFOSDEMに参加したすべての人々が、この記事の共著者です。
このブログは「FOSDEM 2025: Our Qt Highlights」を翻訳・一部加筆したものです。
2024年、Pedro Bessa がコーディネートするグループがFOSDEMを訪れ、オープンソースとフリーソフトウェアのコミュニティとのつながりを深める取り組みを始めることにしました。
今年は、単にイベントに参加するだけでなく、PedroはCristián Maureira-FredesとFabian Kosmaleと共に、FOSDEMにQtプロジェクトの代表として参加するために、ブースを申請しました。
嬉しいことに、私たちは選ばれました!以下は、FOSDEM 2025 で私たちが目撃したすべてのことの詳細なレポートです。
(左から Emilia Valkonen-Damjanovic、Pedro Bessa、Cristián Maureira-Fredes、Sami Shalayel、Moss Heim)
Qt プロジェクトと Qt Group
Qt プロジェクトは、Qt ソフトウェアフレームワークの開発を調整するためのオープンなコラボレーションの取り組みです。歴史的に見ても、Qt プロジェクトのメンテナーや承認者の多くは、商用ライセンスの権利を持つ企業に所属しており、その企業は開発者の雇用、インフラの維持などを通じてプロジェクトを支えています。現在、その役割を担っているのが Qt Groupです。
オープンソースの独立した組織が存在することは非常に有益です。なぜなら、イベントの性質がコミュニティ寄りか商業寄りかに応じて、さまざまなグループやイベントにアプローチする機会を得られるからです。今回、FOSDEM はヨーロッパ最大のオープンソース・フリーソフトウェアイベントであり、コミュニティやエコシステムの幅広い層と交流する貴重な機会となりました。
会場とイベントの規模
FOSDEM は、ブリュッセル自由大学(Université Libre de Bruxelles)のソルボシュ・キャンパスに 8,000 人以上の来場者を迎える予定でした。イベントはキャンパス内の 7 つの建物を使用し、広大なエリアに議論を交わす人々があふれていました。
意外にも、会場の空間設計が非常にうまく機能していることがわかりました。例えば、キャンパスの通りには多様な種類の料理(グルテンを多く含むものが多かったですが)や飲み物を提供するフードトラックが並び、ランチを楽しめるようになっていました。さらに、カフェテリアや、コーヒーや飲み物を販売するポイントもいくつか設置されていました。
他の多くのイベントと同様に、FOSDEM のボランティアは特定の色やデザインの T シャツを着ており、見つけやすくなっていました。実際、ボランティアが周囲にいない場所はほとんどなく、常に誰かが参加者や出展者のサポートをしてくれるという安心感がありました。
展示スタンドは 6 つの建物にまたがり、合計 88 ブースが設置されていました。その中で私たちが選ばれたのは非常に幸運なことでした。では、展示スタンドについてお話ししましょう。
FOSDEMの スタンド
展示スタンドの全リストはこちらで確認できます。Qt プロジェクトのブースは K 棟の 1 階にあり、幸運なことにクロークルームの隣に配置されていました。そのため、スーツケースやジャケットを預けるために訪れる多くの来場者が私たちのブースの前を通り、結果として多くの注目を集めることができました。
FOSDEM は、プロジェクトの開発者や関係者と直接交流できる貴重なネットワーキングの場でもあります。そのため、多くのプロジェクトが可能な限り多くのメンバーを派遣し、2 日間を通して交代しながらブースを運営します。来場者はお気に入りのプロジェクトのメンバーに会うため、何度も同じブースを訪れることがあり、実際に私たちのブースにも何度も足を運んでくださる方がいました。
私たちは特に Qt を活用しているプロジェクトに注目していましたが、実際に多くのプロジェクトが Qt を採用していました!イベントには Qt を活用するプロジェクトが数多く参加しており、そのブースを訪れて直接話を聞く機会を得られたのは非常に貴重でした。
その中のいくつかをご紹介します。
- Overte(Qt5 を使って UI を構築した大規模なインタラクティブ 3D ワールド。Qt6への移行作業を行ってい
- Linux on Mobile(Qt を使って開発されたスマートウォッチの展示)
- FreeCAD (Qt を使用した 3D パラメトリック モデラーのデモ)
- GNURadio (Qt を使って構築された UI とプロジェクトの紹介)
- VideoLAN (Qt で構築された VLC プレーヤーの展示)
- KDE (Qt で作成されたいくつかのデモ:Steam Deck、Krita、Plasma Mobile、Plasma Desktop)
- LibreOffice (Qt を活用)
- LadyBird (Qt を使用して UI を構築した新しいブラウザの開発)
(もしあなたのプロジェクトを紹介し忘れていたら、pedro.bessa@qt.ioまでご連絡ください)
FOSDEM での講演
こちらは私たちのトークのハイライトのいくつかです:「テック史の女性たちはどこへ行ったのか?2.0」このセッションでは、Laura Durieux が以前の「コンピュータサイエンスにおける女性」についての話をさらに発展させ、テクノロジーの歴史における女性たちを紹介しました。ARM アーキテクチャの共同設計者である Sophie Wilson や、ワールドワイドウェブの基礎となるスパニングツリー プロトコルを発明し、その詩も書いた Radia Perlman など、魅力的な人物が紹介されました。
「LLVMにおけるプロファイル誘導型最適化(PGO):アドプターから見た現在の課題」
Alexander Zaitsev は、C++ プロジェクトで PGO を使用する際の一般的な障害について、ドキュメント不足、誤った情報や不適切なアドバイス、ビルドツールのサポート不足、再現性の問題などを議論しました。また、実際のアプリケーションで PGO を使用するデモンストレーションを示す「 Awesome PGO」プロジェクトも紹介されました。
SBOM devroom
日曜日のトラックの一つにSoftware Bill of Materials(SBOM)に関するセッションがあり、Qt がこの分野で最近行っている取り組みに関連するいくつかのトークがありました。興味深い発見としては、SBOM の作成と管理を支援する SCANOSS プロジェクトや、バイナリスキャンと脆弱性検出および管理を支援する OSV-Scalibrプロジェクトが紹介されました。Chris Swan氏 の「C アプリケーション用の SBOM 作成の苦労」では、Yocto や Zephyr がそのツールでビルドされたプロジェクトのために SBOM を生成する進展を見せていることや、主要な Linux ディストリビューションが SBOM を提供し始めていることなど、希望の兆しが語られました。また、さらなる情報を提供するブログ記事も紹介されました。
Containers devroom
土曜日に、Philip Laine がコンテナ画像を効率的に配布し、コンテナレジストリのボトルネックを避けるための興味深いプロジェクトを発表しました。このプロジェクトは、コンテナのダウンロード者が同時にアップロード者として機能するピアツーピアネットワークを使用しています。
テストと継続的デリバリー devroom
Daniel Hiller による発表では、AI を活用して不安定なテストを改善する CANNIER が紹介されました。このプレゼンテーションでは、テストの再実行にかかる時間を最小限に抑えることを目的とした CANNIER アプローチが紹介されました。
Ladybird ライトニングトーク
新しいブラウザ「Ladybird」をご存知ですか? このブラウザは、UI に Qt を使用しています。
そのライトニングトークでさらに詳しく紹介されました。
Qt Project のブースでの交流
多くのディスカッションは、「あ、Qt!以前、...のプロジェクトで Qt を使いました」という言葉から始まりました。Qt はほとんどの来場者にとって馴染み深いプロジェクトでしたが、まったく新しい方々にも出会いました。その中には「Qt って何ですか?」と直接質問してくる方もいました。その場合、私たちは素早く野外で見られる Qt インターフェースの例を挙げて、話を始めました。また、Qt アカデミーを紹介し、学習のスタート方法を教えることに力を入れました。その結果、週末の間に Qt アカデミーの新規ユーザーが約600人増加しました。
開発者向けのイベントではありましたが、プロジェクトマネージャーや、家族の誰かが参加したために同行している方々、マーケティング担当者、さらには大学で何が行われているのか興味を持った一般の方々など、さまざまな職業の方々が訪れました。
来場者には「どんなプロジェクトで Qt を使っているか?」と尋ねると、いくつか印象的な回答がありました。その中には、Qt で牛を搾乳する、Qt で食べ物の注文を処理する、そして Qt で速度取締りのレーダーを欺くといったものがありました。
心理学的 Qt 社会実験
このタイトルに驚いていますか? 心配しないでください!ブースでの交流を促進するアイデアについて議論していたときのことです(結局、私たちは多くの他のブースと競っていました!)。そこで、来場者の関心を引くためにユニークな方法を採用することに決めました。
私たちは三つのキャンディーボウルを用意し、それぞれに「C++」、「Python」、「Rust」とラベルを付けました。来場者がそれらを見たとき、自分の好きなプログラミング言語に対応するボウルからキャンディーを取ることで、自分の立場を示したいという気持ちが働くため、非常に良い会話のきっかけとなりました。初日の結果は一目瞭然でした。Python のボウルはすぐに空になり、C++ と Rust のボウルは引き分けの状況でした。
いくつかのコメントで「X 言語はどうですか?」という声もあったため、次の日にさらに選択肢を増やすことにしました。
二日目には、選択肢を少し広げ、「Python、C++、Other (教えてください!)」というラベルを追加しました。これがさらに効果的で、以下のようなディスカッションに発展することができました:
- なぜ X 言語が他の言語より優れているのか
- もし X 言語が Qt をサポートしたら、どれほど素晴らしいだろうか
- なぜ X 言語が特定の業界にとって最適な選択肢なのか
これによって、さまざまな言語に対する関心や、Qt と他の言語との関係に関する意見を深く聞くことができました。
私たちは、言及された他の言語についてすべてメモを取っていました(ペンと紙で!)。しかし、ブースに訪れた多くの人々のため、いくつかのデータを見落としてしまったことを確信しています。それでも、最終的に得られた結果は以下の通りでした:
C++ と Python に次いで、私たちのトップ言語は以下の通りでした:
- Rust: 18票
- Go: 11票
- C と JavaScript: それぞれ 9票
2日間で合計 4.5 キロのキャンディーが投票に使用されました。
この結果に驚きましたか?
FOSDEM:完璧なオフライン・コミュニティ管理プラットフォーム
「ついに来たんですね!」と、ブースに近づいてくる多くの人々が声を大きくして言ってくれました。まるで中学校の時の親友に偶然会ったような、嬉しそうな表情で。
Qt の 30周年と重なったこのイベントは、Qt プロジェクトの代表として FOSDEM に初めて公式に出展する機会でした。私たちにとって、この機会は Qt がどれほど多くの人々にとって重要で愛されているフレームワーク、学びや GUI プロジェクト作成に欠かせない素晴らしいツールであるかを目の当たりにするものとなりました。
FOSDEM にブースを出展することで、直接私たちにアクセスして交流することが容易になり、多くの人々が自分の Qt のストーリーを共有してくれました。大学で使ったり、個人のプロジェクトに使ったり、あるいは仕事で Qt の導入を上司に勧めようとしている人もいました。私たちの出展は、オープンソースのエコシステムに対して、私たちが協力を歓迎しているというサインを送ることにもなり、それがきっかけでブースに訪れて話しかけてくれる方々もいらっしゃいました。
ユーザーの体験を直接聞くことは、Qt がコミュニティにとっていかに重要であるかを理解する貴重な機会です。多くの人々がブースを離れるときに、良い会話をした後の笑顔を見せてくれました。おそらく、Qt のブースの思い出は、FOSDEM の中でも特に印象的な出来事の一つとして心に残ったことでしょう。
ブースに訪れてくれた皆さん、私たちのコミュニティの一員として支えてくれた皆さん、そしてこの長いブログ記事を読んでくれた皆さん、本当にありがとうございました!
そして、FOSDEM を運営しているボランティアチームの皆さんにも特別な感謝を。これは本当に素晴らしいイベントで、関わったすべての方々にお祝い申し上げます!
関連リンク:
Blog Topics:
Comments
Subscribe to our newsletter
Subscribe Newsletter
Try Qt 6.8 Now!
Download the latest release here: www.qt.io/download.
Qt 6.8 release focuses on technology trends like spatial computing & XR, complex data visualization in 2D & 3D, and ARM-based development for desktop.
We're Hiring
Check out all our open positions here and follow us on Instagram to see what it's like to be #QtPeople.
Cool, would be nice to see someone make it works with cmake :) (not me, I am infinitely too lazy)
How hard would it be to make this same program work with any set of unit tests? Say I want to use the same pretty interface for the unit tests on my own OSS project. Can I cherry-pick this program and fill it in with my list of auto-tests, or is it not ready for that yet?
I'm as curious as Nathan: can this be used for generic autotests?
@Nathan, @razvanpetru
Yes I thought about that, and it would not require a lot of modifications. It currently parses the auto-tests project file (auto.pro in tests/auto), so it could just take any .pro file as input instead. I will definitely look into that.
I wonder, how does this handle the GUI unit tests? Some months ago, I started work on my own test running tool (http://gitorious.org/qt-com...) as part of the community integration project I was working on at the time (http://blog.rburchell.com/2...), but one of the stumbling blocks I got stuck on at the time was that reliably creating and tearing down a test instance (dbus, GUI with no WM/styles, etc) was a lot of work.
I guess I'm going to have to look into this again sometime soon as I want to start revisiting the community integration stuff.
I'd also just like to add: great news! This is exactly the sort of thing I hope to see a lot more of after writing about the frustrations that many are feeling with trying to contribute to Qt (see http://blog.rburchell.com/2...).
@Robin
It is a bit problematic for GUI tests indeed... For now you can't do anything at the same time for these tests. I'm not sure what to do about that...
@Siddharth
Thank Shane and Liang for that :)
@Rohan
Like Bjørn Erik said, the idea is just to have some helper tool to automate and speed up things so I don't think your first point is relevant.
For your second point you are right, ideally the tool should query the list of tests from some server, but then it closes the door to running external auto-tests. Or then we need a different mode for Qt auto-tests and external auto-tests...
Is this blog entry linked from our contribution model help pages? :)
+2 kudo points for making it work on Symbian. Thank you.
I have a couple of suggestions:
First, the test running logic shouldn't be implemented in this tool, because then it can't be reused in automated systems. e.g. this tool probably runs the tests in a slightly different way than the Qt Continuous Integration system itself does - especially for the more complex things such as running of autotests on symbian devices.
Second, the parsing of test definitions from the .pro files probably shouldn't be done here, because it's more error prone than proper build system integration - this tool might have a different idea about what is/isn't a testcase than other systems which are trying to run the tests. The build system knows `make check' and ideally that's the one canonical way to determine what is and isn't a testcase.
@ Rohan
I believe Yoann wrote this nifty tool to make it easier to run Qt auto tests (tests/auto/*). His goal was clearly not to make a swiss army auto tester tool supporting every single use case without being good at anything. To put it simple; it is a replacement for the following workflow:
cd $class ./tst_$class cd .. cd $anotherClass ./tst_$anotherClass cd ..
... it even supports running tests in parallel :-)
@Yoann Lopes
A cross platform solution is... yeah, going to be difficult, if possible at all. The solution I settled on (as I only run Linux) at the time, was to run an Xvfb instance via QProcess. I'm happy to help contribute to make that happen if it's something you'd like to see.
However...
I noticed that some tests don't seem to like Xvfb (unreliable failures), using Xephyr instead made tests pass, but meant that I had to have an annoying window hovering around. Never figured out why. :)
That's a really nice (and fancy looking) tool. Having a test suite for making sure that nothing is broken by your own changes is a must.
What I'd like to see is something like this tool integrated into QtCreator so that real TDD is possible. If you have tried it you will not write code without tests anymore. So no only generating a new class via the QtCreator templates but also a corresponding UnitTest and running it automatically after compile would be a dream.
This a more general question: how can QGraphicsSceneEvents be simulated in unit testing? QTest has support for QWidget events (like QTest::keyEvent) but not for QGraphicsWidgets.
@Alex
Just create the event and send it to the scene with QApplication::sendEvent().
@Yoann
Since events like QGraphicsSceneMouseEvent have no public constructor or property set methods I thought there might be established way to create and send them.
I agree 100% with Jens Stockhausen. TDD helpers in QtCreator are a must.
Yes, TDD in QtCreator would be really nice. Perhaps, the Test tool could be part of the qmake project file and be run automatically after building? so it would not opnly be integrated in QtCreator, but in all qmake build process...
Second the integration of some test-driven development features into QtCreator. If you compare use of QTestLib with QtCreator to, e.g., the JUnit tools available in Eclipse...
I would really like to see something comparable in QtCreator :-).