5.0 Previews Thread

[Dean Roddey]

I was using the mouse mostly since it's a video and otherwise folks would have no idea what was going on. But there are lots of hot keys. I've spent a lot of time working accelerator table support, and correctly distributing hot key around to whatever is the active thing. I'm using the standard hot keys everywhere, at least as far as they are defined by Microsoft. All of the hot keys indicated in the menus of course are active, but there are others that are not in the menus.

I'm sure I'll miss some initially, and we'll take care of them once they are pointed out.

[123]

Actually, the editor will soon show the current line number in the status bar at the bottom. ... double clicking any of the entries in the build results will take you to that line ...

Very good; thanks.

You don't really want to auto-generate widget ids. Any widget with an id shows up as a target for commands. Generally you only want the widgets to which you will really be sending commands to have ids ...Otherwise you end up with a big list of meaningless ids

Understood. I assumed it was just a label and didn't realize it has another purpose (identifies widgets that receive commands).

More likely what will happen is that the right side will eventually become a tabbed window, one of the tabs ... being a 'widget palette' that just shows the widgets in z-order and displays a couple things about them (widget id, area, and type most likely.)

What I'm proposing requires no additional UI elements. Here me out on this one:

Consider having the browser display a template's widgets as child-nodes but only the widgets with ID's. List them in z-order. There's no need for a tabbed window, a widget palette, or an abbreviated list of widget attributes.

Click a widget in the browser pane on the left and it becomes selected in the central content pane and its attributes are listed in the attribute pane on the right. Perhaps allow changing z-order by drag-n-drop re-ordering of the nodes. No new UI elements are needed in this scenario.

Only widget's with IDs are listed in the browser.

[Dean Roddey]

I can't go there, mainly for reasons of fear. The tree widget (in it's resource browser guise) is already insanely complicated. That would put it over the top because that would be a completely special case scenario nothing like anything else that's going on in there. It would just be too much. Though the other scheme would require a a separate window, ultimately it would be an order of magnitude easier, and ultimately equally effective.

And really you do need to show unnamed widgets in such a palette as well, so that would work better in a separate window also, where they don't have to have a name to show up.

Another practical problem is that such a palette needs to indicate selection state, and the tree control doesn't support multiple selection.

[Dean Roddey]

I posted a new update video in the first post. This is an incremental one that shows stuff added since the previous more full overview type of video.

[Dean Roddey]

So, there's something I'm up in the air about and wanted to get some feedback on. If you've been watching the videos, you'll know that I've been working on the 'customize' stuff, which interfaces, global actions, macros, events, etc... so the stuff that you create to provide customization of CQC.

All that part of it is is to just to let you load up files, edit them, and save them. However, with things like events and event monitors, there's also the issue of which ones you want to have running, pausing and resuming and so forth.

There's a reasonable argument to be made that that is not customization, that's configuration. There will be a separate part of the tree browser for configuration, which is things like user accounts, e-mail accounts, lat/long settings and so forth. To be really consistent, it's arguable that the /Customize section should just be to edit stuff, and that there should be a separate bit in the /Configure section where you choose the events you actually want to load. Now that we have hierarchical storage for events, it's not the case that you may really want to have all of the events that just happen to be there to be actually loaded.

It would also, I admit, be technically more straightforward as well. That means that the /Customize stuff only has to talk to the data server. The /Configure bit that would control what's actually running and does pause/run stuff talks to the event server. It would be much cleaner to keep those two things separate from a technical stand point. And the /Configure bit is where you'd see status of the actual running events as well.

Does that make sense. It also has some advantages for you guys, in that just because you made changes to an event doesn't mean it will immediately get reloaded to the event server. You can make changes to a set of related events, save them back away, then go over the /Configure/Events/xxx section and do a reload on ones that you want to pick up changes.

Of course, even if I do keep the separation, there's nothing to prevent there from being a 'push to server' option in the editing section when you save changes. That's certainly doable just to save a step, but keeping editing of events vs. managing the event server itself separate would have lots of advantages.

[Dean Roddey]

I updated the first post to include a preview 10, which demonstrates all of the driver management stuff I've been working on. Here's the link to that one just to save you the time of going back to the first post:

http://www.charmedquark.com/Web2/PostIma...view10.wmv