Hi Ken,
----- Original Message -----
> Nathan,
>
> I'm back looking at pmview.
>
> I've integrated the Aconex code (libapp and pmview) and my changes
> into my pcp-gui workarea.
>
> I can build images that include pmview.
>
> I've fixed the Ubuntu desktop integration so that the icons appear.
>
Good stuff.
> Now my questions ...
>
> 1. Looks like libapp is the generalization of classes from pmchart
> (and
> some repeated in pmtime) that have common use ... I think pmchart and
> pmtime were converted to use those in the Aconex code, but Qt has
> moved
> on since then and they no longer build. Does this sound about right?
>
Yes. If you could forward the build failures you're seeing, it
may ring some bells re other Qt changes.
> 2. pmview parses the scene description and launches the viewer with
> the
> correct objects and layout (in the few simple tests I've done), but
> - lots of the UI components are inactive or missing
> - I get 0, 1 or 2 timecontrol dialogs (sometimes _both_ live and
> archive) appearing ... this is non-deterministic (more debugging
> enabled
> seems to produce more dialogs, so a timing issue?)
IIRC, when debugging is enabled to pmtime on the command line, it
will popup both dialogs. Its a feature - I found it handy when
debugging originally anyway.
> - no metric values are ever fetched, so the objects stay grey
> Does this match where you thought it was up to?
Not quite - it was running fetching metrics and modulating the
scenes correctly. Now that I think back, I do remember archives
working after all (previously thought it was only live - but now
ISTR archives too - perhaps only replayed forwards though). On
the screenshots page, there are three pmview snaps from archives:
http://oss.sgi.com/projects/pcp/screenshots.html
> 3. How do you turn on the diagnostics in a controlled manner ...
> there
> is a mix of fprintf's to stderr, cerr's and calls to console.post ...
> and I don't seem to be able to get them all enabled (I guess we need
> to
> accommodate the fprintf's because of libpcp diags, but I'm not sure
> what's the rationale for the other two diagnostic pipes).
Yeah, console should probably be what we go with, that was the
original plan anyway. When started in debugging mode, pmchart
gives an Options -> Console menu choice. From the desktop,
sometimes there is no associated console for fprintfs (if there
is, who knows where on earth they end up) - for all of the many
desktops (Win32/Mac/Linux), so I added that for my own sanity.
The usual -D <options> works for applN debug levels - they get
translated in the Console class, and timestamping is applied
automatically.
> 4. I can't get a foothold on starting to tackle pmview ... I don't
> understand how the time control is supposed to work, and in
> particular I
> am unconvinced that the "tabbing" from pmchart needs to be applied to
> pmview, which (I think) pmview needs to run in either live or archive
> mode, but not both. And I have no clue how the many logic should be
> connected to the qmc classes to trigger fetching and scene modulation
> callbacks.
Yeah, certainly in a straight port of the original pmview (static
scenes), tabs would not be helpful.
The value fetching *should* be in place (above screenshots show
values were being fetched) ... not sure why that no longer works.
> 5. Would it make sense to start with the current t-o-t pmtime and get
> that working with libapp (and support the PM_TRACE_TIMECONTROL diags
> that seem to have not made it to the brace new pcp-gui world). Then
> do the same for t-o-t pmchart? So start with the t-o-t code and
> selectively merge changes from the Aconex code, keeping all the newer
> features, Qt work and changes in the t-o-t code. And then use
> pmchart as the model for the missing pieces of pmview?
Yes. I really didn't like the name libapp, btw, must come up with
something better. In general, many problems that pmview will have
are solved in pmchart (like time control) - all appropriate code
should move from pmchart into this library. pmgadgets will need a
similar set of functionality.
I don't really have suggestions for better names - something unique
though, perhaps "libqed" ("Qt Extensions and Data-Structures" lib)?
>
> Any/all suggestions would be most welcome at this stage, as I'm
> thrashing about here and not making much progress.
>
There's alot to be done. Refactoring bits out of pmchart would
be highly useful, starting with the time control client code I'd
guess. pmgadgets will need all this stuff too.
It has also been on my list for awhile to investigate if / how we
can make use of the QTestLib to give ourselves better regression
testing confidence in these tools (as coverage is relatively poor;
qa/interact is crying out for automation in particular, since no
one is using, and automating that is the right thing to do anyway).
I *think* QTestLib can help there. Now might be a good time, as
refactoring introduces risk, but I've not got experience with it
to know how best to integrate into our codebase.
cheers.
--
Nathan
|