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@blender.org http://lists.blender.org/mailman/listinfo/bf-committers