Tuesday, October 12, 2010
Wasting time ranting and not doing it
This is just silly, the time used to rant about how hard it is could have been spent making the .deb. It is not that hard to create and you can always use another source deb as a template. There are plenty to choose from.
Monday, October 04, 2010
Wine 1.3.4 on arm (N900)
After reading the announcement of wine 1.3.4 and particularly this on winehq: "Winelib now supports the ARM platform" I just had to try it.
Builds fine in sbox, no problems there. Initial run takes a while of clicking on cancel as winedbg crashes but after that the built in programs runs, but the window manager is not doing such a great job with the wine windows and dialogs.
Screenshots of winemine below:
Update 15.10.2010:
Using desktop mode makes using wine much nicer and keyboard input works too. Running winecfg is a bit problematic as it won't fit the screen properly but editing ~/.wine/user.reg and adding the following lines in the end enables desktop mode:
Builds fine in sbox, no problems there. Initial run takes a while of clicking on cancel as winedbg crashes but after that the built in programs runs, but the window manager is not doing such a great job with the wine windows and dialogs.
Screenshots of winemine below:
Update 15.10.2010:
Using desktop mode makes using wine much nicer and keyboard input works too. Running winecfg is a bit problematic as it won't fit the screen properly but editing ~/.wine/user.reg and adding the following lines in the end enables desktop mode:
[Software\\Wine\\Explorer] 1287126526 "Desktop"="Default" [Software\\Wine\\Explorer\\Desktops] 1287126530 "Default"="800x480"
Monday, August 23, 2010
GPS information widgets
I've been busy with splitting out and rewriting the GPS information widgets from Mapper. I've also removed all the gdk rendering code and using cairo only.
Below is a screenshot from testing app:
Below is a screenshot from testing app:
Friday, August 06, 2010
Creating a large map from OpenStreetMap map tiles
We where planning at work to print large maps of the BSR on plywood and create a puzzle out of it, I think it was 1x1 meter. I made the following simple bash script to download and stitch the tiles using ImageMagick:
Unfortunately printing and large sticker or directly on plywood was out of the budget so in the end it wasn't needed. The fallback was handpainting, not as accurate, but looks pretty good still.
Anyway, I post this tiny script in here in case someone else might need something like it as I didn't find anything suitable when I was searching for a quick and simple solution. The best would of course had been to create a custom map using mapnik and all that, but it would have take too much time (and I don't have any hardware to play with at work, only my laptop with a tiny disk)
#!/bin/sh
#From
#http://c.tile.cloudmade.com/fd093e52f0965d46bb1c6c6281022199/3/256/7/66/26.png
#To:
#http://b.tile.cloudmade.com/fd093e52f0965d46bb1c6c6281022199/3/256/7/76/42.png
Z=7
URL=http://tile.cloudmade.com/fd093e52f0965d46bb1c6c6281022199/3/256/
download_tile() {
FILE=tile_${x}_${y}.png
if [ -r $FILE ]; then
echo .
else
curl --output tile_${x}_${y}.png ${URL}/${Z}/${1}/${2}.png
fi
}
for ((x=66;x<77;x++)) do
for ((y=26;y<43;y++)) do
download_tile $x $y
sleep 0.1
done
montage -geometry 256x256 -tile 1x17 tile_${x}* map_${x}.png
sleep 1
done
Unfortunately printing and large sticker or directly on plywood was out of the budget so in the end it wasn't needed. The fallback was handpainting, not as accurate, but looks pretty good still.
Anyway, I post this tiny script in here in case someone else might need something like it as I didn't find anything suitable when I was searching for a quick and simple solution. The best would of course had been to create a custom map using mapnik and all that, but it would have take too much time (and I don't have any hardware to play with at work, only my laptop with a tiny disk)
Wednesday, June 30, 2010
Signatures
My workplace is tied to environment protection and such and I've been wondering now for a while now, how much resources are wasted on processing e-mail signatures? We have a policy to have all kinds of crap in the signature, about 25-30 lines... sigh, fortunately nobdy enforces it so my signature is a whopping 2 lines, but I digress.
Anyway, many thousands (millions?) of servers need to process e-mail all the time, checking for spam and filter to folders and so on. So if the body of the mail is 1-2 lines and the rest is just baggage, how much energy is now wasted just to move the useless signature around ? One e-mail may not be much, but when you think about how much e-mail is transferred all the time and going to many routers and servers. It must add up to quite a lot don't you think?
Anyway, many thousands (millions?) of servers need to process e-mail all the time, checking for spam and filter to folders and so on. So if the body of the mail is 1-2 lines and the rest is just baggage, how much energy is now wasted just to move the useless signature around ? One e-mail may not be much, but when you think about how much e-mail is transferred all the time and going to many routers and servers. It must add up to quite a lot don't you think?
Thursday, June 24, 2010
The problem with maemo (and meego in a way too)
I've been a happy user of both the original Nokia 770 tablet, the N810 and N900. From the point of view of a normal user I've been very happy with all of them, they have done what they promised and as a user I don't have that much to complain about. But..
As a developer I was drawn to the original tables as it was gobject/gtk+/gnome based with no bloat of C++ or some java stuff.
Made it easy to create software and somewhat easy to support both desktop and tablets in the same software, with some ifdeffing for maemo specific parts (gtk/hildon). That was more or less working in 2007-2008, but currently it's a blody mess.
Trying to support Gregale, Diablo, Fremantle and normal desktop gnome in the same app is these days such a pain that I've almost lost interest to do anything at all (one reason for Mapper developing at a snail pace currently).
Even Fremantle, that should use the latest technologies, (and Diablo) is stuck in the stone ages, gtk is in the 2.10 series (3-4 yeras old) Gregale is even worse with 2.6. Same with glib. Then we have gnome-vfs and gio mess.
And tablets specific Hildon changes, 3 almost compatible versions. Then we have 3-4 different UI styles to support.
And now upstream gtk+ is moving to version 3.0 and GNOME applications should move over to it. GConf is going to be deprecated with GSetting/dconf.
Now what the fuck are you supposed to do as developer wanting to support all tablets and desktop in the same app?
As a developer I was drawn to the original tables as it was gobject/gtk+/gnome based with no bloat of C++ or some java stuff.
Made it easy to create software and somewhat easy to support both desktop and tablets in the same software, with some ifdeffing for maemo specific parts (gtk/hildon). That was more or less working in 2007-2008, but currently it's a blody mess.
Trying to support Gregale, Diablo, Fremantle and normal desktop gnome in the same app is these days such a pain that I've almost lost interest to do anything at all (one reason for Mapper developing at a snail pace currently).
Even Fremantle, that should use the latest technologies, (and Diablo) is stuck in the stone ages, gtk is in the 2.10 series (3-4 yeras old) Gregale is even worse with 2.6. Same with glib. Then we have gnome-vfs and gio mess.
And tablets specific Hildon changes, 3 almost compatible versions. Then we have 3-4 different UI styles to support.
And now upstream gtk+ is moving to version 3.0 and GNOME applications should move over to it. GConf is going to be deprecated with GSetting/dconf.
Now what the fuck are you supposed to do as developer wanting to support all tablets and desktop in the same app?
Wednesday, June 16, 2010
How to change hildon context menu content depending on context
Mainly as a reminder to myself, but if you need to change the content of a context menu set with gtk_widget_tap_and_hold_setup() connect the "show" signal and do you show/hide in the signal handler.
Create your menu, connect signal and setup tap-and-hold:
Then in your handler, check what you need and hide/show menu items:
Create your menu, connect signal and setup tap-and-hold:
menu=GTK_MENU(hildon_gtk_menu_new()); g_signal_connect(G_OBJECT (menu), "show", G_CALLBACK(menu_items_visibility_cb), NULL); gtk_widget_tap_and_hold_setup(widget, menu, NULL, 0);
Then in your handler, check what you need and hide/show menu items:
static void
menu_items_visibility_cb(GtkWidget *menu, gpointer data)
{
if (foo) gtk_widget_show(menu_item_foo); else gtk_widget_hide(menu_item_foo);
}
Subscribe to:
Posts (Atom)


