Re: Google Summer of Code 2011
Hi, Max Usachev wrote: I wonder to know, if Nokia and Maemo community will participate in GSoC 2011 as last years? I think it's a good chance to help Maemo platform in so hard time for community and Nokia. That depends partly on the Maemo community, such as it is (you need mentors, project proposals, and an application to Google), and partly on Google (they may not want to fund Nokia's cast-offs, to be frank). If there is not sufficient community interest within Maemo to put in a Maemo proposal, then there won't be any Maemo GSoC projects, for sure. Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Nokia and MS
Hi, Hämäläinen Kimmo wrote: On Mon, 2011-02-14 at 13:07 +0100, ext Nils Faerber wrote: ... I am very sceptical about all that and don't really buy that redefintion of MeeGo within Nokia as a learning platform for future disruptions. Even if it somehow survives within Nokia as a side project for geeks, it won't receive serious support, just as Maemo never did. I heard Intel is still working on future MeeGo devices. Yes! I imagine that Intel will also be happy to see Atom chips in smartphones in the near future, and will be happy to see a good clean reference smartphone UX available. The question is whether we'll get one, and whether Nokia will open up all of the UX app work they're doing on top of the MeeGo stack once the device is on the market. If that happens, and anyone can take MeeGo put it on a phone in the same way they can with Android, the handset UX has a small but fighting chance. My understanding of Nokia's position, put simply, is We don't think there's a future in MeeGo on smartphones, but we're not sure, so we're going to hedge our bets and keep our hand in. Also, we signed a big partnership agreement to do MeeGo, and backing out of it now would cost us a ton of money. We'll do the minimum that the partnership requires. On the other hand, I still don't find it interesting to talk about Nokia's MeeGo strategy, but I *do* think it's useful to discuss the post-Elopocalyse MeeGo strategy. Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: adaptation of Extras QA hurdles
Hi Roman, Roman Morawek wrote: I uploaded a new release of my application (http://maemo.org/packages/view/babyphone/) on 5th of November, so more than 2.5 months ago. Right now, I have 6 positive votes (including mine) - thus 60% of the demanded hurdle. I guess my application is not one of the top apps, but downloaded ca. 100.000 times. So I expect it is also used and not only positioned in an extreme niche. I think that such a period for a new release is too long. I agree with you. I have never been completely happy with the Maemo Extras QA process, and now that Maemo is no longer a primary focus for many in the community, I think that it would be reasonable to lower any bounds to promotion which we had in the past to new levels. We should ensure that we have some protection against malicious spammy application uploads, but no more - a developer in good faith should be able to ship his application quite easily in Extras. Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Cannot upload screenshot: maemo.org bug
Hi, Daniel Klaffenbach wrote: I have discovered a bug in the maemo.org Downloads area. I have already filed a bug[1] about this two months ago, but nobody seems to care. Ready, fire, aim, eh? Nobody seems to care doesn't really seem fair, given that you opened the bug then there were no further comments at all. Your second comment was around the same time you sent this email, and since then there has been some activity. Maybe this is due to the fact that the platform/website is considered abandoned - I don't know. Since many people are still using Maemo devices and the maemo.org website I would hope that there is still some interest in fixing website bugs. With this tone, you're not really rubbing the people in a position to help up the right way. I don't want to pick on you, but a little stick, a little carrot wouldn't hurt. The platform is not abandoned (and saying so is reflecting badly on the people maintaining it). What can I do against this? Is this really a bug? Do I need special permissions to upload screenshots? Who could fix this? Unfortunately, I am not aware of the list of people who are in a position to debug fix this problem, I know that Niels can, and I assume that Ferenc also has access to the downloads site, but I'm not sure how well he knows it. Outside of that I don't know of a definitive list. Niels, perhaps you could help out by providing one I'll document it? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Discontinue distributing Maemo Bug Jars via email?
Hi, Thomas Perl wrote: I don't like the fact that bug jars are sent several at once, but I can just select all these mails and archive them at once - no big problem. Maybe you can merge them into one single mail per week? Interesting - indeed, getting them all at once is one of the things I don't like so much (as I said on the meego list, though, I definitely like getting an email). On the meego list, I suggested that sending one email with a link to the full online report and a one line summary of changes to the key figures for each of the bug jars might be good enough. What Thomas says here gives me another idea - one bug jar per day - Monday could be the dev bug jar, Tuesday community infrastructure, Wednesday documentation, etc. - no big mail dump, and different teams have a regular rendez vous every week. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maintainer policy - maintainer has disappeared
Hi, Adam Baxter wrote: The maintainer for the zoutube application seems to have disappeared from the face of the Earth and there is a critical bug in the stable version of zoutube - i.e. it doesn't work anymore. There is a fix waiting to be pulled into the maintainer's git repository but he cannot be contacted. What is Maemo's policy for assigning new maintainers or pushing new versions of packages for packages with no current maintainer? 1. Make a best effort to contact him. 2. Ask Maemo admins to make a best effort to contact him. 3. Volunteer to take over maintainership to original maintainer Maemo admins Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Porting Maemo to MeeGo
Hi, ds wrote: is there a guide, howto or something simelar on porting Maemo Apps (e.g. gtk based) to MeeGo. I could not find on MeeGo and Maemo site:-( Not really. It would be more relevant to MeeGo lists than Maemo lists. Linked from the Qt page in the wiki: http://wiki.maemo.org/Qt there is the Qt for Maemo developers guide on Forum Nokia: http://wiki.forum.nokia.com/index.php/Qt_for_Maemo_Developers_Guide (which is labelled as deprecated, but with no indication of what document replaces it). Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Documentation of Maemo extensions for .desktop files?
Hi all, As I mentioned yesterday, I've been looking unsuccessfully for any documentation of the X-* Maemo extensions to the .desktop file format - which extensions are allowed, and for what. Does anyone know of any document which contains a complete list of custom fields an explanation of their purpose, please? Or, if not, a pointer to the source code of whatever app/library parses these files on Maemo? Thanks! Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Documentation of Maemo extensions for .desktop files?
Hi, Thomas Perl wrote: I think it's in Hildon-Desktop, although you have to look through the source to extract the meaning of each field: Thanks for the pointer! The wiki mentions some other fields (and groups) which I don't see mentioned here. Also, looking at the code I don't see where the standard desktop fields are parsed either. It's at this point that I point people to this article, which seems relevant to the situation I find myself in: http://www.salon.com/21st/feature/1998/05/13feature.html Quote: Over time, the only representation of the original knowledge becomes the code itself, which by now is something we can run but not exactly understand. It has become a process, something we can operate but no longer rethink deeply. Even if you have the source code in front of you, there are limits to what a human reader can absorb from thousands of lines of text designed primarily to function, not to convey meaning. When knowledge passes into code, it changes state; like water turned to ice, it becomes a new thing, with new properties. We use it; but in a human sense we no longer know it. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Reviewing beginner packaging docs
Hi Ville, Ville M. Vainio wrote: Sorry for top posting, I'm doing it to avoid addressing our specific points ;-). 1) You can use my qdebwiz python script to package a stereotypical, simple Qt application for N900: git clone git://gitorious.org/qdebwiz/qdebwiz.git README: http://gitorious.com/qdebwiz/qdebwiz/blobs/master/README tl;dr: it populates a debian/ folder according to stuff you have in (also autogenerated) ini file. The debian/rules currently uses CDBS - works fine on autobuilder and linux madde, doesn't work in windows madde. With a few canned tweaks, your package should be OK for Ovi store as well. 2) If you are not in a hurry, wait for Nokia Qt SDK 1.1 betas. NQS 1.1 (w/ Qt Creator 2.1) has support for real packaging, as opposed to development-mode-only support in earlier NQS releases. So - your advice to someone looking to package a Hildon application for Fremantle would be to rewrite it as a Qt app? Or will qdebwiz also work with Hildon apps? Or perhaps I'm misunderstanding you, and you're suggesting that developers should use whatever method is appropriate for the upstream build tools, and then handle the packaging afterwards? (which seems like sensible advice). Thanks! Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Reviewing beginner packaging docs
Hi, Ville M. Vainio wrote: On Thu, Oct 14, 2010 at 11:07 AM, Dave Neary dne...@maemo.org wrote: Or perhaps I'm misunderstanding you, and you're suggesting that developers should use whatever method is appropriate for the upstream build tools, and then handle the packaging afterwards? (which seems like sensible advice). Actually, I wasn't even considering the option that upstream could be someone apart from the packager. That's not the beginner usecase - it's something for a separate porting guide (outlining what you need to change when porting stuff from debian/ubuntu). Well, there's what you use to build your software and what you use to install it. If you're building your software with autotools, you get a bunch of helper scripts for your packaging coming along for the ride. You also get make install and make dist for free. If you're building your software with a Qt project, you also have a standard way of installing software. And usually software writers don't particularly want to install their software on only one distribution, you'll often get .tar.gz, .rpm and .deb versions of the same package. Also, one of the typical beginner strategies I see is someone who takes existing desktop software tries to adapt it for the N900. So there's an existing build infrastructure in place already. We don't really want to create the illusion that it's ok for a beginner to create a project using autotools/cmake and expect everything to work - we would be doing them a disservice. It was ok in the early days of maemo5, but nowadays things we push should work with MADDE and Nokia Qt SDK as well. I disagree. MADDE and Nokia Qt SDK may be the future for MeeGo, but when we're talking about Maemo 5 documentation, Hildon is still the reccommended UI toolkit and we should ensure that people coming to Fremantle have good docs. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Reviewing beginner packaging docs
Hi, Felipe Crochik wrote: http://maemo.crochik.com/qt-development/packaging-a-lib-for-maemo Thanks Felipe! A useful contribution - worthy of a wiki page all to itself: Packaging libraries - do you have a few minutes to copy the info over, please? Thanks! Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Reviewing beginner packaging docs
Hi Ville, Ville M. Vainio wrote: You can get make install quite easily with qmake as well. It's a basic boilerplate you attach to your project: http://pastebin.com/QfsRYtqF I'm not saying you can't - I'm only trying to get people up to speed as quickly as possible with their first application installed on their phone. It so happens that since I know autotools best (and, frankly, there's the best docs for it of all the build systems on Maemo) I used that one. Perhaps you would like to help improve things further and create a your first Fremantle Qt app section in the Packaging article, I would welcome that (as it's something I don't know how to do). RST38h has also proposed helping with an example package using plain Makefiles, which I would also welcome. The idea is to make it as easy as possible to get started, without making everything confusing. Right. Do you think that's the average developer though? Perhaps the average new Maemo developer... I disagree. MADDE and Nokia Qt SDK may be the future for MeeGo, but when we're talking about Maemo 5 documentation, Hildon is still the recommended UI toolkit and we should ensure that people coming to Fremantle have good docs. From PR1.2 onwards, Qt is the recommended toolkit, at least if you are doing anything commercial (but you know this already). N900 has an excellent Qt implementation, and with Qt you stand a recent chance of someone being able (and willing) to help you out if you have problems. All of this is somewhat besides the point of your thread, which is to fix the documentation, and I don't wish to act as stop energy on that. It's just that the page http://wiki.maemo.org/Packaging is not really what we'd like to tell random beginners about packaging right now. Please help improve it. But let's not remove all the autotools stuff (which, allow me to repeat, is there because that's how *I* know how to make packages). Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Reviewing beginner packaging docs
Hi, So I got through my troubles today I think that I've managed to understand pretty well the various aspects of packaging, integration with HAM and the application menu. I'd appreciate reviews comments on the updated http://wiki.maemo.org/Packaging page now, please! Dave Neary wrote: So far, here are a few remarks: * At this stage, your package still doesn't have an icon and an entry in the applications menu - which is what I'm having trouble with now. In fact, the entire section Maemo-specific packaging information has entirely too many unstated assumptions. Just to give three examples: * The Desktop files section points to a [[Desktop file format]] page which does nothing to explain how to write a .desktop file I have explained the minimum .desktop file now - where to install it (and how), what the fields mean, and how to load a pixmap for the menu. One thing I'm missing: fcrochik says that icons should be 64x64, and I can't find any reference to that anywhere in the docs. Can someone with knowledge help clear this up (and, in passing, improve the documentation), please? * The paragraph about .install files. There is a line: You can add the desktop file to the .install file for your application so that it is installed to the correct place, for example, if you have debian/application.install, adding the line: application.desktop usr/share/applications/hildon I have deleted the paragraph. .install files need to be mentioned, in the uploading to extras-devel page, but a .deb should (imho) be able to install by itself, without any maemo-specific extensions. So I'm currently stuck trying to figure out how to get an icon file installed how to write install a .desktop file which will load it up. The advice I've gotten so far is good - but can mostly be summarised as download a working package look to see how they did it. And I know I'm still missing a bunch of stuff which will be necessary for the package to go into extras-devel. In the end, my advice is use whatever build system you prefer to install this file in this directory (as specified by this spec/doc) - here's how to do that in autotools. At this point, I can get from blank laptop to Hello, World installed on my N900 by following these in about 45 minutes. Not bad, if I say so myself. Can anyone help make this even better? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
[Fwd: GTK+/MeeGo Handset integration work, call for bids]
Hi all, This announcement looks relevant both to MeeGo and Maemo developers, so I hope people won't mind me forwarding it along (for information). Thanks, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ---BeginMessage--- The GNOME Foundation is looking for developers to enhance the developer experience of using GTK+ to port and create applications on MeeGo Handset devices. Knowledge of the MeeGo Handset development process, and GTK+ internals will be required to carry out the work. The tasks to be achieved are: - Ensure that GTK+ applications display as expected on the MeeGo Handset platform, including checking that fixes to the compositor are made if necessary. - Add to upstream GTK+ helper functionality to create stand-alone GTK+ applications to run on MeeGo. - Merge Hildon widgets functionality into GTK+ upstream, where it makes sense to do so. The money available for the project is $50,000, and the bidder selection will be made by a group including professional consultants with GTK+ and MeeGo experience and GNOME Foundation Board members. Bids should include: - Results of testing stock GTK+ applications on the MeeGo Handset platform - Details of your research into what GTK+ functionality needs to be added to ease porting of stock applications to MeeGo Handset. - The list of widgets and functionality ported from Hildon to upstream GTK+, including a review of how the functionality would be integrated (extending existing widgets, new widgets, etc.) - A time line and schedule for the whole project - References to previous MeeGo, MeeGo Handset, Maemo, or GTK+ work. Note that the goal of the GNOME Foundation for this project is upstream acceptance of the various modifications made during the project. Please send your proposals to board-l...@gnome.org with the subject line MeeGo Handset Bid. Regards ___ foundation-announce mailing list foundation-annou...@gnome.org http://mail.gnome.org/mailman/listinfo/foundation-announce ---End Message--- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Reviewing beginner packaging docs
Hi all, With Dave, we did a pretty good review of the getting started packaging docs a few months ago, which got people to the point where they could get a hello, world package written packaged as a .deb. We didn't go further than that, and so I've spent some time this week acting as a brand new developer, going from virgin laptop to uploading my first package to extras-devel - and there are a few gaps in the docs. This email is just to point some of those out - and to sollicit help in getting things fixed. Please try to look at these docs with the eyes of a new developer to see what information you might need to get up running in half an hour, which just isn't there. IRC has been helpful (esp. timeless, Stskeeps, Venemo) but I'm making only slow progress. So far, here are a few remarks: * We point people getting started to the SDK page: from http://maemo.org/development to http://wiki.maemo.org/Documentation/Maemo_5_Final_SDK_Installation - but once you have a Scratchbox SDK up running, we didn't tell people how to get started developing. I added a where to next section that points at http://wiki.maemo.org/Packaging - the best reference I'm aware of for packaging a new Hello, World application * On the Packaging page, we do a pretty good job of explaining the basics of autotools, and standard Debian packaging. However, if you try to copy the .deb which you will have at the end of the Packaging a .deb section onto an N900 and install it, it wouldn't work because the Section: field in debian/control wasn't mentioned up to that point. I added a section Testing your package which goes into some of the things you need to do to get a package to install. * At this stage, your package still doesn't have an icon and an entry in the applications menu - which is what I'm having trouble with now. In fact, the entire section Maemo-specific packaging information has entirely too many unstated assumptions. Just to give three examples: * We talk about sections (and point to the packaging guidelines) without talking about which file we need to add a section to where in the file * The Desktop files section points to a [[Desktop file format]] page which does nothing to explain how to write a .desktop file * The paragraph about .install files. There is a line: You can add the desktop file to the .install file for your application so that it is installed to the correct place, for example, if you have debian/application.install, adding the line: application.desktop usr/share/applications/hildon Now - do I need to create a file called application.install or is application to be replaced by my package name? How about application.desktop? I *think* that I need to s/application/package name in both... but it's not clear. So I'm currently stuck trying to figure out how to get an icon file installed how to write install a .desktop file which will load it up. The advice I've gotten so far is good - but can mostly be summarised as download a working package look to see how they did it. And I know I'm still missing a bunch of stuff which will be necessary for the package to go into extras-devel. What I would like to see us do is better document the installation process (which files get installed how, what's Debian specific, what's Maemo specific, what applies to everyone), and better document the .desktop format (like, say, explaining which fields have important values that you must set, which fields go together but are facultative, and which fields are mostly decorative/informative) and basically make it trivially easy for someone to create a package, given working source code, which will pass muster for extras-devel, and understand what each step is useful for along the way. Does anyone have some time over the next couple of days to help make this stuff rock? I'd be very happy to see us split pages off (say: a .desktop format reference separate from the here's the 3 required fields in a .desktop file, here's where you create it, here's how you make sure it gets installed in the right place basic docs. Thanks! Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: dbus-send command/python dbus way for launching voip call through GTalk on N900
Hi Praveen, praveen koduru wrote: I am looking for voice call through Gtalk on N900 from command line like dbus-send command or python-dbus. I'm afraid I don't have an answer to your question, but if/when you get an answer, would you mind taking a minute to synthesise it into a use-case in the wiki, please? It will help enrich it as a knowledge base for those coming after you. You might consider using the use-case template at http://wiki.maemo.org/Documentation/Use_case_template and adding the page to the bottom of http://wiki.maemo.org/Documentation (perhaps the page name could be http://wiki.maemo.org/Launching_GTalk_voice_call ?) Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Camera initialization in Conversations
hi Stefan, Stefan Krastanov wrote: I would like to see the code used for managing the camera in the build-in IM client. My problem is that I haven't found any good documentation. Can someone from the more experienced devs point me to the packages concerned with the initialization of the video source (if someone can give me the name of the source file/package or a function/class/call name this would be great). Just to clarify, are you requesting a pointer to the source code for the IM client, or are you looking for a code snippet which you can use to initialise the camera as a video source? I am not sure if the video initialisation in the built-in IM app is free software, but I am sure that there *is* free software which you can use to see how the camera can be initialised. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Camera initialization in Conversations
Hi Stefan, Stefan Krastanov wrote: I have an idea how to do it on my own, but I was interested in seeing (and modifying) it in the IM app. I had the idea to make it switch to the main camera on dbus signal from the lens-cover. I can do it for a code that I am writing but I would like to try it in the build-in app. To my knowledge (but I'm open to correction) the Maemo messaging application is not free software - I'm afraid that I can't point you to its source code :} Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Bug #10519: qt-maemo-gravity-example has obsolete Qt configuration
Hi all, https://bugs.maemo.org/show_bug.cgi?id=10519 I would like to sollicit help to confirm fix or close this bug - I would like to have a patch to the example that works with PR 1.2 and earlier (and ideally will continue to work with PR = 1.3). I'm not set up to even confirm the bug, I'm afraid, so I definitely would appreciate someone doing Qt development on Maemo 5 getting the source code, trying to compile with PR 1.2, confirming the bug, and ideally helping by submitting a patch. Anyone have some time to have a look? Thanks! Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt SQL Browser/Manager Application - is there one?
Hi, Christian Kandeler wrote: On 09/23/2010 04:41 PM, ext Felipe Crochik wrote: Can anybody recommend any “application” I can port to maemo5 that will allow me to interact with sql lite database? How about http://sqlitebrowser.sourceforge.net? How about sqlite??? http://www.sqlite.org/ Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autocomplete Library
Hi, Sivan Greenberg wrote: I would go to the trouble to provide a more complete autocomplete lib, in the form of completing not just by autocomplete lists provided by some readline client apps, but to employ heuristics to autocomplete words related to a usage domain of certain tools and apps. Sort of like that tool that's available from Debian that reads your source tree for example and then uses that information to enable more wide auto complete when hacking on the code. That's ctags (or etags). Rather, ctags generates lists of symbols that auto-completion features in editors read use for completion. It all depends on the needs of the original poster. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autocomplete Library
Hi Tanmay, Tanmay Verma wrote: Hi I have taken Maemo development project in my mobile computing course and our group was thinking of developing an Autocomplete library. Is there any such library available in GNU C or other libraries which support Maemo apps GNU Readline provides autocompletion abilities. It is used, for example, by MySQL for their autocomplete facility. http://tiswww.case.edu/php/chet/readline/rltop.html http://cc.byexamples.com/2008/06/16/gnu-readline-implement-custom-auto-complete/ Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Getting a phone number from an OssoABookContact
Hi, Andrew Flegg wrote: Here's some code from Hermes'[1] org/maemo/hermes/engine/contact.py: Any chance you could turn this into a use-case using the use-case template in the wiki, please? Thanks! Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Getting a phone number from an OssoABookContact
Hi, Andrew Flegg wrote: On Wed, Aug 25, 2010 at 12:04, Dave Neary dne...@maemo.org wrote: Andrew Flegg wrote: Here's some code from Hermes'[1] org/maemo/hermes/engine/contact.py: Any chance you could turn this into a use-case using the use-case template in the wiki, please? Any particular place you can suggest? Doing it in Python is a bit icky with having to fallback to ctypes, because of deficiencies in the available bindings. The template is here: http://wiki.maemo.org/Documentation/Use_case_template I would use the template as a guideline - the idea is just to have a common structure that allows categorisation and easier search browsing. You could put the page in Documentation/Getting a telephone number Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to use osso RPC calls properly
Hi Ville, Ville M. Vainio wrote: On Wed, Aug 25, 2010 at 4:10 PM, possun...@gmx.com wrote: I've been trying to show bluetooth device search dialog using osso_rpc_run and osso_rpc_run_system but this code returns OSSO_RPC_ERROR every time. You should avoid osso_ calls, my understanding is that they are deprecated (and they deliver very little value in the first place - just make your program maemo specific). snip How would you feel about converting this to a use-case for the Maemo wiki, something along the lines of Searching for bluetooth devices? Thanks! Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Building maemo on Beagle Board
Hi, Amit Sethi wrote: Hi , I am trying to install maemo on BeagleBoard . I am following instructions given here: http://omappedia.org/wiki/Maemo_Getting_Started#Beagle However the process breaks because of a broken package : dbus 1.2.14-0maemo4+0m5 How is it broken? What have you tried so far to fix it? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: OCR for Fremantle
Hi, ac...@dsic.upv.es wrote: Please, could someone tell me if I can obtain the sources of it for recompiling? If yes, from where can I download them? You can get Tesseract here: http://code.google.com/p/tesseract-ocr/ And the build for Fremantle: http://maemo.org/packages/view/tesseract-ocr-dev/ http://maemo.org/packages/view/tesseract-ocr/ Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using libosso-abook getting package requirement error
Hi Pallavi, Pallavi Kandhare wrote: [sbox-FREMANTLE_X86: ~] fakeroot apt-get install libosso-abook-dev Reading package lists... Done Building dependency tree... Done libosso-abook-dev is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. A tip for finding the name of the PackageConfig module: dpkg -L libosso-abook-dev | grep '\.pc$' For me this gives /usr/lib/pkgconfig/libosso-abook-1.0.pc And if i add below line to configure.ac (making no changes to Makefile.am) PKG_CHECK_MODULES(libosso, osso-addressbook-1.0) Output is: Package requirements (osso-addressbook-1.0) were not met: configure.ac So here, you should be doing PKG_CHECK_MODULES(LIBOSSO, libosso-abook-1.0) (note that the pkgconfig module is the name of the .pc file, and the first argument is the prefix you would like to use later in the LDADD command for $(prefix)_LIBS) - if you want to have myproj_LDADD = \ $(LIBOSSO_LIBS) then you need to set the first argument to LIBOSSO. the output is as follows: Description Resource Path Location Type 'book' undeclared (first use in this function) main.c ContactList/src line 45 C/C++ Problem 'EBook' undeclared (first use in this function) main.c ContactList/src line 45 C/C++ Problem 'EBookQuery' undeclared (first use in this function) main.c ContactList/src line 47 C/C++ Problem 'osso_context' undeclared (first use in this function) main.c ContactList/src line 111 C/C++ Problem 'query' undeclared (first use in this function) main.c ContactList/src line 47 C/C++ Problem libebook/e-book.h: No such file or directory main.c ContactList/src line 12 C/C++ Problem libosso-abook/osso-abook.h: No such file or directory main.c ContactList/src line 13 C/C++ Problem make: *** [all] Error 2 ContactList line 0 C/C++ Problem make[1]: *** [all-recursive] Error 1 ContactList line 0 C/C++ Problem make[2]: *** [main.o] Error 1 ContactList line 0 C/C++ Problem ... but once again, please make it easier to help you by including minimum compilable source code (or a link to a pasteboard containing some, or a reference to where you found the source code you are trying to compile) - otherwise people have to guess whether there are problems with your code or your project configuration. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposed reorganization of documentation bug reporting
Hi, jarmo.ti...@nokia.com wrote: What I am still wondering is UI Specification product under Maemo Official Platform classification here: https://bugs.maemo.org/enter_bug.cgi?classification=Maemo%20Official%20Platform Looking at this: http://is.gd/cevlF it appears that these bugs are being opened against applications which do not follow UI specifications, rather than being documentation bugs. I suggest leaving them there - and if people really feel there is confusion, changing the name of the component to just UI. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: HAL context initializing failure
Hi Pallavi,
Pallavi Kandhare wrote:
I did include the sample code in my previous mail.
This code does not compile - there is no main function declaration, no
header declarations, no compilation instructions... An extra 6 lines and
it is a compilable cut paste, without it you are requiring people to
know a certain number of things before helping. Like I said, please do a
little extra to make it easy for people to help.
I am including the code again for your reference:
I am getting the error _HAL context initializing failure_ in my below code
When i debug the code it says unable to access memory at 0x0.
#include stdio.h
#include dbus/dbus.h
#include libhal.h
int main (void)
{
DBusConnection *connection;
DBusError error;
LibHalContext *ctx;
dbus_error_init(error);
if((connection = dbus_bus_get(DBUS_BUS_SYSTEM,error)) == NULL)
{
printf(Error %s\n,error.message);
return 1;
}
if ( dbus_error_is_set(error) )
{
printf(Unable to connect to DBus: %s\n,error.message);
return 1;
}
if((ctx = libhal_ctx_new())==NULL)
{
printf(Error %s\n,error.message);
return 1;
}
if ( !libhal_ctx_set_dbus_connection(ctx, connection) )
{
printf(Error %s\n,error.message);
return 1;
}
if ( !libhal_ctx_init(ctx, error) )
{
printf(Hal context initializing failure %s\n,error.message);
return 1;
}
else
{
printf(Success);
return 0;
}
}
Compiled with
gcc -ggdb `pkg-config --cflags hal dbus-1` hal_context.c -o hal_context
`pkg-config --libs hal dbus-1`
It looks like HAL is not running on your OS. This code works fine for
me. Check if hald is in the process list.
Cheers,
Dave.
--
maemo.org docsmaster
Email: dne...@maemo.org
Jabber: bo...@jabber.org
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Undefined reference error
Hi, Pallavi Kandhare wrote: I have 2 files : list1.h and list1.c, and I call some functions defined in list1.h in main function of main.c. First, some definitions: Functions are generally declared in headers, and defined in C files. A declaration of any function is required before you can use it. list1.h is included in both list1.c and main.c. So your function is declared in main.c, and should compile OK. Still i am getting the following error : /test1file/src/main.c undefined reference to function-name This is a linker error - it means that at the time you are creating the executable, the definition of the function is not being found. The list1.o file is not created. What changes do i need to make to my Makefile in order to remove this error. That all depends on what your Makefile looks like now, doesn't it? ;) Generally it should resemble this: all: list1.o main.o cc -o my_prog list1.o main.o list1.o: cc -c list1.c main.o: cc -c main.c (there are ways to make this shorter, using pattern rules). Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using proc command in Maemo code
Hi, Pallavi Kandhare wrote: When /proc command is used in Maemo code it displays names of all running applications on the system. I also want to display names (and not PID) of all applications which are running / active in emulator. Pls can anybody guide how can i do the same. The command like of the application is in /proc/pid/cmdline Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: UPDATE2: Maemo Info Center library service released with first set of official maemo Fremantle 5 documentation
Hi Jarmo, jarmo.ti...@nokia.com wrote: Maemo LaTeX baseline (origin LaTeX files) and ready-made MediaWiki import documents can be downloaded from here: _http://library.maemodocs.nokia.com/documents/fremantle/Maemo_5_Document_Baselines/_ Can I assume that these docs supercede the previous links you gave me this week, and that I should now import these? Thanks! Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Numbered sections in wiki (was: Re: Packaging guidelines)
Hi, Graham Cobb wrote: 0) I have a meta-comment: to facilitate discussion, the sections of the document should be numbered. This is a user-preference in Mediawiki: in My preferences, in the Misc tab, check Auto-number headings to have sections in all pages numbered. Sections are numbered in the table of contents in any case, so there is no problem with referring to section 4.1 (Package relationships) - I'd like to see people include the names in any case, because section numbers can change in a wiki after edits. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Help needed: packaging/distributing very small C app
Hi, David King wrote: In addition, once something fails, it's still a bit unclear from the current docs about where to continue/repeat which steps. Yes, this is hard to solve in such a compact tutorial, as there are lots of steps where something could fail, and it is difficult to find the right balance between proding too much and too little information. Contributions welcome ;) Sounds like there's a sufficient amount of material for a packaging troubleshooting page? A packaging tutorial really should only cover the most simple things, and point people to canonical references where they can get more information. The Packaging page has already gotten too long for my liking, it seems like most people will only need about half of it at this stage, and the other half is likely to be more confusing than useful. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Help needed: packaging/distributing very small C app
Hi, David King wrote: On 2010-04-28 13:20, Dave Neary dne...@maemo.org wrote: A packaging tutorial really should only cover the most simple things, and point people to canonical references where they can get more information. The Packaging page has already gotten too long for my liking, it seems like most people will only need about half of it at this stage, and the other half is likely to be more confusing than useful. I split off the section on porting a Debian package to Maemo, which shortens the article somewhat. The majority of what remains is focussed on Maemo packaging specifics, with several links to reference documentation. As wiki articles go, it's a good 'un! Definitely a place we can send developers for a basic overview of packaging their stuff. Good work! Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Help needed: packaging/distributing very small C app
Hi Thomas, Thomas Waelti wrote: I'm looking for advanced packaging information for a very small C application. I documented the packaging of a C app (using autotools for building) a while back in the wiki: http://wiki.maemo.org/Packaging#A_concrete_example_-_rot13 This starts with a tiny C program the minimum autotools stuff to build it (I don't include these - would that be useful?) and guides you through making a .deb. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Help needed: packaging/distributing very small C app
Hi, Dave Neary wrote: I documented the packaging of a C app (using autotools for building) a while back in the wiki: http://wiki.maemo.org/Packaging#A_concrete_example_-_rot13 This starts with a tiny C program the minimum autotools stuff to build it (I don't include these - would that be useful?) and guides you through making a .deb. So I included an A to Z for this project, with the 3 files you need to create a .tar.gz using standard autotools. Let me know if it's useful. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Efficient storage and playback of speech
Hi Alberto, Alberto Mardegan wrote: I need to install on the device a few (I guess around 10-20) audio files with some seconds of speech each (it's for GPS navigation). What file format do you suggest to use, considering that one requirement is that the audio is played almost immediately (the lag should be under 1 second) when I request it to? Ogg Speex is a very good codec for low-latency, bow bit-rate human speech coding (things like VoIP fast decoding of short speech extracts would count). Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Dependency problems after PR 1.2 update to extras builder
Hi, Niels Breet wrote: The issue people see is that they are then trying to install the PR1.2 built application on a pre PR1.2 device. This might or might not work, depending on which dependencies are specified. To summarise, from the point of view of a developer: * If I upload a new verrsion of an app which is in Extras, the new version will be built with PR 1.2, and will go into Extras-devel. The old version will no longer be installable from Extras on a PR 1.1.1 device * If I try to test my application from Extras-devel on a PR 1.1.1 device, there is a good chance the application will not install, or will break * The only solution if I want my app to continue being available in Extras is to wait for the PR 1.2 firmware to be released, and not upload any updates Is that correct? And from the point of view of a user, an application which was previously available is no longer available if the developer has tried to update it recently? I don't really understand why uploading an app to extras-devel has hidden the app which is in extras (PR 1.1.1). Isn't that a bit like if I uploaded a package to Squeeze no-one could download it for Lenny any more? If I don't understand the issue correctly, excuse me, but I'm unclear how you expected things to happen with the autobuilder change. Was the idea that there would be a short period between the SDK and the firmware release, and thus developers could start getting their apps into extras for PR 1.2 before the firmware got released? But in that case, they would need a way to test apps promote them from extras-devel to -testing -extras-1.2, no? * Look at the possibility of adding a hacked libhildon package in the builder, so it generates 'correct' dependencies and applications can be installed on PR1.1 if they don't use the new livesearch api. (Probably most of them) I don't understand this - perhaps you could explain? * Discuss how we can improve this situation for the next SSU. How about separate repositories? How difficult would it be to have 2 auto-builder targets, and 2 different extras, extras-testing extras-devel repositories? The defaults wouldn't change for developers, and to test building against the new SDK, you'd just upload to the new autobuilder (where internal Nokia testers could test promote)? Trying to do the right thing, I have the feeling that it backfired. :( These things happen - perhaps if we understood the goals you were trying to achieve, there's a way to mitigate against this for the next time. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Dependency problems after PR 1.2 update to extras builder
Hi, Marcin Juszkiewicz wrote: No, I am not kidding. It was discussed here on mailing list and announced that Extras autobuilder will be updated to PR 1.2 compatible SDK and that resulting packages will be installable only on devices owned by Nokia employed people (and some from cooperating companies). Other users (and developers) have to wait for next firmware drop (which does not have release date as usual so it can be tomorrow or in next year). Now now Marcin, that's not what was said. what was said was that software built with the PR 1.2 SDK would probably only install on devices with PR 1.2 installed. That's not the same thing. ianaré, normally all you have to do is upgrade the firmware on your N900 to PR 1.2, as I understand it. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-developers Digest, Vol 59, Issue 25
Hi, Jeremiah Foster wrote: On Mar 26, 2010, at 3:00 PM, Marius Vollmer wrote: This work has been largely ignored by the Nokia team running the repos, much to my frustration. Yes, Nokia is good at that. ;-) Nokia is not alone. We'll soon get to see how the Intel / Nokia combo is at ignoring the community. :-) How about we give MeeGo a chance to succeed before we complain about its failures? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ask for removal of some packages from Extras Fremantle repository
Hi, Matti Airas wrote: However, as a member of the PyMaemo project I'm really worried about the fate of the pypackager and py2deb packages which allow for creating deb packages of Python programs without resorting to the use of Scratchbox. The functionality provided by these packages is quite essential to the developer story of the PyMaemo project since we don't want to force prospective PyMaemo developers to install Scratchbox and the full SDK just to have packages created. There is an alternative - if Benoît does not want to deal with Extras, and others feel that the packages he was packaging are vital, someone else can take over as official packager and deal with all the stuff he doesn't want to. It's possible to separate packaging development. It is free software after all. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900 USB Networking
Hi, van Porten, Oliver wrote: I've tried following this guide to setup USB networking with my Windows PC: http://wiki.maemo.org/N900_USB_networking#Windows_XP Have you also looked at the more generic http://wiki.maemo.org/USB_networking page also? I'm afraid since I'm not a Windows user I won't be able to help you much. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-testing improvements
H, Graham Cobb wrote: I believe we ALL want better quality software, developers, testers, users, everybody. Everybody wants it, just like they want world peace. The question is what are they willing to sacrifice to get it. I'm with Graham on this. The pre-release burden on the developer is fast making software distribution through Extras less less attractive. Don't forget, we're not ITMS, and there aren't crocks of gold waiting on the other side of a promotion to Extras. And as free software developers, we want to encourage frequent incremental releases - for which the extras-testing framework is a disincentive. And we also want Lots of software available for the platform, which requires keeping the distribution barrier low. If the burden on the testers developers continues to grow, we will see a return to distribution in the wild, and away from Extras, which would be a disaster for Maemo. Bringing all the 3rd party repositories together and making Extras the natural place to ship software to Maemo users has been one of the great achievements of the past few years, but the social tide is turning against it. Don't make distributing software through Extras a task that developers dread. The easiest proposal is to have it be very easy to get into extras-testing, and have it be very easy for users to add extras-testing to their devices, provide scoring comments infrastructure so that users can give feedback on the application, and then let the market do its job and have the cream float to the top. Graham's proposal of making access to Extras more supple, and providing additional incentives to move up the quality ladder, is another way to go about it. Excessive procedure here will kill the fun of shipping Maemo software. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-testing improvements
Hi, Niels Breet wrote: You have to see that Extras should be for applications that are of a high quality. The Extras repository should not give any problems to people who are new to Maemo and have no clue how to work with linux for instance. I think if extras-testing were easy to optionally enable for everyone the problem would be lessened - the QA work could then be done by people interested in the QA work, and the developers could concentrate on making great apps. Developers who want to have their applications available for the largest audience possible, should consider this. If adding a link to a bugtracker is too hard for a developer, can we really expect a quality application from them? I don't think that the bugtracker is the sticking point, and it's a bit disingenuous to say so. Optified and dependencies are optified too puts a burden on a developer vis à vis dependencies. License files included and headers have copyright/license adds an extra requirement on developers over above that which they usually have to do - headers usually aren't required to have a license block, as long as they refer to the licence include it in the distribution. No power management problems, no known security issues and no performance problems (in the checklist) sets the bar quite high for most community-built apps, I would have thought. The issue is: as a developer shipping software that I build in the evenings, how much effort am I willing to put into ensuring the widest distribution possible? The answer might well be: not *that* much. If your app works but is not yet ready for prime time, then consider what your audience is. Technical users will know where to find it. Right now, that's not the case. If we add an unchecked extras-testing repository to HAM on devices, that would be true. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
hi, Niels Breet wrote: Maemo 5 PR1.2 seems to be a release with some large changes which are not backwards compatible with previous releases. Most visible change will be the inclusion of Qt4.6, but there will be some other smaller changes. When you say not backwards compatible, does that mean that applications built with 1.0 or 1.1 will not work on 1.2? Or is it ABI compatible, but adds new interfaces, so that applications built with 1.2 won't necessarily work on 1.1 or 1.0 (which is a different less serious issue in that if you don't use the new interfaces your application should still work unchanged on the older releases)? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Hi, Niels Breet wrote: Niels Breet wrote: Maemo 5 PR1.2 seems to be a release with some large changes which are not backwards compatible with previous releases. Most visible change will be the inclusion of Qt4.6, but there will be some other smaller changes. When you say not backwards compatible, does that mean that applications built with 1.0 or 1.1 will not work on 1.2? That would be forward compatible in my book ;) Tomayto-tomahto. backwards compatible usually means that new interfaces support old applications. Windows 95 was backwards compatible with Windows 3.1, so old .exes still ran unchanged. You didn't even have to recompile. That's what I'm asking - will PR 1.0 packages executables continue to work on PR1.2? Or is it ABI compatible, but adds new interfaces, so that applications built with 1.2 won't necessarily work on 1.1 or 1.0 (which is a different less serious issue in that if you don't use the new interfaces your application should still work unchanged on the older releases)? Applications built on PR1.2 won't work on older versions. There are exceptions, some applications might work, but those make this very complicated. All applications? That seems unusual - especially since the GNOME project (and thus a bunch of the libraries in the API) work very hard to ensure API ABI compatibility. If I compile, unchanged, an application with the PR1.2 API which previously worked on PR1.0, I would expect the new package to continue to work correctly. I would expect it to stop working only after I started using interfaces not available in the old platform. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Hi, Sascha Mäkelä wrote: I was under the impression that for many Qt apps a simple repackaging will do the trick. If this is the case, would it not make sense to make those updates available? After all, before the updates are released to Extras, many users are going to have Qt apps that won't work on their N900. Surely we want to correct that as soon as possible. And what about existing Qt 4.5 based apps in Extras? Should the be demoted when PR1.2 is released? I know of at least one case where Maemo-specific changes were made in Qt 4.5 for Maemo and are no longer available in Qt 4.6 (related to Hildon integration). So it is entirely possible that some apps which previously compiled will not do so after the upgrade. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 PR1.2 and Extras
Hi, Michael Cronenworth wrote: How can you not like this? What is your reasoning? You brought this same response to the last Maemo update, and I still do not understand it. Let's say that there are 10,000 applications in Extras. Now every N900 owner can get all of those apps. Then a new version of the SDK comes out, which is not backwards compatible. A number of potentially bad things can happen: 1. New uploads get compiled with the new SDK, and get downloaded onto phones with the old OS, where they don't work. 2. Developers working with the old SDK upload applications which don't even build with the new SDK 3. To mitigate 2, we decide that all Extras apps need to be recompiled with the new SDK, resulting in a number of applications which fit into both the categories above - some apps stop working until the user upgrades the firmware, other apps don't build require changes and an SDK upgrade from the developer. All of these push inconvenience to the phone user application developer - all unnecessary overhead, especially if the APIs haven't changed and there are issues with run-time library versions (as we saw with PR 1.0 to 1.1). The only way to avoid badness when upgrading the SDK in a not-backwards-compatible way is to have scratchbox, every developer copy of the SDK, and the N900 firmware all upgrade at the same time. I imagine that this is why Graham's not happy about an SDK which isn't backwards compatible. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: About legacy Maemo 5 documentation on the wiki
Hi Anderson, Anderson Lizardo wrote: While fixing a few bugs on the supposedly official developer documentation on the wiki, I just noticed I made a mistake and was actually editing this one: http://wiki.maemo.org/Legacy_Maemo_5_Documentation The problem is that it is often getting high results while searching for documentation (at least for me). Can it be moved to a different place, archived, or even removed completely (as it has been superseded by other documentation as mentioned on the link above)? I think it is too easy to not notice the Legacy on the title. The lecacy stuff is very useful, and it was replaced with PDF-only docs. Jarmo released a new version of those docs lastw eek, awaiting wiki import, and those will purely simply replace the legacy docs, which should be deleted at that stage. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Request: Tutorials use-cases for documentation
Hi Sascha, Sascha Mäkelä wrote: How to override Silent Profile? what do you mean override? You mean have a user-space application decide not to do what the user has explicitly requested the phone to do? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: A proper home page in maemo.org with help wiki for each app in Extras
Hi, Ryan Abel wrote: This isn't really any easier than bundling the docs with the application package itself and marginally more complicated for both the developer and the user. If the docs package is in user/*, then it's cluttering up the application manager and you need twice the amount of effort to get it promoted to Extras. If it's not in user/*, then the user has yet another invisible package sucking up space. I don't see any reason why we couldn't have a Documentation field on the Downloads page linking wherever. I see definite potential here - especially if we require a standard docs template that people can follow just fill out, the way Bugzilla provides a bug template. We'd need to have an easy way to augment wiki pages with things which are vital in docs like screenshots, though. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Request: Tutorials use-cases for documentation
Hi, Aniello Del Sorbo wrote: I too am of the ide of answers specific to a particular toolkit. Quick and easy. Answer to the same use case in a different toolkit belong to that particular toolkit category. While the technology used to answer a question is a concern (and not a tiny, easy to resolve one) which will only get worse with the addition of Qt 4.6 and WRT, I think what's most important now is to concentrate on the questions, and having at least 1 high quality answer for each of them, rather than concentrating on what we do if we end up with several answers. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is the N900 running X-Windows?!
Hi, 白い熊 wrote: I've tried both ssh -XC n900 and ssh -YC n900 and then running leafpad for instance, but it gets run on the N900, is not exported to the PC. I've set: ForwardX11 yes ForwardX11Trusted yes in /etc/ssh/ssh_config on the N900 but it's not exported. What am I doing wrong? Jarmo pointed out something related to this recently on the maemo-users list: http://lists.maemo.org/pipermail/maemo-users/2010-February/015351.html He also points to some documentation on the issue. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packaging questions
Hi, Jeremiah Foster wrote: Is it then considered this way; 1. http://wiki.maemo.org/Packaging Quick Start 2. http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing Complete Maemo Guide 3. http://www.debian.org/doc/maint-guide/ Authoritative Source If this is the way we are seeing it, I can then direct people to those documents and focus my energies there making sure they are up-to-date and complete. That's the general idea. That also means that we can focus these pages more clearly - are there things in 1 that should be in 2, for example? Is 2 linking to all the resources 1 is? (eg PyPackager)? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Request: Tutorials use-cases for documentation
Hi everyone, Titta from Lionbridge has been working hard in recent months to understand what is needed to make Maemo's developer documentation rock, and one of her key goals is to ensure that the Maemo community is involved in the creation of documentation - but setting priorities and helping write and improve documentation. Her group has just created a Use-case template in the wiki: http://wiki.maemo.org/Documentation/Use_case_template The idea of a Use-case, as Titta has explained it to me, is that this will be a very focussed document which will explain how to solve a particular problem with the Maemo platform. It's not API documentation, nor is it an overall guide of the platform, it's a stand-alone piece of documentation that helps a developer perform a frequently requested task. Some examples that came to mind when we were talking about this were: * How can I get use accelerometer data on the N900? * How can I get a list of media files on the device? * How can I create a new sharing plug-in for my favourite online service? * How should I store retrieve configuration for my application? Some of these may be API-specific (like the last one gconf), but the API is the question, not the answer. The general principle is: make sure that the question you want answered is a well defined problem that a developer might have, and doesn't make any assumptions about the platfoiorm (that's what the answer's for). So what's next? We want to gather suggestions for use-cases that need documenting, then we'll create a wiki page for each one, then we (and by we, I mean the Maemo Community will answer the questions. The answers will include code snippets, and brief introductions to the purpose of any libraries we use. The end result should be a library of code snippets that could potentially become a Maemo cookbook. So - the floor is open! Don't all shout at once. What stuff would you like to know? Or, having run the gauntlet solved a problem in the past, which things do you think should be more clearly documented explained? Want to help document your struggles? Thanks for all your help! Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Developing virtual keyboard plugin for Maemo 5
Hi, Kimmo Hämäläinen wrote: says hildon_im_ui_button_set_* APIs are supported. But when verified in header file hildon-im-ui.h there aren't any of the APIs starting from hildon_im_ui_button_set_ This documentation seems out-dated. Some of that API has been removed. Please report a bug for it to get it updated. https://bugs.maemo.org/show_bug.cgi?id=8946 Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packaging questions
Hi, Ajai Khattri wrote: That depends, but for the current situation, I would say no. Firstly, creating multiple binary packages is harder than a single binary, though not by much. I recommend you start out with just a single binary if you can. OK, but Im curious: what would be an example of a package with multiple binaries? binutils, for example? gcc has a few (c89 c99 versions, for example) textutils openssh (scp, sftp, ssh, ...) 2) I got an error saying it could not find package.orig.tar.gz - what does that mean? This means you do not have an original tarball of your package that has the suffix orig.tar.gz. Take a look at the debian documentation here which should help: http://www.debian.org/doc/maint-guide/ch-first.en.html#s-dh_make So, to clarify, I need to have a tarball of the original source inside the untarred tarball build directory? :-) Have a look at this page: http://wiki.maemo.org/Packaging#A_concrete_example_-_rot13 dh_make takes a -f argument that points to the original .tar.gz, and generates rot13_0.1.orig.tar.gz, rot13_0.1-1.diff.gz, rot13_0.1-1.dsc and rot13_0.1-1_i386.changes afterwards. I was following the Maemo docs which dont mention anything about licenses. Maybe there ought to be a link to the dh_make man page from there? Which docs were you following, and how did you get there? we're trying to make http://wiki.maemo.org/Packaging the standard quick start page, and http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing and http://www.debian.org/doc/maint-guide/ the definitive more than you ever needed or wanted to know about Debian packaging, but were too afraid to ignore pages. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo5 SDK slow performance
Hi Max, Max Usachev wrote: Hello! I have strange problem with Maemo 5 SDK - all graphic manipulations in emulator works very slow. Also I get many errors such as: hildon-desktop[1961]: GLIB WARNING ** ClutterX11 - Failed to get XImage of pixmap: e00054, removing I'm sorry, I'm no help - all I can say is that I had the same poblem, also with an Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) (as given by lspci). If it's any help, I got the impression that the problem was Xephyr, rather than X. 3D works fine with the controller, just not in the embedded X server. I don't have the problem any more with an Intel 4 series integrated graphics controller. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
FOSDEM update
Hi all, I updated the FOSDEM page with the latest information about the conference, including all of the Maemo-related content during the conference, and a proposal for a Saturday evening meet-up. There is Maemo-related content in four tracks this year - security, cross-distro, cross-desktop and of course embedded. Let me know if you have any other ideas for Saturday. http://wiki.maemo.org/FOSDEM_2010 Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Telephone API question - answering a call.
Hi Matan, The phone DBus API is documented here: http://wiki.maemo.org/Phone_control And here: https://garage.maemo.org/plugins/wiki/index.php?CSD%20programming%20informationid=1106type=g You can see a Python example for listening to a DBus signal with Python here: http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/DBus/DBus_in_Freemantle Cheers, Dave. Matan Ziv-Av wrote: Hello, how do I answer an incoming call from a C program (or command line, or a python program, for that matter)? -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Telephone API question - answering a call.
Hi,
Matan Ziv-Av wrote:
On Wed, 27 Jan 2010, Dave Neary wrote:
And here:
https://garage.maemo.org/plugins/wiki/index.php?CSD%20programming%20informationid=1106type=g
This does not include answering a call.
I didn't realise you needed any more than this.
This page:
https://garage.maemo.org/plugins/wiki/index.php?com.nokia.csd.Callid=1106type=g
has a link to this file at the top:
http://www.bleb.org/software/maemo/telephony-maemo.c
which contains this code snippet:
static int answer_call(struct csd_call *call)
{
DBusMessage *msg;
msg = dbus_message_new_method_call(CSD_CALL_BUS_NAME,
call-object_path,
CSD_CALL_INSTANCE,
Answer);
if (!msg) {
error(Unable to allocate new D-Bus message);
return -ENOMEM;
}
g_dbus_send_message(connection, msg);
return 0;
}
and you get the csd_call object by listening for the Coming signal as
you can see from the code snippet which is linked to in this page, and
then searching for calls with the COMING status:
http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/DBus/DBus_in_Freemantle
Which I found out in about 15 minutes, reading the links I gave you.
Is this OK now?
Cheers,
Dave.
--
maemo.org docsmaster
Email: dne...@maemo.org
Jabber: bo...@jabber.org
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is mauku open source, i.e free or is in non-free?
Hi, Riku Voipio wrote: Well, such misunderstandings are likely to be caused by the poor extras instructions. Which exact page should Henrik read to get enlightened? David King I are working on improving these. Having not gone through the process myself, I need help. Your questions are great, because they help me identify the questions I need to ask get answered. For the current best information on uploading to extras, there are: http://wiki.maemo.org/Uploading_to_extras and http://wiki.maemo.org/Extras right now. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problems compiling HelloWorld for gtk+
Hi acano, ac...@dsic.upv.es wrote: I write you because I am having problems when compiling the program holamundo for gtk that is shown in the documentacion. I'm not sure if you got an answer for this. In the case where you didn't: Here is the error I obtain: [sbox-FREMANTLE_ARMEL: ~/proyectos/holamundo] gcc -Wall -g gtk_holamundo.c`pkg-config --cflags gtk+-2.0` -o gtk_holamundo `pkg-config --libs gtk+-2.0` /scratchbox/compilers/host-gcc/bin/ld: skipping incompatible /usr/lib/libgtk-x11-2.0.so when searching for -lgtk-x11-2.0 /scratchbox/compilers/host-gcc/bin/ld: cannot find -lgtk-x11-2.0 collect2: ld returned 1 exit status [sbox-FREMANTLE_ARMEL: ~/proyectos/holamundo] Are you sure that you installed GTK+ for armel? What do you see in Scratchbox when you run ls -l /usr/lib/*gtk-x11*? If you have everything set up OK, you should see: /usr/lib/libgtk-x11-2.0.so /usr/lib/libgtk-x11-2.0.so.0 /usr/lib/libgtk-x11-2.0.so.0.1400.7 The minor versions might be different on the last line, depending on the exact version of the SDK you have. The first two are sym links to the third. If you don't see this, you have not installed the SDK correctly, and ld (the linker part of the compile process) can't find the library correctly. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Quick start packaging guide
Hi all, Due to popular demand, I sat down this week with Jeremiah Foster, who explained to me the very quickest way to go about packaging an application. We didn't quite get to uploading to extras, but going from a .tar.gz to a correct .deb is there. http://wiki.maemo.org/Maemo_packaging_quick_start_guide I intend this article to be a kind of landing-point for new Maemo developers. It should contact the short path, with a bunch of shortcuts taken, and lots of links to canonical material. Improvements are welcome! Especially as related to: http://wiki.maemo.org/Packaging http://wiki.maemo.org/Maemo_packaging http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging,_Deploying_and_Distributing http://wiki.maemo.org/Extras http://wiki.maemo.org/Extras-testing http://wiki.maemo.org/Uploading_to_Extras-devel http://wiki.maemo.org/Uploading_to_Extras http://wiki.maemo.org/Developer_FAQ#Extras If we obsolete any of these pages, I'll be happy. If we make it easier to find useful stuff by linking to it from an easy-to-remember-and-reference portal page, I'll be happy. And if this email leads me to discover even more pages which have the same or similar content, even that will make me happy if we can consolidate it all nicely make it nice easy for new developers to find correct information on this. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-devel] List emails subject prefix
Hi, Marcin Juszkiewicz wrote: Get yourself proper email client which will sort your mail into folders. There is X-BeenThere: maemo-developers@maemo.org in each email from this ML. Personally I find that filtering email from mailing lists into folders is a sure-fire way to ensure that I never hear about anything that happens on high volume lists. The general workflow when I used mutt used to be this: * Check mailing list folder - how many unread mails are there since last week? * Under 50 - OK, browse read. Over 50 and under 100 - Think about it. Over 100 - Mark as read. Even if I now have 400 new emails in my main mail inbox every day, you can rest assured that I read *at least* the subject line of every mail I get. If I filtered mail into folders, I suspect that I'd have started missing threads on maemo-users quite a while ago. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: oFono
Hi Aki, It looks like your submission has been accepted. I will confirm 100% today or tomorrow. Cheers, Dave. Aki Niemi wrote: ma, 2010-01-11 kello 08:38 +0100, Denis-Courmont Remi (Nokia-D/Helsinki) kirjoitti: On Saturday 09 January 2010 08:40:29 ext Qole, you wrote: So wait, you're saying we now have a fully open source telephony stack on the N900 that works to make phone calls? Well not exactly. But I'd say not far from it either. First, oFono is signaling middleware; it does not, and never will include its own user interface. The call UI in Maemo5 uses Telepathy, which is open. So all we need is a Telepathy connection manager that uses oFono's D-Bus API. Second, certain things are still to be implemented, such as GPRS (working on it). I'm looking forward to the patches. ;) Last, some stuff might not be do-able, due to interference with the existing N900 cellular stack. SMS reception is one known case (and SMS sending fails too as a side effect). Yeah, SMS and CBS reception are a bit tricky. There can only be a single recipient active at a time on the application processor side. Hence, bootstrapping in the SMS and CBS drivers will fail on the N900 if the default telephony stack is running. You can of course disable the default SMS handler, but then SMSs will no longer be received on the UI, as we're missing that oFono connection manager to Telepathy. Also, the default stack on N900 has some further features related to SMS that are currently missing from oFono. Those features will eventually be added there, too. All and all, oFono should be considered alpha level on Maemo5 at this point. Audio path has not been investigated, but likely would fail too. Right, there is a piece missing in isimodem that sets up the audio path. Currently it's not a big deal, as the default stack will shadow the signaling initiated by oFono and do the Right Thing. Cheers, Aki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: oFono
Dave Neary wrote: snip Oops - sorry, that wasn't supposed to go to the mailing list. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
Hi, Jeff Moe wrote: People have been preaching patience (not just to me, to everyone) since I landed here and before. Why should we be patient? Why can't we demand things work like they do everywhere else? I'm sure google/apple would love for us to be patient for the next 3 years. I guess that the problem is that you demand rather than request. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
Hi, Jeff Moe wrote: Also, perhaps I'm missing it, but it seems really hard to even figure out who the maemo staff is. Perhap I'm missing the obvious wiki page with this info (ala http://wiki.maemo.org/People ). Who is the paid maemo staff? Right up at the top of the People page: The maemo.org team - these are the people working on maemo.org: http://wiki.maemo.org/Maemo.org_team There are also some people working for Nemein who work on various aspects of maemo.org at different times - Ferenc, Rambo, Neithan, Henri, ... Most of these are either present or mentioned in the monthly IRC meetings we hold: http://wiki.maemo.org/Maemo.org_Sprints cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: running application automatically at system startup
Hi, Edward Page wrote: Is anyone collecting these How do I... questions and putting them on the wiki? http://wiki.maemo.org/Tutorials http://wiki.maemo.org/User_FAQ http://wiki.maemo.org/Developer_FAQ Psst... don't tell anyone, but it's a wiki. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
Hi Jeff, Jeff Moe wrote: I've had my device for 1200 hours so far (50 days). For how many of those hours have the various services been down? I'm not sure everything has ever been working for a full complete day. Break in the corners? That's quite a gloss. You could accomplish a lot more by rattling fewer cages. You've known this community for 50 days. Rather than rubbishing the work which everyone has done on this project *before* you arrived, you could criticise a little less frequently, tone down the sabre rattling, and in general be a bit nicer. This has never been a community where he who shouts loudest gets his way - please don't try to turn it into one. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SVN moved permanently?
Hi, I couldn't find any server-move specific wiki page, so I put this information (and similar information for svn to gitorious) in http://wiki.maemo.org/Subversion Cheers, Dave. koos vriezen wrote: 2010/1/16 Till Harbaum / Lists li...@harbaum.org: Hi, it would imho be really a good idea if the maemo.org maintainers would document such changes and just write down a few lines of text describing what will change and how the average developer is supposed to cope with this. This e.g. seems not to work: $svn relocate Unknown command: 'relocate' Type 'svn help' for usage. I did svn switch --relocate https://garage.maemo.org/svn/kmplayer https://vcs.maemo.org/svn/kmplayer (but I've made google as my friend :) Koos ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: News for FOSDEM
Hi, maemo-develoeprs CCed with this useful information) Pau Garcia i Quiles wrote: Send an e-mail to Jonathan Riddell ( j...@jriddell.org ) if you want presence in the KDE devroom. I sent an email to Kenny (the address listed on the devroom page) and got no reply. The same address was listed for cross-desktop talks. I didn't know that Jonathan had taken it over - the deadline is also long past now. Is there still room for talks? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Package Building HOWTO
Hi, Jeff Moe wrote: Yes, I do think it would be good to put it in the main namespace, but right now I'm sort of ramping myself up to where everything is and how it is all set up. I didn't want to munge up the main pages yet. ;) Writing this up is a learning experience for me as I go through the process. Like in Bugzilla, there are people who will rename or move pages, add correct categories and so on for your page if you put it in the wrong place - please don't be afraid to munge the main pages. For the packaging howto, there is already http://wiki.maemo.org/Maemo_packaging - this would be an ideal sub-page (or addition/edition) to that. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How remove package from extra-devel free?
Hi, Darren Long wrote: Hmm. IANAL, but in my naivety, I would have thought that maemo.org would have to provide source for the binaries they (have) distribute(d). Indeed! But the source and the binaries are not the same thing. There are a few ways to deal with the source requirement - and if you are merely redistributing binaries made by someone else, you don't need to provide sources, you only need to be able to point someone to the sources. Another way is to ship sources with the binary. And finally, the one you may be alluding to, the written offer to provide source code, valid for at least three years, to provide the source code on request. So in the case where maemo.org is merely providing a platform for someone to share GPL licenced products, all we need to do is give a link back to the place the source package, or even forward on the written offer that the packager gave us. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Pushing optified Python libs
Hi, Niels Breet wrote: User _applications_ should be in user/* categories. (Basically everything you want the end-user to see and be able to uninstall) Everything else should never be in user. Where should it go? The packaging policy[1] only explicitly mentions user/* sections, as does the wiki [2]. As best I can tell we should be using Debian policy for everything that doesn't appear in the application manager. Here's section 2.2 of the packaging policy [1]: 2.2 Sections Packages are grouped into sections as in Debian, but SHOULD NOT specify a category in the segment part. (However it is not a bug if a package taken from Debian and made available in maemo retains its “contrib” or “non-free” segment.) Instead maemo defines a user segment for controlling visibility in the Application Manager. Packages that are intended to be visible in the Application Manager MUST belong to the user segment, and packages that are not intended to be visible (such as libraries and other dependencies) MUST NOT belong to that segment. [snip] Packages not in the user segment SHOULD use the sections listed in the Debian Policy (http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections). Looking at that page: The Debian archive maintainers provide the authoritative list of sections. At present, they are: admin, cli-mono, comm, database, devel, debug, doc, editors, electronics, embedded, fonts, games, gnome, graphics, gnu-r, gnustep, hamradio, haskell, httpd, interpreters, java, kde, kernel, libs, libdevel, lisp, localization, mail, math, misc, net, news, ocaml, oldlibs, otherosfs, perl, php, python, ruby, science, shells, sound, tex, text, utils, vcs, video, web, x11, xfce, zope. So python looks like a promising section. And I found this document that looks useful for Python packagers, but doesn't mention sections at all: http://www.debian.org/doc/packaging-manuals/python-policy/ Is there a list of the standard Python sections sub-sections somewhere? The easiest way to update the python libraries for now is to either promote an application depending (= the new version) or ping me to manually push them through. A library maintainer currently has no way to vote for/test a library have it get promoted by the normal QA process? I can imagine, for example, a situation where a library gets updated, fixing a lot of bugs, but the application depending on it doesn't bump the depends version. In that case, what should the maintainer do? Ping you to have it promoted? Cheers, Dave. [1] http://maemo.org/forrest-images/pdf/maemo-policy.pdf [2] http://wiki.maemo.org/Maemo_packaging -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo extras downloads keeps resetting description for liqtorch and liqflow
Hi, Niels Breet wrote: On Fri, December 18, 2009 14:30, Cornelius Hald wrote: Would it then be possible to remove those field from the site where you can manually edit this information? Because I think there the real confusion comes from. To quote myself: The description field needs to be hidden for Maemo5, but not for the other operating system versions. That should clear up the confusion. You seem to have missed that line ;) Actually, speaking for myself, I just didn't understand. You mean that the description field on the product page should be hidden from the user completely? Or from the maintainer who edits the page? For example, on http://maemo.org/downloads/product/Maemo5/omweather/ the user still needs to see Weather Forecast on Nokia N900. Ultra-customisable weather widget for showing forecast the way you want. Do you mean that the Description field on the page http://maemo.org/downloads/product/edit/37ee3e5ca78011debca0d72dcd1bdfb1dfb1/ needs to be hidden? Or made read-only? Or is it somewhere else that it needs to be hidden? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Reminder for FOSDEM devrooms!
Hi all, Deadlines are approaching for various Maemo related FOSDEM devrooms: KDE: http://dot.kde.org/2009/12/15/speakers-wanted-fosdem-2010 Deadline: Jan 3rd GNOME: http://live.gnome.org/Brussels2010/Devroom Deadline: Jan 8th Crossdistro: http://fosdem.org/2010/distrominiconf Deadline: None listed Embedded / Mobile: No call for content published yet (apparently there is one, but I have not seen it) Crossdesktop: Freedesktop.org content goes here! I'd like to see talks related to what we're doing with Tracker, upstart, d-bus, Gstreamer and all of the other cross-desktop components we work with Deadline: Proposals go through GNOME KDE calls, I think. Let me know if you want to participate, so that we can co-ordinate sessions across different streams - and get your talks in before Christmas! Time is running short, and between Mer and Maemo 5 we have a lot to tell the world about. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bootstrapping the Maemo 6 Developer Guide
Good idea! Moved page (with a redirect in place). Cheers, Dave. Keywan Najafi Tonekaboni wrote: Hi, Am Freitag, den 11.12.2009, 14:07 +0200 schrieb Quim Gil: Have you ever seen a Developer Guide being created from scratch? Now is your chance, also to get involved. Complain and be bold now so we all have a better time when the time to install the Maemo 6 SDK comes. :) http://wiki.maemo.org/Developer_Guide_table_of_contents This is good news. I would propose some Maemo 6 in the title, so nobody confuse this with the other (even though it's mention in the text). I have started the discussion at http://talk.maemo.org/showthread.php?t=36646 since I believe we are getting many newcomers (and less Linux experienced) developers there. You can give your feedback here if you prefer. Oh, fragmented maemo communication... we need a Mailinglist-to-Forum-to-Mailinglist-Converter (something like Gmane, but instead of for Newsgroups for Talk) Cheers, Keywan -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
[Fwd: Call for Talks - FOSDEM 2010 (GNOME devroom)]
Hi all, At FOSDEM, Maemo will be engaged with four different dev-rooms: the Mobile dev-room, the distros mini-conf, the GNOME dev-room and the KDE dev-room. This year again there are plans for freedesktop.org talks in the GNOME dev-room. Can anyone interested in submitting a Maemo/Mer related talk to the GNOME dev-room please either contact me, or contact Teuf directly CC me, so that we can track where the different talks will be happening? I will link to the GNOME call for content in the FOSDEM wiki page. Jeremiah, you're keeping your eye out for the distro mini-conf call for content, are you? I'm not on any lists that have gotten any news of that one yet. Could you forward anything you see on to me, please? Thanks all! Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ---BeginMessage--- Hi everyone, As for the last few years, we'll have a GNOME devroom next year at FOSDEM (6/7 feb in Brussels), and as always, we want *YOU* to give a talk about the cool project you are hacking on in this devroom During this week-end, we'll have half a day dedicated to GNOME specific talks, and on Sunday, we'll share the devroom with people hacking on other desktop environments and have talks about crossdesktop topics or talks about some GNOME specific topics, but which can be of interest to the other communities. Devroom talks are 30/35 minute long talks presenting one aspect of the GNOME community you care about. This can be a technical talk about a library you're hacking on, but you can also give a talk about how to market GNOME at big events, or about how to get involved in the translation project, ... In short, you can talk about whatever you want as long as it's about GNOME! Like last year, you'll find all the information about the even on http://live.gnome.org/Brussels2010. However,if you want to give a talk, please don't add yourself to the schedule. Send me an email instead describing your talk and the slot(s) you'd like to have, and add that information to the Presenters and their presentation on the wiki. If you aren't giving a talk but are coming, please let us now at http://live.gnome.org/Brussels2010/Attendees ! This is helpful in case we print shirts or name tags. Please send your talk proposals before Friday 8th January. With the end of year holidays, this deadline will come *really* quickly, so the sooner you send a proposal, the better (before the holidays is great ;). Hope to see you all in Brussels, enjoy the last days of 2009, Christophe ___ foundation-list mailing list foundation-l...@gnome.org http://mail.gnome.org/mailman/listinfo/foundation-list ---End Message--- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Developers Guide
Hi Keywan, Keywan Najafi Tonekaboni wrote: is there beside the Wike a Maemo 5 Developer Guide? http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide A lot of pages are still empty in this guide Which pages are empty, specifically? The goal is to have the developer documentation in the wiki. If it needs improving, then we can do it. Is there a start point which guide me to all relevant information? http://wiki.maemo.org/Documentation I tried the wiki and forum nokia... Forum Nokia also has some useful information - especially pertaining to widget style guides, UI guidelines and such. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt or GTK+ which is better for developement
Hi, Abdul Mateen wrote: I am a newbie for maemo , having extensive experience developing for Android platform, I want to ask here, should I start with Qt ? or GTK+ or they will have the same impact, is there any difference in between the two considered with maemo development, officially GTK+ is supported? can we do everything with Qt we can do with GTK+ ? Objectively, you should probably target Qt for new applications. You can develop well integrated Maemo applications with Qt, and it will be the default toolkit interface from Maemo 6 onwards. If you're primarily targeting N900 or lower, you should use GTK+ and Hildon, that will be better integrated. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Updating the info for Extras-devel non-free
Hi, Quim Gil wrote: Hi, the information to upload binary-only packages to extras-devel is out of date: http://wiki.maemo.org/Uploading_to_Extras-devel#.22non-free.22_packages Yet there are several non-free packages in extras-devel extras-testing / Extras. Can someone please update the wiki information reflecting the current practice for Maemo 5? We are seeing more questions about this and actually the current information is misleading since it suggests that non-free packages can bypass the Extras-testing QA process, which is not true. Just to clarify current practice, then: Publishing non-free packages is done by dput (still correct, right?) But they're published to extras-testing, not extras-devel? Is the dput.cf file in the wiki still OK? If not, what modifications are needed? I have made some superficial changes to the text reflecting my best-guess as to what should be done, but I'd need someone who knows packaging well (maybe Jeremiah) to look and check that the change to the .cf file is correct (s/devel/testing/g) and verify if the diablo-extras-non-free section should still be there. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Updating the info for Extras-devel non-free
Hi, I know I'm not the only one confused here... Quim says: We are seeing more questions about this and actually the current information is misleading since it suggests that non-free packages can bypass the Extras-testing QA process, which is not true. And Jeremiah says: Here is the relevant line that I believe X-fade added regarding this: There is no promotion available for non-free. You need to upload yourpackage to the right repository yourself. When he states 'promotion' he is referring to extras-testing. This directly contradicts what Quim said - either non-free packages bypass the extras-testing QA process, or they don't. Which is it? It is preferable that we make sure the wiki reflects reality rather than just changing things on the fly. This page; http://wiki.maemo.org/Uploading_to_Extras-devel#.22non-free.22_packages stated that non-free packages go through the same testing procedure as free packages. This is not the case. I put this in place today, following Quim's mail. Previously it said It's your responsibility to upload to the right place or something like that. Let's wait until Niels comes back so that he can explain exactly what his code does, then we can decide if we want to change the policy. Perhaps part of Niels' tasks when he comes back should be to ensure that we don't need him to come back to explain what policy is? It seems like an awful lot of things depend on him being around. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: independent home screen
Hi, Wang Baisheng wrote: I want to use an independent home screen which has its own process, not contained in the hildon-desktop. And now I have a desktop implemented by gtk, but the hildon-desktop will cover it. What exactly is your question, please? You would like to know how to launch your independent desktop and not have hildon-desktop launched? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Documentation hackfest in Barcelona
[reposted from maemo-community - please excuse the double posting for those people subscribed to both] Hi all, We're planning a documentation hackefest in Barcelona as part of the Barcelona weekend in December (2.5 short weeks away), and you are all active in community documentation efforts (or have been in the past). Anyone interested in attending for the documentation hackfest should register ASAP indicating that you wish to attend so that we can gauge numbers. We're looking forward to a productive session defining the needs of developer documentation in Maemo, and working together to improve the existing documentation as well over the weekend - maybe the Intro pages for maemo.org? Mary Nurminen and Titta Vayrynen from Lionbridge will be co-ordinating the developer docs workshop - they have been contracted by Nokia to improve the developer documentation and they have some objectives that they would like to see us accomplish at the event. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to get n900 IMEI code in C
Hi, Graham Cobb wrote: I have asked Nokia and they are not willing to release the documentation for the CSD services. Their reasons include supportability (the interfaces may change) and that they are trying to push oFono as the right long term solution (although it isn't here yet). I've been following this thread with interest, and have set the wheels in motion to have DBus interfaces documented - to start with, I plan to document one module in HAF to understand the process and document it, and then let ye all loose documenting the rest of them :) If we have an easy way for the interfaces to be documented, I'm sure that the relevant developers in Nokia will see the value help us out. However, many of the CSD services can be discovered using various DBus tools. I have made a start on that and have put the information I have worked out so far in the Wiki of one of my garage projects. You can see this at: https://garage.maemo.org/plugins/wiki/index.php?CSD%20programming%20informationid=1106type=g Great! Any chance that you could put this is the main Maemo wiki, please? The issue with d-feet or similar is that there is no semantic information associated with the interfaces. I may move it to the maemo.org Wiki at some point, but I was waiting until I had got more info and done more testing (including understanding if some things had bad effects!). If anyone wants to contribute, let me know and I can add you to the project. I'd really be happier with this in the Maemo wiki, if you don't mind. We could even link it from the Documentation page. Thanks! Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Follow up from QA meeting on IRC
Hi, Edward Page wrote: To help remind people that there is a checklist and whats on it, should the rating page link to or include the criteria? I see there were no notes on the algorithm. A threshold of 10 was annoying as a developer. As a tester, a threshold of 10 made me feel more comfortable not doing a full blown /opt check or power management check because of 10 people I could hope someone else would do it and I could worry about other issues like application stability. With a smaller threshold I would feel more of a burden to do all of the steps which would discourage me. So I guess I'll share my idea. To me, it seems that one tester would probably be enough for /opt, power management, etc. If the categories were broken out, these could just require a net of +1 karma with a required comment to describe steps and results regardless of whether they gave an up or down. Net +1 is in case others disagree, they can vote it down. Required comments either way are to make people feel comfortable that it was tested properly and not just someone saying it works for me and voting it up. Ed's point definitely resonates with me. The great thing about QA is that you can crowd-source it effectively if you don't require much of the user/tester. It seems like the Maemo QA process is more developer-focussed than user-focussed at the moment, and is as such pushing a lot of the responsibility for the QA process to the user. This seems like an ideal opportunity to lower the barrier to participation to tiny levels, but only if it is 1. easy to give a +1/-1 2. We don't require intimate knowledge of the Maemo community for feedback (I'm thinking of the checklist, what optification means, etc) 3. We require enough feedback that most of the code paths in the application will be tested before we OK an application Lowering the threshold to 5 is implicitly saying we're not getting feedback quickly enough, which in turn is saying the feedback process is overly cumbersome for a casual user. It seems to me that that's the problem, rather than the contents of the checklist or the threshold in place. If giving feedback was trivially easy (as it is, for example, in Android Market) you would be getting hundreds of votes when new versions of applications are released, as people installed used them. So - how can we make giving the feedback and voting on applications easier? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-release
Hi, Quim Gil wrote: We are asking the renaming of pure end user apps called Maemo Something in order to avoid confusion of what is official and what is not. Just to be clear, when you say what is official, what do you mean? Is this applications shipped with the device by default? Or applications created by Nokia? Or applications in the Nokia applications repository? I'd like to think that eventually, applications written by anyone in the community can become official and be installed by default in future Maemo devices, if they prove themselves capable. Cheers, Dave. (For the rest, I agree - if we're not talking about user-targetted apps, the impact is small - I just want to clarify the meaning of the often-used word official) -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to get n900 IMEI code in C
Hi, Faheem Pervez wrote: Yes, the get_imsi method exists. So doing that should work but you will have to change some things: get_imsi returns only one argument: an int32 with the IMSI number. How do you find out what methods, interfaces and paths exist for the DBus services? Are they documented, or is there some kind of DBus explorer to let you look? Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Looking for a tag cloud widget (like the one in Edit tags)
Hi Thomas, Thomas Perl wrote: I need a widget that can display a tag cloud out of a list of items that I provide (with different font sizes depending on a weight associated with each item). In Fremantle, the Images and Camera apps have such a tag cloud (the dialog is called Edit tags), but I don't think that the widget itself is open (if it is, please kindly point me to its source ;). If there's no such thing, maybe I'll do one for Hildon Extras; just don't want to duplicate work that someone else might have done already :) A quick search found this: http://www.mail-archive.com/tracker-l...@gnome.org/msg02732.html I don't know of one in Hildon, but then I don't know Hildon very well :) Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Strange message from autobuilder: ERROR running /etc/buildme.d/setup_build
Hi, ds wrote: [2009-11-04 16:35:01] Processing package vncviewer 0.6.3-fremantle3. Uploader: dschmicker, builder: builder1 [2009-11-04 16:35:21] ERROR running /etc/buildme.d/setup_build: We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. Password: I do not really understand, what it wants to say to me:-( I recognise this message - it is the message which you get when you run sudo (sometimes only the first time). The password is usually not needed if your username is in the sudoers file. The lecture is not given every time if you have lecture=once or lecture=never as options at the top of the file /etc/sudoers. So - the error message isn't weird, it merely indicates a call to sudo with a UID which isn't in the sudoers file as not needing to enter their password. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Does Uploading to Extras need updating for Fremantle?
Hi all, I'm wondering if http://wiki.maemo.org/Uploading_to_Extras needs updating in the context of http://wiki.maemo.org/Extras-testing and http://wiki.maemo.org/Extras after the Maemo 5 release - I'm afraid I don't have teh smarts to be able to tell. Could someone who has experience using Extras, and familiar with the extras-testing extras-devel set-up, please have a look see if it needs revising? The page is linked to from http://maemo.org/development Thanks! Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo 5 Keymaps - The Saga of Pipe Tab
Ville M. Vainio wrote: On Wed, Oct 14, 2009 at 11:02 PM, Ryan Abel rabe...@gmail.com wrote: So qwerty12 compiled a patched xev, I grabbed keycodes and I spent a couple hours trying to convince the device that it'd be a really great idea for shift-fn-b to send a pipe, for fn-right arrow to send tab, and a dozen other shifted and unshifted combinations. FWIW, I think selecting those chars from touch screen (fn + sym) isn't all that bad - probably easier than shift + fn + something. fn + right would make sense though. I guess you have to know that's what you have to do first... I couldn't figure out how to put accents on letters for text messages :) Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Opt Bof?
Hi, Marius Vollmer wrote: Ok, let's do that then. (Do we need to register the BoF ahead of time?) That all depends - if you want the BOF to be on the schedule and have a room you can use, then yes. If you want to gather key people during the conference and pull a few chairs together, then no. I'd just like to point out that the content committee have done our best to accommodate things like this, but demand is high, and space is at a premium now, and we are about to close out the schedule. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Opt Bof?
Hi, Marius Vollmer wrote: Marius Vollmer marius.voll...@nokia.com writes: ext Dave Neary dne...@maemo.org writes: Hi, Marius Vollmer wrote: Ok, let's do that then. (Do we need to register the BoF ahead of time?) That all depends - if you want the BOF to be on the schedule and have a room you can use, then yes. Ok. I'll register the BoF then and leave it to you to decide whether it is important enough to reserve a room for it. Hmm, I am not sure how to proceed now. I made a new section on http://wiki.maemo.org/Talk:Maemo_Summit_2009/Submissions for Proposed BoFs. Is that enough? Or is it too late? Actually, that page (the Talk: page) was where the content committee evaluated proposals from http://wiki.maemo.org/Maemo_Summit_2009/Submissions but that page is now protected, since the deadline is passed. I'll tell you what - I'll take this email as a proposal, and if we have any BOF space left after fitting in all the content we've already accepted, you can have it. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [Qt4Maemo-devel] The Summit: Git/Gitorious - Untracked talks: consider adding them...
Hi, I'm woming into the discussion late, I've taken this as a proper request for BOF space, and have assigned some in the schedule. If you only need half an hour, or if you haven't decided whether to ask for space yet, let me know. In any case, it's a big site, and the principle of BOFs is grab the people you need/want, and sit down informally together - scheduled space isn't a requirement, I think. Cheers, Dave. Kees Jongenburger wrote: Hi David, I assume you want to present to also have some discussion. so let's start with that. This is all IMHO. On Fri, Sep 4, 2009 at 1:57 PM, David Greavesda...@dgreaves.com wrote: I personally thing think that as a development community with git on garage and gitorious.org we should be making efforts to understand how best to use DVCS processes to collaborate. I don't believe that version control system is what is keeping us back from collaborating. I do use git myself when I feel like it to grab projects and start hacking on it but this is not what you are talking about. Maybe it's just me but I see a lot of devs who are new to DVCS and very few community guidelines on how to use DVCS. Qt uses it but, as we've recently been discussing, it could be going better. One can solve many problems in many ways. it's very hard to find a common way of doing things but this is apparently the design goals of the git system and it's very hard to learn from other just because it's distributed(you can't look over somebody's shoulder). Even for developers git is a huge learning curve. While it's not bad to learn at first sight I don't think it solves and problems we have(it probably even make us have more problems because we have more choice) Frankly I don't care which 'good practice' I use - I can go out and find lots of them. But it strikes me that as a community we should at least say hey, quite a few of us are using this approach - if you don't have any strong preferences then you can use it too This is not clear to me. what people what problem,project are you thinking about? what is your target audience? So why now? Well, real soon now (I hope) we're going to have 3 different versions to support. * Fremantle * Diablo * Mer So how do we (you) manage the build-variations (ie debian/* may well vary for each of them. Maybe ./configure too)? Do we use branches? How? I hope not, I know git is good a branches but how confusing will this be for others?. To me divide and conquerer doesn't mean every body gets' it's own branch. For this specific problem (debian stuff) I would suggest using whatever packager use to solve this problem and I don't think it's put everything in a git. Now how do we manage adding features and back-porting simple bug fixes to the stable release whilst you work on that big new feature set. This is a typical problem of people working with closed source. In open-source you release once and might do some minor update for real big problems but overall should not have to maintain a release branch to to long as everybody wants the Latest Greatest. Release often mantra How are contributions and teams handled? It sounds horrendous - and it can be! Indeed it sound overcomplicated. first make it easy to contribute and if it gets out of hand start using tools. Try to keep working with as many people as possible on the same branch to force yourself to think about other people's problems. But actually this is all fairly simple stuff with DVCS once you have it explained and once you grok it - but it's bloody hard to figure out from scratch and it's also very unlikely that you'll arrive at the same solution as another team. Indeed. this is actually where a tend to like bzr (for simplicity) and the very nice launchpad as it removes part of this thinking process. bzr is also a distributed versioning system so not completely fair Which means if you're a member of multiple teams you might find they each have different approaches - whoo hoo! - not! So anyway... I thought a talk would be a good idea. Now at the time no-one had volunteered so I did - some of you may have noticed my name at the bottom of http://www.kernel.org/pub/software/scm/git/docs/git.html Now you may think that qualifies me to offer this talk - you'd be wrong ;) I was hanging around the kernel lists at the time, got interested and acted as an 'editor' pulling together words of wisdom. Since then I've used git a little but it wasn't until we started to need it in Mer that I reviewed the state-of-play and tried to pull in other people's good ideas - so that's what I'd use as a base. However we also have Johan Sørensen (cc'd as I don't think he's on-list) who wrote Gitorious.org - I think having him speak on using git and gitorious would be an opportunity that we shouldn't miss. That does sound good, on something like FOSDEM I would certainly go Equally
