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

[Toni Alatalo]

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 :)