-
Notifications
You must be signed in to change notification settings - Fork 259
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for transparent HTML overlays #1425
Comments
For #1 I'm thinking we could add parameters to Parameter Parameter Parameters |
Could we utilize the current "docking" and add a button that removes the window decorations (and allow for transparent backgrounds? And maybe under Window menu -> Custom (or better name?) we show all the current window dialog frames and allow for the window decorations to toggle and or close the window? |
@JamzTheMan I assume the reason for using docking frames is to let the user move their UI overlay elements as they wish using the mouse? |
Yes, that and it would always center, snap and fill automatically (and reload on campaign load), Although not sure about "click through" to the map will be a problem or not? You get some built in stuff, although, admittedly it couples the functionality to the existing docking framework which we would eventually get rid of. I'm ok with your suggestion as well, just tossing out ideas and seeing what sticks. |
Seems to me it would be helpful to implement the
I think I've figured how to pass mouse events to the I like the idea of the user reorganizing their UI as they wish by moving the overlays around. If the overlay is movable, how should the overlay behave if the map is resized, for example if a frame / window gets docked or undocked? If a frame is docked and the overlay doesn't move, the overlay may become inaccessible. So presumably, we would want to "anchor" the overlay to the closest corner / side once placed by the user, so that it remains proportionally at the same spot after a resize. |
Ya, I would think having a "corner" overlay to be very useful. I assume all coordinate/offset x,y, etc would be relative to the "map" frame and NOT the whole UI? Then you shouldn't have to worry about all the other windows. Should this be it's own "function" instead of extending the dialog5? (I like the name overlay). I can't think of a usecase were I would need a transparent overlay (vs a normal frame/dialog) that wasn't over the map? Also, what do we do with Layers dialog for the GM? Is it always over the overlay? (drawing panel as well although that makes sense to pop it over overlays when needed) |
Exciting stuff. I agree that in macro script this could be a separate The Layers/Drawing/Adjust Map modals should simply render directly over any Custom UI overlays as if they are a part of the map. Any currently open modal should have a corresponding class applied to overlays for CSS to respond to - I feel like the current UI should be generally 'first class' and user-defined overlays should be given information to work around it if they choose. Eventually (once html5 is applied to them, probably), I think overlays should be responsive based on the width and height of the Mapview with CSS media queries and other classes assigned to the overlay body. I am still interested in having UI defined in the campaign properties and have the initial layout at least be strictly defined for a campaign; each overlay needs HTML and CSS and possibly Javascript and images, so it makes sense to make each overlay a tidy package in Campaign properties. A compact edit UI like https://jsfiddle.net/ would make a lot of sense, though that seems a bit ambitious - maybe down the road? :) Anyway, 'Custom UI' tab in Campaign Properties that lets you create a list of named overlays would be a little more approachable for GMs and elevate the feature a bit as a way for GMs to make their frameworks distinctive. I worry if not, they will only be used by a minority of more advanced users. (This might dovetail into #1422 and the overlays might be a folder in a campaign notebook I'm not sure). In my dream world where players can connect on their android and iOS devices, mature frameworks can have a custom UI defined that makes playing on a tablet a breeze. |
I just had a thought; if click-through does end up working while still allowing button presses, would custom overlays being combined into a single HTML 5 overlay that is the entire width/height of the map view which combines all overlays as absolutely positioned DIVs be more performant ? I just had a thought of framework creators adding small, individual overlays for lots of pieces of overlapping UI creating a performance issue (like chrome with lots and lots of tabs), and smushing all defined overlays into a single HTML document might be a lot faster. edit: brain switched half a sentence around.. |
Ok, just had another shower thought.... @Merudo How about adding a This may run into/over/compliment/replace #1424 as you could now create "stat sheets" of any sort where ever you wanted. Another useful "coordinate" would be an offset based on a token for |
Created a brief fiddle demonstrating a sample single HTML document overlay system with 9 potential overlay base positions: |
Can we position said overlay relative to another overlay? Lets say I had 1-4 overlays I wanted to display in the upper right, each with 0-n padding between them. And lets say I may want to display 1, 2, & 4 for player 1 vs 1, 3, & 4 for GM, I wouldn't want that gap in there. Yes, this could be 1 overlay but lets entertain I need 4? Or better yet, lets say I had 0-n overlays (maybe each is a "state") and as such I want them to start in upper left but "wrap" down into a second row? Should we instead treat the map "frame" as one large "window" that we can pass CSS to and organize the overlays that way? Does each "overlay" need to be it's own "dialog/frame"? Also are these elements in the overlay intractable/clickable (I assume so and the click-thru is only for transparent parts of the overlay?) |
@JamzTheMan At least in my approach we could structure an overlay to be another overlay's parent, then style that overlay to wrap a flexbox container around the contents if that is happening. By styling the parent div's options we could change the flex properties, but columns would be a good default. Updated the fiddle with an example, try clicking or manually adding and removing copies of #OVERLAY-004 & 005: |
Yea, I'm just wondering if it would be best to have a single overlay acting like a "glass" layer the framework launching several overlay windows each running it's own webengine. A single instance of a webengine to render a whole page of elements may be more performant. Although I think we are saying the same thing really. Develop all of your "overlays" in a single html/css "dialog" and forget about having to launch multiple "overlay" dialogs each with there own relativePosition. |
(This has been exciting stuff to watch develop. :)) My only concern with using CSS is how touchy CSS can be about layout issues. Is there an option to create some kind of LayoutManager and use that? I could see a LayoutManager that gives each child a priority and a position, then lays them out in priority order. The position might be "+5+0" to mean 5 units to the right and 0 units up from the previous component, and "-10+10" would mean 10 units left and 10 units up, always relative to the corner specified by the offset. So numbers that are +,+ would be from the lower left corner and numbers that are -,+ would be from the bottom right corner. This is the style used by the X Window system to place child windows... Whatever comes out of this, I'm looking forward to it. ;) |
FWIW I'm not suggesting to use CSS to layout swing dialog aka "windows" but rather there is a full width/height invisible pane that is always on and overlaying the map and the user can via macro add content to it. If they wanted a "status panel" in the upper right corner, you would use standard HTML/CSS to place it there. I would think you would be able to layout some simple elements in the corners/sides this way but ya sure, YMMV, i mean, it IS webkit after all so /shrug |
That's the question. If there is a single overlayPane (that sits between the contentPane and glassPane?) and it's a single WebView component, the CSS is being used to position the individual overlays within the WebView and thus, within the overlayPane. But if that overlayPane holds multiple WebView components, then it needs some kind of layout manager to position them (something like SpringLayoutManager). I was suggesting that if this were the solution chosen, the X Window system's "geometry" syntax might be useful in coding the layout manager. It's kind of a toss-up. Using a single WebView means CSS has to be used and CSS is finicky, particularly when it comes to rule specificity. But LayoutManagers are not exactly dream components either and they can be hard to get right. And the CSS rules are already written... |
I second this, its both easier to implement and more flexible.
This above. Plus we open the pool to potential contributors for UIs so much. |
Right now I'm using a
One advantage of multiple overlay components may be faster updates ; if a single overlay needs updating, it will in general be faster to update that single component instead of processing the html for the entire overlay screen. However, I do agree that having one single overlay html component taking the entire screen is probably more effective. For one, it then becomes possible to arrange the layout entirely with CSS & javascript, which is preferable to us reinventing an API. I'm especially excited about the
I made a basic |
Are Ajax techniques possible in Java web components so we can dynamically update the dom without forcing a total refresh? Finding a way to provide updates without a total reload of the html would be great for snappy performance - but I just don't know if something like Vue/react can work in this context... |
- Add function overlay() to display a transparent html 3.2 overlay over the map - Function is used similarly to frame() and dialog(), with [overlay():{ myhtml }] used to display "myhtml" - Discussed in RPTools#1425
PR #1438 implements the feature for html 3.2. Will post an example soon. |
It's possible with HTML 5 in WebView, see #1362. Unfortunately WebView is JavaFX, and to my knowledge it is not possible to have satisfactory transparency when using JavaFX components in Swing. So this approach won't work for overlays until we switch to JavaFX. |
- Add function overlay() to display a transparent html 3.2 overlay over the map - Function is used similarly to frame() and dialog(), with [overlay():{ myhtml }] used to display "myhtml" - Discussed in RPTools#1425
Another downside of a single HTML overlay: in HTML 3.2, it is not possible to vertically align an element to the bottom of the page. Having an overlay element snap to the bottom border or the vertical center is therefore not possible. One option is to have three HTML overlays: one aligned to the top, one aligned to the bottom, and one aligned to the center. |
- Add function overlay() to display a transparent html 3.2 overlay over the map - Function is used similarly to frame() and dialog(), with [overlay():{ myhtml }] used to display "myhtml" - Discussed in RPTools#1425
- Move HTMLJFXPanel WebView code to HTMLWebViewManager - Separate HTMLOverlay into HTMLOverlayManager and HTMLWebViewManager - Feature discussed in RPTools#1425
- Move HTMLJFXPanel WebView code to HTMLWebViewManager - Separate HTMLOverlay into HTMLOverlayManager and HTMLOverlayPanel - Feature discussed in RPTools#1425
- Change so overlays must be given a name, as for frames or dialogs - Add parameter "zorder" to overlay(). The overlays will be drawn according to the zOrder (high zOrder overlays are drawn over low zOrder overlays) - Discussed in RPTools#1425
- Change so overlays must be given a name, as for frames or dialogs - Add parameter "zorder" to overlay(). The overlays will be drawn according to the zOrder (high zOrder overlays are drawn over low zOrder overlays) - Move HTMLJFXPanel WebView code to HTMLWebViewManager - Separate HTMLOverlay into HTMLOverlayManager and HTMLOverlayPanel - Feature discussed in RPTools#1425
PR #1534 implements multiple overlays. I still haven't added the overlay menu in the UI but otherwise it is shaping up to look pretty good. |
- Change so overlays must be given a name, as for frames or dialogs - Add parameter "zorder" to overlay(). The overlays will be drawn according to the zOrder (high zOrder overlays are drawn over low zOrder overlays) - Move HTMLJFXPanel WebView code to HTMLWebViewManager - Separate HTMLOverlay into HTMLOverlayManager and HTMLOverlayPanel - Feature discussed in RPTools#1425
re: HTMLFrameFactory.java
Yeah. We'll need to report non-numeric zorder to the user and probably mention using default (or next) z-order. Is a function to set/change zorder needed? Or just call the overlay() function again with a new zorder? |
- Fix a graphical glitch caused by calling snapshot on a WebView. - Feature RPTools#1425
- Add an overlay menu that allows each overlay to be turned on and off - Feature discussed in RPTools#1425
PR #1543 adds an overlay menu where each overlay can be turned on or off. A bare-bone demo. Click on the macros of the Campaign panel to enable the three overlays: |
We could use the error message
Or, should a new error message be written?
Currently, the |
I like it! |
That works for me.
Good enough. |
- Change so that overlay() gives the following message when provided a non-integer zOrder: Argument key "zorder" to function "overlay" must be an integer. - Change discussed in RPTools#1425
Feature complete? |
I think so. Might be ready for an alpha / beta. |
Tested with examples provided. No issues seen. |
Page added to wiki. https://lmwcs.com/rptools/wiki/overlay_(roll_option) |
Is your feature request related to a problem? Please describe.
Transparent HTML overlays would be a great way to display UI elements, such as a health meter, clickable icons that can launch macros, and a picture of the selected character.
A good example is provided here by @melek : https://forums.rptools.net/viewtopic.php?f=26&p=275748
Describe the solution you'd like
One option would be to extend the
dialog()
function to allow for invisible dialogs, which could then function as overlaysAnother would be to make a whole new function for overlays.
Additional context
The implementation of overlays poses two difficulties:
The text was updated successfully, but these errors were encountered: