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

[Flávio Cardoso Ferreira Pontes]

Hi all.

I'm not a developer, but I really think this proposal has merit.
I use blender cross-platform, on windows at work and in ubuntu at home,
and I see many avenues where some OS integration wouldn't hurt at all.

One that is universal is the question of fonts. I understand many people
do not use much the text tool, but for my trade (I'm a motion graphics
designer) it's fundamental. The current state is really bad, because the
name of the font file must be known to select the font. For the geeky
types like me, it's no big deal, but for the other designers/artists in
my department it becomes a tough sell. Whaqt i suggest is that blender
should have an option to load the font names from the system font
catalog and leave the rest as it is.

The same could be said about the plugins - There should be a plugin
registry where we could select the plugin by name, and, in the rare
ocasion when someone has a plugin thats not intalled, let it be loaded
by file name.

Another problem specific to the windows platform is network folder
access. It would be great if the network shares would display in the
file browser window. The way it is now prevents it from being used in
any serious project at work.

Anyway, for me blender is the superior tool right now. These are just
suggestions from someone who advocates it to non-geeky people.

Oh! Happy new year everyone! keep up the good work!

Regards,

Flávio.


Em Qui, 2008-01-03 às 06:17 +0200, Toni Alatalo escreveu:
> 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
-- 
Flávio Cardoso Pontes

Designer e Videografista
geekemevolucao.wordpress.com