Application manager categories for Fremantle
Hi, I think it's time to define the Application manager categories for Fremantle. This has been done for Diablo here: http://wiki.maemo.org/Task:Package_categories and we should update that page to talk about Fremantle, too, or make a new one for Fremantle. [ Maybe this has been done already, and I just missed it... Apologies if that is the case. ] I feel that defining the list of categories is quite important and as long as I have something to say about this, I very much want to prevent Nokia and the Maemo community going into different directions with this. So, here is a concrete proposed addition to the categories for Fremantle that we would like to make: user/sharingSharing plugins Jussi, please elaborate if you think it is needed. My position is that unless this addition is approved by the Maemo community (via the Maemo council), I am not going to add it to the list of categories. Thanks everybody (and sorry again if I am too much out of date with what is actually happening in this area.) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo UI
Hubert Figuiere wrote: The real problem is that PDF is not a format for electronic books. Because it hardcodes paper size and layout, it is not independant of the media. PDF is a format for digital rendering of printouts. They've added to some relatively recent version of pdf format (5?) the possibility of reflowed PDFs to support ebooks. Not sure how well it works in reality. See http://www.adobe.com/uk/epaper/tips/acr5reflow/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application manager categories for Fremantle
On Tue, Jun 2, 2009 at 6:13 AM, Marius Vollmer marius.voll...@nokia.com wrote: I think it's time to define the Application manager categories for Fremantle. This has been done for Diablo here: http://wiki.maemo.org/Task:Package_categories and we should update that page to talk about Fremantle, too, or make a new one for Fremantle. Unfortunately we never got a chance to test and tweak our list in Diablo, so a Fremantle list might as well just be the same thing. . . . :( So, here is a concrete proposed addition to the categories for Fremantle that we would like to make: user/sharing Sharing plugins This has been discussed before, and my stance on it is: absolutely not. Aside from the fact that a sharing plugins category reeks of silly Nokia Ovi nonsense, it's also entirely incongruous with the rest of the categories. I have to get to work, but hopeful Andrew can elaborate more about why it's a bad idea. ;) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application manager categories for Fremantle
On Jun 2, 2009, at 12:13, Marius Vollmer wrote: Hi, I think it's time to define the Application manager categories for Fremantle. This has been done for Diablo here: http://wiki.maemo.org/Task:Package_categories Can we call this Application Categories? Since we are defining where applications go - not defining a category of package. and we should update that page to talk about Fremantle, too, or make a new one for Fremantle. http://wiki.maemo.org/Task:fremantle_application_categories I feel that defining the list of categories is quite important and as long as I have something to say about this, I very much want to prevent Nokia and the Maemo community going into different directions with this. I agree. So, here is a concrete proposed addition to the categories for Fremantle that we would like to make: user/sharingSharing plugins Jussi, please elaborate if you think it is needed. My position is that unless this addition is approved by the Maemo community (via the Maemo council), I am not going to add it to the list of categories. I too would like to get some feedback from the council on this since it will eventually go into Maemian and packages that do not follow the proposal will get a warning. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application manager categories for Fremantle
ext Jeremiah Foster jerem...@jeremiahfoster.com writes: I think it's time to define the Application manager categories for Fremantle. This has been done for Diablo here: http://wiki.maemo.org/Task:Package_categories Can we call this Application Categories? Since we are defining where applications go - not defining a category of package. Hmm, yeah, terminology. The tool itself, Application manager, is strictly speaking misnamed: add-on software does not need to be an application, of course. We also have themes, codecs, plugins, translations, games, etc. I was using Application manager categories since they are the categories displayed by the Application manager. But, I guess this is not _that_ important, and Application categories is fine as well. and we should update that page to talk about Fremantle, too, or make a new one for Fremantle. http://wiki.maemo.org/Task:fremantle_application_categories Thanks, I have botstrapped it with the Diablo list. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application manager categories for Fremantle
ext Ryan Abel rabe...@gmail.com writes: Unfortunately we never got a chance to test and tweak our list in Diablo, so a Fremantle list might as well just be the same thing. . . . :( Yes. Actually, does it make sense at all to have different lists for different major versions of the OS? So, here is a concrete proposed addition to the categories for Fremantle that we would like to make: user/sharing Sharing plugins This has been discussed before, [ Yes, I vaguely remember, but I couldn't find the links. ] and my stance on it is: absolutely not. [...] I'll make a new thread for this. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application manager categories for Fremantle
Am Dienstag, den 02.06.2009, 16:40 +0300 schrieb Marius Vollmer: This has been discussed before, [ Yes, I vaguely remember, but I couldn't find the links. ] https://bugs.maemo.org/show_bug.cgi?id=3844#c8 and NB#64. andre -- Andre Klapper (maemo.org bugmaster) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Proposed addition to Application categories: Sharing plugins
Hi, now that the task for defining the Fremantle Application Categories has started, we have the first proposal. http://wiki.maemo.org/Task:fremantle_application_categories Add Sharing plugins category The following category should be added: Key Example English i18nExample apps user/sharingSharing Plugins Plugins that add additional upload protocols to applications, such as for Flickr photo upload. I have added it to the Task page. Discuss! :-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application manager categories for Fremantle
i have always thought the categories you install software from on the device should more accurately represent the breakdown specified in maemo.orgdownloads (or vice versa) having 2 completely independent category lists seems fruitless and counter productive. (forgive me if they are already in sync, it never appeared so when i looked last time) gary On Tue, Jun 2, 2009 at 2:47 PM, Andre Klapper aklap...@openismus.comwrote: Am Dienstag, den 02.06.2009, 16:40 +0300 schrieb Marius Vollmer: This has been discussed before, [ Yes, I vaguely remember, but I couldn't find the links. ] https://bugs.maemo.org/show_bug.cgi?id=3844#c8 and NB#64. andre -- Andre Klapper (maemo.org bugmaster) ___ 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: Application manager categories for Fremantle
i have always thought the categories you install software from on the device should more accurately represent the breakdown specified in maemo.orgdownloads (or vice versa) having 2 completely independent category lists seems fruitless and counter productive. (forgive me if they are already in sync, it never appeared so when i looked last time) gary On Tue, Jun 2, 2009 at 2:47 PM, Andre Klapper aklap...@openismus.comwrote: Am Dienstag, den 02.06.2009, 16:40 +0300 schrieb Marius Vollmer: This has been discussed before, [ Yes, I vaguely remember, but I couldn't find the links. ] https://bugs.maemo.org/show_bug.cgi?id=3844#c8 and NB#64. andre -- Andre Klapper (maemo.org bugmaster) ___ 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: Application manager categories for Fremantle
ext Andre Klapper aklap...@openismus.com writes: Am Dienstag, den 02.06.2009, 16:40 +0300 schrieb Marius Vollmer: This has been discussed before, [ Yes, I vaguely remember, but I couldn't find the links. ] https://bugs.maemo.org/show_bug.cgi?id=3844#c8 and NB#64. Thanks! My Bugzilla Fu is weak... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
Murray Cumming wrote: On Fri, 2009-05-29 at 23:07 +0300, Henrik Hedberg wrote: However, usually developer should not need to know mode but Hildon widgets should adjust themselves as much as possible during the relayout. Unfortunately that seems not to be the case, as Conny demonstrated earlier with some screenshots. Yes, someone should file bugs about those standard dialogs. I just did. Here: https://bugs.maemo.org/show_bug.cgi?id=4618 Also I entered a bug for the toolbars: https://bugs.maemo.org/show_bug.cgi?id=4617 I hope it´s ok, I´m not very familiar with the bugzilla monster ;) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle user interface behaviour and API
Brent Chiodo wrote: Anyway, there needs to be a solution, because right now it's unworkable. I filled a bug: https://bugs.maemo.org/show_bug.cgi?id=4619 Hopefully someone will change that. Please vote for it! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
Am Dienstag, den 02.06.2009, 18:06 +0200 schrieb Cornelius Hald: https://bugs.maemo.org/show_bug.cgi?id=4618 https://bugs.maemo.org/show_bug.cgi?id=4617 I hope it´s ok, I´m not very familiar with the bugzilla monster ;) Seems like you successfully tamed Bugzilla, though I always love to see exact steps to reproduce (e.g. in order to reproduce the issue I wonder how to start Fremantle SDK beta in Portrait mode). ;-) andre -- Andre Klapper (maemo.org bugmaster) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
Andre Klapper wrote: Am Dienstag, den 02.06.2009, 18:06 +0200 schrieb Cornelius Hald: https://bugs.maemo.org/show_bug.cgi?id=4618 https://bugs.maemo.org/show_bug.cgi?id=4617 I hope it´s ok, I´m not very familiar with the bugzilla monster ;) Seems like you successfully tamed Bugzilla, though I always love to see exact steps to reproduce (e.g. in order to reproduce the issue I wonder how to start Fremantle SDK beta in Portrait mode). ;-) Ah well, that would be another bug report :P Easiest way is to just create the Xephyr window with -screen 480x800x16 instead of -screen 800x480x16 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposed addition to Application categories: Sharing plugins
Marius wrote: now that the task for defining the Fremantle Application Categories has started, we have the first proposal. The following category should be added: user/sharing Sharing Plugins Plugins that add additional upload protocols to applications, such as for Flickr photo upload. I don't like it, for the following reasons (in order of significance): 1) Plugins for a particular protocol or purpose should go under the appropriate category. If a user is looking for a photo upload thing, they should be trained to look in the appropriate category (e.g. user/graphics[1]). A Flickr upload *application* should be next to a Flickr upload widget, should be next to a Flickr upload applet, should be next to a Flickr upload *plugin*. 2) Alternatively, we'd have sub-categories allowing additions and enhancements for a particular application are found *under* that app. 3) Why limit the description and facilitation to *upload* protocols? Sharing is a two-way process. 4) This semms primarily an Ovi-marketing move where brands are considered more important than end-user experience. Cheers, Andrew [1] DHCP struggling at JavaOne (again) so can't check what the most appropriate category actually is. -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Fremantle OpenGL wrapper?
Hi all, I'm not much of a developer, but I really think it would be a good idea to get a couple OpenGL wrappers ready for Fremantle. I have a thread on talk.maemo.org[1], but maybe I should be posting here too. [1] http://talk.maemo.org/showthread.php?t=29085 I think there should be a wrapper for applications that use OpenGL directly, and maybe an SDL library for games that use OpenGL via SDL. There's work in this area for the Pandora, but I haven't seen much yet for Maemo devices. I propose starting with a simple test game like Armagetron Advanced [2], which actually runs on an N800 at 3 fps with software OpenGL rendering. This game uses SDL and the mesa GL libraries, which suggests that an SDL library like the one developed for the Pandora [3] might work here. [2] http://packages.debian.org/lenny/armagetronad [3] http://www.gp32x.com/board/index.php?showtopic=48023 Like I said, I'm not really a developer, and I can't really take these ideas and make them happen. But I'm paying close enough attention to these things to see that this seems to be an important gap in the available software right now. I would prefer comments on my talk.maemo.org thread, but you can discuss here, too. -- enthusiast, n. One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
Hi, this mail got a bit longer then I expected. I added some ideas how the UI could react to orientation changes. Those are only ideas and I know that it´s too late to implement/change all this. Also I´m aware that there might be different opinions ;) I just had to get this of my chest. Maybe it will at least evolve into a fruitful discussion :) Alberto Garcia wrote: 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. I think most people who use filters and the portrait mode will have to create a different version of the menu for portrait mode. In my opinion there is just not enough space to put them in one row. From the hildon HIG HIG[1]: Filters should be presented in groups. For example, if the menu should allow the user to sort a list of messages alphabetically, the filters present should be at least a sort alphabetically filter and a sort by date. Well, first it´s not possible to present filters without a group, so the first sentence doesn't really make sense ;) and (more important) second: The example filter should have _at least_ sort alphabetically and sort by date. I cannot check right now, but I doubt that those two strings fit into the filter group in portrait mode. And even if they do, how does it look with non-english strings like Alphabetisch sortieren and Nach Datum sortieren?! Maybe you should check again if the filter UI really makes sense at the moment. I know it looks cool, but that doesn't help much if later no one can use it. 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). Hmm... Well, I think the toolkit should do as much as possible for the developer. If the developer wants to override all this magical stuff, then there surely should be a way to do so. I have a couple of ideas how to do this. I have no idea how the relation between Hildon and Maemo-Gtk is, so I don´t know how feasible my suggestion are. Basically I was thinking that Hildon and Maemo-Gtk is one project and the word hildon is more or less just used to introduce API which does not exist in pure Gtk... But anyways, here are some ideas how to embrace the portrait mode a bit more and make the life for application developers easier. 1a) Introduce some kind of important property for widgets. Using this, I could mark some of my buttons as important and thus the UI would make sure that they are shown even in portrait mode. Buttons or widgets without that flag could be omitted or put into a sub menu if there is not enough space. Using this mechanism I also could mark one of my table view column as important. The other column could be omitted. 1b) If a property like important is too generic/vague then how about a portrait and landscape property. This way I still would have the complete control over which widget are shown when and I would have to thing about portrait and landscape mode, but at least I wouldn´t clutter my code with lots of if (portrait_mode) statements... 1c) Or how about that: Landscape mode is always edit mode and portrait mode is always view mode. In this way the application developer would get a big hint on which buttons/widget should be shown. I surely don´t need a change font style button if I´m in the view mode. Using this distinction it would also be possible to change the behavior of other widgets in a meaning full way. For example the text view could change from being editable/selectable with the fingers in edit mode to being pannable in view mode. 2a) Menus: Why not leaving the GtkMenu API like it is, but draw it like the AppMenu? It could still be hierarchically. If I press a button which opens a new sub menu, this sub menu just slided over the current menu and. That way all applications could use a finger friendly menu which using new API. If there are too many (more then 10) menu item, then just show scroll buttons like in the Diablo start menu. If there are GtkRadioMenuItems in that menu they could automatically be shown as Filters and so on... Of course very long menus or menus with deep hierarchies would still be annoying for the end users, but they can be changed over time to make it a pleasant experience. IMO it still would be a much better experience then giving the user a device where every second application still has those ugly stylus menus. 2b) Toolbars: Automatically distribute all buttons on the toolbar evenly over the available space. In this
Re: Application manager categories for Fremantle
On Tue, 2009-06-02 at 08:46 -0400, Ryan Abel wrote: On Tue, Jun 2, 2009 at 6:13 AM, Marius Vollmer marius.voll...@nokia.com wrote: user/sharingSharing plugins This has been discussed before, and my stance on it is: absolutely not. Aside from the fact that a sharing plugins category reeks of silly Nokia Ovi nonsense, it's also entirely incongruous with the rest of the categories. I have to get to work, but hopeful Andrew can elaborate more about why it's a bad idea. ;) I also don't understand why sharing plugins is necessary. Simply plugins is a different matter. I'd estimate one third to one half of the entries in the AM are actually plugins of one sort or the other. Canola plugins, mediabox plugins, claws-mail plugins, pidgin plugins, Battle of Wesnoth plugins. Need I go on? On a related note, packagers are doing a good job of not putting libraries in user/whatever (so they do not appear in blue pill mode), but we still do have some libwhatever packages in the list. It would be good to make sure the same thing isn't happening in fremantle. Joseph Charpak jchar...@worldnet.att.net ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Questions about HildonPannableArea
Hi, i really like the kinetic scrolling aka HildonPannableArea and the maemo weekend allowed me to test it on the real thing (which unlike to the xephir and the beagleboard actually gives some semi-fluid kinetic behaviour). But i have a problem with certain widgets inside the area. GtkTextAreas don't work well since they use the screen tap for markup. Setting them insensitive works, but also makes them visibly insensitive (read: black letters on very dark ground). What's the correct way to configure a GtkTextView to be placed inside a HildonPannableArea? It's worse with a GtkHtml widget. It doesn't even work correctly when being made insensitive. The kinetic scrolling is stuttering and especially the overshots aren't fluid but jump around instead. Both of these work well inside a GtkScrolledWindow. Are there any instructions how to use these with the HildonPannableArea? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Questions about HildonPannableArea
On Tue, 2009-06-02 at 20:47 +0200, Till Harbaum / Lists wrote: But i have a problem with certain widgets inside the area. GtkTextAreas don't work well since they use the screen tap for markup. Setting them insensitive works, but also makes them visibly insensitive (read: black letters on very dark ground). What's the correct way to configure a GtkTextView to be placed inside a HildonPannableArea? You can use HildonTextView inside the HildonPannableArea. It works mostly as expected only you loose the possibility to select text with finger/stylus/mouse. With GtkHtml I don't know how to fix it. Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Fremantle OpenGL wrapper?
From: maemo-developers-boun...@maemo.org [maemo-developers-boun...@maemo.org] On Behalf Of ext Qole [qole.tab...@gmail.com] Sent: Tuesday, June 02, 2009 9:05 PM To: maemo-developers Subject: Fremantle OpenGL wrapper? Hi all, I'm not much of a developer, but I really think it would be a good idea to get a couple OpenGL wrappers ready for Fremantle. What do you like the wrapper do ? If you like to get easiest way to run OpenGL you can take example skeleton from Imagination OpenGL-ES2.0 examples. They run in Fremantle, you just need to compile them or then you can take Qt GLWidget as it is done in hellogl_es2 that is part of Qt4.5 source. I also runs nicely in Fremantle. Good thing using Qt as a wrapper is that you can use full GL but you can mix it with Qt UI widgets or QGraphicsWiew higer level drawing primitives. Kate I have a thread on talk.maemo.orghttp://talk.maemo.org[1], but maybe I should be posting here too. [1] http://talk.maemo.org/showthread.php?t=29085 I think there should be a wrapper for applications that use OpenGL directly, and maybe an SDL library for games that use OpenGL via SDL. There's work in this area for the Pandora, but I haven't seen much yet for Maemo devices. I propose starting with a simple test game like Armagetron Advanced [2], which actually runs on an N800 at 3 fps with software OpenGL rendering. This game uses SDL and the mesa GL libraries, which suggests that an SDL library like the one developed for the Pandora [3] might work here. [2] http://packages.debian.org/lenny/armagetronad [3] http://www.gp32x.com/board/index.php?showtopic=48023 Like I said, I'm not really a developer, and I can't really take these ideas and make them happen. But I'm paying close enough attention to these things to see that this seems to be an important gap in the available software right now. I would prefer comments on my talk.maemo.orghttp://talk.maemo.org thread, but you can discuss here, too. -- enthusiast, n. One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
fremantle gettext version too old
Hi; I just installed the fremantle beta SDK to port an application of mine to maemo 5. I ran into a problem though, since the gettext version (0.14.1) that comes with it is too old. The app is a port of a Gnome app that uses msgctxt in its po files; building it in the scratchbox stops with an error like this: Making all in po ../../../po/de.po:1064: keyword msgctxt unknown [etc] Would it be possible to ship fremantle final with a gettext version that supports msgctxt, so that one can build this app without first locally installing a newer gettext in the scratchbox? gettext 0.15 is the first version that supports this, but of course using the latest (0.17) would be preferable. Regards, Christian ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Fremantle OpenGL wrapper?
On Tue, Jun 2, 2009 at 1:14 PM, kate.alh...@nokia.com wrote: From: maemo-developers-boun...@maemo.org [ maemo-developers-boun...@maemo.org] On Behalf Of ext Qole [ qole.tab...@gmail.com] Sent: Tuesday, June 02, 2009 9:05 PM To: maemo-developers Subject: Fremantle OpenGL wrapper? Hi all, I'm not much of a developer, but I really think it would be a good idea to get a couple OpenGL wrappers ready for Fremantle. What do you like the wrapper do ? If you like to get easiest way to run OpenGL you can take example skeleton from Imagination OpenGL-ES2.0 examples. They run in Fremantle, you just need to compile them or then you can take Qt GLWidget as it is done in hellogl_es2 that is part of Qt4.5 source. I also runs nicely in Fremantle. Good thing using Qt as a wrapper is that you can use full GL but you can mix it with Qt UI widgets or QGraphicsWiew higer level drawing primitives. Kate I am asking for a wrapper that will make it possible to port existing OpenGL applications (mainly games) to Maemo 5+ without having to do any real rewriting. I gave an example in my e-mail of an SDL game that uses OpenGL. If your solutions will allow someone to port a game like Armagetron Advanced without much effort, then that is what I'm looking for. If this means rewriting the game / application, then that's not what I'm asking for. A good way to know if your solution is what I'm looking for is to take the Debian Lenny source code of Armagetron Advanced ( http://packages.debian.org/source/lenny/armagetronad) and make a Qt / Imagination wrapper for it, then compile it to run on Fremantle. If this takes a very long time, then this isn't what I'm looking for. I'm looking for something that would be a drop-in replacement for the OpenGL libraries for games like Quake2 or SDL games like Armagetron. You may think, these aren't important, they're only games, but I would disagree. And I'm not even a gamer. -- enthusiast, n. One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
On Tue, Jun 2, 2009 at 3:04 PM, David Greaves da...@dgreaves.com wrote: I understood that GL wasn't going to be available to the apps on the device... something about the window manager permanently taking the only viewport? I am not sure if this is a beta-phase bug or a hardware or GLES issue. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... I think you are referring to the following two posts, both by Kimmo Hämäläinen. I don't believe they say that GL won't be available, but that there will be a performance hit because the apps will have to go through Hildon-Desktop to render, rather than rendering directly. http://lists.maemo.org/pipermail/maemo-developers/2009-March/018639.html As Kate has already proven, multi-context works. But as long as you have hildon-desktop running in the background, you will not render directly to the screen even if you use Clutter/QtGraphicsView/EGL+OpenGLES2.0/whatnot in your application. When hildon-desktop is running, it is the only one drawing on the screen (with the exception of XVideo). So, killing hildon-desktop is the only way to get direct rendering to the screen at the moment. (We might have something more elegant for this in the future...) http://lists.maemo.org/pipermail/maemo-developers/2009-March/018645.html Keeping the compositor around has some performance impact, because after the application draws to an offscreen pixmap (the window), the X server sends Damage events (saying this part of the pixmap changed) to hildon-desktop, and hildon-desktop asks the 3D HW to use this pixmap in a OpenGL texture and draw it to the screen. So, there is some extra delay (maybe 10-25ms) after the application's drawing is visible. Second implication is that you cannot use HW accelerated zooming and moving of textures for the whole graphical pipeline. You can use it for drawing into your window, but when hildon-desktop draws to the screen, it cannot use it (e.g. it cannot say move this content to there). It will just get a big damage area that is updated by updating the OpenGL texture content. Third implication: to save memory, we are using the texture-from-pixmap GL extension to allow the X server and 3D HW share the pixmap data. This means that while 3D HW is accessing the pixmap data (while transferring it to the 3D chip), X server cannot access it. Thus, while the compositor is updating the screen, it is slowing down X drawing. However, it's not mandatory to use texture-from-pixmap, but then you are paying the price in increased RAM usage. -- enthusiast, n. One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application manager categories for Fremantle
On Tue, Jun 2, 2009 at 2:42 PM, Joseph Charpak jchar...@worldnet.att.net wrote: On a related note, packagers are doing a good job of not putting libraries in user/whatever (so they do not appear in blue pill mode), but we still do have some libwhatever packages in the list. It would be good to make sure the same thing isn't happening in fremantle. My plan was to blitz the packagers once the new package categories were shipped with h-a-m, but since this never happened (and maybe never will) the plan is sort of sitting in limbo at the moment. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
Hi, On Wed, 2009-06-03 at 00:53 +0200, ext Qole wrote: On Tue, Jun 2, 2009 at 3:04 PM, David Greaves da...@dgreaves.com wrote: I understood that GL wasn't going to be available to the apps on the device... something about the window manager permanently taking the only viewport? I am not sure if this is a beta-phase bug or a hardware or GLES issue. David -- Don't worry, you'll be fine; I saw it work in a cartoon once... I think you are referring to the following two posts, both by Kimmo Hämäläinen. I don't believe they say that GL won't be available, but that there will be a performance hit OpenGL is not available in the device but OpenGL ES2 is. Notice that this is a big problem when porting OpenGL applications from the desktop PC world. Some kind of OpenGL to OpenGLES conversion layers are possible but with some FPS cost, I assume. because the apps will have to go through Hildon-Desktop to render, rather than rendering directly. Yes, about 30% penalty with the compositor, but I'm working on non- composited or game mode for hildon-desktop that allows shutting down the compositor and rendering directly to the screen (without killing hildon-desktop). I still need to get it working with dialogs and menus popping on top of the non-composited application, but I guess it'll work in the end somehow. BR; Kimmo http://lists.maemo.org/pipermail/maemo-developers/2009- March/018639.html As Kate has already proven, multi-context works. But as long as you have hildon-desktop running in the background, you will not render directly to the screen even if you use Clutter/QtGraphicsView/EGL+OpenGLES2.0/whatnot in your application. When hildon-desktop is running, it is the only one drawing on the screen (with the exception of XVideo). So, killing hildon-desktop is the only way to get direct rendering to the screen at the moment. (We might have something more elegant for this in the future...) http://lists.maemo.org/pipermail/maemo-developers/2009- March/018645.html Keeping the compositor around has some performance impact, because after the application draws to an offscreen pixmap (the window), the X server sends Damage events (saying this part of the pixmap changed) to hildon-desktop, and hildon-desktop asks the 3D HW to use this pixmap in a OpenGL texture and draw it to the screen. So, there is some extra delay (maybe 10-25ms) after the application's drawing is visible. Second implication is that you cannot use HW accelerated zooming and moving of textures for the whole graphical pipeline. You can use it for drawing into your window, but when hildon-desktop draws to the screen, it cannot use it (e.g. it cannot say move this content to there). It will just get a big damage area that is updated by updating the OpenGL texture content. Third implication: to save memory, we are using the texture- from-pixmap GL extension to allow the X server and 3D HW share the pixmap data. This means that while 3D HW is accessing the pixmap data (while transferring it to the 3D chip), X server cannot access it. Thus, while the compositor is updating the screen, it is slowing down X drawing. However, it's not mandatory to use texture-from-pixmap, but then you are paying the price in increased RAM usage. -- enthusiast, n. One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
