Immediate additions for CalDet: add strip# vs plane#, change how strips are shown (no more just bowtie style), make display with 4 views: combos of {+,-}, {U,V}.
Longer: Add undo/redo to Range object. Use Ranges inside Views.
At Ely, I aggreed to take on JobMenu.
This update covers the last couple weeks.
Added a Range object to hold info about an X or Y range. This allows different objects to share the same range relatively transparently. One object sets the range, the Range then sends a signal and all interested objects adjust their representation to match. Since they must be shared, they have to be memory managed. This is done via a RangePtr which IsA Handle (a general templated reference counting class I got from TC++PL, 3rd.). Currently all ranges are of type doubles which is not so good because a selection needs to be in pixels. Also, some ranges are 1D and some are 2D. In order to not have to maintain duplicate code I want to make the dimension and type a template parameter however, 2 parameter templates are not directly supported (ClassDefT probs - there is a ClassDefTT on roottalk which I could try). I have found that it is extreamly difficult and annoying to mix templates with ROOT (ClassDef/Imp) and Rt.
To make matters more comlicated (well, complicated due to poor template support in CINNT and ideosyncracies in Rt) I don't want object to necessarily just HaveA RangePtr because there is a slightly non-trivial implimentation to the setters and getters of a RangePtr. Some is handled by the Handle (heh), but the other relates to breaking the Rt connection with old RangePtr before accepting and Connecting a new one. So, I want a Rangeable base class which IsA range. Then things like View can BeA Rangeable. However, it is difficult/impossible to connect an Rt signal to a templated class's slot. Grrrr.
The Root2001 talk and the MIDAD update for Ely is on my talks page. Many of the above issues are addressed in the Root2001 talk.
Added trivial printing. This just dumps all Views to an .eps file. I have a query on roottalk about eps printing of TG GUI classes as well, but no bites so far.
I submitted some small changes to TGDoubleSlider which should be in the latest release (3.01/05). They let one change which end is min/max and also adds lines to mark where the resize/move boundaries are.
The Segfaults that plagued me (and halted development) turned out to be one bug in ROOT and one really stupid bug in test-midad.cxx.
TGTableLayout is in ROOT cvs as of last week. For the past couple days I have been battling a segfault due to something stepping on MomNavigator::fFragmentArray. This turned up after my last big commit which was made before doing an update of minos code. After that update the failure was seen - happened before with QueasyDisplay. Sigh....
Got MIDAD and ROOT more friendly today. One can now start ROOT and create MIDAD and a MIDAD display from the root prompt. Other dents were made in the todo list.
I am going to have to reduce the amount of time spent on MIDAD for a while as I will be getting back to work on the E787/E949 online monitor.
Finally a new commit today.
It is getting more and more dificult to deal with TGFrames. I still don't understand the packing rules. Currently many kludges get the job done (eg, if the color scale is placed other than first in UVZVDisplay, then View's name isn't set. Huh?!?, also, need to do a Resize() to force things to actually layout correctly. Huh huh?!?). I wonder just how dificult it would be to embed a TCanvas in a non ROOT gui window....
I queried and was answered by Fons. He has yet to be able to check on TGTableLayout, but expects to soon.
The long absence due to the ATF beamtest is now over, but I must start focusing some time on E787/E949 software so MIDAD work will be slow for a while.
The TGTableLayout was ``finished'' a while ago. See this page for info. I still need to integrate this and some other changes into MIDAD before I commit it to MINOS repo. Also, need to push Fons to get some feedback about getting this into ROOT proper.
The complexity of UVZVDisplay.cxx is growing. I think I need to take a more ``widget'' like approach to displays. That is a ``Display'' is a TGFrame which holds only a single View. Then larger small-d-displays will be a collection of Displays.
Still need to get geometry in there....
Added todo list. It is starting to get a few good ideas.
Started working on a TGTableLayout. Surprised there is not such a thing already.
Some latest screen shots for the reconstruction meeting today:
Added some sliders to handle zooming. This ends up working very well and allows fairly intuitive control.
In the process of getting this slider zooming to work I have come to the conclusion that using ROOT for the GUI is very tedious. Adding these sliders took much longer than it should have. Part of the problem is I am still just getting to learn ROOT GUI programming, but that isn't the whole of it. There is not as much flexability as say Gtk--. For example the vertical sliders insist that the higher value < the lower one. Building up frames in ROOT is similar to the use of HBoxes and VBoxes in GTK but the MatrixLayout didn't perform as I expected (fixed column/row sizes). Anyways, random griping....
Next step is to get back to displaying the geometry.
MIDAD is now under SRT's control. Robert reports problems with SRT putting test-midad and simple-main's main() into libMIDAD. For now I am going to treat this as Not My Problem (tm).
Well, it looks like Robert's recent changes to / addition of Record (which lacks an old style Makefile) will force me to put MIDAD under SRT sooner rather than later. Oh well, tomorrow.
Well, I went ahead and moved it to the MINOS repo. Let the fun begin.
I have noticed a pattern evolving in the development of MIDAD maybe best described as punctuated chaos. The code tends to be almost always in a state of chaos punctuated by brief moments where everything is understood and actually works. Durring the chaotic times I am very stressed because it feels like things are getting away from me. But what comes out of the other side (so far) is a higher level of organization and it always makes me breath a great sigh of relief. Is this typical or just due to my lack of OO design experience....
The new organization of writing Displays is in place with a sample implementation looking much like the old one from the outside. As described in yesterday's entry, a Display inherits from DisplayBase and fills up the fMainFrame protected member (a TGCompositeFrame) with whatever it wants. I still need to flesh out the interface for adding buttons to the button bar and setting up menus. I think there will be a default set of buttons and menus common to all Displays so that people can have a certain expectation of features in all. Probably each Display impl should have its own menu to play with and be allowed to add to the button bar (currently it could overwrite).
The next cute thing I want to add is using TGDoubleSliders to handle zooming in the UZVZDisplay as a better test of this new part of the framework.
I Will post screen shots by at least early Wednesday for the Nue (Wed) and Reco (Thur) group meetings. Also, I'll try to get MIDAD into MINOS CVS r.s.n. ....
There are several Methods that are defined at various levels of the framework that are intended to be called at various stages of running.
Here is how Displays now work: The DisplayBase class handles:
Eventually will probably add some kind of Proxy style registry for Displays so that they can be created on the fly from menu or ROOT prompt. Each entry in this registry would hold a creation method, the name of display used to find it in the registry and a short description (maybe also a long winded one as well) of what the display is. This way people can be for-warned what kind of display they are asking for before it is created.
Got tripped up on a stupid bug for a long time today.
Figured how to handle geometry Viewables. Will go ahead and treat it like any other viewables. Now Models must return CandHandles and UgliGeomHandles. Found out it is possible to get an UGH w/out any candidate since the VldContext comes from the CandHeader which can be got from the Record, so it isn't a problem.
Started thinking about upper level organization more. Currently what is in the code is close. Essentially there is a Display class which provides Menu, Button and Status bars and a ``Main'' class (eg SimpleMain.h) which fills this Display and connects any signals.
What needs to change is that the current Display has one big canvase (RootEmbededCanvas) on which everything is added. This doesn't allow things like TGDoubleSliders or other non-TPad objects to be used. So, I need to come up with a way that provides some default menus/buttons but which the meat is added by the client.
Milind just mentioned to me that I need to think about how to handle BField. I think this will be done similar to how I handle Geometry since it has many of the same features (doesn't change, depends only on what detector, less interactivity needed).
Today was the offline software meeting (3:20) therefore, didn't get as much done as I would have liked.
Hooked up the status bar to Viewables (this brings in issues of Munits as people, unlike software, want to know what units are being shown - currently I am punting). This forced a change of pushing the meat of AddViewable from SimpleMain into Display to allow attaching to signals in a not-so-tortured manner.
Worked a few bugs out of zooming, still not perfect, but its enough for now. Zooming works by writing a ZoomPolicy which follows the Strategy pattern of Go4. Currently have a FitZoomPolicy and a LockZoomPolicy. The former zooms all Views to their physical range, the later zooms the selected view to the selection range and zooms all other views to match if one or both of their coordinates are ``locked'' (this way if you zoom a U-Z view, it forces the V-Z to take the same Z range).
Still contemplating how to handle geometry....
At the meeting, got the delivery date for MIDAD pushed (pulled?) from June to May, but hope to have something to show CalDet folks by April 15th (a very important day in my life). Also got some minute pressure to put MIDAD in CVS. Maybe tomorrow or Monday.
Got basic user controlled Zooming more or less done. Right now I am putting too much specific View dependent code into SimpleMain.cxx. The fix for this may be re-designing the Display class. Maybe turning it into a simple TCanvas instead of the TGMainWindow it is now. Need a generic way to specify the zooming policy to use. Maybe the Strategy pattern from Go4 can be used.
Currently the default zooming locks Z and puts U an V at the same scale, big enough to see all of both. User zooming keeps Z locked an only effects the U or V direction for the View where the zooming was done. This is all done inside of SimpleMain.cxx which doesn't know that it has U/V vs Z views. Thus the problem. Anyways, must leave something to work on durring tomorrows ever so fun 3 hour software phone meeting....
Would like to deal with the GeometryModel as a real Model but an UgliGeomHandle is *not* a CandHandle so Model inheritance won't work. What to do? Maybe geometry data is different enough from event data to handle specially....
Just 24 hours later and big update. The damn thing now actually works. See [midad-caldet-first.png] and [midad-fardet-first.png]. Ignore the brain dead colors and the lack of a multitude of GUI controls for now.
It can now correctly display candmcdigitlists from both Far and CalDet. Prev/Next works. Big clean up in control flow. Default Zooming works. Both strip ends displayed. Numerous minor bug fixes. Oh Joy.
The way I decided to handle zooming was for the Views to ask all their Viewables (at Configure() step) what each Viewable's bounding box is. The View then imposes some zooming convention with this info. Currently the only zooming convetion implemented is to zoom enough so all Viewables fill the View as much as possible. This gives goofy displays of events with only a few digits and currently there is no way to zoom out or in. Details details details. So, in the end I didn't need Robert's Ugli Extents methods, although I will when I start writing geometry Viewables.
I disabled exercising the ModelHistory mechanism for now. A Viewable will always get the latest (and only) Model. The control flow is now such that an external object tells the Views and Viewables to update themselves. It doesn't work so well to have Viewables watching ModelHistories at least for now.
I think next thing to deal with is displaying geometry and getting zooming more controlled. Also, currently it is using ROOT's default color palate which is really brain dead (at least for this usage).
Robert put in necessary code to grab detector extent based on what detector the data is from. Added this to QueasyDisplay/queasy so it now correctly handles Paul's CalDet MC (!!). (Does this mean I am done for the week?...) This is not yet in MIDAD as its use causes problems. Namely, there is no mention of any candidates until well inside concrete viewables and certainly none in View.cxx and a CandHandle is needed in order to get a VldContext which is needed to get a UgliGeomHandle which is needed to get the extents. (whew!). This gets me wondering if I should figure out the TPad::Range emperically as new Viewables are handed to a View. But this causes problems with zooming... Grrrrr.
On possible way to deal with this is to dynamically Range the View so as to just hold all current Viewables, possibly causing a resize if a newer bigger viewable is added. This will have bad interference if the view is zoomed (ie, one would loose zoom if a new Viewable is added to the View). So, have to keep track if currently zoomed.... Is there ``bounding boxes'' associated with TObjects? Don't think so.
Another way to side step this issue is to start working on actually displaying not just data but geometry as well. Doing this may let me set the size based on the geometry (sounds obvious when I type it). ... Of course, thinking about it, this doesn't help, as I still am tied to getting the Geometry from the Candidates. Double Grrrr.
Note: Just realized that there is a bit of confusion about how to handle ModelHistories. Does one need to maintain one MOM for each running of a job path. Will ask minos-soft one of these days.
To do: Context sensitive menus: put default right-button menu into a sub-menu ``ROOT'', use main pop-up to handle MIDAD-specific entries.
To do: Zooming: provide a way to lock zooming of different Views in the same Display (implement with Rt signals). Provide a way to zoom such that as little empty space is shown. Provide visual clues as to what the zoomed coordinate ranges are.
Now have a working display (for the first event in a file anyways [grin]) of just candmcdigitlist Viewable. Now what is needed is a way to clear the ModelHistorys and set them up anew in the same manner as initially. There needs to be checks for the case that a candidate coresponding to a pre-exiting model does not exist in the next event.
Also, need to make DigitListViewable connect to all necessary signals. Currently there is a bit of an asymmetry w.r.t. the inital event setup and how following ones are handled (this is in simple-main.cxx). Need to change things such that all necessary signals get connected, a global ``go'' is issued and then control is passed on to ROOT's main loop.
Need to find a good way to handle multi-object Viewables such as DigitLists. Originally I thought to just override TObject::Paint but that makes it difficult to do things like DistancetoPrimative. So, a better way may be to override TObject::Draw. But, I need to figure out how to effect changes after all the Draw()s are called and how to organize holding all the TObjects.
Settled on how to deal with the top level GUI elements. There is now a Display class which sets up some default GUI elements (buttons, menus, status bar, etc) and holds a QRootEmbeddedCanvas. It is on this canvas that various Views can be laid down. The View management is handled by giving relative coordinate positions for the View corners.
The next step is to figure out how to export any signals that may be produced either by a Display's GUI elements or by any TCanvas items. Part of this will be sanitizing the creation of a Display so that things like connecting to EventControl::Next() is handled by default. Much of this can probably be handled inside the Display ctor.
Am having trouble figuring out how to put all the GUI elements together. In particular, how to manage the layout of different Views. Part of the problem is the plethora of different canvases (TCanvas, TGCanvas, TRootCanvas, TRootEmbededCanvas, etc).
The old EventControl class from QueasyDisplay workes fine in this new framework. I'll rely on this until Mark fines time to implement JobMenu.
Random note: Viewables can use a Model's Modified() and a ModelHistory's Added() signals to turn on a ``dirty flag'' which says to re-calculate any stashed values. A Viewable::Paint() method should work on these stashed values and only recalculate if the dirty flag is set.
I think the next step is to work out interaction with JobControl and get a JobMenu system implemented. But before that, this is what fruit the weekend bore.
Added a class registry / proxy system for the models as well and updated simple-main to test things. The ModelPool plays the part of the registry of 2 classes of objects:
The steps a ``user'' (ie, me) follows when writing a Viewable are:
static ViewableProxy<MyDataViewable> gsMyDataViewable("MyData","MyData");
This will cause a proxy for the Viewable to be registered (at
link time) with the ViewableReg singleton. The first string is
the name given to the ViewableReg in order to create an instance
of this Viewable.. As a convention, use the class name without
the ``Viewable'' part for this name. The second string is the
class name of the Model which this Viewable is intended to
connect with. The convention is to use the Model's class name
without the ``Model'' part.
The steps for writing a Model is similar.
To create a Viewable one first needs a ModelHistory (or it can be set later). One gets a ModelHistory which tracks a particular data type and name from the ModelPool like:
ModelHistory* mh = ModelPool::Instance().GetHistory("TYPE","NAME")
The string `"TYPE"' holds the name of the type of Model with, by
convention, the word ``Model'' removed. So, if one wants a
DigitListModel then `"TYPE"' would be `"DigitList"'. The `"NAME"'
string holds the name used to identify a particular instance of the
type of data. For example, if one wanted the history of the MC digits
one would use `"candmcdigitlist"'. This is the same name used to look
the underlying candidate in the record.
After getting a ModelHistory you can make a new Model of the type the history holds by calling
mh->MakeModel()The new model is returned and also added to the history list, triggering any signals.
One creates a Viewable by doing:
Viewable* v = ViewableReg::Instance().CreateByName("TYPE",mh);
which will return 0 if things don't match up (ie, the passed in "TYPE"
of viewable doesn't handle the type of Models held in `mh').
Found bugs in TEllipse::DistancetoPrimitive and in the default ctor. Sent to roottalk. These kind of things are proving to be a not so minor nuisance.
Have a working ``bogus'' display that shows the 1% core functionality. That is, I have a Viewable held in a View attached to a Model and everything displays correctly (after the above).
Figured out how to have Concrete Viewable classes register themselves. This makes use of a Class Registry / Proxy patern in a similar way to Mark's JobCModuleRegistry, but with out the need for a CPP macro. It is based on this and references therein (``Self Registering Classes...''). This gives a much cleaner (IMO) implementation and doesn't hide what is really going on. Last modified: Mon Jun 25 10:39:14 EDT 2001 ") ?>