It's funny that, exactly one year after my previous post, my current pet project is exactly the same as it was last year! But both the hardware (N900 vs N950) and the software have been upgraded...
March 31, 2012
March 8, 2011
Despite the Twitter crazy, I still feel like talking a bit about some recent project of mine.
grmgpsd, an old school Garmin GPS protocol emulator. It was born by merging two of my older projects, nmeagend and garmintalkd. The first one was a NMEA "server" from the N900's liblocation data, while the second one was a Garmin binary PVT (Position - Velocity - Track) protocol server. Both allowed you do moving map on a PC using your N900 as GPS.
However, after implementing the PVT part of the protocol, I knew it would be extremely easy to implement the rest of the Garmin binary protocol. So I tried to find a use case for such implementation ;). The use case is as follows:
grmgpsd, an old school Garmin GPS protocol emulator. It was born by merging two of my older projects, nmeagend and garmintalkd. The first one was a NMEA "server" from the N900's liblocation data, while the second one was a Garmin binary PVT (Position - Velocity - Track) protocol server. Both allowed you do moving map on a PC using your N900 as GPS.
However, after implementing the PVT part of the protocol, I knew it would be extremely easy to implement the rest of the Garmin binary protocol. So I tried to find a use case for such implementation ;). The use case is as follows:
Yes, you can now use whatever software you used to manage your Garmin's GPS tracks, etc, to manage your N900's content. You can even use that software to exchange them! And, if the magic keywords are not uttered by the host PC, it will appear to be a off-the-shelf Bluetooth NMEA GPS.
What N900 content? Yes, good question. So far, it's all stored in sqlite database whose format was designed ad-hoc. I also made a very simple track logging application that fills the "Active track log" track in such database.
Yet, my plan is to use someone else's program as storage, like, for example, Columbus.
The source is, as per usual, available on my Gitorious.
What N900 content? Yes, good question. So far, it's all stored in sqlite database whose format was designed ad-hoc. I also made a very simple track logging application that fills the "Active track log" track in such database.
Yet, my plan is to use someone else's program as storage, like, for example, Columbus.
The source is, as per usual, available on my Gitorious.
March 8, 2011
So I guess I finally understood Twitter's raison d'être: to be able to post absurdly short blog posts like this one without feeling any embarrassment... because every other blog post is also absurdly short!
Since I deduced that being able to write shorter content-less blog posts would probably mean I could easily force me to write something, well, I gave up and created a twitter account: http://twitter.com/javispedro .
Still doing nothing with it, but will probably start following random people soon :D .
Since I deduced that being able to write shorter content-less blog posts would probably mean I could easily force me to write something, well, I gave up and created a twitter account: http://twitter.com/javispedro .
Still doing nothing with it, but will probably start following random people soon :D .
August 8, 2010
So the deadline is approaching, and slowly all features start appearing:
Pretty much like the way you could on Maemo, the virtual keyboard allows you to copy/paste from it (see the buttons on the top right corner -- prefixed with !! because of an error with my i18n setup). This now works with Gtk+ apps too, even with a stock/nonHildon Gtk+, as long as your text widgets implement GtkEditable or are subclasses of GtkTextView (gedit is the latter).
Even if there's data available on the clipboard, and text selected in a window, only one button appears (so you can't select text and replace it with the clipboard contents). This seems to be an arbitrary UI decision.
The MeegoTouch IM framework has different layouts for each "content type" a text field can handle -- something equivalent to hildon's InputMode property. Since there's no "standard" way that I know of for Gtk+ applications to send "hints" about content type to input contexts, other than setting up different GtkIMContext subclasses for each and every configuration and then setting a widget's "im-module" property, I decided to use g_object_set_data / get_data for hints. For example,
Hildon used a new property ("hildon-input-mode") which was defined in GtkEntry, GtkTextView, etc. Of course, when building with the patched Gtk+ you can still use it.
With content type set to "phone number", the layout presented is certainly interesting because one of the buttons does not generate text instantly: the "*+" button cycles between *, +, w... each time you press it (aka "multipress"). Works too :)
Custom toolbars! I really overestimated the difficulty of this. Turns out, a custom toolbar is just a plain xml file which looks like this:
Each widget can be associated to a different toolbar -- for example, the way I decided for now to allow to do this in Gtk+ is:
When the widget gets focus for the first time, the filename is sent to the input server, which parses it and creates the Qt widgets for you -- afterwards, you can still modify certain attributes of the toolbar, like whether buttons are pressed down or not. Unfortunately, I couldn't find a nice way to design a equivalent API for this in Gtk+, so for now you can only attach toolbars but not modify them. A sane API should implement at least a new class for this and so far I'm don't think defining new classes in a IM Context Plugin is the right way.
Even if there's data available on the clipboard, and text selected in a window, only one button appears (so you can't select text and replace it with the clipboard contents). This seems to be an arbitrary UI decision.
The MeegoTouch IM framework has different layouts for each "content type" a text field can handle -- something equivalent to hildon's InputMode property. Since there's no "standard" way that I know of for Gtk+ applications to send "hints" about content type to input contexts, other than setting up different GtkIMContext subclasses for each and every configuration and then setting a widget's "im-module" property, I decided to use g_object_set_data / get_data for hints. For example, GtkEntry *entry = gtk_entry_new();
g_object_set_data (G_OBJECT (entry), "meego-im-content-type",
GINT_TO_POINTER (MEEGO_IM_CONTENT_NUMBER));
Hildon used a new property ("hildon-input-mode") which was defined in GtkEntry, GtkTextView, etc. Of course, when building with the patched Gtk+ you can still use it.
With content type set to "phone number", the layout presented is certainly interesting because one of the buttons does not generate text instantly: the "*+" button cycles between *, +, w... each time you press it (aka "multipress"). Works too :)Custom toolbars! I really overestimated the difficulty of this. Turns out, a custom toolbar is just a plain xml file which looks like this:<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE MEEGO_IM_TOOLBAR_WIDGET SYSTEM 'VirtualKeyboardToolbarDTD.dtd'>
<toolbar>
<button name="buttonsmile" group="buttonsmile" priority="1" showon="always"
alignment="left" icon="/usr/share/widgetsgallery/imtoolbar/icons/icon-m-messaging-smiley-happy.svg"
size="80%" text="" text_id="" toggle="false" pressed="false">
<actions>
<sendstring string=":)"> </sendstring>
</actions>
</button>
Each widget can be associated to a different toolbar -- for example, the way I decided for now to allow to do this in Gtk+ is:
GtkEntry *entry = gtk_entry_new();
g_object_set_data (G_OBJECT (entry), "meego-im-toolbar",
"/usr/share/widgetsgallery/imtoolbar/exampletoolbar1.xml");
When the widget gets focus for the first time, the filename is sent to the input server, which parses it and creates the Qt widgets for you -- afterwards, you can still modify certain attributes of the toolbar, like whether buttons are pressed down or not. Unfortunately, I couldn't find a nice way to design a equivalent API for this in Gtk+, so for now you can only attach toolbars but not modify them. A sane API should implement at least a new class for this and so far I'm don't think defining new classes in a IM Context Plugin is the right way.
June 22, 2010
So the input context skeleton is finally in place, and gedit can start receiving commit signals from the MeegoTouch keyboard:
I can even create new documents and switch tabs while typing on it, and it correctly follows focus. Not much else to try yet!
Many thanks to murrayc for Multipress Input Method, from which I took many build system related bits and of course to Mohammad Anwari for the original Hildon Input Method.
May 23, 2010
Hello everybody,
I've been selected, as part of the Google Summer of Code project, to work on what will become a Gtk+ Input Method that communicates with the MeegoTouch (previously, Direct UI) Input Method UI Framework.
Basically, input methods either modify or completely replace the flow of characters from your keyboard, keypad,... to whatever applications show in their input fields. They can be either virtual keyboards, thus generating key events on their own, based on mouse input; they can filter some of the key presses on your physical keyboard to allow you access to way more characters -- for example, the "acute" character on some international layouts doesn't produce an acute symbol, but instead combines with the character the next key would produce to form an entirely new character. Of course, you can use both approaches, and have something like the hardware keyboard with symbol palette that the N900 uses, or even way more complex things.
So, when I realized that the next version of then-Maemo6 was going to use a new, Qt-specific input method framework, I knew things would look bad for Gtk+ applications on the platform. If you've ever tried any non-Gtk+, not-Qt application (DOSBox, for example) on the N8x0, or N900, you know what I'm talking about. This is something that would kill usability of most existing Maemo Gtk+ applications, and not only for international users. Clearly, fixing this is quite an important TODO item.
Also, I had already been experimenting with trying to integrate the Maemo-5 input method framework (known as Hildon Input Method, or H-I-M) with SDL, so when I looked upon the idea, I knew this was going to be interesting.
But this is not all -- Harmattan was being slowly cooked in the open, and I was practically ignoring it. MeegoTouch, Qt, etc. is without doubt going to replace most of what I currently know and use, and thus I'm really interesting in getting the hand of it. So I also see this project as an oportunity to get used to the entire stack.
So what did I do first? Well of course, try to run everything.
Of course note that this is using the development theme, and also I was not using the MeegoTouch compositor at the moment, so no translucency goodness: the final UI should look much prettier.
Well, the official GSoC start date is tomorrow. I plan to use this blog to put in news, development progress (hopefully biweekly) or interesting tidbits I discover from the entire MeeGoTouch stack. See you until then!
I've been selected, as part of the Google Summer of Code project, to work on what will become a Gtk+ Input Method that communicates with the MeegoTouch (previously, Direct UI) Input Method UI Framework.
Basically, input methods either modify or completely replace the flow of characters from your keyboard, keypad,... to whatever applications show in their input fields. They can be either virtual keyboards, thus generating key events on their own, based on mouse input; they can filter some of the key presses on your physical keyboard to allow you access to way more characters -- for example, the "acute" character on some international layouts doesn't produce an acute symbol, but instead combines with the character the next key would produce to form an entirely new character. Of course, you can use both approaches, and have something like the hardware keyboard with symbol palette that the N900 uses, or even way more complex things.
So, when I realized that the next version of then-Maemo6 was going to use a new, Qt-specific input method framework, I knew things would look bad for Gtk+ applications on the platform. If you've ever tried any non-Gtk+, not-Qt application (DOSBox, for example) on the N8x0, or N900, you know what I'm talking about. This is something that would kill usability of most existing Maemo Gtk+ applications, and not only for international users. Clearly, fixing this is quite an important TODO item.
Also, I had already been experimenting with trying to integrate the Maemo-5 input method framework (known as Hildon Input Method, or H-I-M) with SDL, so when I looked upon the idea, I knew this was going to be interesting.
But this is not all -- Harmattan was being slowly cooked in the open, and I was practically ignoring it. MeegoTouch, Qt, etc. is without doubt going to replace most of what I currently know and use, and thus I'm really interesting in getting the hand of it. So I also see this project as an oportunity to get used to the entire stack.
So what did I do first? Well of course, try to run everything.
Above you can see the widgetsgallery you can download on your N900, but a bit more recent and also not Maemo 5 but Debian Squeeze on an amd64 host (so I already had to patch some components :) ). Also running is the MeeGoTouch IM UI Server, with the MeegoKeyboard plugin active. Pressing keys on it does what you expect. Typing keys on the hardware keyboard results in some D-Bus messages from the client application to the IM Server -- again, similar to what you'd expect from an input method!
But hey! The MeeGo IM Framework seems to have some unexpected nifty features, at least when compared to H-I-M. This made me think about Gtk+ widgets in there. Sounds hard -- but definitely worth reading about.
But hey! The MeeGo IM Framework seems to have some unexpected nifty features, at least when compared to H-I-M. This made me think about Gtk+ widgets in there. Sounds hard -- but definitely worth reading about.Of course note that this is using the development theme, and also I was not using the MeegoTouch compositor at the moment, so no translucency goodness: the final UI should look much prettier.
Well, the official GSoC start date is tomorrow. I plan to use this blog to put in news, development progress (hopefully biweekly) or interesting tidbits I discover from the entire MeeGoTouch stack. See you until then!
November 18, 2009
Want to know what all this fuss about Maemo is about?
http://wiki.maemo.org/Maemo-Barcelona_Long_Weekend
December 4-6 at Citilab Cornellà!
http://wiki.maemo.org/Maemo-Barcelona_Long_Weekend
December 4-6 at Citilab Cornellà!
September 29, 2009
Truly, a new gaming platform is born!
The above was DrNokSnes running on a N900 :) Thanks to Konttori (author of the video also, thanks!), you can use a Wiimote to control it, even in N8x0! And of course, don’t forget to check the last seconds of the video for TV out and Wiimote control.
Very cool!
You’ll have to wait a bit until this version of DrNokSnes enters extras while I polish some of the rough edges ;)
August 26, 2009
I proudly present yet another Maemo port, DrNokSnes, which comes from DrPocketSnes.
It is capable of emulating Mode7 games like Mario Kart at 20fps with sound in your average N810, which is nowhere near full speed, but much better than original snes9x’s 2-3 fps (without sound!) and still very playable.
You can get it from extras-devel, and check development over at garage.
The biggest problem I found while porting opensnes9x ASM core sources is that it seems that the ABI the N8x0 devices follow mandates that the upper 16 bits of a register holding a unsigned short parameter value be set to zero. The ASM code doesn’t take care of zeroing those and as such random data was being introduced in the C functions, making those crash at weird points, or even worse, adding random behavior to the emulated games (man, seeing all the Mario kart characters keeping hitting themselves the whole race instead of racing was fun).
Also, I was bitten by a gcc bug; thankfully just switching the order of two statements (in the dsp1emu.c file) made the bug go away.
The port
uses SDL for its video, audio, input, and timekeeping functions. SDL
uses XShm in Maemo and I believe is the third fastest way to put images
to the N8x0 video hardware (first one being omapfb, second one being
Xv). Audio uses the SDL ESD backend by default; I found it works much
better setting buffer sizes <= 512 samples — same as what the SDL
ALSA backend “wants”.
I implemented snesadvance.dat speedhacks support into the emulator, since they’re becoming very common these days. Incredibly enough, I couldn’t find a single opcode 42 implementation for the opensnes9x asm arm core, so I had to write my own. It’s still incomplete and doesn’t handle most branch types, but it seems to work fine with my test rom set.
The GUI uses osso-games-startup. I don’t know why I decided to use it (probably because I like integration with the rest of the system), it’s a bit undocumented and has some “wtf” features, but I like the result.Many thanks to the original authors of DrPocketSnes and all of #maemo, who helped me a lot with the port, and enjoy!
August 5, 2009
Because it's actually starting to make sense, I've finally decided to redo my personal website, now with even more computing focus and more English content.
Of course, not wanting to rewrite a single word, most of the content is now gone; the good news is that I'm restoring my blog since, being now empty, I'm no longer ashamed of it ;).
Basically, I no longer own a Palm handheld (having fried it); I purchased a Nokia N810 Internet Tablet and I am enjoying it a lot. Thus expect some few Maemo related posts in here. All of my Palm stuff has been deprecated and moved into a folder in my depot, where it'll remain as long as I remind myself to update it ;)
This time I've settled for Movable Type instead of using Wordpress + my own ugly CMS as the previous iteration of this site did. I like static publishing, but being an OpenID consumer too was sweet. Hope we get along :) .
Of course, not wanting to rewrite a single word, most of the content is now gone; the good news is that I'm restoring my blog since, being now empty, I'm no longer ashamed of it ;).
Basically, I no longer own a Palm handheld (having fried it); I purchased a Nokia N810 Internet Tablet and I am enjoying it a lot. Thus expect some few Maemo related posts in here. All of my Palm stuff has been deprecated and moved into a folder in my depot, where it'll remain as long as I remind myself to update it ;)
This time I've settled for Movable Type instead of using Wordpress + my own ugly CMS as the previous iteration of this site did. I like static publishing, but being an OpenID consumer too was sweet. Hope we get along :) .