03
Feb 08

Boilerplate generator

Faced with the prospect of typing in tonnes of signals & handlers in a pygtk/glade app, I took the programmers perspective “if something is worth doing once, its worth writing a program to do it over and over”, so I wrote a tiny little pygtk/glade generator ironically in perl, its a complete hack that took about 10 minutes to do but works great for my purposes.

You can grab glade-py.pl here, and run it with something like;

glade-py.pl mygladefile.glade output.py wn_mainwindow

and a boilerplate glade file is generated with all the handlers tied up, now the handlers might not all be perfect, as they’re just (self, widget), which won’t fit all cases, but this is more than adequate for saving a lot of effort.


19
Dec 07

Joining the GNOME system monitor team

Hello planet gnome!

I thought I’d repost this entry now I’m on the big pgo and introduce myself along the way. So my name is Karl as you can obviously tell, I’ve been lurking around guadec and lug radio live the last couple of years and had a great time chatting to the gnomers (or gnomies, what is the accepted plural?) here and there, I’ve been on the outskirts of contribution for a while filing bugs and commenting here and there, hacking on the odd cool thing and slowly getting involved. My main project is wine-doors, which some of you may be aware of, wine-doors brings wine to the GNOME desktop in a sensible, user friendly way. Essentially we’re building a package manager for windows apps on GNOME.

After a long time of wanting to get involved with improving gnome system monitor I’ve finally been forced to bite the bullet and get seriously involved with the team. Largely as a result of this bug and being generally annoyed at the design and attitude of the individual contributing.

If you want to see what it’s like so far then check out this image

So now I have super-cow powers on gnome system monitor, what do I plan to do next? Well, this patch is just the first of a pair, the second which I’m working on as fast as I can is to introduce a new colour picker widget (GSMColorPicker) to replace the GtkColorPicker so we can have pretty pictures for the colour pickers like this.

This is about 90% done at the minute, just a couple of bugs and a bit of basic cairo code to go… I’m thinking of pulling this widget back into libsexier too, but expanding it a little. For the time being it is simply being designed to fit in gnome system monitor, be stable and cute and fulfil the requirement.

I’m also going to take a look at updating the default colours to match the new graph widget.

After this, I’m going to have a pop at a long standing bug I reported.

So all in all I’m planning on bringing a little zen to gnome-system-monitor… This all must be completed by 14/1/08 in order for me to get it into gnome 2.22 but this shouldn’t be too hard :)

A little more about me, I’ve been using GNOME since I first tested it out at version 0.9 with redhat 5.2 (correct me if my reminiscence is a little out), I switched from afterstep and never looked back, over the years I’ve pretty much exclusively used GNOME, and watched the incredible improvements that everyone here has made over the last 10 years of GNOME, I’ve been grateful for every last one as my desktop now rocks!

Now I hope to make it rock a little more, along with the above GSM coolness I want to get involved in conduit and have done a few sketches of what I’d like to do with it, but the changes I’d like to make require some rethinking of the UI and an appropriate time to implement them needs to be found.

Lets hope I can make a few little corners of GNOME rock in my own little way :)


11
Sep 07

EMCAScript IE and how to make a web dev laugh

I want to raise a few questions with microsoft about how broken their browser is;

When I assign name=”something” to an input element as part of a form, I don’t expect the document.getElementById(“something”) method to return a reference to the input element, I want it to return a reference to the element with id=”something”, not only is this a completely broken design, it completely breaks any XML processing you’d like to do in internet explorer. So for the microsoft devs that dropped the ball in HTML.

name != id

Next when I assign the handler onchange=”somehandler(this);” to a radio button element, I want that to be called when the radio button changes, not when the radio button has changed and a second click occurs somewhere else, it’s almost like the event has been queued until the next event occurs then it gets processed.

This is what you have to deal with when making something that is 100% compliant with the javascript language definition to IE. And just to be clear both of these bugs (they are not undocumented features) are still evident in IE7.


07
Aug 07

Fittsmenu at last…

For the last few months I’ve been sneaking the odd hour or two to hack on a little project which I’m recruiting a few elite hackers for. This is fittsmenu’ it is a pie menu widget written on top of gobject and gtk. This is however a pie menu with a twist quite literally.

Click to see the video (ogg theora)

You can download the source code: fittsmenu-0.1.tar.gz Hack on it, and enjoy… It is of course very very early, and needs a few minor glitches fixed properly. I need to add a proper destructor to the GtkWidget and figure out a few other bits of widget weirdness. There’s also a bug in the slice width calculation which has been driving me quite mad.

For the time being the makefiles aren’t finished because I’m about to mess around quite heavily with that stuff to prepare fittsmenu to come out of the closet and into its libsexier outfit.

So build it by;

tar -xvzf fittsmenu-0.1.tar.gz
cd fittsmenu-0.1
./configure
make
cd fittsmenu
./fittsmenu

Yes thats right, libsexier… The idea with libsexier is to add yet another widget library to gtk in the same vein as libsexy’s sterling work has. The difference between libsexier and libsexy is that all of the libsexier widgets will be cairo rendered custom widgets rather than composite widgets. The idea is to make them highly interactive visually appealing widgets with some extra blingyness. Currently I have plans for the following widgets other than fittsmenu

  • Dock menu – a gtk menu derivative using the integral scale function of the OSX dock
  • Smooth scrolling line graph, to consolidate some of the duplicated effort in a themable way (gnome-system-monitor, gnome-power-manager for example)
  • Other graphs and charts pie, bar etc…
  • Icon hint widget, a popup widget which simply takes an icon at x,y position and scales it up or down while fading it out. This is similar to the OSX application launch animation.
  • A few other surprises I’d like to keep that way for now…

UPDATES

  • With thanks to Rob Taylor of codethink there is now a gitrepo of libsexier and the autotools stuff is getting fixed up.
  • Forgot to mention that tooltips/icon labels will be shown when hovering over the icons in the centre of menu when bug 43706 is fixed.
  • As a few people have pointed out, fittsmenu isn’t always an ideal replacement for every context menu, however it is something that drawing applications could benefit from, other situations could also benefit however it is all about getting the situation right rather than just blinging everything up for the sake of it. If anyone wants to chat with me about implementing fittsmenu in their app (Inkscape guys I’m looking at you) then please get in contact via email.

10
Mar 07

Wine-doors: Bling intels awakening

For some bizarre reason it seems cairo renders much faster on my macbooks less than powerful i945GM card, and the rendering is less than perfect on my nvidia 6800GT. Surely a card with 4 times the memory, and a faster GPU should out perform a laptop intel?!

Either way, the laptop has been used to bring you…


06
Mar 07

Wine-doors: Beginning of the bling!

I’m just adding in some primitive animations into wine-doors, I have some complaints, the dismal speed of pycairo for one, I think I need some glitz?!

Although there are a few jitters, the animation is working OK, I need to do some other things to it and try to smooth it out a bit


10
Feb 07

Loads of code working! FINALLY!

I’ve just brought back to life the ApplicationPack ramblings of the early stages of the project and now wine-doors can in fact install an application into wine from the command line. Its all very early stages in this because it hasn’t been updated in a long time. I’m looking forward to getting installer command line arguments passed and working nicely, I also want to use AutoHotkey for this part of the process however without testing it at all this will have to wait.

I’m going to go through the queue display, manipulation and processing tomorrow, and maybe add some animations like;

  • Adding a package to the queue fade and shrink
  • Downloading status image/animation
  • Status text hooks for various activities

While I’m doing all that I’ll probably do some work on showing and adding all applications where updates are available.

All thats really needed for wine-doors between now and an initial release is completion of the application pack dtd, a few more wine-tools parsers (application pack creation), tying up lots of UI loose ends (file handling and lots of error handling). 0.1 here we come!!!!


29
Jan 07

wine doors events

Finally got around to sorting out the mouse interaction with the new tile interface in winedoors this is the beginning of the end for the user interface development the ui of course is only part of the picture but i want it perfect. Once the ui work i’ve really wanted done is finished, i shall finally update the ApplicationPack and queue classes along with a variety of other updates vit has suggested to the xml there isn’t a great deal of work involved in this so hopefully a realease will be in sight soon.

I’m enjoying the thumb pad on my n800. Its much faster than fiddling with handwriting or a stylus it seems then that apple are going the right way with iphone.

Of course imrovements could be made, but this is the same thing that bugs me about predictive text. I remember reading a book on touch typing when i was young. One thing that i remember clearly is that the keys on a keyboard are layed out in qwerty style to avoid jamming on old mechanical typewriters based on the the improbability of those letters adjacent being used in succession. This old design rule provides interesing possibilities for sensing incorrect presses. By evaluating the letter probability via a markov syle character matrix then using a dictionary to support the AIML approximation thumb typing coud be even more accurate. Chances are that this is ho apple have made the iphones thumb interface so accurate.

it’s what i’d do!! hell i might even create a patch ;)


28
Jan 07

Why wine-doors isn’t a heap of horse shit!

I’ve just added some lightning fast filter code into wine-doors, based on my filter testcase. its fast, the only thing really slowing it down is the cairo-renderer, however that delays all treeview redraws. I just hope Carl Worth and MacSlow do something to improve the overall speed of cairo soon.

As it stands it takes no time at all to filter the current packlists. All I need to do now is add in the code to do button operations, ratings and votes and things should be off to a good start for finishing up release 0.1, at least I hope it will be ready soon.

Summary of fixes today:

  • Fixed downloader caching
  • Updated some packlist parsing stuff
  • Added filtration into the UI
  • Began adding treeview events

Check the code out and try it! It’s starting to shape up like a really polished application.


16
Aug 06

Why the dock is good…

The dock, OSX dock, cairo dock whatever scaling rolling blingy dock it is, it is after all a dock, is one of the most pleasant user interface elements to use and most people center on the elements like “I can’t fit much on it”, “all my icons look alike” and “I don’t know where on the screen my icon will appear next” as reasoning to demonstrate that the dock is flawed from a user interface stand point.

This is completely wrong and heres why;

  • No single user ever does more than a few things with their computer the most often used applications should always be the ones displayed
  • Icons shouldn’t look alike, and I grant this one but it is easily fixed
  • Because of the design of the dock you don’t need to know where your icons will appear next…

Crucially over the years as the dock has been considered and various replicas have emerged one thing remains apparent, the dock does seem to be a good design, it occurred to me yesterday why…

Fitts’ law states that the time to a target is a function of the distance and size of the target. Here’s the thing the edge of the screen is an infinitely large target, once there you have targets which are not only large in the way they scale but also reduce the distance to the next icon by a method of scaling and positioning so the overall distance to the next target is typicaly 1/3 of the distance it appears to be because of the scaling and positioning effect, by reducing the distance to the target and increasing the size of the target the time to target goes down dramatically as a result.

So perfectly simple but how do we solve the other crucial problems, by creating a list of recently used applications using SLAB code you could display say, 5 most often used applications. Next in line you have an “Applications” button, which will popup the SLAB application browser, next you have a buddy icon which will either popup or start a new instance, a mail icon which displays the current inbox items, a control center icon which will popup gnome control center (or SLAB) and a universal trash/eject/disconnect/exit on drop/go away icon. It would be ideal if icons could be little plugins shipped with the applications and could call external applications with special window decoration having an arrowy bit pointing to the windows position on the dock (how plausible, god knows)… You could even have a plugin for documents icons, showing 3 recent or open documents with a popup for all open and most recent doucments.
We bring together elements of SLAB and gimme here and form them into a user interface which has some brilliant advantages in time and agility. Their are a lot of ideas I have for cairo dock, I’d love to make it a couple hundred frames faster though, especially without Xgl/Glitz I think pango is a serious factor in the speed, and also librsvg is kinda slow. There must be a better way.

This is partly in reply to begun the bling-wars have by the effervesent MacSlow

I think there needs to be a bunch of different elements which can be used easily, obviously these should render as GTK widgets or be usable as widgets. User interface bling after all doesn’t have to be monolithic, look at what cairo does for simple things! However, as widgets they shouldn’t simply be confined to their own space in an application, you should be able to manipulate them as elements which are outside of a window border and use shaped input when overlaying them full screen.
Loading a tiny open GL plugin or chain/pipeline are probably better words you could apply effects from a library of elements for instance, you could load a wireframe of a teapot and spatter all over it PG Tips, this effect runs in which ever element you decide to embed it in, same goes for cairo animations and the cairo/gl devide must be breached anyway in much the same way SDL/GL work together in games like unreal tournament, by putting together shaders and textures and objects and drawings and animation together into an easy to use framework (i used the dreaded f word), the chain could provide staggering effects with only a few plugins, AVS in winamp and Core Animation are fairly good examples.

As I see it there needs to be a marrige between cairo/gl/compositing/gtk and possibly cairo-anim which is a library I’m planning on derriving from cairo-dock.