Google Web Toolkit: February 2025

Wednesday, February 26, 2025

Re: Accidental pin?

Yep, I noticed that too. We do have a fair number of inactive admins for this channel, its possible that someone misclicked and re-pinned that? We've also seen weirdness like the GWT 2.10 release announcement and the first 3 or so replied deleted for no reason, so perhaps something odd is happening with Google Groups itself...

I'm not even sure I had access to pin/unpin messages until recently, but I seem to now. I'll update to get 2.12.1 as the latest pinned message.

On Wednesday, February 26, 2025 at 9:30:21 PM UTC-6 ma...@craig-mitchell.com wrote:

I think someone accidently pinned the 2.9.0 release message.

Unless I've missed something, and we are going backward.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/5ced9d87-06e9-402f-afa3-39a30b63f6b1n%40googlegroups.com.

Accidental pin?

I think someone accidently pinned the 2.9.0 release message.

Unless I've missed something, and we are going backward.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/0c423e78-2ebf-4169-a2fc-ac0062fbf039n%40googlegroups.com.

Tuesday, February 25, 2025

Re: Upgrading to GWT 2.12, and issues with GWT Query

If those are your only use cases, I would strongly consider just dropping GWTQuery (before or after updating GWT) and using plain dom manipulation to achieve your goals.

Before updating - com.google.gwt.dom.client.Element has a setId(String) and a scrollIntoView() method. Hiding rows could probably also be achieved with plain Element calls (adding styles or classes).

After updating to something that supports JsInterop and/or Elemental2, you could use those tools to avoid writing JSNI or using the Element class.

On Tuesday, February 25, 2025 at 11:19:54 AM UTC-6 simon....@infoshare-is.com wrote:

I'm trying to upgrade from GWT 2.5.1 to GWT 2.12, and I'm having issues with GWT Query.

The latest published version of GWT Query appears to be 1.5-beta1, which appears to be hardwired to GWT 2.8.0

Is there a version of GWT Query for GWT 2.12, or is there a suitable replacement?

We're using very simple GWT Query actions -
1. Set HTML ID
2. Scroll selected item into view
3. Hide empty rows in table.

Simon

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/568b4ab8-b57e-4dc8-acc1-e6e84e512084n%40googlegroups.com.

Upgrading to GWT 2.12, and issues with GWT Query

I'm trying to upgrade from GWT 2.5.1 to GWT 2.12, and I'm having issues with GWT Query.

The latest published version of GWT Query appears to be 1.5-beta1, which appears to be hardwired to GWT 2.8.0

Is there a version of GWT Query for GWT 2.12, or is there a suitable replacement?

We're using very simple GWT Query actions -
1. Set HTML ID
2. Scroll selected item into view
3. Hide empty rows in table.

Simon

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/6a4d6324-eb4e-42d0-949b-af7cf36cd924n%40googlegroups.com.

Wednesday, February 12, 2025

Re: Is GWT2.11 Is Really Compatible With Java17

Note that you might also end up being impacted by https://github.com/gwtproject/gwt/issues/10020, which was fixed in GWT 2.12.1. If you are already updated to Java 17, you should be safe to update to 2.12.1. This was apparently reported internally within Google many years ago, but never put on the official issue tracker.

On Wednesday, February 12, 2025 at 6:25:59 AM UTC-6 Jens wrote:

I just noticed you said you updated from Java 8. JAXB classes are considered Java Enterprise Edition classes and have been removed in Java 9 from the default classpath and fully removed from JDK in Java 11. As you now use a newer JDK you have to add a new dependency to your project to have javax.xml.bind.annoations.XmlTransient class again.

You would need to add jakarta.xml.bind:jakarta.xml.bind-api:2.3.3 to use the JAXB API with the old javax.xml package. Any newer version will use the newer jakarta package name. If you also need a matching implementation on your server you can use org.glassfish.jaxb:jaxb-runtime:2.3.9. I use both on the server with Java 17+.

-- J.

Midhunkumar schrieb am Mittwoch, 12. Februar 2025 um 13:07:11 UTC+1:
Hi,

I have attached my classpath file below

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="src" output="target/classes" path="src/main/java">
<attributes>
<attribute name="optional" value="true"/>
<attribute name="maven.pomderived" value="true"/>
</attributes>
</classpathentry>
<classpathentry kind="src" output="target/test-classes" path="src/test/java">
<attributes>
<attribute name="optional" value="true"/>
<attribute name="maven.pomderived" value="true"/>
</attributes>
</classpathentry>
<classpathentry kind="con" path="com.gwtplugins.gwt.eclipse.core.GWT_CONTAINER"/>
<classpathentry kind="lib" path="C:/Users/mkanbazhahan/.m2/repository/com/sencha/GXT/4.2.0/gxt-4.2.0.jar"/>
<classpathentry kind="lib" path="C:/Users/mkanbazhahan/.m2/repository/com/sencha/GXTChart/4.0.3/GXTChart-4.0.3.jar"/>
<classpathentry kind="lib" path="C:/Users/mkanbazhahan/.m2/repository/com/sencha/GXTGantt/4.0.3/GXTGantt-4.0.3.jar"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry kind="output" path="target/classes"/>
</classpath>

Is there anything I need to change to resolve the error, and the error was not about only XmlTransient in one file I have same kind of n number of errors which indicated cannot to be resolved and all are only just imports of an another class but it shows the reported error.

And I have changed the latest version of GWT for java 17 and I have gone through some of the sites which indicates that as of now GWT will support only upto Java 11.

Kindly share your thoughts regarding it.

Thanks,
Midhun.
On Wednesday, February 12, 2025 at 4:35:19 PM UTC+5:30 Jens wrote:
The error you posted shows nothing that would indicate that Java 17 is the issue. Looks more like a general setup/dependency issue.

Your code uses XmlTransient (I guess it is an annotation) but for some reason GWT compiler cannot see the annotation. Also you should make sure that you really only have GWT 2.11 on classpath. If you use GWT libraries you might also have an older GWT on classpath and things can be mixed up. So check your full dependency tree just to be sure.

-- J.

Midhunkumar schrieb am Mittwoch, 12. Februar 2025 um 07:52:12 UTC+1:
Hi,

We have GWT developed project at the version 2.7.0 in Java 8. Currently we are migrating to Java 17 I have changed the Gwt plugin versions to 2.11. After n number of changes in the setup and lot of deployments and build I am still facing the below error

Tracing compile failure path for type 'com.ultramain.client.UltramainHtml'
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/client/UltramainHtml.java'
[ERROR] com.ultramain.client.UltramainWebServiceAsync cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/client/UltramainWebServiceAsync.java'
[ERROR] com.ultramain.shared.MobileCommandReference cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/MobileCommandReference.java'
[ERROR] com.ultramain.shared.ExportExecutionDto cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/ui/ViewSecurityOptions.java'
[ERROR] com.ultramain.shared.settings.Options cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/SaveDeleteStatisticsOptionCommandDto.java'
[ERROR] com.ultramain.shared.MobileSaveDeleteOptionCommandDto.SaveDeleteOptionCommandDtoEnum cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/navigators/PaintableEntry.java'
[ERROR] com.ultramain.shared.ui.Filter cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/DtoData.java'
[ERROR] com.ultramain.shared.DataLink cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/MobileLoadFromImportExportCatalogDto.java'
[ERROR] com.ultramain.shared.importexport.Import cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/dashboard/HtmlDashboard.java'
[ERROR] Line 162: XmlTransient cannot be resolved to a type
[ERROR] Line 177: XmlTransient cannot be resolved to a type
[ERROR] Line 11: The import com.ultramain.system cannot be resolved
[ERROR] Line 140: XmlTransient cannot be resolved to a type..... goes on

My primary question Is GWT 2.11.0 truly compatible with java 17?

I have tried removing the GWT maven plugin and build the project the build is success, but the GWT compilation is not happening. The compilation has to happen and all GWT JS resources will be put inside ultramainhtml folder inside our project's war.

Appreciate your help.

Thanks,
Midhun.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/8a9e9785-195a-4d4e-a6f6-348fc74ea01fn%40googlegroups.com.

Re: Is GWT2.11 Is Really Compatible With Java17

I just noticed you said you updated from Java 8. JAXB classes are considered Java Enterprise Edition classes and have been removed in Java 9 from the default classpath and fully removed from JDK in Java 11. As you now use a newer JDK you have to add a new dependency to your project to have javax.xml.bind.annoations.XmlTransient class again.

You would need to add jakarta.xml.bind:jakarta.xml.bind-api:2.3.3 to use the JAXB API with the old javax.xml package. Any newer version will use the newer jakarta package name. If you also need a matching implementation on your server you can use org.glassfish.jaxb:jaxb-runtime:2.3.9. I use both on the server with Java 17+.

-- J.

Midhunkumar schrieb am Mittwoch, 12. Februar 2025 um 13:07:11 UTC+1:

Hi,

I have attached my classpath file below

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="src" output="target/classes" path="src/main/java">
<attributes>
<attribute name="optional" value="true"/>
<attribute name="maven.pomderived" value="true"/>
</attributes>
</classpathentry>
<classpathentry kind="src" output="target/test-classes" path="src/test/java">
<attributes>
<attribute name="optional" value="true"/>
<attribute name="maven.pomderived" value="true"/>
</attributes>
</classpathentry>
<classpathentry kind="con" path="com.gwtplugins.gwt.eclipse.core.GWT_CONTAINER"/>
<classpathentry kind="lib" path="C:/Users/mkanbazhahan/.m2/repository/com/sencha/GXT/4.2.0/gxt-4.2.0.jar"/>
<classpathentry kind="lib" path="C:/Users/mkanbazhahan/.m2/repository/com/sencha/GXTChart/4.0.3/GXTChart-4.0.3.jar"/>
<classpathentry kind="lib" path="C:/Users/mkanbazhahan/.m2/repository/com/sencha/GXTGantt/4.0.3/GXTGantt-4.0.3.jar"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry kind="output" path="target/classes"/>
</classpath>

Is there anything I need to change to resolve the error, and the error was not about only XmlTransient in one file I have same kind of n number of errors which indicated cannot to be resolved and all are only just imports of an another class but it shows the reported error.

And I have changed the latest version of GWT for java 17 and I have gone through some of the sites which indicates that as of now GWT will support only upto Java 11.

Kindly share your thoughts regarding it.

Thanks,
Midhun.
On Wednesday, February 12, 2025 at 4:35:19 PM UTC+5:30 Jens wrote:
The error you posted shows nothing that would indicate that Java 17 is the issue. Looks more like a general setup/dependency issue.

Your code uses XmlTransient (I guess it is an annotation) but for some reason GWT compiler cannot see the annotation. Also you should make sure that you really only have GWT 2.11 on classpath. If you use GWT libraries you might also have an older GWT on classpath and things can be mixed up. So check your full dependency tree just to be sure.

-- J.

Midhunkumar schrieb am Mittwoch, 12. Februar 2025 um 07:52:12 UTC+1:
Hi,

We have GWT developed project at the version 2.7.0 in Java 8. Currently we are migrating to Java 17 I have changed the Gwt plugin versions to 2.11. After n number of changes in the setup and lot of deployments and build I am still facing the below error

Tracing compile failure path for type 'com.ultramain.client.UltramainHtml'
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/client/UltramainHtml.java'
[ERROR] com.ultramain.client.UltramainWebServiceAsync cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/client/UltramainWebServiceAsync.java'
[ERROR] com.ultramain.shared.MobileCommandReference cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/MobileCommandReference.java'
[ERROR] com.ultramain.shared.ExportExecutionDto cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/ui/ViewSecurityOptions.java'
[ERROR] com.ultramain.shared.settings.Options cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/SaveDeleteStatisticsOptionCommandDto.java'
[ERROR] com.ultramain.shared.MobileSaveDeleteOptionCommandDto.SaveDeleteOptionCommandDtoEnum cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/navigators/PaintableEntry.java'
[ERROR] com.ultramain.shared.ui.Filter cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/DtoData.java'
[ERROR] com.ultramain.shared.DataLink cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/MobileLoadFromImportExportCatalogDto.java'
[ERROR] com.ultramain.shared.importexport.Import cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/dashboard/HtmlDashboard.java'
[ERROR] Line 162: XmlTransient cannot be resolved to a type
[ERROR] Line 177: XmlTransient cannot be resolved to a type
[ERROR] Line 11: The import com.ultramain.system cannot be resolved
[ERROR] Line 140: XmlTransient cannot be resolved to a type..... goes on

My primary question Is GWT 2.11.0 truly compatible with java 17?

I have tried removing the GWT maven plugin and build the project the build is success, but the GWT compilation is not happening. The compilation has to happen and all GWT JS resources will be put inside ultramainhtml folder inside our project's war.

Appreciate your help.

Thanks,
Midhun.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/5831e2ce-3dc3-471d-aaec-69f7a49173edn%40googlegroups.com.

Re: Is GWT2.11 Is Really Compatible With Java17

Hi,

I have attached my classpath file below

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="src" output="target/classes" path="src/main/java">
<attributes>
<attribute name="optional" value="true"/>
<attribute name="maven.pomderived" value="true"/>
</attributes>
</classpathentry>
<classpathentry kind="src" output="target/test-classes" path="src/test/java">
<attributes>
<attribute name="optional" value="true"/>
<attribute name="maven.pomderived" value="true"/>
</attributes>
</classpathentry>
<classpathentry kind="con" path="com.gwtplugins.gwt.eclipse.core.GWT_CONTAINER"/>
<classpathentry kind="lib" path="C:/Users/mkanbazhahan/.m2/repository/com/sencha/GXT/4.2.0/gxt-4.2.0.jar"/>
<classpathentry kind="lib" path="C:/Users/mkanbazhahan/.m2/repository/com/sencha/GXTChart/4.0.3/GXTChart-4.0.3.jar"/>
<classpathentry kind="lib" path="C:/Users/mkanbazhahan/.m2/repository/com/sencha/GXTGantt/4.0.3/GXTGantt-4.0.3.jar"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry kind="output" path="target/classes"/>
</classpath>

Is there anything I need to change to resolve the error, and the error was not about only XmlTransient in one file I have same kind of n number of errors which indicated cannot to be resolved and all are only just imports of an another class but it shows the reported error.

And I have changed the latest version of GWT for java 17 and I have gone through some of the sites which indicates that as of now GWT will support only upto Java 11.

Kindly share your thoughts regarding it.

Thanks,

Midhun.

On Wednesday, February 12, 2025 at 4:35:19 PM UTC+5:30 Jens wrote:

The error you posted shows nothing that would indicate that Java 17 is the issue. Looks more like a general setup/dependency issue.

Your code uses XmlTransient (I guess it is an annotation) but for some reason GWT compiler cannot see the annotation. Also you should make sure that you really only have GWT 2.11 on classpath. If you use GWT libraries you might also have an older GWT on classpath and things can be mixed up. So check your full dependency tree just to be sure.

-- J.

Midhunkumar schrieb am Mittwoch, 12. Februar 2025 um 07:52:12 UTC+1:
Hi,

We have GWT developed project at the version 2.7.0 in Java 8. Currently we are migrating to Java 17 I have changed the Gwt plugin versions to 2.11. After n number of changes in the setup and lot of deployments and build I am still facing the below error

Tracing compile failure path for type 'com.ultramain.client.UltramainHtml'
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/client/UltramainHtml.java'
[ERROR] com.ultramain.client.UltramainWebServiceAsync cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/client/UltramainWebServiceAsync.java'
[ERROR] com.ultramain.shared.MobileCommandReference cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/MobileCommandReference.java'
[ERROR] com.ultramain.shared.ExportExecutionDto cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/ui/ViewSecurityOptions.java'
[ERROR] com.ultramain.shared.settings.Options cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/SaveDeleteStatisticsOptionCommandDto.java'
[ERROR] com.ultramain.shared.MobileSaveDeleteOptionCommandDto.SaveDeleteOptionCommandDtoEnum cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/navigators/PaintableEntry.java'
[ERROR] com.ultramain.shared.ui.Filter cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/DtoData.java'
[ERROR] com.ultramain.shared.DataLink cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/MobileLoadFromImportExportCatalogDto.java'
[ERROR] com.ultramain.shared.importexport.Import cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/dashboard/HtmlDashboard.java'
[ERROR] Line 162: XmlTransient cannot be resolved to a type
[ERROR] Line 177: XmlTransient cannot be resolved to a type
[ERROR] Line 11: The import com.ultramain.system cannot be resolved
[ERROR] Line 140: XmlTransient cannot be resolved to a type..... goes on

My primary question Is GWT 2.11.0 truly compatible with java 17?

I have tried removing the GWT maven plugin and build the project the build is success, but the GWT compilation is not happening. The compilation has to happen and all GWT JS resources will be put inside ultramainhtml folder inside our project's war.

Appreciate your help.

Thanks,
Midhun.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/ccda3675-a0a6-4f8d-b2d1-ed7a07528ba0n%40googlegroups.com.

Re: Is GWT2.11 Is Really Compatible With Java17

The error you posted shows nothing that would indicate that Java 17 is the issue. Looks more like a general setup/dependency issue.

Your code uses XmlTransient (I guess it is an annotation) but for some reason GWT compiler cannot see the annotation. Also you should make sure that you really only have GWT 2.11 on classpath. If you use GWT libraries you might also have an older GWT on classpath and things can be mixed up. So check your full dependency tree just to be sure.

-- J.

Midhunkumar schrieb am Mittwoch, 12. Februar 2025 um 07:52:12 UTC+1:

Hi,

We have GWT developed project at the version 2.7.0 in Java 8. Currently we are migrating to Java 17 I have changed the Gwt plugin versions to 2.11. After n number of changes in the setup and lot of deployments and build I am still facing the below error

Tracing compile failure path for type 'com.ultramain.client.UltramainHtml'
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/client/UltramainHtml.java'
[ERROR] com.ultramain.client.UltramainWebServiceAsync cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/client/UltramainWebServiceAsync.java'
[ERROR] com.ultramain.shared.MobileCommandReference cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/MobileCommandReference.java'
[ERROR] com.ultramain.shared.ExportExecutionDto cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/ui/ViewSecurityOptions.java'
[ERROR] com.ultramain.shared.settings.Options cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/SaveDeleteStatisticsOptionCommandDto.java'
[ERROR] com.ultramain.shared.MobileSaveDeleteOptionCommandDto.SaveDeleteOptionCommandDtoEnum cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/navigators/PaintableEntry.java'
[ERROR] com.ultramain.shared.ui.Filter cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/DtoData.java'
[ERROR] com.ultramain.shared.DataLink cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/MobileLoadFromImportExportCatalogDto.java'
[ERROR] com.ultramain.shared.importexport.Import cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/dashboard/HtmlDashboard.java'
[ERROR] Line 162: XmlTransient cannot be resolved to a type
[ERROR] Line 177: XmlTransient cannot be resolved to a type
[ERROR] Line 11: The import com.ultramain.system cannot be resolved
[ERROR] Line 140: XmlTransient cannot be resolved to a type..... goes on

My primary question Is GWT 2.11.0 truly compatible with java 17?

I have tried removing the GWT maven plugin and build the project the build is success, but the GWT compilation is not happening. The compilation has to happen and all GWT JS resources will be put inside ultramainhtml folder inside our project's war.

Appreciate your help.

Thanks,
Midhun.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/06b12763-f626-49c9-8f92-c02309c92eebn%40googlegroups.com.

Tuesday, February 11, 2025

Is GWT2.11 Is Really Compatible With Java17

Hi,

We have GWT developed project at the version 2.7.0 in Java 8. Currently we are migrating to Java 17 I have changed the Gwt plugin versions to 2.11. After n number of changes in the setup and lot of deployments and build I am still facing the below error

Tracing compile failure path for type 'com.ultramain.client.UltramainHtml'
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/client/UltramainHtml.java'
[ERROR] com.ultramain.client.UltramainWebServiceAsync cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/client/UltramainWebServiceAsync.java'
[ERROR] com.ultramain.shared.MobileCommandReference cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/MobileCommandReference.java'
[ERROR] com.ultramain.shared.ExportExecutionDto cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/ui/ViewSecurityOptions.java'
[ERROR] com.ultramain.shared.settings.Options cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/SaveDeleteStatisticsOptionCommandDto.java'
[ERROR] com.ultramain.shared.MobileSaveDeleteOptionCommandDto.SaveDeleteOptionCommandDtoEnum cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/navigators/PaintableEntry.java'
[ERROR] com.ultramain.shared.ui.Filter cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/DtoData.java'
[ERROR] com.ultramain.shared.DataLink cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/MobileLoadFromImportExportCatalogDto.java'
[ERROR] com.ultramain.shared.importexport.Import cannot be resolved to a type
[ERROR] Errors in 'file:/W:/Java%2017/USI.UNITY.OXY/UltramainHtml/src/main/java/com/ultramain/shared/dashboard/HtmlDashboard.java'
[ERROR] Line 162: XmlTransient cannot be resolved to a type
[ERROR] Line 177: XmlTransient cannot be resolved to a type
[ERROR] Line 11: The import com.ultramain.system cannot be resolved
[ERROR] Line 140: XmlTransient cannot be resolved to a type..... goes on

My primary question Is GWT 2.11.0 truly compatible with java 17?

I have tried removing the GWT maven plugin and build the project the build is success, but the GWT compilation is not happening. The compilation has to happen and all GWT JS resources will be put inside ultramainhtml folder inside our project's war.

Appreciate your help.

Thanks,

Midhun.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/4b301446-6dce-4e56-aa83-0434276c1e6dn%40googlegroups.com.

Re: Suggestion on upgrading gwt-2.6.1 to latest

Oh, but I agree, the nature of the GWT Canvas implementation is no driver at all in which methodology to use to implement your application.

Which design approach should be used depends on what the development team masters best.

The advantage of an OO approach - which I was trying to make clear but obviously failed - is that you can have the model work out the required functionality before you need to draw it out on the canvas. It has many advantages, one of which - in this case - is that you need a lot less complex actions from the canvas itself. The reason is not for performance, but it's a complexity reduction basically.

For that reason OO is very practical on the backend, but given the unique nature of GWT it makes it very practical on the frontend too.

To me, that is one of it's USP's.

And we can agree to disagree on the FP.

Whilst I can imagine that for script languages FP seems like a more natural fit, but for information systems where java shines, OO is the best fit.

The FP adoption in java is not late to the party, but is more like Oracle following the trend trying to make java hip and luring the script developers to jump ship.

So yeah, for FP in Java I would say it is definitely following a trend.

But like I said, we can agree to disagree.

The funny thing about software development is that it is a field in which mastery of the tools is often seen as mastery of the craft.

Now try to explain that to a carpenter or a potter.

On Tue, Feb 11, 2025 at 6:38 PM Colin Alworth <colin@colinalworth.com> wrote:

Sorry if I was unclear - FP vs OO vs whatever really shouldn't matter. I only brought it up because you mentioned "OO style" driving some choices. The nature of the Canvas APIs shouldn't need to drive how you use them, until you are so starved for performance that you can't afford any indirection at all.

I don't think it is fair to call it the current trend - to anyone. Java upped its FP game in Java 8, 10 years ago - and I don't think anyone will argue that Java ever gets to the party early, without years of deliberation. JavaScript is perfectly usable as a functional language (debatably more so than than Java even today, since we still need SAM interfaces and can't just pass functions directly) and has been for 30 years since it was first released.

React's strategy effectively required that they adopt a "stateless" paradigm, which lends itself very well to encouraging (ostensibly) pure functions for rendering, that accept the state/props as an argument.

On Sunday, February 9, 2025 at 2:39:00 AM UTC-6 leon.p...@gmail.com wrote:
Switching to functional is the current trend I guess. Now you can argue whether or not it's smart to change design approach because it's a trend. As a framework - probably yes as you get higher adoption rates.
As an application developer probably not - as it just creates extra maintenance for when the next trend comes around.

On Sun, Feb 9, 2025 at 12:30 AM Craig Mitchell <ma...@craig-mitchell.com> wrote:
> OO vs procedural/functional is quite the different design approach. I would even say that those are worlds apart.

Tell that to the React creators, that switched the framework from OO to functional. 😝

On Sunday, 9 February 2025 at 8:49:40 am UTC+11 Leon wrote:
I can see where you say a developer familiar with the DOM is more likely to work with on the canvas api directly.
And yes, the more technical options the better. Sure.
But I do not see how you can say that an OO vs procedural or functional approach is not that relevant? OO vs procedural/functional is quite the different design approach. I would even say that those are worlds apart. In what way do you think that this difference not relevant?

On Sat, Feb 8, 2025 at 8:53 PM Colin Alworth <co...@colinalworth.com> wrote:

@Craig - If you draw everything on the same canvas, the zoom/scale works on everything on that canvas. it limits what you can do with that canvas. If you want to scale or zoom everything, yes then it doesn't matter. So yes you are right, it depends on the project.
This isn't true, it only applied on the operations that take place while it is set. You can call scale(1, 1) to go back to 1:1, or you can use the save()/restore() that Craig mentioned. You can also clip to keep the zoomed content within certain bounds.
@Colin - With multiple layers I would also need multiple canvas's and overlay them right?
Correct - each would have its own frame buffer, and could be cleared/drawn independently.

We wrote a single adapter widget that uses a single canvas. This adapter widget knows what the zoom level is. Objects that are drawn on that widget of a certain type get zoomed, whilst others of a different type do not. It is super simple and easily explained to new devs. Everyone on the team can add views or objects and the type determines how these are displayed. Even devs without exact knowledge of how the canvas works can develop and maintain objects to be displayed.

I guess it's also a development style/preference thing. If you code the view of the canvas in a single class or single method, the solution is likely to have to rely more on the technological capabilities of the canvas. Working with an adapter then does not really make a lot of sense.
If you have more of an OO style of development, you express more in functional blocks. Then you have to rely less on the technical capabilities as you can translate what needs to be done on the basis of what your objects are before you hit the canvas. Then the zooming/scaling happens in the object, not on the canvas so to speak.
So the required functionality of the canvas remains fairly basic.
I don't make these suggestions lightly - if you are happy with how canvas performs and the quality of the output, then you may well never need them, but it can be fun to know they exist.

I don't much care about OO vs FP styles for this - building an API around these features should be straightforward within whatever paradigm you prefer. For most projects we ended up with roughly two layers of abstractions - the "shapes that get drawn on the screen via canvas commands" abstraction (iterate through "shapes", respect their "z-index" or other relative positioning, capture clicks and figure out which "shape" was clicked on, redraw only changed "shapes" and those that intersect them, etc), and the "business logic drives what shapes to draw" abstraction ("I want a pie chart in the corner, compute slices based on data", "these buttons over here control those axes", "Labeled items in the legend will drive which stars/circles in the chart are highlighted when hovered"). It feels natural to someone who is used to working with a DOM (esp SVG), and can handle thousands of items without much trouble.

Zoom can appear at either level here - multiple coord systems, or make the "zoom" part of the "shape" API. You're totally correct that scaling need not happen at the "canvas level" - while the MDN link I gave seems to imply that, it really is just trying to make it easier for the developer to not need to think about one more "layer" of ways that their data needs to be transformed. From a certain perspective, you might want to just have a transform matrix that you apply to each shape, and compose your zoom-because-zoom-widget, translate-because-panning, rotate, etc operations all at that level, and just apply the transform once when drawing (or even apply to the coords before you call in to canvas). None of it matters as long as the math is correct.

If you need more power, odds are you can find pretty quickly where the "unnecessary" O(n^2) or O(n lg n) operations are taking place (sorted insertion by z-index, solving for intersections, etc), and can do a better job partitioning "shapes" or go all out and drop down to just "business logic drives canvas commands" where it is required.

performance wise, I've done fully animated person relation networks and animated dashboards in large canvases for nearly a decade now.
We've never ran into any performance issues.
That being said, I think the views and on-screen actions we used were somewhat limited when compared to developing a game with full world rendering or something similar.

Did I already say I love this gwt group? It makes me think a lot more about what I am doing and why I am doing it.
Plus the input from the GWT devs usually give me insights I haven't thought about before or didn't know existed.
If you can stand the stream of discussion, you may also enjoy https://matrix.to/#/#gwtproject_gwt:gitter.im. It tends to be more conversational, and can get into the weeds in unrelated topics like this.

On Sat, Feb 8, 2025 at 2:56 AM Colin Alworth <co...@colinalworth.com> wrote:
I'm sorry if my message confused the two kinds of 'zoom' being discussed here - there's the one where the pixels on the physical monitor don't match the pixels of your display (this covers both HDPI and ctrl +/-), and there's the one where the user clicks the + icon (drawn on the canvas) to make everything inside a specific rectangle bigger.

The context2d.scale() method can do both, but I was mostly referring to the first, adapting to the user's current monitor+settings at any given time. Note that in this context, scale() does _not_ make things blurry when you zoom, but effectively multiplies all your coordinates by the scale. The canvas "height" and "width" (the "actual size" in the link's code sample) are what makes things blurry or super precise.

In the second case, scale() can still be totally appropriate, especially if coupled with a "panning" feature, or if data is updating. Odds are very high that in those cases, the parts of the canvas outside the "rectangle" aren't moving - all the various controls, the rectangle itself. Avoiding redrawing whatever you can each frame is important for performance. Or, you can just adjust your coordinate system when projecting on to the canvas, multiplying by your current zoom factor for each position - as above, it is doing the same thing.

While we're discussing it, clipping (with save/restore or without) still also be helpful to conserve rewrites too - if you had a single canvas element, you would clip to inside the rectangle, clear, and redraw only what is in there - save() and restore() are a valid way of handling that, or just reapply state at each pass. If you're careful, you could even just redraw a subset of the rectangle's contents - solve for which items actually changed (doing some intersection math), and clip+clearRect just that section, then redraw just what is in there. If you "draw" a little outside the clip in any of these cases, no big deal - it will get clipped out (but you'll still pay for the code to run, it just won't have any overdraw).

If you think about this like "partitioning" the drawing area with clip, there are two other ways to partition too - you can "tile" canvases, selectively redrawing their entire contents if they are affected, and you can "layer" them, using transparency to enable lower layers or higher layers to remain intact when other layers need to be cleared and repainted. Tiling can also work with non-homogenous blocks - the "rectangle" above could be one canvas, and the "controls" could be in their own.

On Friday, February 7, 2025 at 5:11:41 PM UTC-6 ma...@craig-mitchell.com wrote:
> I would not use the scale functionality as it applies to the whole canvas.

Whatever works for your project is best, however, the scale only applies when you set it. And you can always reset it. Eg:

// Save the current state
context2d.save();

// Apply zoom
context2d.scale(xxx, xxx);

// Draw zoomed stuff
...

// Reset the zoom
context2d.restore();

This also lets browsers use the GPU to render (although, I'm not actually sure if the scaling is done on the CPU or the GPU).

On Friday, 7 February 2025 at 5:02:17 pm UTC+11 Leon Pennings wrote:
I would not use the scale functionality as it applies to the whole canvas.
I'd prefer to apply an adapter pattern for determining actual coordinates on the canvas.
Then you can still have a toolbar, location display or slider for the zoom factor in it's normal proportions and just have the actual content you want to show in a different scale.

Op donderdag 6 februari 2025 om 13:33:12 UTC+1 schreef Colin Alworth:
No problem - I wanted to be sure I didn't make a mistake, since I haven't myself used canvas "in anger" in many years, and only loosely keep track of resources and advice on it.

SmartGWT's "Draw" examples make the API look very similar to the GXT "draw" packages - it isn't really a raster API at all, but a vector API that just happens to be built on top of a canvas implementation.

My recollection is that for fewer than around 1k-10k drawn items, SVG is faster and simpler to understand than canvas, and canvas's benefits only start kicking in when the DOM gets too heavy to manipulate quickly each frame. Looking briefly at the example page you shared a few weeks ago, if you were interested in getting into the low level details of how to do the drawing, your case perhaps could stand being remade in plain SVG - always high resolution. The benefits may be mostly for your own understanding rather than any real observed performance improvements from running the page (that said: dropping SmartGWT would appear to drop almost 8mb of JS out of your 9+mb page).

On Wednesday, February 5, 2025 at 9:46:51 PM UTC-6 ne...@propfinancing.com wrote:
> Neil, I'm not sure where I appeared to have said that.

I am sorry, I did not intend to put words in your mouth.
That was my understanding from your previous email stating
that canvas is a raster format. I misinterpreted your statements.

I apologize for that.

Thank you,
Neil

--
Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com
We offer 30 year loans on single family houses!

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/E3P4xZ8SFCg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/0e1b79f7-fa2e-482f-899b-65c5e9ca3e72n%40googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/E3P4xZ8SFCg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/c66862dd-bcfc-4516-b2bf-c5dc17a73deen%40googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/E3P4xZ8SFCg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/7299cb42-a00a-415a-b6a6-c8718ce1f9ddn%40googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/E3P4xZ8SFCg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/778e24ce-c26e-4170-a346-755129440140n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/CABjQu7StqePOQbD3huLVUBtYH2rQnSO8RNqaQO5Y%2BK_Gx6GhRA%40mail.gmail.com.

Re: Suggestion on upgrading gwt-2.6.1 to latest

Sorry if I was unclear - FP vs OO vs whatever really shouldn't matter. I only brought it up because you mentioned "OO style" driving some choices. The nature of the Canvas APIs shouldn't need to drive how you use them, until you are so starved for performance that you can't afford any indirection at all.

I don't think it is fair to call it the current trend - to anyone. Java upped its FP game in Java 8, 10 years ago - and I don't think anyone will argue that Java ever gets to the party early, without years of deliberation. JavaScript is perfectly usable as a functional language (debatably more so than than Java even today, since we still need SAM interfaces and can't just pass functions directly) and has been for 30 years since it was first released.

React's strategy effectively required that they adopt a "stateless" paradigm, which lends itself very well to encouraging (ostensibly) pure functions for rendering, that accept the state/props as an argument.

On Sunday, February 9, 2025 at 2:39:00 AM UTC-6 leon.p...@gmail.com wrote:

Switching to functional is the current trend I guess. Now you can argue whether or not it's smart to change design approach because it's a trend. As a framework - probably yes as you get higher adoption rates.
As an application developer probably not - as it just creates extra maintenance for when the next trend comes around.

On Sun, Feb 9, 2025 at 12:30 AM Craig Mitchell <ma...@craig-mitchell.com> wrote:
> OO vs procedural/functional is quite the different design approach. I would even say that those are worlds apart.

Tell that to the React creators, that switched the framework from OO to functional. 😝

On Sunday, 9 February 2025 at 8:49:40 am UTC+11 Leon wrote:
I can see where you say a developer familiar with the DOM is more likely to work with on the canvas api directly.
And yes, the more technical options the better. Sure.
But I do not see how you can say that an OO vs procedural or functional approach is not that relevant? OO vs procedural/functional is quite the different design approach. I would even say that those are worlds apart. In what way do you think that this difference not relevant?

On Sat, Feb 8, 2025 at 8:53 PM Colin Alworth <co...@colinalworth.com> wrote:

@Craig - If you draw everything on the same canvas, the zoom/scale works on everything on that canvas. it limits what you can do with that canvas. If you want to scale or zoom everything, yes then it doesn't matter. So yes you are right, it depends on the project.
This isn't true, it only applied on the operations that take place while it is set. You can call scale(1, 1) to go back to 1:1, or you can use the save()/restore() that Craig mentioned. You can also clip to keep the zoomed content within certain bounds.
@Colin - With multiple layers I would also need multiple canvas's and overlay them right?
Correct - each would have its own frame buffer, and could be cleared/drawn independently.

We wrote a single adapter widget that uses a single canvas. This adapter widget knows what the zoom level is. Objects that are drawn on that widget of a certain type get zoomed, whilst others of a different type do not. It is super simple and easily explained to new devs. Everyone on the team can add views or objects and the type determines how these are displayed. Even devs without exact knowledge of how the canvas works can develop and maintain objects to be displayed.

I guess it's also a development style/preference thing. If you code the view of the canvas in a single class or single method, the solution is likely to have to rely more on the technological capabilities of the canvas. Working with an adapter then does not really make a lot of sense.
If you have more of an OO style of development, you express more in functional blocks. Then you have to rely less on the technical capabilities as you can translate what needs to be done on the basis of what your objects are before you hit the canvas. Then the zooming/scaling happens in the object, not on the canvas so to speak.
So the required functionality of the canvas remains fairly basic.
I don't make these suggestions lightly - if you are happy with how canvas performs and the quality of the output, then you may well never need them, but it can be fun to know they exist.

I don't much care about OO vs FP styles for this - building an API around these features should be straightforward within whatever paradigm you prefer. For most projects we ended up with roughly two layers of abstractions - the "shapes that get drawn on the screen via canvas commands" abstraction (iterate through "shapes", respect their "z-index" or other relative positioning, capture clicks and figure out which "shape" was clicked on, redraw only changed "shapes" and those that intersect them, etc), and the "business logic drives what shapes to draw" abstraction ("I want a pie chart in the corner, compute slices based on data", "these buttons over here control those axes", "Labeled items in the legend will drive which stars/circles in the chart are highlighted when hovered"). It feels natural to someone who is used to working with a DOM (esp SVG), and can handle thousands of items without much trouble.

Zoom can appear at either level here - multiple coord systems, or make the "zoom" part of the "shape" API. You're totally correct that scaling need not happen at the "canvas level" - while the MDN link I gave seems to imply that, it really is just trying to make it easier for the developer to not need to think about one more "layer" of ways that their data needs to be transformed. From a certain perspective, you might want to just have a transform matrix that you apply to each shape, and compose your zoom-because-zoom-widget, translate-because-panning, rotate, etc operations all at that level, and just apply the transform once when drawing (or even apply to the coords before you call in to canvas). None of it matters as long as the math is correct.

If you need more power, odds are you can find pretty quickly where the "unnecessary" O(n^2) or O(n lg n) operations are taking place (sorted insertion by z-index, solving for intersections, etc), and can do a better job partitioning "shapes" or go all out and drop down to just "business logic drives canvas commands" where it is required.

performance wise, I've done fully animated person relation networks and animated dashboards in large canvases for nearly a decade now.
We've never ran into any performance issues.
That being said, I think the views and on-screen actions we used were somewhat limited when compared to developing a game with full world rendering or something similar.

Did I already say I love this gwt group? It makes me think a lot more about what I am doing and why I am doing it.
Plus the input from the GWT devs usually give me insights I haven't thought about before or didn't know existed.
If you can stand the stream of discussion, you may also enjoy https://matrix.to/#/#gwtproject_gwt:gitter.im. It tends to be more conversational, and can get into the weeds in unrelated topics like this.

On Sat, Feb 8, 2025 at 2:56 AM Colin Alworth <co...@colinalworth.com> wrote:
I'm sorry if my message confused the two kinds of 'zoom' being discussed here - there's the one where the pixels on the physical monitor don't match the pixels of your display (this covers both HDPI and ctrl +/-), and there's the one where the user clicks the + icon (drawn on the canvas) to make everything inside a specific rectangle bigger.

The context2d.scale() method can do both, but I was mostly referring to the first, adapting to the user's current monitor+settings at any given time. Note that in this context, scale() does _not_ make things blurry when you zoom, but effectively multiplies all your coordinates by the scale. The canvas "height" and "width" (the "actual size" in the link's code sample) are what makes things blurry or super precise.

In the second case, scale() can still be totally appropriate, especially if coupled with a "panning" feature, or if data is updating. Odds are very high that in those cases, the parts of the canvas outside the "rectangle" aren't moving - all the various controls, the rectangle itself. Avoiding redrawing whatever you can each frame is important for performance. Or, you can just adjust your coordinate system when projecting on to the canvas, multiplying by your current zoom factor for each position - as above, it is doing the same thing.

While we're discussing it, clipping (with save/restore or without) still also be helpful to conserve rewrites too - if you had a single canvas element, you would clip to inside the rectangle, clear, and redraw only what is in there - save() and restore() are a valid way of handling that, or just reapply state at each pass. If you're careful, you could even just redraw a subset of the rectangle's contents - solve for which items actually changed (doing some intersection math), and clip+clearRect just that section, then redraw just what is in there. If you "draw" a little outside the clip in any of these cases, no big deal - it will get clipped out (but you'll still pay for the code to run, it just won't have any overdraw).

If you think about this like "partitioning" the drawing area with clip, there are two other ways to partition too - you can "tile" canvases, selectively redrawing their entire contents if they are affected, and you can "layer" them, using transparency to enable lower layers or higher layers to remain intact when other layers need to be cleared and repainted. Tiling can also work with non-homogenous blocks - the "rectangle" above could be one canvas, and the "controls" could be in their own.

On Friday, February 7, 2025 at 5:11:41 PM UTC-6 ma...@craig-mitchell.com wrote:
> I would not use the scale functionality as it applies to the whole canvas.

Whatever works for your project is best, however, the scale only applies when you set it. And you can always reset it. Eg:

// Save the current state
context2d.save();

// Apply zoom
context2d.scale(xxx, xxx);

// Draw zoomed stuff
...

// Reset the zoom
context2d.restore();

This also lets browsers use the GPU to render (although, I'm not actually sure if the scaling is done on the CPU or the GPU).

On Friday, 7 February 2025 at 5:02:17 pm UTC+11 Leon Pennings wrote:
I would not use the scale functionality as it applies to the whole canvas.
I'd prefer to apply an adapter pattern for determining actual coordinates on the canvas.
Then you can still have a toolbar, location display or slider for the zoom factor in it's normal proportions and just have the actual content you want to show in a different scale.

Op donderdag 6 februari 2025 om 13:33:12 UTC+1 schreef Colin Alworth:
No problem - I wanted to be sure I didn't make a mistake, since I haven't myself used canvas "in anger" in many years, and only loosely keep track of resources and advice on it.

SmartGWT's "Draw" examples make the API look very similar to the GXT "draw" packages - it isn't really a raster API at all, but a vector API that just happens to be built on top of a canvas implementation.

My recollection is that for fewer than around 1k-10k drawn items, SVG is faster and simpler to understand than canvas, and canvas's benefits only start kicking in when the DOM gets too heavy to manipulate quickly each frame. Looking briefly at the example page you shared a few weeks ago, if you were interested in getting into the low level details of how to do the drawing, your case perhaps could stand being remade in plain SVG - always high resolution. The benefits may be mostly for your own understanding rather than any real observed performance improvements from running the page (that said: dropping SmartGWT would appear to drop almost 8mb of JS out of your 9+mb page).

On Wednesday, February 5, 2025 at 9:46:51 PM UTC-6 ne...@propfinancing.com wrote:
> Neil, I'm not sure where I appeared to have said that.

I am sorry, I did not intend to put words in your mouth.
That was my understanding from your previous email stating
that canvas is a raster format. I misinterpreted your statements.

I apologize for that.

Thank you,
Neil

--
Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com
We offer 30 year loans on single family houses!

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/E3P4xZ8SFCg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/0e1b79f7-fa2e-482f-899b-65c5e9ca3e72n%40googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/E3P4xZ8SFCg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/c66862dd-bcfc-4516-b2bf-c5dc17a73deen%40googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/E3P4xZ8SFCg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/7299cb42-a00a-415a-b6a6-c8718ce1f9ddn%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/778e24ce-c26e-4170-a346-755129440140n%40googlegroups.com.

Sunday, February 9, 2025

Re: Suggestion on upgrading gwt-2.6.1 to latest

Switching to functional is the current trend I guess. Now you can argue whether or not it's smart to change design approach because it's a trend. As a framework - probably yes as you get higher adoption rates.

As an application developer probably not - as it just creates extra maintenance for when the next trend comes around.

On Sun, Feb 9, 2025 at 12:30 AM Craig Mitchell <mail@craig-mitchell.com> wrote:

> OO vs procedural/functional is quite the different design approach. I would even say that those are worlds apart.

Tell that to the React creators, that switched the framework from OO to functional. 😝

On Sunday, 9 February 2025 at 8:49:40 am UTC+11 Leon wrote:
I can see where you say a developer familiar with the DOM is more likely to work with on the canvas api directly.
And yes, the more technical options the better. Sure.
But I do not see how you can say that an OO vs procedural or functional approach is not that relevant? OO vs procedural/functional is quite the different design approach. I would even say that those are worlds apart. In what way do you think that this difference not relevant?

On Sat, Feb 8, 2025 at 8:53 PM Colin Alworth <co...@colinalworth.com> wrote:

@Craig - If you draw everything on the same canvas, the zoom/scale works on everything on that canvas. it limits what you can do with that canvas. If you want to scale or zoom everything, yes then it doesn't matter. So yes you are right, it depends on the project.
This isn't true, it only applied on the operations that take place while it is set. You can call scale(1, 1) to go back to 1:1, or you can use the save()/restore() that Craig mentioned. You can also clip to keep the zoomed content within certain bounds.
@Colin - With multiple layers I would also need multiple canvas's and overlay them right?
Correct - each would have its own frame buffer, and could be cleared/drawn independently.

We wrote a single adapter widget that uses a single canvas. This adapter widget knows what the zoom level is. Objects that are drawn on that widget of a certain type get zoomed, whilst others of a different type do not. It is super simple and easily explained to new devs. Everyone on the team can add views or objects and the type determines how these are displayed. Even devs without exact knowledge of how the canvas works can develop and maintain objects to be displayed.

I guess it's also a development style/preference thing. If you code the view of the canvas in a single class or single method, the solution is likely to have to rely more on the technological capabilities of the canvas. Working with an adapter then does not really make a lot of sense.
If you have more of an OO style of development, you express more in functional blocks. Then you have to rely less on the technical capabilities as you can translate what needs to be done on the basis of what your objects are before you hit the canvas. Then the zooming/scaling happens in the object, not on the canvas so to speak.
So the required functionality of the canvas remains fairly basic.
I don't make these suggestions lightly - if you are happy with how canvas performs and the quality of the output, then you may well never need them, but it can be fun to know they exist.

I don't much care about OO vs FP styles for this - building an API around these features should be straightforward within whatever paradigm you prefer. For most projects we ended up with roughly two layers of abstractions - the "shapes that get drawn on the screen via canvas commands" abstraction (iterate through "shapes", respect their "z-index" or other relative positioning, capture clicks and figure out which "shape" was clicked on, redraw only changed "shapes" and those that intersect them, etc), and the "business logic drives what shapes to draw" abstraction ("I want a pie chart in the corner, compute slices based on data", "these buttons over here control those axes", "Labeled items in the legend will drive which stars/circles in the chart are highlighted when hovered"). It feels natural to someone who is used to working with a DOM (esp SVG), and can handle thousands of items without much trouble.

Zoom can appear at either level here - multiple coord systems, or make the "zoom" part of the "shape" API. You're totally correct that scaling need not happen at the "canvas level" - while the MDN link I gave seems to imply that, it really is just trying to make it easier for the developer to not need to think about one more "layer" of ways that their data needs to be transformed. From a certain perspective, you might want to just have a transform matrix that you apply to each shape, and compose your zoom-because-zoom-widget, translate-because-panning, rotate, etc operations all at that level, and just apply the transform once when drawing (or even apply to the coords before you call in to canvas). None of it matters as long as the math is correct.

If you need more power, odds are you can find pretty quickly where the "unnecessary" O(n^2) or O(n lg n) operations are taking place (sorted insertion by z-index, solving for intersections, etc), and can do a better job partitioning "shapes" or go all out and drop down to just "business logic drives canvas commands" where it is required.

performance wise, I've done fully animated person relation networks and animated dashboards in large canvases for nearly a decade now.
We've never ran into any performance issues.
That being said, I think the views and on-screen actions we used were somewhat limited when compared to developing a game with full world rendering or something similar.

Did I already say I love this gwt group? It makes me think a lot more about what I am doing and why I am doing it.
Plus the input from the GWT devs usually give me insights I haven't thought about before or didn't know existed.
If you can stand the stream of discussion, you may also enjoy https://matrix.to/#/#gwtproject_gwt:gitter.im. It tends to be more conversational, and can get into the weeds in unrelated topics like this.

On Sat, Feb 8, 2025 at 2:56 AM Colin Alworth <co...@colinalworth.com> wrote:
I'm sorry if my message confused the two kinds of 'zoom' being discussed here - there's the one where the pixels on the physical monitor don't match the pixels of your display (this covers both HDPI and ctrl +/-), and there's the one where the user clicks the + icon (drawn on the canvas) to make everything inside a specific rectangle bigger.

The context2d.scale() method can do both, but I was mostly referring to the first, adapting to the user's current monitor+settings at any given time. Note that in this context, scale() does _not_ make things blurry when you zoom, but effectively multiplies all your coordinates by the scale. The canvas "height" and "width" (the "actual size" in the link's code sample) are what makes things blurry or super precise.

In the second case, scale() can still be totally appropriate, especially if coupled with a "panning" feature, or if data is updating. Odds are very high that in those cases, the parts of the canvas outside the "rectangle" aren't moving - all the various controls, the rectangle itself. Avoiding redrawing whatever you can each frame is important for performance. Or, you can just adjust your coordinate system when projecting on to the canvas, multiplying by your current zoom factor for each position - as above, it is doing the same thing.

While we're discussing it, clipping (with save/restore or without) still also be helpful to conserve rewrites too - if you had a single canvas element, you would clip to inside the rectangle, clear, and redraw only what is in there - save() and restore() are a valid way of handling that, or just reapply state at each pass. If you're careful, you could even just redraw a subset of the rectangle's contents - solve for which items actually changed (doing some intersection math), and clip+clearRect just that section, then redraw just what is in there. If you "draw" a little outside the clip in any of these cases, no big deal - it will get clipped out (but you'll still pay for the code to run, it just won't have any overdraw).

If you think about this like "partitioning" the drawing area with clip, there are two other ways to partition too - you can "tile" canvases, selectively redrawing their entire contents if they are affected, and you can "layer" them, using transparency to enable lower layers or higher layers to remain intact when other layers need to be cleared and repainted. Tiling can also work with non-homogenous blocks - the "rectangle" above could be one canvas, and the "controls" could be in their own.

On Friday, February 7, 2025 at 5:11:41 PM UTC-6 ma...@craig-mitchell.com wrote:
> I would not use the scale functionality as it applies to the whole canvas.

Whatever works for your project is best, however, the scale only applies when you set it. And you can always reset it. Eg:

// Save the current state
context2d.save();

// Apply zoom
context2d.scale(xxx, xxx);

// Draw zoomed stuff
...

// Reset the zoom
context2d.restore();

This also lets browsers use the GPU to render (although, I'm not actually sure if the scaling is done on the CPU or the GPU).

On Friday, 7 February 2025 at 5:02:17 pm UTC+11 Leon Pennings wrote:
I would not use the scale functionality as it applies to the whole canvas.
I'd prefer to apply an adapter pattern for determining actual coordinates on the canvas.
Then you can still have a toolbar, location display or slider for the zoom factor in it's normal proportions and just have the actual content you want to show in a different scale.

Op donderdag 6 februari 2025 om 13:33:12 UTC+1 schreef Colin Alworth:
No problem - I wanted to be sure I didn't make a mistake, since I haven't myself used canvas "in anger" in many years, and only loosely keep track of resources and advice on it.

SmartGWT's "Draw" examples make the API look very similar to the GXT "draw" packages - it isn't really a raster API at all, but a vector API that just happens to be built on top of a canvas implementation.

My recollection is that for fewer than around 1k-10k drawn items, SVG is faster and simpler to understand than canvas, and canvas's benefits only start kicking in when the DOM gets too heavy to manipulate quickly each frame. Looking briefly at the example page you shared a few weeks ago, if you were interested in getting into the low level details of how to do the drawing, your case perhaps could stand being remade in plain SVG - always high resolution. The benefits may be mostly for your own understanding rather than any real observed performance improvements from running the page (that said: dropping SmartGWT would appear to drop almost 8mb of JS out of your 9+mb page).

On Wednesday, February 5, 2025 at 9:46:51 PM UTC-6 ne...@propfinancing.com wrote:
> Neil, I'm not sure where I appeared to have said that.

I am sorry, I did not intend to put words in your mouth.
That was my understanding from your previous email stating
that canvas is a raster format. I misinterpreted your statements.

I apologize for that.

Thank you,
Neil

--
Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com
We offer 30 year loans on single family houses!

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/E3P4xZ8SFCg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/0e1b79f7-fa2e-482f-899b-65c5e9ca3e72n%40googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/E3P4xZ8SFCg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/c66862dd-bcfc-4516-b2bf-c5dc17a73deen%40googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/E3P4xZ8SFCg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/7299cb42-a00a-415a-b6a6-c8718ce1f9ddn%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/CABjQu7SHp-%3DZV7O45xK0S2RpbXrM0A9EdWcy3seovy68wEEZdQ%40mail.gmail.com.