[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34694] trunk/blender/release/scripts/ui/ properties_game.py: Fix for [#25963] Show mouse option in wrong Panel.

[Dalai Felinto]

Discussion to be continued over the tracker:
http://projects.blender.org/tracker/?func=detail&atid=498&aid=25963&group_id=9

Cheers,
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
>> here.
>> 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,
> Thomas
>
>>   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,
>> Dalai
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>