Hildon-thumbnail's API
Dear Hildon developers,
* When you specify a callback, please try to always set "user_data" as
last argument.
This makes generating language bindings for it far more easy
For example for Vala bindings instead of using a generated binding, the
glue developer needs to change this:
[CCode (cheader_filename = "hildon-thumbnail.h")]
public static delegate void ThumbnailFactoryFinishedCallback
(Hildon.ThumbnailFactoryHandle handle, void* user_data, Gdk.Pixbuf
thumbnail, GLib.Error error);
Into this:
[CCode (instance_pos = 1.1)]
public delegate void ThumbnailFactoryFinishedCallback
(Hildon.ThumbnailFactoryHandle handle, Gdk.Pixbuf? thumbnail,
GLib.Error error);
And that's just because Vala is very easy to write a binding for. With
things like PyGTK I guess you have to wrap each user of that callback
into a normal one, and call the actual callback in the abnormal way from
that wrap. Quite cumbersome and hard if everybody would write APIs like
that.
* When you make an API, please always use a real GObject instead of
"typedef gpointer HildonThumbnailFactoryHandle" stuff.
This makes generating language bindings for it far more easy.
Far far more easy, actually.
* When you make a type, please try to be consistent with naming header
files and give them the same name as your type's name. For example
hildon-thumbnail-factory-handle.h if the type is called like
HildonThumbnailFactoryHandle
Not hildon-thumbnail-factory.h unless you call it HildonThumbnailFactory,
which would have been, by the way, a fine name too (I don't know why
adding "Handle" to the type's name makes any sense, but okay).
This makes generating language bindings for it far more easy
* When writing gtk-doc comments, please include all arguments:
Not this:
/**
* hildon_thumbnail_factory_load_custom:
* @flags: #HildonThumbnailFlags indicating which flags to use to create the
thumbnail
*
* ...
**/
But this:
/**
* hildon_thumbnail_factory_load_custom:
* @uri: Thumbnail will be created for this URI
* @mime_type: MIME type of the resource the URI points to
* @width: Desired thumbnail width
* @height: Desired thumbnail height
* @callback: Function to call when thumbnail creation finished or there was an
error
* @user_data: Optional data passed to the callback
* @flags: #HildonThumbnailFlags indicating which flags to use to create the
thumbnail
*
**/
And given what I recommended above, don't put the flags as last, like
how this API ended up becoming, put it in front of user_data or right
after the self.
If the method is a getter for a singleton, GObject libraries usually
call the method something like:
hildon_thumbnail_factory_get or hildon_thumbnail_factory_get_instance
HildonThumbnailFactory*
hildon_thumbnail_factory_get_instance (const gchar *uri,
const gchar *mime_type,
guint width, guint height,
HildonThumbnailFactoryFinishedCallback
callback,
gpointer user_data);
* If you make a GObject-like API, any API, always include the self
pointer:
Not this:
void hildon_thumbnail_factory_move(const gchar *src_uri,
const gchar *dest_uri);
But this:
void hildon_thumbnail_factory_move(HildonThumbnailFactory *self,
const gchar *src_uri,
const gchar *dest_uri);
* Etc etc etc
--
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 Sat, 2008-06-28 at 19:51 +0200, Luca Olivetti wrote: > En/na Luca Olivetti ha escrit: > > En/na Dave Cridland ha escrit: > > > >> Tinymail is good - if Luca upgrades his IMAP server to Cyrus 2.3, he'll > >> see a big speed increase from both Modest and Polymer, I think. > > > > I'm too old for that, now I stick with whatever version comes with the > > distro. > > BTW, after flashing diablo, I tried modest again, and I'm sorry to say > that it's till unusable for me. > The biggest problem is that it cannot cope with big folders (e.g. I have > one that has ~26000 messages) and that's after receiving all headers, it > is slightly better with a ~12000 messages folder. > Besides, it has no threading, no "view next unread" button, no "mark > thread read", no "mark folder read" and no "show only new messages" > option (or at least I couldn't find them). Sizes above 10,000 items are not supported by Modest. Tinymail can handle such folders relatively well (if you use the demo-ui), but Modest does a bunch of sorting operations that makes those sizes unusable slow indeed. We know which areas (blocks of code) are responsible for the slowdown and we can point people to possible optimizations. Among them are the summary store in Tinymail, order of retrieval (which influences the amount of sorting needed by Modest. Rob Taylor is planning to work on this at Guadec too, by the way), sorting itself, storing sort results, making integer values of strings and store these so that those can be compared instead of having to compare strings while sorting, etc etc etc. During the development of Modest there was, however, relatively low priority given to supporting really large folders. About the threading we have discussed this on this mailing list, so you can read in this discussion-thread the possibilities and POV being taken. One of the conclusions is that a fully threaded view wastes too much screen space. Most people just need grouping "discussions", so that is one possibility indeed. Again we can point people to how to make this work (and are some people already doing small experiments too). About the buttons that you would like, the software is opensource and the features that you describe are all relatively easy to implement. For Modest we had a strict UI & requirements document that didn't include your features. Nonetheless would your code that implements them speak loader than E-mails. So I can only recommend checking out the code and trying to implement them. Perhaps provide a plugin-system so that in case Nokia's UI team decides not to accept your UI enhancements, you can still ship plugins that enable the features. If you do, get in touch with the Modest maintainers and developers hint: you can for example find most of them on the Tinymail mailing list. 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)
On Wed, 2008-06-25 at 16:31 +0100, Dave Cridland wrote: > On Wed Jun 25 10:23:44 2008, Philip Van Hoof wrote: > My biggest problem with Modest has always been that the UI > requirements seem to have driven the development, to the extent that > although Tinymail is pretty good, both its development and its usage > has been severely compromised by trying to build a desktop mail > program on an internet tablet. Somewhat agree. I do believe we can extend the IMAP protocol in such a way that indeed desktop E-mail client features are supportable on mobile E-mail clients and more importantly "fast enough". A fully capable Lemonade IMAP server with THREAD is getting very close to that. Add ESEARCH to that (or has Lemonade this?) and you could even do relatively nice vFolder like features. An interesting requirement that you see nowadays is the meme of labels or tags rather than folders. People want one E-mail item to be tagged by multiple tags. That's the equivalent of putting on E-mail item into multiple mailboxes, and then using a mailbox as-if it's at tag instead. That would already work, but people want to search on things like but not only those tags. For example alle E-mails tagged "Important" that came from my girlfriend. When abusing mailboxes as tags that would mean doing a multimailbox spanned search ... Anyway, you get the idea. I would like tools in IMAP that improve the protocol's search capabilities. ESEARCH is a good start, indeed. > The result is a program that looks the part, and has the right > buttons to press, but by insisting on those features as priority over > all else, it's hog-tied itself into poor use of the network, so it's > totally unusable on my mailboxes, whereas Polymer just trundles > through them. I think Modest's IMAP code could be rewritten or improved to use the network right (ie. pipelining the STATUS requests, pipeling an ENVELOPE plus BODYSTRUCTURE fetch, fetching per MIME part, etc) All that would need to be done in Tinymail's layer. You would probably make Polymer again better, just for the fun of it ;), but it could come pretty close to Polymer's network usage. If I could just put resources behind it. Which is not trivial. Modest's basic UI problems are solved. As as you indeed correctly stated is or was Modest's development driven by its UI requirements. Not by the network usage. If Modest's Tinymail layer uses the network in a relatively good way, meaning that it does CONDSTORE and QRESYNC if possible, then that's because I was too jealous on Polymer's network performance :-) These implementations were not required by Modest's requirements. Indeed, competing inspires the passionate mind. > > I wrote Polymer really in order to demonstrate ACAP to people. :-) > The low-bandwidth, big mailbox support was mostly accidental > initially, and only later turned into a really experimental, cutting > edge, thing. (It's now not quite so starkly cutting edge, since > Tinymail has caught up rather a lot). Oh no, no no. Tinymail is not doing pipelining. You and me know that that's a huge difference compared to Polymer's network utilization. The on-demand envelope fetching is neat but for offline usage I will always need to in-background fetch the remaining surroundings anyway. Nonetheless, it's an interesting concept to focus on getting the content that the user wants "right now" in time (at scrolling). Meanwhile storing it for future cached use ... is something Polymer is missing. So .. there you have it, my evil plans for Tinymail ;-), to make it do that. Be afraid, Dave, be very afraid. Moehaha! :) Anyway, we'll/I'll probably do it in such a way that we both can share that store's implementation. > > If somebody would pick it up, I'm sure he'd fully support making > > Telomer and Polymer full featured E-mail clients indeed. > Heck, if people would simply use it, I'd put some time into tidying > it up, but yes, if someone else wants to really run with it, I'd hand > it over. I'm not a Python developer ... we could rewrite it in Vala? :-) -- 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 Wed, 2008-06-25 at 11:55 +0200, Luca Olivetti wrote: > > I'm probably too dumb to find those options ;-) (btw, now polymer just > crashes) No you are right, it's supported on your IMAP server. Cyrus is an excellent choice too, by the way. That's a free software imapd that gets most right. Which is nice, and exceptional. Another really good one is Dovecot, by the way. There is one, that is regretfully being used far to often by people as a 'personal IMAP server', that gets quite a lot of IMAP core spec things just wrong. I'll leave it as an exercise for the reading to figure out which one that is. That's extremely frustrating for E-mail client developers, of course. It's "precisely" their mistakes at implementing the specification correctly that makes developing a good E-mail client that consumes IMAP unimaginably hard. It's the fact that this is hard, that makes it more easy for a E-mail services vendor to sell and develop a new E-mail server that has a closed protocol, and glue a specialized E-mail client to it. IMAP server developers have a responsibility in this, in my opinion. If they want IMAP to succeed, they should NOT misinterpret the RFC. > > Experimentally the client has a lot of value, since it shows how modern > > IMAP usage would outperform any other offering (Blackberry or Windows > > Mobile E-mail clients with Exchange) several times in a row. > > I *do* hope he succeed: it would make me very happy if non-standard > proprietary protocols just disappeared (though many people seem happy > with their crap^H^H^H^Hblackberries and don't mind giving their > passwords to a 3rd party and let their mail pass through rim servers). I'm not against a bit of competition for IMAP. It's that competition that pushed IMAP developers to start thinking about enhancing the protocol under the Lemonade umbrella. Perhaps it would have happened without the competition too. I do think, however, that competition inspires the passionate mind. So I'm fine with the Blackberries and the Windows Mobile E-mail clients and the Exchanges. We'll just compete. It's not that hard, they don't do that many surprisingly difficult things. In contrary, actually. Almost zero innovation comes from those factories. Doesn't sound to me like a lot of passionate people work over there ... must be a really boring job and it must suck realizing that you are actually blocking innovation instead of fostering it. Poor guys ... > >> I'm currently tunneling imap through ssh with compression enabled. > > > > > > That's a good temporary solution indeed. Note that your SSL layer might > > already do compression, in which case the SSH tunnel will just add > > latency to your connection. > > Yes, my goal was to avoid ssl altogether (I can do that with > thunderbird) and at the same time not to expose the imap server to the > internet at large (after all it's my own personal server). Not everybody has the same possibilities as you have. So most E-mail clients default to encrypting the connection if possible. >From a security perspective, that makes a lot of sense. How many people care about that [x] Use STARTLS option ? Too few. Everybody should, nobody is. So E-mail clients that just use it if they see it is available, are right. E-mail clients that don't and yet make it surprisingly difficult for the user to enable it, are wrong. > Unfortunately it seems that claws cannot use cram-md5/digest-md5 and > it's forcing a starttls. Polymer can do cram-md5/digest-md5 but it's > forcing a starttls anyway. Sounds like right behaviour. The risk of exposing one person's private details (like passwords and E-mails) on the naked Internet, outperforms the risk of serving a geek who has made his own SSH tunnel at a very small extra latency hit. -- 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 Wed, 2008-06-25 at 10:48 +0200, Luca Olivetti wrote: > En/na Philip Van Hoof ha escrit: > > > 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. > > I just tried Polymer under windows (btw, try googling for Polymer and > you don't have a chance of finding it, Infotrope Polymer is the right > search term) and it's a bit too basic: either I couldn't find the option > or it doesn't even allow to select the sort order, neither it can thread > the messages. That might be because your IMAP server doesn't support either THREAD nor SORT. Dave is making Infotrope (and derived E-mail clients like Polymer and Telomer) mostly for testing IMAP servers that he develops at the place where he works (at Isode). He's mostly interested in top-notch interaction between the client and the IMAP server (pipelining and testing them in combination with newer Lemonade features). Experimentally the client has a lot of value, since it shows how modern IMAP usage would outperform any other offering (Blackberry or Windows Mobile E-mail clients with Exchange) several times in a row. > As per the tablet it says that Telomer (the tablet version of Polymer) > is even more stripped down, with several key features not working > (though I didn't try it yet). Yeah, the E-mail clients done by Dave are mostly for doing nifty experiments. I've put Dave in CC, so that he can again feel proud about how cool I think his experimental E-mail clients are. > I'm currently tunneling imap through ssh with compression enabled. That's a good temporary solution indeed. Note that your SSL layer might already do compression, in which case the SSH tunnel will just add latency to your connection. -- 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 Wed, 2008-06-25 at 10:00 +0100, Graham Cobb wrote: > On Wednesday 25 June 2008 01:10:28 Philip Van Hoof wrote: > > Polymer does a similar thing to Mulberry. > > I also have some very large folders and I liked the Polymer approach a lot. > It is a shame the author doesn't have the time/resources to turn it into a > full-featured mail application. Personally I want a, primarily, online mail > program (with a few offline features: I would like to be able to download > specific messages for reading offline, and would like to be able to create > emails offline), designed for large, and fairly rapidly changing mailboxes. > > I haven't tried Modest yet but will do so as soon as I install Diablo as it > sounds like it is at least a step in the right direction. The right direction would be a guy like Dave together with me writing a nice Tinymail-API like library, and the guys who wrote Modest adapting that UI to use that. Who knows, some day? ;-) One problem with Infotrope is of course the Python part of it. It's not really cool to have to resort to IPC to talk to it in a reasonably easy way from Vala, C or C++. infotroped.py ? :) maybe ... But as pointed out did Dave mostly made the E-mail clients for experiments (at least afaik). If somebody would pick it up, I'm sure he'd fully support making Telomer and Polymer full featured E-mail clients indeed. Problem is that relatively a lot of people think to know how their E-mail client must be done, but relatively few people will put their energy in it too. :-) ps. Adding Dave in CC again. -- 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 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: 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: Maemo's glib version, lobbying for GIO
On Wed, 2008-02-13 at 08:14 +, Tommi Komulainen wrote: > On Tue, 2008-02-12 at 17:21 +0100, ext Philip Van Hoof wrote: > > My questions ... > > > > Therefore I wonder about what the plan is for Maemo's glib version. How > > soon will Maemo upgrade? What can we do to help speeding up GIO's > > inclusion into Maemo? Would a standalone version be acceptable? > > In general we prefer stable releases (personally I'd say starting > from .6 or so) but we also backport specific things. At the moment there > is no strong demand for GIO so it's not too high up in priority list. > We'll get GIO latest when we upgrade to 2.16. Strong demand will happen as soon as people start picking it up, of course. People will be picking it in during the following weeks, during the Berlin Hackfest and after the hackfest. I'm confident the conference at FOSDEM will make people even more aware of the benefits of standardising on for example async APIs, stream APIs and etcetera. I promised one of the developers in #nautilus to give him my 770 if he maintains and ports gio and gvfs. He sounded very enthusiastic about this. I also made a quick port of just GIO myself which you can find here: http://pvanhoof.be/files/gio-ugly-maemo-port.tar.gz > Then again GIO is just an add-on so it could be easily introduced > without breaking anything, but all work requires resources we could > currently use more elsewhere. That's right. So far only "goffset" is a newly used type that Maemo's glib doesn't have a typedef for. > I mean you'd need to do things like coming up with a migration path from > no-GIO -> glib-without-official-GIO -> glib-with-GIO, figure out when to > introduce what (taking into account release plans we're not at liberty > to discuss - duh!), how/who would deal with bugfixes and periodical > catchup with upstream, etc. Ok. So I promised my 770 to somebody if he gets GIO and GVFS packaged in maemo-extras. He promised me he'll maintain it after that too. His name: A. Walton. I don't yet know whether he'll succeed/proceed of course. If not, I might do it. -- 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: Maemo's glib version, lobbying for GIO
On Tue, 2008-02-12 at 18:46 +0200, [EMAIL PROTECTED] wrote: [Bla bla] > I think you should try to find a way to get gio to work on the existing > glib and then provide a package which could be installed into existing > OS releases. > Or "yes". Just package it properly and support it. Add it to > maemo-extras and version it well http://pvanhoof.be/files/gio-ugly-maemo-port.tar.gz Have fun -- 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
Maemo's glib version, lobbying for GIO
Hi there, Efficient streaming affects memory usage and performance on mobile devices a lot. The more we needlessly copy IO data around, or the more we need to wrap each other's self-invented stream-like apis, the slower the final result (the device) will be. This is absolutely not good. Especially not for the mobile situation. Therefore I'm pleased that at the level of glib a team has started working on GIO. http://svn.gnome.org/viewvc/glib/trunk/gio/ GIO not only comes with a streaming API, but also with a standard way for making cancellable asynchronous APIs. It uses the Asynchronous pattern for this which results in types like GAsyncResult and a type GCancellable. http://svn.gnome.org/viewvc/glib/trunk/gio/gasyncresult.h http://svn.gnome.org/viewvc/glib/trunk/gio/gcancellable.h As Tinymail's main developer I would like to start using these types as soon as possible (that's instantly after my first release). I would like to standardise on how future glib GObject based libraries will do async APIs that are cancellable and I would like to standardise on my stream related APIs too. http://svn.gnome.org/viewvc/glib/trunk/gio/goutputstream.h http://svn.gnome.org/viewvc/glib/trunk/gio/gunixinputstream.h To sooner I can do this, the fewer times my API will need to be broken, the fewer major releases I have to do. The less headaches development teams depending on Tinymail, like Modest's team, will have. If after this current distro Maemo would not get a glib for half a year that includes a GIO, people like me could be blocked for the entire time from delivering APIs like E-mail ones unless I hack-in a standalone version of GIO (sounds ugly to me, but if necessary ...). My questions ... Therefore I wonder about what the plan is for Maemo's glib version. How soon will Maemo upgrade? What can we do to help speeding up GIO's inclusion into Maemo? Would a standalone version be acceptable? My opinion ... .. is that the sooner we have this API in Maemo, the sooner application and- library developers will be synchronised with each other's APIs and IO sharing. For example HTML components need to share IO with the E-mail framework (inline attached images in base64 encoding). The VFS needs to share IO with the E-mail framework (Attachment->Save As). The media player (hi there Valagume developer!) could share IO with the E-mail framework (streaming an attached MP3), or GStreamer could share the IO (a source element that knows about GIO's streams). A lot of libraries expose asynchronous APIs. At this moment are most of them having their own nuance differences. With a generic infrastructure for asynchronous APIs in gio, libraries could finally start doing it in a standardised way. Making things more easy for application developers. Making things more easy for language bindings. Making things contain less bugs. -- 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: Hibernation of applications during ptrace
On Tue, 2007-09-25 at 19:23 +0300, Eero Tamminen wrote: > Hi, > Desktop kills only applications that have announced themselves to be > killable. Application should do that only when they've saved state, > are in the background (i.e. not interacting with the user) and able > to restore the state when restarted. I.e. it would be a problem in > the application I think. Interesting, how would this work? I don't think our application is ever setting itself in this state, so I wonder why this hibernation key is created? :-\ > And desktop does this only when it's notified that the device is low > on memory. So, close extra applications and if that doesn't help, > add swap. You might also try using gdbserver as Gdb can take quite > a lot of memory. This also happens in Scratchbox running on a desktop with 2GB of ram. Using gdbserver is something I can try, yes. Measuring memory availability shows me that around 20MB is still available when testing this on a device. > Another alternative is that the device runs so low on memory that > your application is OOM-killed. You can see this from the syslog. Checked. This ain't happening. Thanks for the hint, though. > In this case add swap or use gdbserver. If you know that the device > should still survive with the amount of memory Gdb and your app > are using, you could set those processes OOM-protected with: > echo -17 > /proc/PID/oom_adj Aha, also very useful indeed. > And OOM-unprotect it afterwards by using "0" instead of -17 (as root > of course), but don't be surprised if the device reboots if they > use too much memory. :-) I wont :) Thanks for the interesting info. Although I think it doesn't yet explain the ptrace problem that I experience :-( -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hibernation of applications during ptrace
On Tue, 2007-09-25 at 18:55 +0300, Eero Tamminen wrote: > You're just not pressing the "Enter" one more time after you type > "cont"? If your application crashes, the enter waiting in Gdb > readline buffer will then cause Gdb immediately to repeat the previous > command and continue the process (which then promptly exits)... > > This is very annoying Gdb behaviour, it should empty readline > buffer before getting new input from the developer. No that's not the problem that I'm experiencing. I also experienced this once the application was about to hit a breakpoint. Sometimes immediately after hitting it. -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Hibernation of applications during ptrace
Hi there hackers! While I'm debugging my application using gdb, I noticed that in both Scratchbox for intel, Scratchbox for ARM and on the device certain things in the Maemo platform decide that the application is hibernating, or ... something. It seems to be the reason why while I'm debugging my application, I very often get an error from ptrace telling me that the process no longer exists. Usually I guess this hibernation support for applications is most likely absolutely awesome and totally cool. However, while I'm developing and especially during a gdb session, I'd prefer that nothing touches my processes and threads. As debugging info I usually get something like this: ... hildon-desktop[25510]: GLIB DEBUG default - computing hibernation key hildon-desktop[25510]: GLIB DEBUG default - hibernation key: appname ... hildon-desktop[25510]: GLIB DEBUG default - removing child from AS ... hildon-desktop[25510]: GLIB DEBUG default - ... no more children, removing app. ... Is there a way to completely disable all this stuff? I know about "run-standalone.sh": Even with this tool I am seeing various problems. Especially when I run my application in gdb. I'd like to disable it "totally". For example: not starting it, patching it out and overwriting the library on my device and scratchbox environment, shooting it in the head before I start my debugging sessions, ... molesting it? Really hurting it? Anything! I also know about the alias for gdb, that makes gdb start with run-standalone.sh. Even that seems to be insufficient as I'm still seeing threads (usually it's threads) being killed by something. Usually while I'm debugging (while I'm focusing on finding a bug or race cond, it's usually really not the moment to kill _my_ thread). Even after using every possible imaginable runstandalonable run- standalone.sh script, I'm still seeing threads getting killed. I have also recompiled GDB from CVS (yesterday's version) and with this version all problems related to GDB specifically seem vanished, the only remaining problem appears to be hildon-desktop killing things behind my back and gdb's ptrace really not enjoying that. -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] [Fwd: [OLPC-devel] Pygtk and garbage collecting]
-- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be --- Begin Message --- This PyGTK bug is going to be important for OLPC as it might slow down object destruction. http://bugzilla.gnome.org/show_bug.cgi?id=320428 For example in the tinymail-python-test.py*, you will find a gc.collect(). This is to speed up the destruction of objects in the situation described in Bug #320428 https://svn.tinymail.org/svn/tinymail/trunk/libtinymail-test/tinymail-python-test.py In case of tinymail the GtkTreeModel that holds a reference on all the headers of the current folder, is such an object. model = MsgHeaderListModel () treeview.set_model (model) newmodel = MsgHeaderListModel () treeview.set_model (newmodel) Will not immediately mark "model" for garbage collection (when model goes out of scope). Adding a gc.collect(), however, will. That model instance, in case of tinymail, holds a reference to the headers of your folder. This is where most of the memory tinymail consumes is located (the summary information). Therefore it's a small disaster on a device with few memory resources, that Pythons garbage collector is slow at detecting this. Applying the patch of Bug #320428 or performing gc.collect() in your Python code fixes this. Note that tinymail isn't going to be the only case. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ Devel mailing list Devel@laptop.org http://mailman.laptop.org/mailman/listinfo/devel --- End Message --- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: The fixes11 mmap patch doesn't respect data alignment on some architectures
On Fri, 2006-07-14 at 19:23 +0200, Philip Van Hoof wrote:
> While the x86 handles unaligned access, ARM doesn't. The patch will not
> work on architectures that don't handle unaligned access.
>
> I will try to fix it, but I don't have a lot experience in this field.
Second attempt to introduce data alignment. It's still getting Killed on
the Nokia 770 ARM device. Regretfully I don't have a debugger for that
device.
In my hexeditor it looks like all of the summary file is now aligned to
4 bytes (or at least something is aligned to 4 bytes).
There's also no dmesg message on the device when the kill happens.
Could use some assistance from an expert in this field ;-) (I'm not)
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
? camel-mime-tables.c
? providers/groupwise/.deps
? providers/groupwise/.libs
? providers/groupwise/camel-groupwise-folder.lo
? providers/groupwise/camel-groupwise-journal.lo
? providers/groupwise/camel-groupwise-provider.lo
? providers/groupwise/camel-groupwise-store-summary.lo
? providers/groupwise/camel-groupwise-store.lo
? providers/groupwise/camel-groupwise-summary.lo
? providers/groupwise/camel-groupwise-transport.lo
? providers/groupwise/camel-groupwise-utils.lo
? providers/groupwise/libcamelgroupwise.la
? providers/hula/.deps
? providers/hula/.libs
? providers/hula/camel-hula-provider.lo
? providers/hula/libcamelhula.la
Index: camel-file-utils.c
===
RCS file: /cvs/gnome/evolution-data-server/camel/camel-file-utils.c,v
retrieving revision 1.17
diff -u -p -r1.17 camel-file-utils.c
--- camel-file-utils.c 2 Jun 2006 00:52:29 - 1.17
+++ camel-file-utils.c 15 Jul 2006 10:18:26 -
@@ -49,135 +49,120 @@
#define IO_TIMEOUT (60*4)
+
/**
- * camel_file_util_encode_uint32:
+ * camel_file_util_encode_fixed_int32:
* @out: file to output to
* @value: value to output
*
- * Utility function to save an uint32 to a file.
+ * Encode a gint32, performing no compression, but converting
+ * to network order.
*
* Return value: 0 on success, -1 on error.
**/
int
-camel_file_util_encode_uint32 (FILE *out, guint32 value)
+camel_file_util_encode_fixed_int32 (FILE *out, gint32 value)
{
- int i;
+ guint32 save;
- for (i = 28; i > 0; i -= 7) {
- if (value >= (1 << i)) {
- unsigned int c = (value >> i) & 0x7f;
- if (fputc (c, out) == -1)
-return -1;
- }
- }
- return fputc (value | 0x80, out);
+ save = g_htonl (value);
+ if (fwrite (&save, sizeof (save), 1, out) != 1)
+ return -1;
+ return 0;
}
/**
- * camel_file_util_decode_uint32:
+ * camel_file_util_decode_fixed_int32:
* @in: file to read from
* @dest: pointer to a variable to store the value in
*
- * Retrieve an encoded uint32 from a file.
+ * Retrieve a gint32.
*
- * Return value: 0 on success, -1 on error. @*dest will contain the
- * decoded value.
+ * Return value: 0 on success, -1 on error.
**/
int
-camel_file_util_decode_uint32 (FILE *in, guint32 *dest)
+camel_file_util_decode_fixed_int32 (FILE *in, gint32 *dest)
{
-guint32 value = 0;
- int v;
+ guint32 save;
-/* until we get the last byte, keep decoding 7 bits at a time */
-while ( ((v = fgetc (in)) & 0x80) == 0 && v!=EOF) {
-value |= v;
-value <<= 7;
-}
- if (v == EOF) {
- *dest = value >> 7;
+ if (fread (&save, sizeof (save), 1, in) == 1) {
+ *dest = g_ntohl (save);
+ return 0;
+ } else {
return -1;
}
- *dest = value | (v & 0x7f);
-
-return 0;
}
/**
- * camel_file_util_encode_fixed_int32:
+ * camel_file_util_encode_uint32:
* @out: file to output to
* @value: value to output
*
- * Encode a gint32, performing no compression, but converting
- * to network order.
+ * Utility function to save an uint32 to a file.
*
* Return value: 0 on success, -1 on error.
**/
int
-camel_file_util_encode_fixed_int32 (FILE *out, gint32 value)
+camel_file_util_encode_uint32 (FILE *out, guint32 value)
{
- guint32 save;
-
- save = g_htonl (value);
- if (fwrite (&save, sizeof (save), 1, out) != 1)
- return -1;
- return 0;
+ return camel_file_util_encode_fixed_int32 (out, value);
}
/**
- * camel_file_util_decode_fixed_int32:
+ * camel_file_util_decode_uint32:
* @in: file to read from
* @dest: pointer to a variable to store the value in
*
- * Retrieve a gint32.
+ * Retrieve an encoded uint32 from a file.
*
- * Return value: 0 on success, -1 on error.
+ * Return value: 0 on success, -1 on error. @*dest will contain the
+ * decoded value.
**/
int
-camel_file_util_decode_fixed_int32 (FILE *in, gint32 *dest)
+camel_file_util_decode_uint32 (FILE *in, guint32 *dest)
{
- guint32 save;
+ return camel_file_util_decode_fixed_int32 (in,
Re: [maemo-developers] A good debugger infrastructure
On Tue, 2006-07-18 at 09:58 +0300, Ed Bartosh wrote: > On Mon, 2006-07-17 at 20:16 +0200, ext Philip Van Hoof wrote: > > The gdbserver didn't work. It crashed. But gdb on the device itself (in > > an xterm), however does work. Pity it's a little bit difficult because > > my ui's are always full screen. But I'll manage. > > > > Thanks for these packages, whoever made them. This is really helping me. > > > > Tapping "u p" and "d o w n" now :) > How exactly gdbserver crashed? Did you try to run application with it or > to attach to existing pid? I only tried with simple non-gui applications > (ping, tracepath) and it worked without any problem. I only tried once, but I attached it to a new program: gdbserver 192.168.1.102:5000 /opt/tinymail/bin/tinymail Other computer: gdb, target remote 192.168.1.102:5000 And gdbserver crashed. I forgot what it said. I think something about "target not found" or something with the tinymail binary. But I will very soon do some more tests. Also, for example, using an NFS share from my /scratchbox/users/$user/SDK_ARMEL/opt :) -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] A good debugger infrastructure
On Mon, 2006-07-17 at 23:05 +0400, Mikhail Sobolev wrote: > On Mon, Jul 17, 2006 at 08:58:46PM +0200, Philip Van Hoof wrote: > > How can I thank you for letting me know there's a gdb package? > It's not me, it's Ed Bartosh :) Oh. Thanks Ed :) > > The mmap() summaries are now working with tinymail on the Nokia 770. > I believe, there's an issue with mmap on jffs2. I'm not sure if it was > already raised in that different thread... I think it was that mmap can only be used read-only on jff2. But that's not a problem here. I'm only using it read-only. And it's working ;-). It can, of course, use some testing. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: The mmap stuff definitely needs more eyes!
Hi there,
This one works on the Nokia 770 device!
http://pvanhoof.be/files/camel_folder_summary_with_mmap_fixes11_data_alignment04.diff
So my real target has finally been reached. Using this stuff, it should
be possible to display huge folders using tinymail on a Nokia 770.
With huge I mean: I'm expecting to support more than 20,000 headers per
folder. I don't know .. in theory it should even work with 100,000 or
more headers. But there's theory and reality. Lets test?
ps. It's of course going to take a while to receive the summary of such
a folder over wifi.
ps. I only tested this (on the device) with the imap implementation.
ps. Other people, please test this?
On Mon, 2006-07-17 at 20:47 +0200, Philip Van Hoof wrote:
> Eeeek. Look at what I just found in my own patches!!
>
> static CamelMessageInfo *
> message_info_load (CamelFolderSummary *s, FILE *in)
> {
> CamelMessageInfo *info;
> CamelImapMessageInfo *iinfo;
>
> info = camel_imap_summary_parent->message_info_load (s, in);
>
> if (info) {
> unsigned char* ptrchr = s->filepos;
> ptrchr = camel_file_util_mmap_decode_uint32 (ptrchr,
> &iinfo->server_flags, FALSE);
> s->filepos = ptrchr;
> label_to_flags(iinfo);
> }
>
> return info;
> }
>
>
> The "iinfo" is simply never assigned, yet being used! Eeek! *scared
> by my own mistakes now*. Very strange that didn't crash and burn on x86
> but does crash on ARM.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] A good debugger infrastructure
On Mon, 2006-07-17 at 22:37 +0400, Mikhail Sobolev wrote: > On Mon, Jul 17, 2006 at 08:16:21PM +0200, Philip Van Hoof wrote: > > > > I didn't try, no. > > > You should definitely try first :) > > > > > > gdbserver is included into gdb package. You can install it from > > > http://repository.maemo.org/ repo: > > > > > > echo "deb http://repository.maemo.org/ mistral free non-free" > > > >> /etc/apt/sources.list > > > apt-get update && apt-get install gdb > > The gdbserver didn't work. It crashed. > Can you get a strace output or something and post a bug at > https://maemo.org/bugzilla/ ? How can I thank you for letting me know there's a gdb package? Using that gdb I fixed the bug that caused the problem of which I thought it was a data alignment issue. The mmap() summaries are now working with tinymail on the Nokia 770. I'm now creating a 50,000 messages IMAP folder for testing. In theory the device should now have the ability to display such amounts. What a simple gdb can do :). You Nokians should brag more about what is available on the platform! I really didn't know that there's a gdb package. Anyhow .. Thanks. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] A good debugger infrastructure
On Mon, 2006-07-17 at 22:37 +0400, Mikhail Sobolev wrote: > On Mon, Jul 17, 2006 at 08:16:21PM +0200, Philip Van Hoof wrote: > > > > I didn't try, no. > > > You should definitely try first :) > > > > > > gdbserver is included into gdb package. You can install it from > > > http://repository.maemo.org/ repo: > > > > > > echo "deb http://repository.maemo.org/ mistral free non-free" > > > >> /etc/apt/sources.list > > > apt-get update && apt-get install gdb > > The gdbserver didn't work. It crashed. > Can you get a strace output or something and post a bug at > https://maemo.org/bugzilla/ ? I will definitely need if more often than just today and now. So I will indeed try to iron out the problem and will post it on that bugzilla once I'm certain it's not me doing things incorrectly. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] A good debugger infrastructure
On Mon, 2006-07-17 at 12:38 +0300, Ed Bartosh wrote: > > I didn't try, no. > You should definitely try first :) > > gdbserver is included into gdb package. You can install it from > http://repository.maemo.org/ repo: > > echo "deb http://repository.maemo.org/ mistral free non-free" > >> /etc/apt/sources.list > apt-get update && apt-get install gdb The gdbserver didn't work. It crashed. But gdb on the device itself (in an xterm), however does work. Pity it's a little bit difficult because my ui's are always full screen. But I'll manage. Thanks for these packages, whoever made them. This is really helping me. Tapping "u p" and "d o w n" now :) -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] A good debugger infrastructure
On Mon, 2006-07-17 at 12:29 +0300, Ed Bartosh wrote: > On Sun, 2006-07-16 at 20:31 +0200, ext Philip Van Hoof wrote: > > On Sun, 2006-07-16 at 21:45 +0400, Mikhail Sobolev wrote: > > > On Sun, Jul 16, 2006 at 06:10:18PM +0200, Philip Van Hoof wrote: > > > > Nevertheless I'd like to re-empathize that software developers working > > > > on embedded devices like the Nokia 770 are very much in need of a good > > > > debugging infrastructure like gdbserver. > > > Could you please be more specific? > > > > > > Running gdbserver on the device. Or is that already possible? Afaik it's > > not. > It just works in my environment. What makes you think it doesn't work? > Did you try to use it? What exactly didn't work? Awesome .. how do I make it work? Is there an ARM package for it? I didn't try, no. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Tinymail using mmap() gets killed by the kernel of the device
On Mon, 2006-07-17 at 11:49 +0300, Eero Tamminen wrote: > On Mon, Jul 17, 2006 at 10:12:21AM +0200, Philip Van Hoof wrote: > > I cannot change these "to, from nor subject" pointers. These are used > > in thousands of lines of Evolution code that I don't want to change. > > There's no need to align access to chars. Is there something that accesses > the saved data as shorts, longs (ints), floats or doubles? Or casts the > char pointers e.g. into int *? (use -Wcast-align) Yes. But I already did something to make sure that access is correct. It's in the patch. Search for "get_unaligned_u32" http://pvanhoof.be/files/camel_folder_summary_with_mmap_fixes11_data_alignment03.diff Yet the patch still isn't working on ARM (and I don't have a debug infrastructure, unless somebody can explain me how to set it up using some emulator -- like qemu? --). -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Tinymail using mmap() gets killed by the kernel of the device
On Mon, 2006-07-17 at 09:55 +0300, Eero Tamminen wrote:
> Hi,
>
>
> Otherwise one just needs to be careful.
> As to this:
> struct MyHeaderSummary
> {
> int16 foo;
> char bar;
> char string[MAXLEN] __attribute__ ((aligned (4)));
> };
>
> If the point of this is to align the "string" member as a pointer
> would, 4 is not correct alignment for 64-bit architectures.
Regretfully, I can't change the structs. They are, in fact, put in the
structs as char pointers. What I do is calculate the offset in the
memory of the mmap to where these pointers need to point to.
The struct instances are kept alive for as long as the mmap isn't
munmap'ed. When the mmap gets munmap'ed, the struct instances also need
to die.
So it's more 'like' this (almost pseudo):
typedef struct _CamelMessageInfo CamelMessageInfo;
struct _CamelMessageInfo
{
/* .. */
char *to, *from, *subject;
/* .. */
unsigned char *mmap_addr;
};
CamelMessageInfo*
message_info_load (CamelSummaryInfo *s)
{
CamelMessageInfo *mi = malloc (sizeof (CamelMessageInfo ...));
mi->to = mmap_addr;
mmap_addr += length-of mi->to
mi->from = mmap_addr;
etc etc
return mi;
}
CamelFolderSummary*
folder_summary_load ()
{
CamelFolderSummary *s = ...
s->mmap_addr = mmap (...);
folder_header_load (s);
for (i=0< i< s->message_count_in_header; s++)
{
CamelMessageInfo *mi;
mi = message_info_load (s);
folder_summary_add_mi (s, mi);
}
}
I cannot change these "to, from nor subject" pointers. These are used in
thousands of lines of Evolution code that I don't want to change.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] A good debugger infrastructure
On Sun, 2006-07-16 at 21:45 +0400, Mikhail Sobolev wrote: > On Sun, Jul 16, 2006 at 06:10:18PM +0200, Philip Van Hoof wrote: > > Nevertheless I'd like to re-empathize that software developers working > > on embedded devices like the Nokia 770 are very much in need of a good > > debugging infrastructure like gdbserver. > Could you please be more specific? Running gdbserver on the device. Or is that already possible? Afaik it's not. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] The Sardine is finally on the grill
On Sun, 2006-07-16 at 19:49 +0300, Carlos Guerreiro wrote: > > Carlos, are there any plans to start organising the meetings we asked > > No concrete plans yet but a clear understanding that they are needed and > will happen soon. > > > for during the BOF? I think the more early those get started, the > > better. > > Agreed. One thing we need to do first and is on my todo list is to setup > a page in the Maemo Wiki to present the results of the BOF and follow up > the consequent action. I hope to have that done very soon. Hey Carlos, Your efforts to get Nokia and Maemo even more close to the community are inspiring. Please continue. Thank you. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] The Sardine is finally on the grill
On Thu, 2006-07-13 at 17:45 +0300, Carlos Guerreiro wrote: > Now, The Sardine is finally on the grill! Great! Carlos, are there any plans to start organising the meetings we asked for during the BOF? I think the more early those get started, the better. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] A good debugger infrastructure
I'm very sure this is well known by Nokians, Nevertheless I'd like to re-empathize that software developers working on embedded devices like the Nokia 770 are very much in need of a good debugging infrastructure like gdbserver. Please give it a high priority. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: The fixes11 mmap patch doesn't respect data alignment on some architectures
Hi there everybody who so far assisted me in trying to get the mmap-for- camel patches to correctly data aligned. Thanks. I will repeat the situation so that everybody has a clear idea of what and why about this E-mail. During the last weeks, I worked on Camel's summary loading. The summary which Camel (a framework for E-mail access being used by Evolution and tinymail) loads is typically used by E-mail clients like Evolution and tinymail for displaying the summary. The summary is a view with mostly headers like the "date received", the "from" and the "subject" headers. Most E-mail clients have this and as you might think, this is indeed one of the most memory and cpu consuming ui pieces of a E-mail client. Therefore I decided to mmap() this information rather than the current fread implementation being used by Camel. You see, tinymail is targeted for small devices with very few memory availability. Yet tinymail promises displaying a lot such headers (more than 10,000). Tinymail can already do this on a device like the Nokia 770. Even with the fread implementation. But as a passionate software developer, I want more. You can read some technical information on the mmap stuff here (and on the Evolution hackers mailing list, and on other GNOME blogs). http://pvanhoof.be/blog/index.php/the-camel-mmap-summary-stuff-what-is-this-all-about/ I want to display 150,000 headers. And I'm certain this is possible if I make sure only the visible headers are really in memory. I know doing that is possible, and I know the shortest path to getting their (going from A to C without passing B) is mmap. That is the reason why I did these Camel patches. Surprise, on a x86 architecture I'm already at B. This is actually working stuff on certain architectures. On architectures that require data aligned access to memory, however, this isn't working. An example of a device using such an architecture is the Nokia 770 which has an ARM cpu. The Nokia 770 *is* definitely a target device for tinymail. I have been trying, with very few experience with ARM and such data aligned memory access, to get the patch to become data aligned. I've received some very useful pointers and information. As Freddie Mercury once said: "I thank you all". I don't have debugger infrastructure for the Nokia 770, nor do I have an emulator running where I can actually use a debugger on. Nor do I have good testing infrastructure myself. So this is making it harder for me to get it right (I'm thinking the problem is a very small one). Using all these hints and tips, I cooked this version of the patch (you'll find an URL below). I will describe how you can get your hands dirty quickly: It's possible that evolution-data-server is already migrated to GNOME's Subversion (this migration is happening these days). Nevertheless should this anonymous CVS infrastructure still work and is this patch based on the anonymous CVS repository. cvs -z3 -d :pserver:[EMAIL PROTECTED]:/cvs/gnome co evolution-data-server cd evolution-data-server/camel patch -p0 < thepatch cd .. ./autogen.sh --prefix=/opt/camel && make && make install The most important files are camel-file-utils.c and camel-folder-summary.c. There's also some ./providers/*/*-summary.c files that are also reading things from the mmap memory (like some version integers). You can get yourself a simple test E-mail client using tinymail: svn co https://svn.tinymail.org/svn/tinymail/ cd tinymail/trunk export PKG_CONFIG_PATH=/opt/camel/lib/pkgconfig ./autogen.sh --prefix=/opt/tinymail && make && make install You can configure an account in tinymail using this simple script: http://pvanhoof.be/files/tny-account-create.sh If you go "online" and open a folder, it will create "summary" files in for example: $HOME/.tinymail/mail/imap/$hostname/folders/INBOX/summary It's that file (for your INBOX folder) that will be mmap-ed if you close that folder and re-open it (or if you restart the application). This is the original patch that didn't care about data alignment at all. This patch works: http://pvanhoof.be/files/camel_folder_summary_with_mmap_fixes11.diff This is my 3th attempt to get data alignment correct. It's not working on a Nokia 770. It will (when the loading of the mmap stuff happens) get killed. On the tty, it will print "Killed". http://pvanhoof.be/files/camel_folder_summary_with_mmap_fixes11_data_alignment03.diff The camel_folder_summary_load method is where all this starts. On Sat, 2006-07-15 at 10:15 +0200, Philip Van Hoof wrote: > On Fri, 2006-07-14 at 17:15 -0400, Jeffrey Stedfast wrote: > > ah, you're going to have to pad strings and possibly other stuff. > > The pstrings themselves and the 7bit encoded unsigned 32 integer bytes. > Since data padding on ARM is 4 bytes (32bit), unsigned
Re: [maemo-developers] Re: Tinymail using mmap() gets killed by the kernel of the device
On Sat, 2006-07-15 at 23:19 +0300, Tomi Ollila wrote: > Philip Van Hoof <[EMAIL PROTECTED]> writes: > > > > > If somebody feels brave, feel free to assist me in getting it 4 byte > > aligned ;-). I don't have a lot experience here. > > (((char *)address + 3) & ~3) I simply use this on each char* pointer? That's it? -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] strange thin crack in hardware... see fotos
On Sat, 2006-07-15 at 01:33 +0200, Collin R. Mulliner wrote: > check out: http://www.mulliner.org/nokia770/pool/fotos/broken_hw/ > > ..it shows my device with a thin crack on the "connector panel" at the > lower part of the device. The device still works 100% as far as I can > tell. I can't recall dropping my device other then once from about 15cm > to the carpet (this was some weeks ago). Today I discovered the strange > crack which seems to go right through the "connector panel". Check out > the 4 fotos I made. Funny. I have exactly the same crack. I never dropped my device. I thought it was because I kept the device in my laptop bag between various other objects like adaptors and stuff -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: Tinymail using mmap() gets killed by the kernel of the device
On Fri, 2006-07-14 at 11:41 +0200, Philip Van Hoof wrote: > When I run tinymail behind a camel with the mmap() patch, on the device, > it will get killed by the kernel (it's not a Segfault, it's a kill by > the kernel). > > When I run tinymail (behind a camel with the mmap..) on my desktop or in > scratchbox, everything works perfectly. > > The OOM killer? It turns out that the data of the summary file isn't 4 byte aligned. This is probably the reason (as I didn't care about alignment when writing the patch). If somebody feels brave, feel free to assist me in getting it 4 byte aligned ;-). I don't have a lot experience here. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Tinymail using mmap() gets killed by the kernel of the device
On Fri, 2006-07-14 at 11:15 +0100, Ross Burton wrote: > On Fri, 2006-07-14 at 11:41 +0200, Philip Van Hoof wrote: > > When I run tinymail behind a camel with the mmap() patch, on the device, > > it will get killed by the kernel (it's not a Segfault, it's a kill by > > the kernel). > > > > When I run tinymail (behind a camel with the mmap..) on my desktop or in > > scratchbox, everything works perfectly. > > > > The OOM killer? > > Check dmesg, the kernel logs when it OOMs. I don't remember a OOM message in dmesg. But at the terminal it prints "Killed" (if it would have been a segfault, it would have printed Segmentation fault). I'm not at a location where I can get Internet access over wifi and I've been using tinymail using the non-mmap patch (causing it to overwrite my summary files with ones that can't be opened with the mmap code). So I can't test at this moment. I will probably recheck the dmesg logs tomorrow or this evening. I do know that the mmap() and munmap() syscalls don't make the kill happen. I know this because I mmap() before I know whether the summary file has the right version or not. It's also detecting an incorrect version, so it can at least read the first bytes (for sure). So it must be something that happens while parsing the memory block. I know I had to use some guint32's, maybe those are differently written to the file on ARM? Regretfully I don't have a debugger for the device (afaik) so I can't check where or what's happening. Running tinymail with gdb on SDK_ARMEL also isn't working :-( -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: Tinymail using mmap() gets killed by the kernel of the device
On Fri, 2006-07-14 at 11:41 +0200, Philip Van Hoof wrote: > When I run tinymail behind a camel with the mmap() patch, on the device, > it will get killed by the kernel (it's not a Segfault, it's a kill by > the kernel). > > When I run tinymail (behind a camel with the mmap..) on my desktop or in > scratchbox, everything works perfectly. > > The OOM killer? In this blog entry I describe how you can compile tinymail with this mmap() patch. There's also binaries. http://pvanhoof.be/blog/index.php/2006/07/13/its-not-a-release-but-its-available-for-your-nokia-770 -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Tinymail using mmap() gets killed by the kernel of the device
When I run tinymail behind a camel with the mmap() patch, on the device, it will get killed by the kernel (it's not a Segfault, it's a kill by the kernel). When I run tinymail (behind a camel with the mmap..) on my desktop or in scratchbox, everything works perfectly. The OOM killer? -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Fixing osso-email, building a custom treeview model. The technique in demo format
Hi there, In this repository I demo the beginnings of how I would implement the GtkTreeView crap for a client like osso-email https://svn.cronos.be/svn/custom-treemodel-demo/trunk/ I also created a wiki pages that explains the major problems with the current osso-email code, and how it could be fixed. http://maemo.org/maemowiki/ImprovementIdeasForOssoEmail Also check out my own wiki for more information http://www.pvanhoof.be/wiki/index.php/Different_ways_of_using_GtkTreeView -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] New wiki page (IMprovementIdeasForOssoMail)
On Wed, 2006-01-11 at 11:22 +0100, Philip Van Hoof wrote:
> On Tue, 2006-01-10 at 12:43 +0100, Philip Van Hoof wrote:
> Somebody cleaned up the page. I added some more documentation and
> explanation. For example about proxy classes and custom models.
>
> I also created a sample here: http://pastebin.com/500098
I updated the same, it now also actually works and has a IMsgHeader,
MsgHeader and MsgHeaderPrx just like how I explained it in the "Proxy"
solution section.
I attached it.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
#include
static int ELEMENT_COUNT = 1;
static int instantiations = 0;
static GtkWidget *window = NULL;
typedef struct _IMsgHeader IMsgHeader;
typedef struct _MsgHeader MsgHeader;
typedef struct _MsgHeaderPrx MsgHeaderPrx;
struct _IMsgHeader {
const gchar* (*get_from_func) (IMsgHeader *this);
const gint (*get_id_func) (IMsgHeader *this);
gint id;
};
struct _MsgHeader {
IMsgHeader parent;
gchar *from;
};
struct _MsgHeaderPrx {
IMsgHeader parent;
MsgHeader *real;
};
/* IMsgHeader (late binding like) impl */
const gint
imsg_header_get_id (IMsgHeader *this)
{
return this->get_id_func (this);
}
const gchar*
imsg_header_get_from (IMsgHeader *this)
{
return this->get_from_func (this);
}
/* Real subject impl */
MsgHeader*
msg_header_new (gint id)
{
MsgHeader *header = g_new0(MsgHeader, 1);
g_print ("Instantiation for id=%d (%d passed)\n!!",
id, instantiations);
instantiations++;
header->parent.id = id;
header->from = g_strdup ("A real IMsgHeader subject!");
return header;
}
/* Proxy impl */
const gchar*
msg_header_proxy_get_from (IMsgHeader *this_i)
{
MsgHeaderPrx *this = (MsgHeaderPrx*)this_i;
if (this->real == NULL)
this->real = msg_header_new (this->parent.id);
return this->real->from;
}
const gint
msg_header_proxy_get_id (IMsgHeader *this_i)
{
MsgHeaderPrx *this = (MsgHeaderPrx*)this_i;
if (this->real == NULL)
this->real = msg_header_new (this->parent.id);
return this->real->parent.id;
}
MsgHeaderPrx*
msg_header_proxy_new (gint id)
{
MsgHeaderPrx *header = g_new0(MsgHeaderPrx, 1);
header->parent.id = id;
header->parent.get_from_func = msg_header_proxy_get_from;
header->parent.get_id_func = msg_header_proxy_get_id;
header->real = NULL;
return header;
}
enum
{
COLUMN_NUMBER,
COLUMN_HEADER,
NUM_COLUMNS
};
static void
msg_header_treeview_destroy_model_item (gpointer data)
{
g_print ("Destroy\n");
}
static void
msg_header_treeview_get_model_item (GtkTreeViewColumn *tree_column,
GtkCellRenderer *cell,
GtkTreeModel *tree_model,
GtkTreeIter *iter,
gpointer data)
{
gint number;
IMsgHeader *header;
/* This function can call the getter on the item in the model.
* Such an item can be a proxy class (IMsgHeaderPrx), triggering
* this getter causes an instantiation (or getting it from a
* factory with a cache) of a real subject (a real MsgHeader).
*
* The proxy now reads the value from the real subject and
* returns it to fullfill the contract of the interface IMsgHeader.
*/
gtk_tree_model_get (tree_model, iter, COLUMN_HEADER, &header, -1);
g_print ("from=%s, %d\n", imsg_header_get_from (header),
imsg_header_get_id (header));
}
static GtkTreeModel *
create_model (void)
{
gint i = 0;
GtkListStore *store;
GtkTreeIter iter;
store = gtk_list_store_new (NUM_COLUMNS,
G_TYPE_INT,
G_TYPE_POINTER);
for (i = 0; i < ELEMENT_COUNT; i++)
{
MsgHeaderPrx *header = msg_header_proxy_new (i);
gtk_list_store_append (store, &iter);
gtk_list_store_set (store, &iter,
COLUMN_NUMBER, header->parent.id,
COLUMN_HEADER, header, -1);
}
return GTK_TREE_MODEL (store);
}
static void
add_columns (GtkTreeView *treeview)
{
GtkCellRenderer *renderer;
GtkTreeViewColumn *column;
GtkTreeModel *model = gtk_tree_view_get_model (treeview);
renderer = gtk_cell_renderer_text_new ();
column = gtk_tree_view_column_new_with_attributes ("Number",
renderer,
"text",
COLUMN_NUMBER,
NULL);
gtk_tree_view_column_set_sort_column_id (column, COLUMN_NUMBER);
gtk_tree_view_colu
Re: [maemo-developers] New wiki page (IMprovementIdeasForOssoMail)
On Tue, 2006-01-10 at 12:43 +0100, Philip Van Hoof wrote: > New wiki page. > > Don't take what I've already mentioned on the wiki page personal. > > As a software developer myself I know how things in a software > development project go. > > http://maemo.org/maemowiki/ImprovementIdeasForOssoEmail > > And of course, feel free to improve the wiki page. Somebody cleaned up the page. I added some more documentation and explanation. For example about proxy classes and custom models. I also created a sample here: http://pastebin.com/500098 Try the same sample without the fixed-width properties of the columns and without the fixed-row-height properties of the treeview. The result will be that in the background, a lot rows will be processed. This is something you don't want to let happen on the Nokia 770, as this would take enormous amounts of (mainly) I/O and CPU processing time in case the instances in de list model are proxy classes and/or in case you've created a custom model with 'lazy' getters. I'll add this E-mail to the document . . . -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] New wiki page (IMprovementIdeasForOssoMail)
New wiki page. Don't take what I've already mentioned on the wiki page personal. As a software developer myself I know how things in a software development project go. http://maemo.org/maemowiki/ImprovementIdeasForOssoEmail And of course, feel free to improve the wiki page. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] Integration with the backup tool
On Mon, 2006-01-09 at 01:23 -0800, Jason Mills wrote: > I think (though I can't speak for Philip directly) that the request was for a > more strongly-worded and detailed backup specification, including both > run-state (i.e., pause-to-disk) and saved-state (backup/restore) of both the > installed application's user data /and/ the application binary/libraries > themselves. Correct -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Integration with the backup tool
Hi there, It would be nice if it would be possible to integrate with the backup software of the Nokia. That way, in case an upgrade of the device is a necessity, the user wouldn't have to run all the backup softwares of all the ISV's that created softwares for his mobility solution. In stead, using just one tool would suffice: The Nokia tool. As all the ISV's had a standard to implement backups of the application state. It would also be 'nice' to some day have ABI and perhaps API stability. And once that (ABI stability) is set in place, the flasher shouldn't overwrite custom applications (but should perhaps warn about the fact that the upgrade might break those). I'm seeing the Nokia 770 as a potential candidate for development of custom softwares. And since a lot of the device is free software, therefore source included, I see it as a usable platform that is highly customizable. If I where one of the Nokia decision makers, I'd "use" that fact. But you guys are free to go in any direction you like. Just like how developers and decision makers at ISV's (like my employer) are free to pick other devices for such applications ;-). -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] A way to create my own flashable binaries
Hi there, For a customer I'd like a way to create my own binaries which I can use to flash a Nokia 770. The reason is that this would make it more easy to do large deployments. I was thinking like this: mount -o loop -t nokia Nokia_770_$x.bin /mnt mv /mnt/bin/sh /mnt/bin/sh.recoverme cp /bin/sh /mnt/bin/sh cp /usr/bin/dpkg /mnt/usr/bin/dkpg.x86 cp mystuff.deb /mnt/ chroot /mnt cd / dpkg.x86 -i mystuff.deb exit cp /mnt/bin/sh.recoverme /mnt/bin/sh umount /mnt for a in *.devices do DEVNAME=`cat $a | grep DENAME | cut -d "=" -f 1` echo "Attach the next device ($DEVNAME) please" read flasher -F Nokia_770_$x.bin -f -R flasher --set-device-name $DEVNAME --reboot done -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] ANN: screenshot tool (mst 0.4)
On Tue, 2005-10-11 at 00:38 +0400, Mikhail Sobolev wrote: > Hi > > Let me announce the availability of the screenshot tool I mentioned > earlier. > > You can grab it at http://only.mawhrin.net/~mss/thingies/mst/ > > All feedback is welcome. Perhaps it's a good idea to create an apt repository for non-official Maemo packages (packages packaged and/or developed by non-Maemo developers and/or packages that aren't included with the default device)? I hereby offer my bandwidth and server-harddisk for this specific purpose. You can test the speed at, for example, http://mirror.freax.be/ (the device is co-located at realroot.be). But perhaps is the Maemo-team/Nokia interested in doing this themselves? Which would also be great, of course. Just note that it will most likely happen sooner or later anyway. If somebody (preferably somebody who knows a lot about Debian package mirrors) is interested in setting it up, contact me. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Documentation
On Sat, 2005-10-01 at 23:09 +0100, Andrew Wafaa wrote: > Hi and great work so far guys and girls. > > I'm just starting to learn about programming and thought that Maemo > would be the best platform to start on. I downloaded the SDK > documentation, and noticed a few problems - spelling mistakes, grammar > etc. I know it's nothing big or anything, but I'm finding it a bit > slow going with the mistakes and I'd hate it if people ended up > holding it against the project. > So with this in mind, could someone tell me how I would go about, > rectifying these little problems within the documentation. I mean is > the an easily editable format available or would I have to basically > re-write the whole damned thing? Also note that the scratchbox related documentation (on Maemo.org) is a bit outdated. And there's also a tiny issue with the d-bus package on the latest stable scratchbox release. I'd be nice to update this documentation (and fix the d-bus package). I think many newcomers will have troubles trying to get the scratchbox environment working cause of this outdated info. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] A few questions about the developmentplatforms internals
On Thu, 2005-09-29 at 11:55 +0200, Philip Van Hoof wrote: > > Hey Karoliina, > > I understand that it's harder than just applying my patches. So please > take your time. It's urgent enough to destabilize Maemo. Of course I meant that it's NOT urgent enough to ... :-) -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] A few questions about the developmentplatforms internals
On Wed, 2005-09-28 at 14:51 +0300, [EMAIL PROTECTED] wrote: > Hello, > > Thanks for the patches for maemo-af-desktop and hildon-control-panel > (plus libosso). > We will consider these after we do the d-bus upgrade. > It requires further branching to start it, so I can't apply this right > away, but > I try to return to these as soon as I have branched the maemo-af-desktop > and hildon-control-panel. Hey Karoliina, I understand that it's harder than just applying my patches. So please take your time. It's urgent enough to destabilize Maemo. The stability of the platform is more important than having a very recent version of D-BUS. Since D-BUS is going to stabilize their API, however, it's going to be useful to eventually upgrade to a D-BUS version with a stabilized API. This will make it much more easy to target the Maemo devices for development of applications (which is what we are planning to do at for example X-Tend, the company where I am professionally employed). Depending on the greatness of the platform and openness of the Nokia/Maemo team you guys can expect more such patches and contributions from people like me. That is a promise. I'm confident for example the GNOME free software developers community is very happy with how you guys are attempting to open up as much as possible. I'm looking forward and am excited to making this dream (an open development platform for mobile devices) come true. Together with you guys. > >-Original Message- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of ext > >Philip Van Hoof > >Sent: 28 September, 2005 14:14 > >To: maemo-developers@maemo.org > >Subject: Re: [maemo-developers] A few questions about the > >developmentplatforms internals > > > >This patch upgrades the D-BUS version of maemo-af-desktop > > > >-- > >Philip Van Hoof, software developer at x-tend > >home: me at pvanhoof dot be > >gnome: pvanhoof at gnome dot org > >work: vanhoof at x-tend dot be > >http://www.pvanhoof.be - http://www.x-tend.be > > -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Bug 98 (Was: Re: [maemo-developers] A few questions about the development platforms internals)
On request I've moved the patches to bugzilla: https://www.maemo.org/bugzilla/show_bug.cgi?id=98 -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] A few questions about the development platforms internals
On Wed, 2005-09-28 at 13:39 +0200, Philip Van Hoof wrote:
> Disregard previous "dbus upgrade" patch for libosso, and use this one
No no no take this one :-)
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
Index: src/osso-hw.c
===
--- src/osso-hw.c (revision 1007)
+++ src/osso-hw.c (working copy)
@@ -405,7 +405,7 @@
return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
}
-new_state = dbus_message_iter_get_boolean(&i);
+dbus_message_iter_get_basic (&i, &new_state);
if (osso->hw_state.system_inactivity_ind != new_state) {
osso->hw_state.system_inactivity_ind = new_state;
if (osso->hw_cbs.system_inactivity_ind.set) {
@@ -425,7 +425,7 @@
return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
}
-s = dbus_message_iter_get_string(&i);
+dbus_message_iter_get_basic (&i, &s);
if (strncmp(s, NORMAL_MODE, strlen(NORMAL_MODE)) == 0) {
osso->hw_state.sig_device_mode_ind = OSSO_DEVMODE_NORMAL;
write_device_state_to_file(NORMAL_MODE);
Index: src/osso-state.c
===
--- src/osso-state.c (revision 1007)
+++ src/osso-state.c (working copy)
@@ -23,6 +23,9 @@
#include "osso-state.h"
#include "osso-log.h"
+static osso_return_t _write_state(const gchar *statefile, osso_state_t *state);
+static osso_return_t _read_state(const gchar *statefile, osso_state_t *state);
+
/**
* This internal function performs a simple validation for the application
* and version information of the osso_context regarding their validity
Index: src/osso-rpc.c
===
--- src/osso-rpc.c (revision 1007)
+++ src/osso-rpc.c (working copy)
@@ -96,7 +96,7 @@
if(first_arg_type != DBUS_TYPE_INVALID)
_append_args(msg, first_arg_type, var_args);
-dbus_message_set_auto_activation(msg, TRUE);
+dbus_message_set_auto_start(msg, TRUE);
if(retval == NULL) {
dbus_message_set_no_reply(msg, TRUE);
@@ -261,7 +261,7 @@
if(msg == NULL)
return OSSO_ERROR;
-dbus_message_set_auto_activation(msg, TRUE);
+dbus_message_set_auto_start(msg, TRUE);
if(first_arg_type != DBUS_TYPE_INVALID)
_append_args(msg, first_arg_type, var_args);
@@ -412,9 +412,10 @@
dbus_error_init(&err);
-dprint("acquiring service '%s'", service);
-i = dbus_bus_acquire_service(use_system_bus?osso->sys_conn:osso->conn,
- service, 0, &err);
+dprint("requesting service '%s'", service);
+
+i = dbus_bus_request_name (use_system_bus?osso->sys_conn:osso->conn,
+ service, 0, &err);
#ifdef LIBOSSO_DEBUG
if(i <= 0) {
if(i == 0) {
@@ -644,7 +645,7 @@
reply = dbus_message_new_error(msg, err_name, retval.value.s);
}
if(reply != NULL) {
- int serial;
+ dbus_uint32_t serial;
dprint("sending message to '%s'",
dbus_message_get_destination(reply));
@@ -687,15 +688,11 @@
case DBUS_TYPE_STRING:
s = va_arg(var_args, gchar *);
if(s == NULL)
- dbus_message_append_args(msg, DBUS_TYPE_NIL,
+ dbus_message_append_args(msg, DBUS_TYPE_INT32,
DBUS_TYPE_INVALID);
else
dbus_message_append_args(msg, type, s, DBUS_TYPE_INVALID);
break;
- case DBUS_TYPE_NIL:
- dbus_message_append_args(msg, DBUS_TYPE_NIL,
- DBUS_TYPE_INVALID);
- break;
default:
break;
}
@@ -736,14 +733,11 @@
case DBUS_TYPE_STRING:
dprint("Appending STR:'%s'",arg->value.s);
if(arg->value.s == NULL)
- dbus_message_append_args(msg, DBUS_TYPE_NIL, DBUS_TYPE_INVALID);
+ dbus_message_append_args(msg, DBUS_TYPE_INT32, DBUS_TYPE_INVALID);
else
dbus_message_append_args(msg, DBUS_TYPE_STRING, arg->value.s,
DBUS_TYPE_INVALID);
break;
- case DBUS_TYPE_NIL:
- dbus_message_append_args(msg, DBUS_TYPE_NIL, DBUS_TYPE_INVALID);
- break;
default:
break;
}
@@ -760,23 +754,23 @@
retval->type = dbus_message_iter_get_arg_type(iter);
switch(retval->type) {
case DBUS_TYPE_INT32:
- retval->value.i = dbus_message_iter_get_int32(iter);
+ dbus_message_iter_get_basic (iter, &retval->value.i);
dprint("got INT32:%d",retval->value.i);
break;
case DBUS_TYPE_UINT32:
- retval->value.u = dbus_message_iter_get_uint32(iter);
+ dbus_message_iter_get_basic (iter, &retval->value.u);
dprint("got UINT32:%u",retval->value.u);
break;
case DBUS_TYPE_BOOLEAN:
- retval->value.b = dbus_message_iter_get_boolean(iter);
Re: [maemo-developers] A few questions about the development platforms internals
Disregard previous "dbus upgrade" patch for libosso, and use this one
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
Index: src/osso-hw.c
===
--- src/osso-hw.c (revision 1007)
+++ src/osso-hw.c (working copy)
@@ -405,7 +405,7 @@
return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
}
-new_state = dbus_message_iter_get_boolean(&i);
+dbus_message_iter_get_basic (&i, &new_state);
if (osso->hw_state.system_inactivity_ind != new_state) {
osso->hw_state.system_inactivity_ind = new_state;
if (osso->hw_cbs.system_inactivity_ind.set) {
Index: src/osso-state.c
===
--- src/osso-state.c (revision 1007)
+++ src/osso-state.c (working copy)
@@ -23,6 +23,9 @@
#include "osso-state.h"
#include "osso-log.h"
+static osso_return_t _write_state(const gchar *statefile, osso_state_t *state);
+static osso_return_t _read_state(const gchar *statefile, osso_state_t *state);
+
/**
* This internal function performs a simple validation for the application
* and version information of the osso_context regarding their validity
Index: src/osso-rpc.c
===
--- src/osso-rpc.c (revision 1007)
+++ src/osso-rpc.c (working copy)
@@ -96,7 +96,7 @@
if(first_arg_type != DBUS_TYPE_INVALID)
_append_args(msg, first_arg_type, var_args);
-dbus_message_set_auto_activation(msg, TRUE);
+dbus_message_set_auto_start(msg, TRUE);
if(retval == NULL) {
dbus_message_set_no_reply(msg, TRUE);
@@ -261,7 +261,7 @@
if(msg == NULL)
return OSSO_ERROR;
-dbus_message_set_auto_activation(msg, TRUE);
+dbus_message_set_auto_start(msg, TRUE);
if(first_arg_type != DBUS_TYPE_INVALID)
_append_args(msg, first_arg_type, var_args);
@@ -412,9 +412,10 @@
dbus_error_init(&err);
-dprint("acquiring service '%s'", service);
-i = dbus_bus_acquire_service(use_system_bus?osso->sys_conn:osso->conn,
- service, 0, &err);
+dprint("requesting service '%s'", service);
+
+i = dbus_bus_request_name (use_system_bus?osso->sys_conn:osso->conn,
+ service, 0, &err);
#ifdef LIBOSSO_DEBUG
if(i <= 0) {
if(i == 0) {
@@ -644,7 +645,7 @@
reply = dbus_message_new_error(msg, err_name, retval.value.s);
}
if(reply != NULL) {
- int serial;
+ dbus_uint32_t serial;
dprint("sending message to '%s'",
dbus_message_get_destination(reply));
@@ -687,15 +688,11 @@
case DBUS_TYPE_STRING:
s = va_arg(var_args, gchar *);
if(s == NULL)
- dbus_message_append_args(msg, DBUS_TYPE_NIL,
+ dbus_message_append_args(msg, DBUS_TYPE_INT32,
DBUS_TYPE_INVALID);
else
dbus_message_append_args(msg, type, s, DBUS_TYPE_INVALID);
break;
- case DBUS_TYPE_NIL:
- dbus_message_append_args(msg, DBUS_TYPE_NIL,
- DBUS_TYPE_INVALID);
- break;
default:
break;
}
@@ -736,14 +733,11 @@
case DBUS_TYPE_STRING:
dprint("Appending STR:'%s'",arg->value.s);
if(arg->value.s == NULL)
- dbus_message_append_args(msg, DBUS_TYPE_NIL, DBUS_TYPE_INVALID);
+ dbus_message_append_args(msg, DBUS_TYPE_INT32, DBUS_TYPE_INVALID);
else
dbus_message_append_args(msg, DBUS_TYPE_STRING, arg->value.s,
DBUS_TYPE_INVALID);
break;
- case DBUS_TYPE_NIL:
- dbus_message_append_args(msg, DBUS_TYPE_NIL, DBUS_TYPE_INVALID);
- break;
default:
break;
}
@@ -760,23 +754,23 @@
retval->type = dbus_message_iter_get_arg_type(iter);
switch(retval->type) {
case DBUS_TYPE_INT32:
- retval->value.i = dbus_message_iter_get_int32(iter);
+ dbus_message_iter_get_basic (iter, &retval->value.i);
dprint("got INT32:%d",retval->value.i);
break;
case DBUS_TYPE_UINT32:
- retval->value.u = dbus_message_iter_get_uint32(iter);
+ dbus_message_iter_get_basic (iter, &retval->value.u);
dprint("got UINT32:%u",retval->value.u);
break;
case DBUS_TYPE_BOOLEAN:
- retval->value.b = dbus_message_iter_get_boolean(iter);
+ dbus_message_iter_get_basic (iter, &retval->value.b);
dprint("got BOOLEAN:%s",retval->value.s?"TRUE":"FALSE");
break;
case DBUS_TYPE_DOUBLE:
- retval->value.d = dbus_message_iter_get_double(iter);
+ dbus_message_iter_get_basic (iter, &retval->value.d);
dprint("got DOUBLE:%f",retval->value.d);
break;
case DBUS_TYPE_STRING:
- str = dbus_message_iter_get_string (iter);
+ dbus_message_iter_get_bas
Re: [maemo-developers] A few questions about the development platforms internals
This patch upgrades the D-BUS version of hildon-control-panel
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
Index: hildon-control-panel-main.c
===
--- hildon-control-panel-main.c (revision 1007)
+++ hildon-control-panel-main.c (working copy)
@@ -905,12 +905,13 @@
confirm_dialog = hildon_note_new_confirmation
(GTK_WINDOW(state_data.window),
RESET_FACTORY_SETTINGS_INFOBANNER);
-
+ /* TODO:
hildon_note_set_button_texts
(HILDON_NOTE(confirm_dialog),
RESET_FACTORY_SETTINGS_INFOBANNER_CLOSE_ALL,
RESET_FACTORY_SETTINGS_INFOBANNER_CANCEL);
-
+ */
+
gtk_widget_show_all(confirm_dialog);
i = gtk_dialog_run(GTK_DIALOG(confirm_dialog));
@@ -929,6 +930,7 @@
GtkWidget *pw_dialog = (hildon_get_password_dialog_new(
GTK_WINDOW(state_data.window), FALSE));
+/* TODO
hildon_get_password_dialog_set_title
(HILDON_GET_PASSWORD_DIALOG(pw_dialog),
RESET_FACTORY_SETTINGS_PASSWORD_DIALOG_TITLE);
@@ -936,7 +938,7 @@
hildon_get_password_dialog_set_caption
(HILDON_GET_PASSWORD_DIALOG(pw_dialog),
RESET_FACTORY_SETTINGS_PASSWORD_DIALOG_CAPTION);
-/*
+
hildon_get_password_dialog_set_max_characters
(HILDON_GET_PASSWORD_DIALOG(pw_dialog),
HILDON_CP_ASSUMED_LOCKCODE_MAXLENGTH);
@@ -1228,7 +1230,7 @@
if(first_arg_type != DBUS_TYPE_INVALID)
_append_args(msg, first_arg_type, var_args);
-dbus_message_set_auto_activation(msg, FALSE);
+dbus_message_set_auto_start(msg, FALSE);
dbus_error_init(&err);
timeout_retval = osso_rpc_get_timeout(osso, &timeout);
@@ -1300,15 +1302,11 @@
case DBUS_TYPE_STRING:
s = va_arg(var_args, gchar *);
if(s == NULL)
- dbus_message_append_args(msg, DBUS_TYPE_NIL,
+ dbus_message_append_args(msg, DBUS_TYPE_INT32,
DBUS_TYPE_INVALID);
else
dbus_message_append_args(msg, type, s, DBUS_TYPE_INVALID);
break;
- case DBUS_TYPE_NIL:
- dbus_message_append_args(msg, DBUS_TYPE_NIL,
- DBUS_TYPE_INVALID);
- break;
default:
break;
}
@@ -1325,33 +1323,36 @@
retval->type = dbus_message_iter_get_arg_type(iter);
switch(retval->type) {
case DBUS_TYPE_INT32:
- retval->value.i = dbus_message_iter_get_int32(iter);
+ dbus_message_iter_get_basic (iter, &retval->value.i);
dprint("got INT32:%d",retval->value.i);
break;
case DBUS_TYPE_UINT32:
- retval->value.u = dbus_message_iter_get_uint32(iter);
+ dbus_message_iter_get_basic(iter, &retval->value.u);
dprint("got UINT32:%u",retval->value.u);
break;
case DBUS_TYPE_BOOLEAN:
- retval->value.b = dbus_message_iter_get_boolean(iter);
+ dbus_message_iter_get_basic (iter, &retval->value.b);
dprint("got BOOLEAN:%s",retval->value.s?"TRUE":"FALSE");
break;
case DBUS_TYPE_DOUBLE:
- retval->value.d = dbus_message_iter_get_double(iter);
+ dbus_message_iter_get_basic (iter, &retval->value.d);
dprint("got DOUBLE:%f",retval->value.d);
break;
case DBUS_TYPE_STRING:
- retval->value.s =
- g_strdup(dbus_message_iter_get_string(iter));
+ {
+char *str;
+ dbus_message_iter_get_basic (iter, &str);
+
+ retval->value.s = g_strdup(str);
+ dbus_free (str);
+
if(retval->value.s == NULL) {
retval->type = DBUS_TYPE_INVALID;
}
dprint("got STRING:'%s'",retval->value.s);
+ }
break;
- case DBUS_TYPE_NIL:
- retval->value.s = NULL;
- dprint("got NIL");
- break;
+
default:
retval->type = DBUS_TYPE_INVALID;
retval->value.i = 0;
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] A few questions about the development platforms internals
This patch upgrades the D-BUS version of maemo-af-desktop
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
Index: hildon-status-bar/hildon-status-bar-main.c
===
--- hildon-status-bar/hildon-status-bar-main.c (revision 1007)
+++ hildon-status-bar/hildon-status-bar-main.c (working copy)
@@ -298,8 +298,7 @@
val[0]->type != DBUS_TYPE_STRING ||
val[1]->type != DBUS_TYPE_INT32 ||
val[2]->type != DBUS_TYPE_INT32 ||
-( val[3]->type != DBUS_TYPE_STRING &&
- val[3]->type != DBUS_TYPE_NIL ) )
+( val[3]->type != DBUS_TYPE_STRING ) )
{
retval->type = DBUS_TYPE_STRING;
if( arguments->len < 4 )
@@ -313,7 +312,7 @@
val[3]->type,
DBUS_TYPE_STRING, DBUS_TYPE_INT32,
DBUS_TYPE_INT32, DBUS_TYPE_STRING,
- DBUS_TYPE_NIL);
+ DBUS_TYPE_INT32);
}
osso_log( LOG_ERR, retval->value.s );
if(retval->value.s){
@@ -354,8 +353,7 @@
val[1]->type != DBUS_TYPE_INT32 ||
val[2]->type != DBUS_TYPE_INT32 ||
val[3]->type != DBUS_TYPE_STRING ||
- (arguments->len == 5 && val[5]->type != DBUS_TYPE_NIL
- ) )
+ (arguments->len == 5 ) )
{
retval->type = DBUS_TYPE_STRING;
if( arguments->len < 5 ) {
Index: hildon-navigator/others-menu.c
===
--- hildon-navigator/others-menu.c (revision 1007)
+++ hildon-navigator/others-menu.c (working copy)
@@ -413,7 +413,7 @@
static void others_menu_changed_cb( char *path, _om_changed_cb_data_t *data )
{
/* Remove callbacks */
- hildon_dnotify_remove_every_cb();
+ /* TODO: hildon_dnotify_remove_every_cb(); */
/* Destroy the menu */
gtk_widget_destroy( data->widget );
Index: hildon-navigator/osso-manager.c
===
--- hildon-navigator/osso-manager.c (revision 1007)
+++ hildon-navigator/osso-manager.c (working copy)
@@ -241,7 +241,7 @@
con = (DBusConnection *)osso_get_dbus_connection(man->osso);
dbus_error_init(&error);
-n = dbus_bus_service_exists(con,buf,&error);
+n = dbus_bus_name_has_owner(con,buf,&error);
if (dbus_error_is_set(&error))
{
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] A few questions about the development platforms internals
On Wed, 2005-09-28 at 10:51 +0200, Philip Van Hoof wrote: > o. What is libmb? > > [EMAIL PROTECTED]:~/cvs/maemo/trunk $ find . -name libmb.pc > [EMAIL PROTECTED]:~/cvs/maemo/trunk $ find . -name mb.pc > [EMAIL PROTECTED]:~/cvs/maemo/trunk $ Aha, that is libmatchbox > o. What is libouto? > > [EMAIL PROTECTED]:~/cvs/maemo/trunk $ find . -name outo > [EMAIL PROTECTED]:~/cvs/maemo/trunk $ And this is for unit testing, right? -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] A few questions about the development platforms internals
Oh, about the attachment of previous E-mail. I ported libosso to a newer D-BUS version. Note that I can't compile the other D-BUS parts because I don't have or know about the libmb and libouto libraries. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] A few questions about the development platforms internals
Hi there,
I was wondering
o. Why isn't libosso created as a clean and correct GObject library?
This would have made it more easy to create language bindings. No?
I could imagine a GObject would be dangerous if you'd use a lot
threading (and then still it's manageable and are people working on
fixing those issues), but I don't see a lot other thread-safety related
code in the library. So I'm assuming that isn't an issue?
Because ... osso_context_t (and osso_af_context_t) isn't inheriting from
GObject. So that must mean that it isn't GObject? And if it would, I'd
rather make more objects in stead of only a context one (but, okay .. I
can live with that).
o. What is libmb?
[EMAIL PROTECTED]:~/cvs/maemo/trunk $ find . -name libmb.pc
[EMAIL PROTECTED]:~/cvs/maemo/trunk $ find . -name mb.pc
[EMAIL PROTECTED]:~/cvs/maemo/trunk $
o. What is libouto?
[EMAIL PROTECTED]:~/cvs/maemo/trunk $ find . -name outo
[EMAIL PROTECTED]:~/cvs/maemo/trunk $
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
Index: osso-state.c
===
--- osso-state.c (revision 1007)
+++ osso-state.c (working copy)
@@ -23,6 +23,9 @@
#include "osso-state.h"
#include "osso-log.h"
+static osso_return_t _write_state(const gchar *statefile, osso_state_t *state);
+static osso_return_t _read_state(const gchar *statefile, osso_state_t *state);
+
/**
* This internal function performs a simple validation for the application
* and version information of the osso_context regarding their validity
Index: osso-rpc.c
===
--- osso-rpc.c (revision 1007)
+++ osso-rpc.c (working copy)
@@ -96,7 +96,7 @@
if(first_arg_type != DBUS_TYPE_INVALID)
_append_args(msg, first_arg_type, var_args);
-dbus_message_set_auto_activation(msg, TRUE);
+dbus_message_set_auto_start(msg, TRUE);
if(retval == NULL) {
dbus_message_set_no_reply(msg, TRUE);
@@ -261,7 +261,7 @@
if(msg == NULL)
return OSSO_ERROR;
-dbus_message_set_auto_activation(msg, TRUE);
+dbus_message_set_auto_start(msg, TRUE);
if(first_arg_type != DBUS_TYPE_INVALID)
_append_args(msg, first_arg_type, var_args);
@@ -412,9 +412,10 @@
dbus_error_init(&err);
-dprint("acquiring service '%s'", service);
-i = dbus_bus_acquire_service(use_system_bus?osso->sys_conn:osso->conn,
- service, 0, &err);
+dprint("requesting service '%s'", service);
+
+i = dbus_bus_request_name (use_system_bus?osso->sys_conn:osso->conn,
+ service, 0, &err);
#ifdef LIBOSSO_DEBUG
if(i <= 0) {
if(i == 0) {
@@ -644,7 +645,7 @@
reply = dbus_message_new_error(msg, err_name, retval.value.s);
}
if(reply != NULL) {
- int serial;
+ dbus_uint32_t serial;
dprint("sending message to '%s'",
dbus_message_get_destination(reply));
@@ -687,15 +688,11 @@
case DBUS_TYPE_STRING:
s = va_arg(var_args, gchar *);
if(s == NULL)
- dbus_message_append_args(msg, DBUS_TYPE_NIL,
+ dbus_message_append_args(msg, DBUS_TYPE_INT32,
DBUS_TYPE_INVALID);
else
dbus_message_append_args(msg, type, s, DBUS_TYPE_INVALID);
break;
- case DBUS_TYPE_NIL:
- dbus_message_append_args(msg, DBUS_TYPE_NIL,
- DBUS_TYPE_INVALID);
- break;
default:
break;
}
@@ -736,14 +733,11 @@
case DBUS_TYPE_STRING:
dprint("Appending STR:'%s'",arg->value.s);
if(arg->value.s == NULL)
- dbus_message_append_args(msg, DBUS_TYPE_NIL, DBUS_TYPE_INVALID);
+ dbus_message_append_args(msg, DBUS_TYPE_INT32, DBUS_TYPE_INVALID);
else
dbus_message_append_args(msg, DBUS_TYPE_STRING, arg->value.s,
DBUS_TYPE_INVALID);
break;
- case DBUS_TYPE_NIL:
- dbus_message_append_args(msg, DBUS_TYPE_NIL, DBUS_TYPE_INVALID);
- break;
default:
break;
}
@@ -760,23 +754,23 @@
retval->type = dbus_message_iter_get_arg_type(iter);
switch(retval->type) {
case DBUS_TYPE_INT32:
- retval->value.i = dbus_message_iter_get_int32(iter);
+ dbus_message_iter_get_basic (iter, &retval->value.i);
dprint("got INT32:%d",retval->value.i);
break;
case DBUS_TYPE_UINT32:
- retval->value.u = dbus_message_iter_get_uint32(iter);
+ dbus_message_iter_get_basic (iter, &retval->value.u);
dprint("got UINT32:%u",retval->value.u);
break;
case DBUS_TYPE_BOOLEAN:
- retval->value.b = dbus_message_iter_get_boolean(iter);
+ dbus_message_iter_get_basic (iter, &retval->value.b);
dprint("got BOOLEAN:%s",retval->value.s?"TRUE":"FALSE&q
Re: [Evolution-hackers] Re: [maemo-developers] Ross' D-BUS port of evolution-data-server on maemo x86
On Wed, 2005-09-28 at 09:37 +0300, Tor Lillqvist wrote: > On on, 2005-09-28 at 01:39 +0200, Philip Van Hoof wrote: > > > However. Building "servers" first also temporarily fixes the issue. > > But shouldn't it have been built first in any case? It's mentioned first > in e-d-s/Makefile.am's SUBDIRS. > Perhaps is the groupware-server/provider target in another targets _DEPENDENCIES (and does it get build long before it should get build)? Well, it's a strange problem indeed. Also because it doesn't get fixed by adding a _DEPENDENCIES to the target in question. But I've had many autotools related strange problems like this before :( -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Ross' D-BUS port of evolution-data-server on maemo x86
On Tue, 2005-09-27 at 01:04 +0200, Philip Van Hoof wrote: Hey Ross, I noticed you've read this thread, [CUT] > ps. It stops here. But I'm not sure whether this is related to the Maemo > platform, since I can reproduce this build-error on a non scratchbox > environment. > > se-transport.Tpo -c camel-groupwise-transport.c -fPIC -DPIC > -o .libs/camel-groupwise-transport.o > make[4]: *** No rule to make target > `../../../servers/groupwise/libegroupwise-1.2.la', needed by > `libcamelgroupwise.la'. Stop. > make[4]: Leaving directory > `/home/freax/dev/evolution-data-server/camel/providers/groupwise' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory > `/home/freax/dev/evolution-data-server/camel/providers' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/home/freax/dev/evolution-data-server/camel' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/freax/dev/evolution-data-server' > make: *** [all] Error 2 > [sbox-SDK_PC: ~/dev/evolution-data-server] > This should be fixable using a DEPENDENCIES macro in the Makefile.am, but it doesn't fix the problem for me (guessing this is a autotools issue). However. Building "servers" first also temporarily fixes the issue. Other than that what I basically had to do was to disable groupwise. And then everything works out fine. http://pvanhoof.be/files/eds_on_maemo.png I can send you a patch if you like, but I don't think it's going to be very useful. It basically disables all the groupwise stuff . . . -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] TomTom on Maemo/Nokia 770?
Hi there, At our company (X-Tend) we'd be very interested in having the option to let TomTom run on the Nokia 770. Are there plans (at TomTom) to sell/package their software in such a way that it's installable and usable on the Nokia 770? -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Ross' D-BUS port of evolution-data-server on maemo x86
On Tue, 2005-09-27 at 09:03 +0300, Kalle Vahlman wrote: > You might get it running, but even without any thorough meditation on > this, I'd say you need to dump most of the UI anyway to make it > feasible for usage on the device. Not only due to the small screen > size[1], but also for performance reasons. The device is very limited > memory wise (for desktop app scale), and basically you don't need or > can to have all the options present for a device like this. Of course, however. A lot of the functionality of evolution is being implemented in evolution-data-server. Creating a new specialised shell is also feasible. Evolution-data-server is less memory intensive than the (current) shell. ps. I altered the Evolution mailing list address in the CC header, because that mailing list has changed since a few months. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Ross' D-BUS port of evolution-data-server on maemo x86
Hi there fellow hackitiehackers,
I've just tried compiling libsoup and Ross's D-BUS port of evolution-
data-server on Maemo-x86 in a scratchbox.
Note that this is only the first part of evolution, of course. The shell
is, of course, the most difficult part. Mainly because it heavily relies
on Bonobo and ORBit-2. So to get Evolution running on Maemo, it might be
more easy to get ORBit-2/Bonobo running first rather than to attempt
removing this dependency right now.
I had to alter the configure.in of Ross's evolution-data-server a little
bit. I attached the patch.
evolution-data-server has been configured as follows:
LDAP support: no
NNTP support: yes
LibSoup support:yes
Kerberos 4/5: no/no
SSL support: no
SMIME support:no
IPv6 support: yes
Exchange support: no
Dot Locking: yes
File Locking: fcntl
Gtk Doc: no
Steps:
cvs -z3 co -r gnome-2-10 libsoup
cd libsoup
./autogen.sh --prefix=/opt/evo
make
make install
cd ..
cd evolution-data-server/trunk
patch < patch.diff
PKG_CONFIG_PATH=/opt/evo/lib/pkgconfig ./autogen.sh --with-dbus=yes
--with-libgnome=no --prefix=/opt/evo/
make
make install
ps. It stops here. But I'm not sure whether this is related to the Maemo
platform, since I can reproduce this build-error on a non scratchbox
environment.
se-transport.Tpo -c camel-groupwise-transport.c -fPIC -DPIC
-o .libs/camel-groupwise-transport.o
make[4]: *** No rule to make target
`../../../servers/groupwise/libegroupwise-1.2.la', needed by
`libcamelgroupwise.la'. Stop.
make[4]: Leaving directory
`/home/freax/dev/evolution-data-server/camel/providers/groupwise'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/home/freax/dev/evolution-data-server/camel/providers'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/freax/dev/evolution-data-server/camel'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/freax/dev/evolution-data-server'
make: *** [all] Error 2
[sbox-SDK_PC: ~/dev/evolution-data-server] >
By the way, Nokia dudes: We are waiting for the device to become
available here in Belgium. Oh and ... since I won one at Guadec. I can't
wait! Send it! :-) *spasm, spasm*
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
Index: configure.in
===
--- configure.in (revision 212)
+++ configure.in (working copy)
@@ -1124,6 +1124,7 @@
AC_MSG_RESULT($with_dbus)
dnl Should we use libgnome functions or not
+if test "x${with_dbus}" = "xno"; then
AC_MSG_CHECKING(if we should use libgnome)
AC_ARG_WITH(libgnome, [ --with-libgnome=[yes,no]Disable the use of libgnome.],
with_libgnome="$withval", with_libgnome="yes")
@@ -1131,9 +1132,10 @@
AC_DEFINE(WITH_LIBGNOME, 1, [Define if libgnome should be used])
fi
AC_MSG_RESULT($with_libgnome)
+fi
if test "x${with_dbus}" = "xno"; then
-AM_PATH_ORBIT2(2.9.8)
+dnl AM_PATH_ORBIT2(2.9.8)
AC_MSG_CHECKING(for CORBA include paths)
IDL_INCLUDES="-I "`pkg-config --variable=idldir libbonobo-2.0`" -I "`pkg-config --variable=idldir bonobo-activation-2.0`
@@ -1145,12 +1147,14 @@
IPC_DEPS="dbus-glib-1"
fi
+if test "x${with_dbus}" = "xno"; then
if test "x${with_libgnome}" != "xno"; then
AC_MSG_CHECKING(for libgnomeui server directory)
GNOMEUI_SERVERDIR="`$PKG_CONFIG --variable=libgnomeui_serverdir libgnomeui-2.0`"
AC_MSG_RESULT($GNOMEUI_SERVERDIR)
AC_DEFINE_UNQUOTED(GNOMEUI_SERVERDIR, "$GNOMEUI_SERVERDIR", [Path where we can find gnome_segv2])
fi
+fi
dnl Utility macro to set compiler flags for a specific lib.
dnl EVO_SET_COMPILE_FLAGS(VAR-PREFIX, DEPS, EXTRA-CFLAGS, EXTRA-LIBS)
@@ -1172,7 +1176,11 @@
AC_SUBST(E_DATA_SERVER_CFLAGS)
AC_SUBST(E_DATA_SERVER_LIBS)
+if test "x${with_dbus}" = "xno"; then
E_DATA_SERVER_UI_DEPS="gtk+-2.0 libglade-2.0 gconf-2.0 libgnome-2.0"
+else
+E_DATA_SERVER_UI_DEPS="gtk+-2.0 libglade-2.0 gconf-2.0"
+fi
EVO_SET_COMPILE_FLAGS(E_DATA_SERVER_UI, $E_DATA_SERVER_UI_DEPS, $THREADS_CFLAGS, $THREADS_LIBS)
AC_SUBST(E_DATA_SERVER_UI_CFLAGS)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
