@DavidWilla it seems you can build such a thing based on CSS and JS: https://www.w3schools.com/howto/howto_js_image_magnifier_glass.asp
In this case it maybe possible to use DOM and CSS to do the job...
Or you take JS framework and wrap it with JsInterop: https://mark-rolich.github.io/Magnifier.js
@/all A new Nalu version is released. 2.6.0 for GWT 2.9.0 (https://github.com/NaluKit/nalu/releases/tag/v2.6.0) and version 2.6.0-gwt-2.8.2 (https://github.com/NaluKit/nalu/releases/tag/v2.6.0-gwt-2.8.2). Besides a few bug fixes there is a new feature added: constraints for parameter inside a route. Here you find more informations: https://github.com/NaluKit/nalu/wiki/14.-Controllers-&-Composites#parameters
you can copy the modified js (esp in SDM, installScriptDirect.js) into your own project and test that way, see workaround at gwtproject/gwt#9734
if your bug only happens in SDM, this is likely the cause
Hi @niloc132 , thx for the fast response. I think my problem is related to:
https://bugs.chromium.org/p/chromium/issues/detail?id=17356#c107
https://docs.google.com/document/d/1_GxIGRvv8ATp3GMhA3jUfVFxGKMWEkFWvtqsSS7QQ2M/edit
In the generated javascript for all method the "displayName" will be added by setting the -XmethodNameDisplayMode ABBREVIATED compiler parameter.
jsMethod.displayName = "ClassName.methodeName". This needs to replaced somehow now with Object.defineProperty(jsMethod, "name", {value: "ClassName.methodeName"});
https://bugs.chromium.org/p/chromium/issues/detail?id=17356#c107
https://docs.google.com/document/d/1_GxIGRvv8ATp3GMhA3jUfVFxGKMWEkFWvtqsSS7QQ2M/edit
In the generated javascript for all method the "displayName" will be added by setting the -XmethodNameDisplayMode ABBREVIATED compiler parameter.
jsMethod.displayName = "ClassName.methodeName". This needs to replaced somehow now with Object.defineProperty(jsMethod, "name", {value: "ClassName.methodeName"});
unless i'm mistaken, we now have to do both, not replace jsMethod.displayName, since other browsers ... still exist
or do other browsers prefer name to displayName, and gwt just stuck with displayName because it implemented the first de facto standard?
according to OptionMethodNameDisplayMode (the class which handles the arg you mentioned) this function name stuff is for chrome dev tools specifically
the createAssignment will need to be replaced (... or appended to), with the function call, object decl you described
Yep
if you're interested in good debugging (in SDM?), take a look at the patch i linked? someone else noticed that stack traces break in SDM or any "i loaded my gwt module from another origin", and i also noticed that promise events don't work either in this case, but only in chrome
ha looks like we can, that's terrible
addMethodDefinitionStatement only wants JsExprStmts to be added to it
and only one, since outputDisplayName is expected to return a single thing
maybe a second set of statements in the emitMethodImplementation's if check instead
would like to check back in with @tbroyer, last i heard he was close to a satisfactory way of starting groupId migration, but i never heard back on how that went
@rdeangelis83
private void emitMethodImplementation(JMethod method, JsNameRef functionNameRef,
JsExprStmt methodDefinitionStatement) {
addMethodDefinitionStatement(method, methodDefinitionStatement);
if (shouldEmitDisplayNames()) {
addMethodDefinitionStatement(method, outputDisplayName(functionNameRef, method));
addMethodDefinitionStatement(method, outputFunctionNameProperty(functionNameRef, method));
}
}
private void generatePrototypeDefinitionAlias(JMethod method, JsName alias) {
JsName polyName = polymorphicNames.get(method);
JsExpression bridge = JsUtils.createBridge(method, polyName, topScope);
// Aliases are never property accessors.
generatePrototypeAssignment(method, alias, bridge, JsMemberType.NONE);
}
private JsExprStmt outputDisplayName(JsNameRef function, JMethod method) {
JsNameRef displayName = new JsNameRef(function.getSourceInfo(), "displayName");
displayName.setQualifier(function);
String displayStringName = getDisplayName(method);
JsStringLiteral displayMethodName =
new JsStringLiteral(function.getSourceInfo(), displayStringName);
return createAssignment(displayName, displayMethodName).makeStmt();
}
private JsExprStmt outputFunctionNameProperty(JsNameRef function, JMethod method) {
String displayStringName = getDisplayName(method);
JsStringLiteral displayMethodName =
new JsStringLiteral(function.getSourceInfo(), displayStringName);
JsObjectLiteral descriptor = JsObjectLiteral.builder(function.getSourceInfo())
.add("value", displayMethodName)
.build();
JsStringLiteral prop = new JsStringLiteral(function.getSourceInfo(), "name");
return constructInvocation(function.getSourceInfo(), "Object.defineProperty", function, prop, descriptor).makeStmt();
}try that out, i think it is close (plus or minus formatting)
Apparently it needed more tests: https://groups.google.com/g/google-web-toolkit-contributors/c/L2RMqglOEXo/m/kCNHSaMeBwAJ (as noted in the project readme too)
needing more tests in gradle at least suggests someone proficient in gradle (i have done a lot of work since we last talked, but still consider it to be too complex to learn without already understanding it)
i am not aware of any significant sbt usage of maven, and only minimal ivy usage
Ha, that experiment-5 looked like those "more tests" actually; and prompted doing an experiment-6 deploying Gradle Module Metadata for GWT itself to confirm the early conclusions (so that gwt-user brings a "dependency constraint" on gwt-dev; similar to having the GWT BOM being transitively depended on). There would still be issues for Maven users not using the GWT BOM, that would have to be dealt with "manually" (using exclusions).
But experiment-4 could be regarded as "enough" (particularly for a RC, for instance), or even experiment-3 (experiment-4 actually adds an o.g→c.g.g relocation for older versions, so can be added later)
ok - so to briefly summarize (and possibly glossing over details), the "missing final post" to the thread could be assumed to say something like:
- with proposal-5, the gradle experience is acceptable
- maven requires the use of a bom to be sane, we will need to aggressively push this to any projects that updates either its gwt dependencies or any libraries that it uses, so we need to enlist library publishers to push the bom
oh, why drop back to 3 or 4 if 5 is strictly better for the gradle cases?
Well, 5 is "exercising" 4 with some external libraries; so as far as GWT is concerned, we would be "doing 4". And "doing 4" requires "doing 3" first (or next, actually).
In terms of setting up the deployment for a new version, the aim is experiment-3 (it's identical experiment-4 and experiment-5). The additions of experiment-4 could be done separately to "make things better".