Re: Fw: Modest/TinyMail problems (continue from the blog comments)
> On Tue, Jun 24, 2008 at 11:24:24PM +0200, Andrea Grandi wrote: >> I continue here a discussion you can find in this post: >> http://pvanhoof.be/blog/index.php/2008/06/24/big-day-for-modest-and-tinymail >> (Just read the comments). > >> Please let me know what do you think about it. > > I want all the messages, and I want them in threaded view. I believe > Modest does the former, but not the latter. Well, Modest always retrieve all the email headers which is probably what you want. And regarding the threaded view, it's not possible for the moment, because tinymail only provides a plain model implementation that does not allow a threaded view. By the way, take into account the screen size constraints in which Modest runs, a threaded view won't be very useful in such a small screen. Br. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fw: Modest/TinyMail problems (continue from the blog comments)
> Hi all, > > I continue here a discussion you can find in this post: > http://pvanhoof.be/blog/index.php/2008/06/24/big-day-for-modest-and-tinymail > (Just read the comments). > > This is my idea: I don't want to be able to download 15.000+ messages. > I just want to download ONLY last 50, 100, 200 at maximum. Modest > doesn't behave in this way now. Even if you set the option "just > download ONLY 50 items". Maybe a bug? Don't know... Ok, I'll try to explain what happens here, many people have the same doubts you mention. It's very important to distinguish between two concepts, the mail header and the mail message. The mail header is what you see at the right pane in the modest window. It's not the full email message, it's just a very tiny piece of information with the very basic data about the message. The headers are _always_ downloaded, but this does not mean that the full email message is always downloaded. This means that if a mate send you a 10Mb email with his last photos, Modest won't download it for you unless you try to open the message saving you money if you're connected by GPRS and bandwidth anyway. Modest setting about download only 50,100,200... last messages, only applies if you have selected download "messages and attachments". Take into account that clicking on to a folder won't download the full messages never, that setting only applies when you click on "send & receive" button, or menu option. > I think the minimum number of messages should be the default value, > then it should let the user keep a maximum of x messages (where x is a > value that user can choose). When 200th message arrives, just drop the > first one and so on... (just like a FIFO queue with a maximum number > of items). Sounds good my idea? I think that Modest could manage 200 > messages quite good. As I said before, even if 2000 new messages arrive Modest won't download them unless you selected to retrieve full messages. Thank you for your comments. Br ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Modest/TinyMail problems (continue from the blog comments)
Hi, ext Philip Van Hoof wrote: > There are also other solutions for handling really large folders of more > than 15,000 items. The problem is not so much network bandwidth of the > envelopes. The problem is rather that each 5000th item the complete > summary storage file is rewritten on a relatively slow flash storage. > > That's a file of by that time 12 MB. If any application during that > write causes a fsync() call, that'll indeed hang your device for several > minutes. > > A solution for that is to either append instead of rewrite the file, or > rewrite the summary storage solution to use multiple smaller mapped > files. We have an experimental summary storage like that in our code, > but it's currently disabled because we didn't want to release untested > code in the device's Modest instance. Anybody doing large amount of writes to JFFS2, should take a quick look at this bug: https://bugs.maemo.org/show_bug.cgi?id=2615 Append is better than rewriting whole file or over/re-writing parts of the file. Churn for the JFFS2 content should in general be avoided. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Modest/TinyMail problems (continue from the blog comments)
On Wed, 2008-06-25 at 00:33 +0200, Luca Olivetti wrote: > En/na Marius Gedminas ha escrit: > > On Tue, Jun 24, 2008 at 11:24:24PM +0200, Andrea Grandi wrote: > > I want all the messages, and I want them in threaded view. I believe > > Modest does the former, but not the latter. > > Claws does both, however it also downloads *all* the headers. > Mulberry (that's not available on the tablet) uses a different approach: > it only downloads enough headers to fill the screen. You scroll down (or > up), it fetches more headers. Latency is higher and it cannot use the > same mechanism for offline operation, otherwise it's pretty efficient, > especially on a constrained device. Polymer does a similar thing to Mulberry. The technique is indeed very interesting and could be adapted to work with offline operations too, if downloading is allowed to take place in the background and if when scrolling up and down a higher priority task to get the visible items can be scheduled upfront. To make this perform good, with few latency problems, we'd need to implement full pipelining. This is something Tinymail's IMAP code can't do at this moment. For it to do such pipelining would require an almost rewrite of the IMAP code (not a trivial task, but planned nonetheless). > On a pc with a relatively slow connection to the imap server is way > faster than thunderbird on the same pc. That's for Mulberry mostly due to the fact that just visible envelopes are downloaded, and for Polymer on top of and Tinymail mostly due to the fact that CONDSTORE and QRESYNC can be used (if the IMAP server supports it). What could help a lot is to use very recent OpenSSL or NSS libraries with your IMAP server and on your device and keep tracking the latest versions. I have not investigated this fully but in theory can the SSL layer do compression. With IMAP data that would compress at a very high compression rate indeed. Certain IMAP servers also have the COMPRESS capability, but since the SSL layer should eventually support compression too, relatively few IMAP servers are implementing this capability. Cheers, -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: passing arguments to hildon applications
On Sun, 22 Jun 2008, Andrew Daviel wrote:
> Do you happen to know of an example using this launch hook ? I had hoped
> that maemopad would have it.
I found the source for PDFviewer (uses Xpdf I see..) on timeless.justdave.net
But it won't compile for me in Scrachbox (missing comapp).
Anyhow, I figure I *ought* to be able to find the relevant DBUS sections
in there to respond to hildon_mime_open_file. A hint from someone that
knows would be nice, though.
I.e. how to hildonize some app so it will work from the file manager or
the browser, or make a wrapper that accepts a DBUS request to open a
URL/file and does e.g. system("mplayer blah.wmv").
--
Andrew Daviel, TRIUMF, Canada
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Modest/TinyMail problems (continue from the blog comments)
En/na Marius Gedminas ha escrit: > On Tue, Jun 24, 2008 at 11:24:24PM +0200, Andrea Grandi wrote: >> I continue here a discussion you can find in this post: >> http://pvanhoof.be/blog/index.php/2008/06/24/big-day-for-modest-and-tinymail >> (Just read the comments). > >> Please let me know what do you think about it. > > I want all the messages, and I want them in threaded view. I believe > Modest does the former, but not the latter. Claws does both, however it also downloads *all* the headers. Mulberry (that's not available on the tablet) uses a different approach: it only downloads enough headers to fill the screen. You scroll down (or up), it fetches more headers. Latency is higher and it cannot use the same mechanism for offline operation, otherwise it's pretty efficient, especially on a constrained device. On a pc with a relatively slow connection to the imap server is way faster than thunderbird on the same pc. Bye -- Luca ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Modest/TinyMail problems (continue from the blog comments)
On Wed, 2008-06-25 at 00:57 +0300, Marius Gedminas wrote: > On Tue, Jun 24, 2008 at 11:24:24PM +0200, Andrea Grandi wrote: > > I continue here a discussion you can find in this post: > > http://pvanhoof.be/blog/index.php/2008/06/24/big-day-for-modest-and-tinymail > > (Just read the comments). > > > Please let me know what do you think about it. > > I want all the messages, and I want them in threaded view. I believe > Modest does the former, but not the latter. Although threaded view is a UI problem for Modest to solve, ain't Tinymail passing the necessary info to Modest so that it could do threading. At this moment. That's because the UI doesn't support it and because the info required for threading (the references headers) consume more bandwidth. If the UI ain't going to use it, then why request it, right? It's however relatively easy to let Tinymail pass it to Modest. We could also request THREAD if the IMAP server supports this capability (which relatively few IMAP servers don't) and build the threading very quickly this way (less analysis and calculating would need to be performed by the device, as the server would solve it entirely). Both would be relatively simple to do. What would be more difficult would be to write a GtkTreeModel that uses this extra info to also represent it in a Tree rather than a flat list. I'm also not convinced that a device with such a small screen could provide a useful view when threaded. I think grouping E-mails together based on "discussion", so basically a one-level Tree instead of a multi-threaded threaded view with each reply recursively going deeper ... I believe that makes a lot more sense. For example: [-] From My Boss, about "Your resignation letter" .+-- Your resignation letter from My Boss .+-- RE: Your resignation letter from My Boss .+-- RE: Your resignation letter from My Boss .`-- RE: Your resignation letter from My Boss Rather than [-]-- Your resignation letter from My Boss [-]-- RE: Your resignation letter from My Boss ....[-]-- RE: Your resignation letter from My Boss .`-- RE: Your resignation letter from My Boss Note that I used dots to indicate the amount of loss screen space in both UI solutions. And let's be honest ... does the second UI solution solve that much more of the problem you try to solve. Also if it's a tablet that you are unlikely going to be using for handling more than ten mails per day and that functions as your secondary E-mail client (your primary is either KMail, Evolution, Outlook or Thunderbird, right?). Anyway, join Tinymail's mailing list if you want to discuss the service- side of the story. The UI side is always going to be a Modest's team decision. Best way to ping those people is to make a bug for Maemo in the product "Mail" or "Modest" (I forgot which is being used atm). http://mail.gnome.org/mailman/listinfo/tinymail-devel-list -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Modest/TinyMail problems (continue from the blog comments)
Hi there, Problem is that for IMAP you want consistency with the UID and the sequence number to check whether or not a synchronization is needed. So you do actually need to build a storage of UIDs versus sequence numbers (that's the least you need, to ensure that you synchronize correctly). At least ... that's for an IMAP server that has neither CONDSTORE nor QRSYNC (like most IMAP servers in the field). What we could do, however, is receive just the sequence number and the UID, not the rest of the envelope headers, for all items later than n. The other problem however is that "what is later"? IMAP servers are 'recommended' but I don't think that they are required to have a sorting order on "date received". Most IMAP servers only increment the UID for their NEXTUID, but I don't think this is a requirement (not to fill up holes). Fair enough, I already hear you think, so we'll just use SORT and SEARCH then? That's another problem, IMAP servers are not required to implement either the SORT nor the SEARCH capability. So we end up with: 1) Just download the UID, not the rest of the envelope headers, but then we are not really certain that when we ask "the bottom last 200 items" that those are the 200 last received ones. 2) To solve that we can SORT/SEARCH, but we might not have that capability at all. 3) If we can't solve the request, we could fall back to just downloading all of the envelopes, like what is the only supported current behavior of Tinymail right now. Sounds good for me ... I await your patches (for Tinymail) :) There are also other solutions for handling really large folders of more than 15,000 items. The problem is not so much network bandwidth of the envelopes. The problem is rather that each 5000th item the complete summary storage file is rewritten on a relatively slow flash storage. That's a file of by that time 12 MB. If any application during that write causes a fsync() call, that'll indeed hang your device for several minutes. A solution for that is to either append instead of rewrite the file, or rewrite the summary storage solution to use multiple smaller mapped files. We have an experimental summary storage like that in our code, but it's currently disabled because we didn't want to release untested code in the device's Modest instance. I can point to it and help you out with testing the implementation if you join the Tinymail mailing list ... because going in detail is going to be offtopic on this mailing list. http://mail.gnome.org/mailman/listinfo/tinymail-devel-list On Tue, 2008-06-24 at 23:24 +0200, Andrea Grandi wrote: > Hi all, > > I continue here a discussion you can find in this post: > http://pvanhoof.be/blog/index.php/2008/06/24/big-day-for-modest-and-tinymail > (Just read the comments). > > This is my idea: I don't want to be able to download 15.000+ messages. > I just want to download ONLY last 50, 100, 200 at maximum. Modest > doesn't behave in this way now. Even if you set the option "just > download ONLY 50 items". Maybe a bug? Don't know... > > I think the minimum number of messages should be the default value, > then it should let the user keep a maximum of x messages (where x is a > value that user can choose). When 200th message arrives, just drop the > first one and so on... (just like a FIFO queue with a maximum number > of items). Sounds good my idea? I think that Modest could manage 200 > messages quite good. > > Please let me know what do you think about it. > > Best regards, -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Modest/TinyMail problems (continue from the blog comments)
On Tue, Jun 24, 2008 at 11:24:24PM +0200, Andrea Grandi wrote: > I continue here a discussion you can find in this post: > http://pvanhoof.be/blog/index.php/2008/06/24/big-day-for-modest-and-tinymail > (Just read the comments). > Please let me know what do you think about it. I want all the messages, and I want them in threaded view. I believe Modest does the former, but not the latter. HTH, Marius Gedminas -- No proper program contains an indication which as an operator-applied occurrence identifies an operator-defining occurrence which as an indication-applied occurrence identifies an indication-defining occurrence different from the one identified by the given indication as an indication-applied occurrence. -- ALGOL 68 Report signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Modest/TinyMail problems (continue from the blog comments)
Hi all, I continue here a discussion you can find in this post: http://pvanhoof.be/blog/index.php/2008/06/24/big-day-for-modest-and-tinymail (Just read the comments). This is my idea: I don't want to be able to download 15.000+ messages. I just want to download ONLY last 50, 100, 200 at maximum. Modest doesn't behave in this way now. Even if you set the option "just download ONLY 50 items". Maybe a bug? Don't know... I think the minimum number of messages should be the default value, then it should let the user keep a maximum of x messages (where x is a value that user can choose). When 200th message arrives, just drop the first one and so on... (just like a FIFO queue with a maximum number of items). Sounds good my idea? I think that Modest could manage 200 messages quite good. Please let me know what do you think about it. Best regards, -- Andrea Grandi email: a.grandi [AT] gmail [DOT] com website: http://www.andreagrandi.it PGP Key: http://www.andreagrandi.it/pgp_key.asc ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Sardine is dead.
Hi, ext Marius Vollmer wrote: > "ext Murray Cumming" <[EMAIL PROTECTED]> writes: > >> The problem with Sardine was that it didn't work, because Nokia didn't >> use it. If only Nokia and the outside world could use the same >> repository (with a few secret extras for the Nokia people) then life >> would be much simpler for everyone, including Nokia and it's >> sub-contractors. > > Precisely. Sardine is dead but the reasons why it was created are alive, probably now even more than before. Let's analyze the problems in the Sardine plan and implementation (thanks for the initial shot Murray, more feedback is welcome). Let's react accordingly in a new plan, defined together with all the stakeholders of such project. There have been some email discussions in the past and there are some ideas around this concept at http://wiki.maemo.org/2010_Agenda#Openness.2C_openness.2C_openness and probably somewhere else. Once the Sardine tears are dry we can start planning form a second attempt, this time successful. -- Quim Gil marketing manager, open source Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Rebuild all chinook source packages on autobuilder
On Mon, 2008-06-23 at 15:30 +0200, ext Fred wrote: > Ed Bartosh a écrit : > > > > If you have any ideas about promoter, don't hesitate to share them here. > > We haven't got much feedback about it. Frankly we almost haven't got > > any :) > > > > Regards, > > --- > > Ed > > > The main remark I would have about it is : Why should I be able to > promote package I didn't upload ... > I know it may not be easy but as we are required to login with our > garage account would it not be possible to restrict the view to project > that we are maintainer of ? > Well, it was done this way to be consistent with existing extras aproach. Everyone can [re]upload packages to extras[-devel], so why promoter should not allow users to do the same? Regards, --- Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Defining the Maemo Bugzilla scope
Hej hej! Currently Maemo Bugzilla is used as a bug tracking system for the "core" software elements shipped in the Maemo platform (to define the term "Maemo" itself, see the discussion at [1]. This includes both Open source and Closed source components *preinstalled* on the devices by Nokia. Obviously this does not include stuff like Skype or Rhapsody - they have their own bugtrackers. And there is Garage Tracker at [2]. It is the bugtracking system for all those products based on the Maemo stack, but not preinstalled on the devices by Nokia. In my opinion and in the long run, Garage tracker should die. Maemo Bugzilla shall be the main bugtracking place for all products based on the Maemo stack. I just didn't like working in Garage Tracker (have to admit that I just took some quick looks to synchronize the status of reports that were duplicated in Maemo Bugzilla). It reminded me a lot of that awful bug tracker that Sourceforge provided when I had a small software project hosted over there, but it may be only my personal opinion that Bugzilla is easier and better to handle than Tracker is. So I wonder: Are Garage project maintainers happy with Garage tracker? Would they be interested to track their bugs in Maemo Bugzilla instead? My (not even reasonible or founded) dislike of the Garage Tracker is entirely my personal opinion after working with several bug trackers in the past. I want your opinions - It does not make sense to think about this too much if everybody is fine with Garage Tracker. ;-) And which projects should be handled in Maemo Bugzilla? Keep it in the current state, as described at the beginning? Open it up for everybody interested in using Maemo Bugzilla to keep track of issues in his/her Maemo based software? The latter one would bring up the next question that Quim raised in the famous bug 630 [3]: Are then the apps preinstalled in a device, »maemo compatible applications«, a different layer sitting on top of the maemo software platform? Stuff to think about... andre PS: Also posted this to Internettablettalk.com and to the Planet. Let's see if I can manage to streamline the feedback. :-P [1] http://wiki.maemo.org/Task:Maemo_brand [2] https://garage.maemo.org/tracker/ [3] https://bugs.maemo.org/show_bug.cgi?id=630#c20 -- Andre Klapper (maemo.org bugmaster) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Installing xulrunner on N810
On Tue, Jun 24, 2008 at 09:08:21AM +0530, jitender singh wrote: > I have done the same as stated in > http://blog.mozilla.com/blassey/2008/03/17/maemo-buildbot/ > to install xulrunner on myN810 OS2008, except that i extracted > xulrunner in /media/mmc2/, because i don't have much space in /opt. > > This doesn't work when i tried to run mybrowser-0.2.2.xulapp > application. /media/mmc2 is mounted with noexec, so you cannot run applications from it. "mount -o remount,exec /media/mmc2" as root should solve that (temporarily, until next reboot). Marius Gedminas -- Any sufficiently advanced magic is indistinguishable from technology. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo released
Quim Gil wrote: > SDK announcement to land soon. > It is great to have kernel source at the same time, many thanks. http://repository.maemo.org/pool/maemo4.1/free/k/kernel-source-diablo/ Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Installing xulrunner on scrathbox CHINOOK
Hi, While building xulrunner as per specified in link http://wiki.mozilla.org/Mobile/Build/Fennec , I am getting this error undefined reference to `hildon_g_scanner_cache_open' How to to resolve this? Regards ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Sardine is dead.
"ext Murray Cumming" <[EMAIL PROTECTED]> writes: > The problem with Sardine was that it didn't work, because Nokia didn't > use it. If only Nokia and the outside world could use the same > repository (with a few secret extras for the Nokia people) then life > would be much simpler for everyone, including Nokia and it's > sub-contractors. Precisely. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
