DoctorMo's Blog

For community centers we need to present to the user the amount of time that their session has left and at the same time log the user off when the session timer runs out. As a nice touch we want to warn the user as the session nears it’s end.

To achieve this we use an app indicator with a menu item with the amount of time left.

For the warnings we use the libnotify and change the icon of the app indicator too:

We also want to notify the user of how much time they have, so we add a welcome:

If the program exits or is killed, the gnome pid is also killed so the user logs off.

All of this is configurable so we can say what users should have what kind of session and what warnings:


logs: /var/log/sessions/
limit_by_group:
admin: ''
users: 01:00:00
testing: false
warnings:
- message: Welcome!
description: You have %(remains)d minutes in your session.
icon: application-community
from: session-start
times: [ '00:01' ]
- message: Session Running Out
description: Your session is about to end automatically, please save all your work. %(time)d minutes remaining.
icon: gtk-quit
from: session-end
times: ['10:00', '05:00', '01:00']


For reporting we also want to log sessions, when they start, when they end and on what machine:


events:
- {date: '2011-07-07T15:36:02.734579', message: log-started}
- &id002 {date: '2011-07-07T15:36:02.763812', message: login, session-pid: 1830, tag: started}
- &id001 {date: '2011-07-07T15:36:51.898611', message: forced, tag: end}
meta: {hostname: delen, username: doctormo}


We add the program’s .desktop file to the /etc/adg/autostart directory so it launches when gnome starts.

You can find all the code here and the ppa package here.

There is a brand new stable release of the efl (Enlightenment Foundation Libraries) for Oneric, and because I want to play with python-efl, I needed to compile and build an entire PPA full of the newest stable release.

So here we have it, I invite anyone to use this PPA if you’re interested (or have a need) to use efl-1.0 in past Ubuntu releases.

sudo add-apt-repository ppa:doctormo/efl
sudo apt-get update
sudo apt-get install python-ecore ... etc


This ppa has taken me all week to build, it’s a lot of work so please do use it if you need up to date efl libraries or a newer cython build and especially if you need python-efl 0.7.3 or better.

I hope to use the code to produce the netbook-launcher effect in the logon screen, but this is very early days and it might be a fools errand. But it will be F’N awesome if successful. Report below if you know anything about programming with efl.

Hey guys, you might remember that a few days ago I was asked to build the lucid netbook launcher functionality for maverick; enough people asked me for a natty version that I wanted to make sure you guys got access to the clutter based netbook-launcher too. So here you go!

Of course this repackaging can’t go on forever, the packages I’ve sent to my PPA have no maintainer and sooner or later there is going to be major api failure as gnome3 moves on and ubuntu doesn’t ship the libraries this interface needs.

With that caveat out of the way, you can install the netbook launcher (3D) like this:

sudo add-apt-repository ppa:doctormo/netbook-launcher
sudo apt-get update
sudo apt-get install yeold-netbook-launcher

If you would like the 2D version of netbook-launcher, then the best thing to do is to install the netbook-launcher-efl which is shipped in natty (and meverick), true it’s a daft package which sucks in unity by mistake, but it still works and unlike the 3D code, the 2D code is still being developed (if only in small ways) by mterry.

Thoughts, comments and problems, please post below…

I’m please to announce that version 1.0 of the deviantArt stash plugins for Inkscape and Gimp are released.

It’s a Big Deal

This is a BIG deal my friends and I’m very excited because not only do we have this functionality, but we have it FIRST, before ANY proprietary software package. That’s right, the stash API was only announced last week and here I am giving you the keys to brand spanking new functionality right from within your favourite art creation applications!

We can do something with art that no other software can do today… send your artwork (with or without sources) directly to your deviantArt account… then once uploaded it can (at your option) open up the web browser so you can look at the artwork, send your friends a link or publish it further in your main galleries.

Oh and you can submit from the command line using the da-submit command.

Where do I get it!?

You can get the goodness from the source tarball or from my ppa if you’re using Ubuntu 10.04/10.10/11.04 by following these steps:


sudo add-apt-repository ppa:doctormo/deviantart-plugins
sudo apt-get update
sudo apt-get install gimp-plugin-dastash inkscape-extension-dastash


Please report bugs in launchpad, if you would like to make these plugins available for other platforms, please do let me know. If you know someone who will sponsor these packages into Debian, also get in touch. Because this is the sort of functionality that should be available directly from the software center.

How do I use it?

Simply go into either Inkscape or Gimp…

Open up an XCF gimp file and from the Image menu, select ‘Publish to’ > ‘deviantArt Stash’:

Open up an SVG file and from the Extensions menu, select ‘Publish to’ > ‘deviantArt’:

A small window will appear, fill in the title and maybe a few keywords and press ok… If this is your first time uploading you will get a pop-up asking you to authenticate:

Log in and now wait as your image is saved as a png, and then the png and source files as sent to deivnatArt. Inkscape might give you a warning that the extension returns (saying you weren’t authenticated) you can safely ignore it. You should still get the webpage pop up in your web browser showing your your new devination:

Now you can edit the piece in the browser and publish it to one of your galleries and give it a good CC license too. Don’t forget that the sources are made available by default, so be sure that’s what you want to do.

With Thanks To

A big shout out to Gilles Dubuc and Mike Halpert from deviantArt who made sure that bugs were fixed and I was given help trying to fix some of the problems with OAuth. Thanks LGM for hosting an awesome event that allowed the project to happen.

If you have any questions or thoughts, please add a comment to this blog entry…

OK so yes, this looks a bit weird but hear me out. The netbook-launcher package was the old clutter based user interface for the Intrepid to Lucid netbook editions of Ubuntu, which was supplemented by the netbook-launcher-efl package that used enlightenment for anyone who didn’t have 3D. After Lucid, the code for the non-efl hasn’t been development and now everything from Maverick onwards is Unity only.

The efl package is still available, but that has it’s own problems…

I always liked the netbook-launcher, I always put it on other people’s computers (especially for the elderly who need big icons) because it filled the screen and everything was right there on the desktop. Perfect.

Screenshot of Netbook-launcher working on Maverick

It wasn’t really available in maverick until tonight, when prompted by a friend who is delivering 10 new Ubuntu computers to the local working-class community. The plan had always been to use the netbook interface and the machines won’t run Unity. So here’s where I step in, I downloaded the Lucid code for liblauncher and netbook-launcher and have fixed the gtk bitrot errors and published the results on a new PPA.

I had to change the name of the clutter package because of the hatchet job done on the netbook-launcher package to upgrade people from Lucid to Unity/Maverick. This means that when you try to install netbook-launcher, you get unity instead. That aside packages are available here:

https://launchpad.net/~doctormo/+archive/netbook-launcher/+packages

My friend probably wants to use the efl version which is still in development (by the heroic mterry no less, is there any cool project that guy isn’t involved with?). The problem with the shipped version is that it recommends the old ‘netbook-launcher’ package which pulls in unity. So I’ve built a new version of that without that dependency problem and I’ll try and get mterry to update the package for Oneric.

To use/test this branch try this:

sudo add-apt-repository ppa:doctormo/netbook-launcher
sudo apt-get update
sudo apt-get install yeold-netbook-launcher netbook-launcher-efl

I hope this ppa will be useful to a few people and do let me know below if you would like a natty version of the package…

So I have all these client computers doing the right thing, I have a long, long list of tweaks needed to turn Ubuntu into a community center operating system. Right now I have a few limitations that I would like to put on users:

• Number of pages able to print per user per printer
• Disk quota, 500MB
• Timed Sessions (1 hour) per user group.

So far I know cups should allow page limitations, but I can’t find it. Disk quotas lack good documentation on how to set them up and timeoutd was the suggestion but it doesn’t appear to work with my testing. Also anything that notifies via notify-osd would be good.

Any suggestions?

One of the requirements for this community greeter (login screen for community center machines) is the ability to switch languages. Normally to switch a language you would unload the greeter and relaunch it with a LANG environment variable and your new language would fall into place from gettext.

But I wanted more. First, what languages are installed on the computer? For this I used python-pybabel and gettext, these two tools working together allow me to both get all the installed languages, limit them to just those I have translations for and show the translated name for the language (see screenshot below).

I decided that what I wanted to do was to hot-swap the text in the widgets. Since I’m using gtkme extensions, I could achieve this by creating a TranslatableWindow class. It’s job is simply to go through the window container at load time and note down all the translatable strings from labels and tooltips:

class TranslatableWindow(gtkme.Window):
“”"Provides functions for translating the window on the fly”"”
def __init__(self, *args, **kwargs):
Window.__init__(self, *args, **kwargs)
self.labels = []
self.tips = []
self.store_translations(self.window)

def store_translations(self, widget):
“”"Go through all widgets and store the translatable elements”"”
for child in widget.get_children():
if isinstance(child, Gtk.Container):
self.store_translations(child)
if isinstance(child, Gtk.Label):
self.labels.append( (child, child.get_label()) )
if child.get_has_tooltip():
self.tips.append( (child, child.get_tooltip_text()) )

def translate_to(self, lang):
“”"Loop through everything and translate on the fly”"”
lang = TEXTS[lang]
for (child, text) in self.labels:
child.set_label(lang.gettext(text))
for (child, text) in self.tips:
child.set_tooltip_markup(lang.gettext(text))
logging.debug(“Performed translation to %s” % lang)

Once I had translatable windows, I could tell my application class to go through each window and translate it if it was translatable:

def translate_to(self, lang):
“”"Translate all windows to target language”"”
for window in self._loaded.values():
if isinstance(window, TranslatableWindow):
logging.debug(“I18n window %s to %s” % (window.name, lang))
window.translate_to(lang)

Obviously because I’m not modifying the environment, when I log you on I need to update your language settings. I actually only show major language varieties and only ask about minor languages at registration time or when you change your setting:

If you’re even more curious, you can check out the code here: Launchpad Code or look at the translations here.

Update from my previous post: Here we have a branch containing a working gdm greeter user interface with a nice python module set for interacting with the gdm greeter service.

What’s nice about this code is how little of it you need to hack on the gdm. Binding up the username and password box to the events pretty much does everything. Most of the original functionality is simple to do.

The design isn’t final, there are gtk limitations and since gdm doesn’t really do clutter or opengl, it’d be impossible to do anything more interesting unfortunately.

The difference in functionality here is that you enter your full name (not your username) and it suggests people to you. The idea with this is that if you type in your name and you’re not a user, the next screen you see will be a register screen.

I selected my name from the list and then entered my passphrase:

Then it will log you in exactly as it should. Have a look at the code and see if you can hack on the gdm, it’s really very easy if you know a bit of python and gtk.

Comment if you do anything interesting.

In Ubuntu we use Gnome and the GDM (Gnome Display Manager) login screen called gdm-simple-greeter. This program is fairly fully featured for a normal Ubuntu install and even has a configuration in /etc/gdm/custom.conf which you can play around with.

But, I want to do something special, I’m making a computer lab with a registration screen and other fun stuff. I’ll blog about the designs and code for that in a future blog post. Today I’m going to talk about how I made a gdm greeter in python despite the lack of documentation and the round-about API challenges.

First thing to realise is that GDM 2.30 which shipped with Ubuntu 10.10 has a rich and full service/client API via DBus. This allows me to do what I’m going to do because it allows my program to act just like the shipped simple greeter. Only a single greeter can talk over the DBus API and it’s worth noting that the API isn’t over the normal System or Session Dbus, it’s over a private dbus unix socket to prevent all sorts of security issues with passing passwords around.

I first deactivated the GDM greeter: `mv /usr/share/gdm/autostart/LoginWindow/gdm-simple-greeter.desktop ~/Desktop/` this will now not allow you to log into Ubuntu!

Next I developed a script which uses python’s DBus lower layers to connect over the private dbus address. The address is given to us via an environment variable ‘GDM_GREETER_DBUS_ADDRESS’ and we just feed that in as it’s randomly generated. Fill in the PASSWORD and USERNAME variables to have GDM handle the communication and log in, this is certainly not a script you should leave installed and I have written a better one with a gui now, just use it as an example.

Finally I developed a .desktop file which will autoload the example script when the login is ready. Copying that into the directory `/usr/share/gdm/autostart/LoginWindow/`.

To restart GDM I used this command as root: `service gdm stop && sleep 1 && service gdm start`

I used a VirtualBox machine which I communicated over via SSH in order to test this out, over and over, hacking away at how this could be done. You can try the same. The log files you should be watching are in `/var/log/gdm/:0-greeter.log` you’ll get all the stderr messages from your login screen in there as well as all the errors.

You can use DBus System connections on org.gnome.DisplayManager.Display to control the display and org.gnome.DisplayManager.UserManager to get lists of users, user information and events for when users are added and removed from the system, same goes for network manager and a bunch of other services running during the login session.

I’ll blog more, and perhaps video when I’m finished. For now, if you’re interested in login screen development for Gnome2 (I don’t know what they’re doing for Gnome3) then this will interest you.

I was reading over the ever wise Matt Zimmerman and his blog post about Listening to Users; in it he argues that user involvement is a nuanced subject and which approach the developer takes can be highly dependant on the timing, cycle and context of the developing project. Providing examples and some interesting comment.

I basically agree with these ideas, but I wanted to add something more to the economic thought.

I talk about user involvement here; I never mean users who are programmers, users who help support other users or users who turn into developers by their continued project involvement. For that subject see User to Developer evolution.

What developers want from users is fine communication on what the challenges and needs they are facing. They would like as much depth into the issues with as much detail on the specifics which cause issues. This communication is not actually in effort to help the user, but is instead a way to help the developer’s project. The user can see the bug or interaction as a way to get their immediate issue resolved, but the developer will be focused on collecting and filtering the relevant information and making tasks to push the project forwards.

Of course the user will still benefit in due course; but the user’s direct support needs are instead not met by bug reports, but by support type people who may or may not know the aims of the project. The goal for support people is to give the user instructions so that they can mitigate their issue and it isn’t about helping the developer. A wily support person will be able to turn a successful support request into a successful bug report which the developer can process and turn into a permanent solution; on the other hand a user or support person who is used to mitigation strategy, but not used to developer interaction will fail to tie the loose end of why the user needed support in the first place.

This can lead to the dreaded ‘toxic workaround’ which Tim Cole has given a talk about. This is a workaround which becomes so well documented and so ingrained in the culture of the users of a product that they fail to actually tell a developer to fix it. So the problem always remains causing issue for anyone new and causing users to go through extra steps to get usable systems. A good example of this is in Ubuntu support channels when people are asked to and expected to compile anything instead of the code being added to a PPA.

In order the listen to users, I think a developer must know the difference between supporting the user, and supporting upstream development; which may place conflicting demand on the developer’s time. The user for their part, if they get frustrated with reporting bugs that never get to be solved, can lash out at developers, ordering and demanding action should be taken and issues resolved.

Of course, if the user isn’t paying the developer to fix their issues, then the user has no right to ask any developer to work on their issue. The user’s only real power is that they can be of use to the developer’s aims in their project’s future refinement. This is because the developer is the one that holds the majority of the economic power. When a developer talks with a user, it’s clearly with an effort to solve the issues the user has brought up; but I think the developer is always thinking about what fixes will benefit the project the most and which users are the most useful to communicate with to achieve those goals.

What are your thoughts?