[Bf-committers] integrating to desktops (Re: [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [13063] branches/blender2.5/blender/source /blender/windowmanager/intern/wm_window.c: Removed silly Global windowstate variable.)

[GSR]

Hi,
kungfoobar at gmail.com (2008-01-04 at 0601.58 +0100):
[...] 
> Why? Because this way the script can add support for such things as
> network shares, KIOSlaves (KDE) and GnomeVFS (Gnome). I would love to
> open and save a .blend file from an ftp or a ssh server as if it were
> local. I already do that in other KDE apps. The script caches the
> files in /tmp and tells blender to actually load/save files from/to
> there.

Heh, and any modern Linux, FreeBSD, Solaris and others provide FUSE
which means file systems ops are at the file system level, not app
level. Plan9 got things right. ;]
 
> Those common dialogs can be supported without any additional building
> requeriments. Just calling the appropiate command line utilities
> (kdialog, zenity...) or trying to import python modules. Of course it
> could autodetect which desktop enviroment the user uses.

I tried the following when Toni posted the first mail (for testing the
idea, personally I do not like the dialog that appears):

import Blender # Just to demo this is running in Blender :]
import pygtk
import gtk

dialog_action = gtk.FILE_CHOOSER_ACTION_OPEN
dialog_buttons = (gtk.STOCK_CANCEL,
                  gtk.RESPONSE_CANCEL,
                  gtk.STOCK_OPEN,
                  gtk.RESPONSE_OK)
file_dialog = gtk.FileChooserDialog(title="Select a file",
                                    action=dialog_action,
                                    buttons=dialog_buttons)

if file_dialog.run() == gtk.RESPONSE_OK:
    result = file_dialog.get_filename()
    print result
file_dialog.hide()
file_dialog.destroy()

It works up to the hide/destroy part, the window seems to get stuck,
no idea why (mixing event loops? no idea... damn, some cases like
destroying the window via window manager made Blender crash). So at
least the concept seems workable.

A different way I can see (excuse the unix style thinking) would be
forking a process with some parameters (command line, env vars) for
settings (open / save mode, start directory, etc) and read or write
the data (file contents) or metadata (file paths) as needed (named
pipes or stdin & stdout). Maybe worth mentioning to the XDG people,
they already provide simple utils (to launch mail program, for
example) so simple load/save integration could be interesting (working
from scripts, support any toolkit without having to link or even know
about it...).

GSR