Networked A/V setup on the cheap with UPnP

As some insiders might already know,I recently acquired a flat. After 1+ month of heavy renovation, now comes the geek-entertaining time of setting up a sound and video system.
edit: the flat is now on the market again.

Having a very few physical media supports, the setup favors digital content and provide it to any interested playing or controling device. 
UPnP AV/DLNA became quickly obvious with its isolated media provider, controller and renderer concepts.
Unwilling to overpay a dedicated bundle and favoring standards and openess, I went on building my own small wireless flexible A/V system. Might be worth sharing.

The main content is made available by a UPnP server driven by Rygel and Tracker on a spare old laptop (200€). Tracker indexes medias from file system later served by Rygel UPnP server.
The setup was a breeze on Fedora 16 with the minor annoyance of DBus requiring a X session. I guess this coupling will soon be broken in our waylandy days. Hopefully.
Furthermore, each other devices exports its local media content "on the wire".

Music is mainly played on a pair of Raumfeld Speaker M (600€). Those babies access and renders music from UPnP servers through Wifi. 
Take my world as a non-audiophile, but they sound very good at all volumes exposing a clear separation of trebbles, mediums and bass. Dont be fooled by the cryptic documentation, the dedicated Controller is not required to integrate nicely within a standard UPnP network. A small web interface is provided to set them up as standalone.

A Panasonic plasma tv P42GT30 (620€) will take care of sending photons from UPnP content. It is quite on the cheap currently and got a slimmer design while keeping the plasma picture quality.










Free UPnP control point apps were installed on Maemo, Android, webOS, linux, and osx devices. They act as fine-grained remote controllers to distribute content to renderers (speaker or screen).

A cheap WiFi router ties everything together with an auto-magical discovery.


A Spotify/UPnP bridge would be greatly welcome but I couldn't find any up-to-date working solution. Independify seems un-maintained ans segfaults with current deps.

Typesafe GObject through static bindings

Recently, I've spent some time discovering type systems theory and got hook to strong statically-typed languages benefits. I just want a compiler to catch more errors thus giving me thrust and guarantees in the predictability of the product and its code.
I also like my IDE to have a lot of contextual data to help me through the implementation. Completion, early errors and defects detection are quite lifesavers.

Contrary to what one might naively expect from a compiled language, C/GObject lakes such insurances and proofs about the correctness of the generated binary.

GCC unawareness of anything but structs and functions makes it a bad helping hand when it comes to code with confidence.
In order to provide OO idioms to developers, GObject does most of its typing at runtime: types, signals and properties are all resolved and bound at the last minute.
Thereby a successfully compiled binary might fail at runtime for type related issues that a compiler could have spotted earlier. Typoing "opened" instead of "open" as signal or property name might have unexpected consequences at execution for example.
Test coverage should include reading stderr where Glib/GObject throws type warning. Not fun as it implies a edit-compile-run loop.

Lets illustrate the issue. In the following code the signal is always referred as an int within an enum or a string. Arbitrary values could be passed without the compiler to raise any flag. Also the arguments typing is enforced only at runtime through a complex marshaling system. Here again, mistakes might sneak in:
C/GObject (example taken from http://simonpena.com/blog/mswl/discovering-gobject-signals/ )


Some languages bindings with compiler's support of OO idioms exists (Vala, Gtkmm, C#, java-gnome., mono...). Their compilers checks the correctness of types/signals/properties definitions and accesses. Note bellow how both the signal and its handler parameter are typed thus bindings error will be caught at compilation:
Gtkmm

Vala


More than their conciseness, the aforementioned benefits of strongly typed bindings makes them really advisable to newcomers IMHO. The C API might be improved by enforcing the wrapping of signals and their handlers within class. This solution implies some verbosity and a more complex bindings generation that could hinder its desirability. Not my call!

Where WebOS got it right: Text-based UI layer and applications

Taking advantage of the demise of HP webOS hardware venture, an orphan tablet and phone reached my postbox recently. As a traditionalist computer geek, I was interested to live the so-called post-PC experience using the beloved webOS.

The two form factors hardware feel robust and nice to handle, notably the perfect balance of usability and portability of the Pré 3.
The user experience is as enjoying and intuitive as stated in reviews describing it in great length. Thus, I wont detail it further.

The active applications developers community  is surprising for stray dying platform. Both official and homebrew channels provide maintained software. Firesales and quite flat learning curve broke barriers. Somehow they did something right here.

Fixes and extentions to standard shell and applications are distributed by Préware.  Being defined as textual data, easily diffeable and patcheable, the environment is simple to modify and extend at runtime location. The Holly Trinity HTML/CSS/javascript makes fiddling with the system accessible to casual developers.
Applications, both system and third-parties, are actually editable data.

The Shell's javascript nature and its you-shall-do-what-you-want extensions mechanism, dynamic languages bindings, GtkBuilder and CSS-enabled Gtk+ tend to offer the same advantages to the Gnome platform.
Though, modifying core modules (mailer, contacts directory, web browser, to name a few) ain't a straight-forward process. Furthermore, patches packaging is not supported by major distributions provisioning services.

Making the whole environment patcheable in-situ without restrictive extensions points might prove fragile and error-prone but offer a freedom rarely seen even in free software. Preware packages supports patch reversion in case of issue or change of mind.
In the interim of having a common extension mechanism ala OSGi and robust well-defined extension points, local-patching might catalyze the transition from user/applications developer to contributor. Editing a system file and creating a patch is a fast process to create a deviation from a base system compared to getting the source, editing building and packaging.
Proposed patches for distribution should be deeply reviewed to enforce compatibility, security and quality.

In a read-only base system future, patches could be deployed at boot time using FS overlays as found in Fedora USB image, ZFS or Btrfs. Or why not a system-wide git repository ?

What's your take ?

Third-party developers experience... Where are we ?

Apple iOS application-centered focus and marketing made third party applications ecosystem a decisive aspect of user capture.  Solution life-cycle and attractiveness are increased by external developers adding each and every use cases imaginable. Even digitally farting.
Thus recruiting third party applications developers is an increasing challenge for a platform competitiveness and userbase/contributions growth.

The monetary insensitive of commercial platforms is certainly a decisive argument, but we may have better to propose with our warm and human-sized community, independence vis-a-vis a single provider, good-doing and ethical principles. And beer events.

The introduction to our technologies and community should strive to be as painless and entertaining as possible while matching the developer knowledge-thirst, a common disease upon us and a huge motivation catalyzer.

A fun, lean and streamlined developer experience may attract the more feature-oriented developers that enjoy watching their ideas materialize as an applications. From project bootstrap to installation on user system.
Those more into technology would enjoy our mature but ever-growing sets of tools, libraries and services.
Picking their interest is an occasion to convince them of the benefits of free software development and maybe have them help improve our common playground.

It is my opinion that the current offering of Gnome in that regard is not as good as it could be. The learning curve to become a proficient application developer is quite steep beginning by choosing a language and setting up a development environment. Coding, scheduling, sharing, testing and distributing an application, all suffer from barriers and complexity. But that can be improved, right ?

By digging into following platforms, I'll try to identify what helps makes a good developer experience, or a great one even.

• Apple iOS: Great documentation and tooling. Self-contained easy-to-setup SDK that handle application life-cycle from development to distribution. Code is written in Objective-C/Cocoa using the XCode IDE. No real 3rd party libraries community.
• Google Android: Regarded as practical API-wise and well-documented. Self-contained easy-to-setup SDK that handle application life-cycle from development to distribution. Using of the Java language, it benefits from its gigantic set of tools (IDEs, build bots, continuous integration) and libraries 
• Eclipse RCP + XScalaWT: Provide a great module mechanism (OSGi) and a lot of services commonly found in applications. Self-contained easy-to-setup SDK that handle application life-cycle from development to distribution. A rich ecosystem of 3rd parties modules avoid having to reinvent the wheel. Obviously development happens in Eclipse IDE in any language supported by the JVM. Scala peppered with a nice SWT DSL will be used. 
• the “Web Platform”: Applications development using our century franca-lingua: HTML/CSS/JS. With years of omnipresence, tools, libraries, documentation and community are unmatched. Still, application development requires system resources access, but not everything is standardized. Also javascript might prove a constraint for security, proper testing, static analysis and performance.
• HP WebOS: Based on web technologies, both Mojo and Enyo provide access to lower-level services to webby UIs. Offer great tooling and distribution channel (but nobidy on the other end)
• Gnome: versatile and complete SDKs, without much constraint in term of technology and possibilities. Might lake a coherent developer story with tools, conventions and processes to guide the developer
• Qt: not experienced yet.

For each, I'll share the full process of bootstrapping, creating and distributing a simple app and present thee communication channels, documentation, processes and tools. Good ideas might be picked here and there.

Then, I’ll match the findings with the current Gnome offering, with *personal* opinions on opportunities to fill holes.

JDK7: Where's my method ?

Yup, it is finally here. Long live to JDK7!
Well hopefully no that long, some people died of age waiting for this version.

Even if my work at Igalia do not usually involve Java coding, I keep an eye on the platform and enjoy some Scala coding sessions. Abstracted from all the complexity of managing object orientation and memory by-hand, helped by amazing tooling and funded by big shots, the community there pushes the envelop in the architecture,methodologies and good practices fields. Always interesting to learn from.

While bringing some improvements to the Java language and APIs, IMHO, the InvokeDynamic framework is the most important addition.
Type inference for generics, handled resources, interesting new/updated APIs (join/fork, NIO2, FileSystem) are great but making dynamic languages at home on the JVM is an amazing achievement.

Basically, InvokeDynamic let the JVM know and cache implementors decisions regading dynamic method call resolution/transformation at first call. Subsequent calls are then treated directly by HotSpot as any other invocation, applying its dark magic to optimize the hell out of it. And Hotspot is a good wizard.

Lets see how JRuby, Groovy and Jython will take advantage of it. JS might prove a greater challenge with its fully dynamic prototype typing, but work is on the way.

Posted from GScribble.

SeedKit BoF at Desktop Summit 2011

The Desktop Summit organizers recently announced the final schedule of the BoF sessions. The SeedKit proposal was selected !

So lets meet Friday, 12th August 10am in room 1.301 to discuss the opportunities of using web UI technologies to build offline gnome apps or augment your existing application with webby views.
We could even talk about your irresistible lust to contribute your ideas, skills or enthusiasm to the project!

In the mean time, get a look at the session proposal and add your name to the attendants list if you can.

See you all there.

Growing SeedKit

SeedKit being more than a year old, now is a good time to do a retrospective, get an overview of what's coming next and where you could help.

By lowering the entry barrier for building, distributing and maintaining a Gnome application, the SeedKit project wants to attract new contributors and make current developers' life easier.
The approach taken is simple: let developers reuse their web UI development skills, tools and community.
Furthermore, the resulting UIs will be more flexible, eyes-pleasing and dynamic, thanks to the amazing progress of the HTML/CSS/JS threesome in WebKitGtk and Seed.

So where are we now ?

We currently provide an GTK widget rendering HTML/CSS/JS content where native libraries and services are accessible from the JavaScript context.
DBus services, GObjects or custom code can be invoked and/or bound to DOM elements data and events.
End result: building an HTML UI communicating with local lower level systems is now possible. This might prove a great alternative to Gtk+ or Clutter.

For the full-blown SeedKit applications (lets call them hybrid for a minute) scenario, a runtime environment is provided. For now it only consists of a simple launcher but will hopefully be augmented with a standard library and a set of guidelines (mostly following the HIG 3) to ensure consistency among hybrids and 'classic' applications.

So yeah, you can run your hybrid application on your computer... Great, but how does it fall and deploy in the hands of the end-user you might ask ?

That's what is coming next.
We have no intention to build a versioning, dependencies and provisioning management system from scratch. Thus hybrid applications should be easily installed from distributions channels, namely packages and repositories.
Thus templates for .desktop files, rpm specs and debian recipes will be added soon to make the packaging a breeze.
If you are a bored packaging wizard, drop by the seedkit-devel list, we need you!

Another missing piece is the aforementioned standard library. HTML alone is far from providing the high-level concepts required to express a user interface naturally (sliders, modal windows, tree, list for example). Web developers already provided solutions in the form of libraries like Mootool, JQuery or ExtJs.
jQuery and its UI widgets will become the favoured target and will be packaged with each application or depended upon if provided by distribution's package. Some help with converting Gtk's Adwaita CSS to jQuery-ui would be great.
Also, we'll build jQuery-esque convenience wrappers for common operations like signals/events connection, data binding, internationalization and files access.

The vision and execution are still in their infancy so now is the good time for you to get involved, shape them to your tastes and need and have fun building the next big thing together ! Gnome developers, designers, web developers, translators, bug hunters will be welcomed with open arms.

Lets get in touch at the the Desktop Summit in Berlin, I'll hopefully present SeedKit in a BoF session.