Did you try to save settings via context menu? It does exactly the same as my custom code.
When you select “Draw in new tab”, you also can also specify alternative draw option for it.
But default with draw option is empty
I right-clicked on the “loaded” ROOT file name and executed “Settings → Save settings”.
Still, “Draw in new tab” does not see them.
1 Like
Can you try to adjust settings and store them in the newly opened window?
Cookies are assigned per web-site. If web-site address in URL string differs between original page and “Draw in new tab” page - cookies will not be reused
I started to suspect that my browser has some “protection” against my cookies, but now I think you found the reason.
I open my web page as:
http://localhost:8080/trial/trial.html
Then, from inside, I load your “jsroot.gsi.de” and the “Draw in new tab” opens:
https://jsroot.gsi.de/dev/?nobrowser&file=http://localhost:8080/MyData/MyFile.root&item=MyCancas;1&opt=
So, the created “localhost” cookies are not used at all.
The only way to have cookies working would be to “deploy” your JSROOT source code on my “localhost”, right?
I think I will try to play with it tomorrow.
I’ve got a question, though.
According to your source code, the “saveStyle(); saveSettings();” create two cookies named, respectively, “jsroot_style” and “jsroot_settings”.
I assume the JSROOT is, by default, “sensitive” to these unique names.
What if I change these names to make sure that they are specific to my “trial” (like “jsroot_style_trial” and “jsroot_settings_trial”)?
Can I ensure the “Draw in new tab” will use my “private” names?
I find standard/default “website address” cookies a bit problematic.
You may have/run different web pages there; each may want its own “defaults”.
So, I would prefer cookies’ names that are specific to my current web page, which are then automatically “inherited” in all tabs that are “spawned” by this web page (e.g., when executing “Draw in new tab”).
Yes,
Cookies names must be “default” - otherwise one cannot use them without providing extra URL parameters again. I do not think this is right way to go.
I think I disagree here.
Imagine a single web server that provides web pages for different experiments, detectors (from different experiments), and sub-detectors (from some specific experiment), and you need to inspect them “simultaneously”.
We need a way to ensure the settings are specific to the “mother’s” web page (which “spawns” new tabs).
Yes, that will probably need an extra (user-defined) URL parameter in JSROOT.
I revise code a little bit.and switch from cookies to browser local storage:
Advantage that local storage is not transmitted in http requests.
If it is really necessary, one could change prefix for the parameters stored there.
Just add &storage_prefix=any_custom_name.
Many thanks for working on it.
I tried your newest version, with “saveStyle(); saveSettings();” (I did not set/modify the “prefix”), but the “Draw in new tab” still doesn’t inherit them.
Maybe it’s still the “localhost” versus “jsroot.gsi.de” problem (like for the cookies)?
It is exactly the reason.
localStorage (which is now used instead of cookies) cannot be accessed from different domains.
Well, from my “localhost” script, I directly load your “jsroot.gsi.de” to always get the most recent “dev” version.
Maybe I could help myself with some trick.
The “Draw in new tab” opens a new tab with an empty " &opt=".
Would it be possible to cheat JSROOT so that it thinks the “option” is “&optdate=3&optfile=3”?
Then one would get “&opt=&optdate=3&optfile=3”, which seems to be working fine.
Ok, I extend functionality how URL is produced.
Now settings has following parameters.
/** @summary Page URL which will be used to show item in new tab, jsroot main dir used by default */
NewTabUrl: '',
/** @summary Extra parameters which will be append to the url when item shown in new tab */
NewTabUrlPars: '',
/** @summary Export different settings in output URL */
NewTabUrlExportSettings: false
You can specify URL of the page which will be used for drawing items:
settings.NewTabUrl = 'http://localhost:8877/jsrootsys/';
This can let you use local storage - if server is the same.
You can specify custom parameters like:
settings.NewTabUrlPars = 'optdate=3&optfile=3'
You also can let JSROOT put most (not all) of custom settings back into URL:
settings.NewTabUrlExportSettings = true;
It is up to you which solution to use.
Many thanks.
For my test purposes, I cannot use/try “settings.NewTabUrl”, because I do not have “/jsrootsys/” installed (the JSROOT always comes directly from your “jsroot.gsi.de”).
The “settings.NewTabUrlPars” and the “settings.NewTabUrlExportSettings” work great (note: I assume they can only pass the “gStyle” settings, not the “settings.ToolBarVert”, which remains “horizontal” in the new tab).
BTW. Perhaps it’s just my personal preference, but … I’ve been thinking that maybe the “optdate” should automatically switch the left “tool buttons” vertically, and the “optfile” should automatically switch the right “tool buttons” vertically (additionally, one would not need to care about the “settings.ToolBarVert” not being transferred to the new tab). Maybe even more general … if any “status line” is displayed at the bottom, switch both “tool buttons” vertically.
Could you maybe try to play with the “tool buttons”?
There are still two problems.
-
When the “
optdate” is used (down-left), the left “tool buttons” need to be switched vertically. One can then clearly see both (enough space is available in the down-left corner for the first “Toogle tool buttons” button). -
When the “
optfile” is used (down-right), the right “tool buttons” need to be switched vertically. But there is still a problem … the final two characters of the “optfile” field still cover the first “Toogle tool buttons” button. I think one needs to move the “optfile” field to the left (so that enough space is always available in the down-right corner for this first button). -
As said above, if any “status line” is displayed at the bottom, one must switch both “tool buttons” vertically. I proposed to do it always automatically, but … if you do not think it is a good idea …with the “
settings.NewTabUrlExportSettings”, the “optdate” and “optfile” are nicely transferred to the new tabs created by the “Draw in new tab”. Unfortunately, the “settings.ToolBarVert” is not transferred (both “tool buttons”, down-left and down-right, are always created horizontally). So, maybe another custom parameter (“transferable”) could be added that would care about it (e.g., something like “&optimize_layout” that could later also be used for other “fancy features”)?
I agree - with “optdate” and “optfie” options tool buttons overlay them.
Therefore I add simple fix - if any of such option appears toolbar automatically set to vertical orientation.
The automatic “tool buttons” orientation works well. Many thanks.
There is still a tiny problem.
If multiple pads are displayed in a single canvas, each gets the “tool buttons” drawn down-right (which is nice).
The problem is with the pad, which uses the most down-right part of the canvas.
Then the very first button of its “tool buttons” (the “Toogle tool buttons”) is covered by the last two characters of the drawn “optfile” field (this problem is not present if the canvas contains a single pad only because then the down-right “tool buttons” are not drawn at all).
Would it be possible to limit the space that the “optfile” field is allowed to use so that enough space is always available in the most down-right canvas corner for this first button?
These are gStyle.fDateX and gStyle.fDateY. Default is 0.01, but can be modified as well.
Like:
gStyle.fDateX = 0.03
This will shift both date and file labels from pad boundary.
I have found that “0.03” is still too small, and one needs: gStyle.fDateX = 0.04;
Maybe you could change the built-in default value from “0.01” to “0.04”?
It seems you reset this parameter to its built-in default value on different occasions:
[..]$ grep -r fDateX jsroot
jsroot/build/jsroot.js: fDateX: 0.01,
jsroot/build/jsroot.js: this.addSizeMenu('Date X', 0.01, 0.1, 0.01, gStyle.fDateX, x => { gStyle.fDateX = x; }, 'configure gStyle.fDateX for date/item name drawings');
jsroot/modules/core.mjs: fDateX: 0.01,
jsroot/modules/gui/menu.mjs: this.addSizeMenu('Date X', 0.01, 0.1, 0.01, gStyle.fDateX, x => { gStyle.fDateX = x; }, 'configure gStyle.fDateX for date/item name drawings');
There are some problems with it …
-
If I set it (in my script) before “
buildGUI('simpleGUI');”, my setting will not be used (i.e., one needs to change it from the default “0.01” to “0.04” AFTER the GUI is “built”). Note: the “optdate” and “optfile” can be set anywhere. -
It is not transferred to the new tab created by the “
Draw in new tab” (i.e., with the “settings.NewTabUrlExportSettings”, one always gets the default “0.01” in the new tab).
0.01 is default value from TStyle class. I prefer to keep it.
jsroot.js is special packaging of JSROOT code. It can be loaded as normal JavaScript code - without modules. Therefore it is normal that code duplicated there.
I cannot confirm this. I can insert gStyle.fDateX = 0.04 here in this demo (with proper import) and it works for me. Maybe you are using external gStyle object?
It is same story as many other settings. In dev branch I add datex and datey URL parameters which are exported as optdate and optfile ones.
Many thanks for the “datex” (works fine).
For the problem with the “statements ordering”:
import { gStyle, settings } from 'https://jsroot.gsi.de/dev/modules/core.mjs';
settings.NewTabUrlExportSettings = true; // "optdate", "optfile", and "datex" work
gStyle.fOptFile = 3; // works fine
gStyle.fOptDate = 3; // works fine
gStyle.fDateX = 0.04; // this does NOT work (one gets the default 0.01 anyhow)
import { buildGUI } from 'https://jsroot.gsi.de/dev/modules/gui.mjs';
buildGUI('simpleGUI');
gStyle.fDateX = 0.04; // only this works
Most probably you store settings in the browser local store.
You can delete them via context menu.