curious tv out
hi am on n900 so will be brief got chance to do some testing witrh n900 and projector tonight my n900 is a month old my n900 works in tv in at home my n900 worked with projectors tested at onedotzero my n900 failed at summit my tv out just failed to show on a projector here with me (it was grainy when it did come through) another n900 here works flawlessly on projector here has tvout driver software changed or has it just worked by fluke up until now? why would it work in the previous places and on other devices at home and not new places? sidenote and very cool: run liqbase on tvout return to desktop or other apps with ctrl \ackspace tvout continues to be liqbase effectively dual display can run one peice of software on projector and another on screen controlled presentations w00t /me sleeps. just thought i would post this because i cant get on irc or anything gary ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras-testing QA checklist (proposal)
Hi, On Fri, Oct 23, 2009 at 11:29 PM, Attila Csipa wrote: > On Thursday 22 October 2009 14:31:38 Quim Gil wrote: > >> Feedback please. This checklist is common for developers (before > >> promnoting their applications to extras-testing) and betatesters (before > >> giving them farewell to reach Extras). > > > >Lack of bug reporting database > > > >http://bugs.maemo.org is the preferred option. Otherwise it needs to be > >identified in the http://maemo.org/packages/ page. > > As you might have noticed :) I ran into this one myself, so (after a short > chat with GA on irc) I'd like to clarify a few things, potentially of > interest > to other folks in -testing, too: > > Is bugs.maemo.org really the preferred option ? There is no visible > automatic, > or user level registration of projects there, nor clear guidelines how to > register a projects with b.m.o. A bit hidden, but: http://wiki.maemo.org/Bugs:Adding_Extra_products > According to GA, the process includes manual > intervention and there is also no grouping (by Maemo categories), so it has > great potential to get messy when projects start to migrate en masse to - > testing. Opening a product for 'mirror', a one-liner script, for example, > seems like a huge overkill. > > If we forego b.m.o, how do we identify this on the alternatively suggested > packages page ? In your package debian/control file add: Xsbc-Bugtracker: bugtracker_web_address HTH Best regards, -- Valério Valério http://www.valeriovalerio.org Again, I found no apparent way of entering such information on > the page, nor wiki guideline (surely we don't want that sort of things > stuffed > into package descriptions?). > > ___ > 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: Maemo-Optify & Builder Bots = Broken?
On Thu, Oct 22, 2009 at 09:37:11AM +0300, Ed Bartosh wrote: > 2009/10/22 Kamen Bundev : > > Hmm, yes, that seems to be the problem. In the final SDK /opt is a symlink > > but in the latest beta SDK it is not. I didn't upgrade my development > > machine, but I have the final on another so I can compare. I'll report back > > if successful. > > > You're right. > Autobuilder uses latest SDK and /opt is in the rootstrap: > tar -ztf /scratchbox/packages/maemo-sdk-rootstrap_5.0_armel.tgz | grep > '^\./opt' > ./opt > > I removed it from there and now packages with /opt directory should be > installable. > Try to re-upload your packages to autobuilder. It should work now. > > Thank you for your help. > > PS: Is someone willing to file a bug for SDK :) ? I don't think you will get anywhere. Isn't this a known issue? The manual installation instructions for the SDK (http://wiki.maemo.org/Documentation/Maemo5_Final_Installation#Manual_Installation) include: In order to facilitate installing applications under /opt on the device, a symlink /opt has been created pointing to /home/opt. The SDK inherits this feature. Under Scratchbox, /opt points to /target/links/opt which in turn points to /targets//opt. Installing the rootstraps makes this point to /home/opt, which is not what we want, since we need /opt to be target specific. In order to resolve this situation, [sbox-FREMANTLE_X86: ~] >rm /targets/FREMANTLE_X86/opt [sbox-FREMANTLE_X86: ~] >mkdir /targets/FREMANTLE_X86/opt I think sbdmock needs to do the same thing after installing the rootstrap. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras-testing QA checklist (proposal)
On Thursday 22 October 2009 14:31:38 Quim Gil wrote: >> Feedback please. This checklist is common for developers (before >> promnoting their applications to extras-testing) and betatesters (before >> giving them farewell to reach Extras). > >Lack of bug reporting database > >http://bugs.maemo.org is the preferred option. Otherwise it needs to be >identified in the http://maemo.org/packages/ page. As you might have noticed :) I ran into this one myself, so (after a short chat with GA on irc) I'd like to clarify a few things, potentially of interest to other folks in -testing, too: Is bugs.maemo.org really the preferred option ? There is no visible automatic, or user level registration of projects there, nor clear guidelines how to register a projects with b.m.o. According to GA, the process includes manual intervention and there is also no grouping (by Maemo categories), so it has great potential to get messy when projects start to migrate en masse to - testing. Opening a product for 'mirror', a one-liner script, for example, seems like a huge overkill. If we forego b.m.o, how do we identify this on the alternatively suggested packages page ? Again, I found no apparent way of entering such information on the page, nor wiki guideline (surely we don't want that sort of things stuffed into package descriptions?). ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras-testing and WONTFIX ?
On Fri, 23 Oct 2009, Attila Csipa wrote: > I've been thinking through some extras-testing scenarios... What happens if an > issue is marked as a blocker, but the developer says it's a WONTFIX, fixed in > Harmattan or similar ? If we play by the book, the app is stuck in testing and > everybody looses - users won't get a potentially interesting app, the > developer doesn't get karma/fame/device/whatever... so not good no matter how > you put it. Obviously, if it's really a QA blocker, we don't want to expose > users to it. On the other hand, we can't (and shouldn't) push developers doing > what they think is not right. So... any takes what the (general) right course > of action would be for such stuck applications (apart from the obvious lose- > lose scenario) ? Such programs will be available in external repositories. Hopefully there will be a collective repository including a large percent of the software (like extras repository in diablo). If not, then there will be many small repositories as it was before the drive to get everything into extras. If many developers will not bother with extras, and Nokia will be unhappy about it, they will have to change the rules. -- Matan Ziv-Av. ma...@svgalib.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras-testing and WONTFIX ?
2009/10/23 Attila Csipa : > I've been thinking through some extras-testing scenarios... What happens if an > issue is marked as a blocker, but the developer says it's a WONTFIX, fixed in > Harmattan or similar ? If we play by the book, the app is stuck in testing and > everybody looses - users won't get a potentially interesting app, the > developer doesn't get karma/fame/device/whatever... so not good no matter how > you put it. Obviously, if it's really a QA blocker, we don't want to expose > users to it. On the other hand, we can't (and shouldn't) push developers doing > what they think is not right. So... any takes what the (general) right course > of action would be for such stuck applications (apart from the obvious lose- > lose scenario) ? > Extras Testing is like being in quarantine for 10 days. After 10 days the app should get approved automatically to Maemo Extras (if some condition are met, but I don't quite remember the details) Of course one can always manually intervene and pull the app from Extras. In this case, though, is the developer that has the last word on his app. Unless the app causes damage or behaves really bad, it should be promoted to Extras. -- anidel Sent from London, Eng, United Kingdom ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
extras-testing and WONTFIX ?
I've been thinking through some extras-testing scenarios... What happens if an issue is marked as a blocker, but the developer says it's a WONTFIX, fixed in Harmattan or similar ? If we play by the book, the app is stuck in testing and everybody looses - users won't get a potentially interesting app, the developer doesn't get karma/fame/device/whatever... so not good no matter how you put it. Obviously, if it's really a QA blocker, we don't want to expose users to it. On the other hand, we can't (and shouldn't) push developers doing what they think is not right. So... any takes what the (general) right course of action would be for such stuck applications (apart from the obvious lose- lose scenario) ? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Power friendliness is in the hands of the app developers, but...
... are there actual examples for what we should do ? Sure, save as much power as we can, don't do things you don't have to, etc, etc. It's easy to say, but where are the 'good practice' examples (e.g. CODE) that demonstrate the suggested guidelines ? I'm starting to swim in boilerplate code trying account for all the ways power-saving might be an issue. For example do I really need to watch focus and window state events like a hawk to see when I have been minimized and thus in a position to cut some slack for the CPU ? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
gtkhtml "link_clicked"
Hello,
How can i handle LINKS in a GtkHtml Widget ?
I have tried to connect "link_clicked" with my funktion.
But what ever i do ... "link_clicked" seems to be ignored.
g_signal_connect(G_OBJECT(html_gtkwidget),
"link_clicked",
G_CALLBACK(my_link_clicked),
NULL);
void my_link_clicked (
GtkHTML *html,
const char *url)
{
//BREAKPOINT
}
##
p_rom...@gmx.de
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshot as loading screen on Maemo 5
2009/10/23 Luca Donaggio : > I was thinking that there should be a way to remove the existing screenshot > from a postinst script when upgrading to a new version of the app. > I mean, some way more reliable than `rm /home/user/.cache/launch/ name>.pvr`. > This could be useful if the new version has a substantially different UI > than before to not confuse previous users. Yes, that would be nice. A small utility that gets the file name of the .desktop file as parameter should be enough I believe? We could then add something like the following to postinst: maemo-remove-screenshot /usr/share/applications/hildon/appname.desktop I believe that maemo-remove-screenshot would then just use the same logic as hildon-desktop(?) to get the file name of the screenshot and remove it. When the location changes (in the hildon-desktop source) this utility would also know about the location change, then.. (The alternative of detecting an upgrade in the application code and doing the removal "by hand" using take=FALSE is cumbersome) Thomas ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: HildonAnimationActor and button events
It turned out to be so much easier without HildonAnimationActor. I was just totally on the wrong track regarding transparency, composition, clutter, and all. After spending one night with HildonRemoteTexture and one with HildonAnimationActor. I'm happy to say that to create a transparent overlay, you don't need them. Just create a new GtkWindow without decorations and use the code that Vlad sent earlier to get it transparent. Well, looks like I'm still a noob :) Thanks for all the help! Conny On Fri, 2009-10-23 at 13:52 +0200, Cornelius Hald wrote: > I think I now know how to do it. Probably I don't even need the > HildonAnimationActor. It should be possible only using cairo and argb > colormap. I'll give it a try later and report back. > > Cheers! > Conny > > > On Fri, 2009-10-23 at 13:12 +0200, Cornelius Hald wrote: > > Hi and thanks for you answer :) > > > > On Fri, 2009-10-23 at 13:01 +0200, Piñeiro wrote: > > > AFAIK, the real purpose of HildonAnimationActor is just what his name > > > indicates, a way to introduce animations on the hildon applications > > > with the help of the window manager, so in fact, it shouldn't be > > > required the feature you want. > > > > I could imagine many use cases where you want to click on something that > > is animated. For example a free floating UI element which you want to > > drag freely over the main window. Or which automatically moves away from > > the cursor, etc... > > > > > Why do you want to interact with this actor? What do you want to get? > > > > I've written a free floating semi transparent button which allows you to > > quit the fullscreen mode. It's supposed to behave exactly like in the > > browser. Of course I have no idea how they implemented it, but my > > implementation does work quite well already. > > > > The only problem is, that if you click this button, not only the > > fullscreen mode is toggled, but also the cursor is moved in the > > underlaying widget. > > > > Ideas how to implement that without the HildonAnimationActor are welcome > > of course. I tried two other ways of realizing this button, but both > > failed, so ATM the HildonAnimationActor is my best bet. > > > > 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 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle fullscreen mode [was Re: Call for testers with N900 for vncviewer]
On Fri, 2009-10-23 at 14:19 +0200, pHilipp Zabel wrote: > On Fri, Oct 23, 2009 at 1:00 PM, Cornelius Hald wrote: > > On Fri, 2009-10-23 at 10:55 +0100, Aniello Del Sorbo wrote: > >> HeFullscreenToggle ? > > > > I like that one. Andrew is of course right, that it doesn't really > > toggle, it just allows to go from fullscreen to not-fullscreen. It's > > difficult to put this into words and I think 'Fullscreen' should somehow > > be part of the name. > > > > So for now 'HeFullscreenToggle' is the winner. Thanks Aniello :) > > Maybe use that name for a convenience ToggleButton derived widget that > one can add to the toolbar? > It could automatically take care of generating the transparent overlay > in fullscreen mode. I could use that name for a convenience ToggleButton, unfortunately there is no such button ;) Of course, if someone wants to implement that, drop me a line and we'll figure out the names. I still have to test and clean my code before it will go to HE, so there is still some time regarding the name :) Cheers! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle fullscreen mode [was Re: Call for testers with N900 for vncviewer]
On Fri, 2009-10-23 at 16:31 +0300, Marius Gedminas wrote: > On Fri, Oct 23, 2009 at 11:44:33AM +0200, Cornelius Hald wrote: > > On Fri, 2009-10-23 at 11:27 +0200, Luca Donaggio wrote: > > > > > I'm no goot at finding names, but what about > > > he_fullscreen_toggle_overlay? > > > > It's a good fit I think. Something shorter would be nice, though. > > > > I was thinking about the following names, but they have problems too: > > > > - HeFullscreenButton sounds like it is a very big button > > - HeFullscreenOverlay sounds like a very big overlay > > How does it work, Gtk-wise? Is it a widget you add somewhere into your > widget tree? If so, where? Somewhere, where you have access to your window object you do the following: he_fullscreen_toggle_new (GTK_WINDOW(win)); The HeFullscreenToggle attaches itself to the window and listens for "window state changed" events. If the window changes its state to fullscreen, the HeFullscreenToggle displays itself. If the state of the window changes back to unfullscreen, the HeFullscreenToggle hides itself again. While the window is in fullscreen state. The HeFullscreenToggle also listens to all "button press" events. So always if you touch the display it is displayed. After 5 seconds of inactivity its hidden again. Just like in the browser. Once you click on the overlay button the parent window is set to unfullscreen. This of course means that your application still has to implement the logic how and when it will switch to fullscreen. I think it's the right way to go, because different applications have different needs. We'll see if others find it usefull. The code still needs cleaning, naming and testing before I put it in HE. But if you're curious it's currently here: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/conboy/src/fullscreenmanager.c?revision=466&root=conboy&view=markup > HeFullscreenOverlay sounds like a GtkBin subclass that contains your > main content area and draws the overlay in the corner when the app is > fullscreened. > > HeFloatingFullscreenButton is too long, I suppose. Yea, it's a bit difficult to describe it in one word ;) Cheers! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshot as loading screen on Maemo 5
I was thinking that there should be a way to remove the existing screenshot from a postinst script when upgrading to a new version of the app. I mean, some way more reliable than `rm /home/user/.cache/launch/.pvr`. This could be useful if the new version has a substantially different UI than before to not confuse previous users. Luca Donaggio 2009/10/23 Claudio Saavedra > El vie, 23-10-2009 a las 17:25 +0300, Kimmo Hämäläinen escribió: > > On Fri, 2009-10-23 at 14:46 +0200, ext Claudio Saavedra wrote: > > > El vie, 23-10-2009 a las 15:37 +0300, Kimmo Hämäläinen escribió: > > ... > > > Let's make a deal, you fix it in the desktop and I fix the > documentation > > > of the method :) > > > > Fixed in hildon-desktop git master now :) > > Committing this to hildon master now :) > > commit 7a9bcd71fe0399604d2bec10bc024290d8d1a9b9 > Author: Claudio Saavedra > Date: Fri Oct 23 18:02:53 2009 +0300 > >Improve the documentation for hildon_gtk_window_take_screenshot() > >Mention the fact that it's a Maemo 5 feature, what's the purpose >of the screenshot, and how to use it. > > diff --git a/hildon/hildon-gtk.c b/hildon/hildon-gtk.c > index f67f830..ee391e4 100644 > --- a/hildon/hildon-gtk.c > +++ b/hildon/hildon-gtk.c > @@ -456,8 +456,23 @@ hildon_gtk_window_enable_zoom_keys > (GtkWindow *window, > * @window: a #GtkWindow > * @take: %TRUE to take a screenshot, %FALSE to destroy the existing > one. > * > - * Tells the window manager to take a screenshot of @window, or to > - * destroy the existing one. @window must be mapped. > + * Tells the window manager to create a screenshot of @window and save > + * it, or to destroy the existing one. If @take is %TRUE but the > + * screenshot is already available, the window manager will not create > + * it again. > + * > + * You should only call this method when @window is already mapped. > + * > + * In Maemo 5 this screenshot, if existent, will be used by the window > + * manager in subsequent launches of the application that created > + * it. The window manager will remove this screenshot automatically > + * whenever the theme, locale, or the time changes; also when a backup > + * is restored. If your application changes its appearance between > + * runs and you want to force the existent screenshot to be removed, > + * set @take to %FALSE. > + * > + * Since: 2.0 > + * > **/ > void > hildon_gtk_window_take_screenshot (GtkWindow *window, > > > > ___ > 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: Screenshot as loading screen on Maemo 5
El vie, 23-10-2009 a las 17:25 +0300, Kimmo Hämäläinen escribió: > On Fri, 2009-10-23 at 14:46 +0200, ext Claudio Saavedra wrote: > > El vie, 23-10-2009 a las 15:37 +0300, Kimmo Hämäläinen escribió: > ... > > Let's make a deal, you fix it in the desktop and I fix the documentation > > of the method :) > > Fixed in hildon-desktop git master now :) Committing this to hildon master now :) commit 7a9bcd71fe0399604d2bec10bc024290d8d1a9b9 Author: Claudio Saavedra Date: Fri Oct 23 18:02:53 2009 +0300 Improve the documentation for hildon_gtk_window_take_screenshot() Mention the fact that it's a Maemo 5 feature, what's the purpose of the screenshot, and how to use it. diff --git a/hildon/hildon-gtk.c b/hildon/hildon-gtk.c index f67f830..ee391e4 100644 --- a/hildon/hildon-gtk.c +++ b/hildon/hildon-gtk.c @@ -456,8 +456,23 @@ hildon_gtk_window_enable_zoom_keys (GtkWindow *window, * @window: a #GtkWindow * @take: %TRUE to take a screenshot, %FALSE to destroy the existing one. * - * Tells the window manager to take a screenshot of @window, or to - * destroy the existing one. @window must be mapped. + * Tells the window manager to create a screenshot of @window and save + * it, or to destroy the existing one. If @take is %TRUE but the + * screenshot is already available, the window manager will not create + * it again. + * + * You should only call this method when @window is already mapped. + * + * In Maemo 5 this screenshot, if existent, will be used by the window + * manager in subsequent launches of the application that created + * it. The window manager will remove this screenshot automatically + * whenever the theme, locale, or the time changes; also when a backup + * is restored. If your application changes its appearance between + * runs and you want to force the existent screenshot to be removed, + * set @take to %FALSE. + * + * Since: 2.0 + * **/ void hildon_gtk_window_take_screenshot (GtkWindow *window, ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshot as loading screen on Maemo 5
On Fri, 2009-10-23 at 14:46 +0200, ext Claudio Saavedra wrote: > El vie, 23-10-2009 a las 15:37 +0300, Kimmo Hämäläinen escribió: ... > Let's make a deal, you fix it in the desktop and I fix the documentation > of the method :) Fixed in hildon-desktop git master now :) > > Claudio > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle fullscreen mode [was Re: Call for testers with N900 for vncviewer]
On Fri, Oct 23, 2009 at 11:44:33AM +0200, Cornelius Hald wrote: > On Fri, 2009-10-23 at 11:27 +0200, Luca Donaggio wrote: > > > I'm no goot at finding names, but what about > > he_fullscreen_toggle_overlay? > > It's a good fit I think. Something shorter would be nice, though. > > I was thinking about the following names, but they have problems too: > > - HeFullscreenButton sounds like it is a very big button > - HeFullscreenOverlay sounds like a very big overlay How does it work, Gtk-wise? Is it a widget you add somewhere into your widget tree? If so, where? HeFullscreenOverlay sounds like a GtkBin subclass that contains your main content area and draws the overlay in the corner when the app is fullscreened. HeFloatingFullscreenButton is too long, I suppose. Marius Gedminas -- After having done some test using hi-tech istruments (moving my mouse during a kernel build) [...] -- Davide Libenzi on lkml signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packaging Libraries
On Fri, Oct 23, 2009 at 02:13:57PM +0200, Jeremiah Foster wrote: > The best way to go about it might be to first pull down your source > package from upstream. Upstream is usually debian and that is easy to > do if you are on a debian, or even debian-like, machine: > > `apt-get source libyou-want-to-port` > > Once that is done, you'll find that you have an original tarball > (named usually libyou-want-to-port.orig.tar.gz) a diff tarball, a > description file ending in .dsc, and the source package dir. The > source package dir, i.e. "libyou-want-to-port/" should contain a > debian dir underneath. You can drop in there, change the maintainer > name to yours, note the dependencies, add that you are maemoifying it > to the changelog, and then build. Building is usually done in the > "libyou-want-to-port/" dir like this; > > `dpkg-buildpackage -D rfakeroot` That should be dpkg-buildpackage -D -rfakeroot. Or you can omit the -D, since it's enabled by default anyway. > You want to do this in scratchbox of course since that is where the > device's dependencies are kept, they should be identical to the > device. Once this building is done, you should get a .deb and .changes > file. The deb is now the binary archive you can use to install your > lib. You can test this on the device and you can also follow the > instructions on the maemo wiki on how to upload your resulting build. > > Of course, this all is a bit of a gloss, there may be issues, like > other dependencies not yet solved, and/or versions that are out of > sync, etc. But once you start this process, feel free to fire off > questions to this list or on IRC #maemo with error messages and you > should find that there are often people who will help you. I certainly > will, but there are others as well who are very knowledgeable about > the platform. There's also MUD Builder which attempts to automate most of the downloading-from-debian-patching-and-rebuilding steps: http://mud-builder.garage.maemo.org/ Marius Gedminas -- Unix for stability; Macs for productivity; Palm for mobility; Windows for Solitaire signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshot as loading screen on Maemo 5
El vie, 23-10-2009 a las 15:37 +0300, Kimmo Hämäläinen escribió: > > > The only thing that this method is doing in the client side is to > set a > > property in the window. When @take is %TRUE, it's the desktop the > one > > who should actually verify whether the screenshot exists already and > > create it or not. That doesn't really require new API, just that the > > desktop does the full job instead of delegating the responsibility > to do > > black voodoo to the client application. > > Yeah, that's right, we can check it in hildon-desktop, but the > function description should also tell the user of the API what is > happening. Let's make a deal, you fix it in the desktop and I fix the documentation of the method :) Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Black border/background around GtkButton
El vie, 23-10-2009 a las 08:25 -0400, Anderson Lizardo escribió: > On Fri, Oct 23, 2009 at 6:52 AM, Andrew Flegg wrote: > > Hi, > > > > If you look at this screenshot, you'll see there are black borders > > around the GtkButtons: > > > >http://twitpic.com/mknhl > > > > This is just two GtkButtons in a GtkHButtonBox in a GtkAlignment in a > > GtkWindow (which has had gdk_window_set_back_pixmap called on it). > > > > Is there a way of getting rid of these backgrounds/borders? > > I've seen that on Scratchbox + Xephyr, but I thought it was just some > drawing issue with Xephyr. Does it happen on a N900 too? > > Anyway, I'll let the GTK+ experts answer you (I'm interested in the > answer as well). This was a design decision from the UI design team [1], and it's implemented at the theme level (by drawing these borders inside the actual GtkButton and other widgets). There's nothing you can do to get rid of these margins. Rationale is that doing it this way, UI team could make sure that all apps "get the padding right". There's a bug about the lack of proper documentation of this in bugs.maemo.org (https://bugs.maemo.org/show_bug.cgi?id=5458). Claudio [1] That I opposed to back in the days, fwiw ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshot as loading screen on Maemo 5
On Fri, 2009-10-23 at 09:58 +0200, ext Claudio Saavedra wrote: > El vie, 23-10-2009 a las 09:39 +0300, Kimmo Hämäläinen escribió: > > > > > > > it's a good idea to check for the existence of the screenshot and > > > recreate it if necessary. > > > > Now that the function is missing this argument (bad design). > > What do you mean by bad design? Because it's not clear who should check for the existing image, or whether it's done at all. ... > The only thing that this method is doing in the client side is to set a > property in the window. When @take is %TRUE, it's the desktop the one > who should actually verify whether the screenshot exists already and > create it or not. That doesn't really require new API, just that the > desktop does the full job instead of delegating the responsibility to do > black voodoo to the client application. Yeah, that's right, we can check it in hildon-desktop, but the function description should also tell the user of the API what is happening. -Kimmo > > Of course a lot of applications are already checking for the existence > of the screenshot, but changing the semantics this way shouldn't really > hurt. > > Claudio > > ___ > 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: Black border/background around GtkButton
On Fri, Oct 23, 2009 at 13:25, Anderson Lizardo wrote: > On Fri, Oct 23, 2009 at 6:52 AM, Andrew Flegg wrote: >> >> Is there a way of getting rid of these backgrounds/borders? > > I've seen that on Scratchbox + Xephyr, but I thought it was just some > drawing issue with Xephyr. Does it happen on a N900 too? Yup. > Anyway, I'll let the GTK+ experts answer you (I'm interested in the > answer as well). Hopefully there's a GTK+ expert around who knows the answer... Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Black border/background around GtkButton
On Fri, Oct 23, 2009 at 6:52 AM, Andrew Flegg wrote: > Hi, > > If you look at this screenshot, you'll see there are black borders > around the GtkButtons: > > http://twitpic.com/mknhl > > This is just two GtkButtons in a GtkHButtonBox in a GtkAlignment in a > GtkWindow (which has had gdk_window_set_back_pixmap called on it). > > Is there a way of getting rid of these backgrounds/borders? I've seen that on Scratchbox + Xephyr, but I thought it was just some drawing issue with Xephyr. Does it happen on a N900 too? Anyway, I'll let the GTK+ experts answer you (I'm interested in the answer as well). 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 fullscreen mode [was Re: Call for testers with N900 for vncviewer]
On Fri, Oct 23, 2009 at 1:00 PM, Cornelius Hald wrote: > On Fri, 2009-10-23 at 10:55 +0100, Aniello Del Sorbo wrote: >> HeFullscreenToggle ? > > I like that one. Andrew is of course right, that it doesn't really > toggle, it just allows to go from fullscreen to not-fullscreen. It's > difficult to put this into words and I think 'Fullscreen' should somehow > be part of the name. > > So for now 'HeFullscreenToggle' is the winner. Thanks Aniello :) Maybe use that name for a convenience ToggleButton derived widget that one can add to the toolbar? It could automatically take care of generating the transparent overlay in fullscreen mode. regards Philipp ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packaging Libraries
On Oct 23, 2009, at 11:39, David Falkayn wrote: > I'm talking about a typical workflow; what steps would probably be > necessary to take a library that's available as a .deb somewhere and > make it available on Maemo? If i knew the specifics, i guess i wouldn' > t need to ask, but there are some general steps like (1) get source > package (2) modify package (3) create new package. It's the details of > how to best do this that i'm wondering about. > > Assume i know nothing and you'll probably be the closest to > understanding my question. ;) Hey David! The best way to go about it might be to first pull down your source package from upstream. Upstream is usually debian and that is easy to do if you are on a debian, or even debian-like, machine: `apt-get source libyou-want-to-port` Once that is done, you'll find that you have an original tarball (named usually libyou-want-to-port.orig.tar.gz) a diff tarball, a description file ending in .dsc, and the source package dir. The source package dir, i.e. "libyou-want-to-port/" should contain a debian dir underneath. You can drop in there, change the maintainer name to yours, note the dependencies, add that you are maemoifying it to the changelog, and then build. Building is usually done in the "libyou-want-to-port/" dir like this; `dpkg-buildpackage -D rfakeroot` You want to do this in scratchbox of course since that is where the device's dependencies are kept, they should be identical to the device. Once this building is done, you should get a .deb and .changes file. The deb is now the binary archive you can use to install your lib. You can test this on the device and you can also follow the instructions on the maemo wiki on how to upload your resulting build. Of course, this all is a bit of a gloss, there may be issues, like other dependencies not yet solved, and/or versions that are out of sync, etc. But once you start this process, feel free to fire off questions to this list or on IRC #maemo with error messages and you should find that there are often people who will help you. I certainly will, but there are others as well who are very knowledgeable about the platform. Good luck and keep us up to date! Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using the sharing plugins
2009/10/23 daniel wilms : > Hi, > > at the moment it is not available, but the plan exist to make it so. > Although I cannot give you any concrete information about the time frame > yet, I will keep you up to date. > > Cheers Daniel > Okay thanks. Guess I'll have to wait . Aniello > ext Aniello Del Sorbo wrote: >> >> :( >> >> Any idea of when this will be available? >> >> Aniello >> >> 2009/10/23 daniel wilms : >> >>> >>> Hi, >>> >>> a general comment about that. Unfortunately right now there is no >>> possibility to use the sharing dialog from a 3rd party application. >>> >>> Cheers Daniel >>> >>> ext Aniello Del Sorbo wrote: >>> No updates.. there should be a Sharing Service that should pop up the sharing dialog, but I can't seem to find the DBUS signature to call it. If any. Any help? Ideas? Am I the only one who wants to share a file from his own application? :) -- anidel Sent from London, Eng, United Kingdom 2009/10/22 Aniello Del Sorbo : > > Hi, > > I've seen the documentation about how to make your own sharing plugin > [1]. > > Is there documentation on how to actually use them from our own > application? > > [1] > > http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Using_Data_Sharing/Sharing_Plug-in > > -- > anidel > > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers >>> >>> >> >> >> >> > > -- anidel Sent from London, Eng, United Kingdom ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using the sharing plugins
Hi, at the moment it is not available, but the plan exist to make it so. Although I cannot give you any concrete information about the time frame yet, I will keep you up to date. Cheers Daniel ext Aniello Del Sorbo wrote: > :( > > Any idea of when this will be available? > > Aniello > > 2009/10/23 daniel wilms : > >> Hi, >> >> a general comment about that. Unfortunately right now there is no >> possibility to use the sharing dialog from a 3rd party application. >> >> Cheers Daniel >> >> ext Aniello Del Sorbo wrote: >> >>> No updates.. there should be a Sharing Service that should pop up the >>> sharing dialog, but I can't seem to find the DBUS signature to call >>> it. If any. >>> >>> Any help? >>> Ideas? >>> >>> Am I the only one who wants to share a file from his own application? :) >>> >>> -- >>> anidel >>> Sent from London, Eng, United Kingdom >>> >>> >>> 2009/10/22 Aniello Del Sorbo : >>> >>> Hi, I've seen the documentation about how to make your own sharing plugin [1]. Is there documentation on how to actually use them from our own application? [1] http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Using_Data_Sharing/Sharing_Plug-in -- anidel >>> ___ >>> 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: HildonAnimationActor and button events
I think I now know how to do it. Probably I don't even need the HildonAnimationActor. It should be possible only using cairo and argb colormap. I'll give it a try later and report back. Cheers! Conny On Fri, 2009-10-23 at 13:12 +0200, Cornelius Hald wrote: > Hi and thanks for you answer :) > > On Fri, 2009-10-23 at 13:01 +0200, Piñeiro wrote: > > AFAIK, the real purpose of HildonAnimationActor is just what his name > > indicates, a way to introduce animations on the hildon applications > > with the help of the window manager, so in fact, it shouldn't be > > required the feature you want. > > I could imagine many use cases where you want to click on something that > is animated. For example a free floating UI element which you want to > drag freely over the main window. Or which automatically moves away from > the cursor, etc... > > > Why do you want to interact with this actor? What do you want to get? > > I've written a free floating semi transparent button which allows you to > quit the fullscreen mode. It's supposed to behave exactly like in the > browser. Of course I have no idea how they implemented it, but my > implementation does work quite well already. > > The only problem is, that if you click this button, not only the > fullscreen mode is toggled, but also the cursor is moved in the > underlaying widget. > > Ideas how to implement that without the HildonAnimationActor are welcome > of course. I tried two other ways of realizing this button, but both > failed, so ATM the HildonAnimationActor is my best bet. > > 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: Announcement: mafw-gst-eq-renderer initial version
On Fri, 2009-10-23 at 12:36 +0200, Xabier Rodriguez Calvar wrote: > O Ven, 23-10-2009 ás 12:18 +0200, Juan A. Suarez Romero escribiu: > > > > Because official renderer doesn't include an equalizer element in > > gstreamer pipeline, which fork does. > > > > The fork sets equalizer values from gconf. And applet is intended to > > change those values in gconf, though you can write your own utility to > > do it. > > But if the change is only inside the renderer, I don't see any reason > why it couldn't work with the official mp, as they don't care anything > about the pipeline. MTR flavour creates a new source with its own uuid (gsteqrenderer), which Mediaplayer doesn't handle. MGR flavour replaces mafw-gst-renderer, reusing the same uuid (gstrenderer), which is handle by mediaplayer. So if you want to use it with mediaplayer, you must install MGR flavour and remove old mafw-gst-renderer (to avoid conflicts as both are using the same names). J.A. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle fullscreen mode [was Re: Call for testers with N900 for vncviewer]
On Fri, 2009-10-23 at 12:07 +0100, Aniello Del Sorbo wrote: > Why is that not a toggle? Because I didn't make it a toggle :D > Can it also bring from non fullscreen to fullscreen? > Simply NOT fade away when in not fullscreen mode... may be passing > that flag via parameter? > > HeFullscreenToggle -> whatever other param, | > > So, if I use it in my toolbar (where I'll leave empty space), it'll > look like a button in un-fullscreen mode with NO_FADE_OUT param. > If I use it in my un-fullscreen app with no toolbar, I still can use > it to toggle fullscreen. That would be of course possible and once the code is in hildon extras you can of course contribute to it. I decided against it, simply because I personally don't need it. In Conboy you activate the fullscreen mode using the menu or a keyboard shortcut. If you want a button on the toolbar, why not just add the button and add gtk_window_fullscreen() as callback. That's almost a one liner + you get the correct behavior of this button, e.g. spacing between other buttons, colorful highlight while pressing etc... Cheers! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Browser addons
Hi, the documentation on how to write browser extensions is not ready yet, but will be available soon. Cheers Daniel ext Sampo Savola wrote: > Hey > > I wonder is there going to be an addon support for Maemo Browser in > Maemo5 like there was in earlier Maemo versions. > > Is there any tutorial how to write new or port existing Firefox addons > for Maemo Browser, unless they work without modifications? > > I would like to see at least adblock for Maemo5 browser :) > > > //Sampo > ___ > 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
Extras Testing queue and number of days left (out of 10)
Hi, it is too complicated to show how many days an application has been in the queue (say 5/10) along with its Karma? -- anidel Sent from London, Eng, United Kingdom ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: HildonAnimationActor and button events
Hi and thanks for you answer :) On Fri, 2009-10-23 at 13:01 +0200, Piñeiro wrote: > AFAIK, the real purpose of HildonAnimationActor is just what his name > indicates, a way to introduce animations on the hildon applications > with the help of the window manager, so in fact, it shouldn't be > required the feature you want. I could imagine many use cases where you want to click on something that is animated. For example a free floating UI element which you want to drag freely over the main window. Or which automatically moves away from the cursor, etc... > Why do you want to interact with this actor? What do you want to get? I've written a free floating semi transparent button which allows you to quit the fullscreen mode. It's supposed to behave exactly like in the browser. Of course I have no idea how they implemented it, but my implementation does work quite well already. The only problem is, that if you click this button, not only the fullscreen mode is toggled, but also the cursor is moved in the underlaying widget. Ideas how to implement that without the HildonAnimationActor are welcome of course. I tried two other ways of realizing this button, but both failed, so ATM the HildonAnimationActor is my best bet. Thanks! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle fullscreen mode [was Re: Call for testers with N900 for vncviewer]
2009/10/23 Cornelius Hald : > On Fri, 2009-10-23 at 10:55 +0100, Aniello Del Sorbo wrote: >> HeFullscreenToggle ? > > I like that one. Andrew is of course right, that it doesn't really > toggle, it just allows to go from fullscreen to not-fullscreen. It's > difficult to put this into words and I think 'Fullscreen' should somehow > be part of the name. > > So for now 'HeFullscreenToggle' is the winner. Thanks Aniello :) > > Now if only someone could help me with those emission hooks... > Conny > Why is that not a toggle? Can it also bring from non fullscreen to fullscreen? Simply NOT fade away when in not fullscreen mode... may be passing that flag via parameter? HeFullscreenToggle -> whatever other param, | So, if I use it in my toolbar (where I'll leave empty space), it'll look like a button in un-fullscreen mode with NO_FADE_OUT param. If I use it in my un-fullscreen app with no toolbar, I still can use it to toggle fullscreen. -- anidel Sent from London, Eng, United Kingdom ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: HildonAnimationActor and button events
From: Cornelius Hald > the documentation of HildonAnimationActor states that by design it is > not reactive. Meaning that actors do not receive motion or button > events. > > The thing is, I want to get notified if someone clicks on my actor, so > how can I do this? Well, as the documentation says, and you have just said, by design this is not possible. > I have a half working solution: I'm using a signal emission hook to > catch all button events that have been emitted. Then I translate the > button press coordinates into coordinates of the main window. With those > coordinates I check whether or not the click was on my actor or not. > > The problem is, that the signal is propagated further, so if there is, > for example, a button under my actor it will also receive the button > clicked event. I don't want that. I want that it stops after being > handled by my actor. I tried using g_signal_stop_emission() inside the > signal hook function, but glib tells me that this is not allowed. > > I'm really lost here, help would be very much appreciated :) AFAIK, the real purpose of HildonAnimationActor is just what his name indicates, a way to introduce animations on the hildon applications with the help of the window manager, so in fact, it shouldn't be required the feature you want. Why do you want to interact with this actor? What do you want to get? === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle fullscreen mode [was Re: Call for testers with N900 for vncviewer]
On Fri, 2009-10-23 at 10:55 +0100, Aniello Del Sorbo wrote: > HeFullscreenToggle ? I like that one. Andrew is of course right, that it doesn't really toggle, it just allows to go from fullscreen to not-fullscreen. It's difficult to put this into words and I think 'Fullscreen' should somehow be part of the name. So for now 'HeFullscreenToggle' is the winner. Thanks Aniello :) Now if only someone could help me with those emission hooks... Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Black border/background around GtkButton
Hi, If you look at this screenshot, you'll see there are black borders around the GtkButtons: http://twitpic.com/mknhl This is just two GtkButtons in a GtkHButtonBox in a GtkAlignment in a GtkWindow (which has had gdk_window_set_back_pixmap called on it). Is there a way of getting rid of these backgrounds/borders? Thanks in advance, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Announcement: mafw-gst-eq-renderer initial version
O Ven, 23-10-2009 ás 12:18 +0200, Juan A. Suarez Romero escribiu: > > Because official renderer doesn't include an equalizer element in > gstreamer pipeline, which fork does. > > The fork sets equalizer values from gconf. And applet is intended to > change those values in gconf, though you can write your own utility to > do it. But if the change is only inside the renderer, I don't see any reason why it couldn't work with the official mp, as they don't care anything about the pipeline. Br. -- Xabier Rodríguez Calvar Enxeñeiro en Informática IGALIA http://www.igalia.com signature.asc Description: Esta é unha parte de mensaxe asinada dixitalmente ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Announcement: mafw-gst-eq-renderer initial version
On Fri, 2009-10-23 at 10:58 +0200, Xabier Rodriguez Calvar wrote: > O Xov, 22-10-2009 ás 13:35 +0200, Juan A. Suarez Romero escribiu: > > If you choose the second flavour, default mediaplayer will not be able > > to use it, as it only handles one renderer: mafw-gst-renderer. > > Which is the reason? If you control equalization with the applet, why > can't you use it with the official mp? > Because official renderer doesn't include an equalizer element in gstreamer pipeline, which fork does. The fork sets equalizer values from gconf. And applet is intended to change those values in gconf, though you can write your own utility to do it. J.A. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle fullscreen mode [was Re: Call for testers with N900 for vncviewer]
2009/10/23 Cornelius Hald : > On Fri, 2009-10-23 at 11:27 +0200, Luca Donaggio wrote: > >> I'm no goot at finding names, but what about >> he_fullscreen_toggle_overlay? > > It's a good fit I think. Something shorter would be nice, though. > > I was thinking about the following names, but they have problems too: > > - HeFullscreenButton sounds like it is a very big button > - HeFullscreenOverlay sounds like a very big overlay > > Originally I wanted to call it HeFullscreenManager, but I now removed > all the 'manager' functionality, so I can't really call it 'manager' > anymore ;) > > Other suggestions? > > Conny > HeFullscreenToggle ? -- anidel Sent from London, Eng, United Kingdom ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle fullscreen mode [was Re: Call for testers with N900 for vncviewer]
On Fri, Oct 23, 2009 at 10:44, Cornelius Hald wrote: > On Fri, 2009-10-23 at 11:27 +0200, Luca Donaggio wrote: > >> I'm no goot at finding names, but what about >> he_fullscreen_toggle_overlay? > > It's a good fit I think. Something shorter would be nice, though. > > I was thinking about the following names, but they have problems too: > > - HeFullscreenButton sounds like it is a very big button > - HeFullscreenOverlay sounds like a very big overlay HeUnmaximiseButton (since another mechanism is used to *go* fullscreen, isn't it)? HTH, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle fullscreen mode [was Re: Call for testers with N900 for vncviewer]
On Fri, 2009-10-23 at 11:27 +0200, Luca Donaggio wrote: > I'm no goot at finding names, but what about > he_fullscreen_toggle_overlay? It's a good fit I think. Something shorter would be nice, though. I was thinking about the following names, but they have problems too: - HeFullscreenButton sounds like it is a very big button - HeFullscreenOverlay sounds like a very big overlay Originally I wanted to call it HeFullscreenManager, but I now removed all the 'manager' functionality, so I can't really call it 'manager' anymore ;) Other suggestions? Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packaging Libraries
I'm talking about a typical workflow; what steps would probably be necessary to take a library that's available as a .deb somewhere and make it available on Maemo? If i knew the specifics, i guess i wouldn' t need to ask, but there are some general steps like (1) get source package (2) modify package (3) create new package. It's the details of how to best do this that i'm wondering about. Assume i know nothing and you'll probably be the closest to understanding my question. ;) On 10/23/09, Claudio Saavedra wrote: > El vie, 23-10-2009 a las 00:37 -0400, David Falkayn escribió: >> Here's a question for you whiz kids: what's the best way to go about >> packaging up a library that already exists, e.g. in debian, for Maemo? >> >> Presumably the process is easier than starting from scratch, but after >> fiddling around with various things and some nice help on IRC, i got >> nuttin. > > Could you be more precise? > > Claudio > > > ___ > 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: Screenshot as loading screen on Maemo 5
2009/10/23 Claudio Saavedra : > El vie, 23-10-2009 a las 09:58 +0100, Aniello Del Sorbo escribió: >> 2009/10/23 Cornelius Hald : >> > On Fri, 2009-10-23 at 09:20 +0300, Kimmo Hämäläinen wrote: >> >> On Fri, 2009-10-23 at 08:08 +0200, Hamalainen Kimmo (Nokia-D/Helsinki) >> >> wrote: >> >> ... >> >> > Please, no threads, no! The screenshot is only taken if it does not >> >> > exist, otherwise the existing screenshot is used. So, the performance >> >> > penalty is not there every time, only when the old screenshot does not >> >> > exist. >> >> >> >> I take this back... After checking the code, it seems the application >> >> needs to check for the existing screenshot. What a disappointing >> >> design... >> > >> > But at least it looks like all screenshots are deleted automatically >> > once you switch themes. That's good :) >> > >> > Conny >> >> >> So ok, to recap, the hildon_gtk_window_take_screenshot only sends a DBUS >> message >> to the window manager, > > No; it sets a property in the XWindow. No dbus involved. Read my > previous message. > Yeah, sorry, "DBUS" just slipped out of my fingers. >> I think the best would be to have a way to retrieve the screenshot path >> so that we can check for it's existence before taking a new one (thus >> we wouldn't be checking >> it in a static path as we do now), instead of >> hildon_gtk_window_take_screenshot checking for >> its existence. > > That would add extra communication overhead. I insist that the best > would be that the desktop itself checks whether the screenshot already > exists. > That's true, but having a means of knowing where the screen-shot is stored, gives us more control (as Andrew just explained) It's also true that it's just a screen-shot to fake a faster load of the application and we may not need that much control anyway. -- anidel Sent from London, Eng, United Kingdom ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle fullscreen mode [was Re: Call for testers with N900 for vncviewer]
On Thu, Oct 22, 2009 at 11:48 PM, Cornelius Hald wrote: > On Wed, 2009-10-21 at 17:13 +0200, Luca Donaggio wrote: > > If there's neither hardware button to toggle fullscreen mode nor a > > default keyboard shortcut and the preferred method is via the > > touchscreen then a specific widget should be included in hildon, just > > to avoid duplicating the same code or, even worse, 'reinventing the > > wheel' for every app. > > > > Maybe it's a candidate for inclusion in Hildon Extras [1] -hint > > hint- ? > > It's not yet perfect, but I think I'll get it soon into Hildon Extras. > The usage is as easy as calling "he_fancy_name_new(window);[1]" it will > take care of the rest alone. > > I'll be back soon with some questions about transparency, composition > and signal emission, but first I have to sleep :) > > http://zwong.de/wp-content/uploads/2009/10/transparent_overlay.png > > Good Night! > Conny > > > [1] The name is not yet decided, so suggestions are welcome. > > > Great Conny! I'm no goot at finding names, but what about he_fullscreen_toggle_overlay? Luca Donaggio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshot as loading screen on Maemo 5
On Fri, Oct 23, 2009 at 10:16, Claudio Saavedra wrote: > > I insist that the best would be that the desktop itself checks whether > the screenshot already exists. Agreed. However, what if the application wants to refresh the screenshot because of a layout/settings change? For this use case, the app should call ...take_screenshot(.., FALSE) to remove the existing one; and then ...take_screenshot(.., TRUE) as normal at next startup/whenever? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshot as loading screen on Maemo 5
El vie, 23-10-2009 a las 09:58 +0100, Aniello Del Sorbo escribió: > 2009/10/23 Cornelius Hald : > > On Fri, 2009-10-23 at 09:20 +0300, Kimmo Hämäläinen wrote: > >> On Fri, 2009-10-23 at 08:08 +0200, Hamalainen Kimmo (Nokia-D/Helsinki) > >> wrote: > >> ... > >> > Please, no threads, no! The screenshot is only taken if it does not > >> > exist, otherwise the existing screenshot is used. So, the performance > >> > penalty is not there every time, only when the old screenshot does not > >> > exist. > >> > >> I take this back... After checking the code, it seems the application > >> needs to check for the existing screenshot. What a disappointing > >> design... > > > > But at least it looks like all screenshots are deleted automatically > > once you switch themes. That's good :) > > > > Conny > > > So ok, to recap, the hildon_gtk_window_take_screenshot only sends a DBUS > message > to the window manager, No; it sets a property in the XWindow. No dbus involved. Read my previous message. > I think the best would be to have a way to retrieve the screenshot path > so that we can check for it's existence before taking a new one (thus > we wouldn't be checking > it in a static path as we do now), instead of > hildon_gtk_window_take_screenshot checking for > its existence. That would add extra communication overhead. I insist that the best would be that the desktop itself checks whether the screenshot already exists. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using the sharing plugins
:( Any idea of when this will be available? Aniello 2009/10/23 daniel wilms : > Hi, > > a general comment about that. Unfortunately right now there is no > possibility to use the sharing dialog from a 3rd party application. > > Cheers Daniel > > ext Aniello Del Sorbo wrote: >> >> No updates.. there should be a Sharing Service that should pop up the >> sharing dialog, but I can't seem to find the DBUS signature to call >> it. If any. >> >> Any help? >> Ideas? >> >> Am I the only one who wants to share a file from his own application? :) >> >> -- >> anidel >> Sent from London, Eng, United Kingdom >> >> >> 2009/10/22 Aniello Del Sorbo : >> >>> >>> Hi, >>> >>> I've seen the documentation about how to make your own sharing plugin >>> [1]. >>> >>> Is there documentation on how to actually use them from our own >>> application? >>> >>> [1] >>> http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Using_Data_Sharing/Sharing_Plug-in >>> >>> -- >>> anidel >>> >>> >> >> ___ >> maemo-developers mailing list >> maemo-developers@maemo.org >> https://lists.maemo.org/mailman/listinfo/maemo-developers >> > > -- anidel Sent from London, Eng, United Kingdom ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Announcement: mafw-gst-eq-renderer initial version
O Xov, 22-10-2009 ás 13:35 +0200, Juan A. Suarez Romero escribiu: > If you choose the second flavour, default mediaplayer will not be able > to use it, as it only handles one renderer: mafw-gst-renderer. Which is the reason? If you control equalization with the applet, why can't you use it with the official mp? Br. -- Xabier Rodríguez Calvar Enxeñeiro en Informática IGALIA http://www.igalia.com signature.asc Description: Esta é unha parte de mensaxe asinada dixitalmente ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshot as loading screen on Maemo 5
2009/10/23 Cornelius Hald : > On Fri, 2009-10-23 at 09:20 +0300, Kimmo Hämäläinen wrote: >> On Fri, 2009-10-23 at 08:08 +0200, Hamalainen Kimmo (Nokia-D/Helsinki) >> wrote: >> ... >> > Please, no threads, no! The screenshot is only taken if it does not >> > exist, otherwise the existing screenshot is used. So, the performance >> > penalty is not there every time, only when the old screenshot does not >> > exist. >> >> I take this back... After checking the code, it seems the application >> needs to check for the existing screenshot. What a disappointing >> design... > > But at least it looks like all screenshots are deleted automatically > once you switch themes. That's good :) > > Conny So ok, to recap, the hildon_gtk_window_take_screenshot only sends a DBUS message to the window manager, but the application still is kind of locked while taking the screenshot (I notice a small slowness when taking the screenshot for the first time). Anyway, a thread wouldn't help at all and as we now know it's also not needed. I think the best would be to have a way to retrieve the screenshot path so that we can check for it's existence before taking a new one (thus we wouldn't be checking it in a static path as we do now), instead of hildon_gtk_window_take_screenshot checking for its existence. -- anidel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
HildonAnimationActor and button events
Hi, the documentation of HildonAnimationActor states that by design it is not reactive. Meaning that actors do not receive motion or button events. The thing is, I want to get notified if someone clicks on my actor, so how can I do this? I have a half working solution: I'm using a signal emission hook to catch all button events that have been emitted. Then I translate the button press coordinates into coordinates of the main window. With those coordinates I check whether or not the click was on my actor or not. The problem is, that the signal is propagated further, so if there is, for example, a button under my actor it will also receive the button clicked event. I don't want that. I want that it stops after being handled by my actor. I tried using g_signal_stop_emission() inside the signal hook function, but glib tells me that this is not allowed. I'm really lost here, help would be very much appreciated :) Thanks! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshot as loading screen on Maemo 5
On Fri, 2009-10-23 at 09:20 +0300, Kimmo Hämäläinen wrote: > On Fri, 2009-10-23 at 08:08 +0200, Hamalainen Kimmo (Nokia-D/Helsinki) > wrote: > ... > > Please, no threads, no! The screenshot is only taken if it does not > > exist, otherwise the existing screenshot is used. So, the performance > > penalty is not there every time, only when the old screenshot does not > > exist. > > I take this back... After checking the code, it seems the application > needs to check for the existing screenshot. What a disappointing > design... But at least it looks like all screenshots are deleted automatically once you switch themes. That's good :) Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: HildonAnimationActor and transparency
Vlad, you are great :)
Your solution works like a charm. Thank you very much!!!
I think you could also have a solution for my second problem, but I'll
create a new thread for that.
Thanks again!
Conny
On Fri, 2009-10-23 at 10:40 +0300, Vlad Vasiliev wrote:
> I'm sorry I forgot a small additional part of code.
>
> Here is the correct variant
>
> pixbuf = gdk_pixbuf_new_from_file_at_size
> ("/usr/share/omweather/icons/Glance/dark_cloud.png",
>128, 128, NULL);
>
> image = gtk_image_new_from_pixbuf (pixbuf);
> g_object_unref(G_OBJECT(pixbuf));
> g_signal_connect(G_OBJECT(image), "expose_event",
> G_CALLBACK(expose_event),
> pixbuf)
> ha = hildon_animation_actor_new();
> gtk_container_add (GTK_CONTAINER (ha), image);
> realize(ha);
> gtk_widget_show_all (ha)
>
>
> realize (GtkWidget *widget)
> {
> GdkScreen *screen;
> screen = gtk_widget_get_screen (widget);
> gtk_widget_set_colormap (widget, gdk_screen_get_rgba_colormap (screen));
> }
>
> gboolean
> expose_event (GtkWidget *widget,GdkEventExpose *event,
> gpointer data)
> {
> cairo_t *cr;
> GdkPixbuf *pixbuf = (GdkPixbuf *) data;
>
> cr = gdk_cairo_create(widget->window);
> gdk_cairo_region(cr, event->region);
> cairo_set_operator(cr, CAIRO_OPERATOR_SOURCE);
> gdk_cairo_set_source_pixbuf(cr, pixbuf, 0.0, 0.0);
> cairo_paint(cr);
> cairo_destroy(cr);
> return TRUE;
> }
>
>
>
> Vlad Vasiliev wrote:
> > Hi Cornelius
> >
> > I used the next solution:
> >
> > pixbuf = gdk_pixbuf_new_from_file_at_size
> > ("/usr/share/omweather/icons/Glance/dark_cloud.png",
> >128, 128, NULL);
> >
> > image = gtk_image_new_from_pixbuf (pixbuf);
> > g_object_unref(G_OBJECT(pixbuf));
> > g_signal_connect(G_OBJECT(image), "expose_event",
> > G_CALLBACK(expose_event),
> > pixbuf)
> > ha = hildon_animation_actor_new();
> > gtk_container_add (GTK_CONTAINER (ha), image);
> >
> >
> > gboolean
> > expose_event (GtkWidget *widget,GdkEventExpose *event,
> > gpointer data)
> > {
> > cairo_t *cr;
> > GdkPixbuf *pixbuf = (GdkPixbuf *) data;
> >
> > cr = gdk_cairo_create(widget->window);
> > gdk_cairo_region(cr, event->region);
> > cairo_set_operator(cr, CAIRO_OPERATOR_SOURCE);
> > gdk_cairo_set_source_pixbuf(cr, pixbuf, 0.0, 0.0);
> > cairo_paint(cr);
> > cairo_destroy(cr);
> > return TRUE;
> > }
> >
> > BR,
> > Vlad.
> > Cornelius Hald wrote:
> >
> >> Hi,
> >>
> >> yesterday I was playing around with HildonAnimationActor and it's really
> >> nice what you can do with it. But there are still some things, I don't
> >> really understand. Hopefully someone can help me with that :)
> >>
> >> I created a HildonAnimationActor and put a GtkImage, made from a ARGB
> >> png, onto it with gtk_container_add().
> >>
> >> The problem is, that the HildonAnimationActor has it's own background,
> >> so the transparent parts of the image show the background of the actor
> >> instead of the underlaying widget.
> >>
> >> I can use hildon_animation_actor_set_opacity() an the actor to make it
> >> transparent, but that affects the complete actor, so both, the actors
> >> background and the image become transparent.
> >>
> >> My question is: How do I make the background of the actor completely
> >> transparent without altering the transparency of the content of the
> >> actor?
> >>
> >> I really hope I don't have to go back to HildonRemoteTexture, because
> >> HildonAnimationActor is much nicer for my purpose.
> >>
> >> Thanks!
> >> Conny
> >>
> >>
> >> P.S. HildonAnimationActor is a GtkWindow, so maybe I should just try to
> >> remove the background of the window? I don't know how to do that, but I
> >> know it's possible. Would this be the way to go or is there a simpler
> >> way?
> >>
> >>
> >> ___
> >> 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
> >
>
> ___
> 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: Screenshot as loading screen on Maemo 5
El vie, 23-10-2009 a las 09:39 +0300, Kimmo Hämäläinen escribió: > > > > it's a good idea to check for the existence of the screenshot and > > recreate it if necessary. > > Now that the function is missing this argument (bad design). What do you mean by bad design? > We should > add some API for creating the screenshot _only if_ it does not exist. > Because the place where the screenshot is stored, is not really public > information. Well, the hildon API is void hildon_gtk_window_take_screenshot (GtkWindow *window, gboolean take); If @take is %FALSE, the screenshot for @window is destroyed. The only thing that this method is doing in the client side is to set a property in the window. When @take is %TRUE, it's the desktop the one who should actually verify whether the screenshot exists already and create it or not. That doesn't really require new API, just that the desktop does the full job instead of delegating the responsibility to do black voodoo to the client application. Of course a lot of applications are already checking for the existence of the screenshot, but changing the semantics this way shouldn't really hurt. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: HildonAnimationActor and transparency
I'm sorry I forgot a small additional part of code.
Here is the correct variant
pixbuf = gdk_pixbuf_new_from_file_at_size
("/usr/share/omweather/icons/Glance/dark_cloud.png",
128, 128, NULL);
image = gtk_image_new_from_pixbuf (pixbuf);
g_object_unref(G_OBJECT(pixbuf));
g_signal_connect(G_OBJECT(image), "expose_event",
G_CALLBACK(expose_event), pixbuf)
ha = hildon_animation_actor_new();
gtk_container_add (GTK_CONTAINER (ha), image);
realize(ha);
gtk_widget_show_all (ha)
realize (GtkWidget *widget)
{
GdkScreen *screen;
screen = gtk_widget_get_screen (widget);
gtk_widget_set_colormap (widget, gdk_screen_get_rgba_colormap (screen));
}
gboolean
expose_event (GtkWidget *widget,GdkEventExpose *event,
gpointer data)
{
cairo_t *cr;
GdkPixbuf *pixbuf = (GdkPixbuf *) data;
cr = gdk_cairo_create(widget->window);
gdk_cairo_region(cr, event->region);
cairo_set_operator(cr, CAIRO_OPERATOR_SOURCE);
gdk_cairo_set_source_pixbuf(cr, pixbuf, 0.0, 0.0);
cairo_paint(cr);
cairo_destroy(cr);
return TRUE;
}
Vlad Vasiliev wrote:
> Hi Cornelius
>
> I used the next solution:
>
> pixbuf = gdk_pixbuf_new_from_file_at_size
> ("/usr/share/omweather/icons/Glance/dark_cloud.png",
>128, 128, NULL);
>
> image = gtk_image_new_from_pixbuf (pixbuf);
> g_object_unref(G_OBJECT(pixbuf));
> g_signal_connect(G_OBJECT(image), "expose_event",
> G_CALLBACK(expose_event),
> pixbuf)
> ha = hildon_animation_actor_new();
> gtk_container_add (GTK_CONTAINER (ha), image);
>
>
> gboolean
> expose_event (GtkWidget *widget,GdkEventExpose *event,
> gpointer data)
> {
> cairo_t *cr;
> GdkPixbuf *pixbuf = (GdkPixbuf *) data;
>
> cr = gdk_cairo_create(widget->window);
> gdk_cairo_region(cr, event->region);
> cairo_set_operator(cr, CAIRO_OPERATOR_SOURCE);
> gdk_cairo_set_source_pixbuf(cr, pixbuf, 0.0, 0.0);
> cairo_paint(cr);
> cairo_destroy(cr);
> return TRUE;
> }
>
> BR,
> Vlad.
> Cornelius Hald wrote:
>
>> Hi,
>>
>> yesterday I was playing around with HildonAnimationActor and it's really
>> nice what you can do with it. But there are still some things, I don't
>> really understand. Hopefully someone can help me with that :)
>>
>> I created a HildonAnimationActor and put a GtkImage, made from a ARGB
>> png, onto it with gtk_container_add().
>>
>> The problem is, that the HildonAnimationActor has it's own background,
>> so the transparent parts of the image show the background of the actor
>> instead of the underlaying widget.
>>
>> I can use hildon_animation_actor_set_opacity() an the actor to make it
>> transparent, but that affects the complete actor, so both, the actors
>> background and the image become transparent.
>>
>> My question is: How do I make the background of the actor completely
>> transparent without altering the transparency of the content of the
>> actor?
>>
>> I really hope I don't have to go back to HildonRemoteTexture, because
>> HildonAnimationActor is much nicer for my purpose.
>>
>> Thanks!
>> Conny
>>
>>
>> P.S. HildonAnimationActor is a GtkWindow, so maybe I should just try to
>> remove the background of the window? I don't know how to do that, but I
>> know it's possible. Would this be the way to go or is there a simpler
>> way?
>>
>>
>> ___
>> 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
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using the sharing plugins
Hi, a general comment about that. Unfortunately right now there is no possibility to use the sharing dialog from a 3rd party application. Cheers Daniel ext Aniello Del Sorbo wrote: > No updates.. there should be a Sharing Service that should pop up the > sharing dialog, but I can't seem to find the DBUS signature to call > it. If any. > > Any help? > Ideas? > > Am I the only one who wants to share a file from his own application? :) > > -- > anidel > Sent from London, Eng, United Kingdom > > > 2009/10/22 Aniello Del Sorbo : > >> Hi, >> >> I've seen the documentation about how to make your own sharing plugin [1]. >> >> Is there documentation on how to actually use them from our own application? >> >> [1] >> http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Using_Data_Sharing/Sharing_Plug-in >> >> -- >> anidel >> >> > ___ > 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: HildonAnimationActor and transparency
Hi Cornelius
I used the next solution:
pixbuf = gdk_pixbuf_new_from_file_at_size
("/usr/share/omweather/icons/Glance/dark_cloud.png",
128, 128, NULL);
image = gtk_image_new_from_pixbuf (pixbuf);
g_object_unref(G_OBJECT(pixbuf));
g_signal_connect(G_OBJECT(image), "expose_event",
G_CALLBACK(expose_event),
pixbuf)
ha = hildon_animation_actor_new();
gtk_container_add (GTK_CONTAINER (ha), image);
gboolean
expose_event (GtkWidget *widget,GdkEventExpose *event,
gpointer data)
{
cairo_t *cr;
GdkPixbuf *pixbuf = (GdkPixbuf *) data;
cr = gdk_cairo_create(widget->window);
gdk_cairo_region(cr, event->region);
cairo_set_operator(cr, CAIRO_OPERATOR_SOURCE);
gdk_cairo_set_source_pixbuf(cr, pixbuf, 0.0, 0.0);
cairo_paint(cr);
cairo_destroy(cr);
return TRUE;
}
BR,
Vlad.
Cornelius Hald wrote:
> Hi,
>
> yesterday I was playing around with HildonAnimationActor and it's really
> nice what you can do with it. But there are still some things, I don't
> really understand. Hopefully someone can help me with that :)
>
> I created a HildonAnimationActor and put a GtkImage, made from a ARGB
> png, onto it with gtk_container_add().
>
> The problem is, that the HildonAnimationActor has it's own background,
> so the transparent parts of the image show the background of the actor
> instead of the underlaying widget.
>
> I can use hildon_animation_actor_set_opacity() an the actor to make it
> transparent, but that affects the complete actor, so both, the actors
> background and the image become transparent.
>
> My question is: How do I make the background of the actor completely
> transparent without altering the transparency of the content of the
> actor?
>
> I really hope I don't have to go back to HildonRemoteTexture, because
> HildonAnimationActor is much nicer for my purpose.
>
> Thanks!
> Conny
>
>
> P.S. HildonAnimationActor is a GtkWindow, so maybe I should just try to
> remove the background of the window? I don't know how to do that, but I
> know it's possible. Would this be the way to go or is there a simpler
> way?
>
>
> ___
> 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
HildonAnimationActor and transparency
Hi, yesterday I was playing around with HildonAnimationActor and it's really nice what you can do with it. But there are still some things, I don't really understand. Hopefully someone can help me with that :) I created a HildonAnimationActor and put a GtkImage, made from a ARGB png, onto it with gtk_container_add(). The problem is, that the HildonAnimationActor has it's own background, so the transparent parts of the image show the background of the actor instead of the underlaying widget. I can use hildon_animation_actor_set_opacity() an the actor to make it transparent, but that affects the complete actor, so both, the actors background and the image become transparent. My question is: How do I make the background of the actor completely transparent without altering the transparency of the content of the actor? I really hope I don't have to go back to HildonRemoteTexture, because HildonAnimationActor is much nicer for my purpose. Thanks! Conny P.S. HildonAnimationActor is a GtkWindow, so maybe I should just try to remove the background of the window? I don't know how to do that, but I know it's possible. Would this be the way to go or is there a simpler way? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshot as loading screen on Maemo 5
Aniello Del Sorbo wrote: > But taking a snapshot slows down the startup... it should be then done > in a small thread? The hildon_gtk_window_take_screenshot function just sends a client message to the root window [1] , and the screenshot is taken by the window manager / hildon desktop (I guess). So, it does not take too long from the application itself, and a thread would make it only slower. BR, Henrik [1] http://maemo.gitorious.org/hildon/hildon/blobs/master/hildon/hildon-gtk.c#line463 -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshot as loading screen on Maemo 5
2009/10/23 Kimmo Hämäläinen : > > Yes, theme change, locale change, time change, restoring a backup (this > in hildon-desktop HEAD) all remove the screenshots. Cool. >> it's a good idea to check for the existence of the screenshot and >> recreate it if necessary. > > Now that the function is missing this argument (bad design). We should > add some API for creating the screenshot _only if_ it does not exist. > Because the place where the screenshot is stored, is not really public > information. Agreed. Can we assume that there'll be a short term update to ..._take_screenshot() to make it do this? Or will it be a new method? Or will it not be until the next (or next + 1) Maemo Update? There's no point special-casing this in our own code if the API is going to change in the next few weeks, and a change in a few months is of little benefit to the first batch of Fremantle applications :-) Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
