Treeview for the texture browser

[Baal]

Something that always bugged me about the texture browser is that it doesn't show the materials in categories (like the media browser). That makes looking for a specific texture very annoying when a lot of them are loaded. I'm wondering why these are even separate windows.

 

So I would like to merge the texture viewer into the media browser (models, entity definitions, sounds would fit in there too but I don't want to be to ambitious). What do the programmers and other mappers think about this?

[greebo]

Hm, I'm wondering how this would look like? The Texture Browser is using the whole groupdialog space and the MediaBrowser is using the whole group dialog space - how would these two be combined in terms of window space usage?

[Komag]

I personally don't think it's a good idea (but I might change my mind after seeing the results).

- First reason is that you shouldn't use so many different textures anyway.

- Second is that you can middle-click a textured surface in the 3D view and this "finds" the texture in the texture browser.

- Third, even with somewhat a lot of textures loaded, I find myself able to find one pretty quickly.

- Fourth, I like just having them all tiled in there instead of spread along some tree system.

But again, I'm open to a change possibly, I just don't feel the need, and I'm sure it would be some work to program it.

[New Horizon]

Doesn't sound like a good solution to me, and as Komag says...there are quick and easy ways to find the right texture.

[OrbWeaver]

I don't really understand the problem myself -- if you want to look up a texture by category, you can use the Media Browser, whereas if you want to look up a texture by appearance, the Textures view provides this.

 

I can't immediately see the benefit of merging the two, not least because of the space issues that have been mentioned, but I would be willing to hear any suggestions of how a combined approach might behave and what improved workflows it would make possible.

[Baal]

Hm, I'm wondering how this would look like?

Like the model browser for example. I'm not using the embedded view though, where it would not really fit. I have to think about how it could be done in this case.

 

I should explain a little better:

The texture browser filters by the selected category in the tree view; by selecting the parent in the tree it would look like the current texture browser. If you select a child it only displays this category (only the loaded ones).

 

By finding textures I don't mean the ones that are already used but browsing through categories to decide which I could use. When I start something new I normally load some categories (wood, brick and cobblestone for example) and see what fits together. I never liked the way they are all lumped together.

 

if you want to look up a texture by category, you can use the Media Browser, whereas if you want to look up a texture by appearance, the Textures view provides this.

I do both regularly so switching between windows is annoying. In my opinion, GTKRadiant did this much better.

The media browser already has a preview but it's not as useful as the texture browser (to small on high resolutions, only one at a time).

 

So what I want is either a texture browser with categories or a media browser with a better preview. Obviously that would mean to merge them.

[OrbWeaver]

I think I understand the sort of thing you mean. So you might have a tree view like the Media Browser, but instead of a single texture preview widget, there would be a widget containing multiple texture previews like the Textures view.

 

It would be necessary to make sure that the behaviour of "what is previewed and when" is carefully considered to be both (1) usable and obvious, and (2) high-performance. For example:

 

1. When you select the top-level "textures" item, the preview shows all loaded textures (identical to the existing Textures view).
   
2. If you select a single texture, you get a preview of just that one texture.
   
3. If you select a directory containing textures, or a multi-texture selection, you get previews for whichever textures out of the selected set are currently loaded. Maybe wireframe placeholders could be used to indicate textures that have not yet been loaded, so it was obvious to the user.
   
4. Double-clicking on a directory in the tree view recursively loads all contained textures.
   

 

Needless to say, this won't likely get implemented for some time, but it is an idea.

[Baal]

Yes, that's exactly what I have in mind.

[greebo]

Well, for this to work, one could extend the existing Texture Browser by a toggle-able Treeview on the left side of the window. The existing textures could then be filtered based on the treeview selection.

 

Are you planning to give this a try?

[OrbWeaver]

Well, for this to work, one could extend the existing Texture Browser by a toggle-able Treeview on the left side of the window. The existing textures could then be filtered based on the treeview selection.

 

I wouldn't favour having a treeview in both dialogs; this seems redundant and could be confusing to users. I would prefer to either attempt the unified approach, or stick with the current system of entirely-different interfaces.

 

Are you planning to give this a try?

 

Not in the near future, since any time I have for DarkRadiant at the moment will be focussed on the renderer, but I might attempt it at some point if there aren't any more pressing issues.

[Baal]

The window could have 3 possible layouts:

1. Both tree view and texture view side by side.

2. Tree view with minimized texture view (like the media browser).

3. Texture view only (with a button to switch between all and currently selected perhaps).

 

If the containing window is to small the user can toggle between 2. and 3.

 

Are you planning to give this a try?

I think he meant me. Yes I do.

[SneaksieDave]

It would hopefully be a separate UI/tab the user could opt not to use at all, because if it takes up a bunch more screen space, it would disrupt a lot of users' layouts.

[OrbWeaver]

I think he meant me. Yes I do.

 

Ah, my mistake. I assumed you were requesting this as a user, not as a contributor.

[Baal]

It would hopefully be a separate UI/tab the user could opt not to use at all, because if it takes up a bunch more screen space, it would disrupt a lot of users' layouts.

It would merge the "Media" and "Textures" tabs into one and provide layouts for this tab similar to the existing ones. I definitely don't want to significantly change something others are used to.

[SneaksieDave]

Care to make a mockup? My concerns would be:

 

1. if the tabs are merged, then you have the choice of one (media) or the other (textures), but not both. Doing texture evals right now, I can definitely say I need and use both tabs. And especially the latter when texturing a map I'm working on.

2. if the new option merges them into one display, then it would require more space: you'd need the tree and the texture to show, and then there'd be no "see them all in one big page" mode, as the Textures tab currently does.

 

But my understanding might be wrong, as I haven't seen the design.

[Baal]

The new tab would have 3 layouts between which the user can switch:

1. Both tree view and texture view side by side.

2. Tree view with minimized texture view (like the media browser).

3. Texture view only (with a button to switch between all and currently selected perhaps).

 

If the containing window is to small the user can toggle between 2. and 3.

The first contains both and would look like the model browser (with the right window containing a view similar to the texture browser). You don't have to switch between them.

 

If the window is not big enough the user can switch between 2 and 3 which is nearly identical to how it currently is.

[SneaksieDave]

So, three tabs in total for the Inspector window: Entity, Media, Console

 

Media contains three buttons (?) to choose modes described above. Choosing would have to be as easy as clicking a tab (since people will go back-forth between existing Texture and Media modes), and retain the shortcuts (N, M, T, O).

[Komag]

I'm getting nervous about this!

[Baal]

I'm getting nervous about this!

Why, I haven't done anything yet.

 

Who is actually using a layout where the combined view wouldn't fit? In my case (the splitpane layout) there would be no switching anymore since the window can be made big enough. The shortcuts will of course be left as they are.

 

I just noticed that the regular layout is a bit different. I guess the people who are not happy about this change use this layout? It would have to be possible to open two texture browser windows to keep the existing functionality then.

[SneaksieDave]

Who is actually using a layout where the combined view wouldn't fit?

Me: (at least based on what I'm imagining; would have to see a mockup to be sure)

[Baal]

I'm still working on this and I have a question for OrbWeaver or greebo.

What kind of callback mechanism do you prefer? There are the GTKRadiant templates, GTK signals and boost also has libraries for this.

[OrbWeaver]

For the low level GTK callbacks obviously there is no option but to use the GSignal mechanism, but for high-level functional callbacks then you should either use a functor object which implements a defined interface, or boost::function.

 

Check out some of the forEachBlah() methods on the modules for examples of the functor pattern; I can't immediately think of an example where the boost::function approach is used.

[greebo]

I did use boost::function for the new command system framework, which basically replaced all that FreeCaller tempaltes from GtkRadiant.

 

Maybe it's easier to give useful advice if you tell us an example of what you intend to do, it's hard to speak generally.

[Baal]

I intend to do it something like this:

There's a singleton (material browser or -store) that keeps the tree store and (multiple, so that you can have texture browser and media browser windows) browser widgets. They each contain a treeview and a texture browser in a paned layout (among other things). You can hide one of the two panes or show them both (3 layouts accessible through buttons or maybe tabs).

 

The widgets need to communicate their input. I could do that through callbacks or maybe call methods on the singleton directly.

[greebo]

The widgets need to communicate their input. I could do that through callbacks or maybe call methods on the singleton directly.

Hm, I'm not still not fully in the picture - I got the part about the shared treestore and the multiple treeviews accessing them (sounds fine so far).

 

To what extent would the widgets want to communicate with each other? Is it some sort of client-server communication (treeviews are "consuming" service methods of the singleton treestore)? Or is it communication in between the treeview classes?

 

Do you have code to look at, perhaps, so I get a better idea?