Purpose and future of ROOT GUI?

cstrato · May 16, 2004, 5:46pm

Dear Rooters

I am not sure if this issue has been discussed before, but I would
be interested to know:
What is the intended purpose for the ROOT GUI TGClasses?
What is the future of the ROOT GUI?

The reason for my questions is the following:
Since about one year I am trying to develop a professional GUI for
my application. Meanwhile, it has more than 25,000 LOC and is still
not finished.
I can probably say that I have put the ROOT GUI to its limits, and
with the thankful help of Valeriy Onuchin I could solve a lot of
problems.

Meanwhile,the ROOT GUI has reached an impressive maturity.
Sorrowly, now I experience some serious limitations which make me
question what the main purpose of the ROOT GUI might be:

Is the main purpose to allow the development of a "quick and dirty"
GUI for certain special purposes?
In this case, the GUI has already all necessary items for its use.

Or is the main intention to allow the development of professional
applications?
Sorrowly, in this case I must say that the current status of the
ROOT GUI is not sufficient for the development of professional
applications, due to some severe limitations, some of which are:

1, TGTable:
The most severe limitation is the lack of a TGTable class which
would allow to display data in a tabular format.
ALL scientific applications have the possibility to display the
data in one or more large tables. Often, these applications allow
the display of tables much larger than Excel, which is limited to
65535 rows and 256 columns only!
In contrast, with the ROOT GUI it is not even possible to display
1000 rows w/o severe problems such as scrolling etc.
Currently, the only possibilty for me is to export the results of
my analysis as text files for display in other programs. However,
it is not possible for me to allow the user to select items due to
the same limitations.
It is probably save to say: As long as there is no TGTable class,
no professional GUI application can be developed.
(However, I must admit maybe the HEP community does not need it?)

2, TGListBox:
Although I (and other users) have mentioned the limitation of
TGListBox periodically since more than two years, sorrowly, this
limitation is still not solved (
Although I have some TGListBox frames in my application, I am
unable to integrate them fully due to this ongoing limitation.

3, TGLVContainer:
Although TGLVContainer has now a horizontal scrollbar when set to
details view, it has still problems to display all of the content,
as everybody can check: Simply reduce the horizontal size of
TBrowser and use the horizontal scrollbar. You will see that some
items are not displayed. Furthermore, in principle the header line
must also be scrollable in order to view the header items.

Probably, similar limitations may exist with respect to displaying
more than few lines of text. However, this limitation might not be
as important, since scientific applications are not a substitute
for text editors.

I apologize if you consider this to be a critique of the ROOT GUI,
and I am interested to know the intended purposes of this GUI.
However, I must admit that I did not expect that today there is
still a GUI framework which suffers the 32k limit. It would be
really great if this limitation could be solved soon.

Best regards
Christian

Valeriy_Onuchin · May 17, 2004, 1:32pm

Hi Christian,
personally I really appritiate you concern about
development of TG classes.
Currently ROOT manpower is strictly limitted,
TG classes are mostly developed by “gang of three (2.5 precisely)”
Fons (probably less than 25% of time)
me and Ilka. The latest persons at the moment do not
do the development of base TG classes itself but as well as you just use
TGxxx classes for development of other ROOT componnents.
IMHO, the problem IS - when development of "some software"
became critically dependent on some components why do not "invest"
into "these components ".
The rest of questions are mostly related to 32k limit.
That requires redesign TGxxx classes. We already have some classes
without this limit , e.g. TGContainer, TGTextEdit classes.
The technique used in these classes can applied in general to the
rest of TGxxx classes but that requires time and efforts for rewriting
a code (more or less clear how to do it and some prototypes exist)

Regards. Valeriy

[quote=“cstrato”]Dear Rooters