Yes I know, if there was an alternative I would use something with open codecs but there isn’t and for better or worse my office uses Apple TV and AirPlay mirroring to do demos and when I have to run the scrum meetings. Having been the only holdout not to get a Mac and finding out that the iPad does not work as an effective VNC to AirPlay middle man, it would be nice to be able to connect natively from my Fedora laptop. To wit I found unofficial documentation on the airplay protocols and it seems to be fairly easy to support but I have no clue of where to start in the gstreamer code.
Basically it is a bunch of HTTP calls to establish the stream and then it is simply a number of packets airplay headers consisting of either H.264 video stream (of the desktop), H.264 extra data or a heartbeat. It also uses a separate port to do NTP time synchronization every 3 seconds. Seems pretty straight forward and fun project for someone to get their hands dirty with.
Note, that I am also willing to help with this if someone can tell me what pads need to be created and how I would go about hooking them up to get the correct stream. E.g. how do I do the http setup, hook in an NTP service and provide headers for h.264 streams and sync the whole thing up. I also plan on writing the UI bits as a GNOME 3 plugin complete with avahi auto-discovery if we can get this working.
[read this post in:
ar de es fr it ja ko pt ru zh-CN ]
Comments Off
I’ve been with Red Hat for over 8 and a half years now and while it would have been nice to get my 10 year plaque I was given an opportunity to join a newly created startup in downtown Boston called Stackdriver. I will be working there with former Red Hat employee and fellow Arlington neighbor, Jeremy Katz. It will be exciting to once again have a team that I will see every day and to be working in an office inside of Boston (ok the OLPC office was 1000ft outside of Boston – but close enough). I’m going to miss Red Hat and the OpenShift team. They are pretty amazing and I encourage anyone who is looking to apply for a job with them.
In any case it is time to take a risk and the opportunity presented itself. I wouldn’t leave Red Hat for just any company but the team they are putting together at Stackdriver along with the management’s views on how a startup should be run convinced me that it is a great bet to make.
I will be transitioning out of Red Hat at the end of the month and starting full steam at Stackdriver. Rest assured I will still be using GNOME and Fedora as my development platform and will continue to be part of the community though less visible. I am also coming back to Python land after my brief stint with Ruby. I have learned to like Ruby even while muttering under my breath on the lack of some documentation and strange design choices here and there. But I digress. It will be nice to get back into Python development.
To all my Red Hat coworkers and friends, lets make sure we keep in touch. Lately it occurs to me what a long, strange trip it’s been. Keep on truckin’!
[read this post in:
ar de es fr it ja ko pt ru zh-CN ]
Comments Off
I don’t do much GNOME work these days but since I was just at GUADEC and Thomas Bechtold started porting D-Feet to PyGI, I decided to do a quick design on how D-Feet could be made to integrate better with GNOME 3 and also become more useful. I’m also out of the loop on the whole Maemo project forks so excuse me if I should have been using a different project name in the mockups to show the concept of external embedded D-Bus monitoring. I don’t have time to do the actual work but perhaps this can be a starting point for those who want to bring D-Feet up to date with the current state of GNOME.
Bus Selection
The bus selection screen lists out the standard buses and allows you to add an arbitrary address. Notice we are taking UI cues from Documents, Boxes and all the other GNOME 3 application designs. The idea behind the statistics and status icons is to give a quick overview of the data going over the buses. This becomes more important as we drill down as it should allow quick identification of any battery draining services that are waking up too much. The idea is to show which services and buses are currently and historically (since d-feet was started) are active or idle.
Notice the bookmark side bar. I haven’t quite fleshed this out but the basic idea is a place where buses, services, interfaces and methods, etc. can be dragged and grouped for quick access per project. Even more interesting is being able to group services so that they become the only ones that get monitored which we will get to later on in the post.
Service Selection
Services are selected much in the same way buses are except you can’t create new services. Here we see the statistics and status which are the similar to the bus selection screen except they are restricted to the particular service. I like the placement of the status icon much better here in the upper left instead of on the icon itself. Status should also indicate if a service is not activated and give the option of activating it, perhaps with a play icon in the upper right. Notice that the user should be able to drag and drop a service into the bookmark panel and they should be able to coexist with buses there. Services without bus names should be excluded by default but be able to be turned on via a context menu option. Hovering over a service should perhaps bring up a quick details box for better identification of services with only unique names.
Service Browsing
Getting rid of the treeview means we can operate on a wider variety of devices. The pane view allows us to restrict to one pane at a time for smaller devices and multiple pane for large screen devices. Much more useful information can be displayed in this way. Like the services without a bus name common interfaces such as Introspectable and Properties are hidden by default. Instead we opt to use those interfaces to display more useful information such as the actual properties. Any items in the pane except for the details pane should be draggable to the bookmarks panel. The bookmark panel itself should have better visual separation than shown here.
Bustle Monitoring
Ok so this is pretty much stolen from my friends at the Bustle project. However there is no reason there needs to be two tools for debugging D-Bus. I just never had an idea of how to seamlessly integrate both tools. To start with I see this as simply monitoring on the bus and individual service level but with the named bookmark panel we can perceivably use that to group together the services and interfaces that we are interested in monitoring and kick off a monitoring session from there. Ideally the output of the monitoring session can be used to further drill down to set up the next session, e.g. remove messages that are just cluttering the output.
Conclusion
This is all pie in the sky and requires someone to pick it up and run with it, further fleshing out the design and implementing the bits. D-Feet was originally a one-off I wrote designed to show D-Bus Python’s access to even the low level bits of D-Bus. It was also an exact visual representation of the message structure hierarchy/pseudo object model which some people had trouble conceptualizing in the early days of D-Bus. Having served its purpose well it is time to rethink D-Feet as a complete D-Bus debugging and monitoring tool with a modern interface that can run on multiple devices or as a remote debugger. I myself do not use D-Bus these days or have any time to work on such an ambitious project but hopefully this post will kickstart a couple of people who have been looking for a something to work on.
[read this post in:
ar de es fr it ja ko pt ru zh-CN ]
After being pinged in Bugzilla I finally set some time out to do a new release of D-Feet – The D-Bus Debugger. This release was aimed at getting some of the bug fixes that have been sitting in git out into an official tarball. The only big change is I took some time out this morning to hack up a new hi-res icon for better integration into gnome-shell. It is based off of the system-search icon in gnome-icon-themes and I now provide a source SVG so those with better art skills than myself can fix it up a bit.
Seriously though, please do feel free to commit fixes and ping me to do releases. I originally wrote it as a one-off tutorial because many similar projects failed to grasp the correct semantics of dealing with D-Bus messages at such a low level. I hear D-Feet is used quite a bit but my own time is limited for such a project as I no longer use it every day. In that respect, if someone wanted to take over upstream maintainership I am sure there is a community of D-Bus developer who would be grateful for faster release cycles and more attentive bug fixes.
Latest release: http://download.gnome.org/sources/d-feet/0.1/d-feet-0.1.14.tar.xz (sha256)
Project page: https://live.gnome.org/DFeet
[read this post in:
ar de es fr it ja ko pt ru zh-CN ]
Comments Off
PyGObject 3.0 has been released!!! This is the stable release we have all been waiting for. 3.0 has been stabilizing for some time. This marks a huge improvement over the 2.28 branch in terms of speed, stability and GObject API coverage. With this release PyGObject remains the most complete language bindings for developing application with GObject Introspection.
I want to thank everyone who has been a part of this release, from those who reported bugs to those who submitted large patches, and also those who cheered us on from the sidelines or gave us support in other areas. At this point in the project they are just too many to list so I won’t, in fear that I may accidentally leave people out.
Highlights Since 2.28
- New rewritten invoker is twice as fast and easier to extend and debug
- Complete break from static bindings so we may improve the core without breaking legacy APIs
- Better type handling
- Parallel installable with PyGObject 2.28 for legacy binding support (2.28 must be compiled with –disable-introspection)
- Support for function calling using keyword arguments
- Support for multiple arrays referencing a single length parameter (e.g. Clutter.Actor.animatev)
- Once again we support Windows builds with some caveats
Going Forward
As we move into another unstable cycle there are a number of goals we will strive for the next major release.
- Documentation – we jump started this at the Desktop Summit but a lot of work is needed to get this to the quality currently exhibited by the PyGTK bindings.
- Full Gtk subclassing – We are almost there but we still need support for calling C callbacks in Python to support overriding interfaces such as Gtk.Widget.for_all()
- Getting rid of all legacy marshallers – currently they are still being used for marshalling vfuncs and signals
- Cutting out the middle man – We should get rid of our dependency on GArguments and marshal directly to FFI
- Moving away from a Gtk+ focus – Clutter and GStreamer 1.0 are just as important to fully support
- Full Gio support – right now dealing with byte streams isn’t completely introspectable
ChangeLog
http://download.gnome.org/sources/pygobject/3.0/pygobject-3.0.0.changes (1.34K)
Download
http://download.gnome.org/sources/pygobject/3.0/pygobject-3.0.0.tar.xz (530K)
sha256sum: ef6735792b0d44287126a6a3b181c85559849063d770506fe06848adb87ce815
http://download.gnome.org/sources/pygobject/3.0/pygobject-3.0.0.tar.bz2 (629K)
sha256sum: 5682603c58be67e336e8cfaf19d6321158425797a7da12f646cc8706508ab95c
About PyGObject
GObject is a object system used by GTK+, GStreamer and other libraries.
PyGObject provides a convenient wrapper for use in Python programs when accessing GObject libraries.
Like the GObject library itself PyGObject is licensed under the GNU LGPL, so is suitable for use in both free software and proprietary applications. It is already in use in many applications ranging from small single purpose scripts up to large full featured applications.
PyGObject now dynamically accesses any GObject libraries that uses GObject Introspection. It replaces the need for separate modules such as PyGTK, GIO and python-gnome to build a full GNOME 3.0 application. Once new functionality is added to gobject library it is instantly available as a Python API without the need for intermediate Python glue.
[read this post in:
ar de es fr it ja ko pt ru zh-CN ]
PyGObject 2.90.4 has been released. This is an unstable release leading up to the PyGObject 3.0 release coming soon.
Highlights
- Various deprecated API that was only needed for the static bindings have been removed which means you must recompile anything that links to PyGObject (currently libpeas and glade)
- Overrides directory variable was taken out of pygobject-3.0.pc and moved to the gi._overridesdir attribute to avoid having multiple .pc files for each version of Python. This means third parties who install overrides need to import gi from their install scripts with the version of python they are installing for.
- Multiple arrays referencing a single length parameter are now supported along with flat GValue arrays. This allows APIs such as Clutter.Actor.animatev to be bindable.
- Refcount crasher bug triggered when using GObject.new was fixed so glade can now import custom Python GtkWidgets.
- Build system now works with MinGW environment in Windows.
- Python 3 now checks instance types again.
- Documents disabled since they aren’t useful yet and present parallel install issues.
- Demos were fixed up to better reflect the preferred way of using PyGObject.
ChangeLog
http://download.gnome.org/sources/pygobject/2.90/pygobject-2.90.4.changes (20.2K)
Download
http://download.gnome.org/sources/pygobject/2.90/pygobject-2.90.4.tar.xz (529K)
sha256sum: 8407b6997181bbca4783798e21d7d63ca41708a6c05a3b08c953d64e7b97b2a1
http://download.gnome.org/sources/pygobject/2.90/pygobject-2.90.4.tar.bz2 (629K)
sha256sum: 467eb39f06664fb8bbb9ab407a15b8d56a63a92ac2f0914afc8518aedd765c43
About PyGObject
GObject is a object system used by GTK+, GStreamer and other libraries.
PyGObject provides a convenient wrapper for use in Python programs when accessing GObject libraries.
Like the GObject library itself PyGObject is licensed under the GNU LGPL, so is suitable for use in both free software and proprietary applications. It is already in use in many applications ranging from small single purpose scripts up to large full featured applications.
PyGObject now dynamically accesses any GObject libraries that uses GObject Introspection. It replaces the need for separate modules such as PyGTK, GIO and python-gnome to build a full GNOME 3.0 application. Once new functionality is added to gobject library it is instantly available as a Python API without the need for intermediate Python glue.
[read this post in:
ar de es fr it ja ko pt ru zh-CN ]
Comments Off
I’ve been tracking down some crashers and refcount issues as well as cleaning up the Python 3 support. Next release will also remove all of the file conflicts associated with PyGObject-2.28 parallel installs. We also have support for compiling under windows using MinGW thanks to Dieter Verfaillie. If you have a bug you care about now is the time to ping me in #python on irc.gnome.org.
[read this post in:
ar de es fr it ja ko pt ru zh-CN ]
