RPTools.net

I have seen that rptool uses a specific license key for jide. I don't know, whether we use anything besides the docking framework from jide. Should we use another such framework for 1.4? Are we going to clarify a few questions about the modularity of 1.4 as well? Maybe a "divide and conquer" approach would allow some people to start hacking away, provided we have interfaces in place. Judging from the masses of volunteers, we should not make any stipulations with respect to OSGI etc, I think.

Well, this is going to be my 100th post and I'm commenting myself. I might have created another topic, but it is just a minor addition. I found this: https://buildhive.cloudbees.com/, where OpenSource projects could get a free integration server (Jenkins) when using Git.

I think we use a few other JIDE items(command framework seems familiar)... My guess is that in the 1.4 we will likely want to use his Editor component in addition so we get some built in javascript formatting goodness without us having to write it ourselves.

I did a grep and couldn't find anything but some simple elements. In particular, if we go for JavaFX, these could/should pobably all be replaced:

(Only main imports kept.)

I remember back in the day that Trevor didn't like the JIDE stuff for a couple of reasons, but they make for a quick and easy approach to dockable panels.

In some of the brainstorming we've done about a new UI there have been some pretty radical ideas that would definitely require that we throw away the JIDE stuff. I'm thinking of stuff like non-rectangular windows, radial menus, and so on. JavaFX might help for some of that, but to really make it work we'd need to build our own L&F layer. That's a pretty big chore and we'd need to provide support for that framework as well as the rest of MT, so I don't know that it's really practical.

I have done some "tests" on other (Swing) docking frameworks and I'd say it is still true that most are either complex or don't work correctly. (I have tested only a few, excluding JIDE.) Considering that for JavaFX no such framework exists, one would either omit it or resort to Swing. I personally would rather omit it. We could simplify the GUI with a narrow left side for "admin" purposes and a wide right side for "business" (arranged as "layers"). As a Sanity check, here is how I would sort the existing windows:
Chat, Macros (Campaign & Global), Initiative -> R; Resources, Map Explorer, Connections, Tables -> L; I'm clueless what "Impersonated" and "Selection" really do. From the little I have seen, they do not justify a separate GUI unit.

If the brainstorming is the one strewn into the forums, then I don't really see the necessity for non-rectangular windows. Radial menues would be "local", in the sense that not a global L&F component(*) would have to be implemented. The layer(*) that needs it would have to implement this itself. I don't think it has many uses besides options for tokens.

(*) I want to distinguish between "components" as part of the software architecture, which provide different technical services to MT and "layers", which may be shown to the user as part of a map stack. So technically, a layer may be part of a component.

Further Note: JavaFX is still a young technology that relies on 3D engine rendering. Expect more graphics driver issues than we have today. (I just had one with mine after 3-4h testing FX; never ever had one with Java before, neither on (any) Linux or (any) Windows.)

I've you're talking about making windows non-dockable I'm against it User.

As to "Selection" and "Impersonated", Those are the macro groups for those assigned tokens.

(I took the liberty of changing assumed typos.) I am thinking about having only two parts of a screen. An L side, which contains various tabs for administration purposes. The R side is almost like tabs but they are actually layers like in Photoshop or Gimp and in a sense, you can see all of them at the same time. Selection of visibility, editability etc. should go on the L side.) That would obviate the need for dockability, or rather everything would already be docked at a specific place.



So "Selection" shows the Macros of the selected token? Then R. "Impersonated" shows the Macros available for the token impersonated? "Impersonated" is then a special selection? The different groupings of Macros are interesting; maybe they should go L instead - maybe even separated, (As you can guess, I'm almost never using Macros.)

All just brainstorming and as that might be more appropriate in another subforum. But it is closely related to the technology we intend to use. Crossposting hasn't been invented for forums, has it?

Heh, it was early when i posted that (for me at least, woke up kinda late too).

The fact that you want things in a specific place is what i don't like. What works for you in a given place, might not work for me. What works in one game system, might not work in another, either.

For instance when i'm building maps, i dont need the initiative window open, as a player, i dont generally need resources open, but sometimes i want to drag an image i have onto the map, so being able to open it at whim is important.

What I have described is system agnostic. Basically all the generalized resources are on the left: e.g. images, network stuff. Also, L and R doesn't mean you can't hide stuff. Compare it with a Windows Explorer: treeview on the left, contents on the right. Or a painter with his palette in the left hand and the canvas at his (right) fingertips (stretching the metaphor here). The two situations you describe are still possible.

What you will "lose" are the options of dropping images into Macro windows, a resource into the network window. Stuff that doesn't really make sense anyway. Maybe it's hard to envision, but imagine a layer on your map, which shows the chat, say on the right, semi-transparent. You get some options on how much screen space you want, transparency etc. but it would never occupy the same space as resources or network logs (which you currently can do.

Unless we can make this preferential I am 100% against any hard coded "resource" locations vs a docking framework. Not counting the reduction of choice removing the docking framework without a replacement severely limits those who wish to create their own docking frames as many of the existing frameworks currently do today. Hard coding also does not take into account various screen sizes, resolutions, etc and reduces users choices significantly(some may say this is a good thing... me... not so much!!!)

Hmm, I need to check out one of those frameworks one of these days. "Hard" coding does not mean that the layout is frozen, so the remark about screen sizes and resolution doesn't hold. (Actually, I didn't mention "Hard" coding at all.) Reducing choices can reduce confusion, so while I am generally for more features, the less you see of their complexity, the better. Most people will just use Macros, not write them. And those people could get accustomed to L/R too.

Anyway, I don't see the benefit/effort ratio being particularly high for docking in MT.

Generally I agree that a well made, fixed layout (and that can be a layout that can flow/resize) has advantaged over a docking layout.

But ...

1) MT is used in very different use cases. Some play F2F with large TVs or beamer, some use it for online playing. Some use heavy macro scripting, some chat only. Some play board games, some almost mapless story games. Finding the one-for-all layout might be difficult.

2) MT totally lives from the macro frameworks (IMHO). Allowing the macro coders to create "integrated" parts of the UI makes it possible to turn a system agnostic MT into a specialized "D&D" or "DogsInTheVineyard"-Machine - or whatever. Where - in your (username) vision - am I allowed to create an interactive character sheet, a toolbar, a non-modal dialog (like we use for selection based targeting)?

Well.. perhaps it's a difference in terminology. Your original statement about left/right being the options is what I would consider "hard coding" in the sense that currently, I can set docks to not just left and right, but also top and bottom. Likewise, I can currently have two docks at the "bottom" and with some variable width in each while still maintaining a top window that draws the fill width(but of course not the height.)

I could be wrong in my thinking based upon the conversation so far, but I still believe what I said holds true(more so about screen size as it pertains to aspect ratio than resolution though!). For example, if bottom/top were not an option, I would expect that would seriously hinder people who have a wide screen monitor and even more so for people who choose to use their (widescreen) monitor in portrait mode instead of landscape. Given a 16x9 aspect ratio, restricting tabs(hide able or whatever) to only left or right could seriously affect their ability to use MapTool in the way that best suits them.

I am one such. I use MT to play with my FtF group(currently working on a top down projector stand, but have used large screen TV and wall projection in the past also.)

I haven't thought about aspect ratio, in particular portrait mode. I was understanding size to refer to your phone vs blockbuster movie screen and resolution being 1920x1200 vs 900x600 and so on.

I do as well. I was thinking of either s split screen with movable separator or "make admin invisible".

L is administration, R is "business". I guess a char sheet is business. a generic toolbar probably administration (but what do you do with the tools?) A targeting dialog would be business again (although I must admit I haven't thought through all of this).

Basically all screen real estate is divided into admin, which is shown on the left only one at a timem and the map on the right which is a stacked set of layers, which may be (semi-)transparent. So, if you want char sheets, which you want to slide around, you need a layer that contains movable objects. If you want to take this to extremis, image all windows to be part of some layer and L=Admin is empty. You would lose the "snap to dock" and even that could possibly be implemented in some layer. (That would be a docking framework through the back door, you might imagine, but with the difference that it isn't part of the basic framework.)

Edit: Maybe selecting screen division statically can serve as a replacement for docking. I.e. any change of layout would require a restart.