lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Generating screenshots automatically


From: Greg Chicares
Subject: Re: [lmi] Generating screenshots automatically
Date: Sat, 14 Feb 2009 18:29:35 +0000
User-agent: Thunderbird 2.0.0.19 (Windows/20081209)

On 2009-02-14 14:51Z, Greg Chicares wrote:
[...]
> On 2009-02-12 15:15Z, Vadim Zeitlin wrote:
[...]
>> 2. The size of lower HTML window is guessed rather than computed, i.e. it
>>    could easily become too small for the text shown in it. This is a
>>    somewhat serious problem as it means I'd have to change my approach of
>>    showing wxHtmlWindow on screen as I do now and render HTML off screen,
>>    but -- thanks to Vaclav's help with this -- this should be easy to do as
>>    well.
> 
> Okay, you're rendering the screenshot and its annotations all together into
> one graphic, as we originally discussed.
> 
> Perhaps we should consider an alternative idea:
>  - render the screenshot into a graphic
>  - embed the screenshot in an html <img>
>  - write the annotations in html <p> paragraphs
> Then the result is html instead of (e.g.) png. What I think we gain
> is that the html annotations could someday contain hyperlinks.

Let me say more about that. Here's a brief example:

<h2>The "Plan" screen</h2>
<p>
  <img src="plan.png" alt="[screenshot]">
</p>
<p>
  <em>ProductName</em>:
  <!-- All we have today is a one-word explanation: -->
  Product
</p>
...more annotation paragraphs

The one annotation I spelled out above is obviously just a placeholder
that conveys no information. Much more needs to be said here. We should
say it in exactly one place, to make maintenance easy and reliable.

This is a listbox with a variable number of strings: different strings
are presented to different end users. If a user sees:
  policy X
  policy Y
  [there could easily be a dozen more items]
then ideally we might write a set of detailed descriptions elsewhere:
  Policy X is a life insurance contract with high early cash values.
  Policy Y is a periodic-payment variable annuity contract.
  ...
and link to that with an html anchor. That would be especially nice
because the descriptions naturally represent proprietary information.
We could set it up this way in the public repository, e.g.:
  <a href="proprietary/policy.html">Policy descriptions</a>.
with a public linked-to file that says literally:
  <p>[placeholder for whatever products are distributed]</p>
and, when building any end-user's distribution, replace that file with
one containing proprietary data. (Displaying that data in the wx html
help browser is like using a GPL browser to view html on a company's
intranet: it doesn't bring content under the GPL.)

We'd still want to keep the screenshot and its annotations together
on one single page, so that users can see it at a glance. For input
fields like "Policy", the one-pager could hold a terse description,
with a hyperlink to potentially-unlimited elaboration elsewhere.

The problem, though, is that then there's no obvious way to create
this html from the WXXRC file. Well, I could replace the <help> text:

  <object class="wxListBox" name="ProductName">
-     <help>Product</help>
+     <help><a href="external.html">External html link</a></help>
  </object>

but then I've broken the wxHtmlHelp facility.

I could propose adding a <userdata> element to the "common attributes"
enumerated in 'tn0014.txt' for all controls--of course, only if that
makes sense for wx in general--but if <userdata> is wanted today, then
surely tomorrow a need for <userdata0>, <userdata1...> will arise; so
that's probably not a good idea. Or I could bastardize <tooltip> for
that purpose, but that's too appalling. Or I could write a slightly
bigger file of present-xrc-contents + custom-extra-data, and generate
the "real" '.xrc' files from that.

But wait: as an experiment, I modify 'skin.xrc' in this vein:
  <object class="wxListBox" name="ProductName">
      <help>Product</help>
+     <foo>xyzzy</foo>
and to my surprise it "works": the <foo> element seems to be ignored
silently. Is that a behavior we can rely upon?

I guess that'd mean we'd have to parse the xml, but then again we'd
save the effort of rendering the text to png. What do you think?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]