A new Ubuntu Linux was released on 21 April. It is version 8.04, with codename Hardy Heron. So I upgraded my home desktop machine. Emacs still works and mutt still works so I am happy. ;-) For me there were two snags until now:

• I want the Caps Lock key to behave as an extra Control key. This worked before and it still works, but now when I press the Caps Lock key the light indicating that Caps Lock is on starts or stops shining, even though I only really use it as a Control key. See this bug report, which also mentions some remedies. I ended up adding some lines to my ~/.bashrc file:

  xmodmap | grep lock | grep Caps_Lock > /dev/null
  if test $? -eq 0; then
      xmodmap -e "remove Lock = Caps_Lock" -e "keysym Caps_Lock = Control_L" -e "add Control = Control_L"
  fi
  

• Firefox 3.0b5 is used. There are not yet versions of Firebug and Live HTTP Headers that are compatible with this. That is not good when you are doing web development. I expect that this will get fixed soon.

In light of that last issue I think I will keep the laptop from my work at the previous Ubuntu for a while until those extensions are available.

Update: Both Wichert Akkerman and Jeroen Vloothuis tell me that there is a Firebug 1.1 beta that works with the new Firefox. This was not automatically found when Firefox looked for updates. This version indeed works, though for me it only works when opening Firebug in a new Window.

All in all a big thank you to everyone who made another Ubuntu version happen!

Today I discovered that an egg I just made for a package was missing some files. Most noticeable was the missing of some zcml files.

It turns out that when you do an svn export and then a python2.4 setup.py bdist_egg to create your egg, you are missing some files. At least I was. When you do an svn checkout and then make your egg, all files are there.

In neither case was any zcml file mentioned in the SOURCES.txt file in the automatically created egg-info directory.

For the tar ball created by a python2.4 setup.py sdist I did not notice any difference.

Does anyone know what is going on here and how to solve this so it works from an svn export too?

Cooking lesson for today: check that egg!

Oh, and sorry for spamming http://planet.plone.org today. I changed the language of a lot of weblog entries from neutral into English. Now they all needlessly show up on that home page.

For collective.editskinswitcher David Convent gave me the idea to get rid of the Access Rule and use a pre-traversal hook instead. That turned out to be pretty easy to do. This looks far cleaner to me. So collective.editskinswitcher is now available as version 0.3. Thanks for the idea David!

It now has an own Product page on plone.org too. Not much is there yet. For downloads just use the cheese shop. If you are using it, drop me a note: it would be nice to know.

Let me show some code. We subscribe to an event in configure.zcml:

And in traversal.py you then have this code:

def switch_skin(object, event):
    """Switch to the Plone Default skin when we are editing.
    """
    context = object
    request = event.request
    portal_props = getToolByName(context, 'portal_properties')
    editskin_props = portal_props.get('editskin_switcher')
    edit_skin = editskin_props.getProperty('edit_skin', '')
    ...
    context.changeSkin(edit_skin, request)

Well, the code is slightly longer, but this should give you an idea. Except for details this is the same code as was in the External Method, which is now gone.

All in all, for this change one file was added: traversal.py. And various files could be removed, mainly: Extensions/* and setuphandlers.py.

More importantly: if you now remove this package from your zope instance without properly uninstalling it, you are not left with an ExternalMethod in your Plone Site that gives errors because the file is not available anymore.

BTW, if you are using this package already, it is best to uninstall version 0.2 and then install version 0.3; that way the quick installer will take care of removing that external method with the access rule for you.

I improved collective.editskinswitcher again. For explanation on what it is, see my first blog entry about it.

You could already get a different skin (presumably for editors) when you are visiting your Plone Site with an edit url, like edit.yourdomain.com.

Now you can also get that edit skin when you are logged in. More precisely: when you have the __ac cookie. This does not work when you are logged in with basic authentication, in other words: via the ZMI.

This is controlled by two new properties in the portal_properties/editskin_switcher.

• based_on_url: when True (the default) you get the behaviour described earlier.
• need_authentication: when True you need to be logged in before your skin is switched. By default this is set to False. This looks for the __ac cookie that Plone gives you when logged in. Note: logging in via the Zope Management Interface is handled without cookies, so the editskin switcher regards you as anonymous then.

You can combine the two behaviours if you want. If they are both True, then you need to have the right url and you need to be logged in.

When both are False, nothing happens: then you might as well simply uninstall this product as it is not useful.

Collective Edit Skin Switcher

For a customer of Zest Software I created a package called collective.editskinswitcher. I gladly took some code from colleague Mark van Lent who did something similar for a different web site. The package is on the Cheese Shop so it can be easy installed. And the code is in the Plone collective.

127.0.0.1 edit.yourdomain.com www.yourdomain.com

...//(edit|cms|manage).something.something....