sugar-build: no Documents drive in Journal

[manuq]

Found the issue trying to attach a patch to this bugtracker from the Journal using Browse in sugar-build emulator. Traceback:

Traceback (most recent call last):
  File "/home/manuq/sugar-build/install/lib/python2.7/site-packages/sugar3/graphics/palettewindow.py", line 1415, in __motion_notify_event_cb
    self.notify_mouse_enter()
  File "/home/manuq/sugar-build/install/lib/python2.7/site-packages/sugar3/graphics/palettewindow.py", line 966, in notify_mouse_enter
    self._ensure_palette_exists()
  File "/home/manuq/sugar-build/install/lib/python2.7/site-packages/sugar3/graphics/palettewindow.py", line 961, in _ensure_palette_exists
    palette = self.parent.create_palette()
  File "/home/manuq/sugar-build/install/lib/python2.7/site-packages/jarabe/journal/listview.py", line 656, in create_palette
    palette = ObjectPalette(metadata, detail=True)
  File "/home/manuq/sugar-build/install/lib/python2.7/site-packages/jarabe/journal/palettes.py", line 102, in __init__
    copy_menu = CopyMenu(metadata)
  File "/home/manuq/sugar-build/install/lib/python2.7/site-packages/jarabe/journal/palettes.py", line 228, in __init__
    if not self._metadata['uid'].startswith(documents_path):
TypeError: startswith first arg must be str, unicode, or tuple, not NoneType

[dnarvaez]

This is a sugar bug, we should follow the ​http://freedesktop.org/wiki/Software/xdg-user-dirs spec and run xdg-user-dirs-update somewhere at startup.

That code is also too fragile I think, it should deal with a non existent document path anyway.

[manuq]

This happens to me with latest sugar-build in Fedora 18. In the XO with latest sugar the 'xdg-user-dir DOCUMENTS' is resolved correctly.

I tried running 'xdg-user-dirs-update' inside Terminal Activity in the sugar-build emulator. Gives this error:

[manuq@localhost ~]$ xdg-user-dir DOCUMENTS
/home/manuq
[manuq@localhost ~]$ xdg-user-dirs-update 
No default user directories
[manuq@localhost ~]$

Outside the emulator:

[manuq@localhost ~]$ xdg-user-dir DOCUMENTS
/home/manuq/Documentos
[manuq@localhost ~]$ xdg-user-dirs-update 
[manuq@localhost ~]$

[dnarvaez]

I think on the XO it works because it uses the same XDG_CONFIG_HOME of GNOME which is not something we should assume is the case.

The error you are getting inside the emulator it's actually a sugar-build bug. I just pushed a fix for it.

[walter]

Did your patch get pushed? I still have this problem on a fresh clone from today. And it doesn't seem to get pulled when I make run on an old sugar-build install either.

[dnarvaez]

Do you have the issue with xdg-user-dirs-update manuq was reporting or the original issue with Documents? For the first I landed a patch or so I thought. For the second no patch was produced yet, I'd expect it to work after running xdg-user-dirs-update from a sugar terminal and restarting though. If it doesn't please let me know.

The sugar patch would be trivial but I don't want to write more main.py patches before the ones I sent long time ago are reviewed and lands. I'm just going to risk conflicts with myself :)

[walter]

Sorry for the confusion. I was having the latter problem (no Documents folder).

[dnarvaez]

I spent some more time investigating it and I think the right solution
is to add it to sugar-runner.

There are really two scripts.

1 xdg-user-dirs-update. It generates user-dirs.* and it's run by the
display manager (gdm, olpc-dm etc). In Fedora and in Debian it's done
with a xinitrc.d script, but I assume other distributions will have
something similar.
2 xdg-user-dirs-gtk-update. Tracks locale changes and creates gtk
bookmarks file. It's part of the xdg-users-dirs-gtk GNOME module and
it's run by gnome-session (through xdg autostart).

Now, in a sugar-build tree, display manager stuff is handled by
sugar-runner, so I think that's where we should run
xdg-user-dirs-update.

If we care about locale changes, then we should also run
xdg-user-dirs-gtk-update in sugar, but that's a different issue
anyway.

[dnarvaez]

Pushed a fix in sugar-runner