Seeing that Martyn has updated his blog with some sweet tracker info, I figured I could do the same
The main feature I’ve been last working on (together with Martyn) is libtracker-miner, Which will ease the creation of data miners for tracker-store (that is, objects that extract useful info from applications and such and transform it into SPARQL, which is pushed into tracker-store).
The idea behind this is that one can develop both independent miners and plugins for the most popular applications which translate data to something Tracker can understand by implementing the TrackerMiner object.
This object also implements control logic, so the control of all available miners can be reduced to a single point, there is also a reworked tracker-status-icon which does precisely this, this is how it currently looks like:
There is also a TrackerMinerFS base class, which eases directory crawling, monitoring and other filesystem features. This is the base object for both applications and files miners.
XInput2 + GTK+
There’s much progress going on here, I empirically suck at blogging, but I promise I’ll make an update about this soon
So, today is officially the last day for the hackfest, it’s been a quite exciting week, with lots of discussions, ideas flowing around and crazy experiments, which had lead us to an agreement on how should a new theming infrastructure be.
People here have been working really hard to get different parts of the lower level infrastructure right, such as CSS theming, the GStylable interface, hit detection for non-rectangular shapes, etc… I’ve been mostly focusing on the replacement for GtkStyle, this is what has been achieved so far in that field:
- Current API limitations: GtkStyleContext would be able to store any kind of data, it’s kind of a hashtable with save/restore habilities, being able to store much more information that could be relevant to engines (goodbye detail string! goodbye widget peeping!), All drawing would be done on top of cairo, one important detail is that the engine wouldn’t get even get the widget pointer (quite necessary for third-party projects using GTK+ theming)
- Animations: These are focused to state changes and are mostly implicit if they affect the whole widget. The style context has to be told if they affect part of the widget though (a checkbox in a cellrenderer, for example). There can also be several animations for different state transitions running at the same time:
Parallel prelight and checkbox animations running, slowed down for appreciation. Glitches will be fixed by correct properties inheritance
- Containers are able to pass placing information to children’s context: Think comboboxes, spinbuttons, notebook tabs, … Now painted elements can get a clue about how do they connect visually with other nearby/related elements. Of course engine implementations will be able to just ignore this information.
Nevermind the ugly rendered elements, that’s up to artists :). The code is in my github repo, in case anybody wants to give it a try.
There’s now just less than a week left for the theming hackfest! I’m quite looking forward for what may happen there, it looks really promising.
So, out of excitement, I’ve began dumping some ideas into a GTK+ git repo. Of course, this is just proof-of-concept code, years light from finished, etc… but hopefully it will help make further ideas start flowing
And now a meaningless screenshot!
This is 9 separate boxes painted through the new API, it would allow containers to hand their children information about the placing context in a group, so the engine could know how to connect elements together. GtkStyleContext could contain any data, so it’s fully extensible.
Sorry, nothing related to sex! Since my previous post, I didn’t actually hack much on getting MPX working, mostly blocking on the lack of ideas about a good API. That was until ImendioConf, where a talk with Richard about the subject made ideas start flowing, so here’s my late christmas present!
Besides making GDK use XInput 2.0, The main change is at the GtkWidget level, I’ve introduced GtkDeviceGroup and the “multidevice-event” signal. GtkDeviceGroup is just a container for GdkDevices, each widget can have several GtkDeviceGroups. The “multidevice-event” reports grouped motion events for the devices contained in a GtkDeviceGroup, it also provides hints about the latest event that happened and whether a device was just added,removed or updated.
The idea is, a widget would add devices to a group on button-press, enter-notify… remove them on button-release, leave-notify… and would get grouped motion events for all these devices in between. In the repo there are also a couple of test apps to show this working.
Obviously, there are quite some things left, I’ve collected missing stuff I’ve identified in the wiki, so if you feel curious about multitouch, compile xorg and help out!
And now of course, some videos of the examples
No! this isn’t another “added tabs to $APP” , Instead I decided to spend my hacking time on getting MPX work with GTK+. Surprisingly, gdk is 99% prepared to handle multiple pointers, so besides adding support there for the new XInput method to handle device grabs, most of the remaining work should just be focused on making GtkWidgets deal sanely with multiple pointers (madness awaits there…). Here’s a “screencast” of my proof app, apologies for the quality, trying to record and use both the nipple thingy and the touchpad isn’t quite easy
Also, I’ve spent one extra week in Istanbul and surroundings with Mitch and Pia, It has proven to be a really beautiful place full of life, returning to Turkey is a must.
 You caught me guys :), I was seriously concerned about your sanity for a while
Update: In case it isn’t clear, the patch isn’t really far from the “evil hack” state, I’ll just submit it to bugzilla as soon as there’s some reasonable base work in which other smaller patches can be developed incrementally.
Almost everybody had some boss that was too exigent about how you spend your work time, but this time it got too far! This is the backtrace I’ve got from epiphany several times:
Program received signal SIGSEGV, Segmentation fault.
#0 ephy_node_db_is_immutable (db=0x854f2c0)
#1 0x080a7ad9 in resolver_found_cb (resolver=0x8507240, interface=3,
protocol=GA_PROTOCOL_INET, name=0x951d5d8 "Richard Hult",
type=0x9229338 "_http._tcp", domain=0x9705e98 "local",
host_name=0x9166308 "Celery.local", address=0xbfa12944,
port=<value optimized out>, txt=0x883a960, flags=4, data=0x8547620)
#2 0xb7f86fbf in ga_signals_marshal_VOID__INT_ENUM_STRING_STRING_STRING_STRING_POINTER_INT_POINTER_INT () from /usr/lib/libavahi-gobject.so.0
Please, at least let me browse API docs and repositories, I promise I’ll behave!
It’s been already more than 6 years since my first contribution to what then was called the ximian-setup-tools. Shortly after that, I was given the oportunity to maintain them, which has been quite rewarding during much time. But lately I’ve grown the urge to move on and hack on other things I nowadays consider more exciting or funny.
So, after 2.21.x I’ll consider both gnome-system-tools and liboobs orphan, left in the cold, crying for a new maintainer! If you want to add some emotion to your life, have these midnight wakeups because you forgot to upload that tarball or just think you had to be maintainer once in your life, please contact me!
If anyone wants to bite the bullet, I’ll of course be around to clear up doubts. Else, I think I’ll just be doing tarballs occassionally.
My USB mouse is getting crazy, it sometimes moves the pointer by itself to some random corner and refuses to get it out the there for a while. This leaves me confused for a few seconds, shaking the mouse like crazy and looking at all corners, trying to locate the pointer again.
Of course, the “locate pointer” option in control-center is quite useful, but looked quite ugly enough to make me deactive it again for a couple of times, until I worked on that some days ago!
click to see the animation
Obviously, this effect will only be used if there is a composite manager available, a quite fun hack. I’m really glad that it has been included in gnome-settings-daemon 2.21.x
If you began using emacs22 and you were used to gtk-doc.el, you probably noticed they aren’t good friends. I had to wipe the dust to my lisp, but I’m glad to tell you there’s already a fix! Right, it also modifies the function not to insert unnecessary trailing whitespaces. Emacs should enable show-trailing-whitespace by default, so we’d all hate them
One of the things I’ve been doing lately at Imendio is a GIO/GVfs powered GtkFileSystem implementation, finally today it reached a really usable state (there are a few quirks left though), I’m already thinking in moving the GnomeVFS implementation away and put this one in its place
On the API, I must say Alex has done a really nice job, GFile has a really powerful and easy to use API, thumbs up!
If you want to play with it, clone the the module from git://git.imendio.com/carlos/gtk-file-system-gvfs.git (or see it here), give it a spin and tell me how it went!
Of course there’s a screenshot for the unbelievers! we could play “spot the difference” with it:
Update: WordPress sucks, it insisted in linking the image to some place inside my admin page…
Due to the “Canvas evaluation moderator” GtkTask, I’ve been informing myself quite a lot about the different available canvases and their possibilities, and one concrete feature available in some canvases grabbed my attention: timelines.
Timelines could be beneficial not only for canvas, but probably toolkit-wide to some extent, as people wants bling here and there, and animations are a part of it. So I began experimenting with a timeline object (which I’ve just submitted to bugzilla, see #444659) and the results don’t look bad so far:
Useless animation (Code)
Useless animation, applied (#328090)