This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Custom icons per window class/name patch


Hi Earle,

I've got this mail after sending my last notes, so please don't think I'm
ignoring your hints.

>I have to admit that I agree with Harold on this, that the whole idea of
>cygwin is to make Windoze look like any other Unix system.  As I'm looking at
more
>of the commercial apps I use and the newer freeware ones I see that the
>majority do provide bitmap icons in the WM_HINTS, just the really old ones like
xterm
>don't.  Even xload has one.  [I was able to patch the XC distribution to get
>a local working copy of xload, one that shows your Windoze CPU utilization.
>If I get the time I'll submit it to the xfree-devel list and see what they
>think of including it in the next full release...]

I agree with you, that this would be the best solution, my suggestion was based
on my limited x related skills.

>IMHO the odds of you getting any SW group to make a special Windoze .ico
>patch and files for cygwin is pretty small.  There's extra work and most
>folks using X11 are using Linux or other unix systems anyway so they aren't
>going to have any tools to make .icos even if they wanted to.  If it's your
>own app, then sure. ;)
>
>The pixmap format's not that bad, and if you defer the icon generation until
>later you can do it in the WM thread, which is a valid X client so all the
>nice X*() functions are available.

Good to hear, but how to compute in detail ? Additional what about the
performance ?
Using the xclient means to transfer the image data every time icon setting will
be performed from the server to the client, which is the server, although the
data is directly asseccable on the server, isn't it ?
I assume based on the things I have learned from you, that all the image data
will be in some property on the server, which has only to be retrieved in some
mysteric way.

BTW: As a starting point I have written a GetWMHints() function similar to your
GetClassHint(). I can probably supply more such functions, If I would know which
property to retrieve.

>Since you can now make a unique window class from the WM_CLASS res_name
> and res_class, changing the icon in one won't affect other apps.

Yes, that make is more easier.

>You might even get X to scale and change the depth
>of the image to the standard Windoze formats by rendering the Pixmap into a
>drawable, and then using the raw bits.  That'd be SW reuse at its best!

I had taken a look into the fvwm source code, which does some pixmap
conversation, it seems to be a graphical bit processing task like changing image
depth to the CreateIcon() format and probably changing image format size)

>Oh yeah, I think there's a tiny memory leak in the patch I sent before.
>You need to free() the res_name and res_class after their use, I don't
>think I did that, mybad!


>...
>>KDE/qt for example uses png images by default, so there may be more
>>formats. My
>>suggestion is to start with this basic implementation and to see if other
>>people
>>have some ideas and knowledge to enhance this.
>
>Eating PNG and JPEG files is not that bad, if you check out the sample
>code in their SDKs they each have about a 30 statement main() that
>decompresses an image into a RGB buffer.  That would definitely be more
>friendly to the Unix folks than .ICO, and if you link dynamically you won't
>blow the server size up at all.

Using the WM_HINTS data make this obsolate, because the client application have
to convert this to the x11 pixmap format like qt does.

>I can see your point, but it seems like the code is just a few steps away
>from being a real standard window manager.  If we get that, then the only
>thing the commercial X servers have on xwin is speed, and I'll trade
>reliability for speed any day when doing real work.
>
Let's go, but don't expect, that I'm a x11 guru :-)

Ralf

----------------------------------------------------------

#include <../../../../lib/X11/Xatomtype.h>	// xPropWMHints

int GetWMHints(WindowPtr pWin, 	xPropWMHints **hints)
{
  struct _Window *pwin;
  struct _Property *prop;
  pwin = (struct _Window*) pWin;

  if (pwin->optional)
    prop = (struct _Property *)pwin->optional->userProps;
  else
    prop = NULL;

  *hints = NULL;
  while (prop) {
    if (prop->propertyName==XA_WM_HINTS
	&& prop->type==XA_WM_HINTS
	&& prop->format==32)
      {
	(*hints) = malloc(sizeof(xPropWMHints));
	memcpy((*hints),prop->data,sizeof(xPropWMHints));
	//ErrorF("hints.flags       =%x\n",(*hints)->flags       );
	//ErrorF("hints.input       =%x\n",(*hints)->input       );
	//ErrorF("hints.initialState=%x\n",(*hints)->initialState);
	//ErrorF("hints.iconPixmap  =%x\n",(*hints)->iconPixmap  );
	//ErrorF("hints.iconWindow  =%x\n",(*hints)->iconWindow  );
	//ErrorF("hints.iconX       =%x\n",(*hints)->iconX       );
	//ErrorF("hints.iconY       =%x\n",(*hints)->iconY       );
	//ErrorF("hints.iconMask    =%x\n",(*hints)->iconMask    );
	//ErrorF("hints.windowGroup =%x\n",(*hints)->windowGroup );
	return 1;
      }
    else
      prop = prop->next;
  }

  return 0;
}


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]