Re: Fwd: conboy-midgard
Thanks for the links, I think I got the main point of Midgard now. I'm planning on doing some test with the Tomboy REST API today. Let's see how this goes. Meanwhile I'll think a bit about a plug-in system. So long! Conny On Thu, 2009-05-28 at 11:54 +0300, Henri Bergius wrote: Hi, On Thu, May 28, 2009 at 11:22 AM, Cornelius Hald h...@icandy.de wrote: I惴 including your mail completely so that your answer is on the list too. What you and Piotr are doing sounds quite interesting, even if I honestly know nothing about Midgard. Concerning replication, sharing and syncing notes, I惴 working on implementing the new Tomboy online service [1]. This is probably not as generic as the Midgard solution, but for most users that should be a good solution. I've discussed Tomboy's synchronization API with Everaldo from Mono team, and the web viewer has already a little bit of code towards it: http://trac.midgard-project.org/browser/trunk/midcom/org_gnome_tomboy/controllers/api.php However, running conboy directly using Midgard as the content repository enables other methods of synchronization in addition to a web service. For example, we could use Maemo's Telepathy system for synchronizing notes with your buddies over the instant messaging connection. For a bit higher-level explanation why I think this is the right way to go, please check out http://bergie.iki.fi/blog/midgard2_at_fscons-your_data-everywhere/ If you愉e planning to go further with the Midgard integration, then maybe we can work together on some kind of plug-in system. If this would be interesting/feasible for you, just contact me. Yep, sounds good. Obviously when the Midgard storage option of conboy actually works, the closer we can put it to the official conboy the better :-) Conny /Henri ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fwd: conboy-midgard
On Thu, 2009-05-28 at 12:20 +0200, Piotr Pokora wrote: C API reference: http://www.midgard-project.org/api-docs/midgard/core/vinland/index.html And simple Hello World example: http://www.midgard-project.org/api-docs/midgard/core/vinland/example-hello-world.html Thanks, the hello world was very useful. Sounds good, and to be honest it's the first idea I thought about when started to hack code for Midgard. Storage abstraction level can be easily implemented via GObject/Gtype system. Also some user configuration seems to be a must. At least from my point of view. Somehow I've always wanted a plug-in system to be more aligned with Tomboy. My idea was, that for example a user uses Tomboy with a plug-in that adds new tags to the xml file format, so he would also need a plug-in for Conboy which adds support for the same tags. Also there are some UI extension in which users are interested, but which I don't want to add to the core. E.g. being able to change a notes background color etc... So there are already quite some use cases for plug-ins. Pluggable storage backends would be another one :) The only problem is that (as you probably have seen) the Conboy code is still quite unstructured, unpolished, young, etc. also I'm only coding on it in my free time, which is not really that much. This means that the plan for doing a plug-in interface is really only a plan at the moment. I have other things on the list which I would like to do first. So for me it would be interesting whether this Midgard backend is something that you want to develop further or if this is more some kind of test balloon. If you seriously consider to continue this project further, then I think I should reconsider my priorities and maybe together we could build a plug-in system that suits your and my needs. Let me know, if you would like to read a patch. I made it against 0.4.3 release. Rev 125 IIRC. That would be nice :) I don't think I'll have time to look into it in detail, but I would be interested in at least seeing how you approach the problem. Cheers! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo SDK (Diablo) and Python Statusbar Plugins
On Thu, May 28, 2009 at 7:55 PM, Brent Chiodo bchi...@gmail.com wrote: I'm trying to get a Python Statusbar plugin working in Scratchbox (DIABLO_X86) but get this error: hildon-desktop[8588]: GLIB WARNING ** default - Could not reload Python module 'quickclip' Falling back to previous version hildon-desktop[8588]: GLIB WARNING ** default - Cannot find function hd_plugin_get_objects And the plugin does not load. Can you provide some source code? As the error says, it could not find the necessary hd_plugin_get_objects function in your plugin, that should return a list of plugin objects. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
Kimmo Hämäläinen wrote: Yes, we have _HILDON_PORTRAIT_MODE_REQUEST and _HILDON_PORTRAIT_MODE_SUPPORT window properties (I think libhildon has convenience functions for setting them). The request property makes hildon-desktop to rotate the screen using XRandR, _IF_ all other visible windows are ok with that. If you don't have the support property or request property, it means that your window only supports the landscape mode. And if there is no convenience function in HildonWindow, then there is naturally the source code of hildon-desktop. :) It contains a test application called tests/test-portrait-win.c. Worth looking... http://repository.maemo.org/pool/maemo5.0alpha/free/h/hildon-desktop/hildon-desktop_2.2.20-1.tar.gz BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, 2009-05-29 at 13:48 +0300, Kimmo Hämäläinen wrote:
On Thu, 2009-05-28 at 17:19 +0200, ext Cornelius Hald wrote:
* What happens to toolbars when in portrait mode? Is there some
automatic behavior like showing the toolbar as two rows instead of a
single row? Is it scaled? Is the space between the buttons reduced?
Or do we have to care about this by ourself, for example listen to some
signal and then hiding some buttons or rearranging them?
AFAIK, there is automatic relayout only for confirmation dialogs (and
maybe application menu as you said), but not much more. So toolbars you
have to handle yourself. The toolkit people can give better answers
(I'm handling the hildon-desktop side).
Toolkit people here :)
Offhand, application menus and confirmation notes will relayout; banners
and picker dialogs will resize to new screen dimensions. That's pretty
much it (unless I'm forgetting something).
* What happens to any other widget when in portrait mode?
It looks crap. That's why the rotation is not unconditional, see below.
* Is there a signal which signals that the screen orientation changed?
Yes, XRandr signals, which are handled by GTK, methinks.
You can connect to GdkScreen::size-changed or GdkScreen::monitors-
changed to get notified and do your magic.
* Is there a function to change the screen orientation and can we
somehow use this with the beta SDK?
Yes, we have _HILDON_PORTRAIT_MODE_REQUEST and
_HILDON_PORTRAIT_MODE_SUPPORT window properties (I think libhildon has
convenience functions for setting them).
typedef enum {
HILDON_PORTRAIT_MODE_REQUEST = 1 0,
HILDON_PORTRAIT_MODE_SUPPORT = 1 1
} HildonPortraitFlags;
hildon_gtk_window_set_portrait_flags (GtkWindow *window,
HildonPortraitFlags portrait_flags);
The HIG[1][2] is very vague on that matter so it would really be nice if
someone from the hildon team or the UI specs team could comment on that.
I think it would be a shame if the new device is finally available and
every time someone holds the device in portrait mode, everything* looks
like crap.
If you don't want to support portrait mode, just don't set any portrait
flags and the UI will look as crappy as you originally planned :)
Claudio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, May 29, 2009 at 01:48:54PM +0300, Kimmo Hämäläinen wrote: AFAIK, there is automatic relayout only for confirmation dialogs (and maybe application menu as you said), but not much more. So toolbars you have to handle yourself. The toolkit people can give better answers (I'm handling the hildon-desktop side). HildonAppMenu has automatic relayout. The number of columns changes from 2 to 1, and filters remain the same. If really necessary, you can also have a different menu for portrait mode, hide some of its items or change some of their labels. Standard (Gtk) toolbars don't change, because I don't think there's a reliable and generic way to change their layout. If a particular toolbar doesn't look good in portrait mode because it has too many items, it's IMHO the app -not the toolkit- that should take care of this. The same applies to many other widgets and the whole program UI in general (if it's going to support portrait mode it should be designed with that in mind). Edit-mode toolbars (HildonEditToolbar) look fine in portrait mode. Again, if the label is too long for portrait the app can change it. To detect screen orientation changes you can e.g. use the size-changed signal of GdkScreen. * Is there a function to change the screen orientation and can we somehow use this with the beta SDK? hildon_gtk_window_set_portrait_flags (window, HILDON_PORTRAIT_MODE_REQUEST | HILDON_PORTRAIT_MODE_SUPPORT); Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Thu, 2009-05-28 at 19:03 +0300, Eero Tamminen wrote:
* Is there a signal which signals that the screen orientation changed?
Application needs to specifically request portrait mode with a window
property (I guess there's some API for that), otherwise window manager
uses landscape mode for the application window.
In the beta SDK there seems to be no API, but when looking into the git
version of hildon I can find some stuff. The last time I was checking I
somehow missed that. But a grep for portrait revealed some places. The
function seems to be hildon_gtk_window_set_portrait_flags() in
hildon-gtk.c.
App can listen to standard XRandr messages for this transition if
it wants to, but it's not necessary.
Ok. Originally I was thinking that XRandr will not be used. I thought
that this would happen on toolkit level - but don't ask me why ;)
* Is there a function to change the screen orientation and can we
somehow use this with the beta SDK?
It's just a question whether your distro's Xephyr version has XRandR
enabled. It should.
Then just use xrandr -o left/right/normal for Xephyr's display.
I did that, and yes, it rotates the screen :) Here again I was aware of
XRandr but thought that it will be implemented on top of something like
clutter to have nice transition effects and stuff... So I was not
thinking about the obvious.
After rotating everything looks ok, but when clicking around I realized
that only the visual content is rotated. Mouse clicks are still handled
like the screen is not rotated at all. For example to close a window I
still have to click the top right corner of my Xephyr window instead of
the top left corner where the close button is drawn.
I figured that I have to set those window properties somehow, so I
checked the newer hildon code and came up with the following code:
static void
set_flag(GtkWindow *window, const gchar *atomname, Atom xatom, gboolean
flag) {
GdkWindow *gdkwin = GTK_WIDGET(window)-window;
GdkAtom atom = gdk_atom_intern(atomname, FALSE);
if (flag) {
guint32 set = 1;
gdk_property_change(gdkwin, atom, gdk_x11_xatom_to_atom(xatom), 32,
GDK_PROP_MODE_REPLACE, (const guchar *) set, 1);
} else {
gdk_property_delete(gdkwin, atom);
}
}
static void
set_portrait_mode(GtkWindow *window, gboolean portrait)
{
set_flag(window, _HILDON_PORTRAIT_MODE_SUPPORT, XA_CARDINAL,
portrait);
set_flag(window, _HILDON_PORTRAIT_MODE_REQUEST, XA_CARDINAL,
portrait);
}
But calling that didn't make a difference. So either the code is wrong
or the window manger in the beta SDK doesn't know about those
properties.
So next, just tried to create a Xepyr window with portrait dimensions,
but without rotation by calling:
Xephyr :2 -host-cursor -screen 480x800x16 -dpi 96 -ac
The result was much better working, unfortunately the UI didn't adopt
much to the new dimensions. The only widget that I use which really
adopted it self, was the AppMenu. The AppMenu shows the buttons in one
column instead of in two. But the Filters are still in one row, leaving
them almost no space at all.
Here are some screenshots:
The main window (toolbar cannot show all items - small arrow is added)
http://zwong.de/wp-content/uploads/2009/05/conboy_note_window.png
A click on the arrow brings up a not finger friendly menu:
http://zwong.de/wp-content/uploads/2009/05/conboy_toolbar_portrait.png
A click on the delete button brings up a crippled dialog:
http://zwong.de/wp-content/uploads/2009/05/conboy_delete_dialog_portrait.png
The AppMenu looks nice, only the Filters get crippled:
http://zwong.de/wp-content/uploads/2009/05/conboy_style_menu_portrait.png
The search window looks as expected:
http://zwong.de/wp-content/uploads/2009/05/conboy_search_window_portrait.png
I think I did my homework ;) Could now please someone how made the specs
comment on whether this is the expected behavior or not?
Thanks!
Conny
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
Grrr I should have just waited for another couple of hours :D
Thanks Kimmo, Berto, Claudio and Hendrik for answering my questions.
They rendered this mail quite useless. Well, maybe at least the
screenshots help someone to get a feeling of the problems he/she will
have to face when implementing portrait mode.
So long!
Conny
On Fri, 2009-05-29 at 13:22 +0200, Cornelius Hald wrote:
On Thu, 2009-05-28 at 19:03 +0300, Eero Tamminen wrote:
* Is there a signal which signals that the screen orientation changed?
Application needs to specifically request portrait mode with a window
property (I guess there's some API for that), otherwise window manager
uses landscape mode for the application window.
In the beta SDK there seems to be no API, but when looking into the git
version of hildon I can find some stuff. The last time I was checking I
somehow missed that. But a grep for portrait revealed some places. The
function seems to be hildon_gtk_window_set_portrait_flags() in
hildon-gtk.c.
App can listen to standard XRandr messages for this transition if
it wants to, but it's not necessary.
Ok. Originally I was thinking that XRandr will not be used. I thought
that this would happen on toolkit level - but don't ask me why ;)
* Is there a function to change the screen orientation and can we
somehow use this with the beta SDK?
It's just a question whether your distro's Xephyr version has XRandR
enabled. It should.
Then just use xrandr -o left/right/normal for Xephyr's display.
I did that, and yes, it rotates the screen :) Here again I was aware of
XRandr but thought that it will be implemented on top of something like
clutter to have nice transition effects and stuff... So I was not
thinking about the obvious.
After rotating everything looks ok, but when clicking around I realized
that only the visual content is rotated. Mouse clicks are still handled
like the screen is not rotated at all. For example to close a window I
still have to click the top right corner of my Xephyr window instead of
the top left corner where the close button is drawn.
I figured that I have to set those window properties somehow, so I
checked the newer hildon code and came up with the following code:
static void
set_flag(GtkWindow *window, const gchar *atomname, Atom xatom, gboolean
flag) {
GdkWindow *gdkwin = GTK_WIDGET(window)-window;
GdkAtom atom = gdk_atom_intern(atomname, FALSE);
if (flag) {
guint32 set = 1;
gdk_property_change(gdkwin, atom, gdk_x11_xatom_to_atom(xatom), 32,
GDK_PROP_MODE_REPLACE, (const guchar *) set, 1);
} else {
gdk_property_delete(gdkwin, atom);
}
}
static void
set_portrait_mode(GtkWindow *window, gboolean portrait)
{
set_flag(window, _HILDON_PORTRAIT_MODE_SUPPORT, XA_CARDINAL,
portrait);
set_flag(window, _HILDON_PORTRAIT_MODE_REQUEST, XA_CARDINAL,
portrait);
}
But calling that didn't make a difference. So either the code is wrong
or the window manger in the beta SDK doesn't know about those
properties.
So next, just tried to create a Xepyr window with portrait dimensions,
but without rotation by calling:
Xephyr :2 -host-cursor -screen 480x800x16 -dpi 96 -ac
The result was much better working, unfortunately the UI didn't adopt
much to the new dimensions. The only widget that I use which really
adopted it self, was the AppMenu. The AppMenu shows the buttons in one
column instead of in two. But the Filters are still in one row, leaving
them almost no space at all.
Here are some screenshots:
The main window (toolbar cannot show all items - small arrow is added)
http://zwong.de/wp-content/uploads/2009/05/conboy_note_window.png
A click on the arrow brings up a not finger friendly menu:
http://zwong.de/wp-content/uploads/2009/05/conboy_toolbar_portrait.png
A click on the delete button brings up a crippled dialog:
http://zwong.de/wp-content/uploads/2009/05/conboy_delete_dialog_portrait.png
The AppMenu looks nice, only the Filters get crippled:
http://zwong.de/wp-content/uploads/2009/05/conboy_style_menu_portrait.png
The search window looks as expected:
http://zwong.de/wp-content/uploads/2009/05/conboy_search_window_portrait.png
I think I did my homework ;) Could now please someone how made the specs
comment on whether this is the expected behavior or not?
Thanks!
Conny
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, May 29, 2009 at 01:22:57PM +0200, Cornelius Hald wrote: The AppMenu looks nice, only the Filters get crippled: http://zwong.de/wp-content/uploads/2009/05/conboy_style_menu_portrait.png This is a bug (already fixed): in portrait, the menu will use the full width of the screen, so in your case I think that these buttons will look fine. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, 2009-05-29 at 13:34 +0200, Alberto Garcia wrote: On Fri, May 29, 2009 at 01:22:57PM +0200, Cornelius Hald wrote: The AppMenu looks nice, only the Filters get crippled: http://zwong.de/wp-content/uploads/2009/05/conboy_style_menu_portrait.png This is a bug (already fixed): in portrait, the menu will use the full width of the screen, so in your case I think that these buttons will look fine. That's good to hear! Thanks :) Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, 2009-05-29 at 13:22 +0200, ext Cornelius Hald wrote: ... After rotating everything looks ok, but when clicking around I realized that only the visual content is rotated. Mouse clicks are still handled like the screen is not rotated at all. For example to close a window I still have to click the top right corner of my Xephyr window instead of the top left corner where the close button is drawn. That would be Xephyr/Xorg bug. The whole point of using XrandR is to get this input event and screen geometry delivery right. BR; Kimmo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, 2009-05-29 at 14:50 +0300, Kimmo Hämäläinen wrote: That would be Xephyr/Xorg bug. The whole point of using XrandR is to get this input event and screen geometry delivery right. I using xserver-xephyr-2:1.6.0-0ubuntu14 which is the ubuntu intrepid version running on ubuntu jaunty. Maybe that's the reason?! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo SDK (Diablo) and Python Statusbar Plugins
I attached the source code since it is rather lengthy (at the very
bottom is the hd_plugin_get_objects() function).
I probably should also mention that I tested this on an actual device,
and it worked great.
On 5/29/09, Anderson Lizardo anderson.liza...@openbossa.org wrote:
On Thu, May 28, 2009 at 7:55 PM, Brent Chiodo bchi...@gmail.com wrote:
I'm trying to get a Python Statusbar plugin working in Scratchbox
(DIABLO_X86) but get this error:
hildon-desktop[8588]: GLIB WARNING ** default - Could not reload
Python module 'quickclip'
Falling back to previous version
hildon-desktop[8588]: GLIB WARNING ** default - Cannot find function
hd_plugin_get_objects
And the plugin does not load.
Can you provide some source code? As the error says, it could not find
the necessary hd_plugin_get_objects function in your plugin, that
should return a list of plugin objects.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
--
Best Regards,
Brent Chiodo
#!/usr/bin/python2.5
#Copyright 2009, Brent Chiodo.
#Quick Clip is free software: you can redistribute it and/or modify
#it under the terms of the GNU General Public License as published by
#the Free Software Foundation, either version 3 of the License, or
#(at your option) any later version.
#This program is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#GNU General Public License for more details.
#You should have received a copy of the GNU General Public License
#along with this program. If not, see http://www.gnu.org/licenses/.
import gtk
import pygtk
import hildon
import hildondesktop
#import hildonhelp
#import commands
import os
#import ConfigParser
#import subprocess
#import osso
#import xml.etree.ElementTree as ET
#import cPickle
import sys
HOME = os.getenv('HOME')
sys.path.append('/usr/lib/quickclip/')
from history import *
from manage_files import *
from settings import *
from settings_dialog import *
from target_files import *
from main_menu import *
from clip_tools import *
from dialogs import *
# Main class
#
class statusbar_applet(hildondesktop.StatusbarItem):
def __init__(self):
hildondesktop.StatusbarItem.__init__(self)
self.settings = Settings().load()
self.files = Target_Files().get_files()
self.history, self.history_target = History().load()
self.button = gtk.ToggleButton()
self.button.set_image(gtk.image_new_from_file(/usr/share/icons/hicolor/40x40/hildon/quick_clip-40x40.png))
self.button.set_name(hildon-statusbar-button-one)
self.button.set_size_request(40,40)
self.button.connect(clicked,self.popup_menu)
self.add(self.button)
self.show_all()
Target_Files().create_files()
def create_menu(self):
self.menu = gtk.Menu()
self.settings = Settings().load()
self.files = Target_Files().get_files()
self.history, self.history_target = History().load()
if int(self.settings['default_menu_positioning']) == 0:
self.default_menu_positioning_func()
self.menu.append(gtk.SeparatorMenuItem())
self.create_parent_func()
if int(self.settings['default_menu_positioning']) == 1:
self.menu.append(gtk.SeparatorMenuItem())
self.default_menu_positioning_func()
self.menu.show_all()
self.menu.set_name(menu_from_statusbar)
self.menu.connect(selection-done, self.menu_done)
self.menu.show_all()
# Main menu call
def popup_menu(self,widget,data=None):
if (self.button.get_active() == True):
self.create_menu()
self.menu.popup(None,None,self.menu_position,0,gtk.get_current_event_time())
# Cleaup?
def menu_done(self, widget, data=None):
self.button.set_active(False)
self.menu.destroy()
def menu_position(self,data=None):
(reqw, reqh) = self.menu.size_request()
(x,y) = self.button.get_parent_window().get_position()
button_allocation = self.button.get_allocation()
y = y + button_allocation.y + button_allocation.height
x = x + button_allocation.x + button_allocation.width - reqw
return (x,y,True)
# ===
def create_parent_func(self):
for item in self.files:
menu_group = gtk.MenuItem(item)
self.menu.append(menu_group)
self.submenu = gtk.Menu()
menu_selection = gtk.MenuItem(Selection File)
menu_entry = gtk.MenuItem(Entry File)
menu_view = gtk.MenuItem(View)
menu_edit = gtk.MenuItem(Edit)
menu_clear = gtk.MenuItem(Clear)
menu_delete = gtk.MenuItem(Delete)
self.submenu.append(menu_selection)
self.submenu.append(menu_entry)
self.submenu.append(gtk.SeparatorMenuItem())
self.submenu.append(menu_view)
self.submenu.append(menu_edit)
Re: Maemo SDK (Diablo) and Python Statusbar Plugins
Wow, I just tried it again today and everything is working fine; that is really strange. This happened to me before, where I've had a problem, then restarting scratchbox makes everything work fine. Sorry for the false-alarm and thanks for the help. On 5/29/09, Brent Chiodo bchi...@gmail.com wrote: I attached the source code since it is rather lengthy (at the very bottom is the hd_plugin_get_objects() function). I probably should also mention that I tested this on an actual device, and it worked great. On 5/29/09, Anderson Lizardo anderson.liza...@openbossa.org wrote: On Thu, May 28, 2009 at 7:55 PM, Brent Chiodo bchi...@gmail.com wrote: I'm trying to get a Python Statusbar plugin working in Scratchbox (DIABLO_X86) but get this error: hildon-desktop[8588]: GLIB WARNING ** default - Could not reload Python module 'quickclip' Falling back to previous version hildon-desktop[8588]: GLIB WARNING ** default - Cannot find function hd_plugin_get_objects And the plugin does not load. Can you provide some source code? As the error says, it could not find the necessary hd_plugin_get_objects function in your plugin, that should return a list of plugin objects. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil -- Best Regards, Brent Chiodo -- Best Regards, Brent Chiodo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, 2009-05-29 at 13:20 +0200, Alberto Garcia wrote: To detect screen orientation changes you can e.g. use the size-changed signal of GdkScreen. This seems like a rather long-winded way to detect landscape or portrait mode, requiring the hard coding of the dimensions. Surely some simple hildon API would make life easier? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, May 29, 2009 at 09:37:10PM +0200, Murray Cumming wrote: To detect screen orientation changes you can e.g. use the size-changed signal of GdkScreen. This seems like a rather long-winded way to detect landscape or portrait mode, requiring the hard coding of the dimensions. Why do you need the hard coding of the dimensions to know what's the page orientation? Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
