[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.)

[Alberto Torres]

I have been thinking about this a lot of times. Using the user desktop
dialogs has several advantages, such user favourite paths, built-in
thumbnails/previews, unconstrained window and some more (explained
below).

There should be a simple way to call a python script when the user
request to load/save a file. Such script should not just return a
path, but it also should call Blender.Load() or Blender.Save()
functions. (the returned path would be used only for recent files menu
and default filename for the next open/save dialog).

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.

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.

Another reason for this is that it could handle different filetypes
other than blender native. The script could autodetect the file format
depending of the extension or looking for magic numbers and use the
appropiate script. (In this case the user should know when is
replacing the scene and when is appending data to it). A simple API
for querying non-bundled scripts about a supported filetype can also
be done whithin this master file-handling script.

All blender have to do in C is to call a python function when user
request to open a load/save dialog, and let the py-magic do the rest.

Regarding other common dialogs (color, fonts), it can be supported the
same way (dialog utilities or py modules), but returning the actual
value this time. I actually like blender color picker, and I rarely
used the font selector.

my 0.02€

Best Regards


2008/1/3, Toni Alatalo <antont at kyperjokki.fi>:
> On Dec 30, 2007, at 7:29 PM, Ton Roosendaal wrote:
>
> Hi,
>
> it's so cool that this refactoring is happening now :)
>
> > Result: windows open default with decoration (or as your default WM
> >
> > branches/blender2.5/blender/source/blender/windowmanager/intern/
> > wm_window.c
> >                       wm_window_open(wm, "Blender", win);
>
> one comment on a bit non-topical but related (old) issue, that i was
> again reminded of yesterday when was helping a Blender newbie (but pro
> with other apps) at our studio yesterday: integrating to desktop
> environments (or window managers, but i guess that newer term covers
> the fact that they are more than just WMs today).
>
> two examples: 1) file/dir select and 2) color picker.
>
> both are basic services that DEs like win, macosx, kde, gnome etc.
> provide (at least 1). interestingly, in some user requests the issue is
> not the UI, but *data*: people have stored preferences in their desktop
> env. for e.g. 'favourite' directories (in some company perhaps e.g. the
> dir of the current project), and i've heard of people using system
> color palettes cross applications, so that they have their fav. (or
> again: project defined) colors readily there for any app to use. i
> think it would be good for Blender to be able to access that data too,
> and it is perhaps easiest to achieve well just by allowing the use of
> the native widgets, which also has the added benefit of the same
> familiar interface for some users.
>
> i think this could and perhaps should be done optionally. isn't one of
> the points of the refactor to allow customising? the original Blender
> way of being uniform cross platforms is good too, and the internal file
> dialog has merits as well - i personally might well want to keep those
> as default, but see that other people and other use situations would
> benefit from using the native ones instead.
>
> without reading any of the new code, nor knowing ghost really from
> before, i was thinking it could be implemented with a kind of a plugin
> interface / function pointers in this style: (written in c-style py,
> ppl who prefer c impls can read just as pseudocode ;)
>
> def blender_filesel():
>      """the existing blender file dialog code"""
>      (..do da thing..)
>      return filepath
>
> def wx_filesel():
>      """an alternative filesel impl that uses the native widget via the
> wx wrapper"""
>      filepath = wxindows.fileselect()
>      return filepath
>
> def mac_filesel():
>      """another alternative file selector that uses mac native stuff
> directly to achieve perfect integration"""
>      filepath = cocoa.nsfileselect()
>      return filepath
>
> def playsign_filesel():
>      """
>      our company custom file selector that reads project info from
> server.
>      allright ok perhaps i would not do this here,
>      but in the os/desktop level instead (i'm sure e.g. kde allows this
> kind of customization)
>      so that other apps would use the same code too. so this not needed
> :)
>      """
>
> blender.tools.filesel_callback = wx_filesel
>
> .. so that is one way to support alternative file selectors (and color
> pickers could work the same way): have a way to define the callback
> function that is used to open the tool, and expect them to return the
> result in a uniform way. otherwise trivial, except i don't know exactly
> what it requires in c to have such a plugin system that alternative
> functions can be there dynamically .. of course just a compile option
> might do well too.
>
> i think the original main problem in supporting native widgets was the
> burden of doing overlapping work on many platforms. that is today eased
> by libraries like WX (which is 10 years old :), that wrap (a bit like
> ghost and sdl) the native stuff behind a uniform interface, and provide
> simple calls for stuff like file selections. so instead of making a
> plugin-system to allow arbitary code for those services, it might be ok
> to just allow optional use of WX (with e.g. build option). i am not
> sure if that would really enable perfect integration, or if indeed it
> would be better to have a plugin system so that e.g. osx or gnome fans
> can do whatever they want for their envs. http://www.wxwidgets.org/
> (it's a huge c++ lib, but who cares, so are mswin, kde and gnome too
> and they are fine as optional dependencies.. oh there seems to be some
> 3d apps that use it too, including the commercial SILO,
> http://www.wxcommunity.com/modules.php?
> op=modload&name=Downloads&file=index&req=viewsdownload&sid=11)
>
> now reading these window management commits that touch ghost too, i was
> also reminded of the possibility of adding this sort of stuff to Ghost
> which kind of plays the same role as WX for Blender already. but i am
> not sure if it makes sense, as have understood that Ghost is mainly
> focused on basic low level stuff like opening windows and getting
> keyboard and mouse input (like sdl), and not on high level complex
> widgets like fileselections and colorpickers, but dunno.
>
> yet another option would be to indeed allow custom callbacks for those
> (and other) tools, but so that the functions could be implemented in py
> too (is afaik simple to implement, just use a function from the py c
> api and pass it the pointer): this would shift the burden away from the
> core devs and the build system, as people could then dynamically use
> any libraries they want (macosx, windows, kde (and i guess gnome too?)
> can all be fully used from py) to implement the service and Blender
> would not need to know (of course possible well made integrations could
> then be bundled in the release as official scripts like usually). my
> basic criteria for deciding whether something should be written in c or
> py is still cpu intensivity, and calling a (couple) OS funcs to
> instanciate existing widgets is certainly not a performance prob., but
> i don't know if py hooks are in the scope of this refactor otherwise.
>
> sorry for the long rambling, hopefully the points came across in a
> clearly enough and not in a too stressful to read way,
>
> my 2cently yours,
> ~Toni (who now also read the new code to see how it works otherwise and
> is smiling :)
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


-- 
DiThi