.rootlogon.C ignored when running TRootBrowser

[ktht]

Check duplicate issues.

• Checked for duplicates

Description

Just what the title says. The settings specified in .rootlogon.C are respected when using the web browser, but not when using the old-style GUI.

Reproducer

Add this to your .rootrc to enable the old-style GUI:

Browser.Name:               TRootBrowser

And these lines which I took from my .rootlogon.C to thicken up the lines and add grid lines:

void _rootlogon()
{
  gStyle->SetCanvasDefH(2*gStyle->GetCanvasDefH());
  gStyle->SetCanvasDefW(2*gStyle->GetCanvasDefW());
  gStyle->SetFrameBorderSize(2*gStyle->GetFrameBorderSize());
  gStyle->SetFrameLineWidth(2*gStyle->GetFrameLineWidth());
  gStyle->SetFuncWidth(2*gStyle->GetFuncWidth());
  gStyle->SetGridWidth(2*gStyle->GetGridWidth());
  gStyle->SetHistLineWidth(4*gStyle->GetHistLineWidth()); // thick lines
  gStyle->SetCanvasBorderSize(2*gStyle->GetCanvasBorderSize());
  gStyle->SetLegendBorderSize(2*gStyle->GetLegendBorderSize());
  gStyle->SetPadBorderSize(2*gStyle->GetPadBorderSize());
  gStyle->SetStatBorderSize(2*gStyle->GetStatBorderSize());
  gStyle->SetTitleBorderSize(2*gStyle->GetTitleBorderSize());

  gStyle->SetPadGridX(true);
  gStyle->SetPadGridY(true);

  gROOT->ForceStyle();
}

ROOT version

Worked perfectly fine up to version 6.36.04. Upgraded to 6.38.00 yesterday and it no longer works. Had to downgrade.

Installation method

Package manager (yay)

Operating system

Manjaro Linux

Additional context

PKGBUILD from which the tarball was built.

[ferdymercury]

I tried on 6.38.00 on Ubuntu 22 and it works fine, I get thick graphs with your rootlogon.C file.

If you do:

void _rootlogon()
{
  cout << "logon working" << endl;
  gStyle->SetCanvasDefH(2*gStyle->GetCanvasDefH());
  gStyle->SetCanvasDefW(2*gStyle->GetCanvasDefW());
  gStyle->SetFrameBorderSize(2*gStyle->GetFrameBorderSize());
  gStyle->SetFrameLineWidth(2*gStyle->GetFrameLineWidth());
  gStyle->SetFuncWidth(2*gStyle->GetFuncWidth());
  gStyle->SetGridWidth(2*gStyle->GetGridWidth());
  gStyle->SetHistLineWidth(4*gStyle->GetHistLineWidth()); // thick lines
  gStyle->SetCanvasBorderSize(2*gStyle->GetCanvasBorderSize());
  gStyle->SetLegendBorderSize(2*gStyle->GetLegendBorderSize());
  gStyle->SetPadBorderSize(2*gStyle->GetPadBorderSize());
  gStyle->SetStatBorderSize(2*gStyle->GetStatBorderSize());
  gStyle->SetTitleBorderSize(2*gStyle->GetTitleBorderSize());

  gStyle->SetPadGridX(true);
  gStyle->SetPadGridY(true);

  gROOT->ForceStyle();
}

Does it print something?

So might be an archlinux packaging or file permission access issue?

[ktht]

Interesting that it works on your machine but not on mine. Added the cout line and it does not print anything in 6.38.00, but it prints in 6.36.04. Tried also .rootlogon.py, hardcoding the full path to .rootlogon.C with Rint.Logon in .rootrc, as well as setting the permissions on .rootlogon.C from 644 to 755, but none of it made any difference. If I copied .rootlogon.C to the same directory where I launched rootbrowse, it printed an error in 6.36.04 saying that _rootlogon is defined twice, while it still didn't print anything or raise any errors in 6.38.00. Like it's unable to find .rootlogon.C at all ...

When comparing the changes made to the build files between Arch package releases (link), then I don't immediately see anything that could be relevant to my issue.

My first instinct was that it may have something to do with native implementation of rootbrowse and rootls, as this recently changed according to the latest release notes. In fact, the same issues persist when running rootls: the cout line works in 6.36.04 but not in 6.38.00.

If this issue is specific only to my machine, how can I debug it? Any ideas?

edit: I'll add that opening a root file with root -l myfile.root, I do see the cout line in 6.38.00, and when I launch new TBrowser from that session and view its contents, I see the expected graphics output with thick lines and all that. This sort of leads me to believe that the issue is really with the rootbrowse implementation.

edit 2: Digging a bit deeper, the .rootlogon.C files are explicitly loaded here:

root/core/rint/src/TRint.cxx

Lines 345 to 376 in 0ffc777

	void TRint::ExecLogon()
	{
	if (NoLogOpt()) return;
	TString name = ".rootlogon.C";
	TString sname = "system";
	sname += name;
	char *s = gSystem->ConcatFileName(TROOT::GetEtcDir(), sname);
	if (!gSystem->AccessPathName(s, kReadPermission)) {
	ProcessFile(s);
	}
	delete [] s;
	s = gSystem->ConcatFileName(gSystem->HomeDirectory(), name);
	if (!gSystem->AccessPathName(s, kReadPermission)) {
	ProcessFile(s);
	}
	delete [] s;
	// avoid executing ~/.rootlogon.C twice
	if (strcmp(gSystem->HomeDirectory(), gSystem->WorkingDirectory())) {
	if (!gSystem->AccessPathName(name, kReadPermission))
	ProcessFile(name);
	}
	// execute also the logon macro specified by "Rint.Logon"
	const char *logon = gEnv->GetValue("Rint.Logon", (char*)nullptr);
	if (logon) {
	char *mac = gSystem->Which(TROOT::GetMacroPath(), logon, kReadPermission);
	if (mac)
	ProcessFile(logon);
	delete [] mac;
	}
	}

And here:

root/net/net/src/TApplicationServer.cxx

Lines 1276 to 1307 in 0ffc777

	void TApplicationServer::ExecLogon()
	{
	if (NoLogOpt()) return;
	TString name = ".rootlogon.C";
	TString sname = "system";
	sname += name;
	char *s = gSystem->ConcatFileName(TROOT::GetEtcDir(), sname);
	if (!gSystem->AccessPathName(s, kReadPermission)) {
	ProcessFile(s);
	}
	delete [] s;
	s = gSystem->ConcatFileName(gSystem->HomeDirectory(), name);
	if (!gSystem->AccessPathName(s, kReadPermission)) {
	ProcessFile(s);
	}
	delete [] s;
	// avoid executing ~/.rootlogon.C twice
	if (strcmp(gSystem->HomeDirectory(), gSystem->WorkingDirectory())) {
	if (!gSystem->AccessPathName(name, kReadPermission))
	ProcessFile(name);
	}
	// execute also the logon macro specified by "Rint.Logon"
	const char *logon = gEnv->GetValue("Rint.Logon", (char*)0);
	if (logon) {
	char *mac = gSystem->Which(TROOT::GetMacroPath(), logon, kReadPermission);
	if (mac)
	ProcessFile(logon);
	delete [] mac;
	}
	}

The methods are almost identical to each other. In both cases, ExecLogon is launched in their respective constructors, yet both classes also inherit from TApplication, which is what native rootbrowse executable uses:

root/main/src/rootbrowse.cxx

Line 137 in 0ffc777

TApplication app("rootbrowse", nullptr, nullptr);

What I don't understand is why TApplication does not implement ExecLogon and call it in its constructor, or make it such that it can be explicitly called once instantiated.

[ferdymercury]

That makes sense. @silverweed moved rootbrowse from Python to C++, and as a (probably unintended) side effect, now rootlogon is not executed. He can tell if it's easy to fix.

In the meantime for 6.38, I suggest you use the workaround root -l file.root -e 'new TBrowser' maybe even defining a bash_alias for it.

[silverweed]

Hello @ktht, thanks for the report.
Indeed as you point out TRint::ExecLogon and TApplicationServer::ExecLogon are line-by-line equal so it looks like they could just be moved to TApplication, which at that point may also execute it.
I need to verify why this is not the case yet, but I'll make sure that the new rootbrowse behaves like the old one in this regard.

[ferdymercury]

behaves like the old one in this regard.

Related improvement suggestion: #19722 (comment)
Using TRint instead (as in rmain.cxx) would also give user flexibility to use command line, unlike a TApplication.

(Side note, .rootrc specifies Rint.Logon, not TApplicaton.Logon)