|
stage 5
Aug 5, 2007 12:25:13 GMT -5
Post by Exuro on Aug 5, 2007 12:25:13 GMT -5
I was just reading over your stage breakdown for stage 5 and thought I would throw out some comments.
"Button Settings Window: Users will now be able to set the angle at which the menu buttons open up their submenus. Angle 0 is straight up, while the rest move clockwise."
Maybe its just the years of math and physics i've taken, but wouldn't it make more sence to make angle 0 to the left and then go around counterclockwise, just like you would on a graph? This way 90 degrees is strait up and so forth. I don't know if this is a good suggestion it is just the way I have and I am sure others have always learned it.
"Button Settings Window: Users will now be able to instruct the 10 main buttons when they should become visible. These settings are also applied to the submenu buttons of that main button. Options include "Hide in combat," "Show in combat," "Hide out-of-combat," "Show out-of-combat," and "Hide menu on mouseout""
There are only two states you can be in. In combat and out of combat. This means that Hide in combat is the same thing as show out-of-combat. And also show in combat is the same thing as hide out-of-combat. I just thought I would point this out so you don't add four options when you only need two that do the same thing.
Thats all I found. Hope you had a nice vacation.
|
|
|
stage 5
Aug 5, 2007 15:08:23 GMT -5
Post by Moongaze on Aug 5, 2007 15:08:23 GMT -5
Maybe its just the years of math and physics i've taken, but wouldn't it make more sence to make angle 0 to the left and then go around counterclockwise, just like you would on a graph? This way 90 degrees is strait up and so forth. I don't know if this is a good suggestion it is just the way I have and I am sure others have always learned it. I honestly wasn't thinking about which direction an angle would be when I wrote it. I Agree though, that 0 should be left I'll do it that way. I had a good reason for breaking it down like that. I really did. Let me think a sec ... Ah, now I remember. The "show" and "hide" things would only take place or happen when combat started or ended. So, if you have a menu that is dedicated to buffs, you want to be able to show and hide it whenever you want by clicking the button. But you want that menu to hide when battle starts. So, with "hide in combat," the menu will disappear when the battle starts. When the battle is over, if you have "show out-of-combat," it will reappear again. Otherwise, it will stay hidden until you open it. I think I need to rename the ideas: "show when combat starts" "show when combat ends" "hide when combat starts" "hide when combat ends" This would make more since. However, if it worked like "show in combat" where it will ALWAYS be visiable in combat, and as soon as you're not in combat, it will disappear ... the issue would come from closing or opening the menu manually. Would it then see that you were not in combat and hide the menu again? Or would it let it be? I can also add "Only show in combat" "Only show out-of-combat" Which will do just what I described above. I don't know. Any other takes on the idea?
|
|
|
stage 5
Aug 5, 2007 17:24:18 GMT -5
Post by Exuro on Aug 5, 2007 17:24:18 GMT -5
I am such an idiot. I said left when I meant right. Had to think about the unit circle.
|
|
|
stage 5
Aug 5, 2007 18:45:03 GMT -5
Post by Moongaze on Aug 5, 2007 18:45:03 GMT -5
Than it shall be right. ahaha. I was a little confused when you said left, but decided to run with it. Either way, it will be the correct position and angle arrangement
|
|
|
stage 5
Aug 8, 2007 20:24:17 GMT -5
Post by Moongaze on Aug 8, 2007 20:24:17 GMT -5
In the end, I think it will be just "Show in combat" and "Hide in combat".
The menu's visibility will be saved before the combat starts. If it's open before combat starts and is set to "Hide in combat" ... it will hide when combat starts. At the end of combat, it will restore the visibility to the way it was (in this case, it will pop it back open). If you set "Show in combat" and the menu is already shown, nothing will happen when combat starts and at the end of combat, it will go back to being open. However, any closing or opening of menus will overwrite this. An example:
Menu is set to "Hide in combat" and is currently closed anyway. Combat begins. Since it was set to "Hide in combat" it hides (but was already hidden, so no big deal). However, during combat, you open it. At the end of combat, it would return to the state it was in (closed). However, since you opened it in combat, that setting will be overwritten and at the end of combat, it is left alone (and will be open).
Also, when set this way, the "auto-close" feature will not function, being that you would want the menu displayed in combat and if you use a spell, I would assume you might use another spell from the menu. The auto-close idea will work better when not in combat, but might be ignored if in combat AND the "show in combat" feature is turned on. "Hide in combat," I think, shouldn't be affected, as it's not needed IN combat, so if you open it, it should auto-close if you want it to.
...
Oh, and I'll have an "Always Show" option, so it will never close (good for some action bars, I guess ... haha)
Still working on the details right now as I code away ... haha.
|
|
|
stage 5
Aug 8, 2007 22:02:54 GMT -5
Post by Exuro on Aug 8, 2007 22:02:54 GMT -5
I was hoping you would do something like this but didn't want to seem too picky. All those other options were a bit too complicated.
|
|
wolftusk
Very Talkative Beta Tester
Posts: 140
|
Post by wolftusk on Aug 9, 2007 8:33:44 GMT -5
In the end, I think it will be just "Show in combat" and "Hide in combat". The menu's visibility will be saved before the combat starts. If it's open before combat starts and is set to "Hide in combat" ... it will hide when combat starts. At the end of combat, it will restore the visibility to the way it was (in this case, it will pop it back open). If you set "Show in combat" and the menu is already shown, nothing will happen when combat starts and at the end of combat, it will go back to being open. However, any closing or opening of menus will overwrite this. An example: Menu is set to "Hide in combat" and is currently closed anyway. Combat begins. Since it was set to "Hide in combat" it hides (but was already hidden, so no big deal). However, during combat, you open it. At the end of combat, it would return to the state it was in (closed). However, since you opened it in combat, that setting will be overwritten and at the end of combat, it is left alone (and will be open). Also, when set this way, the "auto-close" feature will not function, being that you would want the menu displayed in combat and if you use a spell, I would assume you might use another spell from the menu. The auto-close idea will work better when not in combat, but might be ignored if in combat AND the "show in combat" feature is turned on. "Hide in combat," I think, shouldn't be affected, as it's not needed IN combat, so if you open it, it should auto-close if you want it to. ... Oh, and I'll have an "Always Show" option, so it will never close (good for some action bars, I guess ... haha) Still working on the details right now as I code away ... haha. I think that some times, with certain features, i think it may be best to come up with the simplest solution first. I run across these things at work all the time. A handful of users "think" that they want a certain feature, but we usually hold off and come up with a simpler solution that is easier to code. When they have the simplified version, they often either change their mind about how they want a certain functionality to work or they decide that the functionality was not that important/useful in the first place. Also, by designing the simplest solution first, it gives room to make a more complex solution if needed. Just 2 cents...
|
|
|
stage 5
Aug 9, 2007 14:52:23 GMT -5
Post by Moongaze on Aug 9, 2007 14:52:23 GMT -5
I think I just need to have the addon spawn small pink elephants that walk on the screen and move stuff around on the interface for you when you're not doing anything. Like a screensaver, but when you move your mouse, they're STILL MOVING the UI!
Er, um ... hi! =)
I agree with what you say though. I try to do that as much as possible, but I know for a FACT that there's some crazy stuff I do or let people do that is more complicated than it needs to be ... but it was the first thing I thought of, haha.
|
|
wolftusk
Very Talkative Beta Tester
Posts: 140
|
stage 5
Aug 9, 2007 15:16:00 GMT -5
Post by wolftusk on Aug 9, 2007 15:16:00 GMT -5
I think I just need to have the addon spawn small pink elephants that walk on the screen and move stuff around on the interface for you when you're not doing anything. Like a screensaver, but when you move your mouse, they're STILL MOVING the UI! Er, um ... hi! =) I agree with what you say though. I try to do that as much as possible, but I know for a FACT that there's some crazy stuff I do or let people do that is more complicated than it needs to be ... but it was the first thing I thought of, haha. Jeez Moon. I am disappointed! I am sure you meant to say Pink Elekks and not Pink Elephants!
|
|
|
stage 5
Aug 9, 2007 15:19:58 GMT -5
Post by Moongaze on Aug 9, 2007 15:19:58 GMT -5
My bad, that's true. I did mean Elekks. Those are MUCH better looking that Elephants. And smell better too!
|
|
|
stage 5
Aug 9, 2007 16:13:06 GMT -5
Post by Haggo on Aug 9, 2007 16:13:06 GMT -5
I think I just need to have the addon spawn small pink elephants that walk on the screen and move stuff around on the interface for you when you're not doing anything. I don't know exactly why - but somehow I love this idea. ;D
|
|
|
stage 5
Aug 9, 2007 19:17:21 GMT -5
Post by Moongaze on Aug 9, 2007 19:17:21 GMT -5
... don't make me want to add easter eggs ... because I'll do it ... haha
|
|
|
stage 5
Aug 10, 2007 17:09:53 GMT -5
Post by dannyboy on Aug 10, 2007 17:09:53 GMT -5
... don't make me want to add easter eggs ... because I'll do it ... haha Please, oh PLEASE do! And, add a button to make them do that on purpose, for when I'm really bored!
|
|
|
stage 5
Aug 11, 2007 13:34:20 GMT -5
Post by raederle on Aug 11, 2007 13:34:20 GMT -5
By the way, those of us who are map types and pilots would much prefer to have 0 be north, ie straight up. We already think 205, ahh south south west aka *that* way. Which doesn't mean you should now change references, simply that there is no "best" reference.
Raederle
|
|
|
stage 5
Aug 11, 2007 15:29:43 GMT -5
Post by Moongaze on Aug 11, 2007 15:29:43 GMT -5
Maybe I'll add something in the sphere settings window, somewhere, that will let you make it 0 degrees being north, or 0 degrees being right. We'll see ...
|
|