Re: OCR for Fremantle
Hi, On Wed, 2010-07-14 at 11:47 +0200, ac...@dsic.upv.es wrote: > Hi everyone, > > I am working at the university in order to create an OCR for > recognizing hand writing characters. > > We would be very interested in trying to improve the OCR that now is > used on harmattan. > > Please, could someone tell me if I can obtain the sources of it for > recompiling? > If yes, from where can I download them? I don't know about Harmattan's OCR but you can use Tesseract like Dave said or even Ocrad which is easy to compile under Maemo like I did for this experiment: http://www.joaquimrocha.com/2009/08/21/ocrfeeder-running-in-fremantle/ http://www.joaquimrocha.com/2009/10/07/ocrfeeder-repository-relocation-and-maemo-preview/ If you're aiming for handwritten char-by-char recognition instead of cursive text, then Ocrad might be enough imho. Cheers, -- Joaquim Rocha signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: hardware keyboard "open" event
Hi Neal, The physical keyboard opening/closing changes the GConf key "/system/osso/af/slide-open". All you need to do is to listen to this key and call your code. -- Joaquim Rocha Neal H. Walfield wrote: > Hi, > > In an application I'm working on, I'd like to show the search tool bar > if the user "opens" the hardware keyboard. Is there a way to detect > this? I've tried searching but have had no success; perhaps I'm using > the wrong keywords. > > Thanks, > > Neal > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Virtual Keyboard Sources
Hey Sergey, Can you list /usr/lib/hildon-input-method ? -- Joaquim Rocha Sergey Vlasov wrote: > On Mon, Dec 14, 2009 at 11:18 AM, Joaquim Rocha wrote: > >> Hi Sergey, >> >> Have you restarted SB after applying the plugin's name to >> /apps/osso/inputmethod/default-plugins/finger ? >> >> -- >> Joaquim Rocha >> > > Hi Joaquim, > > Indeed, after restart no keyboard showed up at all so I had to revert it > back to "hildon_western_fkb". I may still do something wrong... > > -- > Sergey > signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Virtual Keyboard Sources
Hi Sergey, Have you restarted SB after applying the plugin's name to /apps/osso/inputmethod/default-plugins/finger ? -- Joaquim Rocha Sergey Vlasov wrote: > On Wed, Dec 9, 2009 at 12:37 PM, Andre Klapper wrote: > >> At least with regard to tarballs, hildon-input-method and >> hildon-input-method-framework are available here: >> http://repository.maemo.org/pool/maemo5.0/free/h/ >> <https://lists.maemo.org/mailman/listinfo/maemo-developers> >> > > On Wed, Dec 9, 2009 at 12:46 PM, Faheem Pervez wrote: > >> The code for the virtual keyboards shipped with the N900 are >> closed-source, but you may find >> https://bugs.maemo.org/show_bug.cgi?id=4178 interesting. >> > > > Thanks for the links. I've started to play with > http://live.gnome.org/Hildon/HildonInputMethod, built it, installed and > GConf`ed, but it doesn't show up, I mean it does but looks just like > original keyboard and not anything like from the attachment there > https://bugs.maemo.org/show_bug.cgi?id=4178#c17. Basically I open the web > browser and click to the input filed to bring up the keyboard (Scratchbox + > Xephyr). > > > run-standalone.sh gconftool-2 -R /apps/osso/inputmethod > display_after_entering = 1 > have-internal-keyboard = true > available_languages = > [sv_SE,pl_PL,en_GB,it_IT,ru_RU,es_ES,en_US,no_NO,de_DE,es_MX,da_DK,fi_FI,nl_NL,pt_PT,fr_CA,el_GR,cs_CZ,fr_FR] > int_kb_layout = us > ext_kb_repeat_interval = 50 > start_recognize_after = 2 > dual-dictionary = false > handwriting_timeout = 400 > space_after = false > int_kb_model = nokiarx44 > int_kb_repeat_interval = 50 > ext_kb_layout = us > int_kb_level_shifted = true > ext_kb_model = nokiasu8w > ext_kb_repeat_delay = 600 > completion_area_pos = false > hwr_punct_mode = false > auto_correction = true > slide-layout = English, Dutch > use_finger_kb = true > input_method_plugin = hildon_keyboard_assistant > int_kb_repeat_delay = 600 > case_correction = true > /apps/osso/inputmethod/default-plugins: > finger = hildon_im_example_fkb > hw-keyboard = hildon_keyboard_assistant > stylus = hildon_im_example_fkb > /apps/osso/inputmethod/hildon-im-languages: > current = 1 > language-0 = fi_FI > language-1 = ru_RU > list = [] > ... > > I also tried with "hildon_im_onehand_fkb" value and altered > input_method_plugin, no luck. Any adeas? > > -- > Sergey > > > > > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: g_message not working on N900??
Can you see those on the syslog?: tail -f /var/log/syslog -- Joaquim Rocha ds wrote: > Hi, > > a short question: Some nice guy is testing my application on N900. We > are searching a bug. > > But: If he starts it on N900, he does not get any messages from > g_message on the console, where I have on my N800 a lot of messages. > (Same source, but compiled with fremantle autobuilder or diablo sdk) > > Can anybody help? > > Detlef > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 Keymaps - The Saga of Pipe & Tab
Hi, Matan Ziv-Av wrote: > On Thu, 15 Oct 2009, Roald de Vries wrote: > > > This is not exact. It might work in a terminal emulator, but it is not a > universal thing. Tab and Esc are useful in a lot of programs (such as > Esc for stop current page loading in a browser, and inserting a Tab in > a word processor), and there those CTRL characters do not replace them. > > That's alright but you must keep in mind you are not on a desktop computer and porting an application to Fremantle also passes through providing alternatives to non-existing keys. I really don't think this is an issue and I don't mind to press on two buttons to get a keys dialog instead of using obscure key bindings that aren't even print on the hardware keyboard. Cheers, -- Joaquim Rocha signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 Keymaps - The Saga of Pipe & Tab
Hi Ryan, What hardware keyboard layout are you using at the moment? You can check this by going to the Settings->Text Input. You should be able to input extra characters by pressing Fn and then the Sym/Ctrl key. A dialog with extra characters pops up and all you need to do is tap on the desired one. Could this end your saga? :) -- Joaquim Rocha Igalia · Free Software Engineering Ryan Abel wrote: > Many people are likely to complain that the N900's 3-row keyboard does > not contain enough keys to be usable. Notably missing are important > characters like tab and pipe. > > Now, there _should_ be a relatively straightforward way to fix this > with Xmodmap. But as xev wasn't properly setup to receive keypresses > when I first began this saga, I started out by trying to edit the > symbol files directly. Unfortunately this proved to have no noticeable > effect. > > So qwerty12 compiled a patched xev, I grabbed keycodes and I spent a > couple hours trying to convince the device that it'd be a really great > idea for shift-fn-b to send a pipe, for fn-right arrow to send tab, > and a dozen other shifted and unshifted combinations. > > End result? Either no effect or outright dead keys. > > The grapevine tells me that khertan may have had some luck getting > things to behave, has anybody else been able to, too? If so, can you > enlighten us with your secrets? We have nearly 30 additional > characters available with shift-fn and another 6 that have no fn > character. It would be great to bind these to some useful purpose. > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers signature.asc Description: OpenPGP digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Asking for developers and user support for a N900 application
Hi, Andrea Grandi wrote: > from HTMLParser import HTMLParser <--- package name in upper case... > urllib2.Request(url, data) < method name in upper case... > > first they suggest name convention and then they're the first one not > following them? This really sucks :) > Request is an object (a class), it is not a method :) -- Joaquim Rocha Igalia · Free Software Engineering ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: open source licensing of maemo 5 example code MIT vs GPL
Like Murray said, you can use MIT code with your GPL code. When dealing with licensing issues, if your application is GPL licensed you should look for the GPL-compatible licenses list: http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses Cheers, -- Joaquim Rocha Murray Cumming wrote: > On Sat, 2009-08-29 at 11:19 +, gary liquid wrote: >> When I went looking, I find many are licensed under a permissive MIT >> license. >> this is great and open source friendly, but my application is written >> under >> the GPL. >> >> I am not a licensing expert, so hopefully one of you guys will be able >> to >> help. >> >> is it possible to use and embed pieces of these examples into liqbase >> or >> would they need recreating from scratch? > > Yes, this license is chosen to pretty much let you do whatever you like > with the example code. > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkRadioActionEntry
Hi Aniello, Aniello Del Sorbo wrote: > Hi Joaquim, > > indeed the on_change callback function was the path to follow. > A switch in it solves everthing. > > The Toggle doesn't apply in my case, as I need the Radio concept (if > you select a Pen, you've got to deselect Eraser). You can set the radio's group easily, for example with: hildon_gtk_radio_button_new_from_widget I wasn't suggesting for you to use toggle buttons but only the toggle actions which you could connect to the radios (I never tried it but in *theory* I think this could work). -- Joaquim Rocha ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkRadioActionEntry
Hi Aniello,
That callback in gtk_action_group_add_radio_actions connects to the
"changed" signal of the radio actions.
And from the docs:
The ::changed signal is emitted on every member of a radio group when
the active member is changed. The signal gets emitted after the
::activate signals for the previous and current active members.
So, this way you can check which of the actions was changed (1st
argument of the cb) and the one that got activated (2nd argument of the cb).
On the other hand, the approach you mentioned (having a callback when
the user presses the pen button) may be accomplished using
GtkToggleAction objects with which you can assign a callback for every
action.
Since a radio button is a toggle button, it might work.
Cheers,
--
Joaquim Rocha
Aniello Del Sorbo wrote:
> Actually I think I should use the on_change callback function in
> gtk_action_group_add_radio_actions.
>
> Trying it..
>
> Will report.
> Aniello
>
> 2009/9/15 Aniello Del Sorbo :
>> Hi,
>>
>> I have an issue with my interface.
>>
>> I've created my interface using GtkUIManager from an xml file.
>> In this file I've created a toolbar:
>>
>>
>>
>>
>>
>>
>>
>>
>> in the code I've this gtkradioaction entries:
>>
>> static GtkRadioActionEntry hildon_tools_radio_entries[] = {
>> { "Pen", "pen", N_("_Pen"), "P", NULL, 0 },
>> { "Eraser", "eraser", N_("_Eraser"), "E", NULL, 1 },
>> { "Highlighter", "highlighter", N_("_Highlighter"),
>> "H", NULL, 2 },
>> { "Text", "text", N_("_Text"), "T", NULL, 3 }
>> };
>>
>> that I add to an action group like this:
>>
>> gtk_action_group_add_radio_actions (action_group, hildon_tools_radio_entries,
>> G_N_ELEMENTS(hildon_tools_radio_entries), 0, NULL,
>> hildon_window);
>>
>> They show up fine, I can click on them and only one at a time is
>> selected. And that's fine.
>> But now, how can I set up a callback action whenever, for example, a
>> Pen button is toggled?
>>
>> It worked for menus as the action entries for those had a callback
>> entry I used to specify the callback function.
>> But I am lost on how to connect those radio buttons to actual function
>> in order to perform what they need.
>>
>> Also I want them to reflect the choice the user makes in the menu
>> (actually, I have not dug into the menu issue yet, but I've noticed
>> there are buttons now in Fremantle).
>>
>> Anyway.. suggestions?
>>
>> Thanks!
>>
>> --
>> anidel
>>
>
>
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
Hi karoliina.t.salmi...@nokia.com wrote: > These things are easier in some toolkits and harder in some others. To my > knowledge, Gtk was not really designed for handheld touch user interface > with kinetic scroll etc. on mind in the first place - it is a rather a > desktop toolkit with the rather traditional mindset - > and some of hard core hacking obviously was required to make it function like > it functions on the Maemo 5. That is a great achievement and I have > watched that with awe and lots of respect to the developers who have made it. > I can now enjoy it every day with my N900, lists etc. > work as they should and they make this UI very desirable. Of course GTK+ wasn't thought to be used on touch UIs from the beginning! Was Qt or any of the other UI toolkits with more than a couple years designed for touch screen interfaces? > > On the other hand, it was a lot easier to start the same from scratch on > Startup wizard with Clutter because there > was not the incompatible way of thinking as a barrier between the desired > functionality and what is already there because there was > nothing there already, just start from grass root level from atomic blocks > (start by building a custom ClutterActor) > and then figure out how to stack Actors and how to animated them to get e.g. > a kinetic scroll list done. As there was no base widget, there > was no limitations of the base widget and no associated problems, just > putting some lego blocks together and it was done. With some > adjustable parameters and then fine tuning the feel with these parameters, it > was actually quite efficient to do it. Sure but the question here is not to make super customized widgets but rather to use widgets the way they should be used in an interface, following the established guidelines to provide the user with a nice experience. If you have custom widgets in every program on a system, users will find it harder to use. They will not know what to expect when they tap on a widget they never saw before... that's the point of having guidelines. > > I believe Qt can be in the same position pretty much, > if the widget is started from scratch rather basing it on some existing > widget which has similar limitations than the equivalent > in the Gtk. Qt is more like Gtk + Clutter combined rather than being > equivalent of the Gtk alone. > > Kate said there is some kinetic scroll list already there in the Qt, but I > don't know how its parameters match to the > Hildon/Gtk version we have on the Maemo 5, but I think that with some work it > can be done to function 100% equally, as it works > equally on startup wizard despite it is a completely separate implementation > with a completely different kind of technology behind it. > And despite of that, it still just works, perfectly. > > IMHO good news about composite widgets is that they are very easy to create > in Qt. Many things which are very cryptic in Gtk and glib (no flame intended, > I know > that hard core glib people will disagree, but I don't happen to be very > enlightened to the gobject despite having made few custom ClutterActors > myself in C/glib) are so simple on Qt, > just few lines of very understandable and easy C++ code. I am sure Kate can > show examples. Another good news is that the QGraphicsView appears to have > almost everything that is in Clutter, and modern > mobile user interface widgets can be built with it rather than basing them on > the traditional widgets. And what is more, > Qt allows extensive embedding of the traditional widgets to the graphics view > which may make the task even easier. > I'm pretty sure you can do neat stuff with Qt as you can do them with GTK+ and Clutter but I don't think this really counts when writing or porting applications to Fremantle. There are a set of widgets that behave in a certain way in Fremantle and developers should use those to build they're applications. I can't see where *having the possibility to build* those widgets is a great thing comparing to *having the widgets themselves* ready to use. E.g.: It is pretty easy to build up a dialog in GTK+ without using the GTKDialog class. Make a window, add a box, add buttons, ... but it would be a pain if I had to write all the "standard" widgets I wanna use. Another important thing is that, for Open Source applications, you'd end up having tons of the same composite widgets, written differently, and obviously behaving differently, which would not contribute to code reuse and cripple users' experience. So, please guys, understand that until Qt have the set of widgets that define Fremantle and that developers can use those in a straightforward way, one cannot think of Qt as an intelligent choice to build ap
