Nothing new, just GNOME 3

GNOME 3 is my favorite DE.
I really appreciate how much works has gone into GNOME. Into the UI and below the surface. Seen from my perspective GNOME - as on Fedora - turns into the best system-integrated DE. The control-center can actually be used to control system stuff - thanks to all the changes that happened below, within cups, systemd, pulseaudio, colord, ... To me Fedora feels more like one system, and not several layered components.
Sure, the changes were disruptive and not every one is happy with the results - but that's just normal. And I wonder about all this ranting and bashing on changes.
In the case of GNOME it's also nice and somewhat refreshing to see that there is a plan - a vision - of where to go and what to form.

bobthegnome, gcalctool and vala

gcalctool is the friendly calculater in GNOME. And now - after several others (at least cheese, zeitgeist, gnome-games)- it is ported to vala! Wow.

This didn't happen out of the blue, it was someone actually doing it - bobthegnome and PioneerAxon made this happen.
What does this mean? gcalctool should be easier to maintain and maybe attract even more contributors, as you don't have to deal with the whole boilerplate. And - Vala is gaining momentum. Nice. Cheers.

Fedora 17 Alpha declared GOLD - Try the shell in qemu.

Robyn Bergeron announced: Fedora 17 Alpha release (RC4) was declared GOLD [Source].
This release ships Mesa with llvmpipe (and several other enhancements to allow software rendering), this way gnome-shell can actually be run in a non-accelerated graphics environment - like qemu is.

Just fetch - today or the 28th - an ISO of your flavor (live CDs come in GNOME, KDE, LXDE and XFCE) and run it with qemu:

$ sudo qemu-kvm -smp 2 -m 1024 -net user -net nic \
  -cdrom Fedora-17-Alpha-x86_64-Live-Desktop.iso

Sadly qemu's curl support is still broken, otherwise we could just run:

$ sudo qemu-kvm -smp 2 -m 1024 -net user -net nic \ 
  -cdrom "http://dl.fedoraproject.org/pub/alt/stage/\
17-Alpha.RC4/Live/x86_64/\
Fedora-17-Alpha-x86_64-Live-Desktop.iso"

fontkodo - Searching through a selection of f/loss repositories.

Fontkodo - best experienced with Firefox, but it also works with others - indexes the repositories hosted at

• git.gnome.org
• git.kernel.org
• git.freedesktop.org
• git.freesmartphone.org
• code.entropywave.com
• git.fedorahosted.org
• pkgs.fedoraproject.org 

so covering spec files, python, vala, c, and java code, and images.The focus is therefor on Fedora, GNOME, and vala related code: To aid finding spec files, vala examples and digging through vapis.

Maybe this is useful for some starters which want to look at real world example code.
Search for vala files using "lang:vala" or pngs with a miracle using "lang:png beefy".
To find specfiles requiring orc and hosted at pkgs.fedoraproject.org try "origin:pfo lang:spec orc".

The journal - or system wide logging.

A couple of days ago I mentioned the idea of a session wide logging daemon.
Today the folks around systemd introduced "the journal", an improved logging approach for systemd based systems.

Session wide logging in GNOME.

Currently each application in GNOME is using GLib's logging functionality or something custom.
Errors written to stdout get logged in ~/.xsession-errors - and other places we don't know about.

What I would like, is to have a central place for application related logging. This could have many benefits:

• Users have a single place to look out for errors applications didn't (yet) tell them about.
• A logging daemon can keep a history and this could help solving bugs, e.g. it could be added to abrt reports.
• Leads to less clutter in ~/.xsession-errors

If such a daemon is introduced, it should to be easy to integrate and be backwards compatible. In my eyes talking to this daemon can easily be realized by providing a GLogFunc, which handles the appropriate communication with the daemon. Additional features - like searching or exporting - could also be provided by the DBus interface, bt this is not important for logging itself.

And this is what I suggest:

slogd a simple logging daemon, providing a DBus interface to log messages.  This daemon also has an example backend which logs the messages into a sqlite database (via GDA).

libslogc a very tiny library to communicate with the daemon and slogc, a small tool wrapping libslogc. libslogc also provides slog_client_log (...), a GLogFunc to be used from C.

And there is finally simple.c, a small example on how to integrate libslogc. (Well, there ain't much to do.)

The code can be found at https://gitorious.org/valastuff/slog.
This is a prototype to get some feedback and see what other people think about a central logging daemon.

Fixed: Suspend and Resume on Lenovo x121e

Lately - after using suspend and resume extensively - I've quickly noticed, that the wireless card doesn't come back to live after resume. After filing a bug and getting help - it was somewhat dump not to update my bios after right away - I got the bug fixed using this BIOS/EFI update from Lenovo.
While burning the ISO onto a CD-ROM I found this bug: When nautilus removes the CD drive from the system and doesn't eject the CD-ROM when pressing the "eject" button in nautilus' sidebar.
A last word regarding suspend and resume - I am not completely convinced that the wireless always returns from suspend ...

Da sein - Introducing presence a tool for »videoconferencing«

Intended purpose: Use this application to transmitt audio and video in an n-to-m-peers fashion in quite high quality and with a hopefully low latency. This can be the case in scenarios like connecting video walls, e-lecture or simple bi-directional two people communication.

Intended audience and requirements: This application is designed for an elite circle of users who are in a situation with:

• no NAT problems, e.g. IPv6 users
• one multicast domain or access to their DNS records
• quite high bandwidth, like 2 Mb/s
• secured transport way, aka VPN or or non-public network
• multi-core systems (single core Intel Atoms are a no-go), but something like an AMD E-350
• Fedora 16

Design: Trageting a very specific need (near-realtime bi-directional a/v transmission in a good quality, not caring about bandwidth and security) this tool also doesn't follow public standars like RFCs, but more builds ontop of available features (e.g. gstreamers rtpgstpay). On the other side standards are use:

• RTSP stream control
• dirac video codec
• vorbis audio codec
• mdns service discovery
• Mx based interface
• Fulscreen mode
• IPv6 support

Currently presence is some kind of beta. Find out more on the appropriate page.

Rollo - gswitcheroo, a small daemon for vgaswitcheroo.

I'm working on a small library/daemo/client which wrap some functionallity of  vgaswitcheroo, a small kernel feature to handle hybrid graphic setups found in some laptops.

The main intention is to allow the user to switch to the required card
Sometimes this switch is required, because just one of the cards is connected to the external output of the laptop - which can be used to connect a beamer.

The current code can be found at https://gitorious.org/valastuff/gswitcheroo.
daemon and client should be working by now, but the installation bits need some work.

My intention is to add some configuration point to gnome-control-center. A first suggestion was to use the "System information" -> Graphics-Tab.
Any suggestions and early adopters?

Lose Enden - What it is all about.

The release of GNOME 3 included more than a visual overhaul. The underlying libraries were partly cleaned up and gained new features.

One of these features that gained more ground was gobject introspection (gi). Libraries using GObject can then easily be called from languages like python or Javascript if the support introspection.

This is where vala jumps in. Vala is language which tries to support the C# syntax but uses GObject and compiles to C, which then is compiled into binaries using common C compilers.

So what is the benefit? As all executables and libraries created by vala or based on GObject, their functions and classes etc. can be called natively from gjs (a JavaScript interpreter) and python (using pygi)
Also most GNOME related libraries are build using GObject.

This leads us to the situation where you can use a scripting language and have access to a comprehensive stack of libraries regarding the GNOME desktop environment.

• Rapid development? JavaScript.
• Layout? Glade.
• Style? CSS.
• Library? Vala.

It's not just theory. Look at gnome-shell or gnome-documents.