How I used baz to start my little project

This is a little step by step tutorial for those struggling to use Arch like I am right now. This assumes you haven’t used it before, but know enough about cvs. I don’t do a lot of the –bclark_redhat–dev–craziness that you see in tutorials because it’s just a little too strange for me, even if it’s the “right way” to do it. The Following Tux goes into a little too much depth to be a really good first time tutorial.

Tell baz who I am.

baz my-id "Bryan Clark <bclark_-_redhat>"

Create my archive locally first.

baz make-archive bclark_-_redhat--gnomearchive /home/clarkbw/.arch

Make this archive my default one, I guess in case I have others… which I don’t.

baz my-default-archive bclark_-_redhat--gnomearchive

Go into my source directory.

cd background-channels

Update: Skip down, see note below.

Now I init the tree, because I guess it needs that.

baz init-tree background-channels--dev--0.1

I now need to add my files in there.

baz add *.in *.am *.glade \
	gnome-background-properties gnome-background-channel-subscribe

baz add background_channels/

baz add background_channels/*.py

Check that I didn’t miss anything.

baz lint

Add the files that I forgot to.

baz add .arch-inventory
baz add background_channels/.arch-inventory

Then do the import, don’t know why I need this step either…

baz import

Update: Continue from here, see note below.

baz import -a

And this too? Seems like I should commit at least once.

baz commit

Mirroring my stuff

Now to put this on the GNOME server for easier distribution. Instructions provided from (Mirroring Archives with Bazaar)

baz make-archive -l -m bclark_-_redhat--gnomearchive \
	sftp://clarkbw@www.gnome.org/home/users/clarkbw/public_html/arch

Test to see that I can push stuff to the GNOME mirror.

baz archive-mirror


Helpful commands for you to get my stuff

Tell baz who you are.

baz my-id "Name <email@domain.org>"

Register the archive and… set it as your default

baz register-archive http://gnome.org/~clarkbw/arch/
	Setting arch cache to default path: /root/.arch-cache
	Registering Archive: bclark_-_redhat--gnomearchive

baz my-default-archive bclark_-_redhat--gnomearchive

List the different projects I have in my archive.

baz categories

List branches of the category from the category list.

baz branches $category

Checkout that shizzle from my archive.

baz get $branch

Phew! So that’s it. I think I did most of that right, at least everything works. Now caillon and I can hack around on the background channels!

Update: According to the snorp I can remove the sections from (and including) init-tree to the import section and get the same results.

Just the Channels Ma’am, just the Channels

So I guess I’ll respond since James is starting a good discussion about the channels. The locator file seems like it will work great, I honestly just picked the URI scheme because I knew it would work and it was easy to implement. I should update the page some to reflect that change.

I guess I should add this disclaimer around the technical parts for further discussion. “I’m doing technical hacks that allow me to move towards the idea as fast as possible”. :-) Any of the technical stuff I put in the design page was just to get this moving, so I appreciate fixes like this.

Rodney pointed out in his lovely little way that we should add a MIME type instead. However that solution seems to require fixing multiple pieces of the desktop and I’m not inclined to shelf the idea waiting on that. I’d rather drive forward to get the new parts done and when the ugly technical underpinnings are fixed change to that later.

Anyway Rodney seems all pissed off in his blog and I’m not sure why. My post wasn’t written to offend, but to talk about something cool I was working on. I’m assuming he misread my intentions of working on this channels idea and instead read that I’m rewriting the background capplet in another language. Just to make things clear, it’s not my intention to rewrite your capplet in PyGTK. That is not what I do for work or fun. I only rewrote the capplet because it was easier than trying to work with the existing one. Plus I like working with Python better than C, especially for a program this small and ephemeral.

What happened was I made some changes I felt were necessary to the XML that necessitated changes the rest of the code of the existing capplet and so a quick rewrite seemed the next step. I personally would be happy if someone rewrote my design because it might infer that the design was good, but Rodney and I apparently see things very differently. To each his own. In the end, the capplet layout isn’t ideal for what I want to do, so I won’t be using it for very long. Sorry for the confusion, I hope it’s just that.

The Channels

My post was about the channel idea and I don’t have the UI worked out for it yet. My focus has been on the actual interaction of people getting background channels and sharing them, more than how they actually pick them from the dialog. I think this is the most important part of the problem and I can probably whip up any dialog to solve the choosing channels/backgrounds problem pretty easily.

The channels could be implemented using just HTTP connects but the design I’ve been driving for isn’t just sucking down images from the net. I’m looking to create a kind of (responsible) social sharing of the desktop look. This partially comes from the effect I’ve noticed that people have when they see the backgrounds that others are using on their computers. Or they see the themes and color layouts that other people have and they want that same look. I say responsible sharing in there, because I think authors should be able to include a CC or other kind of license along with their background images if they like. This doesn’t actually create responsibility, but allows for it.

RSS feeds do have a Time to Live element in them, it looks like this <ttl>1440</ttl> under the <channel> parent element and I was planning on using that to determine when to check the channel next. If the ttl element was missing a default could be used instead.

The Storyboard

So this social sharing of backgrounds requires extra information to tag along with the background images. Information like Author, License, URL, and such. I’ll give a little storyboard of how I see it working, because that might convey the information better.


Dave uses GNOME. Dave is checking out photo.net and sees a link to [subscribe to background channel] of their recent photos. Dave clicks on the link and subscribes. He immediately gets a new background image fit to the correct size on his screen. Every week a new background image lands on his desktop. After the background being updated one week, Dave decides he doesn’t like the current image and wants something else for a background.

Dave liked one of the previous images in the channel and wants to have that image longer. He opens up the background chooser and selects the last image from the channel he’s subscribed as his background. Since Dave likes the current image so much he opens up the background chooser to see if the channel has any more images from that author. Through the chooser he then finds that the author has a channel of their own. Dave is then taken to the background image authors site where he can get more of those types of images.


Julia works in Dave’s office and uses GNOME too. She see’s Dave’s background and asks him where he got it. Dave tells her the site and then says that he’s sharing his background images too so she can poke around in his collection.

Julia searches and finds Dave’s computer on the network. She then sees the different channels Dave has subscribed to and the background images available. Dave’s collection is available to Julia as a channel that she can subscribe to herself or she can just get the channels that Dave has and subscribe to those. However Julia sees that most of Dave’s personal collection is pictures of metal bands and in searching for Dave’s backgrounds Julia saw Mikael’s channel that she likes a little better.


Mikael uses GNOME too! Mikael has been taking beautiful photos of his orienteering trips and setup a channel from his machine to serve those images. The images are from his photo collection that he decided to use as a background. Any descriptions that he created in his photo collection viewer are pulled into the channel so people can see more information about the picture. Julia subscribes to Mikael’s channel and gets bi-weekly updated background images from his trips, however she has been stalking him for years so these pictures aren’t big news.

Beyond Backgrounds

The idea then can extend beyond Backgrounds and maybe go into Themes and the like. However I’d like to work out the story for backgrounds because it’s a pretty simple incarnation of the idea and I think it can get up and running quickly. Themes might be easy to get going just like this too, if anyone is interested in this idea I’d love to talk about it, grab me on IRC or at GUADEC.

More Tech Stuff

Again, I’m just picking technology I know about that could be used for an implementation. I was planning on broadcasting available shared backgrounds through the Zeroconf protocol so that other people could view them and subscribe to my background images over the local network. I guess you’d use an HTTP server on the client to generate the channel page like a regular channel website.

Moving On

I’m planning on adding a BackgroundChannels page in the Research & Development section to the GNOME wiki so I can keep this information updated.

Background Channels

I’d worked on this project a while ago, it stalled in Red Hat for various reasons but I continued to toy around with it beyond that because I think it’s really cool and I am pretty sad nothing has happened with it.

The idea of background channels is to give GNOME Desktop users a way to subscribe to a background service. A background service could be a website that periodically releases new background images to a person in a similar way that a weblog provides periodically new entries.

How it works

The background service, (see example background service) runs just like a weblog. Art.gnome.org could provide their own background service just like this example one that would give people all the latest GNOME Backgrounds on their desktop without having to visit their website.

A person who travels to the background service website would see a channel link and click on it to subscribe to the service. This brings up the subscribe dialog like this one below.

When a person chooses to subscribe to a channel they are delivered new backgrounds to their desktop as the channel site updates. In the persons background preferences capplet they see that they are subscribed to a channel and are allowed to remove it if they don’t want to download updates any longer. (You could also just switch to a regular background and leave the channel around).

Things Left

There is probably some UI work that could be done to allow you to choose a specific background from those available from the service. This was never high on my list of finishing right away since the real work is in getting the initial experience done and then later we could work on letting people be more custom about the backgrounds in the channel.

RSS, I’m not an XML head so I just did what I could to make it work. However I’ve discovered a better, simpler way of doing the RSS than in my original example page. Instead of using the seldom seen enclosure tag for the image, which is the right way I believe. You’d probably get the same mileage from using the link tag and less people would have to rework their feedparser to get this thing running.

Code, I’ve coded a lot of this thing up in PyGTK, however I keep getting busy and have to continue to let it rot for a while. But I’ll describe the major parts (since it’s simple anyway) if anyone is interested in picking this up with me.

  • Background Channel RSS Feed
  • Feed Subscribe Dialog
  • Feed Parser Service
  • Background Capplet

Background Channel RSS Feed is a basic RSS feed that I used a pybloxsom blog to generate for me. There is some extra meta-data that you want to provide people about your images like author and description and copyright. I used the native plugin so I could have title=””, author=””, image=””, image_mime_type=””, and so on.

Feed Subscribe Dialog uses the feedparser from Mark Pilgrim to grab a new feed and get the content out of it in order to confirm that the person wants to subscribe.

Feed Parser Service is the most unfinished part of the code. This is supposed to be daemon process that runs in the background and periodically checks the background service site for new backgrounds. It downloads the RSS feed and the backgrounds and stores them locally, it also updates the persons background with the newly downloaded one. During download it displays something like below using egg.trayicon so the person knows the program is active and they are about to get a new background. I created this as a D-BUS service since I wanted to be able to activate it from the background capplet or the subscribe dialog and to make sure that I wouldn’t have multiple copies of the thing running.

Background Capplet was re-written in PyGTK, but I didn’t do too much to change it besides actually using glade and some general HIG cleanups. It stores everything in an XML format that’s close to the original but I avoided the mess with this dead-end wallpaper vs. background term debate and just used background everywhere. It doesn’t import your old backgrounds right now because that’s not a fun feature to add.

Here’s the code that I have so far, bgchannels.tgz. I’d like to get this into CVS sometime, but I wasn’t sure where it could go.

Possible Add-Ons

Torrents? I imagine for a background channel service to really exist with a decent amount of users they’ll want to move to using torrents to distribute their files. Not a big deal anytime soon, but worth thinking about in the future.

UI Love? As I mentioned the background capplet could be changed to better handle channels, however this isn’t the real interesting part so I hope people don’t get stuck on this aspect until we have the rest looking better.

References:

Update: Chris Aillon and I were planning on working more on this at GUADEC if anyone is interested in hacking on it there.

aboot

This is the blog personality of Bryan Clark. I'm a designer in a world of open source. This blog reflects mostly writing about Design, Open Source, Economics, Beer, Wine, and Dogs. There's more information about me on this site or you can contact me directly at clarkbw@gmail.com.

scategories