gtk clutter tearing
Hi, I have made a simple animation using a clutter timeline with clutter-gtk-0.10 and clutter-1.0 but there is excessive tearing when the animation plays making the animation look terrible. I have tried none, dri and glx values for the CLUTTER_VBLANK environment variable but this seems to have no effect at all. Is there a way to fix this? Thanks Mark.___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Smalltalk developers on N900.
On Mon, 2009-12-28 at 18:36 -0500, Joseph Charpak wrote: On Mon, 2009-12-28 at 15:55 -0500, Aldon Hynes wrote: I've kicked around trying to get Logo running as well as thinking about other languages. I'm interested in Ada on the devices. It looks like progress is being made on the Debian for ARMEL front, so hopefully we'll see something sooner rather than later. Hi, GCC 4.4 and 4.5 support Ada on armel-linux : you just need a small patch to enable Ada and of course to download preexisting binary compiler, see URL below. http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00450.html Exception model with this patch is still setjump/longjump not yet following GNU EABI. GCC Ada testsuites results are currently clean: http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02442.html === acats Summary === # of expected passes2321 # of unexpected failures0 === gnat Summary === # of expected passes748 # of expected failures 8 # of unsupported tests 1 Laurent http://guerby.org/blog ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo AutoBuilder - maemo-optify issue [broken]
ext Nathan Anderson nat...@andersonsplace.net writes: It appears that maemo-optify doesn't work (not sure where the --auto came from) doesn't work on the diablo builder. Looks like maemo-optify in Diablo is too old. It shouldn't be there at all, I think, but it's better to keep it up-to-date, so I have updated it. If we ever change the default for --auto, we should be careful to do it only for Fremantle, somehow. I'll put some comments into the code, and maybe a skeleton to make it easy to do the right thing when the time comes. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
New optification issues in extras-testing
Hi, i have just been instructed to reduce the size of osm2go _incl._ its depending libraries to under 500k: http://maemo.org/midcom-permalink-fd66da42f17511dea9eb9b28404387138 Guys, i really hate the fact that you come up with new rules every three days. I have already had complains about doesn't look nice enough, won't run on maemo6 and now this. Please either a) make the all-libs-together-have-to-stay-under-500k an explicit rule for extras and i'll consider following that rule, or b) just delete that thumbs-down if it's not appropriate and make clear that it's not required that all components together stay under 500k Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, sorry, the link was truncated. I am talking about: http://maemo.org/midcom-permalink-fd66da42f17511dea9eb9b28404387138713 Additional info: There already is a version in extras that is exceeding these new limits. The new version fixes some bugs. So the new version gives no disadvantage over the version currently in extras. Delaying it just prevents the bug fixes to reach the end users. Till Am Dienstag 29 Dezember 2009 schrieb Till Harbaum / Lists: Hi, i have just been instructed to reduce the size of osm2go _incl._ its depending libraries to under 500k: http://maemo.org/midcom-permalink-fd66da42f17511dea9eb9b28404387138 Guys, i really hate the fact that you come up with new rules every three days. I have already had complains about doesn't look nice enough, won't run on maemo6 and now this. Please either a) make the all-libs-together-have-to-stay-under-500k an explicit rule for extras and i'll consider following that rule, or b) just delete that thumbs-down if it's not appropriate and make clear that it's not required that all components together stay under 500k Till ___ 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: New optification issues in extras-testing
Am Dienstag, den 29.12.2009, 13:18 +0100 schrieb Till Harbaum / Lists: http://maemo.org/midcom-permalink-fd66da42f17511dea9eb9b28404387138 Error 404: Page could not be found. Probably https://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_armel/osm2go/0.8.1-maemo1/ Guys, i really hate the fact that you come up with new rules every three days. Who exactly is you in your sentence? According to the ChangeLog, 500k has been listed at http://wiki.maemo.org/Extras-testing/QA_Checklist since Oct 22nd, 2009. Maybe you meant two months instead of three days? andre -- Andre Klapper (maemo.org bugmaster) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, the page you are referring to says: The application or its dependencies ignore the recommendation to use the eMMC to install as much files as possible, filling the root partition with 500kb or more. It does not say that the _sum_ of all dependencies has to be below 500k. This rule that the sum of all components also has to stay below a certain limit is new. Osm2go is below 500k and so is the goocanvas it depends on. Now this guy is talking about the fact that the sum is over 500k. Till Am Dienstag 29 Dezember 2009 schrieb Andre Klapper: Am Dienstag, den 29.12.2009, 13:18 +0100 schrieb Till Harbaum / Lists: http://maemo.org/midcom-permalink-fd66da42f17511dea9eb9b28404387138 Error 404: Page could not be found. Probably https://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_armel/osm2go/0.8.1-maemo1/ Guys, i really hate the fact that you come up with new rules every three days. Who exactly is you in your sentence? According to the ChangeLog, 500k has been listed at http://wiki.maemo.org/Extras-testing/QA_Checklist since Oct 22nd, 2009. Maybe you meant two months instead of three days? andre ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [SyncEvolution] SyncEvolution in Fremantle
Hi! This is becoming more SyncEvolution specific. Should we continue cross-posting to maemo-developers? On Sat, 2009-12-26 at 13:53 +, Ove Kaaven wrote: Patrick Ohly skrev: I was planning to do a 0.9.2 update release in a few weeks. Should we merge your code and include the Maemo support in the release announcement? If you want. It's your call. Given that you raised some questions below about improvements which cannot be done in backwards-compatible way between releases of the calendar backend (change tracking!), it might be better to give it some more time and release with 1.0 (tentative goal: end of March). Is the debian/ dir in the sources maintained, anyway? Not at the moment. It was used exclusively for the Maemo .deb, so feel free to modify it. It's not clear from the website whether this Linux Foundation license agreement is really to be sent to the moblin guys, or to some other address. My reading is that it needs to go to the Linux Foundation. I'll check. (Presumably, syncevolution isn't part of moblin.) Correct. On Thu, 2009-12-24 at 08:03 +, Ove Kaaven wrote: via the Maemo-Calendar backend which I've spent the last two days writing I'm glad to hear that you got this working without too much effort. Any suggestions about improving the available documentation to make backend development easier? Not sure. I did find all the sync source stuff a bit confusing and badly documented. I was hoping that TrackingSyncSource.h had enough information to be useful, but you are right, it doesn't explain the big picture. A more general introduction of source, item, etc. would be needed. Time to resurrect Doxygen and write some additional pages, I suppose. Would that have helped? Especially since it's been years since I last programmed C++ (I had started to agree with the C++ detractors, it's a *really* messy language, and it still remains the case that any C++ framework you didn't design yourself can be quite difficult to get into). IMHO *any* framework is difficult to start with, regardless of the language :-/ I can't quite recall exactly what confused me the most as I wrote the backend, but there are still a few things I'm unsure of: - I'm not sure how to properly write those integration tests in the *Register.cpp I can add those when merging the code. - Do I need to worry about getSupportedTypes() or anything You only need to implement the pure virtual methods, everything else has reasonable defaults. getSupportedTypes() is legacy code which was inherited from the Funambol library. It became obsolete when moving to libsynthesis and is already removed on master (well, almost - just found a copy of it in a derived class). Funambol required that sources deal with data conversion themselves, whereas with Synthesis this is done by the engine. - The Maemo's calendar-backend can return entries that have changed after a particular date (typically you'd use the time of the previous sync). Is there a way to use this to improve on the TrackingSyncSource method, so it won't be necessary to load and generate revision strings for the whole database every time? As Congwu said, this can be done by inheriting from SyncSource directly and adding the SyncSource* building blocks that you want to reuse. You can use the TrackingSyncSource as an example how that is done. The time of last sync is something that could be stored either in an internal source property or (better) in the SyncML anchor string, handled by the Synthesis engine. However, this will require changes to the Synthesis/SyncEvolution and SyncSource interfaces. We have to work on this anyway for resume support in the SyncML server, so my suggestion is to address this in 1.0 like this: * make those API changes * create a new DateSyncSource which requires the following information from derived classes: * complete list of all local item IDs * list of changed item IDs since a certain time * change FileSyncSource so that it is derived from DateSyncSource Do you have easy access to all IDs of existing items? This is necessary to detect deleted items. - The Maemo addressbook (which is still ebook-based), as well as the calendar (which has APIs to convert to vcal 1.0 and ical 2.0), Do you have a pointer to these APIs and perhaps the underlying source code? I'm curious how the vCalendar 1.0 support is done. stores some non-standard fields. I noticed something on the SyncEvolution webpage about mimeprofiles to specify what fields are stored locally. Is there a way to specify that, so that these fields are not destroyed on the Maemo device when syncing with a server that doesn't support them, even though the backends do convert from/to the standard vcard and ical formats? This is already possible, but we aren't sure yet how to maintain the different profiles. Right now, src/syncclient_sample_config.xml contains a contacts field
Re: New optification issues in extras-testing
On Tuesday 29 December 2009 14:01:40 Till Harbaum / Lists wrote: This rule that the sum of all components also has to stay below a certain limit is new. Osm2go is below 500k and so is the goocanvas it depends on. Now this guy is talking about the fact that the sum is over 500k. Any limit that includes dependencies will simply not work as there is no guarantee (except with the rare exception where the developer is maintainer of ALL the dependencies as well) what amount of space will be used on the NAND. Different versions might have different optification rules, they might grow or shrink, include additional dependencies of their own, etc. A source of misunderstanding might be the wording of the requirement: The application or its dependencies ignore the recommendation to use the eMMC to install as much files as possible, filling the root partition with 500kb or more. I can see how this can be interpreted both ways - both total and per package. As IMHO there is no point in the former (see above), and if there is a consensus about this it should perhaps be corrected that the per-package context of the 500K is clear(er). A broader question is if the 500K as a *number* should be part of the blocker paragraph. AFAIK the 500K is a guideline (unless 'encouraged' became a synonym with 'required'), what we are (supposed to be ?) looking at here is the general principle of avoiding *unnecessarily* wasting resources. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
On Tue, Dec 29, 2009 at 13:01, Till Harbaum / Lists li...@harbaum.org wrote: the page you are referring to says: The application or its dependencies ignore the recommendation to use the eMMC to install as much files as possible, filling the root partition with 500kb or more. It does not say that the _sum_ of all dependencies has to be below 500k. I agree, it looks ambiguous. The *intent* seems to be that installing an application shouldn't take up more than 500KB of the rootfs (your Python example on the package page is specious, BTW, as Python is now optified). If the dependencies are used by lots of apps, and have separate maintainers; I can understand your point. However, since: * you maintain both libgoocanvas3 and osm2go * neither are optified (according to the comments) * I *imagine* there aren't lots of other apps depending on libgoocanvas3 which have been let through QA ...this would seem to fall on to your shoulders. The STRONG recommendation is that EVERYTHING is optified, and getting pedantic about the numbers when you control both halves of the application stack seems a little churlish. After all, someone wanting to be difficult could split their app into 500 2KB packages which depend on each other :-) Now, on to solving the problem, have you tried putting auto in debian/optify? If so, did both packages continue to work after being auto-optified by the builder (or maemo-build-deb in Scratchbox, if you prefer). The intention is that they *should* (which is why 'auto' will become the default at some point in the future). Hope that helps, 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: New optification issues in extras-testing
ext Attila Csipa ma...@csipa.in.rs writes: A broader question is if the 500K as a *number* should be part of the blocker paragraph. [...] I think the only sane thing to do is to look at the ratio of files in /opt to those not in /opt, and require that ratio to be at least the same as the ratio of the space in /opt to the one in /. Maemo-optify could be changed to move as many files into /opt as needed to meet this requirement, starting from the biggest. It's on my todo list... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
On Tuesday 29 December 2009 11:03:01 Marius Vollmer wrote:
ext Attila Csipa ma...@csipa.in.rs writes:
A broader question is if the 500K as a *number* should be part of the
blocker paragraph. [...]
I think the only sane thing to do is to look at the ratio of files in
/opt to those not in /opt, and require that ratio to be at least the
same as the ratio of the space in /opt to the one in /.
Maemo-optify could be changed to move as many files into /opt as needed
to meet this requirement, starting from the biggest. It's on my todo
list...
I don't understand why maemo-optify doesn't just move *everything* to /opt,
including files under 2k etc. What advantage does it give to not have them in
/opt? For instance, I ran into this problem with asterisk where it had many
small sound files which still put 600k on the NAND.
-} elsif ($size = 2048) {
+} elsif ($size = 0) {
...
In sum, what is the upside of including anything but symlinks on the NAND?
IMHO, it should punt everything to /opt as long as it is needed at all.
Thanks for maemo-optify, it makes things so much lazier^H^H...easier. :)
-Jeff
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, ext Andrew Flegg wrote: The application or its dependencies ignore the recommendation to use the eMMC to install as much files as possible, filling the root partition with 500kb or more. It does not say that the _sum_ of all dependencies has to be below 500k. I agree, it looks ambiguous. The *intent* seems to be that installing an application shouldn't take up more than 500KB of the rootfs (your Python example on the package page is specious, BTW, as Python is now optified). If the dependencies are used by lots of apps, and have separate maintainers; I can understand your point. However, since: * you maintain both libgoocanvas3 and osm2go * neither are optified (according to the comments) * I *imagine* there aren't lots of other apps depending on libgoocanvas3 which have been let through QA Where this 500kB figure for these packages come from? If it's uncompressed size, then it's bogus as the rootfs is compressed. The script attachment here: https://bugs.maemo.org/show_bug.cgi?id=5795 Tries to give a more realistic[1] estimate on how much space a package actually takes from the rootfs. - Eero [1] Note that the documentation is removed with an apt hook. If one installs package directly with dpkg to the device, this hook doesn't get called. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Jeff Moe on 12/29/2009 08:20 AM wrote:
I don't understand why maemo-optify doesn't just move*everything* to /opt,
including files under 2k etc. What advantage does it give to not have them in
/opt? For instance, I ran into this problem with asterisk where it had many
small sound files which still put 600k on the NAND.
-} elsif ($size= 2048) {
+} elsif ($size= 0) {
Submit a patch to maemo-optify[1]. This is a must. Only kernel/Nokia
libraries should be on the rootfs. With so little space, there is no
reason for any end-user or commercial generated content to be on the rootfs.
[1] http://gitorious.org/+maemo-af-developers
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
Hi, ext Mark Clarkson wrote: I have made a simple animation using a clutter timeline with clutter-gtk-0.10 and clutter-1.0 but there is excessive tearing when the animation plays making the animation look terrible. I have tried none, dri and glx values for the CLUTTER_VBLANK environment variable but this seems to have no effect at all. Is there a way to fix this? Screen update isn't yet synched to LCD refresh. Please file a bug about it to bugs.maemo.org (it needs support from kernel display driver, X server, SGX driver, Clutter and hildon-desktop compositor, but I guess you could file it against Official platform - Core - X). After this I think things should look fine in Clutter when app does things right. E.g. panning in normal applications can still tear though because Gtk doesn't have any support for Vsync. This is not really fixable due to how Gtk painting is arranged, parts of the window are painted in application callbacks. If application callback is fast enough that it gets into same boxed damage event from X server (to compositor) as the internal Gtk pannable area scroll, there's no tearing, if it gets drawn later, then update for that part of the window goes to screen on next compositor screen update. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hallo! In sum, what is the upside of including anything but symlinks on the NAND? IMHO, it should punt everything to /opt as long as it is needed at all. Thanks for maemo-optify, it makes things so much lazier^H^H...easier. :) Symlinks take space on disk, too. I'm not sure if they take a whole block or a part of it but there is likely a limit where a links costs more space than the data itself. Is this where the 2K come from? We also should keep care that we do not run out of inodes (which IMHO should not be a problem if we replace the real file with a link because that does/should not increase the amount of inodes). -- Gruß... Tim. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
On Tue, 2009-12-29 at 16:57 +0100, ext Tim Teulings wrote: Hallo! In sum, what is the upside of including anything but symlinks on the NAND? IMHO, it should punt everything to /opt as long as it is needed at all. Thanks for maemo-optify, it makes things so much lazier^H^H...easier. :) Symlinks take space on disk, too. I'm not sure if they take a whole block or a part of it but there is likely a limit where a links costs more space than the data itself. Is this where the 2K come from? Perhaps it's the time to symlink directories ? ;-) Cheers, -- Senior Software Engineer Maemo Software ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
On Tuesday 29 December 2009 13:07:36 Mohammed Hassan wrote: On Tue, 2009-12-29 at 16:57 +0100, ext Tim Teulings wrote: Hallo! In sum, what is the upside of including anything but symlinks on the NAND? IMHO, it should punt everything to /opt as long as it is needed at all. Thanks for maemo-optify, it makes things so much lazier^H^H...easier. :) Symlinks take space on disk, too. I'm not sure if they take a whole block or a part of it but there is likely a limit where a links costs more space than the data itself. Is this where the 2K come from? I didn't check for sure, but I don't think symlinks take anywhere near 2k. Perhaps it's the time to symlink directories ? ;-) ln -s /opt/etc /etc/opt http://www.pathname.com/fhs/pub/fhs-2.3.html#ETCOPTCONFIGURATIONFILESFOROPT But a bit OT. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Jeff Moe on 12/29/2009 08:20 AM wrote: Symlinks take space on disk, too. I'm not sure if they take a whole block or a part of it but there is likely a limit where a links costs more space than the data itself. Is this where the 2K come from? An inode on the default file system is only 256 bytes. Ext was optimized for small files and fast symlinks. We also should keep care that we do not run out of inodes (which IMHO should not be a problem if we replace the real file with a link because that does/should not increase the amount of inodes). With only 2 gigs of space by default, you are not going to run out of inodes. This discussion should have been long ago prior to Maemo 5's release and not now. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
- Original message - Is there a way to fix this? Screen update isn't yet synched to LCD refresh. Please file a bug about it to bugs.maemo.org (it needs support from kernel display driver, X server, SGX driver, Clutter and hildon-desktop compositor, but I guess you could file it against Official platform - Core - X). I just tried the Bounce Evolution game and that synchs perfectly so I guess this means full screen OpenGL works fine (as it does with general transition effects). Does this mean that full screen clutter will work well too? Would the Qt 4.6 Animation Framework work smoothly non-fullscreen? What are the chances of this 'bug' being a high priority and getting fixed soon? I guess that smooth non-fullscreen animation is something many developers would want and end-users would expect to see. I'll get off and file this bug... Cheers Mark ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to change button shape?
Hi Till, How can i influence the shape of such buttons explicitely? I don't think you can influence the shape explicitly. This is done completely via Gtk theming. The theming is defined here: /usr/share/themes/default/gtk-2.0/gtkrc If you look for example for fremantle-button-group-box you will find a style which defines those toggle buttons which are only rounded at the outer left and right button. There is the GtkStyle API with which you can apply a defined style to a specific widget. It's rather cumbersome, but it might work for you. If you're still interested, I can dig up some code where I used this API. Cheers! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
Eero Tamminen on 12/29/2009 09:17 AM wrote: because Gtk doesn't have any support for Vsync. Gtk doesn't need to support Vsync. Qt won't magically fix this problem either. Only the compositor needs to support Vsync. Once it does then *all* 2D operations will be tear-free. Gtk, Qt, terminal-based, etc. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi,
it's likely wait too late for such a question, but why doesn't just /opt/bin,
/opt/share etc exist with the system looking into those paths as well?
Noone would have to care about optification then, no symlinks would
be required and most packages could just be optified by configure
--prefix=/opt.
I must be missing a very obvious thing that makes the current solution
better/nicer/whatever.
Till
Am Dienstag 29 Dezember 2009 schrieb Michael Cronenworth:
Jeff Moe on 12/29/2009 08:20 AM wrote:
I don't understand why maemo-optify doesn't just move*everything* to /opt,
including files under 2k etc. What advantage does it give to not have them
in
/opt? For instance, I ran into this problem with asterisk where it had many
small sound files which still put 600k on the NAND.
-} elsif ($size= 2048) {
+} elsif ($size= 0) {
Submit a patch to maemo-optify[1]. This is a must. Only kernel/Nokia
libraries should be on the rootfs. With so little space, there is no
reason for any end-user or commercial generated content to be on the rootfs.
[1] http://gitorious.org/+maemo-af-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: New optification issues in extras-testing
Hi, Am Dienstag 29 Dezember 2009 schrieb Eero Tamminen: Where this 500kB figure for these packages come from? As long as there's no indication whether the limit itself is meant to be interpreted as logical or physical memory space there's imho no point of discussing what this guy actually measured. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to change button shape?
Hi, Am Dienstag 29 Dezember 2009 schrieb Cornelius Hald: The theming is defined here: /usr/share/themes/default/gtk-2.0/gtkrc If you look for example for fremantle-button-group-box you will find a style which defines those toggle buttons which are only rounded at the outer left and right button. There is the GtkStyle API with which you can apply a defined style to a specific widget. It's rather cumbersome, but it might work for you. If you're still interested, I can dig up some code where I used this API. Thanks, but i won't need it if it gets complicated. I was interested in using this for buttons used as a replacement for gtknotebook tabs in fremantle. But the current toggle buttons already look quite nice for this purpose, so there's no need to make things more complex. Thanks again, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi, Am Dienstag 29 Dezember 2009 schrieb Andrew Flegg * you maintain both libgoocanvas3 and osm2go Still this would require additional work i'd like to avoid. * neither are optified (according to the comments) Osm2go is of course optified, otherwise it wouldn't already be in extras. Just the stuff the system needs symlinks for is still in rootfs as i really think this excessive symlinking is ugly as hell. * I *imagine* there aren't lots of other apps depending on libgoocanvas3 which have been let through QA Xournal? ...this would seem to fall on to your shoulders. The STRONG recommendation is that EVERYTHING is optified, and getting pedantic about the numbers when you control both halves of the application stack seems a little churlish. After all, someone wanting to be difficult could split their app into 500 2KB packages which depend on each other :-) Then why do you talk about a 500kB limit if you in fact want _everything_ in /opt? What's the point of giving hard numbers and then stating that you want something different? Now, on to solving the problem, have you tried putting auto in debian/optify? If so, did both packages continue to work after being auto-optified by the builder (or maemo-build-deb in Scratchbox, if you prefer). Why should i? I think the 500k per package limit is fine and neither of my two packages exceeds it. There is a rule, i am following it and that's it. If you don't like the rule, then change it. If you think my interpretation of the rule is valid but not what it intends to say, then re-phrase the rule to become clear. If you want to do neither: Accept my interpretation. The intention is that they *should* (which is why 'auto' will become the default at some point in the future). That's the moment where i'll have to deal with it. Not before. As i said above: I think the current 500k limit per package is just fine, so for me this is just an unnecessary hurdle. Hope that helps, Andrew Regards, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
On Tue, Dec 29, 2009 at 19:49, Till Harbaum / Lists li...@harbaum.org wrote: Am Dienstag 29 Dezember 2009 schrieb Andrew Flegg * you maintain both libgoocanvas3 and osm2go Still this would require additional work i'd like to avoid. Well, the creation of debian/optify containing the one word auto shouldn't be *too* much work. * neither are optified (according to the comments) Osm2go is of course optified, otherwise it wouldn't already be in extras. Just the stuff the system needs symlinks for is still in rootfs as i really think this excessive symlinking is ugly as hell. I entirely agree! maemo-optification is a HIDEOUS hack (the thread where /opt was unveiled contains my thoughts); but it's the easiest way to solve the problem for authors who don't want to do too much work, and the most expedient for Nokia as they realised the problem *far* too late. * I *imagine* there aren't lots of other apps depending on libgoocanvas3 which have been let through QA Xournal? OK. Unfortunately, the packages interface doesn't let you see reverse dependencies ATM. ...this would seem to fall on to your shoulders. The STRONG recommendation is that EVERYTHING is optified, and getting pedantic about the numbers when you control both halves of the application stack seems a little churlish. After all, someone wanting to be difficult could split their app into 500 2KB packages which depend on each other :-) Then why do you talk about a 500kB limit if you in fact want _everything_ in /opt? What's the point of giving hard numbers and then stating that you want something different? Who is this you? Do you see my name on the comments page?[1] Why should i? I think the 500k per package limit is fine and neither of my two packages exceeds it. There is a rule, i am following it and that's it. If you don't like the rule, then change it. If you think my interpretation of the rule is valid but not what it intends to say, then re-phrase the rule to become clear. If you want to do neither: Accept my interpretation. Why the confrontational approach? Why this you sort it out attitude? That's the moment where i'll have to deal with it. Not before. As i said above: I think the current 500k limit per package is just fine, so for me this is just an unnecessary hurdle. OK, so when that switches to automatic, can we have it in writing that you won't be on this list complaining about us changing the rules and breaking your packages? Of course, one *hope's* it'll work for libgoocanvas3 or osm2go, but it wouldn't work for Python (due to the way it uses readlink during library determination), so the odds are it not working on *all* packages. Cheers, Andrew [1] I'm fed up of being castigated by a small majority in this community for trying to help people understand the actions of others. -- 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: New optification issues in extras-testing
On Tuesday 29 December 2009 16:49:21 Till Harbaum / Lists wrote: Now, on to solving the problem, have you tried putting auto in debian/optify? If so, did both packages continue to work after being auto-optified by the builder (or maemo-build-deb in Scratchbox, if you prefer). Why should i? I think the 500k per package limit is fine and neither of my two packages exceeds it. You should do so, so your users don't brick their phones. It's soo easy to put everything in /opt. I agree the symlinking madness is a bit messy, but it workz and it's what we are stuck with until we have 2G NANDs. Do it for the users, not for some QA list. :) -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
how to hide libs project etc.
Hi, I'm planning to release a package that requires some libs and other relating projects, so I will upload them to auto build and extras-devel. But I'm wondering if I can hide some of them from application manager list, because the user needs to select the main project only. Is it possible ? If so, how to set it? Regards, Kimitake ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to hide libs project etc.
Sorry, I found it could be controlled by debian/control's section. Regards, Kimitake On Tue, Dec 29, 2009 at 4:40 PM, Kimitake kimit...@gmail.com wrote: Hi, I'm planning to release a package that requires some libs and other relating projects, so I will upload them to auto build and extras-devel. But I'm wondering if I can hide some of them from application manager list, because the user needs to select the main project only. Is it possible ? If so, how to set it? Regards, Kimitake ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to hide libs project etc.
On Tuesday 29 December 2009 21:40:34 Kimitake wrote: Hi, I'm planning to release a package that requires some libs and other relating projects, so I will upload them to auto build and extras-devel. But I'm wondering if I can hide some of them from application manager list, because the user needs to select the main project only. Is it possible ? If so, how to set it? In Section: just don't preface them with user/. That will make them invisible to the Hildon Application Manager. You can find valid a Section: here, btw: http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing#Sections -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
portrait view of Hildon-desktop
Hi Everyone: Does maemo5 support portrait view by now ? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [SyncEvolution] SyncEvolution in Fremantle
Patrick Ohly skrev: This is becoming more SyncEvolution specific. Should we continue cross-posting to maemo-developers? Dunno, I wasn't subscribed to the syncevolution list yet. I suppose I should subscribe to it. But I think some Maemo developers may have some interest in the progress of this anyway? On Sat, 2009-12-26 at 13:53 +, Ove Kaaven wrote: Patrick Ohly skrev: I was planning to do a 0.9.2 update release in a few weeks. Should we merge your code and include the Maemo support in the release announcement? If you want. It's your call. Given that you raised some questions below about improvements which cannot be done in backwards-compatible way between releases of the calendar backend (change tracking!), it might be better to give it some more time and release with 1.0 (tentative goal: end of March). Well, I think many people could benefit from synchronization before March, even if an incompatible change is introduced later. Is then the best way to just keep my unofficial builds available, without upstream integration before 1.0? It's not clear from the website whether this Linux Foundation license agreement is really to be sent to the moblin guys, or to some other address. My reading is that it needs to go to the Linux Foundation. I'll check. OK. I'm not sure what's up with having to sign Linux Foundation Moblin Workgroup Individual or Corporate Contribute License Agreement v1.0 (phew) if SyncEvolution isn't a Moblin project. Perhaps I'll just stick with the other options for now. I was hoping that TrackingSyncSource.h had enough information to be useful, but you are right, it doesn't explain the big picture. A more general introduction of source, item, etc. would be needed. Time to resurrect Doxygen and write some additional pages, I suppose. Would that have helped? Yes, probably. IMHO *any* framework is difficult to start with, regardless of the language :-/ Well, I've usually found it fairly easy to get into frameworks written in C or Python, but not C++. Not sure if that's just coincidence... - I'm not sure how to properly write those integration tests in the *Register.cpp I can add those when merging the code. OK. - Do I need to worry about getSupportedTypes() or anything You only need to implement the pure virtual methods, everything else has reasonable defaults. Well, I just imagine reasonable default is not always perfect or efficient or anything... getSupportedTypes() is legacy code which was inherited from the Funambol library. It became obsolete when moving to libsynthesis and is already removed on master (well, almost - just found a copy of it in a derived class). Funambol required that sources deal with data conversion themselves, whereas with Synthesis this is done by the engine. Allright. - The Maemo's calendar-backend can return entries that have changed after a particular date (typically you'd use the time of the previous sync). Is there a way to use this to improve on the TrackingSyncSource method, so it won't be necessary to load and generate revision strings for the whole database every time? As Congwu said, this can be done by inheriting from SyncSource directly and adding the SyncSource* building blocks that you want to reuse. You can use the TrackingSyncSource as an example how that is done. Well, as an example, it's really not very enlightening. Its implementation has no explanation. What is all this multiple-inheritance mess really doing? How many (and which) virtual base classes would I have to derive from to implement a more efficient change tracker, with the least amount of code? Would I have to spend a month digging into the internals of every single class of this huge forest of multiple-inheriting classes and take notes about how they work and interact, before I'd be able to write code that does something as simple as considering a known subset of the database as potentially modified since last sync, instead of checking the whole database? (The reasons I stopped using C++ are all coming back to me now...) The time of last sync is something that could be stored either in an internal source property or (better) in the SyncML anchor string, handled by the Synthesis engine. However, this will require changes to the Synthesis/SyncEvolution and SyncSource interfaces. We have to work on this anyway for resume support in the SyncML server, so my suggestion is to address this in 1.0 like this: * make those API changes * create a new DateSyncSource which requires the following information from derived classes: * complete list of all local item IDs * list of changed item IDs since a certain time * change FileSyncSource so that it is derived from DateSyncSource Works for me. Do you have easy access to all IDs of existing items? This is necessary to detect deleted items. Sure, a full list of IDs can be queried easily, with minimal overhead
Re: New optification issues in extras-testing
ext Till Harbaum / Lists li...@harbaum.org writes: it's likely wait too late for such a question, but why doesn't just /opt/bin, /opt/share etc exist with the system looking into those paths as well? My gut feeling is that this is not feasible in the short term, and not good enough for the long term. It is not feasible in the short term since it likely requires many iterations of the OS itself in order to get this to work reasonably well, and OS iterations are unfortunately just too damn slow. That's my feeling at least, and I was looking for a 'solution' that didn't require changes to the OS itself. (Incidentally, we shouldn't have made the /opt - /home/opt symlink either, we should just have 'homeified' packages to /home/maemo. The symlink has caused more than its share of problems...) Now, in the long run, I hope we do not have to do any of this. The rootfs should just be large enough, either by putting it on a single big partition, or by combining multiple partitions transparently with some kind of unionfs, lvm, or by just mounting /usr from a second partition. This allows us to stay compatible with the rest of the world, and is what common sense dictates. (The current plan is to have one big partition for /, but only for Harmattan.) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [SyncEvolution] SyncEvolution in Fremantle
Ove Kaaven skrev: This is already possible, but we aren't sure yet how to maintain the different profiles. Right now, src/syncclient_sample_config.xml contains a contacts field list (internal representation) and vCard profile that is used both for the SyncML peer and the local backends, with some tweaks to let some properties be handled differently on both sides (EVOLUTION rule). I found a case I'm not sure about. If you add a Jabber address to a contact, the vcard looks like: X-JABBER;TYPE=jabber:address but if you add a Ovi by Nokia address, the vcard looks like: X-JABBER;TYPE=nokiachat:address (If you add both, they not unexpectedly become separate entries, on separate lines.) Is there a good way to model that? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
