T3D GUI Editor-Revamped: Introduction--Part I
by Daniel Hopkins · 09/24/2009 (12:59 am) · 9 comments
Hey all!
It's been a while since my last blog. During that time, I've been keeping myself busy doing different game-related odd jobs and working on some projects of my own. The most notable job I had the pleasure of working on was helping John Kanalakis port his super cool SpriteWorks program to T3D (the result of which should make its appearance in the GG store some time soon). It was great working with him and I had a lot of fun. If you haven't seen it yet, I would really encourage you to head on over to the blog and his website to check it out.
In the midst of all this hustle and bustle, I got to thinking about what kind of project I could start which would, similar to my realtime material editor for TGEA, increase my knowledge of particulare area of Torque, benefit the community in some way, and, perhaps, help me earn a little more money. To make a short story shorter, I chose to make revamping T3D's current GUI editor my project. Though a great improvement over the previous versions, I think you will agree it still has a lot of room for improvement. Time to get to work!
Hence, after a couple days work, though still in a very basic form, I figured it was at the point at which I could announce it and give a little introductory demonstration and perhaps a small glimpse of the power and usefulness of the final product. Without further ado:
T3D GUI Editor--Revamped: An Introduction
(I apologize for the poor audio. I'll try and have that ironed out for the future videos)
So, there you have it! As stated in the video, I would really love to get any ideas/comments/feedback the community might have. I think a big given is a realtime GUI control profile editor which allows you to create and edit profiles without leaving the editor, so, fear not, that is on its way. Other than that, feel free to throw out any and all ideas you might have regarding your version of a perfect GUI editor. It will really help to make a great overall product.
Well, that's all for now! Of course, I'll be posting more updates and videos as things progress. This is Part I.
It's been a while since my last blog. During that time, I've been keeping myself busy doing different game-related odd jobs and working on some projects of my own. The most notable job I had the pleasure of working on was helping John Kanalakis port his super cool SpriteWorks program to T3D (the result of which should make its appearance in the GG store some time soon). It was great working with him and I had a lot of fun. If you haven't seen it yet, I would really encourage you to head on over to the blog and his website to check it out.
In the midst of all this hustle and bustle, I got to thinking about what kind of project I could start which would, similar to my realtime material editor for TGEA, increase my knowledge of particulare area of Torque, benefit the community in some way, and, perhaps, help me earn a little more money. To make a short story shorter, I chose to make revamping T3D's current GUI editor my project. Though a great improvement over the previous versions, I think you will agree it still has a lot of room for improvement. Time to get to work!
Hence, after a couple days work, though still in a very basic form, I figured it was at the point at which I could announce it and give a little introductory demonstration and perhaps a small glimpse of the power and usefulness of the final product. Without further ado:
T3D GUI Editor--Revamped: An Introduction
(I apologize for the poor audio. I'll try and have that ironed out for the future videos)
So, there you have it! As stated in the video, I would really love to get any ideas/comments/feedback the community might have. I think a big given is a realtime GUI control profile editor which allows you to create and edit profiles without leaving the editor, so, fear not, that is on its way. Other than that, feel free to throw out any and all ideas you might have regarding your version of a perfect GUI editor. It will really help to make a great overall product.
Well, that's all for now! Of course, I'll be posting more updates and videos as things progress. This is Part I.
About the author
#2
09/24/2009 (1:46 am)
looks nice, a more intuitive ui... 
#3
09/24/2009 (2:01 am)
Nice job Daniel, had that exact same though about having to scroll to properties. 
#4
09/24/2009 (11:46 am)
Looks like an amazing tool, Daniel. These are pretty obvious, but I'd love to see videos showing the adding of custom content (text, images), multi-stage buttons (hover, pressed, etc), and non-button UI objects (meters, health bars, etc). Excited about what you're working on. 
#5
I am happy to assist you with testing and ideas. We depend on the GUI editor a lot more than the average Joe.
A. De-couple the GUI from any scripts. For example, if you have a script which dynamically makes changes at run-time to a GUI. You would not want to see those changes while in the GUI editor. You would want to see them only during run-time. For some reason, the GUI editor detects these change scripts, makes changes to the gui in the editor and when you save, you are saving the gui with the scripted changes applied.
B. Tab book and tab page need a lot of love. The gui controls should be a little smarter and prevent you from even seeing the tab page control. The ability to add a tabe page should be inside the tab book's properties window.
C. If adding a tab book or tab page control and set the dock property to full, it does not show in the GUI. If you do that then click and drag the control's size handle, they will pop into full mode.
D. If you have a very tall tab page and want to put a scroll bar in, this is a big hassle. In addition, if the tab page is taller than the screen area, you can not access controls on the bottom of the tab page. The gui editor needs a verticle workspace scroll bar.
E. Some controls should be properties and not controls where it makes sense. Thus eliminating nesting of controls for many common tasks. For example,
1. The scroll bar should be a property
2. Image should be a property
3. Border should be a property
F. GUI editor should know that some controls should not be added to other controls. For example, you can add a tab page on top of another tab page. The gui should prevent this.
G. The text should be a single control with properties you set which provide different behaviors. Why do we have multiple types of controls for this; i.e. textbox, MLtext, single line text, etc.
H. MLText needs a editor.
I. The concept of look and feel could be revamped. Why not set properties like font, bold, italic, size, color, etc. all in the properties of the control. AKA Visio Studio's approach.
J. When selecting the value of a property, it needs to select the entire string, not just what is shown on the screen. Also the cursor needs to go to the end of the value not the beginning.
K. If a property is a vector, then present 3 separate boxes with up/down arrows so values can be changed by typing them in or with the arrows.
L. A blank GUI should have properties where you can set background, border, image. Not nesting of controls.
I can provide more if this is the direction you were heading?
09/24/2009 (12:06 pm)
The GUI editor is so weak and full of little gotchas. I wrote a list of bugs for beta 4 and not all of them were addressed in B5. I am not sure they will make it to RC though? I am happy to assist you with testing and ideas. We depend on the GUI editor a lot more than the average Joe.
A. De-couple the GUI from any scripts. For example, if you have a script which dynamically makes changes at run-time to a GUI. You would not want to see those changes while in the GUI editor. You would want to see them only during run-time. For some reason, the GUI editor detects these change scripts, makes changes to the gui in the editor and when you save, you are saving the gui with the scripted changes applied.
B. Tab book and tab page need a lot of love. The gui controls should be a little smarter and prevent you from even seeing the tab page control. The ability to add a tabe page should be inside the tab book's properties window.
C. If adding a tab book or tab page control and set the dock property to full, it does not show in the GUI. If you do that then click and drag the control's size handle, they will pop into full mode.
D. If you have a very tall tab page and want to put a scroll bar in, this is a big hassle. In addition, if the tab page is taller than the screen area, you can not access controls on the bottom of the tab page. The gui editor needs a verticle workspace scroll bar.
E. Some controls should be properties and not controls where it makes sense. Thus eliminating nesting of controls for many common tasks. For example,
1. The scroll bar should be a property
2. Image should be a property
3. Border should be a property
F. GUI editor should know that some controls should not be added to other controls. For example, you can add a tab page on top of another tab page. The gui should prevent this.
G. The text should be a single control with properties you set which provide different behaviors. Why do we have multiple types of controls for this; i.e. textbox, MLtext, single line text, etc.
H. MLText needs a editor.
I. The concept of look and feel could be revamped. Why not set properties like font, bold, italic, size, color, etc. all in the properties of the control. AKA Visio Studio's approach.
J. When selecting the value of a property, it needs to select the entire string, not just what is shown on the screen. Also the cursor needs to go to the end of the value not the beginning.
K. If a property is a vector, then present 3 separate boxes with up/down arrows so values can be changed by typing them in or with the arrows.
L. A blank GUI should have properties where you can set background, border, image. Not nesting of controls.
I can provide more if this is the direction you were heading?
#6
@Scott: Those are some great ideas! Keep 'em coming! It would be great if you could create a list and send it to my public email: danhopkins09@gmail.com
09/24/2009 (12:38 pm)
@OmegaDog, Javier, Todd, Russell: Glad you like it! There will be plenty of videos to come as different features are added in, so stay tuned for more!@Scott: Those are some great ideas! Keep 'em coming! It would be great if you could create a list and send it to my public email: danhopkins09@gmail.com
#7
A. Agree 100%
B. I can see where you might want to see the Tab Book outline in edit mode but it should be as unobtrusive as possible. All this is easily done in the controls render method. All GUI controls have the ability to determine if the editor is active or not, but I don't think I have really seen it used except in my own controls. And I agree with the ability to add tabs from the control it's self. There should be a way to add designer verbs to a control for design time functionality like this.
C. For the tab controls this is all handled in the controls onadd and onchildadded methods. I know the tab book prevents controls from being added to it directly and just passes them up to its parent. The same could be done to the tab page to prevent it from being added to anything but a tab book control.
D. Agree
E 1. Mixed feelings on this one. Having played around with the scroll bar control I can understand why it is separated.
E 2 and 3. They took an approach similar to CSS on the web, I think it would be nice to have a real time editor instead.
F. Again, this is handled in the controls themselves and not the editor.
G. My guess would be to not overwhelm the gui designer with things they don't need. Take a look at the code for the controls, if you can merge all of them together then post it as a resource. But I think they are linked in an inheritance chain so you may break another control in doing so. I encountered that problem when I first modified the guiTextListCtrl it broke other controls and had to write my own control.
H. Agree 100%
I. They have taken a path similar to CSS for the web. We just need a real time editor for the profiles.
j. Agree 100%
K. Would be nice, just not sure how the editor would know if the property is a vector. I have not seen any way (without hard coding) to determine what data type a property is.
L. You must have at least on control in order to render your gui as that is where the rendering occurs. This is true no matter what you develop in. If you write windows applications you have to have a form to put the controls on. In Torque you just use a control as your form. Background, border and all that could be handled nicely if we had a real time profile editor.
09/24/2009 (2:02 pm)
@Scott, I have some familiarity with gui controls and the way they work some of you items I agree with and others I understand why they did what they did. Some of it I think is just having the code moved from one engine to the next with out spending a lot of time on it. ANy way here is my 2 cents.A. Agree 100%
B. I can see where you might want to see the Tab Book outline in edit mode but it should be as unobtrusive as possible. All this is easily done in the controls render method. All GUI controls have the ability to determine if the editor is active or not, but I don't think I have really seen it used except in my own controls. And I agree with the ability to add tabs from the control it's self. There should be a way to add designer verbs to a control for design time functionality like this.
C. For the tab controls this is all handled in the controls onadd and onchildadded methods. I know the tab book prevents controls from being added to it directly and just passes them up to its parent. The same could be done to the tab page to prevent it from being added to anything but a tab book control.
D. Agree
E 1. Mixed feelings on this one. Having played around with the scroll bar control I can understand why it is separated.
E 2 and 3. They took an approach similar to CSS on the web, I think it would be nice to have a real time editor instead.
F. Again, this is handled in the controls themselves and not the editor.
G. My guess would be to not overwhelm the gui designer with things they don't need. Take a look at the code for the controls, if you can merge all of them together then post it as a resource. But I think they are linked in an inheritance chain so you may break another control in doing so. I encountered that problem when I first modified the guiTextListCtrl it broke other controls and had to write my own control.
H. Agree 100%
I. They have taken a path similar to CSS for the web. We just need a real time editor for the profiles.
j. Agree 100%
K. Would be nice, just not sure how the editor would know if the property is a vector. I have not seen any way (without hard coding) to determine what data type a property is.
L. You must have at least on control in order to render your gui as that is where the rendering occurs. This is true no matter what you develop in. If you write windows applications you have to have a form to put the controls on. In Torque you just use a control as your form. Background, border and all that could be handled nicely if we had a real time profile editor.
#8
@Everyone: As I told Scott, if you have any feedback/ideas, feel free to post here or contact me at danhopkins09@gmail.com.
09/24/2009 (2:49 pm)
@Ryan: Thanks for your feedback!@Everyone: As I told Scott, if you have any feedback/ideas, feel free to post here or contact me at danhopkins09@gmail.com.
#9
Hey, great work. Looking forward to see where this will be going.
I did the GUI editor update for Torque 3D (helped immensely by feedback from Jason Hetu) and it is exciting to see this being carried further.
I particularly like the palette integrated there into the sidebar. The new features for laying down controls also look great.
@Scott
A lot of this touches on the core GUI toolkit rather than the editor and it is so true, there is *lots* of room for improvement there. I hope to be able to get around to doing some work on this for 1.1.
09/25/2009 (12:06 am)
Hey, great work. Looking forward to see where this will be going.
I did the GUI editor update for Torque 3D (helped immensely by feedback from Jason Hetu) and it is exciting to see this being carried further.
I particularly like the palette integrated there into the sidebar. The new features for laying down controls also look great.
@Scott
A lot of this touches on the core GUI toolkit rather than the editor and it is so true, there is *lots* of room for improvement there. I hope to be able to get around to doing some work on this for 1.1.
Associate OmegaDog