Re: [hpoj-devel] xojpanel compiled-in pixmaps

[Joe P. <joe...@sn...>]

On Monday 05 March 2001 08:13 pm, PASCHAL,DAVID (HP-Roseville,ex1) wrote:

<...>
> In order to avoid having to hack the .xpm files, perhaps you could use a
> trick similar to what I did in ptal-mlcd, something like the following:
>
> #define static static const
> #include <foo1.xpm>
> #include <foo2.xpm>
> // etc.
> #undef static

It works. Thanks very much, David.


> > ojstatus.cpp: In method `void XojPanel::createInterface()':
> > ojstatus.cpp:160: passing `char **' as argument 1 of
> > `QPixmap::QPixmap(const
> > char **)' adds cv-quals without intervening `const'
> > make: *** [ojstatus.o] Error 1
>
> Strange -- I haven't the slightest idea what "cv-quals" means.  I'm only
> familiar with the situation where the compiler complains when you pass a
> const pointer to a function that takes a non-const pointer, which can be
> fixed either by adding the const in a typecast, or by adding "const" to the
> function prototype.

I found a small number of references to 'cv-quals' in a google / deja.com 
search for the error. It seems to be shorthand for 'const / volatile 
qualifiers'. 

> > In the case of hpoj_mini.xpm, this is the line of code:
> > this->setIcon(QPixmap(hpoj_mini_xpm));
> >
> > For the LCD background pixmap:
> > *lcdPixmap = (QPixmap)hpojlcd_xpm;
>
> I'm assuming these typecasts cause an implicit construction of a QPixmap
> object, taking its input from the XPM string array.

Right.

> I think it would be preferable to avoid hacking/renaming the file, to make
> it easier to change the image.

I agree with that. I didn't know any other way until you suggested the 
'#define' wrapper.

> > I put a couple of xojpanel screenshots on my site with
> > different versions of
> > the graphic. I'm not totally pleased with either one of them,
> > but you can
> > take a look. I'll probably try out some different fonts, etc.
> > to see if the
> > appearance can be improved a little more.
> >
> > http://pages.cthome.net/jsp/hpoj-linux-gui/index.html
>
> I think either one is fine.  Personally I would sort of lean towards the
> first one with the smaller font for the second line, but perhaps you could
> try squeezing the letters in a bit more (the way it is with the larger
> font).

I'll work on it some more.

-- 
Joe