Hello Bob. Thanks for starting this thread.
Working on the frame embedding idea:
-
Objective is to make any window embeddable, exactly like the applet.
-
This could take several forms.
-
Key is that all behavior would be the same.
I don’t really understand #3 - An embedded jalview window may be required to have a range of different functionality, and even exclude titles/menus/widgets and several interactive operations. Much of those could be filtered out at the Javascript level (e.g. click-drags to select could be masked) rather than filtering at the java level: I think a balance will be needed to empower JavaScript coders whilst absolutely ensuring they do not have to dig into Java/java2script-generated-JavaScript to achieve what they need.
Please discuss:
Framing:
a) Just like a frame, with frame closure buttons
b) Just like a frame, with title bar, but no closure buttons
c) Could be “undecorated” – no title or closure buttons
d) Visualization only - no border, menu bar, popup menu or other GUI widgets except scroll-bars if required (ideally all visualisations will have a fit to window/zoom parameter to control this also).
Orthogonally:
a’) Full interaction. All clicks/drags/etc are functional (including display of popup menus).
b’) Partial interaction. Only interactions essential for selection and navigation are provided.
c’) No interaction. Selection only.
d’) Static figure.
for c+(b’,c’,d’) I would provide a hover UI that allows access to image/data export functions.
Q: How to specify/decide?
Embedding:
a) Frame-specific embedding, using the frame’s setName() [as opposed to setTitle()] property.
b) Could be class-specific, using a class name instead of a frame name.
c) Could be (must be?) indicated on the page with a standing div of a syntactically specified id.
Not really sure about what a,b,c really mean here. I would like the mechanism for specifying how different GUI elements are embedded to be from a vanilla front-end developer’s perspective.
d) Could morph to the size indicated by div CSS or could override the size indicated by div CSS
+1 for first - Yuk to second. It should never override size - always adapt to computed layout (so it plays nicely in dashboards, and can adapt to different page geometries via device/adaptive layouts).
e) Directives could use the class attributes of the div
+1
f) Directives could be automatically transmitted to the frame’s clientProperties for discoverability in Java.
g) Some pages might be designed to take URI query information to load this into the Info block, but that’s not a Java issue, I think.
Agreed. A front end dev will also want to be able to disable any URI query processing from any SwingJS components they are using.
Menubar, PopupMenu, general “reduced” feature set:
My thinking here is that this is fully controllable by Java. Java just needs to have access to embedding information in the frame constructor in order to tune itself to its environment.
As a first approximation, yes. e.g. in c above, the context menu could provide access to the top-level JalviewJS menubar entries if need be (we already have a way to move those around which could be additionally taught to shunt them into the popup menu).
However, I would like to also see execution paths that bypass all top-level window creation machinery - ie a javascript call like:
yields a bare-bones visualisation of the alignment file (ie c+d' above). Of course, some refactoring of the java will be required to avoid dependencies on GUI classes when none are needed, but I'm sure they will be possible.
j.
···
On 18/03/2019 12:00, Robert Hanson wrote: