Things You Don’t Expect To Discuss With Random Girls You Stand Beside At Concerts
#94: Memory allocation strategies for next-gen consoles.
Things You Don’t Expect To Discuss With Random Girls You Stand Beside At Concerts
#94: Memory allocation strategies for next-gen consoles.
Having evaluated various options the people at Bug Labs, makers of the BUG have decided to switch to using Poky as their build system and development tool. You can read more on their blog.
Been putting off writing about this for a while, but it's getting on a bit, so a 'short' blog post is in order, I think. Guadec '08 was pretty awesome. I was expecting it to be a little stale, not so many of the talks sounded that exciting, and all the talk about decadence/stagnation (poppycock!) probably lead me to have negative preconceptions. That just meant that some of the excellent talks that there were were even better, as they came unexpected.
OpenedHand, of course, had some excellent talks, but I guess this goes without saying by now. Clutter just gets more and more interesting (go check out the new 0.8 release, recently accompanied by 0.8 releases of the gtk, qt, gstreamer and cairo integration libraries!), as do our surrounding applications and technologies. Guadec always seems to get me coding on Dates-related bits - '06, I rewrote the event-fitting and query code in Dates (making it usable on the tablets), '07 I started writing libjana (as used in openmoko-dates and openmoko-messages, amongst other things) and this year, I wrote vala bindings and started some work with glade3 integration. Unfortunately still a ways to go on the latter, but I hope it'll provide the foundation of Dates 2, eventually. I will delivery on that pledge, honest!
Istanbul was an excellent location for guadec and is a really interesting and entrancing place. Anyone reading p-g-o would have seen the multitude of picturesque photos being spammed about the place, but the coolest thing with Istanbul is that it really is like that, everywhere you look. It must be awful for OCD photographers, there are so many picture opportunities. Even with my camera-phone, I managed to capture some (what I consider) great photos. It's a close match between Istanbul and Catalonia, but I think Istanbul just about pips it. One thing that Istanbul couldn't quite match was the very cool atmosphere that there was at the Villanova (sp?) cabin site. Having everyone in one place, with easy transportation to the event was really nice and it'd be cool if that were repeated in future guadecs somehow.
Outside of the businessy aspect of guadec, I had a great time jamming with the Drooling Macaques. Hats off to the guys (Lucas, J5, Alberto, Carlos, Claudio, Edward, Rob, Thomas, Lefty, Jono, I don't think I missed anyone?), especially for putting up with my terrible drumming! I'll be better for next year :) Also, kudos to Collabora and whoever else was involved in setting up the awesome boat party. Was a lot of fun, although I'm sure some others partied a lot harder than I ;)
As for all this GTK+3.0 talk, I think Karl's post is a pretty good short-list of features that I'd like to see in a new major version. To that list, I'd add easy event redirection, a w3c style bubble/capture event system and for there to be a scrollable interface, as opposed to some crazy, hard-to-implement, totally undocumented, magic way of creating scrolling widgets (no, I'm not bitter...) Also, better input method integration/control (from the program side as well as the user interface side) wouldn't go amiss. Past this, I don't think there's that much more necessary... For next generation interfaces, we have Clutter. Once we can embed GTK inside Clutter reliably (off-screen is coming in 2.x, right? That just leaves easy event mangling/synthesis/redirection?), all sorts of crazy shiz can go down. At the end of the day, I suppose it's down to the people that will be doing the work. If the majority of GTK devs think there needs to be a new major version, I trust them to make the right decision - they did a pretty bang-up job on 2.x :)
As for Gnome 3.0, I think the future of HCI lies in more specialist devices and ubiquitous/pervasive computing that it does on the desktop. I'd like to see a Gnome 3.0, just because I think it'd be very interesting and I like to play with new toys, but I don't think it's something that's *necessary* per se. Certainly there's still quite a ways to go in polishing what we already have.
Clutter 0.8 suite of integration libraries is now available for download
at:
sources/clutter-cairo/0.8/
sources/clutter-gst/0.8/
sources/clutter-gtk/0.8/
MD5 Checksums:
56b69645629293d5dcd93817fabe669a clutter-cairo-0.8.1.tar.gz 91262dd6ead7261a584dacf5dd1933f5 clutter-cairo-0.8.1.tar.bz2 9ebf9bbe406757472952743ca01870f3 clutter-gst-0.8.0.tar.gz 13d2a34ea76e4f010e66d20eba12e864 clutter-gst-0.8.0.tar.bz2 1fea21affb3a74014fc0b4270b67ed2d clutter-gtk-0.8.1.tar.gz 0a93adeb69281dcd1d8455a53f746d9b clutter-gtk-0.8.1.tar.bz2
The Clutter integration libraries suite is a series of open source libraries for integrating Clutter with other libraries:
This suite of libraries allows to use the Cairo drawing API into Clutter; or to use the GStreamer pipelines to render to a texture inside the Clutter scenegraph; or to embed a Clutter scenegraph into a GTK+ application.
List of changes since 0.6:
List of changes since 0.6:
List of changes since 0.6:
As usual, have fun with Clutter!
Poky Linux distribution provides SDK for quite long time. From time to time I hear persons which complain about lack of libX or libY in toolchain tarballs. But there is a solution for them — Poky SDK can be expanded with packages.
This is described in Poky Handbook already:
The meta-toolchain and meta-toolchain-sdk targets (see the images section) build tarballs which contain toolchains and libraries suitable for application development outside Poky. These unpack into the /usr/local/poky directory and contain a setup script, e.g. /usr/local/poky/eabi-glibc/arm/environment-setup which can be sourced to initialise a suitable environment. After sourcing this, the compiler, QEMU scripts, QEMU binary, a special version of pkgconfig and other useful utilities are added to the PATH. Variables to assist pkgconfig and autotools are also set so that, for example, configure can find pre-generated test results for tests which need target hardware to run.
Using the toolchain with autotool enabled packages is straightforward, just pass the appropriate host option to configure e.g. “./configure –host=arm-poky-linux-gnueabi”. For other projects it is usually a case of ensuring the cross tools are used e.g. CC=arm-poky-linux-gnueabi-gcc and LD=arm-poky-linux-gnueabi-ld.
So you want to build GTK+ based application but “configure” tells you that you miss GTK+ headers? In normal systems you would install development packages. Same is with Poky SDK, but due to fact that there are no repositories for Poky a bit more work is needed.
You will need contents of “tmp/deploy/ipk/” from other developer or from local Poky build. I have them from local build and they are stored in “/home/hrw/devel/OH/poky/trunk/build/tmp/deploy/ipk” directory.
Next step is editing opkg configuration file (stored in /usr/local/poky/eabi-glibc/arm/arm-poky-linux-gnueabi/etc/opkg.conf) to add feeds locations. With my packages it looks like this:
arch all 1 arch any 6 arch noarch 11 arch arm 16 arch armv4 21 arch armv4t 26 arch armv5te 31 arch qemuarm 36 src oe-all file:/home/hrw/devel/OH/poky/trunk/build/tmp/deploy/ipk/all src oe-armv5te file:/home/hrw/devel/OH/poky/trunk/build/tmp/deploy/ipk/armv5te
Now it is time to install those missing headers: “opkg-target update” will update list of available packages and “opkg-target install gtk+-dev” install required headers.
First something really simple: helloworld.c. Run “arm-poky-linux-gnueabi-gcc hello.c -o hello”. Result will be ARM binary:
14:14 hrw@home:$ file hello hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.14, dynamically linked (uses shared libs), not stripped
I took Tasks 0.13 as an example of autoconf based application as it use some libraries not present in standard toolchain. After unpacking and starting “./configure –host=arm-poky-linux-gnueabi” I got message that GTK+ headers are missing so I installed them with “opkg-target install gtk+-dev” (like it is described).
After next “configure” call there was message about missing “libecal” which is part of “eds-dbus” so “opkg-target install eds-dbus-dev” solved problem.
Finally “configure” does not give any errors and “make” call built application:
14:19 hrw@home:tasks-0.13$ file src/gtk/tasks src/gtk/tasks: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.14, dynamically linked (uses shared libs), not stripped
As you see Poky SDK is not limited to default set of packages but can be extended with additional ones. OK, someone needs to build them first but imagine situation when company has 10 developers — one has Poky build tree which he use to generate packages which can be used by rest of team without spending precious time on building.
Poky Linux distribution provides SDK for quite long time. From time to time I hear persons which complain about lack of libX or libY in toolchain tarballs. But there is a solution for them — Poky SDK can be expanded with packages.
This is described in Poky Handbook already:
The meta-toolchain and meta-toolchain-sdk targets (see the images section) build tarballs which contain toolchains and libraries suitable for application development outside Poky. These unpack into the /usr/local/poky directory and contain a setup script, e.g. /usr/local/poky/eabi-glibc/arm/environment-setup which can be sourced to initialise a suitable environment. After sourcing this, the compiler, QEMU scripts, QEMU binary, a special version of pkgconfig and other useful utilities are added to the PATH. Variables to assist pkgconfig and autotools are also set so that, for example, configure can find pre-generated test results for tests which need target hardware to run.
Using the toolchain with autotool enabled packages is straightforward, just pass the appropriate host option to configure e.g. “./configure –host=arm-poky-linux-gnueabi”. For other projects it is usually a case of ensuring the cross tools are used e.g. CC=arm-poky-linux-gnueabi-gcc and LD=arm-poky-linux-gnueabi-ld.
So you want to build GTK+ based application but “configure” tells you that you miss GTK+ headers? In normal systems you would install development packages. Same is with Poky SDK, but due to fact that there are no repositories for Poky a bit more work is needed.
You will need contents of “tmp/deploy/ipk/” from other developer or from local Poky build. I have them from local build and they are stored in “/home/hrw/devel/OH/poky/trunk/build/tmp/deploy/ipk” directory.
Next step is editing opkg configuration file (stored in /usr/local/poky/eabi-glibc/arm/arm-poky-linux-gnueabi/etc/opkg.conf) to add feeds locations. With my packages it looks like this:
arch all 1 arch any 6 arch noarch 11 arch arm 16 arch armv4 21 arch armv4t 26 arch armv5te 31 arch qemuarm 36 src oe-all file:/home/hrw/devel/OH/poky/trunk/build/tmp/deploy/ipk/all src oe-armv5te file:/home/hrw/devel/OH/poky/trunk/build/tmp/deploy/ipk/armv5te
Now it is time to install those missing headers: opkg-target update will
update list of available packages and opkg-target install gtk+-dev install
required headers.
First something really simple: helloworld.c. Run arm-poky-linux-gnueabi-gcc
hello.c -o hello. Result will be ARM binary:
14:14 hrw@home:$ file hello hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.14, dynamically linked (uses shared libs), not stripped
I took Tasks 0.13 as an example as it use some libraries not present in
standard toolchain. After unpacking and starting ./configure
--host=arm-poky-linux-gnueabi I got message that GTK+ headers are missing so I
installed them with opkg-target install gtk+-dev (like it is described).
After next “configure” call there was message about missing “libecal” which is
part of “eds-dbus” so opkg-target install eds-dbus-dev solved problem.
Finally “configure” does not give any errors and make call built application:
14:19 hrw@home:tasks-0.13$ file src/gtk/tasks src/gtk/tasks: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.14, dynamically linked (uses shared libs), not stripped
As you see Poky SDK is not limited to default set of packages but can be extended with additional ones. OK, someone needs to build them first but imagine situation when company has 10 developers — one has Poky build tree which he use to generate packages which can be used by rest of team without spending precious time on building.
BTW — It is not limited to Poky SDK. Other OpenEmbedded based systems should be more or less capable of doing such things.
Neil cooked up a quick Clutter-Qt widget (Klutter?Qlutter?) today.
For those that enjoy Qt, this represents a more powerful and flexible alternative to QGraphicsView (imho).
Source is here; http://svn.o-hand.com/repos/clutter/trunk/clutter-qt. Note, needs Clutter 0.8.
Mira’s reaction — priceless…
Last updated:
July 23, 2008 06:00 PM
All times are UTC.
Powered by Planet.