Yet another creative developer from Pardus, Renan Çakırerk has created Quickformat. And I wanted to let you know !

It is also integrated to Dolphin !

You can find a lot of information about Quickformat from Renan’s Blog. Have fun !

Users wanted to see service descriptions in service-manager and I tried to find a proper solution, here is the result;

Service Manager meets PDS from Gökmen Göksel on Vimeo.

In Package Manager, when user clicked on a package -to get its details-, details comes with sliding-down animation. And then if user clicks the same package, details goes away with sliding up animation.

But, when user clicks a different package while one of them opened before, it closes the first one directly (no animation) and then shows the new one with a sliding down animation. A small touch;

--- trunk/kde/package-manager/manager/src/rowanimator.py	2010/10/20 13:51:19	32615
+++ trunk/kde/package-manager/manager/src/rowanimator.py	2010/11/07 20:29:59	32912
@@ -45,16 +45,27 @@
         self.direction = DOWN
         self.row = None
         self.lastrow = None
-        self.timeLine = QTimeLine(300)
         self.t_view = updater
+        self.initTimeLine()
+        self.hoverLinkFilter = HoverLinkFilter(self)
+        self.t_view.installEventFilter(self.hoverLinkFilter)

+    def initTimeLine(self):
+        self.timeLine = QTimeLine(300)
         QObject.connect(self.timeLine, SIGNAL("frameChanged(int)"), self.updateSize)
         QObject.connect(self.timeLine, SIGNAL("finished()"), self.finished)
+        self.timeLine.setDirection(QTimeLine.Backward)

-        self.hoverLinkFilter = HoverLinkFilter(self)
-        self.t_view.installEventFilter(self.hoverLinkFilter)
+    def animate(self, row, reverseOld = False):
+        if self.row >= 0:
+            if not self.row == row:
+                self.timeLine.setFrameRange(DEFAULT_HEIGHT, self.max_height)
+                self.timeLine.start()
+                QObject.connect(self.timeLine, SIGNAL("finished()"), lambda: self.animate(row, True))
+                if not reverseOld:
+                    return

-    def animate(self, row):
+        self.initTimeLine()
         self.setRow(row)
         self.timeLine.setFrameRange(DEFAULT_HEIGHT, self.max_height)
         self.timeLine.start()

Fixed it :) Here are the results;

The old one;

Old Package List Animation from Gökmen Göksel on Vimeo.

The new one;

New Package List Animation from Gökmen Göksel on Vimeo.

Linux Journal just announced the 2010 Linux Journal Readers’ Choice Awards, and good news Pardus is in top five this year !

In three important categories, Pardus catches the top five;

- Best Linux Distribution; 1st Ubuntu and 5th is Pardus

- Best Package Management Application; 1st Apt and 5th is Pisi

- Product of the Year; 1st Android, 2nd KDE lol and 5th is Pardus

The other good news is our best friend Python selected 1st in both Best Programming and Best Scripting Languages categories.

Have a nice Sunday !

Pardus have its own package management system: PiSi (For more information about pisi you can checkout development page). Package-manager uses its backend. As you may remember from my previous posts, we are using an infrastructrure for managing operations called Çomar. Package-manager calls Çomar where it can check that if the user have necessary priveleges to use PiSi by using PolicyKit (which calls PolicyKitKde on KDE). You may see that this operation resembles KAuth. One can ask why we are using this method, instead of KAuth. Well, the simple answer is that this infrastructure is nearly 4 years old. :-)

Let’s look at the new features of package-manager…

The most significant change is the new interface where you may see that there are tabs similar to rekonq and chromium. Package-manager doesn’t have anything to offer in file menu but settings, so this menuless aspect works better for our needs and it saves a one line space, which is getting more and more important for netbooks and other small screen devices.

Another great improvement you may catch from the first screenshot is rating stars for packages. The rating option was a feature requested by our users for a long time. Since we kept them waiting so long, we thought that the solution should worth. We put out a new project called AppInfo which can work with any package management system. At the moment, only PiSi backend is completed but anyone can write a new backend for rpm, deb or any other package-manager of choice. AppInfo provides a rating for each package from its main database. Clients uses AppInfo API to check out the rating database from a predefined AppInfo server which provides screenshots and rating info for the requested package. Below you can see the information of package-manager in use.

In the last screenshot you may be interested in the overlayed widget. The trick is the PDS.Gui class. I’ve written about Pardus Desktop Services before. This Gui class is a new add-on for PDS aiming to improve usability. It also supports animated transitions which based on QTimeLine and to achieve an animation infrastructure similar to QPropertyAnimation. Using QPropertyAnimation was an option for sure, however I wanted to experience to create a basic animation framework with power of Qt. So this choice was totally personal… :-)

Package Manager in Action

While integrating the new search mechanism to achieve an auto completion for packages, I used PDS.Gui as well.

I embedded the basket window and the progress dialog into the main window with PDS.Gui as well.

You may download Pardus 2011 Beta and check the new features.

Thanks for the fish…

Birçok konuda bu tip tartışmalar yaşanır, bazen sadece fanatiklik bile bir tarafın seçilmesinde etken olabilir (doğru olmayabilir ama olur). Ben bunun dışında biraz gerçeklerden bahsetmek istiyorum:

• Özellik Kümesi
  • Qt sağladıkları ile birlikte tam bir geliştirme kütüphanesi, sadece grafik arabirim için değil en alt seviyede ihtiyaçlar için bile bir destek sunuyor. Veritabanı, Ağ, Web, XML … uzayıp giden kocaman bir özellik kümesini sunuyor. Öyle ki sadece Qt kullanarak koskoca bir masaüstü ortamı yazmak mümkün. Tam olarak neler içerdiğine [1] adresinden bakılabilir.
  • GTK+ ise Qt’ye göre çok daha az sayılabilecek bir özellik listesine sahip, fakat bu noktada GTK+’ın geliştirilmesindeki asıl sebebin arabirimler olduğu unutulmamalı. Arabirim dışında kalan işler için gerekli özellikler GLib altında geliştiriliyor (GTK+, Glib üzerinde), Qt’nin sunduğu kadar geniş bir yelpazeye sahip olmasa da yeterince uzun bir özellik kümesi var. Daha detaylı bir liste API dokümanlarından [2] incelenebilir.
  • Qt C++ ‘a ek olarak kolayca anlaşılabilecek sinyal slot mekanizmasını beraberinde getiriyor, GTK+ ise C üzerinde nesneye dayalı bir yaklaşım sergilemeye çalışırken anlaşılması zor bir hale geliyor.
• Görünüm
  • Qt Native QT uygulamaları, QGtkStyle[3] ile birlikte GTK+ temalarını (simge temaları dahil) kullanabilir hale geliyor, bunun dışında Qt Windows ve Mac Os X üzerinde de doğal görünüm sağlayabilen ortak tek kütüphane. QGtkStyle Qt tarafından sağlanıyor.
  • GTK+ Sadece kendi tema stillerini destekliyor, GTK-Qt-Engine [4] ile (GTK dışında geliştirilen gönüllü bir çalışma) bütün Qt temalarının desteklenmesi söz konusu olamıyor. Windows ve Mac Os X için herhangi bir desteği yok, kendi temaları ile çalışmaya devam ediyor. Ayrıca tema noktasında iş sadece görsellik ile bitmiyor, butonların sıralaması, layout düzeni gibi işler de temaya bağımlı olarak değişebiliyor (Qt’de İptal en sağ altta, GTK+’da Tamam en sağ altta gibi) QGtkStyle bu farklılıkları gözetebiliyor, GTK-Qt-Engine’in böyle bir yeteneği yok.
  • Ayrıca tema noktasında iş sadece görsellik ile bitmiyor, butonların sıralaması, layout düzeni gibi işler de temaya bağımlı olarak değişebiliyor (Qt’de İptal en sağ altta, GTK+’da Tamam en sağ altta gibi) QGtkStyle bu farklılıkları gözetebiliyor, GTK-Qt-Engine’in böyle bir yeteneği yok.
• Altyapı
  • Qt C++ ile geliştirilmiş ve C++ ile tam uyumlu bir API sunuyor. Nesneye Dayalı bir dilin bütün nimetlerinden faydalanıyorlar (bütün objeler QObject nesnesinden, bütün grafik arabirim nesneleri QObject nesnesinden türemiş QWidget nesnesinden türüyor, …)
  • GTK+ Qt’nin aksine C ile yazılmış ve kendine has bir API yapısına sahip. Fakat C++ için yazılmış bir wrapper ile (GTKmm) Qt’nin sahip olduğuna benzer bir hiyerarşi düzenine sahip. GTK+ nesneye dayalı bir yapı için, GObject nesnesinden miras alarak türüyor.
• Belgelendirme
  • Qt eksiksiz bir API belgesi ve bunu yanında süreçleri profesyonelce yazılmış bir bilişim kitabı tadında anlatan nasıl yapılır belgelerine sahip. Bu belgeler Qt tarafından sağlanıyor ve Qt paketleri ile birlikte erişilebilen Asisstant adlı uygulama ile ya da web üzerinden sunuluyor. Aynı zamanda Qt uygulamaları için doxygen formatında yazılmış açıklama metinlerinen QHelpEngine ile yardım belgesi üretmek mümkün hale geliyor.
  • GTK+ ‘da Qt’de olduğu gibi detaylı bir belgelendirme arşivine sahip değil, API belgeleri GTK tarafından çevrim içi sunuluyor olsa da, çevrim dışı belgelere 3.parti yazılımlar ile erişebiliyorsunuz.
• Tasarım Araçları
  • Qt Designer adından bir arabirim tasarımcısı ile birlikte geliyor, bu tasarımcı aynı zamanda Qt Creator uygulaması içine gömülü bir şekilde çalışarak tam bir geliştirme ortamı sunuyor. Designer XML tabanlı bir tasarım dosyası üretiyor ve bu dosya hazır araçlar sayesinde desteklenen diller için hazırlanmış kodlar haline getiriliyor. Ayrıca designer mevcut Qt nesneleri dışında dışarıdan geliştirmiş olduğunuz nesnelerin de arabirimi üzerinden kullanılmasına olanak sağlıyor.
  • GTK+ Glade ile birlikte arabirim tasarımı işini hallediyor, Glade GtkBuilder formatında Qt’dekine benzer bir şekilde desteklenen dillere çevirilebilecek bir tasarım dosyası üretiyor, bu dosyalar yine benzer araçlar ile desteklenen diller için üretiliyor.
• Performans
  • Bu konuda net bir sonuç ortaya koymak pek mümkün olmuyor, bu süreci alt kümelerine; çizim, bellek yönetimi, yüklenme süresi, çözülme süresi vs. şeklinde bölerek değerlendirmek gerek. Zira Qt yapılan iş ile ilgili bir çok bileşeni kendi sağlıyor olsa da GTK+ ile dışarıdan bir çok bileşeni kullanmak gerekiyor. Bu noktada performans değerlendirmesini net bir biçimde yapmak çok zor bir hale geliyor.
  • Genel kanı GTK+’ın Qt’ye göre daha hafif olduğu olsa da Qt’nin özellikle 4.4 sürümünden sonra bellek yönetimi ile ilgili yapmış olduğu yenilikler ile bu durumun geçerliliğini yitirdiği gözleniyor.
  • Daha önce yapılmış polygon çizimleri ile ilgili bir performans testini [5] adresinde bulabilirsiniz.
• Çeviriler
  • Qt kendi çeviri yönetim sistemine sahip fakat Gettext kütüphaneleri ile birlikte de kullanılabiliyor. Bütün Qt nesneleri Unicode destekliyor ve soldan-sağa <> sağdan-sola diller arası geçiş için bütün arabirim otomatik olarak yön değiştirebiliyor.
  • GTK+ herhangi bir çeviri yönetim sistemine sahip değil fakat Gettext kullanılarak çevirilebilir arabirimler tasarlamak mümkün.
• Test
  • Qt Arabirim ya da arabirimden bağımsız süreçlerin birim testlerini yapabilmek için bir test kütüphanesi sunuyor (QTestLib)
  • GTK+ için böyle bir özellik mevcut değil
• Programlama Dilleri
  • Qt C++ ile geliştiriliyor ve doğal hali ile C++ destekliyor. Bunun yanı sıra Qt için hemen hemen bütün dillerde kullanılmak üzere bağlayıcılar (binding) geliştirilmiş. Ayrıca Qt ECMA script (JavaScript) destekliyor. Ayrıca kendine has QML adında hızlıca uygulama geliştirebileceğiniz bir platform daha sunuyor.
  • GTK+ C desteği ile geliyor fakat Qt’de olduğu birçok bağlayıcı GTK+ için de mevcut. Bağlayıcılar konusunda Qt’den hemen hemen bir eksiği olmamasına rağmen, GTK+ ile JavaScript şimdilerde mümkün gözükmüyor.
• Çokluortam
  • Qt çokluortam işlerini Phonon ile hallediyor (Qt’nin içerisinden geliyor) birçok arkaucu (backend) destekliyor; mplayer, vlc, gstreamer, xine. Phonon arka uçlar için ortak kulanılacak bir katman, arka uçlar sisteme göre değişiyor ve bu arka uçlar Qt tarafından değil, çalıştığı sistem tarafından sağlanıyor. Ayrıca çokluortam dosyaları üzerinde (efekt ekleme gibi) işlem yapmaya da olanak sağlıyor.
  • GTK+ Gstreamer kullanıyor ve arka uç olarak sadece Gstreamer’ı destekliyor. Arka uç Gstreamer’ın kendisi GTK+ tarafından sağlanıyor.
• İletişim Desteği
  • Qt Dbus ve IPC destekliyor
  • GTK+ sadece Dbus destekliyor
• Lisans
  • Belki de bu tartışmanın eskiden kullanılan en önemli vurgusu Qt’nin lisans durumydu, fakat Nokia satın aldıktan sonra Qt’nin lisansını LGPL olarak değiştirdi, bu noktada GTK+ ile Qt arasında özgürlük açısından herhangi bir fark bulunmuyor fakat Qt için ücreti karşılığında profesyonel destek alabiliyorken GTK+ için hala böyle bir destek alamıyorsunuz.
  • Ayrıca işin Python tarafında Qt’nin LGPL olmasının ardından pyGtk düşüşe geçmiş.

Sonuç

Açıkçası bu listeyi çok daha fazla uzatmak mümkün. Bir yerde durmak gerekiyordu :).

Benim kişisel görüşüm Qt’den yana; size tam bir çözüm sunuyor ve bu tam çözümü sunarken her süreç birbirine benzer işliyor, Qt içeren bir C++ kodunu çok hızlı bir şekilde Qt içeren bir Python kodu haline getirebiliyorsunuz. Nesneye dayalı geliştirilmiş olmasının verdiği esneklik ve uyum, üstüne bir de çok detaylı belgelendirme, rahat okunabilir kodlar eklenince Qt açık ara lider benim için fakat ikisi ile de mükemmel uygulamalar geliştirmek mümkün.

Bu konu ile ilgili yaptığım araştırma sırasında karşılaştığım/kaynak aldığım bazı yazılara [6] [7] [8] [9] adreslerinden ulaşılabilir.

Not: GTK+ ile ilgili yazdıklarımda eksiklerim/yanlışlarım olabilir, kesinlikle bu konuda yorum bırakmaktan çekinmeyin.

[1] http://doc.qt.nokia.com/4.7/classes.html
[2] http://library.gnome.org/devel/references#api-platform
[3] http://labs.qt.nokia.com/2008/05/13/introducing-qgtkstyle/
[4] http://kde-look.org/content/show.php?content=9714
[5] http://zrusin.blogspot.com/2006/10/benchmarks.html
[6] http://techfreaks4u.com/blog/?p=953
[7] http://ldn.linuxfoundation.org/article/application-development-framework-choices-gtk-vs-qt
[8] http://www.jbkempf.com/blog/post/2007/02/10/Qt4-Interface
[9] http://www.caddd.org/2010/03/qt-vs-gtk.html

Bir çok sunumda da savunduğumuz bir argüman var; PiSi sadece paket yönetiminde değil, paketleri geliştirmek için sunduğu kolay kullanım ile de diğer paket yönetim sistemlerinden sıyrılıyor.

Paketlerin sisteme kurulması, güncellenmesi, kaldırılması ya da daha derinlerde bağımlılıklarının çözülmesi, paketlerin sıkıştırılması gibi işleri yaparken ne kadar hızlı ve verimli olduğu şüphe götürmez bir gerçek. Paket geliştiricileri için ise Python ve XML sayesinde paket geliştirme sürecinde diğer paket yönetim sistemlerine göre büyük avantajlara sahip.

Python’un tartışılacak pek bir yanı yok, hali hazırda kendisine rakip olabilecek pek bir ürün de yok zaten (ruby’nin vs. nin başımızın üstünde yeri var ama Python daha bi can yani :)) Fakat paketlerin önemli bilgilerini içeren dosyaların hepsi XML formatında. Bu dosyaların XML olmasının birçok avantajı var; herhangi başka bir formata dönüştürmek, hali hazırda bir çok kütüphane kullanarak bu dosyaları işlemek, dosyanın denetimlerini gerçekleştirebilmek ya da dosyanın tasarımında bir değişiklik yapmak oldukça basit. Gelgelelim XML’in çok önemli bir dezavantajı var; insanlar için yazması ve okuması zor bir format XML. Günümüzde henüz paketleri geliştiren mükemmel makinelerimiz olmadığına göre, insanlar önem sıralamasında en üstte :)

Bu problemi çözmek için XML düzenleyecek araçlar yazmak üzere tarihi birçok projemiz mevcut. Fakat ne bu projeler bir türlü mutlu bir sona ulaşabildiler, ne de çoğu “geek” dediğimiz sınıfa giren paketçilerimiz bu araçları kullanmaya sıcak bakmadı. Paket bakıcılığı ile pek uğraşmıyor olsam da bende bu araçlar yerine Vim kullanmayı tercih ediyorum. Bu kadar paket varken ve PiSi ile paket geliştiren bir çok paketçi varken, bu konuda bir değişiklik yapmakta pek kolay değil. Ayrıca değiştirmeye karar verdiğinizde XML’in sağladıklarını sağlayacak birşey bulmak ve PiSi’nin bu formattan anlayacak hale gelmesini sağlamak (PiSi ile birlikte buildfarm ve arkadaşları gibi büyük bir topluluk da bu değişimden nasibini almalı) pek kolay bir iş değil.

Konuyu bir-iki haftadır birazda geyik unsuru olarak aramızda konuşurken (daha sonra geliştirici listesinde de konuşuldu bir kuple), kullanabileceğimiz alternatif veri taşıyıcı formatları araştırdık; JSON, YAML ve hatta şahsen ben kendim Google’ın kendi işlerinde kullanmak üzere tasarladığı protobuf projesini dahi inceledim. Fakat aralarında en mantıklısı ve XML’e en yakın özellikleri sağladığı gibi asıl problemimize (kolay okunan ve yazılan bir format istiyoruz !) de tam çözüm olacak tek alternatif YAML gibi gözüküyor (evrenin herhangi bir yerinde daha iyisi varsa yorum olarak ekleyin). PiSi’nin proje lideri Fatih ve Pardus 2009 Sürüm Yöneticisi Onur ile birlikte konuyu konuşurken çok daha eğlenceli dosya formatları geliştirdik lâkin Dünya henüz buna hazır değil :)

Mevcut bir pspec.xml ile yeni ortaya çıkan pspec.yaml arasındaki okunulabilirlik ve yazılabilirlik ise sanırım gayet net;

YAML gibi bir formatı seçmekle iş bitmiyor ne yazık ki; PiSi’nin YAML anlayacak hale getirilmesi, bu işin (deyim yerindeyse) en “pis” yeri. Bu işi şu anki iş yükümüzle ve düşündüğümüz şekli ile (PiSi’nin XML ile ilgili kısımlarını tamamen YAML’a geçirmek) yapmak neredeyse imkansız olduğu için bu konu geyik olarak kapandı diye düşünüyordum ki; bir bardak mojito imdadıma yetişti;

XML’in avantajı kolay olarak başka formatlara çevirilebilmesi ve XML için kullanılabilecek en hızlı Python kütüphanelerinden Piksemel ve YAML için gerekli PyYaml kullanarak, pspec.yaml gibi bir dosyayı PiSi’ye işlemesi için vermeden önce PiSi’nin anlayabileceği XML formatına çevirmek gayet kolay olacaktı oysa ki :)

pisi-yaml‘ın kendisi burada, denemek için örnek bir paket ise burada mevcut. Tabi bunlardan önce PyYaml paketini kurmanız gerek. Gerekli dosyaları çektikten sonra kde-odf-thumbnailer paketini pspec.yaml‘dan derletmek için kde-odf-thumbnailer dizininde;

# ./pisi-yaml.py build pspec.yaml

Derleme bittikten sonra pspec.yaml dosyasının XML’e çevirilmiş haline .pspec.xml dosyasından göz atabilirsiniz.

Pardus 2011′de YAML ile yazılmış paketlerimiz olur belki kim bilir ?

Bu yıl KDE ve Gnome vakfının birçok sponsorun da desteği ile birlikte düzenlediği Desktop Summit ’09 için biraz önce Kanarya Adaları‘na geldik Gökçen ile birlikte. 03-11 Temmuz arasında olacak, Akademy ve GUADEC katılımcılarının bir arada yer alacağı etkinliğin son günleri ise İspanyolca sunumlar ile öncelikli Kanarya Adaları sakinleri ve İspanyol ziyaretçilere adanmış olacak.

KDE 4 ile bu seviyede bütünleşmiş başka bir Linux dağıtımının olmadığını düşünürsek, Pardus’un bu etkinliğe katılıyor olması gayet heyecan verici ;)

If you remember from my blog entry about Network Manager Plasmoid, Pardus uses Comar layer for all stuff that needs by a desktop user; networking, user operations, service operations, display management, disk management etc. It also integrated with PolicyKit; so you can define atomic privileges per user. Comar also provides great API that helps Qt’s “Code less, Create more.” thought ;)

For example, to connect a profile that you have in your wireless profile list:

>> import comar
>> link = comar.Link()
>> link.Net.Link['wireless_tools'].setState('Monaco','up')

That’s all ! And if you need a privilege for this operation Comar will call PolicyKit-Kde4 for asking you a password ;) Comar uses D-Bus for communication and it is possible to make aysnc calls just by using async key and proper function to notify by current operation.

And this is the New Network Manager of Pardus !

Don’t forget to watch the screencast in here !

If everything goes ok I will be at Akademy Gran Canaria and I hope we will show you a lot of impressive tools that we made ;)