Re: [lmi] Generating screenshots automatically

[Greg Chicares]

On 2009-02-23 12:34Z, Vadim Zeitlin wrote:
> On Mon, 23 Feb 2009 01:47:08 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> All these panels, for every skin:
> GC>   grep wxPanel skin*.xrc |less -S
> GC> are siblings. They're in one-to-one correspondence with wxBookCtrl
> GC> pages. Those are exactly the objects for which we want screenshots.
> GC> No panel has any embedded child panel.
> 
>  The last one could however change, which is why I think it unwise to take
> all wxPanels.

I wouldn't use wxPanel in any other way myself, but that's only because
I wouldn't know how. AFAIK, it's just something like a wxWindow that
happens to work for notebook pages. OTOH, you might someday show us a
different way to use it: the scales would fall from my eyes, but then
the "invariant" that I was assuming would break.

However, that doesn't matter, because...

> But then we're not going to iterate over XRC nodes anyhow
> because of:
> 
> GC> Every "skin" file has exactly one book control. You can access it
> GC> by calling MvcController::BookControl(). Iterating over the panels
> GC> is the same as iterating over the book pages. I would suppose that
> GC> iterating over the pages is easier,
> 
>  Yes, I didn't realize that we could use BookControl() here. Indeed, using
> it is much simpler and requires no changes to wxXmlResource.

That's great. I suspect that's a much stronger invariant. If we ever
did anything outside the book-control paradigm, then MvcController
would break in deep and obvious ways.

> GC> as long as that lets us access "custom" tags like '<lmi:annotation>'.
> 
>  This will work as long as all objects have unique names. BTW, I called
> this tag <lmi:help_link> and currently the code considers that the tag

I do like to have control over names. But, since this will all be done
in lmi, and wx obviously won't contain special code to recognize any
specific tag in an 'lmi:' namespace, I can change <lmi:help_link> to
<lmi:my_really_cool_evocative_name> at will and recompile.

And perhaps I'd find a use for another "custom" tag that I can't yet
imagine; but I'd be able to add support for it.

> contents is just the link target because this is much more convenient to
> write in XML than the entire HTML fragment. I.e. consider:
> 
> <lmi:annotation>&lt;a 
> href="link_target"&gt;link_text&lt;/a&gt;</lmi:annotation>
> 
> vs
> 
> <lmi:help_link>link_target</lmi:help_link>
> 
> Of course, the latter doesn't allow specifying the link text but I
> currently use the name of the control as it which IMO is good enough. And
> if it isn't we can always add <lmi:help_link_text>.

That sounds like it ought to work just fine.

> GC> At the insertion point, the dialog has just been loaded, so IIRC
> GC> the first page is selected by default. I suppose I'd approach it
> GC> like this:
> GC> 
> GC>   some_integral_type number_of_pages = /* get number of pages */;
> GC>   for(int j = 0; j < number_of_pages; ++j)
> GC>       {
> GC>       BookControl().ChangeSelection(j);
> GC>       // produce a screenshot of MvcController::CurrentPage() here
> GC>       }
> 
>  So far I instantiated each panel inside a separate wxFrame but it doesn't
> make sense to do this if the panels are already created so I'll use your
> approach. One question however: would you like the screenshot include the
> entire dialog, just the notebook or just the notebook page?

If it's not too hard, then it'd be ideal to include the notebook page
as well as the tab controls at the top, but exclude the large static-
text control and pushbuttons at the bottom. But if including the tab
control makes the code much more complex, then that's not crucial.

IOW, in this prototype screenshot:

https://savannah.nongnu.org/file/skin_panel_20090219.png?file_id=17486

we could remove the frame (the "LMI Plan Panel" titlebar and the rest
of the blue rectangle surrounding the panel); and ideally we'd add the
whole set of notebook tabs at the top, to give the user a visual cue
indicating which tab was selected, if that's easy enough. Otherwise,
we could write the tab's name as an html title:
  <h3>The "Plan" tab</h3>
  <img> [PNG goes here] </img>
  <p> [annotations begin...

Of course, if including the selected tab is easy, but including all
of them is harder, then we'd pick the easier way--these would both
be equally good:

  +---------------------------+
  | Plan | Group | ...        | <-- all tabs are shown
  +---------------------------+
  | [controls on the wxPanel] |
  | ...                       |
  +---------------------------+

  +---------------------------+
  |      | Group |            | <-- only the current tab is shown
  +---------------------------+
  | [controls on the wxPanel] |
  | ...                       |
  +---------------------------+

but if either one takes considerable extra code, then this is good too:

  The "Group" panel             <--This is an html heading

  +---------------------------+
  | [controls on the wxPanel] | <--This is the PNG.
  | ...                       |
  +---------------------------+

where html text annotations would follow at the bottom of any of those
drawings.

> GC> To me, this suggests generating screenshots only for whatever
> GC> "skin" is currently loaded. We can even do that at run time: on
> GC> demand, for example, or perhaps the first time the program is
> GC> run.
> 
>  All I can say is that we definitely should do it every time the dialog is
> opened because it's a time-consuming process.

I'll certainly make it depend on some condition that'll rarely be
true: probably
  if(user selects some generate-screenshots command)
    {
    create an mvc instance
    generate the screenshots
    do "something" with the generated screenshots
    destroy the mvc instance, as if by pressing Cancel
    }

> Right now it's also a very
> ugly one because the pages must be visually shown on screen but I hope to
> work around this, at least for MSW.

I don't mind showing the pages. Actually, it may be desirable, as it
provides a visual cue, serving much the same function that a progress
dialog might. I wouldn't go out of my way to make the book control
appear and step through its pages; but if it does so naturally, then
I wouldn't do any work to prevent it--I wouldn't even add a single
line to block painting.

Well, if you make it too fast, I might consider calling a sleep()
function to make it wait a couple hundred milliseconds on each tab.
But that would only be a finishing touch, easily added later.

And I especially wouldn't inhibit this accidentally-desirable artifact
in any platform-specific way that'd make it work "better" for msw than
for GNU/Linux.

> GC> We can't yet see every profitable use for this facility. Probably
> GC> we'll discover new uses later. But we can specify the interface for
> GC> the first part now, and I hope this message completes any part of
> GC> that specification that was missing.
> 
>  I think so. Just one last question: would you still like me to finish
> xrcshot tool which would generate the HTML files (and accompanying PNGs)
> for all the panels in skin.xrc or is this unnecessary now? The worry I have
> is that integrating the changes in LMI can take some time and so you might
> not be able to generate these screenshots yourself sufficiently soon.

Perhaps you could send me the binary by personal email. Then I can
use that to meet my short-term needs. Later on, when we integrate it
into lmi, it's okay if the output is improved: no one should object
to enhancements, and, best of all, it's *automated*, so we can put
enhanced screenshots into users' hands at virtually no cost.

The reason why I'd like to have a binary myself is that I anticipate
changing the <help> elements significantly soon, probably editing
their contents many times and inspecting the results at each stage.