Created attachment 21823 [details]
alpha/themable WM icons

hi michael, happy new year :-)

pl->obr: i vaguely remember that you did something in the icon area yourself,
yes ? Then probably michael and you should synchronize this  work ?

obr @ pl: I assume you are talking about #i37167#. This is still in planing
stage, so Michaels patch looks like a very good starting point.

I need to take a closer look at it ..

The patch looks pretty similar to what I had in mind except for the following:

I planned to add those icon lists in VCL, which has the advantage that we don't
need an VCL API change for unix. Furthermore we need a fallback implementation
which checks for the display color depth.

I also would like to add the 48x48 icon size to default_images.

What do you think ?

Personally (and this is just me here) I'd like to see the OO.o libraries move
towards being more usable by unanticipated new components. On that basis -
having a fixed/small enumeration of all available icons - and some magic index
that you pass through to VCL is highly sub-optimal. Furthermore, VCL is not
really a logical place to look for the set of 'all possible window icons' ;-)

Of course - by having an internal resource set I guess you can do a much easier
fix - but, surely changing the VCL API shouldn't be a major issue - if it's done
right it shouldn't be a large rippling change - since we can have just a single
SetIcon call - with a changed signature for all platforms: clearly there is no
need for a special-Unix-only case here.

Ultimately, with my searches I could only find 2 instances of seticon being
called - so ... anyhow; I imagine the quick hack of leaving the limited
functionality in place with a vcl/ would solve the immediate problem, require
little effort and leave the infrastructure with this limitation - so I'm
guessing that'll be the chosen solution ;->

IIRC the reason for the VCL API is (once again) Windows: on Windows the title
bar icon API is just an index into the native resource linked against the
application binary. This is why the XPM icons currently used build into the
soffice.bin as well.

So what about creating the Image lists in the desktop/soffice.bin then ? 

Well; from my quick glance at the code - I saw that on win32 the icons are
loaded from the application - by index - but surely this is by no means
necessary - the Win32 API must provide a means to generate an HICON from an
image / other API avenues to generate this ?

We currently pick up the window icon from the resource but I think this could be
changed. There is for instance the Win32 API call CreateIconIndirect() which
takes an ordinary HBITMAP. 
However, we would still need Windows Iconresources in the executable, as this is
required for the document icons in the explorer, afaik. 

Tiny fix to cope with BGR/RGB swap problem:

+			if( pBitmap->mnFormat == BMP_FORMAT_24BIT_TC_BGR )
+			{
+				pDestData[2] = *pData++;
+				pDestData[1] = *pData++;
+				pDestData[0] = *pData++;
+			}
+			else // BMP_FORMAT_24BIT_TC_RGB
+			{
+				pDestData[0] = *pData++;
+				pDestData[1] = *pData++;
+				pDestData[2] = *pData++;
+			}
+			pDestData += 3;
+			*pDestData++ = 255 - *pAlphaData++;

The patch uses stderr and fprintf without including stdio.h in syswin.cxx, which
breaks the build on Debian/ppc.  See issue 42845 for details.

I have applied the "bitmapToPixbuf" etc. parts of the patch, but sticked with
the index based interface for now: even though I agree that VCL Bitmaps based
interface makes sense, this should be dicussed further with the framework team. 

Ummm ... why did you assign this to me ? Is there something i should do ?

Because I got it from you initially ;-). Furthermore, since I am not a VCL
maintainer, I am not going to argue whether to change the VCL API for WM icons
and how. So I leave this discussion up to you, Stephan, Andreas and Michael.

I just picked parts of the patch for fixing #i37167.

I think this is something for OOo later. Unless someone objects ?

Reset assignee on issues not touched by assignee in more than 2000 days.