Recently in Maemo Category

August 8, 2010

So the deadline is approaching, and slowly all features start appearing:

copy.png
paste.png
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,
        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.

phonepreedit.pngWith 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 :)

customtool.pngCustom 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:

initialcommit.png
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.

imframework.png
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!
customtoolbar.pngBut 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à!

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

DrNokSnes GUI

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!