[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender  trunk/blender/release/scripts/ui/ properties_game.py: Fix for [#25963] Show mouse option in wrong Panel.
blender at dingto.de
Mon Feb 7 20:59:15 CET 2011
Ack, sorry Dalai, I just don't get it :)
> Discussion to be continued over the tracker:
> Dalei, I mean Dalai ;)
> 2011/2/7 Thomas Dinges<blender at dingto.de>:
>> Hi Dalei,
>> thanks for your feedback!
>> I appreciate that very much, because I don't get feedback regarding
>> UI/Interface (concerning the python scripts) very often.
>>> Hi Thomas,
>>> options such as framing (Letterbox/Extend/Scale) and background color
>>> are actually used for both Player and the embed BGE. So why not the
>>> mouse? The way I see it (and the reason why it's there) is because
>>> Blender itself always has a mouse pointer. BlenderPlayer, however, as
>>> a standalone application does not necessarily would have one. Yes is a
>>> "shared" property, but it stands on its own in the Player.
>> Good point, I didn't thought about the special status of it in the player.
>>> That said I don't have a really strong opinion on that topic and
>>> nothing was ever set on stone. I just miss a big picture on the design
>>> For example if mouse fits better under "Display" I would rename it to
>>> "Mouse Cursor" instead of "Show Mouse".
>>> Also I have my doubts on whether "Display Lists" and "Use Frame Rate"
>>> actually belongs to "Performance". Think that way, "DisplayList" is
>>> (finally) on by default. The reason someone would turn it off would
>>> be: (1) to run in a gfx that doesn't support it (is there such a
>>> thing?). or (2) in very particular cases where DL performs better than
>>> Vertex Array. "Use Frame Rate" in the other hand affects the whole
>>> game. It can slow downs the logic and physics to assure the rasterizer
>>> always run on its loops. I'm not sure about you but I only use this
>>> when I want to do screencapture of the game with
>>> bge.render.saveScreenshot. They are known cases where this can benefit
>>> your game (e.g. those with heavy Python calculation) but the change in
>>> the game is so drastic that, again, I don't think Performance is a
>>> good group for them.
>> "Display Lists" and "Use Frame Rate" were in the performance panel before my commit, that was not a change I did.
>>> I find great that you put time and effort on this, but such a change
>>> should come with a better explanation than the message
>>> "reorganization" and wrong panel may convey. Specially because
>>> otherwise it gets hard to argue on that.
>>> And please, I know you are doing a really nice work in the UI, but
>>> refrain from changes in the code if the person that committed is
>>> active and maintaining it :)
>> I am sorry Dalai, I will ask you for feedback on it next time, when I do
>> changes in the Game Engine UI.
>> Still, as module owner of the UI scripts I do changes there all the time
>> and in the best of my abilities. So did I today.
>> But I agree, that in this current beta (near to stable) stage we should
>> communicate UI changes better.
>> That's something I wish myself for other people too working on Ui
>> scripts. ;-)
>> I hope we can resolve the issue. :)
>> Feel free to change the Game Engine buttons if you find a better
>> solution. Or I/you can revert my commit?
>> Best regards,
>>> A reply in the commit log or a
>>> conversation over IRC can lead to a better dialog. Sometimes the
>>> maintaner-ish of a part of the code have sheltered ideas and future
>>> plans that can add for a better design. E.g. this is a list of things
>>> I would like to see in Blender before 2.5 and some of them does affect
>>> the UI: https://docs.google.com/document/d/1gBzJ_8A8_XHAE5NfyqV5UG7feZuLa_y7v-uccsHBNi0/edit?hl=en&authkey=CK3n9Y4G
>>> (see the 1st and 3rd item)
>>> Kind regards,
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers