gökmen göksel

October 28, 2010 18

Pardus 2011 Beta with new Package Manager

I was busy with Pardus 2011 for a while (we released Pardus 2011 Beta last week), where I couldn’t find a chance to write about development process. You will see great improvements in the upcoming release; Pardus 2011 will be shipped with KDE 4.5.2 and a whole bunch of our management tools which are written with Python, PyQt and PyKDE. I guess the package-manager will be the most noteworthy one in all.

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…

Tags: ,

October 19, 2010 13

Qt ya da GTK+, ne dersin ?

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

Tags: ,

July 30, 2010 1

Tony

Tony, bizim ikinci köpeğimiz idi..  15 yıldır bizimle birlikteydi ve maalesef bu yılın başında aramızdan ayrıldı, giderken tam 15 yaşındaydı.. Annesi bir fino, babası çoban köpeği; çarpık bir ilişkinin meyvesiydi.. 15 yaşında olmasına rağmen boy olarak bir süs köpeğini tip olarak ise tamamen bir çoban köpeğini andırıyordu kendisi.. Çok süper düper bir canlıydı.. Yemeğini kuşlarla paylaşırdı;

Kuşlar rahat rahat yiyebilsin diye onlardan uzakta dururdu.. Özledim işte bi yazim dedim.. Tony’nin diğer cici fotoğrafları.. Şimdi Tony’nin kulübesinde Lucky yaşıyor, safkan bir Alman Kurdu.. Onu da çok seviyoruz..

July 10, 2010 Off

Özgürlük.

TDK diyor ki;

Herhangi bir kısıtlamaya, zorlamaya bağlı olmaksızın düşünme veya davranma, herhangi bir şarta bağlı olmama durumu.

Çok sevdiğim ama verdikleri tepkilere anlam veremediğim, söylediklerini ve ima ettiklerini bir türlü anlayamadığım birkaç Pardus Geliştiricisi, bundan böyle projenin içinde olmayacaklarını açıkladılar. Onların arkasından bir kaç kişi daha gitti. Bunun yanında birçok dostumda gidenlerin haklı olduğunu “onlar haklı” pankartları ile desteklediler.

Üzüldüm, hem de çok üzüldüm. İki gündür, bir türlü kendimi toparlayamadım. Yazılanlardan sonra, geliştiricilerin ayrılmasından çok yazılanlara üzüldüm.

UEKAE ‘de çalışan geliştiriciler ile dışarıdan gönüllü destek veren geliştiriciler arasında ortaya çıkan/çıkartılan bu durumun temelinde; -bana kalırsa- sürekli birlikte olan bir ekibin sahip olduğu yoğun iletişimin, sürekli ayrı olan bir ekiple birleştirilememesi yatıyor. Buna bir çözüm bulunabilir mi, bende bilmiyorum.

~ * ~

Yazdığımız bütün kodlar, paket bilgi dosyaları, betikler vb. her şey halka açık, yani biz Özgür Yazılım üretiyoruz. Hem de Türkiye’de hiçbir zaman olmadığı kadar. Ve bunu – emsalleri ile karşılaştırdığınızda – az sayıda insan gücü ile yapıyoruz.

Pardus’un bir Özgür Yazılım olmasının büyük artıları da var tabi;

Evet, Gönüllü çalışanlarımız var \\o/ Yukarıdaki grafikte 2006-2009 yılları arasında uludag deposuna yapılan gönderilerin oranları yer alıyor. Görüldüğü üzere üretilen Teknoloji’nin önemli bir kısmını UEKAE ‘de çalışan geliştiriciler üretiyor. Bu teknolojileri üretebilmek için gerekli paketlerin hazırlanmasında da %76′ya %24 gibi benzer bir oran, pardus deposunda bulunuyor. (Bunları biz daha çok çalışıyoruz demek için yazmadım, sadece durumu anlatabilmek için yazdım. Zira bizim daha çok çalışmamız tabi ki doğru olanı.)

~ * ~

Pardus 2008 ve sonrasında yapılacak işleri yazıp mevcut durumumuzu takip edelim diye ve daha “şeffaf” olabilelim diye, bir “Proje Yönetim” aracı arayışına girmiş idik. O dönemlerde yapılan tartışmalardan bir sonuç çıkmamıştı (ki gelistirici listesinde yapılan tartışmalardan bir sonuç çıkması “mucize“). Bizde yine o dönemlerde, tam olarak nerede gördüğümüzü hatırlayamadığım bir yerden esinlenerek, bir yapılacak işler dosyası hazırladık. Belirli bir düzene sahip bu dosya üzerine yapılacak işleri ve işin durumunu giriyorduk vs. Tabii ki 2011 sürecinde, artık bu ilkel yöntemin de işe yaramamaya başlaması ile birlikte, “Proje Yönetim” aracı arayışları yeniden alevlendi. Özgür yazılım projelerinin en büyük sorunu, herkesin her daim konuşması fakat iş bir proje için çalışmak olduğunda sessizce beklemesidir. Herkes konuşur ama bazıları çalışır. Ve biz o bazılarının yaptığı çalışmalara muhtacız. Yine bir çok insan konuştu, bazıları iş yaptı ve Jira adında bir yazılım kullanmaya karar verdik. Yaptığımız araştırmaların sonucunda, Özgür Yazılımlar için kullanılması ücretsiz fakat özgür olmayan bir lisansa sahip olan Jira ‘da karar kıldık. Bu listedeki diğer projeler gibi. (Aralarında Özgür Yazılımların da bulunduğu kabarık bir liste).

Bu kararı verirken bir yanlış yaptık; gönüllü geliştiricilerin de kullanacağı bir yazılım için kendi kendimize karar verdik. Kararı kendi kendimize vermiş olmamızın yanında, bir de Neden Özgür bir alternatifini seçmediğimiz için, geliştiricilerimiz haklı veya haksız olarak şikayetlerini dile getirdiler. Hatamızın farkına varıp bir çözüm üretebilmek adına, ısrarla savunulan, Özgür lisansa sahip Redmine ‘ın gereksinimlerimizi karşılayacak kıvama getirilebilmesi için bir ortam hazırlamaya ve elimizden geldiğince bu konuda destek olmaya, bu süreç işlerken de Jira ile devam etmeye karar verdik.

Bu kararımızı açıklayınca ardı arkası kesilmeyen, bazıları hakaret seviyesinde birçok ithamda bulunarak bazı geliştiricilerimiz projeyi bırakacaklarını açıkladılar.

~ * ~

Hala üzgünüm ve şaşkınlık içerisindeyim ve hala anlayamıyorum.

Özgür Yazılımın bir güzelliği de istediğiniz zaman bırakıp gidebilme özgürlüğü.

Keşke böyle olmasaydı ama herkesin yolu açık olsun..

Tags: ,

June 15, 2010 10

Pisi Yaml Desteği [Beta]

Pardus’u diğer dağıtımlardan farklı kılan en önemli özelliklerinden biri de PiSi , Pardus’un Paket Yönetim Sistemi.

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 vs. XML

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 :)

Biraz over-engineering gibi gözükse de uygulanabilecek en hızlı çözüm ve PiSi’nin sağladığı mevcut yapıdan tamamen izole olarak geliştirilebilir. yaml2xml dönüşümü için yazdığım kod pek baştan savma bir kod (hatta çok kötü bir kod bile diyebilirim). Fakat buradaki amacım kısa ve hızlı bir şekilde sonuca ulaşabilmek olduğundan, biraz da “deneysel” diyebileceğim pisi-yaml ortaya çıktı.

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 ?

İyi eğlenceler.

Tags: ,

April 20, 2010 6

Universal Apps

In Pardus Corporate we use KDE 3.5.10 and some of our new tools from Pardus 2009 which runs KDE 4.3.5 (for now). Tools in 2009 are designed to work with the current desktop environment which is KDE 4.3.5. So, we have a problem in Pardus Corporate side; we need kdelibs4 on KDE 3.5.10. It is possible to use kdelibs4 but in some ways it is not a great idea.

We think that we can create a solution for making universal apps which run on KDE 4.x with kdelibs4 and for others (kde3.5, xfce etc.) which use Qt libs.

Most of the code in our applications just depends on Qt 4.x, but some important parts for the desktop integration depends on KDE.

Basics of desktop integration

  1. Icons
  2. Colors
  3. Fonts
  4. Language Selection
  5. Translations
  6. Notifications
  7. …

I started with KIconLoader port for Qt, which I have found the C++ version on this blog entry and ported it to Python from scratch. For colors, fonts or language selection it is enough to read the user’s kdeglobals files. Notifications are handled by PyNotify on Qt-Only mode… When things started to grow up I decided to merge them under the name of Pardus Desktop Services (Pds).

Example Usage of Pds

>> import pds
>> desktop = pds.Pds()
>> desktop.session.Name
'kde'
>> desktop.session.Version
'4'
>> desktop.config_file
'/home/gokmen/.kde4/share/config/kdeglobals'
>> desktop.settings('Icons/Theme', 'default')
u'oxygen'

Other Classes

PDS also provides the following classes;

QIconLoader – for icon loading from current desktop settings (Kde 4, Kde 3.5, Xfce ..)

QUniqueApplication – for creating a unique application like KUniqueApplication. It also provides sending commands to running instances through QLocalServer.

I18n – Pds uses Gettext for translations and supports the kdelibs’ i18n-like parameters such as (%1, %2).

Notification – Uses PyNotify if it’s installed otherwise it uses QSystemTrayIcon balloon message.

worth a thousand words..

The following example shows two running Package-Manager instances; first one is running as a KUniqueApplication on Kde 4.4 provided by kdelibs4 and the second one is running as a QUniqueApplication which is provided by Pardus Desktop Services on Kde 3.5. Same application, same features, one code..

You can checkout source code of Pds from here and you may have a look at the package-manager fork for an example usage of Pds.

Tags: ,

March 22, 2010 3

Ne zaman geliştiriyoruz ?

Bildiğiniz gibi Pardus, Tübitak desteği ile hatta daha doğrusu Tübitak bünyesinde geliştirilen güzide bir proje. Aynı zamanda Pardus bir “Özgür Yazılım” projesi yani dışarıdan da destek alıyor. Bir çok güzide insan kendi gönüllerinden, kendi ellerinden gelen ne varsa yapmaya çalışıyor.

Peki Pardus geliştiricileri genelde ne zaman geliştiriyorlar Pardus’u ? Normal şartlar altında; yani Tübitak çalışanlarını işçi olarak ele alırsak ve bu iş için Tübitak tarafından ayrılan mesai zamanlarına bakarsak; Pazartesi-Cuma günleri arasında saat 08:00′dan 17:00′a kadar olan süre ortaya çıkıyor. Pardus sadece bu süre zarfında geliştiriliyor olsaydı şimdi nerede olurdu ?

Çok soru sordum açıkçası biraz da “bilimsel“* gerçeklere bakalım;

Yukarıdaki grafikte 2006-2009 yılları arasında uludag deposuna yapılmış tüm gönderilerin (commit) gün içerisinde gönderim sıklıkları ifade ediliyor. Grafiğe göre özellikle mesai saatlerinde gerçek bir yükseliş var fakat önemli nokta hemen hemen her günün her saatinde Pardus ofisinden birilerinin çalıştığını gösteriyor. Mesai saatleri ile diğer saatlerin oranına bakarsak;

Sanırım dediklerim daha iyi anlaşılıyor :) Aynı incelemeyi Pardus deposu için yaptığımızda olayın çok daha güzel bir yanı ortaya çıkıyor;

Evet, mevcut paketlerin çoğunu mesai saatleri dışında, yani çalışanların kendilerine ait olan saatlerde yapmışız. Çıkardığım grafiklerden daha bir çok ilginç sonuçta çıktı tabi;

  • Uludag ve Pardus deposuna en çok 2009 yılında gönderi yapmışız.
  • Katkıcı deposuna en çok gönderi ise 2007 yılında yapılmış.
  • 2006 ve 2007′de Pardus deposunu neredeyse sadece mesai saatleri dışında kullanmışız
  • Her yıl git gide mesai saatlerindeki çalışma performansımız gözle görülür bir şekilde artmış
  • Katkıcı deposu 2009 yılında diğer gün ve saatlerden çok farklı olarak en çok Çarşamba günleri saat 22 ‘de kullanılmış
  • Uludag deposuna yapılan gönderilerin %82.24′ünü Tübitak çalışanları, %17.76′sını gönüllü çalışanlar yapmış
  • Pardus deposuna yapılan gönderilerin %76.53′ünü Tübitak çalışanları, %23.47′sini gönüllü çalışanlar yapmış
  • Katkıcı deposuna yapılan gönderilerin %62.84′ünü gönüllü çalışanlar, %37.16′sını Tübitak çalışanları yapmış
  • Tüm depolarda ortak olarak en çok gönderiler 16 sularında mesai bitiminden hemen önce yapılmış
  • Tüm depolarda ortak olarak en az gönderi 6 ile 7 sularında yapılmış (doğal olarak)
  • Tübitak çalışanlarının en verimli olduğu saatler mesai içerisinde 14,15 ve 16 saatleri

Tüm bu veriler ile ilgili ayrıntılı grafikler [1] [2] [3] adreslerinde. Sayfalarda alttaki açılır kutulardan değişik depo/yıllara göre grafik ürettirebilirsiniz. (Kullandığım Svg çizim kütüphanesinde bazı problemler olabiliyor; sayfayı yenilemeniz yeterli)

* İşin bilimsel kısmı bu verilerin hepsini “svnlog” çıktısından aldım, kullanılabilecek hale getirmek için bir betik yazdım ve grafik kütüphanesinin anlayabileceği şekle çevirdim.

Tags: ,

February 15, 2010 5

Otomatik saatler

Siz hareket ettikçe sizin hareketinizden enerji alan ve yapıldığı teknolojiye bağlı olarak ya içerisindeki pili şarj eden ya da içindeki zemberek sayesinde mekanik olarak kurma işlemini gerçekleştirerek çalışmaya devam eden saatler. İngilizcesi “Automatic Watches” olunca Türkçesi biraz anlam karmaşasına yol açıyor olsa da başka mantıklı bir çeviri gelmedi aklıma..

Mekanik olanlar ortalama 1-2 gün boyunca durdukları yerde çalışmaya devam edebilirler. Pil şarj eden modeller ise genelde 1-2 gün sonrası uyku konumuna geçerek mekanik aksamı çalıştırmak yerine sadece saatin bilgisini dijital olarak tutarlar ve herhangi bir hareket ile şarj edilmelerini takiben mekanik aksamı gerçek zamana göre güncellerler.

Eski işlerimi toparlarken, okunmamış maillerimi okurken fark ettim ki Türkiye’deki otomatik özgür yazılım saatini harekete geçiren ve onu sürekli olarak şarj eden bir ekip ile çalışıyorum (Zorunlu hizmetin ardından bugün işte ilk günüm..) Sadece bu ofiste çalışan insanlardan bahsetmiyorum; hata giren, yorum yapan, saati çok hızlı şarj edeyim derken hızını alamayan ama her yönüyle bir şekilde bir sonraki adım için enerji üreten insanlardan bahsediyorum.

Özgürlükİçin‘in hazırladığı PodCast‘i dinledim biraz önce; resmen duygulandım yahu -arada Pardus Piyango talihlileri de açıklandı – :) Sonrasında Beyin‘de gezindim bir süre; gerçekten ele alınabilecek o kadar güzel yeni fikir var ki..

Sevgili Necdet Yücel‘e ve 64bit ekibindeki tüm arkadaşlara da 64bit Pardus sürümü için gösterdikleri müthiş çaba içinde ayrıca büyük bir teşekkür etmek istiyorum, zira özgür yazılımlarda yapılacak işler için konuşmak çok kolaydır fakat bir şeyler yapmak, işleri sonuca bağlamak her zaman sıkıntılı olur.

Bakalım ilerleyen günlerde zembereği gerebilmek için neler yapacağız..

Tags: ,

January 28, 2010 1

Teknoloji.

Hani şu anda bu yazıyı okuduğunuz o plastik kutunun içindeki her şey. Her gün değişiyor teknoloji. Bazen tekrarlıyor kendisini bazen yeniliyor..

Bakış açılarımız değişiyor, alışkanlıklarımız değişiyor, teknoloji bazen ayak uyduruyor bazen bize yön veriyor.

3 sene öncesine kadar dokunmatik cihazlar yanlış tasarımlarının kurbanı kalemlerle birlikte pek bir kullanışsızdılar ama teknolojiktiler (!). Sonra birileri dokunmatik bir cihazın gerçekten dokunulabilir bir şey olmasını akıl etti ve gerçekleştirdi. iPhone mobil dünyayı sağdan sola geçirdi. Sadece o incecik, dokunulabilir, kompakt donanımı ile değil, üzerinde çalıştığı müthiş donanımın hakkını veren yazılımları ile de çok büyük bir değişime sebep oldu.Mobil dünyanın donanım üreticileri iPhone‘a bakarak donanım üretmeye başladılar. Yazılım üreticileri mobil MacOsX ‘i temel aldılar. Büyük abiler mobil yazılım pazarına girmeye karar verdi vs. vs.

Mobil pazarın en önemli oyuncusu Nokia bile Apple‘ın mükemmel bir şekilde gerçeğe dönüştürdüğü bu yaklaşımı yeni yeni keşfetmeye başladı.. Binlerce modele sahip olmasına rağmen hiçbir Nokia modeli iPhone’un yakaladığı başarıyı yakalayamadı.. Hatta birkaç yüz tanesi bile tek başına iPhone ile başa çıkamadılar..

Teknoloji durmuyor ya yerinde hani değişiyor, yeniliyor ya kendini.. E-book (elektronik kitap) denilen, başta pasif monochrome ekranları, elektronik mürekkebi ile geldi. Önce gerçek kağıttan kitapların en büyük oyuncusu Amazon el attı e-book işine.. Kindle’ı çıkarttı kısmen başarılı oldu.. Ekran okuma için gerçekten çok başarılıydı, müzik dinleyebiliyordunuz ve internete girebiliyordunuz siyah-beyaz.

Apple ?

Durmadı tabi, tablet bir bilgisayar çıkaracağı söylentileri dolaşmaya başladı.. Bir sürü tasarımcı olası iTablet tasarımlarını ortaya attılar (isim bile çelişkili idi iTablet, iSlate ..). Artık Apple’ın tasarım yaklaşımını anlamış olacaklar ki (sadece basit) ortaya atılan olası tasarımların hemen hemen hepsi dün Steve Jobs‘ın biz Dünyalılara duyurduğu iPad ile hemen hemen aynıydı.

Yine yaptılar. Steve Jobs efsanevi tanıtımı sırasında iPad’in yerini şu şekilde tarif etti; “herkesin telefonu ve dizüstü bilgisayarı var, biz bunların yanına üçüncü bir teknoloji yerleştirmeyi hedefledik ve sanırım başarılı olduk“.

Steve Jobs işe geri döndükten sonra ilk olarak büyük yanlışı düzeltti Intel‘e geçti. Masaüstü ve Dizüstünde çok değerli olan bu adımı yenilenmiş gri-siyah tasarımlı iMac‘ler izledi. iPod‘un başarısını ve gelişimini söylemeye gerek yok herhalde :) Arada o müthiş tasarımcılarının elinden MacBook Air çıktı.. iPhone ile dokunulabilen efsaneyi yarattıktan sonra yine yeni bir efsane ile aramızda. FSF‘nin dediği gibi iBad olabilir özgürlük için; ama teknolojinin bu kadar gelişmiş olması heyecan verici.. Hep Apple yapıyor olsa da ben mutlu oluyorum :)

Tags: ,

August 10, 2009 6

Kısa bir ara…

Birlikte çalışmaktan çok mutlu olduğum arkadaşlarımdan ve sevdiklerimden zorunlu olarak bir süreliğine ayrı kalıyorum; 5-6 aylığına Jandarma Er olarak, aşağıdaki bu güzel evleri ile ünlü olan Safranbolu’ya gidiyorum ;)

Safranbolu Evleri, Yücel Ünlü - Nisan 2007

Görüşmek üzere…

Tags: ,

Older Posts
Newer Posts