On Thu, 2003-09-04 at 10:09, Uwe Pross wrote:
http://www-user.tu-chemnitz.de/~uwp/fvwm_grill.jpg
put this picture on the web site. It is funny, of course,
It's hilarious but it's not a logo. I think it should go on the web page
somewhere, maybe the cats page (erm - maybe not). How about a
On Thu, 2003-09-04 at 10:09, Uwe Pross wrote:
http://www-user.tu-chemnitz.de/~uwp/fvwm_grill.jpg
put this picture on the web site. It is funny, of course,
It's hilarious, but it's not a logo. I think it should go on the web
page somewhere, maybe the cats page (erm - maybe not). How about
a
Mikhael Goikhman wrote:
There are some large issues with WindowStyle_proposal.txt to solve, like
reduction of the StyleFunction otherwise it will grow infinitelly when
switching themes, here the current Style is more optimal. Also currently
multiple Style commands are queued and executed at
Mikhael Goikhman wrote:
On 08 Jun 2003 14:24:58 +0100, Tim Phipps wrote:
I've got some free time now and I was thinking of implementing the
WindowStyle command that was proposed ages ago. I think this means I
vote no (not very strongly) but I'd appreciate some help in reviewing
Olivier Chapuis wrote:
Seems that there is no conclusion here. It seems that there is two
votes for it (me and Mikhael) one vote against (Dominik) and one
unclear vote (Dan). So I ask for more votes and clarification
I've got some free time now and I was thinking of implementing the
Mikhael Goikhman wrote:
Is this a final syntax we want to have? I prefer:
Pick WindowStyle NoTitle, !Borders
I think Tim suggested this syntax some years ago together with
SetupFunction, but I can't verify this right now.
I did, the spec is in WindowStyle_proposal.txt in CVS. I was
Mikhael Goikhman wrote:
Tim, everyone is patiently waiting for your say.
Regards,
Mikhael.
Shite! I was keeping quiet. I wish I hadn't said anything. I don't
consider myself an FVWM developer at the moment, I haven't done anything
for years but if you want my opinion here it is: I
[EMAIL PROTECTED] wrote:
- COPYING ---
Before using this software, every user is expected to read the
statements in the file ETHICAL_LICENSE that comes with the fvwm
distribution.
Hi All,
I was just trying to have a look at the new spangly mozilla icons
and found a core dump in FvwmIconBox. Patch attached.
Cheers,
Tim.
Index: modules/ChangeLog
===
RCS file:
Dominik Vogt wrote:
CVS, or 2.4.x or both?
CVS, but it might be in older releases
Cheers,
Tim.
--
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,
Dmitry Yu. Bolkhovityanov wrote:
On Thu, 8 Aug 2002, Tim Phipps wrote:
/257 will take ages on any processor, /256 will take one cycle on most.
257 is the correct scale factor for conversion between 8- and
16-bit colors: 257==0x101, so that e.g. 0xFF becomes 0x if multiplied
OK-find . -name '*.h' -o -name '*.c' | xargs grep -n 257
./fvwm/ewmh_icons.c:343:fg[0] = colors[0].blue/257;
./fvwm/ewmh_icons.c:344:fg[1] = colors[0].green/257;
./fvwm/ewmh_icons.c:345:fg[2] = colors[0].red/257;
./fvwm/ewmh_icons.c:346:
Dominik Vogt wrote:
Do you have additional suggestions? Did I miss anything that
could be added (I left out auto raising when the pointer enters a
window on purpose).
What about when windows are created, mapped or generally change state or
do you think FvwmEvent is the way to handle this?
Dan Espen wrote:
Olivier Chapuis [EMAIL PROTECTED] writes:
Why you do not trust me? I run my Xserver with depth 8 and I get no
problems with all the app I can run (including netscape -no-install).
I trust you, I just never heard of an X Server that supported
8 bit that way.
I've
But, when I run my Xserver with depth
8 (and fvwm allocate these 216 colors) I *cannot* reproduce any
problems, I can run netscape, xv, gimp, any gtk/gnome apps, any
kde apps ..etc without any problems.
You may be being helped by your graphics card/Xserver. If your setup
allows other
A couple of bugs with the recent pager changes:
1) *FvwmPager: BalloonYOffset -1
This is legal and means the balloon is above the pager window.
FvwmPager is now complaining about this and changing it to +3
2) *FvwmPager: HilightColorset * 2
The colorset isn't being stretched to fill the
Dominik Vogt wrote:
Alias GotoDesk MyGotoDesk
Builtin GotoDesk
Unalias GotoDesk
How would this be different to just reversing to order of command look
up? i.e. look for functions before built in commands.
Cheers,
Tim.
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
fvwm-workers@fvwm.org wrote:
Tim, does my latest commit fix all the bit_gravity problems you
encountered?
Yes, Thanks.
--
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]
Configuration Information [Automatically generated, do not change]:
uname: SunOS silver 5.5.1 Generic_103640-40 sun4u sparc SUNW,Ultra-5_10
compiler flags: gcc -g -O2 -Wall -Wno-implicit-int
FVWM Version: 2.5.2
FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.2
FVWM_DATADIR:
fvwm-workers@fvwm.org wrote:
Fixed.
Thanks, that's much better.
Cheers,
Tim.
--
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
fvwm-workers@fvwm.org wrote:
On Tue, Apr 23, 2002 at 06:05:06PM -0400, Dan Espen wrote:
If I'm on the right track, then I think the menu would have to release
the grab once the menu is torn off
Well, it does release the grabs. But as it is now, whenever the
pointer enters a tear off menu,
[EMAIL PROTECTED] wrote:
I do not think the use of the SizeWindow was correct, it causes problem
when you create the static gc in parse_colorset. If you take a look
at the code the SizeWindow is created after the config file is read.
Sorry, that was my fault. My fvwmrc defines the colorsets as
Configuration Information [Automatically generated, do not change]:
uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10
compiler flags: gcc -g -O2 -Wall -Wno-implicit-int
FVWM Version: 2.5.1
FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1
FVWM_DATADIR:
[EMAIL PROTECTED] wrote:
On 18 Apr 2002 13:46:21 -0600, Gregg Dameron wrote:
Bottom line - PipeRead is brilliant, indispensable - I'd like to see itbe more
so.
My guess is that calling many shell utilities (read: many processes) is
sometimes more expensive than one perl script doing the
Configuration Information [Automatically generated, do not change]:
uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10
compiler flags: gcc -g -O2 -Wall -Wno-implicit-int
FVWM Version: 2.5.1
FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1
FVWM_DATADIR:
[EMAIL PROTECTED] wrote:
I still don't use fvwm-themes but I can confirm core dumps at least a
few times. However only if the config file contains the gradients, if I
use FvwmConsole to dump in the colorsets I get same errors, and the
gradients are changed, but they are not really gradients,
fvwm-workers@fvwm.org wrote:
Wasn't it planned to make the new code complatible with the old
FvwmTheme way? Now, all my colour sets are gone.
Bye
Dominik ^_^ ^_^
Yes, I don't know what's gone wrong. The differences between FvwmTheme.c
and colorset.c are fairly minor and I didn't have a
[EMAIL PROTECTED] wrote:
[FVWM][FvwmErrorHandler]: ERROR *** internal error ***
[FVWM][FvwmErrorHandler]: ERROR Request 56, Error 13, EventType: 0
[FVWM][FvwmErrorHandler]: ERROR *** internal error ***
[FVWM][FvwmErrorHandler]: ERROR Request 72, Error 13, EventType: 0
I think these are being
[EMAIL PROTECTED] wrote:
[FVWM][FvwmErrorHandler]: ERROR *** internal error ***
[FVWM][FvwmErrorHandler]: ERROR Request 56, Error 13, EventType: 0
[FVWM][FvwmErrorHandler]: ERROR *** internal error ***
[FVWM][FvwmErrorHandler]: ERROR Request 72, Error 13, EventType: 0
(EventType may be 19.)
[EMAIL PROTECTED] wrote:
On 16 Apr 2002 15:13:30 +0100, Tim Phipps wrote:
Is it time to move the colorset handling from FvwmTheme to fvwm?
Actually moving the FvwmTheme code and replacing it with a pass-through
module was on my todo list, near the top. But if you may do it, fine.
I
fvwm-workers@fvwm.org wrote:
On Wed, Apr 17, 2002 at 01:02:25PM +, Mikhael Goikhman wrote:
Why not to have one if (Pdepth 2) when defining colorset 0 or any
unused/deleted colorset? The default for normal depths could be as it is
now, 4 colors: black on rgb:be/be/be and its
Hi All,
Is it time to move the colorset handling from FvwmTheme to fvwm? What I'm
thinking of is:
*) copy most of modules/FvwmTheme/FvwmTheme.c to fvwm/colorset.c
*) new command Colorset that calls fvwm/colorset.c
*) new command ReadWriteColors to replace *FvwmThemeReadWriteColors
*) a very
Configuration Information [Automatically generated, do not change]:
uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10
compiler flags: gcc -g -O2 -Wall -Wno-implicit-int
FVWM Version: 2.5.1
FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1
FVWM_DATADIR:
fvwm-workers@fvwm.org wrote:
On Tue, Apr 02, 2002 at 03:54:24PM +0100, Tim Phipps wrote:
I think this might be a bit_gravity problem. I can't get FvwmWinList to
have a gravity of anything other than NorthWest. Does fvwm2 force this?
Yes, it's essential to reduce redraws with opaque resize
Configuration Information [Automatically generated, do not change]:
uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10
compiler flags: gcc -g -O2 -Wall -Wno-implicit-int
FVWM Version: 2.5.1
FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1
FVWM_DATADIR:
Configuration Information [Automatically generated, do not change]:
uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10
compiler flags: gcc -g -O2 -Wall -Wno-implicit-int
FVWM Version: 2.5.1
FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1
FVWM_DATADIR:
Configuration Information [Automatically generated, do not change]:
uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10
compiler flags: gcc -g -O2 -Wall -Wno-implicit-int
FVWM Version: 2.5.1
FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1
FVWM_DATADIR:
[EMAIL PROTECTED] wrote:
On Thu, Mar 28, 2002 at 09:39:26AM +, Tim Phipps wrote:
AddToFunc test
+ I MoveToDesk 0 -1
+ I MoveTodesk 0
Current test
3) Probably the reason for (1) and (2): Although the window is
unmapped and moved to another desk, fvwm still thinks it holds
[EMAIL PROTECTED] wrote:
Hi,
Key F11 A M Next (*) Focus
This doesn't work with FlipFocus, but the Focus command spoils the
most-recently-focused order of the windowlist. Ideally, the wm should know
when we cycled to a window that we want focused, and move it to the start
of the list, in
Configuration Information [Automatically generated, do not change]:
uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10
compiler flags: gcc -g -O2 -Wall -Wno-implicit-int
FVWM Version: 2.5.1
FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1
FVWM_DATADIR:
[EMAIL PROTECTED] wrote:
Description:
FvwmWinList gets messed up when the window at the top of the list
closes. It looks like the old window names are not erased when the
windowlist is redrawn.
Repeat-By:
*FvwmWinList: FollowWindowList
Start several
Configuration Information [Automatically generated, do not change]:
uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10
compiler flags: gcc -g -O2 -Wall -Wno-implicit-int
FVWM Version: 2.5.1
FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1
FVWM_DATADIR:
[EMAIL PROTECTED] wrote:
I hope that the next snapshot will compile.
Tim what is the version of your Xlib? Is there, some where
in your X11 headers, an XOpenOM declaration?
There is no mention of XOpenOM in /usr/openwin/include, X11 is
/usr/openwin/lib/libX11.so.4 if that helps. uname -a:
[EMAIL PROTECTED] wrote:
Ah, do you have a use for this in mind? Why would a user want to
not be informed about syntax errors in his commands?
Yes, I have a couple of instances where and event calls a function that
may or may not exist. I have to do an AddToFunc my_destroy_$w I NOP
before I
Configuration Information [Automatically generated, do not change]:
uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10
compiler flags: gcc -g -O2 -Wall -Wno-implicit-int
FVWM Version: 2.5.1
FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1
FVWM_DATADIR:
[EMAIL PROTECTED] wrote:
Tim,
can you remember the logic behind rounding the window size up or
down? Shouldn't it always be rounded down except for interactive
resizing?
Yes. The reason for rounding up with interactive is to keep the pointer
in the window when the resize is done so you
Configuration Information [Automatically generated, do not change]:
uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10
compiler flags: gcc -g -O2 -Wall -Wno-implicit-int
FVWM Version: 2.5.1
FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1
FVWM_DATADIR:
fvwm-workers@fvwm.org wrote:
On Tue, Mar 19, 2002 at 03:26:24PM +, Tim Phipps wrote:
Nearly, you have to specify a colormap and a border pixel when creating
non-root visual windows, and the gcs used to fill the borders have to be
created from an fvwm visual window. I've attached a patch
[EMAIL PROTECTED] wrote:
Apart from the apparent bugs (windowshade doesn't do anything,
the border layout of small windows is screwed, window corners
sometimes flash above the parent during opaque resizing), what do
you think about the now code (mostly in terms of speed, but feel
free to comment
Configuration Information [Automatically generated, do not change]:
uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10
compiler flags: gcc -g -O2 -Wall -Wno-implicit-int
FVWM Version: 2.5.1
FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1
FVWM_DATADIR:
[EMAIL PROTECTED] wrote:
I think it's the PipeRead but I'm not sure, anyway a sensible fix is to
not send an M_NEW_PAGE if the page hasn't changed and the attached patch
is very simple. Is there any reason to send M_NEW_PAGE when the page
doesn't change?
Yes. It's necessary to force a
[EMAIL PROTECTED] wrote:
An empty FvwmIconMan displays a button with the Title string in it
but it doesn't use the TitleColorset properly, it seems to just
draw a flat button using the colorset background, shadow and hilight
colors. If the colorset has a pixmap it is
Configuration Information [Automatically generated, do not change]:
uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10
compiler flags: gcc -g -O2 -Wall -Wno-implicit-int
FVWM Version: 2.5.1
FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1
FVWM_DATADIR:
Hi All,
I tracked down an endless loop with FvwmIconMan caused by
*FvwmIconMan: *Action Select SendCommand FlipFocus
*FvwmEvent: new_page my_geom_record_all
my_geom_record_all has a PipeRead bash -c ' echo AddToFunc...' in and
I think fvwm has recently started to grab the pointer with
[EMAIL PROTECTED] wrote:
That's because someone thought it would be a good idea to add the
quiet option after the command string. I agree that this is
most unfortunate. Should we break compatibility here?
I vote yes since I've never used the quiet option, it only puts messages
in the log
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
The problem really is that tranparent colrosets don't work in the title
button, here's a patch.
I'll apply the patch. Is this 2.5.0 only or should it be changed in
2.4.7 too?
I guess so, I can't check cvs easily but if 2.4.7 has transparent
Hi All,
NorthEast was going South due to some missing commas, here's a patch.
Cheers,
Tim.
Index: libs/Parse.c
===
RCS file: /u/phippst/share/cvsroot/fvwm/libs/Parse.c,v
retrieving revision 1.7
diff -u -r1.7 Parse.c
---
How come no-one using CVS has noticed this?
Cheers,
Tim.
Index: fvwm/fvwm.h
===
RCS file: /u/phippst/share/cvsroot/fvwm/fvwm/fvwm.h,v
retrieving revision 1.24
diff -u -r1.24 fvwm.h
--- fvwm/fvwm.h 2002/03/11 09:52:11 1.24
+++
[EMAIL PROTECTED] wrote:
Description:
An empty FvwmIconMan displays a button with the Title string in it
but it doesn't use the TitleColorset properly, it seems to just
draw a flat button using the colorset background, shadow and hilight
colors. If the colorset
[EMAIL PROTECTED] wrote:
On Mon, Mar 11, 2002 at 04:29:50PM +, Tim Phipps wrote:
If we remove the decor window the frame window will
have to change to the fvwm visual.
Why? I don't intend to draw into the frame window, only to
reparent the individual sub windows of the decor_w
Configuration Information [Automatically generated, do not change]:
uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10
compiler flags: gcc -g -O2 -Wall -Wno-implicit-int
FVWM Version: 2.5.1
FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1
FVWM_DATADIR:
Morning all,
A feature request:
1) Could I have $[pointer.x]/$[pointer.y] variables to return the
pointer position relative to the window frame? I would use this to
create a WarpToWindow function so the number should be pixels from the
top-left of the fvwm frame. It might be useful
Done. Try pointer.x, pointer.y (position in root window),
pointer.wx, pointer.wy (position in frame) and pointer.cx,
pointer.cy position in client window. See man page for details.
Thanks, it's working nicely now. very useful when you middle-click a
link in mozilla to get a new window,
[EMAIL PROTECTED] wrote:
Mail manually forwarded from Dominik:
[EMAIL PROTECTED] wrote:
Description:
I have a panel that hangs on a window with a border and titlebar.
When the panel is up it looks fine but shading it leaves something
behind. Lowering the window leaves
On 09 Feb 2002 08:00:53 -0600, FVWM CVS wrote:
SendToModule FvwmButtons Title row column ...
This is causing me problems when I try to set a button title to a
number. I have three buttons in a container to display the day, date and
time. This new syntax doesn't work with containers so I have
Hi All,
Another patch, this one adds the ability to do
SendToModule FvwmButtons Icon 7 AIcons/appl/mail/xmail_new.xpm
No documentation yet since I'm not sure if this syntax is any good.
Cheers,
Tim.
Index: modules/FvwmButtons/FvwmButtons.c
[EMAIL PROTECTED] wrote:
Description:
I have a panel that hangs on a window with a border and titlebar.
When the panel is up it looks fine but shading it leaves something
behind. Lowering the window leaves bits on top of other windows.
Repeat-By:
*Buttons: (Title (Side)
Configuration Information [Automatically generated, do not change]:
uname output: SunOS silver 5.5.1 Generic_103640-38 sun4u sparc SUNW,Ultra-5_10
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wall -Wno-implicit-int
prefix: /u/phippst/sunos
FVWM Version: 2.5.1
FVWM_MODULEDIR:
Hi Dominik,
I'm just wondering if tear of menus would be better off in a module?
Making fvwm create its own top level windows makes it more vulnerable to
being killed (try xkill when you don't have anything important on
screen). I seem to remember scwm having the same problem, I'm not sure
[EMAIL PROTECTED] wrote:
On 2 Feb, Dominik Vogt wrote:
I lika that patch :-) Consider it applied. The next logical
thing to do would be to change the pixmap of a button.
I think a man page change is the next thing to do ;-)
Does this patch work if you have multiple instances of
Hi All,
Here's a patch to make FvwmButtons understand this:
FvwmCommand SendToModule FvwmButtons Title 5 You have Mail!
Buttons are numbered from 0 and are in the order in your config file
(containers don't count). It only works with buttons that have a title
in the config file (could
Configuration Information [Automatically generated, do not change]:
uname output: SunOS silver 5.5.1 Generic_103640-38 sun4u sparc SUNW,Ultra-5_10
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wall -Wno-implicit-int
prefix: /u/phippst/sunos
FVWM Version: 2.5.1
FVWM_MODULEDIR:
fvwm-workers@fvwm.org wrote:
Log message:
* Use gnu libiconv in priority against the system iconv
Thanks, all my UTF error messages have gone.
Cheers,
Tim.
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
[EMAIL PROTECTED] wrote:
Alexander Kotelnikov [EMAIL PROTECTED] writes:
# -*-perl-*-
Dan That line is in the file in order to make emacs go into perl mode.
The disadvantage of the #! line is that it contains a hard-coded
path. On my HP-UX machine, Perl is not in /usr/bin.
In
fvwm-workers@fvwm.org wrote:
Log message:
* New commands Any and PointerWindow.
So what's the difference between Any and Next?
Cheers,
Tim.
--
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
[EMAIL PROTECTED] wrote:
On Mon, Jan 28, 2002 at 12:27:35PM +, Tim Phipps wrote:
Part of this problem is that UTF8 isn't a valid charset. The GNU
libiconv documentation says UTF-8 is the correct name. Does anyone know
what the correct name for glibc is?
The glibc support UTF8 and UTF-8
Configuration Information [Automatically generated, do not change]:
uname output: SunOS silver 5.5.1 Generic_103640-38 sun4u sparc SUNW,Ultra-5_10
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wall -Wno-implicit-int
prefix: /u/phippst/sunos
FVWM Version: 2.5.1
FVWM_MODULEDIR:
I sent this direct to Olivier, here it is to the mailing list.
[EMAIL PROTECTED] wrote:
I am afraid to do not understand. what I would like to
implement is automatic configuration. An alternative to
atom is a new (undocumented) _command_, say, ParentRelative.
If a module has a transparent
Configuration Information [Automatically generated, do not change]:
uname output: SunOS silver 5.5.1 Generic_103640-38 sun4u sparc SUNW,Ultra-5_10
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wall -Wno-implicit-int
prefix: /u/phippst/sunos
FVWM Version: 2.5.0
FVWM_MODULEDIR:
fvwm-workers@fvwm.org wrote:
Works fine for me, at least if I correct the typo in the style
name:
Repeat-By:
Style * PlacementOverlapPenalities 1 10 0 1 0.5 10
^^^
Works for me too, sorry about that.
Cheers,
Tim.
--
Visit the official FVWM web
fvwm-workers@fvwm.org wrote:
[FVWM][CMD_Style]: ERROR Bad style option: PlacementOverlapPenalities
Hm, that doesn't explain the error message you get. BTW, is there
a specific reason why negative penalties are not allowed?
It does, the error has gone away and it now does what I want.
Configuration Information [Automatically generated, do not change]:
uname output: SunOS silver 5.5.1 Generic_103640-38 sun4u sparc SUNW,Ultra-5_10
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wall
prefix: /u/phippst/sunos
FVWM Version: 2.5.0
FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.0
fvwm-workers@fvwm.org wrote:
In the end all I have to do is to reactivate the code that we had
before I introduced the decor_w.
Don't do that, there were lots of minor bugs with the drawing of
FvwmBorders and noinset and hiddenhandles. I seem to remeber this all
started when someone
fvwm-workers@fvwm.org wrote:
I like that idea. The only thing I can't imagine is: how can we begin
to implement such a monster of a feature? Yes, it would simplify
a *lot* of code. But to me it looks like a much greater challenge
than the infamous GSFR (Great Style Flag Rewrite) several
[EMAIL PROTECTED] wrote:
This is not the only problem. Here are related ones.
Currently Style list is always optimized. It is not obvious how to do this
with this new StyleFunction. The function functionality just does not
allow to do everything we may want to do with StyleFunction.
I just
Is it time for a rethink of the style system? It seems that the style
command and a few builtin commands manipulate a windows appearance and
behaviour but they don't do a complete job. We could generalize them and
provide a means to do more selective control with some additional commands.
Configuration Information [Automatically generated, do not change]:
uname output: SunOS silver 5.5.1 Generic_103640-38 sun4u sparc SUNW,Ultra-5_10
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wall
prefix: /u/phippst/sunos
FVWM Version: 2.5.0
FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.0
Here's a path that fixes the problem.
Cheers,
Tim.
Index: fvwm/ewmh.c
===
RCS file: /u/phippst/share/cvsroot/fvwm/fvwm/ewmh.c,v
retrieving revision 1.3
diff -u -r1.3 ewmh.c
--- fvwm/ewmh.c 2001/11/26 15:37:37 1.3
+++ fvwm/ewmh.c
Hi All,
The latest snapshot is dated Nov 7th.
Cheers,
Tim.
--
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]
fvwm-workers@fvwm.org wrote:
Can you reproduce this and send the relevant parts of your config?
fvwm2rc:
=
AddToFunc my_destroy_event
+ I Current WarpToWindow
*FvwmEvent: destroy_window my_destroy_event
FvwmEvent
FvwmCommandS
=
In an xterm run FvwmCommand Current RecaptureWindow
Configuration Information [Automatically generated, do not change]:
uname output: SunOS silver 5.5.1 Generic_103640-37 sun4u sparc SUNW,Ultra-5_10
Compiler: gcc
Compilation CFLAGS: -g -O2
prefix: /u/phippst/sunos
FVWM Version: 2.5.0
FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.0
[EMAIL PROTECTED] wrote:
While both of these screenshots are 1px less tall than their
yesterday's AnotherLevel-based analogs (due to lack of buttons?), the
picture is the same -- 2.4 is 2px wider and 1px taller than 2.2.4.
However, I didn't check 2.2.5 yet (in fact, I never used it).
Hi All,
Just gone to update to the latest and there are no snapshots for
September.
Cheers,
Tim.
--
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,
[EMAIL PROTECTED] wrote:
Have XPM support? no: Can't find required X11/xpm.h
Does setting $CPPFLAGS to -I/sup/include help?
Cheers,
Tim.
--
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
Configuration Information [Automatically generated, do not change]:
uname output: SunOS silver 5.5.1 Generic_103640-35 sun4u sparc SUNW,Ultra-5_10
Compiler: gcc
Compilation CFLAGS: -g -O2
prefix: /u/phippst/sunos
FVWM Version: 2.4.1_beta1
FVWM_MODULEDIR:
[EMAIL PROTECTED] wrote:
Did I miss something when I concluded that FvwmBacker can no
longer do what it did before?
No, if FvwmBacker does what the man page says:
*FvwmBackerCommand (Desk d, Page x y) command
Specifies the command to execute when the viewport
fvwm-workers@fvwm.org wrote:
On Wed, Aug 15, 2001 at 08:06:42AM +0200, Olivier Chapuis wrote:
I get a FvwmButtons core dump when I change colorsets and the buttons
contains swallowed shaped app.
FvwmButtons-WMakerApplets: Cause of next X Error.
Error: 4 (BadPixmap)
Major
fvwm-workers@fvwm.org wrote:
I don't think this is a bug. Omitting the commas between the
options is not officially supported. This happens because
OK then can we change the FvwmButtons man page and add a note in NEWS:
*FvwmButtons: (options) [title icon command]
Specifies the
Configuration Information [Automatically generated, do not change]:
uname output: SunOS silver 5.5.1 Generic_103640-35 sun4u sparc SUNW,Ultra-5_10
Compiler: gcc
Compilation CFLAGS: -g -O2
prefix: /u/phippst/sunos
FVWM Version: 2.4.1-beta1
FVWM_MODULEDIR:
Hi All,
I can't find fvwmrect.h in the snapshots. The mail archive has it being
added on 01/08/06.
Cheers,
Tim.
--
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
1 - 100 of 115 matches
Mail list logo
