[Bf-committers] 2.5 UI font

[Toni Alatalo]

Knapp kirjoitti:
> bet we would loose all that with QT. PyQT has a restrictive licence
> but QT is good.
>   

This is getting offtopic, but just so that you know, there is also 
PythonQt which is actually made for embedding like done in Blender. We 
are using it in our Ogre network client app, Naali, to use Qt also from 
Python in the c++ app. PythonQt is not GPL but some BSD-like license, 
and also comes with wrappers to the qt core & gui etc libs. Then again 
Blender itself is GPL like PyQt so I don't know what your point was :)

The cool thing is that with PythonQt it is not only about UI, but the 
metaobject system - qt properties and slots are automatically exposed to 
Python (and Javascript via QtScript) without any manual bindings code, 
basically similar to the Blender RNA mechanism.

Blender has the own things, they are in place and working - am myself 
looking forward to integrating things from different apps to be tools 
there, curious to see how that goes (like can i use qt libs written for 
elsewhere in blender with pyqt or pythonqt or something).

~Toni

> On Wed, Dec 9, 2009 at 4:07 PM, Goat Man <goatman.py at gmail.com> wrote:
>   
>> Is there some logical reason why all this time is being spent reinventing
>> the wheel making a GUI toolset when there are perfectly good libraries that
>> currently do the job, ie. PyGTK and PyQT? Having it all done in openGL is
>> nice for performance, portablity to mobile devices, transparent overlays - i
>> admit, but in the end is it really worth all that extra work?
>>
>> I'm currently working with a small studio, and that as far as i know, we are
>> the only ones who are making an entire feature length film completly with
>> Blender249.  (don't ask me where we are or what the film is about i can not
>> disclose any of that).  Itsn't that the dream of the BF?  That somebody
>> would have the guts do an entire character animated film all with Blender.
>>
>> What is fustrating me is the corrners we are having to cut in 249, nobody is
>> supporting it, and i'm having to hack into the C code to expose things that
>> were missing in the Python API.  We want to switch to 25 right now, but
>> things are moving too slowly on 25 for our schedule.
>>
>> -brett
>>
>>
>> On Thu, Dec 10, 2009 at 2:16 AM, Martin Poirier <theeth at yahoo.com> wrote:
>>
>>     
>>> --- On Wed, 12/9/09, Damir Prebeg <damir_prebeg at yahoo.com> wrote:
>>>
>>>       
>>>> What amuses me is argumentation that horizontal layout is
>>>> bad since we had to scroll because of high panels like
>>>> Mirror Transp or Modifier stack. Yep, right. In current
>>>> vertical layout we don't have to scroll at all.
>>>>         
>>> What amuses me is that this isn't the argument at all.
>>>
>>> Panels that extend vertically means you have to scroll in TWO directions
>>> with horizontal layouts whereas vertical layouts already stretch in that
>>> direction, ensuring that you always only need to scroll in one direction.
>>>
>>> That means using the mousewheel to scroll is not enough for horizontal
>>> layouts because it only provides scrolling in one direction (sans
>>> modifiers).
>>>
>>> That is, of course, not counting any layout engine that would wrap around
>>> columns of an horizontal layout (that's not going to code itself).
>>>
>>> Martin
>>>
>>>
>>>      __________________________________________________________________
>>> Looking for the perfect gift? Give the gift of Flickr!
>>>
>>> http://www.flickr.com/gift/
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>>>       
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>>     
>
>
>
>