RPTools.net

I wonder if you used the more advanced frameworks available here. If you didnt it would be helpful for this discussion if we'd show you some examples how framework designer created individual UI using frames (docked, floating).

On the other hand I might simply miss the possibilities to do so in your vision.

Whether the underlying structure is a docking framework or not is not important to me (as in the common user). But taking the macro coders the possibilities they have now would be a huge drawback.

Ditto...
As could I...

Exactly... we want to make sure that unless there is a "very" compelling reason to do so, we don't remove functionality.

Personally, I use the docking features quite heavily, even when not using a macro framework(in which I believe I use an additional 1-2 MORE dockable frames.) More to come shortly(taking screenshots and image manips)

As I already stated, I am not familiar with any (macro) framework. If you will suggest one and explain a few moves around, that'd be great. Particularly those, where you think you need the dockables. I certainly do not intend to hinder macro programmers, since in my eyes the macro possibility is one of the major reasons MT is afloat.
I just wonder whether the same functionality can't be achieved with less of a code base. (Minor look&feel and terminology clashes to be sorted out.)

I hope i can gather some screenshots and examples tomorrow.

EDIT: didnt found the time to do it yet, but its not forgotten

Sorry for the long reply.

Here is my normal layout(click to see full size view):

Attachment:

My Usual MapTool Layout thumbnail.PNG [ 145.54 KiB | Viewed 326 times ]

For me, the dockable functionality is extremely nice to have(and in my brain... critical... but that's just an opinion). As you can see, I use the pin/unpinned features, the multiple panels aggregated via tabs to a single panel, and the ability to dock to the "bottom left"( as opposed to full screen bottom).

Also, I think Aliasmask has created a "toolbar"(can't find it.. perhaps it's on his wish list), but ToyRobots has one I did find made via the macro system. I have no played with it yet, but you can take a look at the screenshots here: viewtopic.php?f=33&t=15566. Though I don't know for sure, my guess is that someone would want this "docked" along the top of their MT window(since this is where "toolbars" typically go).

Of course, custom "toolbars" as a feature could be mitigated by letting uses access the "real" toolbar via the next generation macro framework(javascript API's to the Java interface) and/or exposing some of the existing Java API's for toolbar creation via an Interface, as opposed to making them into a dockable panel.

I will let CiF expose more.. hopefully, we can get a few of the heavy framework authors to chime in also(Aliasmask, Wolph42, etc) to see if they have any thoughts based upon their existing or proposed macro work.



Another thing to be aware of is that Azhrei has already said(and I agree with him from what I take of his words) that in 1.4 he wants kind of a "mode" selection which would turn on/off(ie, visible/not visible) some of the tools based upon if you are a player or a GM. I believe he wanted this to be something of a prompt during start up with the option to "save and never ask me again". I would agree that the default layout for a brand new user is REALLY confusing(ie, what is Global, what is Campaign, etc). I would wonder if perhaps as part of the mode selection feature(assuming we keep dockables which I REALLY want to do) we should have a set of default panels and arrangement that are different based upon what mode you select. This would make it much simpler for a new person to not get overwhelmed with tons of panels that in some(many) they may not need.

As far as macro coders go, access to whatever framing is finally decided on is key. In fact, I wish there was some more control over the current environment as is. One of my biggest complaints with current system is the statsheet popup. It has a set format, doesn't accept html and floats over the main display area rather than being dockable.

The current options are to turn it off and have a toolbar that handles onSelect events where a custom frame can be viewed. I believe Rumbles framework for 4e does that. Another option would be to change the token type and use the onMouseover event to handle the alternate info for a dockable frame. Basically, the stat sheet is not displayed because a blank line is the only data returned but in the process another macro to show info on token is run.


Yeah, I keep threatening to do this, but I haven't put anything together yet.

Let me explain with a drawing on my part. All colors, fonts, etc. bear no significance - this is a case study. On the left you see (collapsed) the Admin parts. Library and Maps you also have there. The Options is a (makeshift) abbreviation for the drawing toolbar(*) And layers is for the currently semi-floating layerpane we currently have plus all the additional layers we would have. Your Chat will be on the bottom (default) or whereever the configuration/customization would allow it to be - as a layer. The initiatives I would associate with the corresponding tokens - also a separate (customizable) layer. I can't see the semantics of the Selection pane, besides what Ctrl-A and Ctrl-TAB couldn't handle. The Campaign Tab contains global Macros, right? Since I don't know, what they do, I can't really say. But if they are rather associated with the selected token (like the few I wrote), I would have them appear next to the token, like initiative. If they are associated with, say, loading a campaign but passing it through a filter before, it would be on the left.

(*) Toolbars are an interesting topic. My current preference would be to have them out of the way too. But even if not, something has to happen here. The default drawing, etc. tools do the strangest things if you are not very careful and together with the missing Undo functionality have caused the biggest loss of momentum in my games. (I'm vain enough to suppose I'm not the only one.) On the other hand, well-designed toolbars are useful.

I haven't read anything about the almighty Javascript engine that allows access to almost everything. I fully favor Javascript for the scripting engine and would also like to provide access to objects currently inaccessible. But it's not like this is just a switch in Java7, there's work to do.

Regarding stat-sheet popup: that would also be also be solved in the way I depicted.

In fact, I now believe that the general access to more and various features requiring "windows" is in opposition to a docking framework, which does not allow overlap and transparency. Docking allows tidy desktops for elements that are not supposed to share space. If you rather want to share space that's not good.

I hope, I'm getting my point across. From a personal point of view, I fully understand your concerns. I still remember the time when I first found out that Windows did have "yank", it just called it "paste". And what an odd word that was for the task. And why on earth it was associated with Ctrl-V. Even today, I don't think those are really good ideas, but they work and I understand them. So while I don't want you all to agree with me, I have the feeling that you're still looking for the "yank", all the while it's there but called "paste".

Final note: All of the above should have used the subjunctive form. Where it doesn't: it's still my vision (as CiF called it) only. Not a roadmap for MT 1.4 or 2.0.

So, I sampled three, hopefully different examples of existing frameworks. Two made by me, one by Rumble.

Lets start with Rumbles BoL (Barbarians of Lemuria IIRC) framework. It has low automation (as in GM and PC have to handle stuff by hand) and is classic, as in token related macros are on that token. GM macros are campaign macros. There is a tool/button bar for most important functions.



Next my heavily automated savage worlds framework. All data and action is based on the character sheet. There is a frame that holds all combat related macros (switching of states, advancing initiative, run reload) and a target selection frame.



Last example is something quite different. It is my framework for the indy game Dogs in the Vineyard. Its a story game and it resolves conflicts by throwing a pool of dices (traits gives you more dice) and raise&see in a poker-like narrative "discussion". All the traits used to fill the pool are shown on a character sheet and your dice pool and all functionality to raise and see is in another frame. For the GM it is interessting to open different char sheets and pool windows at the same time for different tokens/characters.





I dont believe that dockable frames are the only way to achieve this flexibility. If I - as macro coder - can place my content on a thingy you call layers, its all fine by me. I dont think that macros are easily stored in context menus (maybe radial?), because the space is pretty limited. I might have, in a complex framework, lots of macros on a token, easily 20 or 30. Have them all float around my macro would be horrible clutter. I can see this done right, too ... this comes down to details.

Btw ... there was a huge thread about UI changes some time ago where a lot of cool ideas happened - stuff like corner menus, radial context menus, transparent layers, ... . Have you (username) read that?

I do like the ability to place my framework windows tidily on the screen edges (eg character sheets) or have them floating (eg toolbars or dialog-style windows like click based attack dialog). I tend to use different layouts for different frameworks and it does matter if i play or GM.

EDIT: oh, if you have questions to how the frameworks are used, feel free to ask. I think it is important to get a good grasp on the workflow and the screenshots might not suffice.

Some of this I have to think about a bit, so here's just a quick answer to some points.

I read some of it, maybe even most, but the threads are huge. I don't recall what corner menus are.

I would see that at least one layer is dedicated to macros. In fact the component framework coinciding with layers for a large part would allow to easily add new layers. But I'm afraid there hasn't been too much effort spent in analyzing the semantics of MT 1.4/2.0. The only "decisions" were made on JavaFX and OSGI (neither set in stone as I reckon). But if we start to mix Swing and JavaFX (where there is no docking provided), we are mixing even more technology without having semantics.

And work on 1.4 is not really commencing as far as I know. RL life has most DEV in a tight grip and from what I know about real life, it doesn't really let go. So as I am prototyping what I wrote above as getting used to JavaFX, I wondered how we can share the burden. One way would be to externalize certain functionality to be provided by those that need it. But you would still need the facilities to do so. So I'm saying: you get a layer and place anything anywhere, similar to designing an HTML page. And if you needed to snap things to the edges, that'd be your problem - the "tools" be in place.

My vision is this: create layers each for

• Background
• Vision blocking Objects
• Tokens
• Fog(s) of War
• Grid

They may be interdependent. Additional layers would be

• Drawing
• Chat
• Macros/Framework

But that should suffice for the subject we post on.