Topic: PLEASE VOTE - New Editor features: Submenus and branched Wizard

[Monsieur OUXX]

I'm currently working on the following enhancements:

1) Enhancement #1: Submenus

The menus system of the Editor is pretty basic: You can only have one drop-down menu per item in the main  menu. In other words, there can never be more than one level in any menu.
this is what you see below with "File-->Open".

After I'm done, it will be possible to add a submenu in a menu. this is what you see in the example below with "File-->Print-->SomethingElse".



2) Enhancement #2: Branched wizards

In the Wizard class, one can only do "Next" and "Previous", but your choice in a pane can never change what pane will be displayed next. their order is only based on their index in the wizard panes' list.

After I'm done, here will be a possible use case:
You have 4 panes in your wizard: A, B1, B2, and C. On pane A (the first pane of the wizard), the user can choose between option "1" and option "2". then he clicks next. If he chose "1", he will see pane B1. If he chose "2", he will see pane B2. When he clicks Next again, he will see pane C.

A --> B1 --> C
or
A --> B2 --> C

[icey games]

Just curious, do you think it's possible to add layers to the rooms? You know, like how PS has layers for a picture document. I had some ideas before of how it would work for a game and I can only get ideas when I come to the point in the room editing when I need the layers.

The only thing I can come up with now is, over lapping walkable areas. The ability to turn them on/off would still work. This is best for birds eye view games such as GTA advance where as when you walk under a bridge. You can make a walkable area that goes straight under the bridge but wheat about when you need to walk on top of it? You can turn off the walkable area on the ground but it will cut off a part of the bridge at the point where it intersects. Thus stopping the player from running all the way across.

[monkey_05_06]

That would require massive changes to the engine, not just the editor. I just want to make sure you're aware of that.

Adding layers for the various room areas/masks is not a bad idea, but it's not an insignificant amount of work, nor is it a "minor" revision.

As for the present time, you can create another walkable area in that scenario for the overlapping areas. It's not as simple if you have scaling, locked views, or other things, but not impossible.

Oh, and this really has nothing to do with this thread.

[Monsieur OUXX]

Noctis, please do not pollute this thread. This is a thread with a very specific purpose. I'm not here to suggest changes, I'm here to report two minor changes I've done.

=======

PEOPLE, PLEASE VOTE TO GIVE ME ACCESS TO THE SVN REPOSITORY
CJ said I need to be peer-reviewed before those 2 changes can be committed. Please drop a small message if you think those 2 enhancements can be of any use, or if they should be left out.

[sonneveld]

How about you produce a patch first?  Let us see what you're changing.  I don't have any sort of vote in these things but I don't think yelling is going to help.

[Monsieur OUXX]

How about you produce a patch first?  Let us see what you're changing.  I don't have any sort of vote in these things but I don't think yelling is going to help.

I'm not yelling, I'm making the message visible, as the official procedure hasn't been decided yet, therefore making this vote unusual and easily confusing for contributors.
I didn't know it was possible to submit a patch, it's CJ himself who suggested this procedure.
Is it common practice to make a patch out of source files rather than compiled files? That sounds awkward.

[sonneveld]

I didn't know it was possible to submit a patch, it's CJ himself who suggested this procedure.
Is it common practice to make a patch out of source files rather than compiled files? That sounds awkward.

Oh yes, if anything, it's much better to produce a patch for text files since you can easily see what's changed.  A single patch file can be emailed without needing svn commit access.  See http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-patch.html (I'm assuming you're using tortoisesvn and on windows)

[Monsieur OUXX]

Oh yes, if anything, it's much better to produce a patch for text files since you can easily see what's changed.  A single patch file can be emailed without needing svn commit access.

Yeah OK, then who should I email the file to ?

[Calin Leafshade]

The editor enhancements have mainly been handled by Tzachs and I.

Either of us would be happy to review your changes and see if they are worth integrating into the dev branch

[tzachs]

Are the changes to be used by plugin creators, or is this simply infrastructures for future development?
Are you planning on using those code changes for features yourself?

Basically, if the improvements are actually needed and used, then it's great, but if it just something for future potential development, then my main concern is having untested code in the system. If this will be something employed by others too then the code might get bloated and we will have trouble identifying the actual used and important code from the rest.

[monkey_05_06]

I'll check in anything, forget these guys, send me a PM.

No, seriously, I was joking. I do have SVN check-in access, but I agree with tzachs. Useful, yes, but only if it's being used.

[Monsieur OUXX]

OK, so:
- at first I said I'd use this in a new feature, and I was answered that I'm going way too fast.
- So I said I wouldn't use it, and would just add it to make the Editor's code more flexible, and now I'm being told that if it's not used, it's useless.

Seriously. It's just submenus. You see that in every application in the universe.
And it's been tested, since I've created a dummy submenu.

So what should I do now? In the meantime, people are compliing C++ assembly classes and porting stuff to Mac, and I can't even commit a bloody submenu.

===========

EDIT:
I didn't see that post, only tzachs' and Monkey's.

Either of us would be happy to review your changes and see if they are worth integrating into the dev branch

Calin, I'll send you a patch file in PM.

To answer tzachs' and monkey's question: I haven't decided if I'll use it myself, but it can totally be used by plugin developers: If they want to add several entries in the menus without bloating them, they can group them in a submenu. For example, imagine if features "check out" and "check in" were grouped under "source control" -- monkey wink wink nudge nudge -- that would be cleaner. That's just an exemple, I'm not planning on developing a source control plugin, by the way.

[monkey_05_06]

It would help if I understood SVN or more recently I've looked at git. Proper C# bindings for either have been somewhat eluding me (missing/incomplete features/functions, etc.)...wink wink.

Of course we know what submenus are for, and I don't object to the editor having such a feature by any means. Even a useful feature such as this isn't always heavily utilized though, making it seem less useful.

[Monsieur OUXX]

Even a useful feature such as this isn't always heavily utilized though, making it seem less useful.

Well for example when I see entries in the "File" Menu like: "Game statistics", "Make template", "auto-number speech lines", etc. ... I could see them being moved to a "Tools" menu (like it's done in most apps) and then within this Tools menu, subdividing things into "stuff related to dialogs", etc. for example I could see a submenu with "Auto-number speech lines", "Create voice acting script", where the external plugin "Dialog manager" would also nicely fit.

[DoorKnobHandle]

Submenus only make sense from a design standpoint when you have a LOT of menu items that also share strong logical connections in groups (otherwise you just turn a 2 click action [file->save] into a 3 click one [file->submenu->save], actually making the interface worse instead of improving it). I know this is not what you want to hear but there is no reason to add this to AGS as there is only a small number of menu actions anyways, nor is there any reason to assume this will change in the (near) future.

That's my opinion, not sure if I have a say in this!

[Sslaxx]

Even a useful feature such as this isn't always heavily utilized though, making it seem less useful.

Well for example when I see entries in the "File" Menu like: "Game statistics", "Make template", "auto-number speech lines", etc. ... I could see them being moved to a "Tools" menu (like it's done in most apps) and then within this Tools menu, subdividing things into "stuff related to dialogs", etc. for example I could see a submenu with "Auto-number speech lines", "Create voice acting script", where the external plugin "Dialog manager" would also nicely fit.

Honestly, the "Game statistics" option and "Auto-number" item should be under a separate tools top-level menu anyway. Placing them with the existing build menu items would work best.

[tzachs]

- at first I said I'd use this in a new feature, and I was answered that I'm going way too fast.
- So I said I wouldn't use it, and would just add it to make the Editor's code more flexible, and now I'm being told that if it's not used, it's useless.

It's not like we're a formal institute. Different people have different opinions, and none of us have any authority... it's just an opinion.
If it's in any way been a de-motivator then I apologize, I was just raising a small concern, nothing major.
I'll shut up about small issues like this in the future, since keeping people motivated to contribute is much more important.

[Monsieur OUXX]

Well apparently submenus don't seem to interest anybody.
But still, I'll push them forward, as I'm definitely convinced that they could come handy to someone developing plugins and not wanting to bloat the existing menus with their new features. Also, I've got a feeling that new features will flourish in the editor itself in a near future (I could already count 2 parallel branches, other than mine).

I still didn't have time to do the "diff" file but I'll do it soon.

[RickJ]

I think both features are reasonable additions.  Since Monsieur OUXX has already implemented them I see no reason why they should not be included.   

[Monsieur OUXX]

I think both features are reasonable additions.  Since Monsieur OUXX has already implemented them I see no reason why they should not be included.   

at the moment I'm thinking of a way to add them as plugins. That would create less fuss. However I'm not sure the GUI objects are sufficiently exposed at runtime.