Hildon input method: how to write a fullscreen keyboard plugin?
Hi,AllI am trying to write a fullscreen keyboard plugin for Hildon input method.I tried two ways:1, Call gtk_window_fullscreen in activate_plugin:It didn't work. 2, Resize the keyboard window to 800X480 in hildon_im_ui_resize_window.The related application will exit abnormally.And matchbox wm tells: matchbox-wm: X error warning (0): BadValue (integer parameter out of range for operation) (opcode: 12) Is there any constraint on _NET_WM_WINDOW_TYPE_INPUT window in matchbox wm?Or should I do something special in fullscreen keyboard plugin? Any hints will be welcome! Thanks a lot! _ 上Windows Live 中国首页，下载最新版Messenger！ http://www.windowslive.cn___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: policy updates (was: Problems with the fremantle autobuilder...)
Hi, ext Jeremiah Foster wrote: If they are illegal this needs to be clearly communicated in the Packaging Policy document so that packagers know what to name their packages. Currently the version naming is rather unclear and version strings like the one mentioned above is confusing at best. Can we encourage Nokia to work with Maemo to clarify and complete the Maemo Packaging Policy. If there are updates you would want to get to the Maemo policy, please put them to the updates wiki page: http://wiki.maemo.org/Task:Packaging_policy_proposed_changes Before or after discussion on this list. There was earlier (when policy was originally released) also some discussion about minor updates people would want to the policy. If somebody could go through the mailing list (all mails on policy have policy in their subject) and add the suggestions to the proposed changes page, this could speed up getting the policy updated for Fremantle(/Mer/...). Btw. We hope to get the next policy update out as a Debian package which source package will contain the LyX sources for the policy PDF file. - Eero Ps. I added the policy keyword to the subject line of this mail too. :-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: policy updates (was: Problems with the fremantle autobuilder...)
On May 27, 2009, at 9:51, Eero Tamminen wrote: Hi, ext Jeremiah Foster wrote: If they are illegal this needs to be clearly communicated in the Packaging Policy document so that packagers know what to name their packages. Currently the version naming is rather unclear and version strings like the one mentioned above is confusing at best. Can we encourage Nokia to work with Maemo to clarify and complete the Maemo Packaging Policy. If there are updates you would want to get to the Maemo policy, please put them to the updates wiki page: http://wiki.maemo.org/Task:Packaging_policy_proposed_changes Before or after discussion on this list. Thank you for pointing out that resource Eero! There was earlier (when policy was originally released) also some discussion about minor updates people would want to the policy. If somebody could go through the mailing list (all mails on policy have policy in their subject) and add the suggestions to the proposed changes page, this could speed up getting the policy updated for Fremantle(/Mer/...). Another good suggestion. :) Btw. We hope to get the next policy update out as a Debian package which source package will contain the LyX sources for the policy PDF file. Brilliant - I think this would be useful, people tend to shy away from pdfs. - Eero Ps. I added the policy keyword to the subject line of this mail too. :-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problems with the fremantle autobuilder...
Jeremiah Foster wrote: On May 26, 2009, at 14:27, Tim Teulings wrote: If you upload a version that already exists, the autobuilder will reject it. This makes sense. Sadly this statement is ambiguous. that already exists exists on what? in what state? Is available in extras-devel for that distribution. I and others think that if a package P with a given version X is uploaded and fails to build then a subsequent attempt to upload package P version X should not be rejected. That is how it works at the moment. Once package P version X has been successfully built then a subsequent attempt to upload package P version X should be rejected. That is how it works at the moment. Nothing to worry about then :) David -- Don't worry, you'll be fine; I saw it work in a cartoon once... -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon input method: how to write a fullscreen keyboard plugin?
Hi,
the problem is that the plugin is supposed to be a widget because in
previous versions it would be embedded inside the Input Method window
that was placed in the lower part of the screen, but this obviously
won't work well for widgets that are a window themselves. I guess that
you should set the plugin type to HILDON_IM_TYPE_FULLSCREEN and keep an
internal field with the actual window, like this:
void
plugin_enable(HildonIMPlugin *plugin, gboolean init)
{
...
gtk_widget_show_all(GTK_WIDGET(priv-window));
...
}
As for having a fullscreen window, I'm not sure about the restrictions
placed by the window manager, but if regular windows don't work well you
could experiment with a dialog window. You could also remove decoration
on that window for a nicer effect.
Regards,
Felipe
xuxing wrote:
Hi,All
I am trying to write a fullscreen keyboard plugin for Hildon input method.
I tried two ways:
1, Call gtk_window_fullscreen in activate_plugin:
It didn't work.
2, Resize the keyboard window to 800X480 in hildon_im_ui_resize_window.
The related application will exit abnormally.And matchbox wm tells:
matchbox-wm: X error warning (0): BadValue (integer parameter out of
range for operation) (opcode: 12)
Is there any constraint on _NET_WM_WINDOW_TYPE_INPUT window in matchbox wm?
Or should I do something special in fullscreen keyboard plugin?
Any hints will be welcome!
Thanks a lot!
立即试试微软地图新功能，msn互动浏览！ 立刻体验！
http://ditu.live.com/?form=CR
___
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
What would you like to learn about Qt?
Hello, Qt labs is asking on their blog, What would you like to learn about Qt. Since Qt is a part of maemo I thought it might be interesting for those who read this list. http://labs.trolltech.com/blogs/2009/05/26/what-would-you-would-like-to-learn-about-qt/ Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
conboy-midgard
Hi, does anyone know something about the package conboy-midgard? I just saw it in extras-devel. I'm only curious, because I'm the author of Conboy, so I'm naturally interested who is using it and for what. I'm really happy that someone is doing something with the code - so step forward stranger I won't bite - promised :D Cheers! Conny P.S. Version 0.4.4 was just released! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problems with the fremantle autobuilder...
On Tue, 2009-05-26 at 14:04 +0200, Jeremiah Foster wrote: Why would you want to upload a package with the same version number? Incrementing the version number is the purpose of the version number, so of course you would want to change the version number every time there is a new package. Because if it takes 20 attempts to autobuild correctly we don't want to burn through twenty numbers like foo-maemo1 through foo-maemo20. Once we've successfully autobuilt, our *next* change will have an incremented number e.g. maemo2. and if that takes 20 times to get autobuilt correctly it should still be just maemo2, not maemo21 nor maemo42. But based on other emails it sounds like the system is working the way I've described, *successfully* autobuilt packages prevent the re-use of that particular version number. Packages that are not built successfully do not prevent the reuse. And by successfully autobuilt I'm assuming we mean successfully built by the extras-devel autobuilder. Joseph Charpak jchar...@worldnet.att.net ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle user interface behaviour and API
On 5/14/09, Cornelius Hald h...@icandy.de wrote: Panable Area How exactly should I use it? I replaced my ScrollableWindow with a PanableArea, the rest of the code I left as it is in Diablo. Inside the PanableArea is a GtkTextBox. Nothing else. Now, it renders correctly, that is it has only this small scroll indicator and not a real scroll bar. But I cannot pan. If I try to pan it always selects the text inside the text box. How is this supposed to work? How is the destinction made between selecting text and scrolling/panning the text? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers I have also run into this problem trying to update Quick Clip (the text viewer part). If anyone here uses Quick Clip in Diablo, you will see I have implemented Kinetic scrolling (via mokoui.FingerScroll) by having a toggle-button to toggle whether the TextView is selectable or not. The toggle-button callback is very simple (this is in Python): def select_mode_button_callback(self, widget, button=False, check=False): if button == True: active = self.select_mode_button.get_active() self.m_select_mode.set_active(active) if check == True: active = self.m_select_mode.get_active() self.select_mode_button.set_active(active) if active == True: self.textview.set_sensitive(True) self.textview.set_editable(False) else: self.textview.set_sensitive(False) Basically it just toggles the Textview sensitive/insensitive. But if you try to do this in Fremantle, it grays out the Textview (when insensitive) making the text unreadable. Maybe a viable solution would be to not gray out the Textview? Anyway, there needs to be a solution, because right now it's unworkable. -- Best Regards, Brent Chiodo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
