amelia-development Mailing List for AMELIA

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi Joao,

I've committed a bunch of work to the AMELIA SVN repository, so this
is an update on what I've been up to.

The main thing is the introduction of the AEventAnalysisData class.
I've been thinking of a way to store custom data from different
analysis and this is what I come up with. The general idea is that any
work done by a student is stored in some container, and the container
then has the responsibility of
1) Telling AMELIA when it was updated. (via signals)
2) Saving itself to a file.
3) Loading itself from a file.
Furthermore, the containers are organized into modules. As of right
now, there can only be one type of container per module (it was
easier). But I'm still thinking if that is the right choice. What do
you think?
Another feature is that the modules can be attached to an event (ei:
bookmarked tracks in an event) or they can be attached to some global
entity (ei: the combinations added to a histogram), even though the
latter is not implemented yet. Also I should note that so far I create
one module per plugin, a plugin can have multiple modules (or can
share them with other plugins).

Next are the actual implementation details:
The AEventAnalysisData class is a base class that defines a few basic
functions that a container has to implement. They are the 3
functionalities mentioned earlier (update, saving, reading).
The update notification is done via a Qt signal.
The saving is done by writing an XML block to a file stream. The
format is as follows:
<analysis module="ModuleName" type="ContainerType">

</analysis>
The reading is done by looking through an XML tree, whose root is the
analysis tag in the format above. I also pass the event that the
container will belong to, in case I need to load some tracks from it.
But in the future, I would like to replace this by a method where the
container can grab the event from the AEventManager.

The overall calls to the store/loading of all modules is handled by
the AEventPackage class that stores everything in the .logbook file
that is in each package.

An example of a container that I created is the ATrackCollection
class. This container holds collections (I'll rename the class to
ATrackCollection*s*) of tracks, which can be referenced by name. For
example, the list of bookmarked tracks is stored in a ATrackCollection
container as "bookmarked_tracks" under the AGeometry module. The same
is done with track combinations (ATrackCombination now inherits
ATrack. As I understand, ATrackCombination represents a collection of
particles that decayed from a single particle. Furthermore, you
already had a collection type identifier in ATrack and
ATrackCombination had an "equivalentTrack" member), known as
"combined_tracks".

The main problem right now is that the class is tied to a specific
event, because it has to load the tracks from it. What I would like to
do is to store some unique identifier to be stored with each track and
then retrieve the event that the track belongs to based on it. To be
more clear, right now the following happens:

loadFromFile(tracks,event)
  foreach( trackid in tracks)
     event->getTrack(track)

But I want the following:

loadFromFile(tracks)
  eventmanager=getEventManager()
  foreach( trackinfo in tracks)
    event=eventmanager->getEvent(trackinfo.uniqueIdentifierForEvent);
    track=event->getTrack(trackinfo.trackid)

This way we could store tracks from different events in one
collection. For example, the histogram plugin could store the tracks
in each histogram. Do you have any suggestions for what could be used
as a unique identifier? I don't trust the filename, because that could
be easily changed. For example, the events in AMELIA use the event/run
numbers for filenames, but the events in the RAL masterclass just use
Event#.xml. Are the event/run numbers relatively unique (ei: between
simulated events and real events?)

Another problem that I've run into, but easy to fix, is the selected
track ID. Before this, when a user selected a track it was assigned an
ID based on a counter. However, since the selections are persistent
between sessions, should the selection ID be persistent too? If not,
then the solution is simple. When a track is added to an
ATrackCollections container, then its selection id is set to
(parentEvent->highestSelectionId++). But I think it would be much
friendlier if the ID's were persistent, in case the student names some
notes in his notebook. In that case, it could be a bit more
complicated to find the next available selection ID. What do you
think?

To demonstrate the flexibility of the AEventAnalysisData containers, I
created a new plugin to show that they can be used for something other
than collections of tracks. The new plugin is basically a lab
notebook, using which the student can append notes to events. It uses
a container called ALabNoteBookData that holds a collection of
entries. Each entry has two properties: the date it was created and
the text it contains. The notes are currently displayed in the sliding
stacked widget that holds the detector view and the interesting tracks
table. I've added a method to AGeoPlugin which makes it easy to add
another page to the stacked widget and adds an entry to the menu bar
(see View->Main View->).

It is mainly a proof of concept, so it is quite simple. I do have some
additional ideas, and I'm sure you will have even more. For example:
- The text could be "rich text" and event contain links that trigger
certain actions in AMELIA. For example, there could be links to tracks
(clicking it would select the track) or links to histograms (click it
would display a specific histogram).
- There could be a global notebook monitor, which would show the notes
for all events in a single list.

My next goals are the following:
- Make AMELIA work in fullscreen mode. I remember that you done some
work on this in the pre-plugin era and what you've done with the
AGeometry monitor should still be compatible (the layout didn't change
that much). But the web views and the abase class had some changes.
I've already handled the menu in abase (I just scale everything to
reflect the resize) and I just need to stick the web views into a
layout so they too get automatically resized...
- Fix two regressions from the pre-plugin era. 1) The monitors in the
menu are not tilted 2) A screenshot of the QIrrWidget is not being
displayed in the menu. Instead you see some garbage..
- Start documenting the code and the specific frameworks in AMELIA.
Basically, I want to write comments in the headers about what each
function of each class and the class itself does, and then run one of
those auto-documention generating scripts to turn that into HTML. Also
I want to write how certain things can be hooked into (ei: adding new
options to the AGeometry monitor, adding new monitors to ABase, using
the analysis containers, using the track model..)

Do you have any comments? We should probably have a meeting on Skype again.

--
Cheers,
Karol Krizka

2008	Jan	Feb	Mar	Apr	May (31)	Jun (21)	Jul (11)	Aug (1)	Sep (10)	Oct (10)	Nov (14)	Dec (2)
2009	Jan (1)	Feb	Mar (1)	Apr (1)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

amelia-development Mailing List for AMELIA

amelia-development — AMELIA development mailing list