sbox2 & maemo
Hi, Scratchbox2 can now be found in debian, unstable and testing carry frequently updated releases of it. I've been going over a number of packages trying to test it. I think it's pretty good considering the limited amount of people using it, and the fact that the public maemo rootstraps are an insult to all root filesystems. Most problems arise from maemo being totally geared towards SB1, which is terribly unfortunate. It has resulted in rootstraps being stripped of many essential packages to make them even marginally useful, all because SB1 has kindly provided those and even pretended that its versions satisfy build-dependencies for them. Target images are quite a bit more useful, but require special tools to extract files out of jffs2 images, I'm not even sure if these tools are available outside Nokia? I know that internally Nokia has rootfs tarballs that are very close to what's needed by SB2, so not much needs to be done to improve the situation. I hope the right people read this. Continuing on the topic of build dependencies, SB2 has an open design issue regarding them. Since SB2 is using the host system to provide most (all) of the build tools, build dependencies of packages need to be checked against the host. But then again build dependencies contain -dev packages (libraries and headers) which need to be in the target buildroot, so the build dependencies need to be checked against the target as well. Obviously the easy solution would be to require all build deps on both host and the target, but this is not very practical. Therefore I would need some way of reliably identifying what should be checked from where. Any ideas are welcome. The raw mechanism is already in place to call dpkg-checkbuilddeps for both transparently, but now we'd need to figure out the logic. Now a little bit about target emulation, since that's always popping up when scratchbox is discussed. SB2 is *seriously* not going to do it in the default mode of operation. Instead there is so called "emulation mode", used through the -e switch to sb2. That's still using user-mode emulation with qemu, but effectively does a pseudo chroot. It's not as good as system-mode qemu, but useful for running apt, dpkg and related tools to maintain the target root. It also shouldn't be considered as a real target emulation environment to be used for application or system development. So people would normally do something like this when using sb2: sb2 -e apt-get update sb2 -e apt-get dist-upgrade cd ~/src/my_package sb2 dpkg-buildpackage -rfakeroot It might be a good idea to try to automate the use of emu mode for apt and dpkg, might save some headaches down the line. Shouldn't be too hard to detect normal invocations of them. Nokia and Maemo community really need to figure out an easy way for developers to use the real hardware and system-mode qemu. Those are the only adequate solutions for testing and debugging of software. Also note that SB2 is totally not interested in doing x86->x86 development, like what many people are doing today with SB1. People need to wake up, smell the coffee, integrate with debian proper and get with the program. It's stupid to maintain a lame x86 port of maemo which nobody wants when all the components should be pushed to debian and ubuntu and get those bigger communities involved in their development. One day we will anyway be running debian/stable with a few custom components on the tablets. That was the aim with this whole debian thing in the first place, remember? regards, Lauri ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to judge if GtkWindow is on top of hildon desktop or NOT
Zhu, Peter J ([EMAIL PROTECTED]) wrote: > I used differnt solution. Hildon library has a special function of > hildon_window_get_is_topmost() to address this very elegantly. Yeah, I read your second mail after I replied :) It probably depends on what you want. If you just want to check if your application is running in the foreground then this probably is the right thing to do. On the other hand if you really need the visibility state, then my approach probably works better, for example to test if a dialog or something else is on top of the window. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: How to judge if GtkWindow is on top of hildon desktop or NOT
Simon, Thanks for response. You get me a new way looking at this issue. I used differnt solution. Hildon library has a special function of hildon_window_get_is_topmost() to address this very elegantly. Peter Simon Budig wrote: > Zhu, Peter J ([EMAIL PROTECTED]) wrote: >> I tried to use both gdk_window_is_visible and gtk_window_is_active to >> judge if GtkWindow is on top of hildon desktop or not. But >> unfortunately both fail to get correct result. > > Well, the result probably is correct, but does not describe the > visibility in your sense :) > > To track the effective visibility state connect a callback to the > visibility-notify-event signal. This gets invoked whenever the > visibility changes and you'll get a GdkVisibilityState, indicating if > your widget is fully visible, partially obscured or fully obscured. > > Hope this helps, > Simon > -- > [EMAIL PROTECTED] http://simon.budig.de/ > ___ > 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: How to judge if GtkWindow is on top of hildon desktop or NOT
Zhu, Peter J ([EMAIL PROTECTED]) wrote: > I tried to use both gdk_window_is_visible and gtk_window_is_active to > judge if GtkWindow is on top of hildon desktop or not. But unfortunately > both fail to get correct result. Well, the result probably is correct, but does not describe the visibility in your sense :) To track the effective visibility state connect a callback to the visibility-notify-event signal. This gets invoked whenever the visibility changes and you'll get a GdkVisibilityState, indicating if your widget is fully visible, partially obscured or fully obscured. Hope this helps, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Alarm API: Recurrence
On Wed, 2007-07-25 at 09:30 +0300, Santtu Lakkala wrote: > Murray Cumming wrote: > > So I think that the (wrongly formatted) documentation is wrong when it says > > that it is the > > "Number of minutes between each recurrence" here: > > http://maemo.org/api_refs/3.0/alarm-api/structalarm__event__t.html > > The documentation is indeed wrongly formatted (the source has gtk-doc > comments, not doxygen comments). > > The howto[1] is more accurate, please use that instead. > > [1]: > http://maemo.org/development/documentation/how-tos/3-x/howto_alarm_interface_bora.html Yes, that makes much more sense. I guess I just made a bad guess at interpreting the wrongly formatted API documentation. Thanks. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Patch to fix a hildon-1 bug
Hi, Here I send a patch at end of this mail to fix a hildon-1 bug that will cause program crash as hildon window is destroied in some cases(Specially in case it returns FALSE in the delete-event processing of that window). Basically, the GtkBorder widget should be freed with gtk_border_free() rather than using g_free if it's NOT created by g_malloc. diff --git a/src/hildon-window.c b/src/hildon-window.c index 1f1fac6..6e67057 100644 --- a/src/hildon-window.c +++ b/src/hildon-window.c @@ -380,9 +380,9 @@ hildon_window_finalize (GObject * o self = HILDON_WINDOW (obj_self); -g_free (priv->borders); -g_free (priv->toolbar_borders); - +gtk_border_free(priv->borders); +gtk_border_free(priv->toolbar_borders); + if (G_OBJECT_CLASS (parent_class)->finalize) G_OBJECT_CLASS (parent_class)->finalize (obj_self); @@ -488,6 +488,8 @@ hildon_window_get_borders (HildonWindo g_free (priv->borders); g_free (priv->toolbar_borders); +priv->borders = NULL; +priv->toolbar_borders = NULL; gtk_widget_style_get (GTK_WIDGET (window), "borders",&priv->borders, "toolbar-borders", &priv->toolbar_borders, Peter ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
