Re: Style IconSize and application supplied icon windows
Application-provided icon windows are purposely not resized by IconSize because the application may need the window to be a certain size. The window could provide more than just an icon, so resizing may adversely affect the application's functionality. There is a quick note about application-provided icons in the fvwm man page. Steve Marcus Lundblad wrote: When an application supplies it's own window as an icon (for example XJewel), the style IconSize has no effect. I guess this is known problem, since this feature (IconSize) is quite new. Just thought to point this out just incase... //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Clicking through shaped icons to desktop
Dan Espen wrote: S. Anderson [EMAIL PROTECTED] writes: On Fri, Aug 16, 2002 at 10:43:28AM +0200, Dominik Vogt wrote: On Thu, Aug 15, 2002 at 07:34:53PM -0600, S. Anderson wrote: On Thu, Aug 15, 2002 at 08:12:16PM -0400, Dan Espen wrote: Steve Talley [EMAIL PROTECTED] writes: I didn't get any response to this on the FVWM user's list, so I thought I'd try the devel list. Hmm, looks like this slipped thru the cracks. Thanks, Steve Steve Talley wrote: Hello, I've been using shaped desktop icons which look very spiffy but present a frequent problem. When I go to click on an icon, about half the time (depending on the icon) I end up clicking on a transparent part of the icon, which gets passed through to the desktop. The result is that the root menu pops up instead of the intended deiconification. Just thought I would mention, if you use png images for your Icons, clicking on the transparent part will do what you want. Um, really? But we haven't implemented anything like this in fvwm. hmm, mabey the transparent part of my icon isn't completely transparent then. It is here if you want to look at it. http://www.xmission.com/~sa/terminal.png For me, clicking on the transparent parts is like clicking on the root. I'm running current FVWM CVS, Mandrake 8.1 with XFree 3.3.6 and an S3 Savage video card. I get the same behavior. Clicking on the transparent portion of a png or xpm icon image still clicks through to the root window. FVWM version 2.5.2 compiled on Solaris 8 with support for: XPM, PNG, GNOME WM hints, EWMH hints, Shape, SM Steve -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Clicking through shaped icons to desktop
I didn't get any response to this on the FVWM user's list, so I thought I'd try the devel list. Thanks, Steve Steve Talley wrote: Hello, I've been using shaped desktop icons which look very spiffy but present a frequent problem. When I go to click on an icon, about half the time (depending on the icon) I end up clicking on a transparent part of the icon, which gets passed through to the desktop. The result is that the root menu pops up instead of the intended deiconification. This behavior differs from some other window managers (and M$ Windows) where clicking within the bounds of the icon, even on transparent portions of the icon, results in a click on the icon itself. This looks just as nice and makes for a less error-prone experience. Is there some easy config fix for this in FVWM that I've missed in the man page? I know I could just not use shaped icons, or use more dense icons, but that would detract from the spiffiness. Barring a configuration fix, has anyone given any thought to how this could be implemented in FVWM? My knowledge of the X Shape extension is limited but I don't believe that it allows you to catch clicks passed to transparent portions of the window. Technically, there is no transparent part of the window (I think). Am I wrong? One thought I had would be to implement an non-shaped InputOnly window over the shaped pixmap icon window. Then map/move/resize it along with the pixmap icon window. But looking through the code this would seem to be a big change. Any other suggestions? Thanks, Steve -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: [Patch] MinIconSize/MaxIconSize
Mikhael Goikhman wrote:
On 22 Jun 2002 16:25:27 -0600, Steve Talley wrote:
One of the things I liked about MWM (CDE actually) was that the
size of the icons could be limited/controlled. In FVWM this isn't
possible, short of specifying an icon image for each app. The
result is that people who use IconBox/IconGrid may have icons that
are too big for the grid spot. The FVWM man page mentions FVWM's
inability to clip icons in this case.
Another issue that is mildly bothersome is that the width of the
icon title bar is determined by the width of the icon image. So
small icons result in a smaller area to click on.
The attached patch addresses both of these issues. It provides
support for two new Style subcommands:
MinIconSize width height
MaxIconSize width height
These allow you to limit/control the size of both user-provided
and application-provided icon images. Icon images that are
smaller than MaxIconSize are clipped. Icon images that are bigger
than MinIconSize are padded.
Seems like a good patch. Some notes.
Thanks Mikhael. I have implemented all of your suggestions in the
attached patch. Comments inline:
Is it possible to replace int with unsigned char? This will save 12
* 500 = 6Kb for me.
Sure. I just looked at a 256x256 icon on my desktop (at 1152x864),
and it was huge. However, for *much* larger resolutions in the
future, 256x256 may not be all that big...
Icon sizes bigger than 1/4 of screen are bad.
Setting both MinIconSize and MaxIconSize to the same dimensions
has the effect of enforcing a rigid size for the icon image. For
example:
Style * MaxIconSize 64 50
Style * MinIconSize 64 50
Since this is the main usage, is this possible to change the syntax
to:
Style * IconSize x y[, x2 y2]
where one pair means both min and max values?
Excellent idea. Certainly simplifies the syntax.
Another optimization would be to say that size 0 is invalid so it
may be used to switch the feature off. Any of the following 3:
Style * IconSize
Style * IconSize 0 0
Style * IconSize 0 0, 0 0
may disable the feature completely. It would be possible to only
partialy disable it (IconSize 0 0, 48 0). This should save another 4
bits and seems more consistent than the logic in the patch that
allows one integer in the pair (I don't think this should be allowed
as ambiguous, use 0 instead).
Agreed. However, I have made -1 the disable/default value, since 0 is
a valid maximum dimension. Consider the setting:
Style * IconSize 64 0
This will result in something like the attached zeroheight.jpg
(IconGrid is defined) or zeroheight2.jpg (IconGrid not defined),
effectively allowing the user to specify that no image is to be shown
but still be able size the icon title.
This results in the same behavior as MWM/CDE. See the attached
before/after images to see the efect of the patch and the above
settings. The same IconBox/IconGrid settings are used in each
case.
Please take a look at the attached patch and let me know if there
are any questions/suggestions/etc. It is based on the latest CVS
snapshot.
Regards, Mikhael.
Thanks again Mikhael. Let me know if you have any other
suggestions/comments on the latest patch.
Steve
Index: fvwm/add_window.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.c,v
retrieving revision 1.295
diff -u -r1.295 add_window.c
--- fvwm/add_window.c 2002/06/17 00:33:06 1.295
+++ fvwm/add_window.c 2002/06/24 04:07:02
@@ -1057,6 +1057,25 @@
return;
}
+/*
+ * Copy icon size limits from window_style structure to FvwmWindow
+ * structure.
+ */
+void setup_icon_size_limits(FvwmWindow *fw, window_style *pstyle)
+{
+if (SHAS_ICON_SIZE_LIMITS(pstyle-flags)) {
+fw-min_icon_width = SGET_MIN_ICON_WIDTH(*pstyle);
+fw-min_icon_height = SGET_MIN_ICON_HEIGHT(*pstyle);
+fw-max_icon_width = SGET_MAX_ICON_WIDTH(*pstyle);
+fw-max_icon_height = SGET_MAX_ICON_HEIGHT(*pstyle);
+} else {
+fw-min_icon_width = MIN_ALLOWABLE_ICON_DIMENSION;
+fw-min_icon_height = MIN_ALLOWABLE_ICON_DIMENSION;
+fw-max_icon_width = MAX_ALLOWABLE_ICON_DIMENSION;
+fw-max_icon_height = MAX_ALLOWABLE_ICON_DIMENSION;
+}
+}
+
Bool setup_window_placement(
FvwmWindow *fw, window_style *pstyle, rectangle *attr_g,
initial_window_options_type *win_opts)
@@ -2074,6 +2093,9 @@
/** border width **/
XSetWindowBorderWidth(dpy, FW_W(fw), 0);
+
+ /** icon size limits **/
+ setup_icon_size_limits(fw, style);
/* placement penalities */
setup_placement_penalty(fw, style);
Index: fvwm/add_window.h
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.h,v
retrieving revision 1.26
diff -u -r1.26 add_window.h
--- fvwm
Re: [Patch] MinIconSize/MaxIconSize
Mikhael Goikhman wrote:
On 23 Jun 2002 22:30:25 -0600, Steve Talley wrote:
Mikhael Goikhman wrote:
Another optimization would be to say that size 0 is invalid so it
may be used to switch the feature off. Any of the following 3:
Style * IconSize
Style * IconSize 0 0
Style * IconSize 0 0, 0 0
may disable the feature completely. It would be possible to only
partialy disable it (IconSize 0 0, 48 0). This should save another 4
bits and seems more consistent than the logic in the patch that
allows one integer in the pair (I don't think this should be allowed
as ambiguous, use 0 instead).
Agreed. However, I have made -1 the disable/default value, since 0 is
a valid maximum dimension. Consider the setting:
Style * IconSize 64 0
This will result in something like the attached zeroheight.jpg
(IconGrid is defined) or zeroheight2.jpg (IconGrid not defined),
effectively allowing the user to specify that no image is to be shown
but still be able size the icon title.
Hmm, ok.
Can IconSize receive 0 arguments (not just 2 or 4) for disabling too?
Oops. Yes, I have added this feature to the attached patch.
Steve
Index: fvwm/add_window.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.c,v
retrieving revision 1.295
diff -u -r1.295 add_window.c
--- fvwm/add_window.c 2002/06/17 00:33:06 1.295
+++ fvwm/add_window.c 2002/06/24 15:29:52
@@ -1057,6 +1057,25 @@
return;
}
+/*
+ * Copy icon size limits from window_style structure to FvwmWindow
+ * structure.
+ */
+void setup_icon_size_limits(FvwmWindow *fw, window_style *pstyle)
+{
+if (SHAS_ICON_SIZE_LIMITS(pstyle-flags)) {
+fw-min_icon_width = SGET_MIN_ICON_WIDTH(*pstyle);
+fw-min_icon_height = SGET_MIN_ICON_HEIGHT(*pstyle);
+fw-max_icon_width = SGET_MAX_ICON_WIDTH(*pstyle);
+fw-max_icon_height = SGET_MAX_ICON_HEIGHT(*pstyle);
+} else {
+fw-min_icon_width = MIN_ALLOWABLE_ICON_DIMENSION;
+fw-min_icon_height = MIN_ALLOWABLE_ICON_DIMENSION;
+fw-max_icon_width = MAX_ALLOWABLE_ICON_DIMENSION;
+fw-max_icon_height = MAX_ALLOWABLE_ICON_DIMENSION;
+}
+}
+
Bool setup_window_placement(
FvwmWindow *fw, window_style *pstyle, rectangle *attr_g,
initial_window_options_type *win_opts)
@@ -2074,6 +2093,9 @@
/** border width **/
XSetWindowBorderWidth(dpy, FW_W(fw), 0);
+
+ /** icon size limits **/
+ setup_icon_size_limits(fw, style);
/* placement penalities */
setup_placement_penalty(fw, style);
Index: fvwm/add_window.h
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.h,v
retrieving revision 1.26
diff -u -r1.26 add_window.h
--- fvwm/add_window.h 2002/03/24 19:19:24 1.26
+++ fvwm/add_window.h 2002/06/24 15:29:53
@@ -57,6 +57,8 @@
FvwmWindow *fw);
void setup_frame_size_limits(
FvwmWindow *fw, window_style *pstyle);
+void setup_icon_size_limits(
+ FvwmWindow *fw, window_style *pstyle);
void increase_icon_hint_count(
FvwmWindow *fw);
void change_icon(
Index: fvwm/fvwm.1
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/fvwm.1,v
retrieving revision 1.23
diff -u -r1.23 fvwm.1
--- fvwm/fvwm.1 2002/06/21 14:32:34 1.23
+++ fvwm/fvwm.1 2002/06/24 15:30:04
@@ -5333,7 +5333,7 @@
slashes ('/'). The last style in these groups is the default.
.IR BorderWidth , HandleWidth ,
.IR NoIcon / Icon , MiniIcon ,
-.IR IconBox , IconGrid , IconFill ,
+.IR IconBox , IconGrid , IconFill , IconSize ,
.IR NoTitle / Title ,
.IR TitleAtBottom / TitleAtLeft / TitleAtRight / TitleAtTop ,
.IR LeftTitleRotatedCW / LeftTitleRotatedCCW,
@@ -5881,8 +5881,9 @@
values for the icon grid, looking for a free space. The default
grid is 3 by 3 pixels which gives a tightly packed appearance. To
get a more regular appearance use a grid larger than your largest
-icon. Currently there is no way to clip an icon to a maximum
-size. An
+icon. Use the
+.I IconSize
+definition to clip an icon to a maximum size. An
.I IconGrid
definition must follow the
.B IconBox
@@ -5913,6 +5914,42 @@
.EX
Style * IconBox -80x240-1-1, IconFill b r
.EE
+.I IconSize
+sets limits on the size of an icon image. Both user-provided
+and application-provided icon images are affected.
+.EX
+.RI IconSize [ width height [ maxwidth maxheight ] ]
+.EE
+All arguments are measured in pixels. When all four arguments are
+passed to
+.I IconSize,
+.I width
+and
+.I height
+represent the minimum size of an icon, and
+.I maxwidth
+and
+.I maxheight
+represent the maximum size of an icon. Icon images that are smaller
+than the minimum size are padded. Icon images that are bigger than
+the maximum size are clipped.
+
+If only two arguments are passed to
+.I
Re: [Patch] MinIconSize/MaxIconSize
Dmitry Yu. Bolkhovityanov wrote: On Sun, 23 Jun 2002, Steve Talley wrote: Since this is the main usage, is this possible to change the syntax to: Style * IconSize x y[, x2 y2] where one pair means both min and max values? Excellent idea. Certainly simplifies the syntax. A small comment: IconSize suggests that icons fill be somehow forced (shrinked/grown) to specified size. Isn't IconSizeLimits a more intuitive name? Hi Dmitry, When IconSize is only passed two arguments (which is likely the most common scenario), all icons are indeed forced to the given size. So I think the name IconSize makes sense. Thanks, Steve -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
