lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Fancy diagnostics for art-provider class


From: Greg Chicares
Subject: Re: [lmi] Fancy diagnostics for art-provider class
Date: Thu, 19 Mar 2009 10:58:41 +0000
User-agent: Thunderbird 2.0.0.19 (Windows/20081209)

On 2009-01-16 18:34Z, Vaclav Slavik wrote:
> 
> On Thu, 2009-01-15 at 22:07 +0000, Greg Chicares wrote:
>> However, I'd still welcome any comments about these concerns:
>> 
>> >  - I'm testing this carefully with msw only, so I could be missing an
>> >    entire dimension. Is my recent code going to give lots of nuisance
>> >    diagnostics with GNU/Linux? (I'd guess not, because of theming.)
> 
> Normally not, but it's possible. LMI's icon_monger will still be used
> for LMI-specific icons and the user is free to configure toolbars to use
> non-default icons size. In that case, the user would get lots of
> resizing warnings. But I did never see this done in practice.

Okay. Then in this rare case, there'll be lots of warnings (though each
appears only once), but they are meaningful because resizing can be ugly.

>> where I wrote a statement that seems rather gruesome [1]. Can there even
>> exist a tidy way of achieving what I attempted? There are two categories:
>>  (A) bitmaps provided and used by lmi
>>  (B) bitmaps built into wx and used by wx html help
>> and I seek a run-time test that'll tell me if a bitmap in category A is
>> missing (falling back on a built-in wx bitmap causes a theme clash),
>> without giving false-positive diagnostics for Category B. However, both
>> categories are subject to change in the future. 
> 
> Let me suggest another classification:
> 
> (A') LMI-specific bitmaps provided and used by LMI app
> (B') stock bitmaps that LMI provides customized version of
> (C') other stock bitmaps that LMI doesn't know or care about

Thanks. Much better. This inspired the 20090319T1019Z commit.

> If an icon from category A' is missing, it's a serious problem --
> there's no replacement for it. Category B' is never used on GNU/Linux
> (where system theme's bitmaps stake precedence) and even though it is
> used on MSW, the app can fall back to wx's built-in versions;
> consequently, a missing piece in B' is much less serious. Finally, no
> warnings or errors should be produced for C'.

That's what I did:
  A': a serious warning
  B': a less grave warning, for msw only
  C': no warning

> Here's another idea how to deal with the checks:
> 
> * Prefix all bitmap names from A' with "lmi-" (e.g. "lmi-run-case"
>   instead of "run-case"), either by renaming their respective PNG files
>   too or stripping the prefix in CreateBitmap(). This would allow you to
>   detect members of A' and emit warnings about missing icons for them.

I accomplished the same thing by enumerating them in the program.
Admittedly that's less robust under maintenance when we add icons,
but we expect to do that rarely.

> * For B' ∪ C', warn only about rescaling (and probably not under
>   wxGTK), but not about missing icons.

For B', I give a warning with msw because the builtin wx icons
clash aesthetically with the lmi replacements. And there's a
warning whenever rescaling occurs.

We've encountered some actual problems with missing icons, so I
wanted specific, unmistakable warnings whenever a missing file
would degrade the visual appearance of the program.




reply via email to

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