Issue 41225

Summary: hack to theme WM icon ...
Product: gsl Reporter: mmeeks <mmeeks>
Component: codeAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: andreas.schluens, issues, nospam4obr, philipp.lohmann, stephan_schaefer
Version: 680m72   
Target Milestone: AOO PleaseHelp   
Hardware: Other   
OS: Linux, all   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Description Flags
alpha/themable WM icons none

Description mmeeks 2005-01-24 17:44:29 UTC
So - as you know, I've always been aghast at this code, and - needing it to be
themed myself, I thought I'd switch some of the existing hacks for some
different ones :-)
The attached patch - works only on unix - it leaves the old / magic number
setting in parallel with the new BitmapEx sequence setting. With the gtk+
backend it results in themable alpha-transparent WM icons.
Of course - I have a number of questions:

Are the svtools/ icons deprecated ?
Is there a better API to do this - really, I'd prefer to have a MIME/Type string
somewhere rather than this ugly enumeration exposed as magic numbers via. UNO
properties ;-)

Also - of course, to have any hope of going up-stream, I guess it'd need a Win32
& also a plain-unix equivalent - which, as yet, I havn't got anywhere near
looking at. Perhaps it's easy to turn a BitmapEx on Win32 to an HICON, similarly
one might imagine the X backend would be quite easy to convert a Bitmap to a
Pixmap & mask. May be best to have a platform-conditional to do depth etc.
conversion to something friendly to the backend in SystemWindow::SetIcon, I have
no idea.
Comment 1 mmeeks 2005-01-24 17:44:58 UTC
Created attachment 21823 [details]
alpha/themable WM icons
Comment 2 philipp.lohmann 2005-01-24 17:55:32 UTC
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 ?
Comment 3 nospam4obr 2005-01-25 06:43:53 UTC
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 ..
Comment 4 nospam4obr 2005-01-25 09:48:19 UTC
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 ?
Comment 5 mmeeks 2005-01-25 10:00:24 UTC
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 ;->
Comment 6 nospam4obr 2005-01-25 10:32:48 UTC
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 ? 

Comment 7 mmeeks 2005-01-25 10:54:47 UTC
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 ?
Comment 8 stephan_schaefer 2005-01-25 12:02:52 UTC
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. 
Comment 9 mmeeks 2005-01-28 15:00:47 UTC
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++;
Comment 10 chris 2005-02-15 17:09:45 UTC
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.
Comment 11 nospam4obr 2005-02-24 14:48:06 UTC
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. 
Comment 12 philipp.lohmann 2005-02-24 15:27:46 UTC
Ummm ... why did you assign this to me ? Is there something i should do ?
Comment 13 nospam4obr 2005-02-25 06:30:38 UTC
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.
Comment 14 philipp.lohmann 2005-03-04 14:09:40 UTC
I think this is something for OOo later. Unless someone objects ?
Comment 15 Rob Weir 2013-07-30 02:15:28 UTC
Reset assignee on issues not touched by assignee in more than 2000 days.