Re: [lmi] Generating screenshots automatically

[Greg Chicares]

On 2009-02-22 20:54Z, Vadim Zeitlin wrote:
> On Sun, 22 Feb 2009 19:03:32 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Let me propose that it generate one html file
> 
> (and one PNG file I presume)

Yes.

> GC> for each wxPanel in the XRC dialog that was just loaded,
> 
>  Do you mean only top level panels by "each" here? Because you could
> perfectly well have other panels embedded in the top level ones. Or maybe
> you mean all notebook pages? But this, of course, assumes that there is a
> notebook and then we need to find it somehow. So using the top level panels 
> seems a better idea

http://lists.nongnu.org/archive/html/lmi/2009-02/msg00037.html
|
| We want one output file per wxPanel. Thus, for 'skin.xrc', this command
|   grep wxPanel skin.xrc
| identifies the twelve output files we'd want.

I expressed it that way because I'm not sure what "top level" means.
All these panels, for every skin:
  grep wxPanel skin*.xrc |less -S
are siblings. They're in one-to-one correspondence with wxBookCtrl
pages. Those are exactly the objects for which we want screenshots.
No panel has any embedded child panel.

Every "skin" file has exactly one book control. You can access it
by calling MvcController::BookControl(). Iterating over the panels
is the same as iterating over the book pages. I would suppose that
iterating over the pages is easier, as long as that lets us access
"custom" tags like '<lmi:annotation>'.

> but the trouble is that I was adding support for
> enumerating all top level objects defined anywhere in XRC

I suppose that would include wxMenu etc., which we can skip.

> while you need to
> do it just for the top level objects defined in the same XRC file as this
> dialog was loaded from.

We want only one screenshot per wxPanel in the current XRC dialog.
That's why I thought it'd be easiest to do this right after that
dialog is loaded in MvcController::MvcController().

> And having something as specific as this in
> wxXmlResource hardly makes sense IMHO and so I'd prefer to find some
> LMI-specific solution for enumerating these panels. Can you think of
> anything?

http://lists.nongnu.org/archive/html/lmi/2009-02/msg00026.html
|
| [...] if you'd like a [no longer] premature idea, call it from
| 'mvc_controller.cpp', in MvcController::MvcController(), right after
| the WXXRC dialog is loaded:
|
|     if(!wxXmlResource::Get()->LoadDialog(this, parent, 
view_.MainDialogName()))
|         {
|         fatal_error() << "Unable to load dialog." << LMI_FLUSH;
|         }
| +
| +   ExtravasateAnnotatedScreenshots(BookControl());
|
|    
BookControl().ChangeSelection(last_selected_page[view_.ResourceFileName()]);

At the insertion point, the dialog has just been loaded, so IIRC
the first page is selected by default. I suppose I'd approach it
like this:

  some_integral_type number_of_pages = /* get number of pages */;
  for(int j = 0; j < number_of_pages; ++j)
      {
      BookControl().ChangeSelection(j);
      // produce a screenshot of MvcController::CurrentPage() here
      }

And you don't have to worry about leaving the book control on its
last page, because the first line after the insertion point selects
the "right" page.

I'm not sure how to get the number of pages in a wxBookCtrlBase.
Even though today we're using only wxNotebook, someday we'll want
to offer other book-control types. But, referring to the wx-2.8.7
documentation, I don't see how to count wxTreebook pages; that's
why I said only "/* get number of pages */" above.

>  Alternatively, we could generate the screenshots for all top level panels
> defined anywhere. But then it really wouldn't make sense to do it from
> here. OTOH I don't quite understand why should this be done on a per dialog
> basis anyhow, it seems to me it'd be better to generate all screenshots at
> once, wouldn't it?

I'm not sure that really would be better. For one thing, I don't
think you can load all the dialogs at once--the names collide,
by design.

We distribute only one "skin" from 'skin*.xrc' to each end user.
>From that end user's perspective, it's the only skin that exists.
One annotated screenshot for each page in that skin's unique book
control is enough to cover that end user's entire universe.

Some skins sacrifice power for simplicity. Those are the skins
whose end users would want screenshots.

Other skins sacrifice simplicity for power. They provide many
expert features. We distribute them only to expert users. Expert
users are less likely to need screenshots. We might never generate
screenshots for an expert user's "skin". (We don't want to make
it difficult to do so; but we would not routinely want to do so.)

To me, this suggests generating screenshots only for whatever
"skin" is currently loaded. We can even do that at run time: on
demand, for example, or perhaps the first time the program is
run. There are many possibilities:
 - offer a menu command to print the screenshots
 - load the screenshots in a wxHTML window
 - put the screenshots into html help
and we don't have to choose among those possibilities today.

> GC> and simply write all those files to disk, separately.
> 
>  Which directory should be these files written to?

Really, wherever this code would write a file is okay:
  std::ofstream os("foo.txt");
That's something I can easily change as new uses emerge.

>  Also, I guess that this will be just used as an illustration of how to use
> the code for generating these files and won't be done like this in the real
> program, will it? I.e. it doesn't make sense to try to do anything smart
> here like checking whether the screenshot files already exist and not
> recreating them if they're new enough?

Let's divide the work into two parts:
 - generating screenshots, generically, outside any specific context
 - doing something with them
The first requires specialized knowledge that you have but I don't;
the second doesn't.

We can't yet see every profitable use for this facility. Probably
we'll discover new uses later. But we can specify the interface for
the first part now, and I hope this message completes any part of
that specification that was missing. Once this is integrated into
lmi, I can explore various ways to use it. It's more efficient for me
to do that on my own: playing with it is easier than discussing it.