search

leaningtech / cheerpj-meta

Run Java 8 applications, libraries, applets, Java Web Start, and Oracle Forms on the web without legacy plugins.
https://labs.leaningtech.com/cheerpj
445 stars 21 forks source link

Feature request: Generate id/class for GUI elements #92

Closed oeway closed 3 years ago

oeway commented 3 years ago

I think it would be great if the generated HTML elements can contains unique ids or css class generated consistently from its java version, this can help a lot for customisation or fixing display issues with css. In most the cases, I found there are issues in the display, I need to use css selectors like .window>div>div>div (actual example). Sometimes it fixes this window but breaks the other.

I guess the mapping from Java UI to HTML will never be perfect, small fix will always be needed and having access to id or css class would just make the life much easier.

alexp-sssup commented 3 years ago

I am not comfortable in committing to a public API for styling Java AWT components which are rendered as DOM nodes. The reality is that AWT is not designed for that.

AWT was designed with the idea of letting the platform decide how to render the components. Nice idea in theory but in practice a recipe for disaster, this model was indeed mostly (although not fully) thrown out of the window when Swing was introduced.

There are a lot of subtle assumptions in AWT about how the components should be rendered and CheerpJ tries to create DOM elements to render an acceptable results which is somehow close to the original UI.

The reality is that there are very significant constraints to what sort of changes can be achieved via CSS styling without breaking the assumptions in AWT. If we were to offer a documented way to style the element, then we would also need to somehow guarantee what can be done and what not, which seems outside of the scope of CheerpJ.

Moreover, we see AWT as a legacy technology with no commercial interest. In our experience we have only seen Swing being used in enterprise settings.

There is also the question of how to deal with mixed AWT/Swing apps (those exists) and CSS styling could only ever modify the AWT part which would generate unexpected inconsistencies for users.

In short, this is not a feature that I (as the CTO of the company) think we should implement. I am willing to revisit this decision is there is significant commercial demand for this feature.

oeway commented 3 years ago

Thanks for the explanation.

Since my main motivation to propose is to fix the rendering issues with the current implementation (not to go further have fancy css styling), could you please also clarify what’s your policy or recommended solution to fix UI rendering issue with awt? Should we send issues about those them so you may fix? Or awt can only be supported as is since there isn’t enough commercial interest?

alexp-sssup commented 3 years ago

We absolutely welcome bug reports about AWT UI correctness, we will do what we can to fix them but depending on the complexity of the problem it might take a while before we have the bandwidth to work on some of those.

The good news is that CheerpJ releases are immutable. This means that if you have your app working and displaying correctly (with custom CSS fixes) with a specific loader.js endpoint, then the app will keep working indefinitely. You would only need to worry about the UI changing if you choose to use an updated version of CheerpJ.