Adding "Unofficial" Features

[bstrdsmkr]

I came to MT bc i'm building a multitouch table and needed something with power and flexibility to serve as a face to face battlemap. I know that projector mode is nearly at the top of the wall of features, but that doesn't help me now =) I have an idea in my head of how i'd want the interface to look and while my strength lies mostly in javascript and python, I don't think its outside my capabilities to build it.

What i see when i think about how to build it and make it fairly customizable is a table containing the name of an image, a function to run when it's clicked on, an x offset (probably relevant to the bottom right corner of the screen), and a similar y offset. That way if someone wants to setup a scifi skin, they just photoshop the images, adjust the x/y offsets to reposition them if necessary. If it's done right, that could easily grow into a very flexible skinning system, if a user wants to bend MT to their will, all they would really need to do is comb the source code for the relevant function and tie it to a graphic in the table.

Obviously this isn't possible without editing the source code and making a new build. From the wall of features I gather that i'm not the only one who's anxious to see something more touchscreen/projector friendly. My question is, knowing that Trevor and etc are working on a solution that's probably way better than my hack job, what would be the best way to distribute such a beast until the real savior cometh? lol Again i'm not trying to step on anyone's toes but i'm impatient and I think a stop gap measure is better than no measure.

Feedback? comments? concerns? account banning? =)

[Azhrei]

My question is, knowing that Trevor and etc are working on a solution that's probably way better than my hack job, what would be the best way to distribute such a beast until the real savior cometh? lol

Well, it's probably quite a distance off right now. So we would welcome any "user interface testing" that you would like to implement! It might be that during your implementation process you'll figure things out that will help with what is later the final result. It's always good to have people try things out and get feedback from the community, then use that feedback to further tailor the code...

Again i'm not trying to step on anyone's toes but i'm impatient and I think a stop gap measure is better than no measure.

I agree -- go for it!

My inclination would be to first sit down with the existing code and learn how it works. Probably make some minor changes to it and see how it reacts.

Then you'll want to plot out your plan of attack: what you'll need to change and how. With that information you can post back here what your plans are and get any hints or help that the current code manglers may have for you to help accomplish it.

Code that is generic and reusable is more likely to be merged into the existing code base, so keep in mind the philosophy of programming to interfaces, using factory methods to create UI elements, and so on. Much of the current code doesn't do those things (sigh) but they will be a factor in 1.4 so you're more likely to see your code (or something like it) integrated into 1.4 if you adhere to them.

I posted in another thread about converting the toolbar buttons so they are created by factory methods so if you feel up to it that might be a good place to "get your feet wet", so to speak.

[bstrdsmkr]

My inclination would be to first sit down with the existing code and learn how it works. Probably make some minor changes to it and see how it reacts.

Then you'll want to plot out your plan of attack: what you'll need to change and how.

Well, the layout i have in mind is a quarter wheel in the corner that will collapse into a single button when not in use. When popped out i'm thinking one of the buttons on the wheel will, when clicked, pop out a quarter radial menu around it containing a button for each macro group associated with the currently selected token. Likewise, when a button for that macro group is pressed, the buttons for each group will be replaced with buttons for the macros in that group plus a back button to go back to the groups. As a result of this, Each macro will have to be able to have an image associated with it (not a bad idea in and of itself). I think someone posted about having a semi-working model very similar to this before, only centered around the token itself. I think if i can find that post again and get the hang of how that code works and adapt it, that'll give me an easy head start.

[jfrazierjr]

My inclination would be to first sit down with the existing code and learn how it works. Probably make some minor changes to it and see how it reacts.

Then you'll want to plot out your plan of attack: what you'll need to change and how.

Well, the layout i have in mind is a quarter wheel in the corner that will collapse into a single button when not in use. When popped out i'm thinking one of the buttons on the wheel will, when clicked, pop out a quarter radial menu around it containing a button for each macro group associated with the currently selected token. Likewise, when a button for that macro group is pressed, the buttons for each group will be replaced with buttons for the macros in that group plus a back button to go back to the groups. As a result of this, Each macro will have to be able to have an image associated with it (not a bad idea in and of itself). I think someone posted about having a semi-working model very similar to this before, only centered around the token itself. I think if i can find that post again and get the hang of how that code works and adapt it, that'll give me an easy head start.

Start in MapToolFrame. There area already 4 locations "builtin" for plugging in tool windows for each border. Here is an example of on such in use:

zoneRendererPanel.add(getChatActionLabel(), PositionalLayout.Position.SW);

Note that at current, SW, NE, and NW are in use, so that only leaves the bottom right corner(this is assuming you don't want to remove any functionality, only add).

Basically, if you want to add some type of thing there, you would need to pass as the first argument some subclass of Component( such as JPanel, JButton, etc). With the number of items you are thinking of adding, I would say that all of your radial menu logic should be in a new class (buttons, button listeners to handle mouse clicks, etc)
That should be enough to get you started.

[bstrdsmkr]

ok i've looked at this and toyed with the code. It looks like for nearly the same amount of work the whole gui could be separated into something that could be generated at runtime from an xml file. This is getting away from the original topic of discussion so i'll start a new thread for it.