Re: How to include glib-object.h
On Mon, 2010-03-29 at 11:24 +0200, Alberto Garcia wrote: > Actually you should include `pkg-config --cflags glib-2.0` Well, actually, the location library apparently provides a pkg-config file that he should check for instead, so he doesn't have to worry about checking for its glib dependency. However, this example suggests that the liblocation pkg-config file is broken, because it suggests checking for glib too. Well, that whole pkg-config call is very strange. http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Using_Connectivity_Components/Using_Location_API#Using_Location_API CCing David so he can investigate. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: qmake
On Thu, 2010-02-25 at 09:59 -0500, John Kemp wrote: > > Users of (awful, horrible, hateful, doesn't-actually-do-much) qmake > > Is there an easy alternative for doing Qt builds? I use autotools with Qt because autotools-created projects do things in de-facto standard documented ways on Linux, and actually work. It's slightly awkward due to moc, but that's not too bad. Daniel Elstner created this little example to get started: http://github.com/danielkitta/qhello Here's another example, in a Nokia project, though I doubt that it's quite as good as Daniel's: http://maemo.gitorious.org/maemo-af/contextkit/trees/master And lots of Qt and KDE people like CMake, though I don't personally: http://www.murrayc.com/blog/permalink/2009/10/28/trying-qmake-and-cmake/ -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: qmake
On Thu, 2010-02-25 at 11:26 +0200, Tatu Lahtela wrote: > Another option is that you have run qmake outside the scratchbox > environment > and created invalid Makefiles. You might have to delete your current > Makefiles manually and then re-run qmake in the target platform. Users of (awful, horrible, hateful, doesn't-actually-do-much) qmake regularly have to do complete rebuilds. Luckily, when using git, it's easy to remove all generated files like so: git clean -dfx Back-up first, I suppose. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
On Tue, 2010-01-19 at 08:43 -0300, Jeff Moe wrote: > > I don't have to be here for years to see how things are managed and > where the problems are. Things are clearly in progress. It's apparently a move in the right direction, even if it's not everything you want. How about letting it settle down just a little bit and then calmly suggesting how to avoid problems in future. I am sure that Tero and his colleagues would actually like ideas that reduce the awkward infrastructure work. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bad Xephyr OpenGL performance
On Thu, 2009-12-03 at 11:53 +0100, Murray Cumming wrote: > Everyone knows that OpenGL (Accelerated 3D) performance in Xephyr (on > the host PC) is bad, so you only see the smooth Maemo effects when > running on an actual device. But nobody I ask seems to know _why_. It's > maybe only a problem on Intel graphics hardware, but again, nobody I ask > knows why. > > I wonder if it's related to specific effects that Maemo uses, because > the simple glxgears demo (in the mesa tarball) happily gets me around > 1500 fps, or around 700fps using the -fullscreen option. > > Can someone enlighten me, ideally with bug report URLs? Doesn't anybody know? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ 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
On Thu, 2009-12-03 at 13:31 +0100, Jeremiah Foster wrote: [snip] > Maemo is based on debian which is a Free Software GNU / Linux distribution, > so many of the libraries use LGPL or the GPL. This may have a bearing on your > apps, so it often pays to understand the licenses before you start > distributing your software. That's unnecessarily alarmist. The licenses (such as LGPL, MIT) used by typical Maemo APIs create no significant problem for distribution of applications built on the platform. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ 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
On Thu, 2009-12-03 at 11:28 +0100, Dave Neary wrote: > 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. However, the published Maemo 6 Framework suggests that Maemo 6 will have a very different API for the UI, even if it does use general Qt conventions: http://qt.gitorious.org/maemo-6-ui-framework So I doubt that it's very helpful to write an application for Maemo using Qt now, other than just to learn about Qt. I wish they'd publish the API reference online. You can build it locally. I can't publish it because I'm afraid that the (no-modification, no-distribution) license doesn't allow it. These blog entries give some small idea of the new API: http://zchydem.enume.net/?p=128 http://zchydem.enume.net/?p=149 http://zchydem.enume.net/?p=243 > If you're primarily targeting N900 or lower, you should use GTK+ and > Hildon, that will be better integrated. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Bad Xephyr OpenGL performance
Everyone knows that OpenGL (Accelerated 3D) performance in Xephyr (on the host PC) is bad, so you only see the smooth Maemo effects when running on an actual device. But nobody I ask seems to know _why_. It's maybe only a problem on Intel graphics hardware, but again, nobody I ask knows why. I wonder if it's related to specific effects that Maemo uses, because the simple glxgears demo (in the mesa tarball) happily gets me around 1500 fps, or around 700fps using the -fullscreen option. Can someone enlighten me, ideally with bug report URLs? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing nonsense
On Tue, 2009-11-03 at 15:21 +, Gary Birkett wrote: > > I totally agree, it is not part of the testing regime itself and as > long as > an app is technically capable it passes the test. > the checklist has been defined here: > > http://wiki.maemo.org/Extras-testing/QA_Checklist Assuming that you are talking about ignoring UI issues, rather than just being outraged (outraged!!) that I apparently wanted the app to be ready for Maemo _6_: I don't claim to know what the aims of the testing are. But I did see this on the main testing page: http://wiki.maemo.org/Extras-testing#The_extras-testing_QA_queue_.26_you " Offering good quality community software to owners of Maemo devices is a top priority. We have a chance to show the world that open source software developed by community projects can match commercial software in terms of features, usability, reliability and fun. But we also face the risk of getting maemo.org Extras associated with beta quality software made by geeks for geeks only, without the last mile of polishing. " So I've been a) assuming that an application can't be impressive if if doesn't use Maemo 5 widgets and generally follow the Maemo 5 UI layout. b) assuming that the application maintainer would like some feedback. (Note that the wiki is generally verbose, fragmented, repetitive and hard to navigate around. That's not because it's a wiki.) -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing nonsense
On Tue, 2009-11-03 at 15:59 +0100, Till Harbaum wrote: > there's another problem with the testing i am facing with gpxview: > Nonsense ratings. > GPXView got a "thumbs down" for needing lots of porting to match the > maemo6 gui. > Yes, harmattan! Why the heck should a fremantle program not be > forwarded to > extras due to the fact that it will be hard to port it to qt (which is > what that guy > is imho trying to say)? It was a typo. I meant maemo 5. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Removing a package from extras-devel: glom-sqlite
How can I remove a package from extras-devel? I'd like to remove the glom-sqlite package because we now have sqlite support (and PostgreSQL) support in our main glom package in extras-devel. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
On Thu, 2009-10-01 at 11:11 +0100, Graham Cobb wrote: > On Thursday 01 October 2009 10:16:56 Murray Cumming wrote: > > I don't see any need whatsoever to fork hildon. It's just an invitation > > to confusion and nasty problems such as this. > > > > If someone wants to create a reusable set of widgets, they should just > > create a new library. It's not difficult. What's the downside? > > Quick summary of many emails: there are two options, both have > disadvantages... > > 1) New library: clean solution but problems are mainly that the widgets will > never be included in Hildon, may not be consistent with HIldon (particularly > as changes get made), the community will probably lose interest in maintaing > them, they will not be in the standard SDK or documentation, many developers > will never know they exist. And it is yet another widget library on top of > GTK: Maemo already has one (Hildon), do we really need two? These disadvantages are nothing compared to the disadvantages of forking, or even of adding (as yet unwritten) new third-party code directly to a stable library. And it assumes that trying to put widgets directly into hildon will magically improve them, maybe by therefore forcing hildon developers to work them. But that won't work - they will just rot there and eventually be removed. Just do what's normal. Create a library. If/When things are good enough then they can go into regular hildon. Writing good APIs is very difficult - it takes time and a few iterations. > 2) Put in Hildon: great long term solution (addresses all the disadvantages > above). Main disadvantage is that Nokia (not the Hildon development team) > control Hildon updates -- it is not posible for the community to provide a > package which updates Hildon on the device except as part of an official > Nokia SSU. Nokia control not only the timing of such a release but may (for > reasonable business reasons) even decide not to ship an updated Hildon in an > SSU because the risk of introducing a bug is larger than the benefit of the > new widget. Also, users may decide not to install the update for similar > risk concerns (maybe less likely in this age of frequent security updates). > So, a Hildon fork might happen if applications really want to use the new > functionality. > > There is no good answer. I believe the only long term fix is for Nokia to > (effectively) fork all the libraries they use and put them in a completely > separate directory (/usr/nokia/lib), and link their own applications to use > that directory (not forgetting to release source packages for their forked > libraries). They would then allow the community/user to install and update > any libraries in the standard directories, for non-Nokia apps to use. Of > course, any developers who trust Nokia more than the community (their choice) > could choose to use the Nokia libraries. > > Graham > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
On Wed, 2009-09-30 at 14:10 +0300, Marius Vollmer wrote: > ext Alberto Garcia writes: > > > On Tue, Sep 29, 2009 at 06:08:00PM +0300, Marius Vollmer wrote: > > > >> > we can perfectly create a parallel installable version of the > >> > same library, that the community can maintain in extras and link > >> > against in their applications. > >> > >> Yes, but there are some practical problems about that. > > > > The first obvious problem is that we would end up having two similar > > versions of the same library installed, and that means more disk and > > memory, apart from the inability to use maemo-launcher. > > > > What else? > > You have to be careful to never link two libraries with overlapping > symbols into the same process. In the case of libhildon, that is > probably manageable, and the possibility can probably be ignored. > > If necessary, there can even be a second maemo-launcher. I don't see any need whatsoever to fork hildon. It's just an invitation to confusion and nasty problems such as this. If someone wants to create a reusable set of widgets, they should just create a new library. It's not difficult. What's the downside? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
On Thu, 2009-09-24 at 08:28 +0200, Cornelius Hald wrote: > Hi! > > There are some important widgets which are deprecated without a > replacement in Fremantle. Those widgets are still available, but they > are not fully finger-friendly or don't look good. When this is just about regular GTK+ widgets that are not supported on Maemo, I'd rather just see the Maemo GTK+ port improved. We don't need more unnecessary ifdefs in our applications. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo on Beagle: Broken package dependencies
On Thu, 2009-09-17 at 20:32 +0200, Till Harbaum / Lists wrote: > Hi, > > i'd really suggest that we stop using this alpha port and > somehow join forces to get the beta2 port running or > even wait for the final sdk. > > I am really interested in getting fremantle to run on the > beagleboard, but the alpha sdk really is useless nowadays > as not a single application from the current extras-devel > will work with this. Also the alpha sdk is pretty limited. > > Anyone interested/willing to help on this? Possibly yes. Where can we track progress so far? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: open source licensing of maemo 5 example code MIT vs GPL
On Sat, 2009-08-29 at 11:19 +, gary liquid wrote: > When I went looking, I find many are licensed under a permissive MIT > license. > this is great and open source friendly, but my application is written > under > the GPL. > > I am not a licensing expert, so hopefully one of you guys will be able > to > help. > > is it possible to use and embed pieces of these examples into liqbase > or > would they need recreating from scratch? Yes, this license is chosen to pretty much let you do whatever you like with the example code. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Need sample application on Maemo 5 SDK
On Wed, 2009-09-16 at 16:58 +0530, Venugopal Rao Gubbala wrote: > Hi, > > Can you give link for maemopad example with your changes? > > Currently I am using command "apt-get source maemopad" Will it get me the > correct maemopad example for maemo sdk 5? Yes. But the svn source code may have a few small changes. Here is some information about checking maemoexamples out from svn: https://garage.maemo.org/scm/?group_id=273 Please use reply-to-all with the mailing list. Don't just take things off list. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Need sample application on Maemo 5 SDK
On Wed, 2009-09-16 at 10:16 +0300, Dmitri Vorobiev wrote: > On Wed, Sep 16, 2009 at 9:48 AM, Venugopal Rao Gubbala > wrote: > > Hello, > > > > > > Can any one provide me Sample application on Maemo 5 SDK with all the > > predefined folder structure. > > There are many Maemo 5 sample applications available from Garage: > > https://garage.maemo.org/svn/maemoexamples/trunk/ > > I guess this is what you might be looking for. I recently updated the maemopad example that is there. It should be quite sane. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
On Wed, 2009-09-09 at 14:25 +0300, Quim Gil wrote: > The maemo-optify tool helps developers to prepare Debian packages that > use /opt. This tool moves selected files inside the package to > locations > under /opt, and will symbolically link from the original location to > the > new place of the file. An early version of the tool can be found at > http://gitorious.org/maemo-af/maemo-optify - see the README file for > details. So we can just run maemo-optify-deb on our package's debian/ directory, reupload and not worry about it again? (Assuming that maemo-optify-deb worked OK.) -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ 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...
On Tue, 2009-09-08 at 20:57 +0200, Kees Jongenburger wrote: > 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 This is nonsense. Any project that doesn't have both a stable and an unstable branch is either not being used by real people or has stagnated. It's entirely normal. But that has nothing to do with git, which I wouldn't try to defend. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
On Fri, 2009-09-04 at 14:33 +0300, Kate Alhola wrote: > I just don't see any reason why you can't > make least as good UI design with Qt than you can > do with GTK+/Hildon. One small example that's been mentioned already in this thread: How do we create a HildonAppMenu with Qt? How do we create a HildonTouchSelector, and/or any of the specific selectors for time or dates, etc. I believe the answer is that we can't. The Maemo Qt developers have not yet even decided whether they will add API to Qt for Maemo-specific UI features, let alone implemented it. It's OK to like Qt, but there's no need to avoid the actual problems faced by actual developers. I guess you could hack something together that looked and felt similar to the standard hildon widgets, but that's hardly a development platform. Of course this doesn't suggest that things will be much better for GTK+ when a Qt-based Maemo API is the primary platform. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Time to push Fremantle extras-testing?
On Wed, 2009-07-29 at 16:21 +0300, Quim Gil wrote: > Hi, if you are maintaing packages in Fremantle extras-devel or you have > a generic interest in the Extras QA process, please have a look at > http://talk.maemo.org/showthread.php?t=30541 and a say in that thread or > here if you prefer. Yes, please. Then it would be clear that some of my stuff in extras-devel is really meant to be used but some of it is just early experimentation. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
garage.maemo.org is down
When can we expect garage.maemo.org to be up again? It's currently breaking the web uploader for extras-devel, which uses it for login. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Beagleboard touchscreens?
On Wed, 2009-07-01 at 10:29 +0200, carlos.guerre...@nokia.com wrote: > This will most definitely work with the BeagleBoard: > http://elinux.org/Xenarc_USB_touchscreen_for_Beagleboard/OMAP3_EVM > > We've got one of those in the office working with a BeagleBoard. > It has DVI input (you'll need a HDMI-to-DVI converter) and a > separate USB connection for the touchscreen. > It's not cheap though. > A minor annoyance - particularly if you are in a hurry - is > that Xenarc will not take foreign (as in non-US) > credit cards so you need to wire them the money before they ship. > Nevertheless I found their customer service responsive and > professional (in dealing with the order). They shipped it > quickly and it came in good shape. Thanks. I think we'll get one. 400 USD plus shipping doesn't seem too awful. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Beagleboard touchscreens?
I'm going to buy some BeagleBoards for the Openismus office. http://beagleboard.org/ I'd like to try installing Maemo 5 on them, which I believe is possible, and which will be a learning experience. I hear that Mer can be used with a mouse instead of just a touchscreen, but I'd like to install Maemo as intended, so I think we'll need touchscreen displays. So does anyone know of any touchscreen hardware that will definitely work with beagleboard and Maemo? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, 2009-06-12 at 12:17 +0200, Alberto Garcia wrote: > However the modifications you're talking about (changing the > implementation of Gtk widgets so they look/behave differently while > maintaining the same API) can't, by definition, be moved upstream :) I don't see why not. That happens for the Windows and Mac ports. OK, so this might need a slightly different structure in the source code, but it's perfectly #ifdef-able. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: svn2git conversion testing at garage.maemo.org
On Tue, 2009-06-09 at 23:15 +0200, Ferenc Szekely wrote: > Hello, > > I have finished the automated svn2git conversion support for garage > projects that are currently using subversion for revision control. > > I am looking for project admins who would be willing to help me testing > the whole procedure in the live environment. > > Please drop me an email if you are an administrator of a garage project > which has a subversion repository and you would consider using git in > the future. We could use git for maemomm. git is rather annoying to me personally day-to-day but we are used to it on git.gnome.org so we'd enjoy the consistency. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, 2009-06-12 at 00:23 +0200, Alberto Garcia wrote: > > > All in all I think that the Gtk-API should be used more, but that > > the rendering on the screen should just different from the rendering > > on the desktop. > > We try to do that where possible. Sometimes it's just a matter of > theming the widget correctly, but other times it requires significant > changes to Gtk, and the maemo-Gtk maintainers try to keep it as close > to upstream as possible, because maintaining a big fork is a hard > task, but they can tell you better than me :) It's easier now that GTK+ (and hildon) uses git. And the changes could go upstream within a year, reducing the differences in your fork. This happened for previous Maemo GTK+ additions: http://live.gnome.org/Maemo/GtkContributions (I know it's too late.) -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, 2009-05-29 at 23:07 +0300, Henrik Hedberg wrote: > However, usually developer should not need to know mode but Hildon > widgets should adjust themselves as much as possible during the > relayout. Unfortunately that seems not to be the case, as Conny > demonstrated earlier with some screenshots. Yes, someone should file bugs about those standard dialogs. And most custom application layouts would need a different layout for portrait mode. The GTK+ box model can't know that you suddenly want the buttons in a hbox on the bottom instead of in a vbox on the right. I'm currently reading about Android. They have a whole API for reacting to the orientation change for this reason. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, 2009-05-29 at 13:20 +0200, Alberto Garcia wrote: > To detect screen orientation changes you can e.g. use the > "size-changed" signal of GdkScreen. This seems like a rather long-winded way to detect landscape or portrait mode, requiring the hard coding of the dimensions. Surely some simple hildon API would make life easier? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkAction vs. AppMenu
On Sun, 2009-05-24 at 19:58 +0200, Cornelius Hald wrote: > Another thing is, that if you compare those two menus, you can easily > see that the Diablo menu has more structure due to the use of > separators. I'm not yet sure how to get back this structure, but I'll > make some experiments. HIG suggestions are welcome as well :) The Hildon HIG http://maemo.org/api_refs/5.0/beta/hig/html/ch06s09.html says " Only use toggle buttons as filters in a menu. Use them in groups, so they are not mistaken for regular buttons. Make the group behave like either a group of check buttons or a group of GTK radio buttons, as required. " I wonder how we should "use them in a group". Maybe putting them in a "filter" has that effect. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Does Maemo's Qt look like Hildon?
On Mon, 2009-05-25 at 12:25 +0300, Antonio Aloisio wrote: > While we are on the subject of Qt looking like Maemo without > API > changes, how are you dealing with the need for Maemo-specific > API such > as that in HildonWindow: > http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html > > This trick is possible because Maemo applications have menus, toolbars > as any normal > desktop application. Okay they look different, but we can instruct Qt > to give them the looks that > we want... > The same thing happens for the other official supported Qt platforms > (mac, s60 ans so on) Yes, I know that's the Qt philosphy, but repeating it doesn't answer my question. For instance: I guess, Qt windows can't usually have markup in their titles, so you'd be changing the documented behaviour (therefore subtly changing the API) if you parsed the regular title as markup, instead of offering separate API: http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html#hildon-window-set-markup (I think that the new API should be added to upstream GTK+ instead anyway.) I guess, Qt windows don't usually have a concept of "activated by the window manager": http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html#hildon-window-get-is-topmost (This is presumably something different than gtk_window_is_active(): http://library.gnome.org/devel/gtk/unstable/GtkWindow.html#gtk-window-is-active ) Also, I doubt that the Qt menu and toolbar API easily supports the idea of one-single "edit" toolbar, introduced in Maemo 5: http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html#hildon-window-set-edit-toolbar -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkAction vs. AppMenu
On Sun, 2009-05-24 at 15:55 +0200, Alberto Garcia wrote: > On Sun, May 24, 2009 at 01:48:11PM +0200, Murray Cumming wrote: > > > However, I'm was asking about the API and implementation, because > > the Fremantle UI guidelines are really out of our control at this > > point. > > The implementation can be changed, we're in beta and that means that > things can still be fixed. No, Beta generally means that API and UI changes are no longer possible. And I think that's the case with Maemo 5. It's unfortunate that we only saw a well-enough documented API reference and HIG at the beta stage. I think that the quality improvements from being more open would have been worth more than whatever short-term market positioning Nokia gained by working in isolation. Yes, I'm whining aimlessly. Sorry. > I think that the proper place to discuss this is the Maemo bugzilla, > so can you please file a bug against Gtk? > > https://bugs.maemo.org/enter_bug.cgi?product=Desktop%20platform Done: https://bugs.maemo.org/show_bug.cgi?id=4578 -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkAction vs. AppMenu
On Fri, 2009-05-22 at 22:09 +0200, Murray Cumming wrote: > On Fri, 2009-05-22 at 19:00 +0200, Alberto Garcia wrote: > > On Fri, May 22, 2009 at 05:08:08PM +0200, Cornelius Hald wrote: > > > > > The result now is: > > > - gtk_toggle_button_new() is working but it displays the buttons as > > > toggle buttons not as radio buttons. > > > > Well, that's what looks better in the Fremantle UI style. > > Yes, the Hildon HIG seems to suggest this, though it's very vague due to > the non-native-speaker English and the lack of screenshots (I filed bugs > about that already): > http://maemo.org/api_refs/5.0/beta/hig/html/ch06s08.html Sorry, that was the wrong section. It's actually not mentioned in the public Maemo HIG. I filed a bug: https://bugs.maemo.org/show_bug.cgi?id=4577 > > However, if radio buttons are meant to look a certain way in Maemo, why > isn't that just a matter of theming or even of making a change in the > GTK+ code instead of asking people to use the GTK+ API in an abnormal > way? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Does Maemo's Qt look like Hildon?
On Mon, 2009-05-18 at 23:39 +0300, Antonio Aloisio wrote: > Hi > > Although new-style Maemo 5 menus with sub-menus are > discouraged, I don't > think they should be forbidden. The current C API makes it > very > difficult to create them because HildonAppMenu is just a grid > container, > not a menu API. But I see no reason for Qt to make the same > mistake. > > Of course they would not be displayed as a tree-like menu. > > To be honest I don't know yet if we will have those menu in Qt too. > Currently I can't take other tasks, but if someone is interested in > implementing them, he/she is welcome and I'll happy to help him/her in > that job. While we are on the subject of Qt looking like Maemo without API changes, how are you dealing with the need for Maemo-specific API such as that in HildonWindow: http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html I'm trying to get a general feel for how Qt can stick to its concept of multiple platforms without API changes, though Mameo 5 seems to be the first Qt platform with a significantly uncommon UI and API. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkAction vs. AppMenu
On Sun, 2009-05-24 at 05:08 +0200, Alberto Garcia wrote: > > > Toggle-like radio buttons are quite common too in many user > > > interfaces. > > Not that I can think of. > > Well, I haven't made a list :) but out of the blue I can think at > least of the GIMP, Audacity, OpenOffice/MS Word/Abiword/Gnumeric, > the iPhone... Where I can find examples of these, it seems to be where space constraints make a real radio button difficult to use. Such as the alignment buttons in the OpenOffice toolbar. But Maemo Fremantle suggests their use _always_, for some other unexplained reason. This suggests that it's just about the cosmetic appearance, suggesting that it's an issue for the theme. Otherwise it's just another tedious #ifdef to add to code when porting to Maemo. > and I'd swear I saw them in the Moblin 2 UI too. But I > wasn't only thinking about computer interfaces, they're used in some > home appliances too. Home appliances generally have awful UI and have very little UI consistency. You'll find plenty of prior art for design mistakes in the home. That lack of consistency means that there can be no meaningful convention to differentiate between toggle buttons and radio buttons there anyway. However, I'm was asking about the API and implementation, because the Fremantle UI guidelines are really out of our control at this point. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkAction vs. AppMenu
On Sat, 2009-05-23 at 18:38 +0200, Alberto Garcia wrote: [snip] > Toggle-like radio buttons > are quite common too in many user interfaces. Not that I can think of. > For Fremantle it has been decided that the way to show radio buttons > it to make them look like toggle buttons, Fair enough. The Fremantle UI guidelines are out of our control, unfortunately. > and applications have been > designed with that in mind (and that includes making sure that radio > buttons and toggle buttons are not mixed in a way that can confuse the > user). [snip] Well, toggle buttons that act like radio buttons is confusing. But given that the Fremantle UI guidelines force us to have them, surely the very existence of any real radio buttons will confuse the user, making them even less likely to understand that these non-radio-radio-buttons actually act like radio buttons. So I still feel that you should just change the appearance of radio buttons and thus make both the UI and API simpler. Of course, I know it's too late to change any of this now, so I'm just complaining. These kinds of mistakes are always made when development is allowed to be done in isolation for a while, just as the initial Maemo API had many obvious mistakes. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkAction vs. AppMenu
On Sat, 2009-05-23 at 18:08 +0200, Alberto Garcia wrote: > On Fri, May 22, 2009 at 10:09:49PM +0200, Murray Cumming wrote: > > > if radio buttons are meant to look a certain way in Maemo, why isn't > > that just a matter of theming or even of making a change in the GTK+ > > code instead of asking people to use the GTK+ API in an abnormal > > way? > > Well, there are several reasons for that: > >* First, I don't think there's anything abnormal about that > API. gtk_toggle_button_set_mode() is there exactly for that > purpose and it's trivial to use. I think that function is widely considered to be useless and illogical. > I don't think it's necessary to > patch GTK when GTK is already designed to do what we want here. > >* Second, maemo-gtk already differs from the upstream version of > GTK in quite a few things. Still, API differences should be avoided where possible. A lot of unpleasant API differences were reduced before the Fremantle work. [snip] -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkAction vs. AppMenu
On Fri, 2009-05-22 at 19:00 +0200, Alberto Garcia wrote: > On Fri, May 22, 2009 at 05:08:08PM +0200, Cornelius Hald wrote: > > > The result now is: > > - gtk_toggle_button_new() is working but it displays the buttons as > > toggle buttons not as radio buttons. > > Well, that's what looks better in the Fremantle UI style. Yes, the Hildon HIG seems to suggest this, though it's very vague due to the non-native-speaker English and the lack of screenshots (I filed bugs about that already): http://maemo.org/api_refs/5.0/beta/hig/html/ch06s08.html However, if radio buttons are meant to look a certain way in Maemo, why isn't that just a matter of theming or even of making a change in the GTK+ code instead of asking people to use the GTK+ API in an abnormal way? > So even > if you use gtk radio buttons directly (i.e, without gtk actions) I > suggest you to do something like this: > > gtk_toggle_button_set_mode (GTK_TOGGLE_BUTTON (radio_button), FALSE); > > Of course you can still use the traditional radio button look if you > want, see the attached example (it might help you with the keyboard > accelerators too). > > Berto > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle user interface behaviour and API
On Thu, 2009-05-21 at 14:47 +0200, Cornelius Hald wrote: > On Thu, 2009-05-21 at 14:11 +0200, Alberto Garcia wrote: > > In principle that feature is not officially supported in Fremantle, > > and adding support in HildonTextView might create inconsistencies > > between similar-looking apps/dialogs that could be quite confusing. > > > > But of course we can reconsider it (I don't have the last word, > > though). I'll see what we can do. > > Well, if there is any chance to reconsider, that would be great. I > myself would be very happy and I think a bunch of other developers too. > I mean a big scrollable/panable text view is quite common for a lot of > applications. Mail clients, ebook readers, word processors, chat > programs, etc. all profit from copy&past for which we need a way of > selecting text. [snip] It would be interesting to know what UI Modest has for this in Fremantle when editing large emails. Personally I can't get that far in my own eccentric scratchbox target. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: separate input method for specific application/field
On Tue, 2009-05-19 at 14:26 +0200, Andrey Voropaev wrote: > Hello! > > I'm not very experienced with GTK and maemo, so please bear with me :) > > After reading various pieces of documentation, I got the impression, > that currently it is not possible to set custom input method for > specific input field. At least property "im-module" of GtkEntry is not > supported. Is this correct? This was added in GTK+ 2.16: http://library.gnome.org/devel/gtk/stable/GtkEntry.html#GtkEntry--im-module But Maemo Fremantle has GTK+ 2.12. So, no, I don't think there is any easy way to do this in Maemo. I personally pushed for that feature in GTK+ because of this. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Qt/Maemo in Qt's Git repository
Is there any plan to do the Qt Maemo port, currently in svn here: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/?root=qt4 in the (new) regular Qt git repository: http://qt.gitorious.org/ That would make it easier to see what is happening, and would probably make it easier for the developers to handle their changes. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Does Maemo's Qt look like Hildon?
On Mon, 2009-05-18 at 12:52 +0300, Antonio Aloisio wrote: > Hi, > An option is putting non sub-menus QActions in the QMenuBar. > In that way the developer don't have to use maemo specific APIs. > > Then Qt can > 1. fetches the actions from the QMenuBar > 2. checks if those QActions are not a submenus > 3. Creates a Dialog with buttons with those QActions > 4. Connects the dialog:show() to the title bar Although new-style Maemo 5 menus with sub-menus are discouraged, I don't think they should be forbidden. The current C API makes it very difficult to create them because HildonAppMenu is just a grid container, not a menu API. But I see no reason for Qt to make the same mistake. Of course they would not be displayed as a tree-like menu. > BTW that's not implemented yet... You are using a gmail email address. Do you actually work for Nokia and/or Qt? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Does Maemo's Qt look like Hildon?
On Fri, 2009-05-15 at 18:31 +0300, Antonio Aloisio wrote: > Hi, > currently they look like standars Diablo menus. > Those kind of menus are still in fremantle and we are going to use > them to keep the compatibility > with the Qt desktop applications. > Btw similar menus could be done by the application developers > themselves > > We haven't talked yet about having this kind of menu in Qt for > fremantle. BTW If we will plane to have them, it > will be possible without adding Hildon-specific API. I don't see how both aims are possible at the same time with the same API. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Does Maemo's Qt look like Hildon?
I'm curious about something, yet too lazy to try it myself: When creating menus with Qt in the Maemo 5 Beta SDK, using the normal Qt APIs, such as QMenu http://doc.trolltech.com/4.5/qmenu.html do they look like Maemo 5 menus? http://talk.maemo.org/showpost.php?p=283026&postcount=35 Or is it instead necessary to use some separate Hildon-specific API? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA from extras-devel to extras-testing
On Wed, 2009-05-06 at 19:09 +0300, Marius Vollmer wrote: > We have always known in the back of our minds that we should separate > packaging from upstream development, but it was always too much trouble > without sufficient gain if you are always making 'upstream' and package > releases at the same time anyway. The immediate gain to doing things in the standard way is mostly for others - either maemo-like alternatives such as Mer, or people using other tools, such as jhbuild. There's then some indirect gain for you as those other people help test and patch your code. Of course, I know you know this. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA from extras-devel to extras-testing
On Tue, 2009-05-05 at 16:40 +0100, Ian wrote: > Hi > > This is ideal, at least in theory. The problem is that many package > > maintainers don't know the programming language of the software they > > are packaging. If you are packaging something written in erlang you > > will not be able to quickly fix bugs in that package if you don't know > > erlang. This problem is a big one in debian, which is why they pass > > bugs upstream. How many package maintainers know the code of the > > package they maintain in maemo? > > This separation of code and packaging (.diff.gz and .orig.tar.gz.) is > IMO extremely important for Maemo and should be actively encouraged by > both Nokia and the community processes. > Downstream projects will thank us for it, i imagine Yes, I wish that Nokia projects such as hildon stuck to that instead of packaging directly from svn. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA from extras-devel to extras-testing
On Mon, 2009-05-04 at 13:57 +0200, Dave Neary wrote: > Hi, > > Andre Klapper wrote: > > However packaging is not a product, but one aspect of a product, so I'd > > prefer to see bug reports filed against the specific product. In general > > products should (must?) have a bugtracker - otherwise I consider the > > developers/maintainers to not be interested in user feedback. > > That's a bit of a leap isn't it? > > This feels like we're trying to re-solve problems that others have been > working on for a long time. Linux distributions have all added some form > of "upstream bug tracker" support. > > They all keep packaging bugs downstream, though. If there's a problem > with your Debian packaging, that problem should get reported to the > package maintainer, not the software developer. I think that varies between distros and packages and upstream modules. We can decide what we want to do. For instance, - Ubuntu and RedHat try to think a bit more about GNOME issues and send them upstream only when they are sure that it's a bug and one they agree with. They generally try to hide the fact that upstream GNOME exists, considering it a distraction for most users. - Ubuntu and RedHat don't care about less important packages, so you won't get much attention from their bug tracker for them. You can file distro bugs but you'll learn not to bother. - Random Minor Distro users are best to use upstream because they don't have a bug triage team to send stuff upstream anyway. - gentoo users are meant to put everything through the gentoo bug trackers first. Which is how I (upstream) like it. I don't have an opinion yet about what's best. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA from extras-devel to extras-testing
On Mon, 2009-05-04 at 12:06 +0200, Jeremiah Foster wrote: [snip] > And if > someone does not want to create a bug tracker, for whatever reason, > how can we convince them not to open their own repo if Maemo rejects > their package? We can't. But then it probably won't be as easy for people to install that application. At the least, it will be much less visible on the device and on maemo.org. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA from extras-devel to extras-testing
On Sun, 2009-05-03 at 20:15 +0200, Jeremiah Foster wrote: > Who is going to build all of this infrastructure? For the voting stuff, I have no idea. Maemo/Nokia wants it so I guess they will make it happen. > Won't this type of > requirement help create separate private repos? You mean the possible bug-tracker requirement? I hope maemo.org still eventually aims to provide real bug tracking (bugzilla) to any package in extras. So a package can just use that if it doesn't have something already. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA from extras-devel to extras-testing
On Thu, 2009-04-30 at 22:53 -0400, Ryan Abel wrote: > Assuming the package has a bug tracker, sure. That seems like a good requirement in general. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to capture mouse event for a GtkWindow in maemo?
On Sun, 2009-04-19 at 13:00 +0800, chunlong yu wrote: > I inherit the Gtk::Window ,overwrite it's virtual member function > on_button_press_event (GdkEventButton* event) and > on_button_release_event (GdkEventButton* event) , There are no such default signal handler virtual functions in the maaemo version of gtkmm: http://maemomm.garage.maemo.org/docs/tutorial/html/ch04s02.html > and add such codes in the construction function: > singal_button_press_event.connect(...) and > singal_button_release_event.connect() You probably need to connect "after": http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/sec-xeventsignals.html > or add such codes in the construction > function :add_events(Gdk::EventMask::...). Note that you can only use add_events() after the widget has been realized. For instance, in a signal_realize signal handler. > Neither method can capture mouse event. how can i response mouse event > for a GtkWindow in maemo? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Google Summer of Code
On Tue, 2009-03-31 at 08:20 +0300, Ville M. Vainio wrote:
> 2009/3/31 Ian Foster :
>
> > Hello, I am a student looking to apply for the Google summer of code with
> > Maemo. Im looking for something that does not require a lot of programing
> > experience, but I would love to lean more.
>
> Implement "maemo launcher" for PyQt apps - i.e. have a a python
> instance ("launcher daemon") around that has pyqt imported, and forks
> new processes when new program wants to be launched.
>
> This has the advantage that it's not maemo specific, but can be used
> to speed up pyqt app launch wherever linux is used on slow
> environments.
That could be useful, but it's not a 3 month project.
--
murr...@murrayc.com
www.murrayc.com
www.openismus.com
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle extras?
On Fri, 2009-03-06 at 07:14 -0500, Ryan Abel wrote: > On Mar 6, 2009, at 5:58 AM, Murray Cumming wrote: > > > Are there already working Mameo Fremantle extras-devel and extras > > repositories and the corresponding build/promotion system? > > > Please see the relevant thread on maemo-community.[1] > > > [1]http://lists.maemo.org/pipermail/maemo-community/2009-February/003336.html I did (and I joined that mailing list after finding it via google), but I didn't see a clear conclusion or any statement that it has been done. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Fremantle extras?
Are there already working Mameo Fremantle extras-devel and extras repositories and the corresponding build/promotion system? I'd like to use it soon to upload some maemomm packages. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fast PDF library
On Wed, 2008-12-03 at 15:06 +, Graham Cobb wrote: > On Wednesday 03 December 2008 05:09:49 Dmitry S. Makovey wrote: > > Should I just abandon the idea of straight PDF rendering on Maemo and > > convert documents into HTML instead and view them using browser? > > This is also an issue for being able to use the tablet to show presentations. > > I have experimented with exporting presentations to PDF but they just take > far too long to render on the tablet. [snip] I suggest that you talk to the libpoppler developers about how you can help them to optimize the code. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Remove list item -- How on earth?!
On Fri, 2008-10-03 at 03:23 +0300, Queen wrote: > Hello all! > > So, here's the deal. > I made a GtkWidget *window5. > It has several widgets. Among them, a GtkList *list_info_description and > a menu. Do not use GtkList. It is deprecated (since years ago), and rather broken, as you can read here: http://library.gnome.org/devel/gtk/stable/GtkListItem.html You probably want to use a GtkTreeView, with a GtkListStore model. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: On the problem of Nokia bugs substituting changelogs
On Tue, 2008-09-02 at 17:16 +0200, Andre Klapper wrote: > Am Dienstag, den 02.09.2008, 16:41 +0300 schrieb > [EMAIL PROTECTED]: > > > -Original Message- > > > From: Dave Neary [mailto:[EMAIL PROTECTED] On Behalf Of ext Dave Neary > > > [EMAIL PROTECTED] wrote: > > > Would it be possible for the Modest team to exclusively use > > > the external bugzilla, given that it's a free software project? > > > > It would be very nice from the community perspective, very much so, > > and of course it would make open development much easier as well. > > > > But, internally, the development process is highly regulated, and tools > > like bugzilla play different roles than they do outside -- trust me > > on that one. Modest has to satisfy both of its natures, with > > the internal one getting the most emphasis, for very pedestrian > > reasons... > > > > So, while I agree that it would be nice to have one open bugzilla, > > I do not see that happening anytime soon. > > I also do not see this happening very soon, but it is definitely a > long-term target of mine. > Developers want one central place to track software issues. > This currently is Nokia's internal bug tracker, this should become > bugs.maemo.org for Maemo open source projects. I'm not confident that this will happen even for open source parts because the work on open source parts is often secret. Nokia are just too afraid of leaking future product features and schedules. But maybe you can persuade them to do this for _some_ modules, such as GTK+, if not for others, such as hildon-libs. I don't speak for Nokia, of course. But that shouldn't be a blocker to getting some human-readable text for release notes or NEWS files (ChangeLogs are something else, traditionally). Once a release is published, I don't see how Nokia could object to publishing the changes. Hopefully Andre can be the guy to extract the bug titles for those internal bug numbers. It might would need advance planning. > The task is to work out those issues that currently block managing > Modest, MicroB, etc. completely in public and find solutions for each > issue, most probably quite often with the input of lawyers, sigh... > So adopting/using Nokia's current internal processes and workflows in > public (bugs.maemo.org) requires having a policy about those pieces of > information that a commercial company does not want to be accessed by > its competitors, such as policy plans, product and hardware information, > information about the internal testing infrastructure or especially > copyright related issues. > > (Half of this email copied from a blog entry I was just writing on.) > > andre -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Standardization of packages version name in the extra repositories
On Fri, 2008-07-25 at 13:21 +0100, Andrew Flegg wrote: > On Fri, Jul 25, 2008 at 1:17 PM, Murray Cumming <[EMAIL PROTECTED]> wrote: > > On Fri, 2008-07-25 at 11:20 +0100, Andrew Flegg wrote: > > > [snip] > >> * Any package patched, or not from a existing deb source, needs to > >> have a maemo version suffix. > > > > So every single package in extras should have a maemo suffix? > > No, because some projects will be simple repackages of an upstream > package with no additional Maemo patches which aren't available > upstream. Ah, thanks, that seems to be the opposite of what you say above. So, how about packages that are not in debian? When you say "upstream" here, it's not clear whether you mean upstream debian or upstream source. upstream normally means source. We should strongly discourage any patches that are not submitted to the upstream (source) projects. I suggest that these rules should be stated somewhere simply on a wiki page, not somewhere deep in a PDF. > For example, Maemo Mapper has no Maemo-specific patches and so the > upstream version *is* the version of the deb. Similarly, something > that's come from (say) mud from an upstream deb without any further > patches (probably, typically, CLI apps) would also not have a maemo > suffix. > > However, if the upstream source can't build a Maemo package, or it's a > package solely put together for Maemo, it needs a maemo suffix. > > That's my understanding - hopefully Eero could correct me? > > Cheers, > > Andrew -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Standardization of packages version name in the extra repositories
On Fri, 2008-07-25 at 11:20 +0100, Andrew Flegg wrote: > On Fri, Jul 25, 2008 at 11:16 AM, Antonio Aloisio > <[EMAIL PROTECTED]> wrote: > > > > I propose you all, to choose a standard version name for us maemo packages. > > It's such a good idea, it's already been done! :-) > > See section 3.1 of the Maemo Packaging Policy: > > https://maemo.org/forrest-images/pdf/maemo-policy.pdf > > My understanding[1] of this is: > > * Any package patched, or not from a existing deb source, needs to > have a maemo version suffix. So every single package in extras should have a maemo suffix? > * For example, if the base version is 7.0, the package version from > should be 7.0-0maemo1 for the first upload, 7.0-0maemo2 for the > second, etc. > * If the upstream package comes from Debian (with version 3.5-7) > and is unpatched, > the package uploaded from is also 3.5-7. > * If the upstream package comes from Debian (with version 3.5-7) > and is patched, > the package uploaded from mud is 3.5-7maemo1 for the first upload, > 3.5-7maemo2 for the second, etc. > > Hope that helps, > > Andrew > > [1] http://wiki.maemo.org/User:Jaffa/mud_design#Requirements -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Sardine is dead.
On Mon, 2008-06-23 at 16:23 +0300, Marius Vollmer wrote: > Hi, > > I am sorry to announce that the 'unstable' Sardine distribution of the > Hildon Desktop is dead. It's corpse is being removed: the buildbot will > be shut down, and the repositories will be removed from the servers. > > We didn't manage to make it useful enough to justify keeping it alive. > > Of course, the source code of the packages that have been built for > Sardine continues to be developed in real-time in the open, and you can > in fact expect more projects to be freed over time. > > Most of the projects are developed on stage.maemo.org: > > https://stage.maemo.org/svn/maemo/projects/haf/trunk/ > > Should anyone be interested, the Sardine machinery is hosted in the > maemo garage: > > https://garage.maemo.org/projects/sardine/ > > So long, and thanks for all the fish! This is sad. There's a big need to have a real unstable distribution so that application developers can adapt to new versions of Maemo before they are released. Or at least some beta releases. The problem with Sardine was that it didn't work, because Nokia didn't use it. If only Nokia and the outside world could use the same repository (with a few secret extras for the Nokia people) then life would be much simpler for everyone, including Nokia and it's sub-contractors. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community council
On Mon, 2008-06-16 at 22:13 +0200, Dave Neary wrote: > Hi all, > > So - the community council, then... > > what do people think of the idea? I like it. It's not clear what it will become, but it could be a good way for Maemo to start becoming less owned by Nokia alone, thus giving it more life. I think Nokia want to have way to do this. I recommend being quite informal to start with, only adding rules and bureaucracy where it's genuinely useful. > What should the remit be? At the very least it can be a group of people who's job it is to clearly and briefly express the community's needs and concerns. Where consensus exists, it should express it. The mailing list is too busy for most people to see that otherwise. Like the GNOME Board, it may later wish to delegate some tasks to specialized groups, such as administrators for mailing lists, web servers, source code repositories, etc. > I agree with the poster who said that monthly or quarterly election > would be too frequent. All depends on how onerous the voting process > will be, I suppose. > > Proposals to go here: https://wiki.maemo.org/Task:Community_Council > And discussions can go to the list, or here: > https://wiki.maemo.org/Talk:Task:Community_Council -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo.org community leadership - the maemo.org Community Council
On Fri, 2008-06-13 at 17:26 +, Darius Jack wrote: > Nothing is automatic on the Internet. > That's you, moderator, administrator, operator, setting the terms. > That's you cutting the thread off. > Today you set 20 kb limit, tommorow 10kb, next week 1line input. > Long live democracy. > > Your money, your business, your terms. > But please don't call me a community. > I use Google Groups and there is no limit on thread size. > A good practice is to follow full thread, > no pre-editing, no cutt offs, no moderation > > One day you speak about a community > and another day you show me who is the ruler. > Bye bye my fiends, no more communities of developers governed by > moderators. > Nokia , shame on you, financing community governed by moderators. > > One day 20kb limit is in operation. > Tommorrow 10kb, next week 1 line is allowed. > Or better. No-reply-discussions. That's not even a Haiku. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [gtkmm] Gdk::Pixbuf::create_from_file() segmentation fault in maemo
On Mon, 2008-06-02 at 15:25 +0800, Dinh Khac Thanh wrote:
> Hi all,
>
> I got problem trying to load an image to a gtkmm using pixbuf's
> create_from_file() in scratchbox. Here is the snippet of code:
> std::auto_ptr err;
>
> cout << "Start to load logo" < image =
> Gdk::Pixbuf::create_from_file("./icons/logo.png",err);
> Glib::ustring err_str = err2->what();
You need to check pointers for NULL before dereferencing them. That's
basic C++. For instance;
if(err)
std::cout << "Error message = " << err->what() << std::endl;
else
std::cout << "Succeeded" << std::endl;
> cout << "Error message = " << err_str< cout << "Finish to load logo" < These lines are taken from a DrawingArea widget's constructor with
> 'image' variable of type Glib::RefPtr.
>
> The output is:
>
> Start to load i2rlogo
> qemu: uncaught target signal 11 (Segmentation fault) - exiting
>
> if I change the path to the image file that makes it wrong path, no
> segmentation fault error:
>
> Start to load logo
> Error message = Failed to open file './icons/home.png': No such file
> or directory
> Finish to load logo
>
> Could anyone suggest the reason behind this?
>
> Regards
>
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
--
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Gtkmm's DrawingArea problem
On Fri, 2008-05-30 at 14:19 +0800, Dinh Khac Thanh wrote: > Hi all, > > I wrote a simple program using gtkmm's DrawingArea widget. It turns > out fine (no error) but does not show up in Xephys window. After > searching Google I got this: [snip] > > > Yes, the version of gtkmm that is in the maemo repository uses some > > > > special optimizations. The most obvious change is that there are no > > > default signal handlers, so you must connect a signal handler instead of > > > just overriding the default one. > which I think is my problem (I check on_expose_event and it is not > called). But I couldn't find the solution from that link. > Could anyone tell me how to solve this? Thnx in advance. You just need to add this code in your constructor: #ifndef GLIBMM_DEFAULT_SIGNAL_HANDLERS_ENABLED //Connect the signal handler if it isn't already a virtual method override: signal_expose_event().connect(sigc::mem_fun(*this, &Clock::on_expose_event), false); #endif //GLIBMM_DEFAULT_SIGNAL_HANDLERS_ENABLED I am adding that to the clock example in the gtkmm book (in the gtkmm-documentation module): http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/sec-drawing-clock-example.html > Btw, anyone has experiences on using Gnome Canvas in maemo? I am > thinking of switching to Gnome Canvas since using Drawing Area/Gdk's > Pixmap is a pain to me. I recommend that you use goocanvas. libgnomecanvas is not really maintained now, and people generally avoid using it. goocanvamm exists, though I haven't yet used it on Maemo. Do try to use the gtkmm-list mailing list for questions about gtkmm. You were lucky that I saw your message on maemo-developers. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Who's who in maemo
On Wed, 2008-05-07 at 10:58 +0200, Dave Neary wrote: > Hi all, > > I've been looking for a "Who's who in maemo" - a list of active > developers (Nokia and otherwise) and what they specialise in. I haven't > found one. > > I think that such a list would be very useful. In particular, I'd like > to know when I see a nokia.com email address replying to a subject about > the roadmap whether the person is a decision maker, a developer, or > somewhere in between. It would also help, I think, to allow people to > personalise and better direct any concerns and complaints, rather than > just saying "It's Nokia's fault". > > What do people think about this? Should I just get started and see how > far I get? Yeah, something like this would be useful. It would be generally useful if @nokia.com people mentioned their roles in their email footers, or their job titles where these are informative. We should not force people to speak only about what they are officially responsible for, because that would kill converstaion, but it would be nice to have a clue about what they might be speaking officially for. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fwd: Urgent regarding resizing of boxs
On Sun, 2008-04-27 at 03:56 -0300, nisha jain wrote: > Hi All, > > I am facing a problem in gtk hbox and vbox widgets and i have to > resolve this issue as soon as possible. > Please let me know if any one has some inputs-- > > I am having following code to make a GUI for my application and I > need to resize my windows to utilize all > space i don't want any gaps inbetween the hboxs and vboxs but these is > lots of space wasting. In general I recommend that you play with Glade to get more experience of how GtkBox packing options work. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder for extras repository public beta
On Fri, 2008-04-25 at 17:36 +0200, Niels Breet wrote: > Hi all, > > > A while ago we discussed the idea of an autobuilder for the extras > repository. [1] We "We" is Nokia/Maemo, right? > have been working on creating such an autobuilder and > have been testing it in private. As a result we now think it is time to > do a tests with a larger group and make it publicly known. I love you. > Please give > it a try and tell us your results. > > - What does the autobuilder do? > > The autobuilder takes a source package from the incoming queue and tries > to build it in a fresh environment. The builder fetches all dependencies > from the extras-devel repository. If it can't find the dependency in > extras-devel, it will fail and send a mail to the extras-cauldron-builds > list. [2] > > If there are no problems with the package, the builder can create armel, > i368 and source packages. Those will be put in the extras-devel > repository after a successful build. > > Instructions for the builder can be found at here[3]. > > The builder only handles building one package at a time. If you have > dependencies that are not present in the extras-devel repository, please > upload these first. > > - web-based assistant > > We have also created a web-based assistant[4] to help you with requesting > rights to upload and creating/uploading of source packages. You can upload > packages to the builder with either dput or the assistant. > > - How do I get my package into extras? > > After a successful build a package will appear in the extras-devel > repository. You can move your packages from extras-devel to extras with > the promotion interface[5]. Instructions for the promotion interface > can be found here.[6] > > We would like to invite all developers to take a look at the autobuilder > and promotion interface and try it out. Please discuss problems and > feature requests on the maemo-developers list.[7] > > More information about our effort can be found at the extras-cauldron > website[8]. > > > > - Niels > > > [1] > http://lists.maemo.org/pipermail//maemo-developers/2007-November/thread.html#12600 > and others. > [2] https://garage.maemo.org/mailman/listinfo/extras-cauldron-builds > [3] http://extras-cauldron.garage.maemo.org/HOWTO.html > [4] https://garage.maemo.org/extras-assistant/index.php > [5] https://garage.maemo.org/promoter-beta/interface.py > [6] http://extras-cauldron.garage.maemo.org/devel-mover.html > [7] https://lists.maemo.org/mailman/listinfo/maemo-developers > [8] http://extras-cauldron.garage.maemo.org/ > > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How do I get package into extras or extras-devel?
On Mon, 2008-04-07 at 18:30 -0400, Jason Edgecombe wrote: > Hi Everyone, > > I'm working on porting/packaging Kerberos & OpenAFS to OS2008. > > How do I go about uploading a package to extras-devel & extras? I'm > hoping to be ready in a couple of weeks, but I wanted to start the ball > rolling. This should help: http://maemo.org/community/application-catalog/extras_repository.html -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What does Nokia's acquisition of Trolltech mean to Maemo?
On Wed, 2008-01-30 at 21:26 +0100, Klaus Rotter wrote: > Klaus Rotter schrieb: > > Well, it is (to me) more a question of C vs C++. I started with C about > > twenty years ago and liked it a lot. But some of the features of C++ in > > addition with Qt are IMHO more "elegant", if you use a OO toolkit with > > an OO language like C++. E.g. methods overloading (which is really nice). > > Some addition to this: I started programming Qt about 10 years ago with > Qt 1.x. Don't remember exactly. Qt was more or less the reason I started > learning C++. I got used to use some of the features C++ offered, but I > have some problems to read a program which uses a lot of the advanced > C++ features. Meanwhile, I wrote some Java code (starting which Java > 1.0) and found it somewhat easier (at least to understand) compared to > C++. But sometimes I miss pointers. > After this period I started to work with gtk and C (I tried a lot of > other toolkits, eg. FLTK, wxWidgets (version 1), Fox and also Tcl/Tk > with ET). So, when I came back to gtk and C and found some "missing" > features in the object oriented design. gtkmm > So, Vala may be one way to go... > it really looks interesting. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Contribution code, ...
On Tue, 2008-01-15 at 13:59 +0100, Martin Grimme wrote: > Hi, > > 2008/1/15, Murray Cumming <[EMAIL PROTECTED]>: > > It's working in Germany as of a few days ago. > > Did you get a full discount or was it correctly 99 EUR? No, I didn't get a full discount. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Contribution code, ...
On Mon, 2008-01-14 at 15:05 +0200, Quim Gil wrote: [snip] > - There are no issues in Austria, Belgium, Denmark, Ireland, Finland, > Netherlands, Norway, Sweden and Switzerland. > > - We are getting reports from France, Germany, Italy, Spain and UK at > this moment. There have been some issues in some of these shops but let > me until tomorrow to summarize the situation. It's working in Germany as of a few days ago. > - We will talk to US and Canada later today due to different timezones. > > I'm hoping to post a general summary tomorrow, hopefully full of good > news. :/ -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: HildonCalendar
On Tue, 2008-01-15 at 10:20 +0200, Markku Vire wrote: > Hi, > > As your option two describes: Previous versions of Hildon contained a > patch for GtkCalendar that made it fit better to the environment. Now > this custom implementation is known as HildonCalendar. Other > (non-hildon) environments can continue to use GtkCalendar as earlier. > > Too bad that this customization was not possible to implement trough > inheritance, but there are no virtual methods in GtkCalendar class :( It sounds like the people who wrote HildonCalendar should work on a new calendar widget to go in upstream GTK+. > I didn't find either the documentation about HildonCalendar, but the > headers show that the API is similar to GtkCalendar, just replace > gtk_calendar_* with hildon_calendar_*. See: > > https://stage.maemo.org/svn/maemo/projects/haf/trunk/hildon-1/src/hildon-calendar.h > > Cheers, > > -Markku- > > Graham Cobb wrote: > > I am currently trying to tidy up some things reported by the hildon-audit > > tool. One thing it has reported is: > > > > gtk_calendar_new: GtkCalendar is deprecated, use HildonCalendar from > > hildon-1: > > see http://live.gnome.org/Maemo/Gtk210Migration#M14 > > > > I have looked at that URL but it doesn't help much! > > > > My first problem is in deciding exactly what has been deprecated. The > > reference to the GtkCalendar widget is in code which is not currently > > conditional for Hildon: it is the same on all platforms. Is the message > > telling me: > > > > 1) That GtkCalendar is being removed from Gtk. On Hildon it is replaced > > with > > HildonCalendar. On other platforms it is replaced with other things, not > > specified. > > > > Or... > > > > 2) Today code can use GtkCalendar on Hildon and get a calendar widget that > > is > > customised for the Hildon environment. That behaviour is changing and, in > > future, GtkCalendar widgets will be the same on all platforms and not > > optimised for Hildon. To get a calendar widget for use on Hildon you > > should > > use HildonCalendar, not GtkCalendar. But GtkCalendar is still the correct > > widget to use on other Gtk platforms. > > > > Or... something else? > > > > And, lastly, where can I find some documentation on HildonCalendar? > > > > Graham > > > > P.S. I am really not a GUI guy -- give me a kernel interface any day... > > ___ > > maemo-developers mailing list > > maemo-developers@maemo.org > > https://lists.maemo.org/mailman/listinfo/maemo-developers > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: developer program discount code does not work
On Thu, 2008-01-10 at 14:10 +0530, Trilok Soni wrote: > Ok. I have just got an e-mail from maemo team that expiry date of code > is now > extended to 30.06.2008. Thanx Nokia and Maemo Team. And my code (the second one) started working yesterday at the German online Nokia shop. This has been a mess, but Nokia is a large company that has some difficulty communicating with itself. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GTK IM switch by software keyboard
On Thu, 2008-01-03 at 22:52 +0800, Bin Chen wrote: > I have ported a new GTK input method module to my platform, the > regular steps to switch input method in a GTK+ text widget is to right > click the entry point and select the desired input method. > > Now I want to do all this more simpler, I want to add a button in the > software keyboard or a hardware keyboard, when press the button, the > GTK+ input method will switch in a round-robin scheme. Is it possible? I don't believe this is currently possible, but it would be possible with the very latest version of GTK+: http://bugzilla.gnome.org/show_bug.cgi?id=502446 Unfortunately, that's not in any version of Maemo, or even any regular Linux distro yet. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Announcement: OS2008 2.2007.50-2 source repository
On Fri, 2008-01-04 at 14:52 +0100, Frantisek Dufka wrote: > [EMAIL PROTECTED] wrote: > > Hi, > > > > The source code for open source components of OS2008 version 2.2007.50-2 > > have been uploaded to a new repository. To be able to find the sources, > > please point your browser to > > > > _http://repository.maemo.org/pool/os2008/free_ > > > > Thank you. So Chinook and os2008 is different thing now. That makes no sense to me - it's contradictory to everything we've heard before. I don't understand why a new repository has been created. > Chinook is the > SDK and os2008 has sources to (latest only?) firmware image. That's nice > and makes sense. Perhaps os2008 repository is there also to provide > those planned non-monolithic OS updates in future? > > So, umm, any plans to make os200x repository updated together with > firmware release in future? > > Frantisek > > P.S. I am very happy about the kernel source, thanks > http://repository.maemo.org/pool/os2008/free/source/k/kernel-source-rx-34/ -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Chinook install
On Thu, 2007-12-20 at 16:15 -0500, [EMAIL PROTECTED] wrote: > > Is there a problem repository.maemo.org? Yes. I'm not even going to try to use it for another day or so. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo Chinook g++ bug: numpunct
g++ in the Maemo Chinook has a rather serious bug that is known to have been fixed already for desktop versions of Linux. It's not getting any love in the public bug-tracker: https://bugs.maemo.org/show_bug.cgi?id=2465 -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
gnome-doc-utils on Maemo Chinook
Has anyone managed to build a gnome-doc-utils package for Chinook? This would be useful when building several other packages. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Changing GPG key
On Tue, 2007-11-06 at 13:23 +0100, Johannes Schmid wrote: > Because I revoked my old GPG key, I wanted to change the key stored for > the Maemo extras repository. After my mail to [EMAIL PROTECTED] remained > unreplied I would like to ask whom I should contact to change the key. Please. This is really slowing us down. Can't someone let Johannes upload packages again? -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to get rid of this error.
On Wed, 2007-10-31 at 00:45 -0400, pradeep MN wrote: > Hi all, > We are using Ubuntu, scratchbox 1.0.7, how to over come this > error while running C++ program.. > > > > [sbox-SDK_X86: ~/apps] > g++ ex1.cc -o ex1 `pkg-config hildon-libsmm > hildon-fmmm --cflags --libs` > > > Package sigc++-2.0 was not found in the pkg-config search path. > Perhaps you should add the directory containing `sigc++-2.0.pc' > to the PKG_CONFIG_PATH environment variable This is rather strange. Is this Maemo Bora or one of the Chinook alphas or betas? -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Repositories mess: conclusions and actions
On Sat, 2007-10-27 at 21:17 +0300, [EMAIL PROTECTED] wrote: > but at least nobody can say - 'sorry guys, I didn't know my app could brick > the device'. Requiring any quality control before having a place to put the alpha/beta-quality stuff will just stop us from getting much software. Software needs to be released in order to increase its quality. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Wed, 2007-10-24 at 14:49 +0300, Quim Gil wrote: > This is an invitation to resume all previous discussions about "the > repository mess" and come up with conclusions and actions. Please read > this through and have a say, specially if you are maintaining a > repository with maemo packages out of maemo.org [snip] Does this need to be in place for Chinook, or just for Chinook+X? Or, will the addition of new packages to Chinook's extras repository block on these policies being in place? I'd like to get some beta (alpha, maybe) Glom packages in to Chinook's extras, to get things moving. They wouldn't pass quality tests. But I don't really want to set up my own repository. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo training
On Sat, 2007-10-20 at 15:52 +0200, Mathias Uebelacker wrote: > Hello, > > i saw that movial offers a 3 day training with maemo stuff. Is there > any known training facility in germany which offers a training like > that or is there any online training? Openismus is based in Germany. Maybe we can offer some developer training. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810 maemo device program open for submissions
On Fri, 2007-10-19 at 10:20 +0300, Quim Gil wrote: > On Fri, 2007-10-19 at 08:15 +0200, ext Murray Cumming wrote: > > After entering my profile > > information, and clicking publish on the confirmation page, I am taken > > to https://maemo.org/profile/, but I see no way to make a request for an > > N810 discount. > > Because this is the private view of your profile and in the way we have > designed the thing the application is done in the edit profile side. > > Go to edit your profile and you will find the option to apply... unless > you have declared an affiliation with Nokia. This is also behaving in > the way it has been designed. Ah. I have declared a contractor affiliation with Nokia. But you just told me in a private email to apply anyway, after I double-checked with you about the "if in doubt, apply". I guess I'll pretend not to be affiliated. > I'm filing bugs like http://bugs.maemo.org/show_bug.cgi?id=2133 thanks > to your feedback to improve this tool. Feel free filing bugs or > enhancements requests yourselves. We can discuss and fix stuff there. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N810 maemo device program open for submissions
On Thu, 2007-10-18 at 15:17 +0300, Quim Gil wrote: > It's out now: > > http://maemo.org/news/announcements/view/1192708879.html This says "In order to apply go to your maemo profile (same login as the so-called Garage account) and make your request there. Please read carefully the instructions, terms and conditions." I feel like I've failed the first test. After entering my profile information, and clicking publish on the confirmation page, I am taken to https://maemo.org/profile/, but I see no way to make a request for an N810 discount. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Trying to get started with Chinnok
On Thu, 2007-10-04 at 06:15 -0400, William Hope wrote: > Hi all, > I'm new to this type of development environment, so I'm not sure I > didn't miss something. > > I'm going straight to Chinnok and to get started, I wanted to compile > the simple example in "Programming with maemomm". > > This is on a fresh install following the install instructions for > "Maemo 4.0 Chinook beta SDK" & "Programming with maemomm". > > I was able to get around this: > > [sbox-SDK_BETA_X86: ~/prgms/ppim/trunk/src] > g++ simple.cc -o simple > `pkg-config hildon-libsmm hildon-fmmm --cflags --libs` > Package hildon-libsmm was not found in the pkg-config search path. [snip] You need hildonmm rather than hildon-libsmm for Chinook. That should be correct when mentioned in the Chinook version of "Programming with maemomm": http://maemomm.garage.maemo.org/unstable/docs/tutorial/html/ch04s04.html Maybe you are reading the version for the stable (Maemo Bora) version: http://maemomm.garage.maemo.org/docs/tutorial/html/ch04s04.html -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Patches for hildon with regular GTK+?
On Tue, 2007-10-02 at 13:38 +0200, Tollef Fog Heen wrote: > * Murray Cumming > > | On Tue, 2007-10-02 at 09:19 +0200, Tollef Fog Heen wrote: > | > * Murray Cumming > | > > | > | I guess that Ubuntu must be patching hildon to create their Ubuntu Gutsy > | > | packages: > | > | http://packages.ubuntu.com/gutsy/devel/libhildon-1-dev > | > | Does anyone know where those patches are? > | > > | > https://code.launchpad.net/~ubuntu-mobile/hildon-1/ubuntu is the > | > Launchpad page related to our branch of hildon-1. It's branched off > | > SVN from back in May, so we should probably merge in changes after > | > that. (https://code.launchpad.net/hildon-1 is the set of all branches > | > related to hildon-1, including an ongoing import of svn trunk.) > | > | Thanks. Do you plan to submit patches upstream? > > Yes, we just haven't gotten around to it yet. It's definitively > something we want to do. Great. Thanks. By the way, it would be nice if you could update your hildon-1 package. The upstream version has an API change needed by the latest hildonmm. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Patches for hildon with regular GTK+?
On Tue, 2007-10-02 at 09:19 +0200, Tollef Fog Heen wrote: > * Murray Cumming > > | I guess that Ubuntu must be patching hildon to create their Ubuntu Gutsy > | packages: > | http://packages.ubuntu.com/gutsy/devel/libhildon-1-dev > | Does anyone know where those patches are? > > https://code.launchpad.net/~ubuntu-mobile/hildon-1/ubuntu is the > Launchpad page related to our branch of hildon-1. It's branched off > SVN from back in May, so we should probably merge in changes after > that. (https://code.launchpad.net/hildon-1 is the set of all branches > related to hildon-1, including an ongoing import of svn trunk.) Thanks. Do you plan to submit patches upstream? -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Patches for hildon with regular GTK+?
On Tue, 2007-10-02 at 08:40 +0200, Koen Kooi wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Xan schreef: > > On 10/2/07, Murray Cumming <[EMAIL PROTECTED]> wrote: > >> I noticed that hildon-1 (and probably others) don't build from svn > >> without the maemo-patched GTK+: > >> > >> hildon-date-editor.c: In function 'hildon_date_editor_init': > >> hildon-date-editor.c:456: error: 'HILDON_GTK_INPUT_MODE_NUMERIC' > >> undeclared (first use in this function) > >> hildon-date-editor.c:456: error: (Each undeclared identifier is reported > >> only once > >> hildon-date-editor.c:456: error: for each function it appears in.) > >> > >> > >> I guess that Ubuntu must be patching hildon to create their Ubuntu Gutsy > >> packages: > >> http://packages.ubuntu.com/gutsy/devel/libhildon-1-dev > >> Does anyone know where those patches are? > > > > Crap, noticed I only replied Murray, not the list. So: you need to use > > --with-maemo-gtk=no if you want to use stock GTK+. And yes, as far as > > I can tell this is not mentioned anywhere in the README or similar, > > we'll fix it tomorrow. > > > > Thanks for the feedback, keep it coming! > > Does libhildonfm2 already build ontop of a stock gtk+? No, it doesn't seem to have a --with-maemo-gtk=no configure option: hildon-file-selection.c: In function 'hildon_file_selection_create_thumbnail_view': hildon-file-selection.c:2281: warning: implicit declaration of function 'gtk_widget_tap_and_hold_setup' hildon-file-selection.c:2282: error: 'GTK_TAP_AND_HOLD_NONE' undeclared (first use in this function) hildon-file-selection.c:2282: error: (Each undeclared identifier is reported only once hildon-file-selection.c:2282: error: for each function it appears in.) hildon-file-selection.c:2282: error: 'GTK_TAP_AND_HOLD_NO_INTERNALS' undeclared (first use in this function) hildon-file-selection.c: In function 'hildon_file_selection_create_list_view': hildon-file-selection.c:2402: error: 'GTK_TAP_AND_HOLD_NONE' undeclared (first use in this function) hildon-file-selection.c:2402: error: 'GTK_TAP_AND_HOLD_NO_INTERNALS' undeclared (first use in this function) hildon-file-selection.c: In function 'hildon_file_selection_create_dir_view': hildon-file-selection.c:2497: error: 'GTK_TAP_AND_HOLD_NONE' undeclared (first use in this function) hildon-file-selection.c:2497: error: 'GTK_TAP_AND_HOLD_NO_INTERNALS' undeclared (first use in this function) make[2]: *** [hildon-file-selection.lo] Error 1 -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Patches for hildon with regular GTK+?
On Tue, 2007-10-02 at 00:27 +0300, Xan wrote: > On 10/2/07, Murray Cumming <[EMAIL PROTECTED]> wrote: > > I noticed that hildon-1 (and probably others) don't build from svn > > without the maemo-patched GTK+: > > > > hildon-date-editor.c: In function 'hildon_date_editor_init': > > hildon-date-editor.c:456: error: 'HILDON_GTK_INPUT_MODE_NUMERIC' > > undeclared (first use in this function) > > hildon-date-editor.c:456: error: (Each undeclared identifier is reported > > only once > > hildon-date-editor.c:456: error: for each function it appears in.) > > > > > > I guess that Ubuntu must be patching hildon to create their Ubuntu Gutsy > > packages: > > http://packages.ubuntu.com/gutsy/devel/libhildon-1-dev > > Does anyone know where those patches are? > > Are you using --with-maemo-gtk=no ? No. Thanks for the tip. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Patches for hildon with regular GTK+?
I noticed that hildon-1 (and probably others) don't build from svn without the maemo-patched GTK+: hildon-date-editor.c: In function 'hildon_date_editor_init': hildon-date-editor.c:456: error: 'HILDON_GTK_INPUT_MODE_NUMERIC' undeclared (first use in this function) hildon-date-editor.c:456: error: (Each undeclared identifier is reported only once hildon-date-editor.c:456: error: for each function it appears in.) I guess that Ubuntu must be patching hildon to create their Ubuntu Gutsy packages: http://packages.ubuntu.com/gutsy/devel/libhildon-1-dev Does anyone know where those patches are? -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Software on MMC cards & OSSO question
On Sun, 2007-09-02 at 21:40 +0300, Mika Yrjölä wrote: > On 9/2/07, David Hazel <[EMAIL PROTECTED]> wrote: > > > My second question is to do with the OSSO library. I am using the call > > osso_rpc_run_with_defaults to open the browser. The Doxygen > > documentation says that this call is "blocking", which I take to mean > > that control should not return to my application until the browser is > > closed. However, I am finding that control returns immediately, and does > > not block my application. Is this a bug in OSSO, or have I misunderstood > > what the "blocking" refers to? Ideally, I really need my application not > > to continue past the invocation of the browser until the latter is > > closed by the user. Failing that, I need to be able to embed a browser > > in my application. > > The call will block until either a reply/error has arrived to the > call, or it timeouts. In this case, I'd assume that whatever method > you're calling, it probably returns a reply indicating success (or > failure) to your application via libosso as soon as that particular > operation (say, opening an URL) has succeeded, allowing the execution > of your app to continue. One way of doing what you want might be to > listen for the disappearance of the browser service with D-BUS (and > hope that it's gone because user closed it, instead of a crash :), but > this is just a quick idea. > > (as a disclaimer, it's been a while since I've used the osso_rpc_* > calls myself, so my knowledge might be obsolete and misleading) Yes, this is what happens. I doubt that there are many cases when they ever do anything but return success. I also very much doubt that there's any show_web_page_and_block_until_the_user_closes_it() D-Bus method for the browser. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Finding the mmc cards
On Wed, 2007-08-29 at 12:39 +0300, Eero Tamminen wrote: > Hi, > > Please file a documentation bug into Maemo Bugzilla. We need this > documented. Handling of removable medias, especially with file systems > as easily corrupted as FAT, needs special care from applications > (stop using files when pre-unmount message is delivered on them so > that unmounts succeed, do better error handling etc.) Ah, so that's the GnomeVFSVolumeMonitor::volume_pre_unmount signal? Thanks for that tip. I'm using the GnomeVFSVolumeMonitor to detect the presence of the card so far. For instance, see the rather unpleasant code in volume_path_is_mounted() here: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/modest/trunk/src/modest-tny-account-store.c?root=modest&view=markup I also respond to the GnomeVFSVolumeMonitor signals to detect actual mounting and unmounting in on_vfs_volume_mounted() and on_vfs_volume_unmounted() in the same file. It's probably not a good example, but I don't know of a better one. > ext [EMAIL PROTECTED] wrote: > > I agree that assuming mmc1 and mmc2 is potentially dangerous. In an answer > > to my > > original question on this subject, someone suggested that mmc0 and mmc1 > > were the > > correct names, whereas in my Scratchbox environment they are mmc1 and mmc2. > > Consequently, when I was implementing a scan for memory cards, I opted to > > look > > in the /media folder for files whose names begin "mmc", and to assume that > > any > > such file I find might be a memory card. This appears to work (in the > > test/development environment), but personally I hate making those kinds of > > assumptions. I would far rather have a definitive statement from someone to > > the > > effect that "if you do X, this will guarantee to find the memory cards and > > nothing else". For me, this is particularly important, as my application > > will be > > sold commercially and needs to work under all circumstances. > > > > > > David Hazel > > > > > > > > After our thread some weeks ago regarding reading the serial number > > from a > > MMC card, I've since implemented detection of the MMC card's presence by > > the > > existence of those same files. I know my solution works on my device > > perfectly. > > > > I figure it's probably a bad decision, because the architecture could > > change > > somewhat with the next hardware or software release. > > > > Can someone tell me, is there an approved / documented way of identifying > > the > > location of any MMC cards currently installed? I've noticed you can't > > simply > > look for /media/mmcX because that directory will exist even if there is no > > card > > inserted. > > > > Also, what determines MMC1 vs MMC2 as the card's path for > > internal/external? Is > > it possible these paths would change at some date? I know some Linux > > distro's > > with SATA drives had a problem with the drives changing their /dev/sdX path > > every reboot. I know that MY Nokia isn't doing anything similar, but I > > figure > > it's possible that my /media/mmc1 might be internal, but for someone else > > it > > could be the external slot - or maybe in the next hardware revision or > > something. > > > > I did find the alias names located in the /sys/ path that specify > > "internal" is > > for one and "external" or removable or something for the other. Also, are > > the > > names and paths the same for the 770's? Since I have an n800 I don't know. > > I'm > > hesitant to read too much data from /sys/ because it all looks _so_ > > Maemo-specific I wonder if I will tie my code too closely to one hardware > > revision. > > > > Just looking for the most _compatible_ way to identify if/when and where a > > media > > card is present. > > > > And as usual, from Python. > > > > Thanks, > > Tony > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Doxygen?
On Tue, 2007-08-14 at 14:26 +0100, Tony Green wrote: > On Tuesday 14 Aug 2007, Murray Cumming wrote: > > On Mon, 2007-08-13 at 21:24 +0100, Tony Green wrote: > > > Hello all. > > > > > > I'm trying to make a package of MySQL, but dpkg-buildpackage throws up an > > > error saying "Doxygen needed to make docs" and exits. > > > > > > Looking through the mailing list archive, I see that it's apparently > > > necessary to build this from source, but when I try to do that, "make" > > > fails saying: > > > > [snip] > > > > I have doxygen in Maemo Chinook/Sardine and I'm quite sure that I had it > > in Maemo Bora too. What version are you using? > > > > I don't think I even had to do "apt-get install doxygen". > > Thanks. That gave me a clue. Turns out it's actually in the scratchbox > environment but not in $PATH. A quick tweak to ~/.bashrc and everything > works. Where was doxygen actually? I've just noticed that the ARM doxygen package in Maemo Sardine doesn't actually seem to install a doxygen binary as it does in the X86 target. But maybe I'm not looking in all the right places. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Doxygen?
On Mon, 2007-08-13 at 21:24 +0100, Tony Green wrote: > Hello all. > > I'm trying to make a package of MySQL, but dpkg-buildpackage throws up an > error saying "Doxygen needed to make docs" and exits. > > Looking through the mailing list archive, I see that it's apparently > necessary > to build this from source, but when I try to do that, "make" fails saying: [snip] I have doxygen in Maemo Chinook/Sardine and I'm quite sure that I had it in Maemo Bora too. What version are you using? I don't think I even had to do "apt-get install doxygen". -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
On Mon, 2007-08-06 at 17:21 +0300, Marius Vollmer wrote: > "ext Guillem Jover" <[EMAIL PROTECTED]> writes: > > > What you seem to be asking for, is some kind of Release Notes, with > > the most important package versions, or really big features. > > What is missing from my packages (and probably others) is a properly > maintained NEWS file, and maybe a channel to make these NEWS files > easily accessible from the Release Notes of a OS release. > > I don't maintain the NEWS file since I don't make proper releases of > my packages: I just make snapshot after snaphot and then suddenly its > over and the OS is released, containing whatever was my last snapshot. > > I would be good to maintain the NEWS file also for snapshots, and I > should force myself to do it. Yes, this would be a big help. You'd have my thanks. You probably do something similar for your debian changelogs already. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: debhelper in Sardine
On Mon, 2007-07-30 at 10:47 +0300, Terje Bergström wrote: > On 7/29/07, Murray Cumming <[EMAIL PROTECTED]> wrote: > I'm trying to build a debian package for cairomm, using the > original > debian package. It needs debhelper, but it doesn't seem to be > available > in Sardine (It is available in Bora). I never fully understand > apt-get > errors but here they are in case they provide a clue: > > Hi, > > There seems to be something fishy with the dependencies, but you > really should not need to install debhelper. What's happening is that > debhelper (or actually an empty virtual package) is installed already. > You are asking apt-get to upgrade to a newer version from sardine and > the newer version has dependency problems. Yes, thanks, I just installed debhelper outside of scratchbox, removed debhelper from the build dependencies in debian/control, and also decreased the number in debian/compat. That last change is probably a bad idea, but it seems to work. This allows me to build the packages. Of course, I'd rather have a real debhelper in scratchbox so I have to make less changes to debian build files. > Just don't upgrade debhelper and you should be fine. In any case > Scratchbox will override debhelper with its own, so what's installed > with apt-get is irrelevant. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras packages for sardine
On Mon, 2007-07-02 at 12:28 +0300, Ferenc Szekely wrote: > On 6/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Thanks Ferenc :) > > > The sardine extras repo is ready. Please try to upload something > there. The lines to your dput.cf are as follows: > > [sardine-extras] > login = > fqdn = garage > method = scp > hash = md5 > allow_unsigned_uploads = 0 > incoming = /var/www/extras/incoming/sardine > > Let me know if you run into troubles. This seems to be working well. I updated this page to mention sardine: http://maemo.org/community/wiki/ExtrasRepository -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
debhelper in Sardine
I'm trying to build a debian package for cairomm, using the original debian package. It needs debhelper, but it doesn't seem to be available in Sardine (It is available in Bora). I never fully understand apt-get errors but here they are in case they provide a clue: [sbox-SDK_ALPHA_X86: ~/packages_cairomm/cairomm-1.4.4] > apt-get install debhelper Reading Package Lists... Done Building Dependency Tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: debhelper: Depends: dpkg-dev (>= 1.7.0) but it is not going to be installed E: Broken packages [sbox-SDK_ALPHA_X86: ~/packages_cairomm/cairomm-1.4.4] > apt-get install dpkg-dev Reading Package Lists... Done Building Dependency Tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: dpkg-dev: Depends: perl5 E: Broken packages [sbox-SDK_ALPHA_X86: ~/packages_cairomm/cairomm-1.4.4] > apt-get install perl5 Reading Package Lists... Done Building Dependency Tree... Done Note, selecting perl instead of perl5 perl is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 10 not upgraded. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
