S/r Editor: Layout

[greebo]

Firstly I stand by what I said before that stims and responses are completely different and I would prefer them listed separately because the user will be dealing with them separately at different times, even exclusively. These are typical examples of how I might normally be working with S & R in real situations...

I get your point and I'll look into separating the dialog. I'm not terribly happy about that because it will involve similar or duplicate code and more work (all the internal GTK callback stuff for example), but I agree that this is probably clearer ans easier to use in the end. Hopefully other things will get easier as well when the dialogs are separated.

 

Furthermore, at present it seems you can convert a stim into a response and vice versa which is meaningless. If I add a response in entity A to stim B to set the property C on entity D to be the same as entity E and later hit the stim button then presumably all thoses settings are lost and the item in the list is now a stim B doing nothing and to which I now need to add a radius and other qualifying properties. I might as well change an ocean into a cabbage, losing all of its aqueous nature and then start adding vegetable properties.

When the dialogs are separated, this issue will be gone. From the entity spawnargs' point of view stims and responses are very similar and they are treated nearly identical code-wise, that's why a conversion button was suggesting itself. (As a matter of fact (it won't matter anymore anyway) converting stims to responses and vice versa wouldn't have resulted in loss of properties or anything.)

 

Right clicking to add or delete is fine but a separate add button is the more common useage. It is true that in for example, the Wndows Explorer interface one can right click an empty space in a window to say, create a new text document but there are also separate options in the file menu to select 'new' or of course in a text editor.

As already posted in another thread, I'll go for an "Add" button again. The space issue I mentioned will not be much of a problem, when the dialogs are separated, so this might be a plus.

 

I suggest that both the right click menu 'add stim' and a separate add button both call up a separate list, either a list box or a menu such as on the type button now. Whatever is used it must be dynamic so new ones can be added. A separate 'change stim' button calls up the same list but only when an existing stim is selected.

I don't quite understand what you're envisioning here. If I have the choice I avoid popping up several new windows for each action or property change, so I'd vote for adding a single "Type" dropdown field to choose the stim type (Fire, Frob, Water, etc.). First, each new dialog means more code and work, and second, I consider it bad design having popups.

 

I still think that a simple "Add" button will do the trick: Click on Add > Default Stim is added to the list > Change stim type > Change properties.

 

What do you mean about "dynamic"?

 

I think I would be tempted to do away with or disable the X close button at top right and to avoid any doubt whatsoever have two buttons 'OK' and 'Cancel' which I believe are in more common useage. 'Apply' is elsewhere used to mean 'apply but don't exit' whereas 'OK' means 'apply and exit'. While 'close' does not explicitly mean 'cancel and close'.

Let's go for an OK button that means "Save and Close" and a CANCEL button that ditches the changes and closes the dialog. The REVERT button will be removed.

[OrbWeaver]

I get your point and I'll look into separating the dialog. I'm not terribly happy about that because it will involve similar or duplicate code and more work (all the internal GTK callback stuff for example), but I agree that this is probably clearer ans easier to use in the end. Hopefully other things will get easier as well when the dialogs are separated.

 

You could use a tabbed pane (GtkNotebook) for this, with a Stims tab and a Responses tab. However, I am not yet convinced of the need to separate out the stims and responses, while it is true they are conceptually different, it is not obvious that having a single list is actually confusing or limiting in any way. Is the concern that when there are a large number of stims and responses, it will get hard to find them?

 

I don't quite understand what you're envisioning here. If I have the choice I avoid popping up several new windows for each action or property change, so I'd vote for adding a single "Type" dropdown field to choose the stim type (Fire, Frob, Water, etc.). First, each new dialog means more code and work, and second, I consider it bad design having popups.

 

I presume he means a combo box, like the current "Type" selection. I agree that having extra dialogs is clumsy and unnecessary.

 

Let's go for an OK button that means "Save and Close" and a CANCEL button that ditches the changes and closes the dialog. The REVERT button will be removed.

 

That sounds fine by me, it's exactly what I've got on the Objectives editor.

[New Horizon]

Tabbed would be a nice way to deal with it.

[greebo]

That's a good idea, I'll try that one. It may indeed help to reduce similar code sections. When using tabs, I could still use a single data manager (the SREntity) from both tabs at the same time, which is a plus.

[New Horizon]

That's a good idea, I'll try that one. It may indeed help to reduce similar code sections. When using tabs, I could still use a single data manager (the SREntity) from both tabs at the same time, which is a plus.

 

Nice.

[Fidcal]

I don't quite understand what you're envisioning here. If I have the choice I avoid popping up several new windows for each action or property change, so I'd vote for adding a single "Type" dropdown field to choose the stim type (Fire, Frob, Water, etc.).

Agreed. By 'separate list' I meant separate from the right context menu not a separate dialog - a drop down list box or whatever in the same dialog but shared by the two selectors : the right context menu and the add button. OR (as I'm not sure but maybe this is what you are doing) just the add button alone. By 'dynamic' I meant, well I think I misused the word, I meant not a fixed passive list of stims that is hardwired into your code but will include new stims as they are added. Suppose I'm stating the obvious really but it had to be said. I agree about buttons 'Save and Close' and 'Cancel' sounds good to me, and removing the revert button.

 

Orbweaver : I think the tabbed pane is an even better idea than separate dialogs; I'd forgotten about those. That sounds perfect to me. My suggestion to separate stims and responses is an organizational and conceptual one. When they are mixed it suggests a group of similar things - that there is some kind of commonality of type. There isn't. And you 'never' access them together.

 

At the moment there are already two quite distinct sections bolted together to form one dialog with a few buttons shared and two unlike types mixed in a list. It can be made to work yes but if it had started with two tabs I doubt anyone now would be wondering whether to attach the two tabs side by side so they can be seen together.

 

I suppose I've laboured the point but I was asked for my views on the s & r interface and I like to do a thorough job!

[New Horizon]

I'm already toying around with an early tabbed version. Looks great.

[sparhawk]

You could use a tabbed pane (GtkNotebook) for this, with a Stims tab and a Responses tab. However, I am not yet convinced of the need to separate out the stims and responses, while it is true they are conceptually different, it is not obvious that having a single list is actually confusing or limiting in any way. Is the concern that when there are a large number of stims and responses, it will get hard to find them?

 

I doubt that our objects will have a large number of stims. Why should they? It's not Dromed, where S&R were one of the most important mechanics, because no scripting was available. I expect that an average object will not have more then five to ten (MAXIMUM) stims. Realistically I believe that it would be even less than that.

 

What I do find a bit annoying is the motif style combobox. I think it might be better to use a listbox for the stim type to choose from, so that you can assign it with a double click. Here we might get a bigger list of types. I find comboboxes usually not very good for navigation when they contain more than a handfull of items.

[sparhawk]

I'm already toying around with an early tabbed version. Looks great.

 

Is there already a build with it?

[greebo]

Only on SVN. But not fully functional yet.

[sparhawk]

Wow!

[OrbWeaver]

What I do find a bit annoying is the motif style combobox. I think it might be better to use a listbox for the stim type to choose from, so that you can assign it with a double click. Here we might get a bigger list of types. I find comboboxes usually not very good for navigation when they contain more than a handfull of items.

 

I agree that a combo box can be awkward if you have a massive number of options (like the DoomEdit entity menu), but in this case we don't really have that many. A list box would take up more space and require more dragging and navigation to get to the type you want, whereas with a combo box you can find and select it quickly.

[greebo]

From the other thread:

 

Still adds a frob which then has to be changed but I assume you are going to change that to a selector from the add button or merge with the type button as an add/edit button? So the user will click that button, if an existing stim or response is highlighted then selecting a stim name will change it but if no existing stim is selected then a new one is created from the selector.

The plan was to auto-select the newly added stim so that the user recognizes easily that a new stim has been added to the list.

 

To be honest, I'm not very fond of listboxes being opened on clicking a button, I think one drop-down field to choose the type is enough. It's of course possible to add another "Add" button right next to the type combo box, but I envisioned the right part of the window being reserved to editing stims, not for stim list manipulation.

 

Hope also to see the properties of the inherited stims and responses even if they can't be changed. That is planned isn't it?

Aren't you seeing it already? The widgets are greyed out, but the values should be visible.

[OrbWeaver]

To be honest, I'm not very fond of listboxes being opened on clicking a button, I think one drop-down field to choose the type is enough. It's of course possible to add another "Add" button right next to the type combo box, but I envisioned the right part of the window being reserved to editing stims, not for stim list manipulation.

 

Yeah, as long as the user can easily see which is the new stim, such as by autoselecting it, it doesn't matter if it has a random type to start with. All of the other properties will start at default values anyway, and have to be changed by the user, so the stim type is no different here.

[SneaksieDave]

Aren't you seeing it already? The widgets are greyed out, but the values should be visible.

Maybe he's referring to actually seeing information in the Response Effects box. I do see greyed out entries for S/R, but nothing in Response Effects. Also, it's not clear at this point whether we can actually select the greyed out S/R entries, but it seems not.

[greebo]

This should work as well for Response Effects. You can't select the greyed out effects, but all the information is displayed in the list box, so you can see everything at a glance, event if the widgets are "insensitive".

[Fidcal]

I think it's because I'm using the beta that I'm not seeing what you're seeing. I cannot even select any of the inherited stims or responses - ie, clicking on them does not highlight them. And on added response effects I get the error message I reported before. I've never yet seen any response effects.

 

I take the point about adding providing defaults which you then change but if the item itself is not what is wanted it feels to me like asking for burger and fries and the waiter brings a hot dog with a note 'you can change this for any food item you wish.' I don't mind customising my fries with ketchup but I'd prefer to actually get fries from the start.

 

Does the selector list have to be an integral part of the selector button? I envisage the two buttons as you now have them : 'add' at the bottom left and the type button at top right but both open the same selector list. The edit button function points to the highlighted stim in the left list; the add button function points to the next place at the bottom of that list.

 

I like the idea of keeping editing on one side and the add and remove buttons on the left side. But I think if clicking the 'Add' button makes a list appear on the right it won't be confusing.

 

A compromise might be that when the 'add' button is clicked it adds a blank highlighted numbered place holder at the bottom. I know this sounds nitpicking but I just hate wanting to add a holyStim and click add and a frobStim is added. It just feels 'huh?' to me.

 

I still think the ideal is to click 'Add' and a list appears and you select what you want. When you create an entity you select from a list; you don't click 'add entity' and a zombie is created which you then change for a bucket. It is accepted that you might then change the default properties of the bucket to something else but the zombie would be something of a surprise.

[greebo]

But I think if clicking the 'Add' button makes a list appear on the right it won't be confusing.

So you suggest that the editing items on the right should be replaced with a list with the available stims and after selection the list disappears and the items reappear? Or should the list go to a new popup?

[sparhawk]

Just tested the new version and the tabs make the dialog much more intuitiv now.

[SneaksieDave]

I think it's because I'm using the beta that I'm not seeing what you're seeing. I cannot even select any of the inherited stims or responses - ie, clicking on them does not highlight them.

I dunno, I get the same. Can't select (by click, but I can arrow up/down to outline them) the inherited/greyed out fields, and can't see any effects for them.

[greebo]

Hm, maybe there are some differences in the GTK behaviour on your and my system?

[SneaksieDave]

D'oheth. Yeah there must be. The outline boxes are the most I can get, and that's with up/down arrows (the values showing are for the damage stim, of course):

[greebo]

I'm using the latest 2.10.x GTK DLLs, so maybe this has changed. Maybe we should think about upgrading those libraries, OrbWeaver?

[Fidcal]

I also just get the outline highlight on the inherited stims if I use the arrow keys but I get nothing in the edit boxes at all. see HERE. If I add a frob stim then check 'radius' then the default 10 appears but I cannot change it. Further, if I cancel and exit and re-open the dialog then that default radius shows for the inherited stims too.

 

It might just be the map I am using. I am using the fire entity in the snow map. Maybe the stim properties are just not set up here yet to get DR to make sense of it.

 

My broadband is now activated but I'd be reluctant to get that awesome 3GB plus download yet as I am only allowed 5GB a month and don't know yet how much I'll be using for other stuff! Hate to download it and find myself internet paralysed till next month!

 

As for the selector list I was visualizing a drop down box like the one now that drops down from the type button on the right. The same one could still drop down but activated by both that button and the add button. Or alternatively a pop up box. To replace the edit boxes temporarily with an 'embedded' selector list might seem odd. Hope that makes sense.

[greebo]

I also just get the outline highlight on the inherited stims if I use the arrow keys but I get nothing in the edit boxes at all. see HERE. If I add a frob stim then check 'radius' then the default 10 appears but I cannot change it. Further, if I cancel and exit and re-open the dialog then that default radius shows for the inherited stims too.

It really looks like a GTK issue. I will try to provide you with a newer package, so we can test that.

 

My broadband is now activated but I'd be reluctant to get that awesome 3GB plus download yet as I am only allowed 5GB a month and don't know yet how much I'll be using for other stuff! Hate to download it and find myself internet paralysed till next month!

The total mod size on my end is 3,5 GB which has to be divided by two ~ 1.75 GB. The largest parts are models (~800 MB) and textures (~500 MB), you could skip them if you checkout each folder separately.

 

As for the selector list I was visualizing a drop down box like the one now that drops down from the type button on the right. The same one could still drop down but activated by both that button and the add button. Or alternatively a pop up box. To replace the edit boxes temporarily with an 'embedded' selector list might seem odd. Hope that makes sense.

So if you click on the bottom left, the list on the top right would drop down? I'm not sure if that would be the expected behaviour for most users. I would lean more toward a pop-up drop-down list if it's absolutely necessary (I'm not very fond of pop-ups either as you know).