Call for devs [part II]

[Advice: this post is Gentoo GNU/Linux - oriented]
 
Hello again folks :)

This second part of the post is about a project of mine i started at the beginning of the 2009 and that still lies there on gitorious (today moved from github to gitorious). I started a GUI for emerge, the packages administration utility in Gentoo. I know it is a bit of an ambitious project since emerge does not provide an API iirc, so this project is "just" a command-line parser. But I started it with no particular ambition except for my own will to have some sort of advanced GUI on top of emerge. It is called Gluk (almost-casual name so do not ask me what it stands for).

I spent some time writing some sort of wrapper library that tries to handle emerge transparently to the user. There are nice classes currently and I will just sum them up here in order to (hope so) whet the appetite :-P.

Classes:

• Ebuild: this class inherits QFile and adds some useful methods that ease Ebuild files reading (useFlags(), description(), keywords(), sourceUrl()... and so on)
• Package: this class actually represents the package installed or to-be-installed on the system. You can think of as an instance of the ebuild file.
• GlukTreeModel: a QAbstractItemModel inheritance that makes easier browsing the portage tree.
• PortageEngine: a singleton class that actually does the dirty work representing an interface to Portage.

 

You can have a look at the project here. It currently builds and I encourage you to try it but do not expect anything special. Iirc it currently only does packages pretending :).

If you run Gentoo GNU/Linux and want to contribute please let me know since i'd appreciate much!! Ideas are of course welcome :)

Cya!!

Call for devs [part I]

Hello dear KDE community. It's pretty much you do not hear from me. I finally finished my exams and now I'm working at my thesis project. You'll hear about it as soon as I graduate since I'd like it to be useful to us. But I'll talk about it later on, in a dedicated post.

 
The "call for devs" I'd like to talk about is about two projects. The first one is about the Media Center project for the Plasma Shell. Unfortunately I couldn't manage to write code anymore for it and it is still there hanging on svn. I placed a README file in order to clarify what the current status of the project is. Nice features got implemented but many need to be tested and written still. That's why we have two GSoC ideas (and other in my mind might probably be added to the list) that should interest you (or some of you :).


So let's go through the ideas.


MediaBrowser backends and API:

This is a pretty huge and interesting project imho. There is already code written for this and I'd like GSoC'ers to take care of it in order to improve the API and write new backends. But let's go step by step.


As some of you might remember the Media Center project aims to make use of the main pillars of Plasma in order to develop the Media Center Components KDE should make use of to play multimedia contents. I won't go again into the details (if interested go back to my old posts). The MediaBrowser is what we are talking about here. It is one of those components and actually it is an applet that was designed to ease the navigation through the media contents available both on your home PCs and on the net. The navigation through different contents should be done with the help of the DataEngines that are able to retrieve data from different resources. So, the MediaBrowser Applet exposes an API that allows developers to write their own backend to fetch different contents from different resources. Technically each backend must give access to a QAbstractItemModel used by the view of the MediaBrowser.
Currently we only have a local-file backend that just allows browsing through local files on your pc. But, together with the KDE-Silk people, we already have some dataengine ready to be used with the backends. First of all there is the video-dataengine. It is a generic dataengine that supports backends. It actually uses an unified data structure that extracts the relevant datas from each backend in order to expose video sources through Plasma. Currently we have just one implementation: YouTube dataengine, and it works pretty well. Other backends should be written for vimeo, blip.tv and so on. We also have pictures dataengines (picasa and flickr) and i'd like them to be also put as backends of a generic picture dataengine. In addition to this the idea is to start writing other backends for the MediaBrowser applet able to query and fetch data from the generic video and image dataengines in order to let the user browse through his favourite web service video/pictures providers.

Of course more proposals within this field are apreciated so, just start from reading the README file and ping me on IRC if you need more clarifications.


The second idea is:

Ui re-styling:

This is a really needed project for the Media Center. Let's say I didn't focus so much on the look and feel of it during the development so we need to polish the GUI. The aim is to make use of the QtDeclarative stuff hoping it'll be ready to use by the beginning of the GSoC. Unfortunately i cannot tell you much about this since I didn't spend much time hacking with this feature from Qt. I suggest you to come on #plasma and directly ask if you are interested in this project. The aim is to write a dynamic UI that would make Media Center appear shiny and easy to use :).

I hope this stuff will interest you. The project directory is browsable at Media Center Components

Start hacking on it if you feel so that you'll be prepared and more aware of what I'm talking about when you'll submit your proposal.


Cheers!