Re: [maemo-developers] Suggestions for scirocco?
On Wed, 2006-11-29 at 20:21 +0100, Frantisek Dufka wrote: > Charles 'Buck' Krasic wrote: > > > Hi, > > > > I think it would be nice if in addition to a rootfs, there is a kernel > > that includes some of the extras that are useful for developers. The > > main example I am thinking of is NFS client support, so that the > > scratchbox CPU transparency feature is easier to setup (I think it was > > this way in Maemo 1.x, but I am not sure). > > > > - -- Buck > > Could be solved by packaging additional modules, Familiar did this, you > can have kernel-modules-nfs package etc. Would be nice to have most > modules packaged like this and have depmod/modprobe on device working. > I'd vote against various precompiled kernels with different combinations > if it can be solved by modules. Binary package for NFS client modules were there in the maemo 2.0, but that packages was more or less dirty hack. I think it would be nice if someone could write instructions how to create this kind of binary packages. I quickly checked and module-assistant might provide way to create these binary module packages, but I didn't have time to play around with it to test it really. Does anyone know if that could be the tool for this? Sincerely, -- Miko Nieminen <[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Taste the Herring!
Hi, A bit over 4 months ago the Maemo project released Sardine, a fresh and tasty bleeding edge distribution of the Hildon Application Framework for the Nokia 770 Internet Tablet. Sardine contains the latest versions of HAF components and some key dependencies. Have you wanted to get a taste of the new features and APIs but had no appetite for the bleeding edge? Herring, the stabilization distro for Sardine is just what you need and it's out. Like Sardine, Herring is meant for application developers, hackers and tinkerers, not for end-users. To taste it, follow the step by step instructions in http://maemo.org/maemowiki/SardineGettingStarted replacing 'sardine' with 'herring' in the 'sources.list' file. So what about it? Sardine will always contain the latest component versions. However, in order to make releases it is necessary to feature freeze the software and concentrate on polishing, bug-fixing and otherwise stabilizing the code. Doing this without stopping forward development requires branching off the code. This is done in the revision control system, component by component as it becomes necessary. When components start branching in the revision control system the Sardine branches as well: a separate stabilization distro is created. The current Hildon Application Framework stabilization distro is Herring. How stable is Herring ? Herring is not finished in the sense of being production ready but it has been feature frozen. It is being polished and bug-fixed and is already quite stable. Further updates will continue to come to the repository. Maintenance will also happen there. Start making your application ready for the next Maemo. The Hildon Application Framework that is being polished in Herring will be used in the next major 3.0 release of Maemo which will be called Bora. By porting your application to Herring and testing it in the Herring environment you can cover a lot the ground to port it to Bora. The updates in Sardine and Herring do not cover the complete Maemo scope but they do cover a lot of the API surface: the Hildon Application Framework, the Bluetooth stack and Python as well as X Window. So most applications can get quite close to being ready for Bora. Best regards, Carlos ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Scratchbox 1.x with scirocco/mistral
2006/11/29, Tomi Ollila <[EMAIL PROTECTED]>: "Kalle Vahlman" <[EMAIL PROTECTED]> writes: > 2006/11/29, Kalle Vahlman <[EMAIL PROTECTED]>: >> 2006/11/28, Tomi Ollila <[EMAIL PROTECTED]>: >> > my wishlist to scratchbox developers: >> > >> > 1) make this work (or is there something I did wrong ?) (*) >> > 2) update subversion to at least 1.3 so that svn log --limit=n works. >> >> FWIW, you can install self-compiled tools under /host_usr (which is >> visible in all targets) and add /host_usr/bin to your PATH. Yes...but I want to keep the changes in /scratchbox/ directory tree as bare minimum... The requirement (without any hacking) to add group "sbox" to /etc/groups is disturbing enough ;) Well, technically you could say it's the root dir you are modifying ;) But more seriously, /host_usr/ is specifically meant for the user, that's why it resides in the /scratchbox/users/ tree. And unless you are building your stuff in /tmp, you are already working inside /scratchbox/users as your home lives there, so it really isn't that radical. (I'd like to just tar my /scratchbox and move to other machine, extract it there and start using... but I understand there is no point spending expensive development time doing that) No, and even if you do, having stuff in /host_usr isn't going to make a difference, as it will be copied along the other user-specific stuff AFAICT. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Suggestions for scirocco?
Charles 'Buck' Krasic wrote: Sure modules would be fine too. Are those pre-compiled modules suitable for the kernel version that ships with maemo 2.1? Yes, kernels are patched so you may wish to avoid them but those modules are not and work with stock N770 kernel (except PPTP that needs crypto support in kernel). NFS should work. Haven't tried yet myself, have nothing nfs exported around, but nobody reported failure so far. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Proper documentation (was Re: HildonProgram input to gtk_widget_show()?)
On Wed, Nov 29, 2006 at 07:46:51PM +, Danny Milosavljevic wrote: > Is there a way to do something to the tone of like: > > (outside of scratchbox) > cd scratchbox/home/user/source/foobar/source/ > scratchbox-batch SDK_ARM make I want this too! > I.e. I'd like to avoid having to do manual mode changes with > "/scratchbox/login" / "exit" all the time just to issue "make". And > "/scratchbox/login" doesn't take the working directory you were in (before > calling it) into account. Reading /scratchbox/login: if you give it -d dir, then it chdirs there. Hey, and you can give it a command to run--this actually works! /scratchbox/login sbox-config -st SDK_ARM /scratchbox/login -d nflick dpkg-buildpackage -rfakeroot where "nflick" is relative to /scratchbox/users/$USER/home/$USER > Hmm, I should just check what "/scratchbox/login" does and hack something > up myself... after all, this might be some weird special thing that > interests only me, again ;) Apparently you don't need to. > [and "/scratchbox/" is a bad place to put scratchbox to, am I the only one > to have almost all the harddisk space on "/home/" and almost none on "/" ?] I used to do that, but then I've learned and now I just put everything into one big partition. And yes, /scratchbox/ is a bad place. It does not follow the Filesystem Hierarchy Standard. It should be /opt/scratchbox. And the Debian packages should copy/symlink the /opt/scratchbox/login script to /usr/bin/sbox or something. Marius Gedminas -- This message has been ROT-13 encrypted twice for higher security. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Proper documentation (was Re: [maemo-developers] HildonProgram input to gtk_widget_show()?)
> > Oh, it works great for toy programs. But the problems snowball for > > larger applications. > Umm ...ok, I think maybe you need to spend some time in Debian or Ubuntu > because the package management is one of the absolute joys of Debian > based distros. Pardon me, I meant the N770 devel platform in general and not debian's packaging. I think I've built about a dozen different package formats over the years and debian is one of the best. Debian did once delete my glibc package in the early days of dselect but that was a very long time ago. .mike ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Proper documentation (was Re: [maemo-developers] HildonProgram input to gtk_widget_show()?)
* For SDL programs you need to export one environment variable BTW, what is this variable? Apparently, I haven't been exporting it. ;-) -- Tcsh: Now with higher FPS! http://www.gnu.org/philosophy/shouldbefree.html ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Suggestions for scirocco?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frantisek Dufka wrote: > Charles 'Buck' Krasic wrote: > >> Hi, >> >> I think it would be nice if in addition to a rootfs, there is a >> kernel that includes some of the extras that are useful for >> developers. The main example I am thinking of is NFS client >> support, so that the scratchbox CPU transparency feature is >> easier to setup (I think it was this way in Maemo 1.x, but I am >> not sure). >> >> - -- Buck > > > Could be solved by packaging additional modules, Familiar did this, > you can have kernel-modules-nfs package etc. Would be nice to have > most modules packaged like this and have depmod/modprobe on device > working. I'd vote against various precompiled kernels with > different combinations if it can be solved by modules. > > Or is there significant memory overhead for modules? > > Frantisek > > BTW, for precompiled NFS modules check this > http://www.internettablettalk.com/forums/showpost.php?p=25716&postcount=12 > > Sure modules would be fine too. Are those pre-compiled modules suitable for the kernel version that ships with maemo 2.1? In any case, my main concern is that the procedure for using scratchbox CPU transparency is currently severely hampered, and I have little hope that an inexperienced developer will realize that the documented procedure for enabling CPU transparency isn't working is because by default the 770 kernel does not have NFS client support. This really needs to be fixed. - -- Buck -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFbeVHPrrWIMa4SMsRArq3AKC+iKd5jtMVxthzeGR3j9CWxS8vzQCgkX5f iaJuqzshtkpTyTCzuttNL+s= =UxIC -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Proper documentation (was Re: [maemo-developers] HildonProgram input to gtk_widget_show()?)
On Wed, 2006-11-29 at 14:05 -0500, Mike Frantzen wrote: > Sometimes. Off the top of my head there were lots of little things > like gtk_arrow's or GTK_STOCK_CONNECT Could you elaborate? GTK_STOCK_CONNECT should be present in the GTK+ 2.6 API, and therefore present in Maemo's GTK+. If not, is there a Maemo bug for this? -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: Proper documentation (was Re: HildonProgram input to gtk_widget_show()?)
Hi, On Wed, 29 Nov 2006 12:24:46 -0500, Mike Frantzen wrote: > I think it's even worse than that. There are enough differences to the > usual linux/gtk development environment that the N770 is very > frustrating to develop for. I find it actually quite nice. There are some memory-saving quirks (as expected for an embedded device), but overall it is very nice to program for. >[...] > The N770 > used enough bleeding edge technology that it has some very sharp edges; > and as a developer I really don't like the bleeding part. > > The big ones that immedietly come to mind are: > 1) gstreamer which I understand if you want to offload multimedia to > the DSP. It's just too bad that it's not stable. They are (were?) hiring, go and fix it so it _is_ stable ;) > 2) dbus/libosso. blech, complex solution to a simple problem. very > "Windows" like Well, even being an old-school communicating-processes-with-pipes UNIX model thinker, I have to admit that on an embedded platform there just isn't enough RAM to do it the right way (likewise to develop a GUI app in C is madness, usually - that I take part in regularily ;) -, but there just isn't enough RAM to do otherwise). Now if you specified what exactly is bad about dbus/osso... > 3) hildon-specific gtk widgets instead of just modifying the stock GTK > widgets to work well on the N770 platform > > Porting existing applications to the N770 involves rewriting some things > and kludging the hell out of others. Both which make it much less > likely that the diffs will be accepted back into the main application's > source tree. Which means the porter has to maintain his diffs out of > the tree which is a big PITA. I see where you are coming from. I usually assume GTK as a platform as an unchanging entity (even _binary_ compatible since time immemorial). That said, with IT2006, the only special-case I have left is hildon_window_new, hildon_program_* stuff and the mime callback, all in all maybe 20-30 lines. It's not like the whole development paradigm changed. > Writing new applications for the N770 locks your application into the > N770 platform or you implement a lot of things twice, once for the N770 > and once for everything else. My experience negates that. You do design the GUI look twice, by neccessity. The display is smaller and higher resolution than any PC display and stylus input neccessites some changes. The other stuff is fine just like it was. > You end up doing things twice since it's > much more pleasant to debug outside of a N770 or a scratchbox. Hmm, I dislike the two-environment stuff as much as the next guy, but I don't see a way around it. Is there a way to do something to the tone of like: (outside of scratchbox) cd scratchbox/home/user/source/foobar/source/ scratchbox-batch SDK_ARM make I.e. I'd like to avoid having to do manual mode changes with "/scratchbox/login" / "exit" all the time just to issue "make". And "/scratchbox/login" doesn't take the working directory you were in (before calling it) into account. Hmm, I should just check what "/scratchbox/login" does and hack something up myself... after all, this might be some weird special thing that interests only me, again ;) [and "/scratchbox/" is a bad place to put scratchbox to, am I the only one to have almost all the harddisk space on "/home/" and almost none on "/" ?] cheers, Danny ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Proper documentation (was Re: [maemo-developers] HildonProgram input to gtk_widget_show()?)
Mike Frantzen wrote: And like on other Linux Desktops, you need to have a .desktop file so that your program appears in the menus. And they're much more mature that what we have on the N770. There was the recent thread about trailing whitespace being invalid in a .desktop file. If you edit the .desktop file on the N770 and use word completion then it will leave trailing whitespace... A bit offtopic but trailing spaces in .desktop are a problem in the mature Linux Desktop GNOME. Add a space after the Type= value and your application disappears from the GNOME menu, just as it does on the Hildon Navigator menu :). Johan. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Proper documentation (was Re: [maemo-developers] HildonProgram input to gtk_widget_show()?)
On Wed, 2006-29-11 at 14:05 -0500, Mike Frantzen wrote: > > And like on Debian, things need to be in a package so that > > they can be managed. This is IMHO actually the hardest thing. > > Doesn't sound that much, does it? :-) > > Oh, it works great for toy programs. But the problems snowball for > larger applications. Umm ...ok, I think maybe you need to spend some time in Debian or Ubuntu because the package management is one of the absolute joys of Debian based distros. If you have spent time in it, then possibly there is something you have not quite understood. Package management is really one of the things the entire planet loves about Debian. Could you explain further what the issue might be so we could offer help. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Suggestions for scirocco?
Charles 'Buck' Krasic wrote: Hi, I think it would be nice if in addition to a rootfs, there is a kernel that includes some of the extras that are useful for developers. The main example I am thinking of is NFS client support, so that the scratchbox CPU transparency feature is easier to setup (I think it was this way in Maemo 1.x, but I am not sure). - -- Buck Could be solved by packaging additional modules, Familiar did this, you can have kernel-modules-nfs package etc. Would be nice to have most modules packaged like this and have depmod/modprobe on device working. I'd vote against various precompiled kernels with different combinations if it can be solved by modules. Or is there significant memory overhead for modules? Frantisek BTW, for precompiled NFS modules check this http://www.internettablettalk.com/forums/showpost.php?p=25716&postcount=12 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Proper documentation (was Re: [maemo-developers] HildonProgram input to gtk_widget_show()?)
> > The N770 forces developer do it Nokia's way or not at all. > What do you mean? > * Gtk programs work out of the box Sometimes. Off the top of my head there were lots of little things like gtk_arrow's or GTK_STOCK_CONNECT not being there and gtk_file_choose_button misbehaving (or was it crashing?). > * For programs which do not use Gtk nor SDL, you need to set > one X property > (these are so that Task Navigator can associate them > with the correct .desktop file) Unless you hit one of the little "quirks" about the .desktop files. Or you have a script wrapping your application that spawns a small gui process before the main application (hint the first process will silently get killed by dbus). Or you start suid root and privsep. > And like on other Linux Desktops, you need to have a .desktop > file so that your program appears in the menus. And they're much more mature that what we have on the N770. There was the recent thread about trailing whitespace being invalid in a .desktop file. If you edit the .desktop file on the N770 and use word completion then it will leave trailing whitespace... > And like on Debian, things need to be in a package so that > they can be managed. This is IMHO actually the hardest thing. > Doesn't sound that much, does it? :-) Oh, it works great for toy programs. But the problems snowball for larger applications. > > The big ones that immedietly come to mind are: > > 1) gstreamer which I understand if you want to offload multimedia > > to the DSP. It's just too bad that it's not stable. > Want to != forced to? Forced to if you want audio input. No ESD, OSS or ALSA for recording. Things can get very unstable with multiple processes and gstreamer on the N770. > > 2) dbus/libosso. blech, complex solution to a simple problem. > very "Windows" like > If one wants to integrate well to any other Desktop environment, one needs > to implement some of their stuff too. I don't see Maemo being more > difficult in this respect than any other Desktop environment. Yeah, this one's just me being grumpy. Libosso hides the dbus messiness very well. > > 3) hildon-specific gtk widgets instead of just modifying the > > stock GTK widgets to work well on the N770 platform > Are you sure the "just modifying the stock GTK widgets to work > well on the N770 platform" doesn't mean "rewriting the whole > widget"? :-) In that case it's probably easier to make another > widget, that way you could at least get an API that's designed > for the job. GTK is fairly object oriented for C. It is designed to be able to derive new widgets from other widgets. Most of the Nokia-ized widgets I've used have a close sibling in the traditional GTk library with a different API. I would have been more than happy to see the GTK widget modified for behave better on Nokia and then a very hildon specific widget derived with a more condusive API. It all goes to portability. From a development standpoint the N770 could have been just another linux/GTK target with a few ifdefs. Making a complex application "look good" on the N770 doesn't require forking the UI, just forking a lot of the functions. > If the UI's would be done with something like Glade (like AFAIK most > Gnome programs are), having two UI XML descriptions shouldn't be that > bad. This of course depends on whether the constraints of smaller > (physical) screen size force larger UI design changes, but that's > a physical constraint, not a software constraint. (it also requires > the UI tool to support Maemo) The Nokia guys did this very well. Adapting to the smaller screen has been near painless. .mike ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Scratchbox 1.x with scirocco/mistral
"Kalle Vahlman" <[EMAIL PROTECTED]> writes: > 2006/11/29, Kalle Vahlman <[EMAIL PROTECTED]>: >> 2006/11/28, Tomi Ollila <[EMAIL PROTECTED]>: >> > my wishlist to scratchbox developers: >> > >> > 1) make this work (or is there something I did wrong ?) (*) >> > 2) update subversion to at least 1.3 so that svn log --limit=n works. >> >> FWIW, you can install self-compiled tools under /host_usr (which is >> visible in all targets) and add /host_usr/bin to your PATH. Yes...but I want to keep the changes in /scratchbox/ directory tree as bare minimum... The requirement (without any hacking) to add group "sbox" to /etc/groups is disturbing enough ;) (I'd like to just tar my /scratchbox and move to other machine, extract it there and start using... but I understand there is no point spending expensive development time doing that) > Actually it is in your PATH already, but the scratchbox version is > found first (so reorganizing the search order is neccessary). You > could also use the SBOX_REDIRECT_* variables I guess (see > /scratchbox/doc/variables.txt for more info). ay!. editing bash config files (again). I've so far managed well with $ HOME=/home/$USER DISPLAY=:2 PAGER=less LANGUAGE=en_GB /scratchbox/login (with scratchbox 1.x setting HOME is not necessary :D) I just want to do as little changes to the system as possible (and installation notes short) so that there is easy and robust way to repeat everything again when need arises (for me or someone else). I once had "broken" scratchbox environment which compiled software fine but the binaries just did not work. I'll keep running subversion out of scratchbox for command options it does not handle -- but keep suggesting its upgrade whenever there is suitable moment to do so. > Kalle Vahlman, [EMAIL PROTECTED] Tomi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: star atlas for maemo
Hi, On Wed, 29 Nov 2006 11:14:14 +0100, alessandro pasotti wrote: > Hello, > > an application that I really miss from the 770 is a star atlas, does anybody > knows of an existing application that could be easily ported to maemo? > > Most of the "big" ones like celestia or kstars are too heavy and use 3d > open-gl hence are not suitable, I've tested "stars" but I've got errors like > > /home/ale/src/stars-0.12+1/configure: line 1: gtk-config: command not found > > checking for gdk-pixbuf-config... NONE > configure: error: Could not find gdk-pixbuf-config in PATH > > Any hint? In gtk2, "gtk-config ..." is now "pkg-config ... gtk+-2.0". "gdk-pixbuf" is part of gtk2, so no need to check it manually any more. There should be a configure.ac or configure.in where you can change that using the unbelievably arcane M4 language (good luck...). If you want an almost clean configure.ac (as clean as I got it without repeatedly banging my head on the keyboard - yes, automake is that bad) to start from, take mine: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/configure.ac?root=ssh-key-manager&view=log (you can also use the entire project as a clean starting point for a maemo project since it's just a skeleton so far - if you are quick enough ;)) Ross is right, porting a gtk1 application is so easy, it boggles my mind why gtk1 applications are still around unported (the API is pretty much compatible, too - with a few exceptions). Have fun :) cheers, Danny ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Proper documentation (was Re: [maemo-developers] HildonProgram input to gtk_widget_show()?)
Hi, > The N770 forces developer do it Nokia's way or not at all. What do you mean? * Gtk programs work out of the box * For SDL programs you need to export one environment variable * For programs which do not use Gtk nor SDL, you need to set one X property (these are so that Task Navigator can associate them with the correct .desktop file) And like on other Linux Desktops, you need to have a .desktop file so that your program appears in the menus. And like on Debian, things need to be in a package so that they can be managed. This is IMHO actually the hardest thing. Doesn't sound that much, does it? :-) Btw. Have you checked out my "clueful developer test": http://maemo.org/pipermail/maemo-developers/2006-August/005316.html ? > The big ones that immedietly come to mind are: > 1) gstreamer which I understand if you want to offload multimedia > to the DSP. It's just too bad that it's not stable. Want to != forced to? > 2) dbus/libosso. blech, complex solution to a simple problem. very "Windows" like If one wants to integrate well to any other Desktop environment, one needs to implement some of their stuff too. I don't see Maemo being more difficult in this respect than any other Desktop environment. > 3) hildon-specific gtk widgets instead of just modifying the > stock GTK widgets to work well on the N770 platform Are you sure the "just modifying the stock GTK widgets to work well on the N770 platform" doesn't mean "rewriting the whole widget"? :-) In that case it's probably easier to make another widget, that way you could at least get an API that's designed for the job. Btw. With which Gtk widgets you have problems on N770? > Porting existing applications to the N770 involves rewriting some > things and kludging the hell out of others. For integrating them well; yes, maybe (depends on one's definition of integrating well. Integrating SDL games means mainly re-mapping the keys if the SDL app otherwise is a suitable candinate performance, screen-size and interaction-wise.) For porting; no, it doesn't. However, I do agree that the documentation could be improved. > Writing new applications for the N770 locks your application into the > N770 platform or you implement a lot of things twice, once for the N770 > and once for everything else. Maybe one could think of it as a chance to reflect on the application's design and refactor it's parts to be more independent of each other? :-) If the UI's would be done with something like Glade (like AFAIK most Gnome programs are), having two UI XML descriptions shouldn't be that bad. This of course depends on whether the constraints of smaller (physical) screen size force larger UI design changes, but that's a physical constraint, not a software constraint. (it also requires the UI tool to support Maemo) > it's much more pleasant to debug outside of a N770 or a scratchbox. I don't have problems in debugging in (x86) Scratchbox. What kind of issues you have? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: Troubleshooting .desktop and .service file
Hi, On Mon, 27 Nov 2006 18:29:12 +0200, Eero Tamminen wrote: > Hi, > > ext Danny Milosavljevic wrote: >>> (One of the benefits of D-BUS is that other programs don't >>> need to know whether your app is running, they can just >>> send messages to it with D-BUS auto-invocation flag and >>> D-BUS takes care that only one instance of your application >>> is running.) >> >> If you call that an "advantage"... It usually breaks one of the oldest and >> best UNIX conventions: that the process blocks the caller until the task >> is done. > > I think you are a bit confused. Nobody's removed good ol' exec > from the libc, so nothing's "broken". :-) Hmm, yeah, but I meant it in a different way. I mean waitpid() won't do anything sensitive/useful anymore on gui programs. (And I gave an example to that.) Maybe I'm just a too old-fashioned UNIX-head, seeing that the nicest response was yours, and the worst response from someone else was "never mail me anymore" (_that_ was weird... I mean, really weird. Must be some kind of taboo he wasn't supposed to talk about ;)). Then again, it doesn't matter for viewer programs like firefox and book readers and most of the stuff used when on the Nokia 770, so don't get me wrong. I just wanted to illuminate the other side for completeness sake (in the bigger picture of all UNIX computers). > Whether the D-BUS call is asynchronous or synchronous is controlled with > a flag used when sending the message. (in CORBA everything is by > default synchronous because it's used mainly for "remote procedure > calls" whereas D-BUS is used more for delivering events and events are > usually async) Good to know :) To place it in technical terms: I think that dbus activation doesn't allow passing a channel to the existing process, in order that the existing process could use it to signal that it is "done" with the task later. Seems that having a process-oriented view is really unusual this year... strange o_O > > You know on desktop when you want to have another browser window, you > run Firefox which checks whether there's already a Firefox running and > then sends a message to that so that it opens another window. Yes, even that already breaks my model (the new process "should" block until I closed the new window again, basically react as if it were not using the singleton-process optimization) - and its arguably a very popular program, so I guess times are just changing... > Sure, it > already saves some time, but more is saved if you don't need to start > Firefox (or any other app) in the first place, just send the message to > the already running process and D-BUS is the one checking whether > something already runs... Yes, I know that as an optimization on an embedded platform this makes sense. I'm just a person that is way too used to synchronous batch scripts, so just ignore me... ;) cheers, Danny ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Suggestions for scirocco?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tran Van Hoang wrote: > Hi all, > > In an effort trying to make scirocco officially support scratchbox > apophis 1.x, we're also trying to make scirocco better if possible. > So if you would like to have any thing else supported, please say > it soon enough so we can at least try our best. > > REPOSITORY A sensible suggestion * Missing xserver-kdrive build-dep > packages like libxproto-composite libxproto-damage etc.. should be > available. > > Suggestions like "source for libosso-certman-dev should be > available" won't be supported. It's nokia-properietary code. But of > course any suggestion is welcome > > ROOTSTRAP/Rootfs * Are there any other tools/packages that you'd > like in rootstraps or rootfs? Hi, I think it would be nice if in addition to a rootfs, there is a kernel that includes some of the extras that are useful for developers. The main example I am thinking of is NFS client support, so that the scratchbox CPU transparency feature is easier to setup (I think it was this way in Maemo 1.x, but I am not sure). - -- Buck > > Thank you, BR, TranVan Hoang > > ___ maemo-developers > mailing list maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFbcgxPrrWIMa4SMsRAi7hAKCItAcmdZ78qHl+Vwbfksb/YDGUuQCeMWL9 2ex7vh1L6C1MZ7DexC7EhHQ= =3dTe -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Proper documentation (was Re: [maemo-developers] HildonProgram input to gtk_widget_show()?)
> Without proper developer documentation, I don't think it is realistic to > expect many developers to migrate to the maemo platform. Sure, maemo is > fine for experienced developers, who have likely already developed for > Linux/Unix, have some Gtk experience, etc. But, there are Nokia 770 users > out there who have no or little Linux experience and may also be > developers. I wonder how many developers have simply given up on maemo > because of documentation. I think it's even worse than that. There are enough differences to the usual linux/gtk development environment that the N770 is very frustrating to develop for. The usual embedded linux target gives the developer the freedom to choose the methods to his madness. The N770 forces developer do it Nokia's way or not at all. Most embedded linux targets are just as mature as the underlying linux system. The N770 used enough bleeding edge technology that it has some very sharp edges; and as a developer I really don't like the bleeding part. The big ones that immedietly come to mind are: 1) gstreamer which I understand if you want to offload multimedia to the DSP. It's just too bad that it's not stable. 2) dbus/libosso. blech, complex solution to a simple problem. very "Windows" like 3) hildon-specific gtk widgets instead of just modifying the stock GTK widgets to work well on the N770 platform Porting existing applications to the N770 involves rewriting some things and kludging the hell out of others. Both which make it much less likely that the diffs will be accepted back into the main application's source tree. Which means the porter has to maintain his diffs out of the tree which is a big PITA. Writing new applications for the N770 locks your application into the N770 platform or you implement a lot of things twice, once for the N770 and once for everything else. You end up doing things twice since it's much more pleasant to debug outside of a N770 or a scratchbox. I'm not happy with the N770 software. The hardware is great and the platform does have some serious potential if it ever matures under the hood. .mike ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Proper documentation (was Re: [maemo-developers] HildonProgram input to gtk_widget_show()?)
As can be seen at http://www.gossamer-threads.com/lists/maemo/developers/10038?search_string=HildonProgram;#10038 , this isn't the first time this question has been posted to the list. Unfortunately, it appears that Steve's question went unanswered when he posted to the list in July, and soon after, he stopped posting to the list altogether. As is often done in the developer documentation on maemo.org, the various how-tos refer to the source for maemopad for more information. As a technique to shorten the amount of text that needs to be included in an article, it works, but it tends to leave a lot of questions unanswered. There can be many things found in the source code that are not explained in the relevant articles, and it can be unclear where to go to find explanations. However, in this case, the problem is compounded further, because the source code example that is supposed to demonstrate how to code a proper maemo application repeats the error. One wonders if maemopad was even built with the 2.0 SDK, let alone tested. Also, passing in a HildonWindow * to gtk_widget_show() before calling gtk_main() raises additional questions, because as stated in the documentation, there may be multiple HildonWindows, and each window could be added to the HildonProgram to provide a different view. In the past, when HildonApp was a GtkWidget, there was a single top-level widget that was suitable for the call to gtk_widget_show(). This is no longer the case, and it is unclear how to make things work if the developer were to use multiple HildonWindows. Last night, I found myself muddling through the "Making a Package for the Application Manager" how-to. It's not just that this how-to appears to, unfortunately, be written for a semi-advanced audience that already has experience creating packages. It's simply difficult to follow this how-to--there are lots of grammar issues, little contextual information, and other issues. For instance, it refers to various fields that may be modified in the debian control file, but the control file is barely mentioned. It has a section about providing an icon in base64 format, but there is no information for how to go about converting to base64. It suggests to go to the Debian Policy Manual, section 5.7, for more information, but there is no link to the manual anywhere in this how-to, and in addition, section 5.7 of the manual (once found by searching on the Web) doesn't provide much useful information. Without proper developer documentation, I don't think it is realistic to expect many developers to migrate to the maemo platform. Sure, maemo is fine for experienced developers, who have likely already developed for Linux/Unix, have some Gtk experience, etc. But, there are Nokia 770 users out there who have no or little Linux experience and may also be developers. I wonder how many developers have simply given up on maemo because of documentation. I hope something can be done to address the deficiencies in the developer documentation. Unlike on the wiki, this documentation cannot be easily enhanced by the community, and submitting bugs against documentation in Bugzilla is tedious. Regards, Aaron Levinson On Wed, 29 Nov 2006, Johan Bilien wrote: > Aaron Levinson wrote: > > >In all the examples at maemo.org, I see the following: > > > >gtk_widget_show(GTK_WIDGET(program)); > > > >program is of type HildonProgram *. > > > >It is unclear to me how this could ever work. HildonProgram is not a > >GtkWidget. > > > >So, is this actually correct? Do the documents on-line need to be changed > >to instead pass in a HildonWindow? > > > > > > Yes indeed, > > I filled #889 against the documentation. It seems the documentation was > ported a bit too blindly from HildonApp to HildonProgram ... > > Thanks, > Johan. > ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Suggestions for scirocco?
2006/11/29, Tran Van Hoang <[EMAIL PROTECTED]>: Hi all, In an effort trying to make scirocco officially support scratchbox apophis 1.x, we're also trying to make scirocco better if possible. So if you would like to have any thing else supported, please say it soon enough so we can at least try our best. REPOSITORY A sensible suggestion * Missing xserver-kdrive build-dep packages like libxproto-composite libxproto-damage etc.. should be available. Suggestions like "source for libosso-certman-dev should be available" won't be supported. It's nokia-properietary code. But of course any suggestion is welcome ROOTSTRAP/Rootfs * Are there any other tools/packages that you'd like in rootstraps or rootfs? Thank you, BR, TranVan Hoang ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers Yes, all the debian tools needed to properly sign and commit packages to the extras repository! Luca Donaggio ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Suggestions for scirocco?
Hi all, In an effort trying to make scirocco officially support scratchbox apophis 1.x, we're also trying to make scirocco better if possible. So if you would like to have any thing else supported, please say it soon enough so we can at least try our best. REPOSITORY A sensible suggestion * Missing xserver-kdrive build-dep packages like libxproto-composite libxproto-damage etc.. should be available. Suggestions like "source for libosso-certman-dev should be available" won't be supported. It's nokia-properietary code. But of course any suggestion is welcome ROOTSTRAP/Rootfs * Are there any other tools/packages that you'd like in rootstraps or rootfs? Thank you, BR, TranVan Hoang ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Many garage apps not in garage repository
On Wed, Nov 29, 2006 at 11:43:17AM +0100, Rainer Dorsch wrote: > I recently updated my 770 and got a now very well working maemo-mapper. Very > impressive work, and I almost missed the important update. Fortunately, I had > the right entry in my sources.list file. > > I noticed that many (most?) of the garage packages are not listed by > apt-cache > (oggplay, maemopadplus, scite,). Couldn't we have a repository which > contains (almost?) all packages on garage? Yes, that's repository.maemo.org, component "extras". You have to go and bug individual package maintainers to read http://maemo.org/maemowiki/ExtrasRepository and upload their packages there. > Can I subscribe to a forum, such that I get mailed all the new posts, like a > mailing list does? No idea. I do not use forums. Marius Gedminas -- Any time somebody tells you that you shouldn't do something because it's "unprofessional," you know that they've run out of real arguments. -- Joel Spolski signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: [maemo-users] How does the device-self-reset work?
Hi, > You can disable the lifeguard. You cannot disable the OOM killer, > and I do not think you can disable the software watchdog. OOM killer happens because Linux has (also on desktop) a memory usage optimization called "overcommit". AFAIK this can be disabled from /proc/, then (even unused) allocations will fail when programs try to do them, not afterwards when memory is really used and there's not enough of it. If overcommit is disabled, probably more programs will abort() (Glib used by Gtk for allocs will abort() the program if allocations fail) or don't start at all. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
On Wed, Nov 29, 2006 at 12:25:54PM +0200, Marius Vollmer wrote: > Please allow me to ramble a bit: +1 Marius Gedminas -- Never trust a smiling Gates. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
multiblock writes Re: [maemo-developers] Unresolved issues (Week 47)
Tommi Komulainen wrote: * http://maemo.org/pipermail/maemo-developers/2006-October/005985.html MMC - multiblock writes 4th mention Does OMAP 1710 support multiblock writes safely? I guess you can remove it from the list. I take this post http://linux.omap.com/pipermail/linux-omap-open-source/2006-November/008285.html as a yes. Whether omap driver and mmc block layer source in our 2.6.16.27 is ideal or not is different story. As for omap.c it seems to be similar in current omap git tree and seems to return number of written bytes both for DMA and PIO modes [1]. As for mmc block layer there is better error handling in current git tree and number of bytes written are taken into account now [2] so the operation partly succeeds which has better chance to do whole transfer correctly by repeating smaller chunks in case of error. I will try to add this to 2.6.16.27. Maybe this will make difference with http://maemo.org/pipermail/maemo-developers/2006-November/006410.html or maybe not. Frantisek [1] http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=blob;h=2a73361a3896dc0a357ccf76d09b5a462797a5f9;hb=e4bbd3ec9084824eba003cdf91378138f239d03f;f=drivers/mmc/omap.c#l721 [2] http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=blob;h=f9027c8db79226250a0e0fced80633be29d16cba;hb=e4bbd3ec9084824eba003cdf91378138f239d03f;f=drivers/mmc/mmc_block.c#l374 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: high speed (52/48Mhz) MMC mode added
On Wednesday 29 November 2006 12:53, Armin Warda wrote: > Sorry, > > mea culpa, mea culpa, it was all my own fault! > > I somehow mixed up > zImage-su-18-200625-2gb-mmcplus52Mhz > and > zImage-su-18-200639-2gb-mmcplus52Mhz > > When I reported the problem, I was running *200625* on > 2.2006.39-14, which indeed fails to load cx3110x and umac... ... and yes, I always run my device with disabled lifeguard or watchdog, and enabled r&d mode, which probably saved me from the reboot loop. > Everything is fine with *200639* on 2.2006.39-14. > > Thanks, Frantisek! > > regards, Armin. > > On 11/28/06, Larry Battraw <[EMAIL PROTECTED]> wrote: > > Actually, I noticed the same thing although I'll have to go back and > > make sure it wasn't all of the kernels that had problems with WEP. I > > was never able to get it working although WPA is fine. > > > > Larry > > > > On 11/28/06, Frantisek Dufka <[EMAIL PROTECTED]> wrote: > > > Armin M. Warda wrote: > > > > I repeated the test three times, the result was always reproduced. > > > > > > > > regards, Armin. > > > > > > Huh, that's weird. wi-fi driver and 802.11 protocol is even not in > > > kernel but in extra module. The only changes in that kernel are: > > > 1 extended backlight control (patch on my site) > > > 2 high speed mmc patch (on my site) > > > 3 kernel has enabled crypto API (disabled in nokia build) for PPTP > > > > module > > > > > Any dmesg errors while connecting? Are you running correct IT2006 > > > version for the kernel (i.e. not running older 1.2006 with disabled > > > lifeguard or watchdog by chance)? Are you booting otherwise same > > > systems (preferably from flash)? > > > > > > Works for me fine with WPA with Asus WL-500G deluxe. > > > Just also flashed that kernel and tried also ad-hoc WEP conection > > > with my notebook and it works too. > > > > > > I simply don't have any idea why it should affect wi-fi network at > > > all except when possibly using with older IT2006 from July (so the > > > cx3110x and umac modules cannot load) which normally causes reboot > > > loop. > > > > > > Frantisek -- --- May the Source be with you! Linux. --- --- secure eMail: http://www.gnupg.de/ --- --- My Homepage http://armin-warda.de/ --- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: high speed (52/48Mhz) MMC mode added
Sorry, mea culpa, mea culpa, it was all my own fault! I somehow mixed up zImage-su-18-200625-2gb-mmcplus52Mhz and zImage-su-18-200639-2gb-mmcplus52Mhz When I reported the problem, I was running *200625* on 2.2006.39-14, which indeed fails to load cx3110x and umac... Everything is fine with *200639* on 2.2006.39-14. Thanks, Frantisek! regards, Armin. On 11/28/06, Larry Battraw <[EMAIL PROTECTED]> wrote: Actually, I noticed the same thing although I'll have to go back and make sure it wasn't all of the kernels that had problems with WEP. I was never able to get it working although WPA is fine. Larry On 11/28/06, Frantisek Dufka <[EMAIL PROTECTED]> wrote: > Armin M. Warda wrote: > > I repeated the test three times, the result was always reproduced. > > > > regards, Armin. > > > > Huh, that's weird. wi-fi driver and 802.11 protocol is even not in > kernel but in extra module. The only changes in that kernel are: > 1 extended backlight control (patch on my site) > 2 high speed mmc patch (on my site) > 3 kernel has enabled crypto API (disabled in nokia build) for PPTP module > > Any dmesg errors while connecting? Are you running correct IT2006 > version for the kernel (i.e. not running older 1.2006 with disabled > lifeguard or watchdog by chance)? Are you booting otherwise same systems > (preferably from flash)? > > Works for me fine with WPA with Asus WL-500G deluxe. > Just also flashed that kernel and tried also ad-hoc WEP conection with > my notebook and it works too. > > I simply don't have any idea why it should affect wi-fi network at all > except when possibly using with older IT2006 from July (so the cx3110x > and umac modules cannot load) which normally causes reboot loop. > > Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Many garage apps not in garage repository
Hello, I recently updated my 770 and got a now very well working maemo-mapper. Very impressive work, and I almost missed the important update. Fortunately, I had the right entry in my sources.list file. I noticed that many (most?) of the garage packages are not listed by apt-cache (oggplay, maemopadplus, scite,). Couldn't we have a repository which contains (almost?) all packages on garage? Can I subscribe to a forum, such that I get mailed all the new posts, like a mailing list does? Thanks, Rainer -- Rainer Dorsch Alzentalstr. 28 D-71083 Herrenberg 07032-919495 jabber: [EMAIL PROTECTED] GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: star atlas for maemo
On Wed, 2006-11-29 at 11:14 +0100, alessandro pasotti wrote: > /home/ale/src/stars-0.12+1/configure: line 1: gtk-config: command not > found > > checking for gdk-pixbuf-config... NONE > configure: error: Could not find gdk-pixbuf-config in PATH That means the application uses GTK+ 1.2, which is *very* old and unmaintained. Porting it to use GTK+ 2 is generally quite simple. The alternative is to build GLib 1 and GTK+ 1 for the 770, but that would be a bad idea. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] extras repository
"ext Carlos Guerreiro" <[EMAIL PROTECTED]> writes: > Yeah. That's the way to go: proper archive management with something > like DAK (we'll look into that at least for sardine and herring once > there's some time) and a build system to go with it. I think we are more in need of a clue than in need of proper tools. :-) Please allow me to ramble a bit: Just deploying DAK doesn't automatically give you a sensible repository layout or distribution landscape. Actually, without knowing too much about DAK, it might be that having to wrestle with DAK itself will distract us and make it harder to see clearly where we actually want to go. (Hopefully I am wrong, the real Dakkers please correct me.) So, what would a sensible distribution landscape be? I don't have the experience to be authoritative here, but I think Ferenc is well on the right way. First, we should be talking about distributions and theirs components, not so much about repositories. [ Distributions are things like mistral, scirocco, sardine, herring; components are things like main, free, non-free, extras; repositories are things like http://repository.maemo.org/, http://catalogue.tableteer.nokia.com/ ] Then, the thing to realise is that we have two ways of looking at what is going on, and they tug at each other: on the one side we have the 'traditional' model of releasing a monolothic OS image and a matching monolithic SDK; this is how it looks to a lot of people inside Nokia, I think. On the other side is the 'traditional' Debian model of using evolving repositories of packages where the packages are deployed in the 'same' environment as they are developed, and the repositories are the means of deploying new stuff; this is what people expect to be happening when they see Scratchbox and apt/dpkg being used for maemo. The situation where the "mistral" distribution is supported for the SDK but not for the device is a good example: this situation looks perfectly alright from the "OS image + SDK" point of view, but having the thing break when you configure "mistral" on your device was a big surprise for people who had the "one environment" view. In my opinion, the "one environment" development model is vastly better than the "OS image + SDK" model, assuming that we can make it work. And we _can_ make it work: the device and the OS running on it are fully capable of being a development environment, there should be no problem getting GCC running on it, etc. The device just is too slow and has too little memory to be a nice development environment. Enter Scratchbox: it's not an emulator to test the final software, but it's an emulator for the development part of the environment on the device. So I think we should be heading towards the "one environment" model. The sardine distribution is already there, and the rest is quite close. I think we can actually copy the Debian model mostly verbatim, with "unstable" for integrating significant changes, "testing" to represent the most recent release candidate for the next release, and "stable" for maintenance of the last release. Roughly speaking, "sardine" would be "unstable", "herring" is the first attempt at a distribution in "testing" state, "scirocco" is the current "stable" and "mistral" is the stable release before scirocco. One important point is that releases (that are 'stable') can evolve: maintenance would be done by putting a new version of a package into "stable". Another important point is that distributions are designed to be self-contained and all-encompassing: all packages whatsoever that are meant to be used _with_ a certain distribution should be _in_ that distribution. That would include all 3rd party applications listed on the Applications Catalogue wiki pages. The distributions would be divided into components, and "extras" would simply be one of those components. The existing 'Tableteer' catalogue would turn into a component as well (but it might continue to be hosted in a different way than "extras".) The proprietary software that is added to a meamo distribution to make the complete IT OS would also just be a component of the distributions. Ideally, this component will also be served from a public repository, but maybe that is not possible. It should be frowned upon for people to run their own repositories. The only accepted way to distribute packages for maemo devices would be to put them into one of the repositories on maemo.org. This allows the community to maintain them collectively. In the ideal world, the Application Manaher would not have a "Application Catalogues" dialog at all; it would only have a "Select components" dialog. [ There could also be a "Select distribution" dialog and once a new release has been made of the IT OS, people might choose to use it to select that new release and then the "Check for updates" view would let them do the upgrade. (UI-wise it might be better to not put that functionality into the Application Manager,
[maemo-developers] star atlas for maemo
Hello, an application that I really miss from the 770 is a star atlas, does anybody knows of an existing application that could be easily ported to maemo? Most of the "big" ones like celestia or kstars are too heavy and use 3d open-gl hence are not suitable, I've tested "stars" but I've got errors like /home/ale/src/stars-0.12+1/configure: line 1: gtk-config: command not found checking for gdk-pixbuf-config... NONE configure: error: Could not find gdk-pixbuf-config in PATH Any hint? -- Alessandro Pasotti w3: www.itopen.it ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Scratchbox 1.x with scirocco/mistral
2006/11/29, Kalle Vahlman <[EMAIL PROTECTED]>: 2006/11/28, Tomi Ollila <[EMAIL PROTECTED]>: > my wishlist to scratchbox developers: > > 1) make this work (or is there something I did wrong ?) (*) > 2) update subversion to at least 1.3 so that svn log --limit=n works. FWIW, you can install self-compiled tools under /host_usr (which is visible in all targets) and add /host_usr/bin to your PATH. Actually it is in your PATH already, but the scratchbox version is found first (so reorganizing the search order is neccessary). You could also use the SBOX_REDIRECT_* variables I guess (see /scratchbox/doc/variables.txt for more info). -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Scratchbox 1.x with scirocco/mistral
2006/11/28, Tomi Ollila <[EMAIL PROTECTED]>: my wishlist to scratchbox developers: 1) make this work (or is there something I did wrong ?) (*) 2) update subversion to at least 1.3 so that svn log --limit=n works. FWIW, you can install self-compiled tools under /host_usr (which is visible in all targets) and add /host_usr/bin to your PATH. I have git there for example. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] libosso svn up-to-date?
On Tue, 2006-11-28 at 19:07 +0100, ext Johan Bilien wrote: ... > > I've noticed that it's necessary to call osso_initialize() before using > > any hildon-fm API. Is it also necessary to call it before using any part > > of hildon-libs? > > No that should not be necessary. > > I'm a bit suprised you need to do it for hildon-fm, is that because of > DBus-based gnome-vfs? That's a negative, sir. At least I have written GnomeVFS programs without osso_initialize. I guess osso_initialize would be only required if some code uses Libosso functions. BR, Kimmo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
