Better dialog tools?

[Mora Fermi]

While dialog functions inherited from maptools are definitely useful, they are neither very easy to use nor very elastic. The dialog description "language", cobbled together to avoid the limitations of maptools' original macro system, is neither user friendly nor descriptive.  Add to that complete lack of control over the layout and styling, and we end up with dialogs that are somewhere between awful and atrocious. 

Now, given that we have an actual dynamic scripting language to play with, an option for a more complete UI system opens up. Since this is something I always considered a big problem with Maptools, I'd like to help, but to do so, I'd need to know your future plans.

The simplest, at the moment, would probably be to improve existing dialog functions. Starting with replacing strings with dicts (or maybe in reverse, go for xml?), improving the API should be fairly simple.

Another option would be to give access to AWT directly and let the user deal with all the complexity.

[Virenerus]

At the moment I have no plans to do something with the dialog system. But I agree that it needs work.
I think a object oriented version of the current dialog system would be a lot better then the old one. SWT should already be open for macros for users who want the full complexity / capability.

Sorry that I am not really active at the moment. At my studies I have a project ending in three weeks with big presentations in Helsinki and Stanford. Until then I won't really be able to do any work here. After that I have a lot more time and will start to work a lot more on the project. For my current plans the next features are campaign storage/macro overhaul and maybe tree based macros.

In the long run I want to modernize one window after the next, but this would take a lot of time.

Edit: For future reference I meant Swing instead of SWT

[Mora Fermi]

Can you possibly include a sample of how one would call SWT from the macro? I've been trying various combinations of things stolen from Groovy tutorials, but nothing seems to work.

[Virenerus]

Oh I am so sorry. In my last post I wrote SWT, which is a cool Java GUI library, but not the one that is used in T³. We use Swing, so naturally SWT methods should not work.

You should be able to use the normal Java Swing/AWT methods. There are a lot of tutorials about it. I now also included the simpler Groovy SwingBuilder. I wrote an example here. Further tutorials can be found on the groovy website.

Be aware that 0.3.7 is still missing the Groovy SwingBuilder. It is in the 0.3.8 (yeah. I can make a new version with only this one feature added^^ I love it).

[Mora Fermi]

That would explain things! 

I assume that you have not pushed 0.3.8 build out yet? The example you wrote doesn't work on the latest download (commit# 075bf03 ).

P.S. Can you please mark your builds with the branch you're building from? I spent several hours trying to merge your changes to my repo, only to find that the "master" branch is essentially unbuildable.

[Virenerus]

0.3.8 will be out in a few minutes.

The master branch should be totally fine. Maybe your problem is with the maven dependencies? I am always building from the tagged versions in the master branch. Other branchs only contain unfinnished work that will later be merged into the master branch. What exactly is you problem?

[Mora Fermi]

I suspect it's part of my relative lack of Git knowledge -- the result of my attempts to merge in your changes in master resulted in a tree that was lacking abeille and all related .xml files, while .java files that depended on those were still unchanged. (and my changes on top of yours were very minimal and should not interfere with this)

I've tried building the "new-serialization" tree which, aside from the "usual" classpath/Maven problems built fine.

I'll try building master branch from pristine code and report.

P.S. Why do DocCreator's compiler settings default to java 1.5?

[Virenerus]

Should be problem on your side. Github shows the albeille xml files are all where they should be.

DocCreator is only an old utility project. All it did was extract the javadoc comments from the macro API classes and post them to the website. I created the basic macro API documentation from it. It is no longer usefull and I removed it from the repo.