• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Question - IDE Why is Room properties a docked tab?

DeScruff

Member
- Please excuse me if I'm not using the proper terminology for various areas.-
Something kinda struck my curiosity, and thats why is the 'Room Editor' a "docked tab" (like the Resource tree) rather then just attached to the Room workspace tab? - (Kind of like the 'toolbox' in the sprite editor)


I just ask cause Im not sure why you would need to edit the room properties while not looking at the room. Kinda like how I don't need a paintbucket when I'm editing code ;)

But maybe one of you has a reason to have this tab around while doing something else, and I'd be interested to hear it.
(EDIT: Higher resolution image)
 

gnysek

Member
I think it would be great, if room editor tab can be docked inside room editor, not inside IDE globally.
 

Mike

nobody important
GMC Elder
We've played with several ways of doing this internally, but they just didn't work correctly. We're aware that the current solution isn't great, and at some point we'll find a solution that works, but until we do find something we're all happy with internally it'll be stuck like this I'm afraid.
 

csanyk

Member
This is an issue that I've noticed as well; I find that a docked Room Editor for some room often is left at the top when I've switched focus away from the room to something else in the current workspace, taking up space that could otherwise be used by something more relevant in the current context.

Seems to me the room editor should attach itself to the room, but if the entire room editor floated inside a workspace it'd be space inefficient as well...

Designing UI/UX is hard.

I'm glad to hear from @Mike that YoYo are aware that it's not ideal and are trying to come up with better, at least.
 

gnysek

Member
Same as those panels on room properties are sometimes so little, you even cannot read header of them. Somebody forgot to put "min-height" on them.
There's loot of room to optimize room panels positions yet (tilesets too).
 
Z

zendorf

Guest
This is why the far left property panel needs to become context aware and auto change depending on what tab you currently have open. When you are editing a room it should change to displaying the room properties, when editing a sprite it changes to the sprite editing tools and when editing a script you just see the resource tree. If there are times you want to override this, then you can use a lock icon on this context aware properties panel so that it doesn't auto change. Additional panels(or duplicates) can also be tabbed next to it or on the right hand side as desired.

And if you do go in that direction, we also need another context aware tabbed window for instances in the room editor that allow for multi selection. There needs to be a way of editing instance properties without the current scaled multi-window madness that currently exists. It has gone backwards from 1.4 in this respect.

And to the OP, the best arrangement with the current IDE is to dock the resources and room editor next to each other on one side (I use the left side). The good thing about doing this is that if you are editing a room, the room editor properties becomes the active tab and if you are in a workspace the resources tab becomes the active tab. This also frees up a lot of space on the right hand side of the interface. So, in this respect there IS some context awareness to the panels, but obviously it could be better.
 
Last edited by a moderator:

Mike

nobody important
GMC Elder
This didn't work, we tried this early on. Having the dock appear and disappear was very visually jarring. On top of this, because the left side actually moves the contents of the workspace (it doesn't cover it), it means the entire contents shift, and again it looked seriously nasty.

These things are in the dock so they could be dragged out, this was especially important for the tile window. This lets you move it to another monitor and fill it up with tiles so that when in full on editing mode, you've got a large space for editing the room.

We are in agreement that it would be much nicer if it were inside the room "tab", so that when you moved the tab the docks go with it. But the way we tried, it just didn't work. We're not giving up, we just need to try and work out a better way.
 
S

Storyteller

Guest
could this be an option for the user to select?

One of the first things I do, is dock my resource tab and room options on the left hand side. A more context aware and 'pinnable' system would be good, though I see the trouble. Making as much of the UI a user selected option, is probably the way to go.

personally, being able to drag room properties into the room would be ok, though I feel once Ive gotten more used to the workspace mentality I will begin to save layouts for different tasks. A context aware setup, would help in some regards, but rearranging my layout if Im jumping over to another tab briefly would be terrible. Again, Id go for a user option wherever possible.
 

Mike

nobody important
GMC Elder
Sorry, we can't in this case. I'm all for user options but it had other more technical issues that also made it not work.
 

GMWolf

aka fel666
One solution would be a complete IDE rewrite, such that it is built out of panels.
Each panel could be subdivided into 2 panels, recursivly.

So the whole IDE would be a single panel.
You could split that in two to have a bottom panel, and the toolbar up top.
Split the larger bottom panel in to to have the resource tree over on the right, and the workspace occupies the rest.

When you open a room, it would split that panel with the properties on the left and the room on the right. When you close the panel, both go.
Something simmilar to Blender3Ds design - Its increadibly modular.

Of course this will never happen, as a full rewrite is obviously not what YYG is looking for.

Alternatively, make all tabs belong to the current tab. So the room editor would have its own sets of tabs, the the workspaces would have its own tabs, etc.
That way if you switch back to the workspace, only the workspaces tabs show.
 

csanyk

Member
Alternatively, make all tabs belong to the current tab. So the room editor would have its own sets of tabs, the the workspaces would have its own tabs, etc.
^^^THIS.

I've advocated for this as well. The "workspace" should be an entire tab in the IDE, and the tab should include all the dockable regions, not just the central main region. That way when you switch between workspaces, everything that's being displayed in the window should be relevant to the context of the current workspace, not some other workspace that you just left.

This would go a LONG way to making workspaces work better, as well as help with the feeling I get that the interface is cramped. The workspace UI feels more cramped when it's displaying dock regions that have nothing to do with the current workspace, but are leftovers from the previous workspace I was just doing work in.
 

Mike

nobody important
GMC Elder
see above. I've already said above that we agree that the room docks should be inside the TAB if at all possible, but that when we tried it, it just didn't work. The layouts were just wrong. What was once a single click suddenly became several. It looked great, but just didn't work. We will come back to it at some point though, because it's not "right" the way it is - we know this.

In terms of the "splitting" UI. This is how the debugger works, and it's fine for raw code, but nothing else which is why we never did it for the IDE.
 

GMWolf

aka fel666
Something that would be great (and, I presume rather easy to implement, unless its already a thing, that is), would be to have keyboard shortcuts to show/hide single tabs.
Like, perhaps Ctrl plus arrow keys, or single keys like R to show/hide resource tree, and T for the left panel.
 

Mike

nobody important
GMC Elder
again..... we had that, but it just got in the way, especially when editing code (which is usually when you want them), where these kinds of key combo's are used for other things.
 
S

Storyteller

Guest
@Mike out of curiosity, doesn't work as in it caused bugs/code errors, or doesn't work as in usability testing?
just wondering.
 
Z

zendorf

Guest
I can't help but think that having a resizeable split half way down the resources tree would help alleviate some issues. As can be seen from the screenshot in the first post, you rarely need to see the full length of the whole resource tree. If it was split halfway down(obviously it could be resized) with the lower section dedicated to anything that needs to be context aware such as instance properties when in the room editor or the object properties/event list when you are editing code.

Most 3d applications tend to have a split in their explorer/outliner with properties below. There is no perfect solution but this does mostly work and though this properties area can get cramped, having it tabbed (horizontal or vertical) gives quick access to numerous properties. Have a look at Cinema4D for a good example of this. I have been using it for 10 years and never feel like I am fighting the interface. All windows can be docked or floated at will , but most of the time the standard setup works very well. It is renowned for being the easiest 3d application to use, largely because of this refined interface.

 

Mike

nobody important
GMC Elder
You can already do this. Drag in a dockable window to the resource tree and you'll get a split.
 
S

Skywolf

Guest
@ Mike,
After skimming through here and seeing "we tried that and it just didn't work" several times, I have to ask.. Who is "we"?
These alternate suggestions didn't work for those of you designing the software, but this is a beta, and isn't the point of a beta (at least partially) to get feedback from users outside if the office?

Ie... Maybe I would have much rather worked with the 3extra clicks then having the room properties perma docked. But because it didn't work for "we"..
I've already said above that we agree that the room docks should be inside the TAB if at all possible, but that when we tried it, it just didn't work. The layouts were just wrong. What was once a single click suddenly became several. It looked great, but just didn't work
 
Z

zendorf

Guest
You can already do this. Drag in a dockable window to the resource tree and you'll get a split.
Aha, I had no idea you could do this, I thought you could only add new tabs...very nice! So now I can have a second resource tree above the layers pane, which works really well. Now, if only we could dock ALL windows (objects, events, instance properties, creation code window, etc.) we would be cooking with gas :)
 
Last edited by a moderator:

Posh Indie

That Guy
@ Mike,
After skimming through here and seeing "we tried that and it just didn't work" several times, I have to ask.. Who is "we"?
These alternate suggestions didn't work for those of you designing the software, but this is a beta, and isn't the point of a beta (at least partially) to get feedback from users outside if the office?

Ie... Maybe I would have much rather worked with the 3extra clicks then having the room properties perma docked. But because it didn't work for "we"..
This is why I have given up on giving feedback/requests and instead rely on questions like, "Will this ever be updated?" and "Are there any plans to implement this?"

Feedback/request responses always come off as, "We know what you want better than you do, and we know when you want it better than you do. You asked for [topic]? You don't want that now. We will add what you really want instead because you are just confused as to what you really want. You're welcome."

I mean, reading over these forums it is painfully obvious that with all of the feedback/requests, what we all REALLY want is the image editor to be consistently updated with the highest priority.

The reasons usually come off as, "Because of reasons".

This is my interpretation of this entire thread, up until now:
"Why is this like this?"
"Because. It doesn't work the other way."
"How doesn't it work?"
"Because it doesn't."
"But what if we do this instead?"
"It doesn't work. We tried literally everything already. It's unfortunate, but we know this is the way you want it to remain until a better option comes along."
"But why doesn't it work?"
"It doesn't look pretty."
"But how would we know if we never saw it?"
 

Mike

nobody important
GMC Elder
What are you talking about?

We take and implement feedback all the time. How about "Because of reasons" meaning; I don't want to have to do an indepth discussion of 3 years of development history, along with videos that will show and demonstrate the various issues every time something like this comes up? If we've tried it in the past, we'll say so. If it's an easy reason to describe, we will. If it's a more indepth reason then we probably won't because it'll take ages and we have - well, work to do.

And I can't tell if your image editor jibes is sarcasm or not. We've taken a survey of requests, and we've prioritised them in order, and are now implementing them - what more could you want?
(aside from I want it NOW! NOW! NOW! NOW! NOW! NOW! NOW! :) )

Feeback is incredibly important, and we do spend time reading it. But if you don't want to provide it, then that's up to you.

M.
 

Posh Indie

That Guy
What are you talking about?

We take and implement feedback all the time. How about "Because of reasons" meaning; I don't want to have to do an indepth discussion of 3 years of development history, along with videos that will show and demonstrate the various issues every time something like this comes up? If we've tried it in the past, we'll say so. If it's an easy reason to describe, we will. If it's a more indepth reason then we probably won't because it'll take ages and we have - well, work to do.

And I can't tell if your image editor jibes is sarcasm or not. We've taken a survey of requests, and we've prioritised them in order, and are now implementing them - what more could you want?
(aside from I want it NOW! NOW! NOW! NOW! NOW! NOW! NOW! :) )

Feeback is incredibly important, and we do spend time reading it. But if you don't want to provide it, then that's up to you.

M.
Mike said:
Sorry, we can't in this case. I'm all for user options but it had other more technical issues that also made it not work.
Other more technical issues that made it not work? As long as we're being fully transparent about it so it doesn't sound like a response drawn out of a hat... sounds like, "Reasons, my friend. Reasons." Never asked for videos and 3 years worth of coverage. Just more than, "We did it. Didn't like it. Next?"

Trying not to be overly critical of you guys, but so far the vibes I personally get are, "Yeah, whatever." whenever something comes up (Especially for the power users). And sure, you guys do listen to feedback. I bet if I made an image editor request it would be in the software as of yesterday.

I am not being a "Now! Now! Now!", guy, by the way. Remember. I gave up on caring about giving feedback/requests because I have resigned myself to, "It'll never happen anyway", so I am effectively not asking for anything right now, haha. Will I continue asking if things will ever get implemented or updated? Sure. I know the Gods on Mt YoYOlympus will either say, "Maybe" or "Not happening" which at least lets me know when things will NOT be implemented.

Your survey of requests? When and where was this done? (Serious question, actually. Would I be able to see the priority listing, by chance? If I can see it, all my questions will be answered and I can disappear for a while, haha)
 
Last edited:

Mike

nobody important
GMC Elder
Wasn't a case of "we did it, didn't like it". As I said above, I totally agree that the current room editor docking isn't ideal, and we want to put it in the tab, but the design and implementation we tried just didn't work - not technically, but from a usability standpoint. Just felt horrible, to the point of being unusable. We'd planned it all out, designed it, it looked really nice. But when we tried the finished result, it was horrible - utterly horrible.

This isn't to say "well that's it, we're not doing it". Just that we need more time to sit and research a little as to why it didn't work so we can make it work the way everyone would like it to.

We're not going to throw things in that simply don't work right, just because we spent weeks doing it.

We'll be doing a new road map or something like it soon (I hope). Just need time to get it together. Not sure about the results, we'll need to discuss internally about releasing them - will ask.,
 

Posh Indie

That Guy
Wasn't a case of "we did it, didn't like it". As I said above, I totally agree that the current room editor docking isn't ideal, and we want to put it in the tab, but the design and implementation we tried just didn't work - not technically, but from a usability standpoint. Just felt horrible, to the point of being unusable. We'd planned it all out, designed it, it looked really nice. But when we tried the finished result, it was horrible - utterly horrible.

This isn't to say "well that's it, we're not doing it". Just that we need more time to sit and research a little as to why it didn't work so we can make it work the way everyone would like it to.

We're not going to throw things in that simply don't work right, just because we spent weeks doing it.

We'll be doing a new road map or something like it soon (I hope). Just need time to get it together. Not sure about the results, we'll need to discuss internally about releasing them - will ask.,
Yes. A better roadmap. I can get behind that. As far as that is concerned, I, personally, would not even expect super accurate timeframes (That would just be painting a target on your backs). It would just be nice to see what bigger features are in planning and the general ordering on them.
 
Top