Zugg Software :: View topic - Possible to return to a more zMUD-esque package editor?

Beginner Joined: 27 Jul 2005 Posts: 20

Having just downloaded the latest CMUD beta (2.05), the first thing I notice in the 'Package Editor' is the shying away from the 'classic' interface, where it would have in the... main area... Columns of the classes/aliases/triggers/etc that could be clicked on and edited. Now, I find myself faced with a tree view which is ridiculous to navigate.

Where previously (in zMUD) I could simply click on a class and have a column list presented to me which I could scroll through horizontally in a moment, I have a massive list which I must scroll through vertically. Clicking on a class is useless - it simply has a grey screen with a few tickboxes on it.

If I am not mistaken one of the touted features of CMUD is the more efficient package editor... I am curious about two things.

1) Why would the interface be changed to require scrolling dozens of times through a massive vertical list rather than horizontally perhaps once or twice?

2) Is there any way to return to a more 'classic' package editing interface in this regard? (I know there will be at least one wise guy who will say 'Use zMUD', but please don't)

I am absolutely loving every feature in CMUD besides this one and it seems to me a very critical UI component. Truly, this is the only thing stopping me from purchasing CMUD nigh on immediately. Is anybody able to inform or assist, please?

Posted: Wed Oct 10, 2007 1:26 pm

Zugg will be the final and official answer on this but I'm pretty sure sure there won't be a return to a more 'classic' zMUD interface. I personally love the new interface, and Zugg has spent a lot of time on the new package editor.

I don't have the long lists you speak of but you can try using the search feature ( Ctrl+F ) to quickly find a class, or the 'Show Only This Class' option to narrow the lists.

I think Zugg also mentioned that this brings the package editor more in line with modern UI standards. The only other suggestion I can make is to try greater logical groupings of modules, packages etc. Personally I think it's worth it and that you'll grow to appreciate the new package editor so I say make the leap and buy it. Very Happy

Posted: Wed Oct 10, 2007 2:54 pm

You shouldn't have a "massive list" to scroll through. Expanding and contracting classes allows you to only see what's on the path to the current class. Unless you have many settings in few classes (which would've been just as hard to navigate in zMUD) or few settings in many classes (which should be improved by the treeview) anyway. There's still a search filter to help you find a specific setting quickly. I'd imagine that there's almost zero chance that the old layout will come back exactly how it used to be.

With that said, though, viewing the contents of a class in the old format is a feature that's requested quite often. Would, say, having the old view present when you select a class (which currently have a lot of empty space) help any?

Beginner Joined: 27 Jul 2005 Posts: 20

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

I like most of the new UI, but being able to see a more standard 'Windows Explorer' style view would be preferable, with the contents of a class/folder being shown in the right pane when the class/folder is selected in the left, and you'd not have all that dead grey space. It'd also be nice to be able to navigate through the tree using keys more easily (again, in a more 'Windows Explorer' style) - pressing left for example would take you to the parent folder if the current one is already collapsed, pressing right takes you one level down if the parent is expanded etc. I think the problem with doing that though was that it's in a 3rd party component.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

You can also make tabs for the classes you are working with most frequently allowing you switch rapidly between them. It is either done from the right-click in the tree view or by dragging the class up to the tabs area. Possibly even both, and it should also work for all manner of settings not just classes. I just can't remember if I ever tested it for that.

Posted: Thu Oct 11, 2007 7:32 pm

So here is a question for you...

It would be relatively easy for me to add a list of the items within a class to the panel on the right (the panel that you said had all of the grey space on it). However, if you double-clicked a setting within the list to edit, then the right panel would be replaced with the editor panel for the setting you double-clicked.

In other words, the way the current settings editor works is that you have a hierarchical tree-view of all settings on the left, and the right panel is the editor for the currently selected setting. Whenever you select a setting, the right panel changes to edit that setting.

Since a "Class" setting doesn't have many options, the editor panel is mostly grey as you noticed. I can add the list of settings within the class to the editor panel for the class, but that list would only be shown when editing a class. When editing a trigger, for example, you'd still see the full editor panel for the trigger and you wouldn't see the class list anymore.

The "Windows Explorer" user interface model doesn't really work for the Settings Editor because the purpose of the Settings Editor is to edit the contents of each setting. It would be like adding a file editor panel to Windows Explorer, allowing you to edit a file by clicking on it. The user interface model that is more appropriate is the 3-pane Email UI model. It has folders (classes) in one pane, the messages within the folder (settings within the class) in a second pane, and then the selected message (selected setting) in a 3rd pane. I've played with this UI model, but you really need a larger editor pane for settings. I've even played with the 3 column view that newer versions of Outlook use, and that still takes up too much space. It's still something I'm always thinking about, but it's pretty low on the priority list since the current Settings Editor works pretty well and has a lot of ways it can be customized as people have already pointed out.

Anyway, if adding that list of settings to the class editor panel would be useful, let me know.

Beginner Joined: 27 Jul 2005 Posts: 20

Novice Joined: 26 Apr 2007 Posts: 44

Some of us really like the view of the Cmud editor..

Posted: Thu Oct 11, 2007 8:26 pm

Luckily, this method leaves the editor as it is mostly intact. It just adds more information for those that want it, to an area that's unused.

Wizard Joined: 14 Aug 2004 Posts: 1269

Posted: Thu Oct 11, 2007 10:24 pm

A "history" of edited settings is on my (long) to-do list. So that would give a "Back" and "Forward" button like in a web browser. I've wanted this already when I double-click on an alias or variable in the script editor to view it, and then want to go back. So this will definitely get done. Probably not in 2.06, but soon.

In the later future, what I want to do with the Settings Editor is to make the various panels "dockable". So the TreeView and the Editor panel on the right would be separate dockable panels. When this is done, I can add a 3rd dockable panel (invisible by default) that shows the settings in the currently selected class. Then you'll be able to rearrange the panels however you want. For example, on a dual-monitor system, you could put the TreeView/ClassView docked on the left, and have the Editor panel be fullscreen on the right, or anything like that. This would be the most flexible way to handle the Settings Editor UI.

No timescale on any of this though.

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

I was thinking that instead of the class panel taking up so much space (and 95% of it being empty grey space) that it would shift up to occupy as little space as possible at the top and you get the settings within that class visible below in an easy to see scrollable details style view.
If you wanted to edit the setting you would double-click and it'd then open that setting in the same way as if you'd picked it from the left hand pane.

Newbie Joined: 29 Aug 2005 Posts: 5

I really think an undelete feature would be nice if you accidentally deleted the wrong one, kind of like undo.

Posted: Fri Oct 12, 2007 2:21 am

Posted: Fri Oct 12, 2007 8:25 am

Another possibility is to maintain a history table and have some way to access that. It would be easier to do but it will still require significant redesign.

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

Wizard Joined: 14 Aug 2004 Posts: 1269

Some databases natively support Undo even after commiting the transaction, and possibly lots more transactions after that, but the Undo will only work if a later transaction hasn't changed any of the objects that were in the transaction that you want to undo. So undoing a specific transaction is not guaranteed to work. (But undoing a whole bunch in reverse order would be OK.) Anyway, this requires keeping a transaction log, or Tech's suggestion, and I suspect this is all more work than Zugg wants to do right now. Actually, SQLite say:

Wizard Joined: 14 Aug 2004 Posts: 1269

Actually, that only works for fairly simple transactions, but I reckon CMUD probably only uses very simple ones anyway...

Beginner Joined: 27 Jul 2005 Posts: 20

Posted: Fri Oct 12, 2007 5:48 pm