Hello Bob. Thanks for starting this thread. On 18/03/2019 12:00, Robert Hanson wrote: > Working on the frame embedding idea: > > 1) Objective is to make any window embeddable, exactly like the applet. > 2) This could take several forms. > 3) 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: <div><script>jalviewjs.render(alignmentfile: 'uniref50.fa')</script></div> 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.
_______________________________________________ Jalview-dev mailing list [email protected] http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-dev
