New Tool Announcement: AgeCreator 0.0.0 pre-pre-pre-alpha

[Branan]

I haven't released a new build yet, but I've got some slight GUI modifications in trunk that I think make things much more streamlined. Anyone building from SVN: please give me feedback.

[diafero]

It works fine here, but there's one thing I find confusing: I imported some random age to test stuff (I'm not a modeller, but I like to know what's happening ), and when I hit "add spawn point", nothing seemed to happen. I had to think twice (and add another spawn point) before realizing that it obviously does NOT ask me for a name, and that the new object was added at the far bottom of the list. Adding an object should definitely select it in the tree view. Optionally, it might be less confusing to ask for the name while we are at it, as most of them time one will want to change it anyway. Besides, that's what people are used to when they create a file (ok, on some file managers it says "New File", but the view is in edit mode and you can type). If you can change the tree view so that one can edit the name directly in there, these two can be easily combined.

[Branan]

Thanks for the feedback, I'll see about making names editable in the object list.

Now I'm not entirely sure I need the properties panel at all. HMMMMMMM...

[diafero]

What other way do you envision to change options like activators, the type of a region, responders and all the other things that are NOT modelling when building an age?

[Branan]

I'm not entirely sure yet. But there are so many options I'd be worried that an object with physics and a complex modifier would make that panel unruly. I may go back to dialogs for object properties.

EDIT: specifically, multiple dialogs accessible through a right-click menu, for different classes of properties.

EDIT2: Something like this

[Branan]

One other thing about new objects and usability - when the 2D draw interface is in place, the new object will be clearly hilighted there, as well as the just-commited selection of the object in the list view.

[diafero]

Adding objects is nice now . I wonder what all that free space will be used for...
Some usability notes (please tell me if you prefer bug-reports in google code instead of forum posts):
- The "Windows" menu still allows you to select the "Object Properties" editor
- The tree view items don't yet behave quite as expected. For example, I would expect the F2 key to trigger edit mode, as well as clicking on the item twice slowly (as opposed to doing a double-click). Besides, hitting Enter should accept the change I made, while Esc should discard it.

[Branan]

Adding objects is nice now . I wonder what all that free space will be used for...
Some usability notes (please tell me if you prefer bug-reports in google code instead of forum posts):
- The "Windows" menu still allows you to select the "Object Properties" editor
- The tree view items don't yet behave quite as expected. For example, I would expect the F2 key to trigger edit mode, as well as clicking on the item twice slowly (as opposed to doing a double-click). Besides, hitting Enter should accept the change I made, while Esc should discard it.

• That's an oversight, I'll remove it from the menu
• F2, return, and escape all work correctly for me, as does double-click, at least here at work on Vista using my R50 snapshot build. I'll test on Linux and XP when I get home. Two slow single clicks is an easy change, I didn't enable it because it's not really "standard" - some apps and OSes use it and some don't.

For now I'm rather indifferent to bug reports vs forum posts... Bug reports are easier to track, but so far it's been mostly small things that I can fix quickly, so tracking isn't really an issue yet. When things are more fleshed out and the bugs are uglier, Google will be a must. You might want to start switching over now to get in the habit

[diafero]

Weird, I could have sworn these keys did not work, but they do now... I take this as a sign I should go to bed early today

Two slow single clicks is an easy change, I didn't enable it because it's not really "standard" - some apps and OSes use it and some don't.

I can't comment about Mac or Gnome, but I got used to it because it works on both KDE and Windows. I would expect that Qt behaves "standard" on each platform per default (they usually do quite well on that), so how does plain QTreeView work?

When things are more fleshed out and the bugs are uglier, Google will be a must. You might want to start switching over now to get in the habit

I am already training that by annoying Zrax with tons of reports for libHSPlasma

[Branan]

I can't comment about Mac or Gnome, but I got used to it because it works on both KDE and Windows. I would expect that Qt behaves "standard" on each platform per default (they usually do quite well on that), so how does plain QTreeView work?

I don't think I changed the edit triggers from the defaults, though I may have and just forgotten, what with all the other work I was doing poking at the TreeView stuff. I'll double-check it.

EDIT: confirmed in source and ui files I didn't change anything, this is the default. I'll enable slow-click editing for now and make it configurable once configuration stuff exists.