Re: FVWM: Where's stdout + stderr
On Sat, Nov 13, 2021 at 05:33:15PM -0700, Jaimos Skriletz wrote: > On Sat, Nov 13, 2021 at 5:25 PM Dominik Vogt wrote: > > > > The Devuan upgrade finally forces me to switch to v3, but it's > > giving me a _hard_ time debugging the configuration during the > > transition. There is zero indication of what fvwm is doing in the > > console output. Where's the error output? > > > > Checkout the -v option in the manual page. Fvwm now outputs logs to > ~/.fvwm/fvwm3-output.log and needs to be turned on. You can turn it on > for a running process using the SIGUSR2 signal. Thanks. This "3" stuff really needs to go away. Feels like being back to the nineties. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
FVWM: Where's stdout + stderr
The Devuan upgrade finally forces me to switch to v3, but it's giving me a _hard_ time debugging the configuration during the transition. There is zero indication of what fvwm is doing in the console output. Where's the error output? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: How to make window appear on multiple (but not all) desktops?
On Wed, Feb 26, 2020 at 03:16:12PM -0500, Stephen Talley wrote: > In my FVWM configuration, I can use either Sticky: > > # Show window on all desktops > Style *Emulator* Sticky > > ???or StartsOnDesk: > > # Show window on desktop 3 only > Style *Emulator* StartsOnDesk 3 > > But how can I make a window appear on, say, desktops 3 and 4, but not 0, 1, > or 2? Fvwm does not manage desk objects. The desk a window is present on is just a property of the window, so there is no direct way to do that. However, you can do some scripting: -- snip -- addtofunc custom_gotodesk + I setenv _desk $0 + I test (envmatch _desk 1) all (xeyes) stick on + I test (envmatch _desk 2) all (xeyes) stick on + I test (envmatch _desk 3) all (xclock) stick on + I test (envmatch _desk 4) all (xclock) stick on + I GotoDesk 0 $0 + I All (xeyes) stick off + I All (xclock) stick off + I unsetenv _desk -- snip -- Call this function instead of GotoDesk with custom_gotodesk -- This won't work if you click on the pager to switch desks because the GotoPage command is hard coded there. In that case, FvwmEvent helps: -- snip -- *FvwmEvent: new_desk deskchange Module FvwmEvent addtofunc deskchange + I echo dc $[desk.n] + I setenv _desk $[desk.n] + I test (envmatch _desk 1) all (xeyes) movetodesk + I test (envmatch _desk 2) all (xeyes) movetodesk + I test (envmatch _desk 3) all (xclock) movetodesk + I test (envmatch _desk 4) all (xclock) movetodesk + I unsetenv _desk -- snip -- You'll probably want to put the module execution in the initfunction/restartfunction. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Perform action, one in a time - at every open window at all desks and workspaces.
On Thu, Feb 06, 2020 at 10:00:57PM +0100, Peter Holm wrote: > Is there any way go to every populated desk/page, and perform action > at windows att thoose desk/pages.? Yes, the command is "all", e.g. all Thumbnail_MiniIcons > I would like to perform this modified version of Tavis Ormandy's > tumbnial function at every populated desk/page when some specific > comdirions are met. > > DestroyFunc Thumbnail_MiniIcons > AddToFunc Thumbnail_MiniIcons > + I SetEnv fvwm_mini_icon_size 64 ##Replace with infostore > + I Current Raise > + I SetEnv MiniIcon-$[w.id] $[w.MiniIconFile] > + I ThisWindow (!Shaded, Focused, !Overlapped, !FvwmPager, !Iconic) PipeRead \ > " echo Raise; $[FVWM_USERDIR]/bin/thumb $[w.id] $[fvwm_mini_icon_size]\ > $[FVWM_USERDIR]/tmp/mini_icon.tmp.$[w.id].png $[w.MiniIconFile]\ > && echo WindowStyle EWMHMiniIconOverride, MiniIcon > $[FVWM_USERDIR]/tmp/mini_icon.tmp.$[w.id].png || echo Nop" Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: ResizeMoveMaximize bug or feature? and alternatives
On Fri, Dec 08, 2017 at 12:17:21PM -0600, Mark Nejedlo wrote: > When I use "Maximize 100 100" on an xterm, it leaves a margin on the bottom > and right of the window due to left over fractions of character > height/width, which is fine. Yes. > I'd like to move that margin to the top and > left of the window, so I tried to use "ResizeMoveMaximize frame 100 100 -0 > -0" but the margin is still at the bottom and right. > > Does anyone have any suggestions for how to accomplish what I want? Is this > a bug I should report? Yeah, this may be considered a bug, probably due to the order in which the resizing and movement calculations are done. The new position is calculated before cropping the window's size from 100% to a multiple of the character size. If you follow up the ResizeMoveMaximize with a "Move -0 -0" it should be fine. I'll think about a fix. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: ResizeMoveMaximize and EwmhBaseStruts issue
On Fri, Jul 18, 2014 at 01:54:03PM +0200, Walter Alejandro Iglesias wrote: > I discovered today the ResizeMoveMaximize function. I find it useful > for maximize windows in half screen. But seems it doesn't understand > well EwmhBaseStruts (fvwm.2.6.5). For example: > > With: > > EwmhBaseStruts 0 72 0 0 > > The commands: > > ResizeMoveMaximize frame 50 100 0 0 > ResizeMoveMaximize frame 100 50 0 0 > ResizeMoveMaximize frame 100 50 0 50 > > Ignore the Ewmh setting, and: > > ResizeMoveMaximize frame 50 100 50 0 > > besides places the window some pixels to the right. The Resize like commands do not honour the EWMH working area because in the fvwm philosophy it is wrong to force application choices (like the struts set by the deskto environment) on the user. However, with my latest commits, you can add the suffix "wa" or "da" to the Resize arguments. Then only the given percentage of the size of the working area or dynamic working area is used. E. g. ResizeMoveMaximize 100wa 100wa 0 0 Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: IconMan old patch
On Wed, Aug 06, 2014 at 05:17:06PM +0200, Walter A. Iglesias wrote: > Searching for a way to preserve icon styles on IconMan while hovering it > with the mouse I've found this: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529036 On Sun, 17 May 2009 14:08:51 +0200, Norbert Buchmuller wrote: > Package: fvwm > Version: 1:2.5.26-1 > Severity: normal > Tags: patch > > Currently only the focused and plain buttons can have different styles > and colors when selected, an iconified window's button always looks like > a plain window's button. I prefer to use different style and colors for > iconified windows even if they are selected. > > The attached patch adds the 'IconAndSelectColorset' and > 'IconAndSelectButton' configuration options. > > Note: I sent the patch to the fvwm-workers mailing list a month ago, but > nobody bothered to reply. That's really a strange idea to dump patches into the Debian bug tracking system because nobody took care of it on the list back then. Anyway, I've cleaned up the patch a bit, tested it and will apply it in a minute. > Is there some reason to not adopt that change? Lack of time. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Force application to use my icons
On Thu, Jul 31, 2014 at 12:23:45PM +0200, Walter Alejandro Iglesias wrote: > Is there a effective way to force applications to use the icon I set > with Style * Icon someicon.png? > > I accomplished that for mini icons with: > > Style * EWMHMiniIconOverride > > But I couldn't with icons. I've tried IconOverride, > Icon[Dont]DonateIcon, both settings fails. Overriding icons is tricky. :-) Try something like this Style SeaMonkey IconOverride, Icon the_icon_you_want_wo_use.xpm As far as I can see it is *not* possible to simply remove the icon image, you would have to make a small transparent pixmap and use it as the icon to achieve that. Note that setting icons works differently if the style name is '*', in other words: the "Icon" style needs to be present on a style line with a real name to work here. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: [fvwm] fltk window origin and fvwm
On Thu, May 22, 2014 at 09:02:17PM +, szukw...@arcor.de wrote: > I have written an image viewer that uses FLTK-1.3 . > > On MS-WINDOWS (Win7) the origin of the image window is fixed at > the current position and the image window height and/or width > changes with the width and height of the image. > > On LINUX I use fvwm 2.6.5 . > > With LINUX I have a severe problem: the image window hops around > like a frog when the image window height and width changes with the > width and height of the image. I have sent an EMAIL to the list ... 1. Could you make a minimal version of your program that still exhibits the problem and send me the source code (along with detailed instruction, if necessary)? 2. Also, please turn on some debug otuput with the following fvwm command: bugopts DebugCRMotionMethod on and post the output it produces (before trying (3)). 3. Trying the following styles one after another may or may not help: Style MoveByProgramMethod UseGravity Style MoveByProgramMethod IgnoreGravity Style MoveByProgramMethod AutoDetect (Actually, AutoDetect is the default and would probably not change anything.) 4. Finally, if (3) does not fix the problem and recompiling fvwm is no problem for you, could you please edit the file fvwm/events.c: In the function __handle_cr_on_client() there is some disabled debug output: #if 0 fprintf(stderr, "cre: %d(%d) %d(%d) %d(%d)x%d(%d) fw 0x%08x w 0x%08x " "ew 0x%08x '%s'\n", ... #endif (At line 960 in the latest version.). Could you change the "#if 0" to "if 1" and recompile and reinstall fvwm? This produces more details about what happens when the window is moved or resized. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: How to make xclock transparent?
On Thu, Feb 21, 2008 at 11:53:12PM +0800, for.register for.register wrote: > Thank you all , finally I found FvwmScript is a better choice for me. > And it is more easy to set and more flexible. *Please* don't top-post on this mailing list! > On Thu, Feb 21, 2008 at 11:39 PM, Jesús Guerrero <[EMAIL PROTECTED]> wrote: > > > > On Thu, 21 Feb 2008 14:23:59 +0800 > > "for.register for.register" <[EMAIL PROTECTED]> wrote: > > > > > Hi, all > > > > > > Is it possible to make xclock transparent? > > > > > > Here is my config, it doesn't work. > > > Colorset 8 RootTransparent > > > Style XClock !Title, !Borders, Colorset 3, NeverFocus, \ > > > WindowListSkip, \ > > > CirculateSkip, StartsOnPage 0 0, Forecolor Colorset 3 > > > > > As someone already said, xclock can't be transparent because it just > > lacks that feature. I remember some kind of odd patch around, but that > > was a big time ago. I doub't you can find it anymore. You have a number of > > options: xdaliclock, dclock? (not sure about this one), oclock (probably > > the most similar one if you like analog clocks). And surely many more. > > > > You can also use FvwmScript. There are lots of clocks scripts around. > > > > And there're also the wmaker applets, but I don't know if any of these > > offer transparencies (they are convenient to be swallowd into fvwmbuttons, > > though. > > > > Fvwm colorsets can't do anything at all once you are on the client area > > of the window. > > > > -- > > Jesús Guerrero <[EMAIL PROTECTED]> > > > > Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: How to make xclock transparent?
On Thu, Feb 21, 2008 at 03:47:54PM +0800, for.register for.register wrote: > You mean it is impossible to do that with xclock? Please post replies on this mailing list below the quoted text. To answer your question: yes, xlock has no transparency feature. > On Thu, Feb 21, 2008 at 3:30 PM, Thomas Adam <[EMAIL PROTECTED]> wrote: > > On 21/02/2008, for.register for.register <[EMAIL PROTECTED]> wrote: > > > Is it possible to make xclock transparent? > > > > > > Here is my config, it doesn't work. > > > Colorset 8 RootTransparent > > > Style XClock !Title, !Borders, Colorset 3, NeverFocus, \ > > > WindowListSkip, \ > > > CirculateSkip, StartsOnPage 0 0, Forecolor Colorset 3 > > > > Look at xdaliclock instead, or cheat and use FvwmScript. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: SIGSEGV in FvwmButtons.c
On Wed, Feb 06, 2008 at 09:59:33AM +0600, Roman S Dubtsov wrote:
> On Wednesday 06 February 2008, Dominik Vogt wrote:
> > ... snip ...
> >
> > I think the crash is caused by the call to XFillRectangle in
> > libs/Colorset.c, line 452. Again, the cs_pixmap probably has been
> > destroyed by the time the gc is used. I have committed a patch to
> > CVS that may solve the problem. Can you try it out please?
>
> Looks like this solves the problem. Thanks! Could you please point me at
> modified files?
Sure, here is the patch generated with
$ cvs diff -u -D "2008-02-05 12:00:00"
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
? patch
Index: ChangeLog
===
RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v
retrieving revision 1.3029
retrieving revision 1.3030
diff -u -u -r1.3029 -r1.3030
--- ChangeLog 5 Feb 2008 01:37:21 - 1.3029
+++ ChangeLog 5 Feb 2008 21:04:46 -0000 1.3030
@@ -1,5 +1,14 @@
2008-02-05 Dominik Vogt
+ * libs/Colorset.c (CreateOffsetBackgroundPixmap):
+ catch BadGC when updating root transparent window background
+
+ * libs/XError.c (do_coredump):
+ (ferror_set_temp_error_handler):
+ (ferror_reset_error_handler)
+ (ferror_call_next_error_handler):
+
+ new helper functions
* libs/XError.c (PrintXErrorAndCoredump):
try to dump core the hard way
Index: NEWS
===
RCS file: /home/cvs/fvwm/fvwm/NEWS,v
retrieving revision 1.745
retrieving revision 1.746
diff -u -u -r1.745 -r1.746
--- NEWS3 Feb 2008 23:36:05 - 1.745
+++ NEWS5 Feb 2008 21:04:47 - 1.746
@@ -25,11 +25,13 @@
- Fixed a crash when certain EWMH messages were sent to
unmanaged windows.
- Fixed a memory leak in multibyte codepage code.
+ - Ignore the EWMH staysontop and staysonbottom hints if the
+ EWMHIgnoreStackingOrderHints style is used.
- Fixed a sporadic crash when the root background set by gnome,
fvwm-root, esetroot etc. changes and a root transparent
colour set is used.
- - Ignore the EWMH staysontop and staysonbottom hints if the
- EWMHIgnoreStackingOrderHints style is used.
+ - Fixed spradic crash in modules with root transparent
+ background from colour sets.
---
Index: libs/Colorset.c
===
RCS file: /home/cvs/fvwm/fvwm/libs/Colorset.c,v
retrieving revision 1.71
retrieving revision 1.72
diff -u -u -r1.71 -r1.72
--- libs/Colorset.c 3 Feb 2008 23:12:19 - 1.71
+++ libs/Colorset.c 5 Feb 2008 21:04:47 - 1.72
@@ -29,7 +29,9 @@
#include "libs/Colorset.h"
#include "libs/PictureBase.h"
#include "libs/Graphics.h"
+#include "libs/Grab.h"
#include "libs/PictureGraphics.h"
+#include "libs/XError.h"
/* globals */
colorset_t *Colorset = NULL;
@@ -349,6 +351,26 @@
}
}
+static int is_bad_gc = 0;
+static int BadGCErrorHandler(Display *dpy, XErrorEvent *error)
+{
+ if (error->error_code == BadGC)
+ {
+ is_bad_gc = 1;
+
+ return 0;
+ }
+ else
+ {
+ int rc;
+
+ /* delegate error to original handler */
+ rc = ferror_call_next_error_handler(dpy, error);
+
+ return rc;
+ }
+}
+
/* create a pixmap suitable for plonking on the background of a part of a
* window */
Pixmap CreateOffsetBackgroundPixmap(
@@ -447,11 +469,21 @@
xgcv.ts_x_origin = cs_width-sx;
xgcv.ts_y_origin = cs_height-sy;
fill_gc = fvwmlib_XCreateGC(
- dpy, win, GCTile | GCTileStipXOrigin | GCTileStipYOrigin
- | GCFillStyle, &xgcv);
+ dpy, win, GCTile | GCTileStipXOrigin |
+ GCTileStipYOrigin | GCFillStyle, &xgcv);
+ if (fill_gc == None)
+ {
+ XFreePixmap(dpy, pixmap);
+ return None;
+ }
+ XSync(dpy, False);
+ is_bad_gc = 0;
+ ferror_set_temp_error_handler(BadGCErrorHandler);
XFillRectangle(dpy, pixmap, fill_gc, 0, 0, width, height);
- if (CSETS_IS_TRANSPARENT_ROOT_PURE(colorset) &&
- colorset->tint_percent > 0)
+ if (
+ is_bad_gc == 0 &&
+ CSETS_IS_TRANSPARENT_ROOT_PURE(colorset) &&
+ colorset->tint_percent > 0)
{
FvwmRenderAttributes fra;
@@ -465,6 +497,14 @@
0, 0, width, heig
Re: FVWM: SIGSEGV in FvwmButtons.c
; Reading symbols from /usr/lib/libXfixes.so.3...done.
> Loaded symbols for /usr/lib/libXfixes.so.3
> Reading symbols from /usr/lib/libgsf-1.so.114...done.
> Loaded symbols for /usr/lib/libgsf-1.so.114
> Reading symbols from /usr/lib/libcroco-0.6.so.3...done.
> Loaded symbols for /usr/lib/libcroco-0.6.so.3
> Reading symbols from /usr/lib/libxml2.so.2...done.
> Loaded symbols for /usr/lib/libxml2.so.2
> Reading symbols from /usr/lib/libpangoft2-1.0.so.0...done.
> Loaded symbols for /usr/lib/libpangoft2-1.0.so.0
> Reading symbols from /usr/lib/libpangocairo-1.0.so.0...done.
> Loaded symbols for /usr/lib/libpangocairo-1.0.so.0
> Reading symbols from /usr/lib/libpango-1.0.so.0...done.
> Loaded symbols for /usr/lib/libpango-1.0.so.0
> Reading symbols from /usr/lib/libpcre.so.3...done.
> Loaded symbols for /usr/lib/libpcre.so.3
> Reading symbols from /usr/lib/libXdmcp.so.6...done.
> Loaded symbols for /usr/lib/libXdmcp.so.6
> Reading symbols from /lib/i686/cmov/libpthread.so.0...done.
> Loaded symbols for /lib/i686/cmov/libpthread.so.0
> Reading symbols from /lib/libbz2.so.1.0...done.
> Loaded symbols for /lib/libbz2.so.1.0
> Core was generated by
> `/home/busa/apps/fvwm-cvs/libexec/fvwm/2.5.25/FvwmButtons 8 5 none 0 8 -g
> 816x35'.
> Program terminated with signal 11, Segmentation fault.
> #0 PrintXErrorAndCoredump (dpy=0x8091de0, error=0xbf82e60c,
> MyName=0x808b068 "ComboPanel") at XError.c:85
> 85*nullp = 99;
> (gdb) bt
> #0 PrintXErrorAndCoredump (dpy=0x8091de0, error=0xbf82e60c,
> MyName=0x808b068 "ComboPanel") at XError.c:85
> #1 0x0804fa97 in myErrorHandler (dpy=0x8091de0, event=0xbf82e60c) at
> FvwmButtons.c:577
> #2 0xb7e8c8b3 in _XError () from /usr/lib/libX11.so.6
> #3 0xb7e94069 in ?? () from /usr/lib/libX11.so.6
> #4 0x08091de0 in ?? ()
> #5 0x080c2600 in ?? ()
> #6 0xbf82e6b8 in ?? ()
> #7 0xb7e934c1 in _XGetXCBBuffer () from /usr/lib/libX11.so.6
> #8 0xb7e943ea in _XReply () from /usr/lib/libX11.so.6
> #9 0xb7e88338 in XSync () from /usr/lib/libX11.so.6
> #10 0x0804dfcb in change_colorset (colorset=11, Event=0x0) at
> FvwmButtons.c:2705
> #11 0x0805063a in process_message (type=262144, body=0x8088b50) at
> FvwmButtons.c:2735
> #12 0x08050939 in My_FNextEvent (Dpy=0x8091de0, event=0xbf82ea68) at
> FvwmButtons.c:2443
> #13 0x08051680 in Loop () at FvwmButtons.c:1068
> #14 0x08052fc6 in main (argc=9, argv=0xbf82ed04) at FvwmButtons.c:878
> (gdb) info locals
> msg = "BadGC (invalid GC parameter)", '\0'
> suc =
> (gdb) frame 10
> #10 0x0804dfcb in change_colorset (colorset=11, Event=0x0) at
> FvwmButtons.c:2705
> 2705 XSync(Dpy, 0);
> (gdb) list
> 2700 {
> 2701 if (b->swallow&b_FvwmModule)
> 2702 {
> 2703 /* the bg has changed send the
> info to
> 2704 * modules */
> 2705 XSync(Dpy, 0);
> 2706 send_bg_change_to_module(b,
> Event);
> 2707 }
> 2708 else if
> (CSET_IS_TRANSPARENT_PR(b->colorset) &&
> 2709
> !buttonBackgroundButton(b->parent, NULL))
> (gdb) info locals
> ub = (button_info *) 0x80a0448
> b = (button_info *) 0x80a5e90
> button = 20
> (gdb) info args
> colorset = 11
> Event = (XEvent *) 0x0
> (gdb) quit
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: FVWM: Fvwm vs. Compiz / Compiz Fusion
On Tue, Feb 05, 2008 at 04:48:05PM +, seventh guardian wrote:
> On Feb 5, 2008 4:35 PM, Dominik Vogt <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, Feb 05, 2008 at 03:51:09PM +, seventh guardian wrote:
> (...)
> > > I believe the first part of the work would be to make fvwm support
> > > ARGB visuals. Then, having a proper composite manager module would be
> > > good. As for the effects, it's all in the composite manager code..
> >
> > Note that I have an ARGB patch lying on my disk that is more or
> > less an Xorg specific hack. I wasn't able to find out how to
> > properly detect ARGB visuals. The patch looks like this:
> >
> > /* We assume that a truecolour visual of depth 32 is
> >* actually an ARGB visual (hard to detect otherwise)
> >* in this case, clone the window visual/cmap etc. */
> > if (
> > fw->attr_backup.visual->class == TrueColor &&
> > fw->attr_backup.depth == 32)
> > {
> > /* ARGB visual */
> > ...
> > }
> >
> > Since it's such a blatant hack I refused to apply the patch yet.
>
> I've asked on #xorg-devel and there is a non-hackish way of doing it.
> I'll try to update the patch accordingly.
Have you any written piece of information on this topic?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: FVWM: Fvwm vs. Compiz / Compiz Fusion
On Tue, Feb 05, 2008 at 03:51:09PM +, seventh guardian wrote:
> On Feb 5, 2008 3:25 PM, Hans Voss <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > During the last couple of days I had to use the latest Ubuntu release
> > a lot (7.10 I believe). It had the beautiful graphics from Compiz
> > Fusion running (transparencies, desktop cube, "burn on close").
> >
> > Now, of course this is in NO way a productivity item, but it helps to
> > "poke some eyes"
>
> People tend to focus on eye candy, but the technology allows for
> productive improvements!
>
> Think of shrinking windows instead of iconifying them. You'd get the
> space you need on the desktop, yet you can see what is going on inside
> the window. People currently use ImageMagik to screenshot a window and
> then make an icon out of the image. I used to use it, but it is really
> slow.. With a composite manager it is a matter of directly using the
> image from memory, or even just paint it directly to the screen..
>
> > and after even a couple of minutes I was having
> > withdrawal symptoms for FVWM.
>
> I tend to have them too.. Xcompmgr is the closest I get.. ;)
>
> > However, I got wondering, is there anyway that fvwm might, someday, be
> > able to use/create/"do" such graphical "stunt work" as well?
> > (I don't want much, I know ;-).
>
> I believe the first part of the work would be to make fvwm support
> ARGB visuals. Then, having a proper composite manager module would be
> good. As for the effects, it's all in the composite manager code..
Note that I have an ARGB patch lying on my disk that is more or
less an Xorg specific hack. I wasn't able to find out how to
properly detect ARGB visuals. The patch looks like this:
/* We assume that a truecolour visual of depth 32 is
* actually an ARGB visual (hard to detect otherwise)
* in this case, clone the window visual/cmap etc. */
if (
fw->attr_backup.visual->class == TrueColor &&
fw->attr_backup.depth == 32)
{
/* ARGB visual */
...
}
Since it's such a blatant hack I refused to apply the patch yet.
> > Or is this something that just cannot be done (without replicating all
> > the work Compiz and predecessors have done)? And why we would even
> > want that is yet another discussion all together. (I think, basically,
> > just to poke other people (Vista users, Mac users) in the eye).
>
> As I said, the main work is in the composite manager I guess. But
> currently Compiz requires some hacks to be opengl accelerated, which
> are not wanted.. Maybe the recent EXA extension would help while the
> XGL server isn't ready for production..
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: FVWM: SIGSEGV in colorset.c
On Tue, Feb 05, 2008 at 03:00:18AM +0600, Roman S Dubtsov wrote: > On Tuesday 05 February 2008, Dominik Vogt wrote: > [snip] > > There is no output of FvwmButtons in there. Can you please post > > a stack trace in a new thread please? > > Log file has these lines that are related to FvwmButtons (starting from line > 52): > > ComboPanel: Cause of next X Error. >Error: 13 (BadGC (invalid GC parameter)) >Major opcode of failed request: 70 (PolyFillRectangle) >Minor opcode of failed request: 0 >Resource id of failed request: 0x320 > > I doubt I will be able to post a stack trace since FvwmButtons did not dump > core, they just exited due to some error condition. (The message above looks > like it is from default X11 error handler which exists after printing a error > AFAIK). Could you please hint me how to obtain log file solely from > FvwmButtons? You can't. Most of the modules, including FvwmButtons, do not print much to the console. FvwmButtons should really write a core file here as it crashes with abort(). I have committed a patch that tries to force a core by accessing a null pointer instead. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: SIGSEGV in colorset.c
On Mon, Feb 04, 2008 at 10:30:03PM +0600, Roman S Dubtsov wrote: > On Monday 04 February 2008, Dominik Vogt wrote: > > Should be fixed with my latest commit. I think the X error should > > be gone too. Can you try it and look if the X error reappears, > > pease? > > I have attached a patch which checks image != NULL before calling > XDestroyImage(image). After this, FVWM does not crash, I've applied the patch. > but my FvwmButtons-based panel does (see log attached). There is no output of FvwmButtons in there. Can you please post a stack trace in a new thread please? [snip] > [fvwm.1][parse_colorset]: <> error reading root background > [fvwm.1][parse_colorset]: <> error reading root background [snip] > [fvwm.0][parse_colorset]: <> error reading root background > [fvwm.0][parse_colorset]: <> error reading root background > [fvwm.0][FvwmErrorHandler]: <> *** internal error *** > [fvwm.0][FvwmErrorHandler]: <> Request 73, Error 8, EventType: 28 > [fvwm.0][parse_colorset]: <> error reading root background > [fvwm.0][FvwmErrorHandler]: <> *** internal error *** > [fvwm.0][FvwmErrorHandler]: <> Request 73, Error 8, EventType: 28 > [fvwm.0][parse_colorset]: <> error reading root background [snip] > [fvwm.0][parse_colorset]: <> error reading root background > [fvwm.0][parse_colorset]: <> error reading root background > [fvwm.1][parse_colorset]: <> error reading root background > [fvwm.1][parse_colorset]: <> error reading root background Oh my, you seem to get *tons* of these errors. It looks like some process updates the root backgorund and then immediately changes it quite often. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: SIGSEGV in colorset.c
On Fri, Feb 01, 2008 at 01:02:05AM +0600, Roman Dubtsov wrote: > I have intermittent FVWM crashes. They occur when I start either > gnome-control-center, nvidia-settings, or wine (this one works almost > always). I use FVWM from Debian. > > [EMAIL PROTECTED] 00:51:32 fvwm-cvs]$ fvwm -V > fvwm 2.5.23 compiled on Jan 31 2008 at 23:37:18 > with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm, > SM, Bidi text, > > Core is not always dumped, sometimes FVWM crashes with X11 error > message similar to this: > > [fvwm.0][FvwmErrorHandler]: <> *** internal error *** > [fvwm.0][FvwmErrorHandler]: <> Request 73, Error 8, EventType: 28 > > But today I was able to obtain a core dump and trace SEGFAULT to > particular line of colorset.c: > > (gdb) bt > #0 0x080a723e in parse_colorset (n=11, line=0x80eba93 > "RootTransparent") at > /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/colorset.c:1170 > #1 0x080a826c in update_root_transparent_colorset (prop=287) at > /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/colorset.c:1776 > #2 0x0806d328 in HandlePropertyNotify (ea=0xbfd725f4) at > /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/events.c:3177 > #3 0x0806c001 in dispatch_event (e=0xbfd72624) at > /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/events.c:3926 > #4 0x0806c718 in HandleEvents () at > /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/events.c:3967 > #5 0x0808d955 in main (argc=2, argv=0xbfd730d4) at > /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/fvwm.c:2610 > > Apparently, it is the place where average color is calculated. The > definition of 11 colorset is as follows: > > Colorset 11 fg #D7D9DD, RootTransparent, Tint white 30, sh #404040, hi #404040 > > Is there anything else I can do to help to resolve the issue? > colorset.c in CVS head did not change since 2.5.23, so I did not build > and test it, but will surely do if necessary. Should be fixed with my latest commit. I think the X error should be gone too. Can you try it and look if the X error reappears, pease? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: SIGSEGV in colorset.c
On Fri, Feb 01, 2008 at 08:53:32PM +0100, Viktor Griph wrote: > On Fri, 1 Feb 2008, Roman S Dubtsov wrote: [snip] > >Also, I have attached: > >* crash.log.bz2 --- log file obtained after source modifications described > >in > >Viktor's e-mail, > >* gdb.log.bz2 --- gdb log, > >* fvwm.tar.bz2 --- my config (stripped down a bit). > > It seems as if XGetGeometry does the right thing, and gets the size of the > root pixmap, but XGetImage, still generates a BadMatch error. That is > quite strange, since the XServer is grabbed until after the call to > XGetImage. If the pixmap was invalid, I'd think that XGetGeometry should > fail as well, but apparently it doesn't. That's because it is necessary to call XSync() right after grabbing the X server. The MyXGrabServer() function in libs/Grab.c does this, and we really must never call XGrabServer or XUngrabServer directly anywhere else because My...() does reference conting (I'll fix that in my next patch). However, I have no idea why the XSync() call is necessary. I've never seen any documentation that mentions it, but real life shows that it is necessary (perhaps only with XFree86/Xorg?). > >[snip] > > > >PS. I have added a check for NULL after XGetImage with a goto to the > >cleanup > >portion of the function and was not able to reproduce the crash. > > That's as I expect. THat is actually the best solution I can come up with > right now. But it will not get rid of the X-errors. We always have to cope with unexpected errors anyway. > We should at least add > that kind of checks to all XGetImage calls. But ideally we should also > find a way to not get the error at all. Using MyX(un)Grabserver() should fix this. > I belive the error will be reduced > if the event queue is checked for additional background changes before > doing any redrawing. That should also save updating root transparancy for > a background that is remeoved directly. It will however not guarantee that > the background pixmap isn't removed during the actual update. [snip] Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: SIGSEGV in colorset.c
On Fri, Feb 01, 2008 at 01:10:43PM +0600, Roman S Dubtsov wrote: > Hi, > > Thanks a lot for the replies! > > First, I have forgot to mention that I run FVWM under gnome-session manager. > I > think that this may be important, because sometimes gnome-settings-daemon > resets the wallpaper to the one from gnome settings (I wish I could turn this > off, very annoying). After FVWM crash I still have X up and running and I am > able to restart FVWM from console. > > Next, I have two separate screens: DFP and TV set up using nvidia proprietary > driver. I have also reproduced the issue using open-source nv dirver, so > screen setup probably is not an issue. > > Also, I have attached: > * crash.log.bz2 --- log file obtained after source modifications described in > Viktor's e-mail, > * gdb.log.bz2 --- gdb log, > * fvwm.tar.bz2 --- my config (stripped down a bit). I could take just a quick look at the output. We have average_pixmap = something != 0 cs->width = 720 cs->height = 360 image = 0 k = 0 > The config consists of multiple files that are sourced from .fvwm/config. All > colorset definitions and some uses are in data/decorations/current/script > (Translucent is a left-over from the times I used that patch, now I don't). > Other files where colorsets are used are: > * data/panels/combopanel-horz > * data/scripts/FvwmScript-NetworkPanel > * data/scripts/FvwmScript-ClockCalendar > > PS. I have added a check for NULL after XGetImage with a goto to the cleanup > portion of the function and was not able to reproduce the crash. > > PPS. Just in case, periodically (several minutes after startup, and a day or > two later) I also observe screen lock-ups after dragging a window: window is > not moved, I cannot click on anything, but if there's video output, it goes > on normally. After ~10-15 seconds everything is back to normal. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: SIGSEGV in colorset.c
On Thu, Jan 31, 2008 at 10:08:47PM +0100, Viktor Griph wrote: > On Fri, 1 Feb 2008, Roman Dubtsov wrote: > > >Hello, > > > >I have intermittent FVWM crashes. They occur when I start either > >gnome-control-center, nvidia-settings, or wine (this one works almost > >always). I use FVWM from Debian. > > > >[EMAIL PROTECTED] 00:51:32 fvwm-cvs]$ fvwm -V > >fvwm 2.5.23 compiled on Jan 31 2008 at 23:37:18 > >with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm, > >SM, Bidi text, > > > >Core is not always dumped, sometimes FVWM crashes with X11 error > >message similar to this: > > > >[fvwm.0][FvwmErrorHandler]: <> *** internal error *** > >[fvwm.0][FvwmErrorHandler]: <> Request 73, Error 8, EventType: 28 > > That is a BadMatch error from XGetImage (probalby line 1149 in > colorset.c), which would then return null, and explain the segfault on > line 1170. According to the man page of XGetImage, that is caused by > trying to read outside the pixmap. Which seems quite strange since on line > 1045-1048 the pixmap and size is set to that of the root_pic. And it then > verifies the with at line 1102-1121, and the XServer is grabbed during the > test until after the XGetImage call. The root pixmap may change while the function is running; so the returned pixmap may already be destroyed when GetImage is called. This might happen when using FvwmBacker, fvwm-root, esetroot or similar programs. > >Is there anything else I can do to help to resolve the issue? > >colorset.c in CVS head did not change since 2.5.23, so I did not build > >and test it, but will surely do if necessary. > > I'm interesting in having verified that cs->picture == NULL for the > colorset, and also have the with and hight queried from the image before > the XGetImage printed. I must be missing some possible path here. But I > fail to see how the picture can be non-NULL - at least not with your > Colorset definition. It doesn't need to be NULL. See above. Also not that the given colorset can't be responsible for the crash because it does not have the bg_average bit. Anyway, we definitely need to check the result of XGetImage in all places where it's called (colorset.c, ewmh_icons.c, FImage.c) and implement some fallback strategy. [snip] Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: SIGSEGV in colorset.c
On Fri, Feb 01, 2008 at 01:02:05AM +0600, Roman Dubtsov wrote: > I have intermittent FVWM crashes. They occur when I start either > gnome-control-center, nvidia-settings, or wine (this one works almost > always). I use FVWM from Debian. > > [EMAIL PROTECTED] 00:51:32 fvwm-cvs]$ fvwm -V > fvwm 2.5.23 compiled on Jan 31 2008 at 23:37:18 > with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm, > SM, Bidi text, > > Core is not always dumped, sometimes FVWM crashes with X11 error > message similar to this: > > [fvwm.0][FvwmErrorHandler]: <> *** internal error *** > [fvwm.0][FvwmErrorHandler]: <> Request 73, Error 8, EventType: 28 Hm, fvwm really doesn't crash just because of an X error. I've heard about this "crash without core on X error" stuff several times, but I don't know what's going on. Maybe the X server itself crashes. > But today I was able to obtain a core dump and trace SEGFAULT to > particular line of colorset.c: > > (gdb) bt > #0 0x080a723e in parse_colorset (n=11, line=0x80eba93 > "RootTransparent") at > /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/colorset.c:1170 > #1 0x080a826c in update_root_transparent_colorset (prop=287) at > /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/colorset.c:1776 > #2 0x0806d328 in HandlePropertyNotify (ea=0xbfd725f4) at > /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/events.c:3177 > #3 0x0806c001 in dispatch_event (e=0xbfd72624) at > /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/events.c:3926 > #4 0x0806c718 in HandleEvents () at > /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/events.c:3967 > #5 0x0808d955 in main (argc=2, argv=0xbfd730d4) at > /home/busa/buildspace/x11/wm/fvwm/fvwm-2.5.23/fvwm/fvwm.c:2610 > > Apparently, it is the place where average color is calculated. The > definition of 11 colorset is as follows: > > Colorset 11 fg #D7D9DD, RootTransparent, Tint white 30, sh #404040, hi #404040 > > Is there anything else I can do to help to resolve the issue? Yes, if you still have the core, run the following gdb commands: $ gdb fvwm core (gdb) bt (gdb) info locals (gdb) info args (gdb) p *cs (gdb) p k (gdb) p colors[k-1] (gdb) p colors[k] (gdb) up (gdb) info locals (gdb) info args (gdb) p *cs (gdb) up (gdb) info locals (gdb) info args (gdb) p *te Then post all the output. Also, I need *all* your colour set definitions and all config lines that use them. It's probably best to post your whole config file. I'll be away for a couple of days, but I'll look into the problem next week. > colorset.c in CVS head did not change since 2.5.23, so I did not build > and test it, but will surely do if necessary. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: SIGSEGV in ewmh_events.c:194
On Wed, Jan 30, 2008 at 05:55:55PM +0100, Philipp Kolmann wrote: > Hi, > > I have had several fvwm crashes today with one program and could get it down > to a FVWM issue: > [snip] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb7ba58c0 (LWP 20284)] > 0x080aadcf in ewmh_MoveResizeWindow (fw=0x0, ev=0x80fb180, style=0x0, any=0) > at ewmh_events.c:194 > 194 if ( > (gdb) bt > #0 0x080aadcf in ewmh_MoveResizeWindow (fw=0x0, ev=0x80fb180, style=0x0, > any=0) at ewmh_events.c:194 > #1 0x080a9aaa in EWMH_ProcessClientMessage (exc=0x8119670) > at ewmh_events.c:1485 > #2 0x0806f380 in HandleClientMessage (ea=0xbfd84a14) at events.c:1805 > #3 0x0806c031 in dispatch_event (e=0xbfd84a44) at events.c:3969 > #4 0x0806c73f in HandleEvents () at events.c:4010 > #5 0x0808cba5 in main (argc=1, argv=0xbfd854c4) at fvwm.c:2597 > (gdb) quit > > I have compiled a fresh FVWM CVS checkout from 2 hours ago. > > If I can be of any help diagnosing the problem, please tell me how I can help. I have just committed a fix for that crash. Can you try the most recent CVS code? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: FvwmPager is confused about StickyAcrossPages
On Sat, Jan 19, 2008 at 11:24:43PM -0600, Jonathan Kotta wrote: > FvwmPager will show a StickyAcrossPages window on all desks, not just > the one that the window is on. Here is a minimal config to show the > problem: > > Style FvwmPager Sticky > Style FvwmConsole StickyAcrossPages > > Module FvwmPager 0 1 > FvwmConsole > > If I switch pages, FvwmConsole's little proxy window in the pager > always appears in the current page of the pager. If I switch to the > other desk, the little proxy is still there, always on the current > page, even though the actual window is still on desk 0. Fixed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: force placement after timeout?
On Sun, Jan 13, 2008 at 05:35:21PM -0800, Danek Duvall wrote: > For most windows, I have ManualPlacement set, and it's generally what I > want. But a number of apps throw up non-transient windows of their own > accord which thus require placement. I'm not always around to place the > windows, and so the wireframe will sit there until I return, possibly > hanging other programs due to the server grab. > > Is there any way for fvwm to recognize that placement hasn't happened > within, say, n seconds, and fallback to some other placement policy? There > doesn't seem to be anything in the man page about that (at least in 2.5.18, > or in the NEWS file for the subsequent releases). No, not at the moment, > If there isn't, how hard would it be to add such a feature? I don't think that would be difficult. You need to wind up some timer at the start of the placement loop, and when it fires make it generate some X event to wake up the loop and let it fail. The window would then be placed at +0+0. But maybe that's not necessary. If you know the offending windows, is it an option to give them a different placement policy? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: How to name something that doesn't have "-name"?
On Wed, Jan 09, 2008 at 10:20:01AM +, Chris G wrote: > I want to start up a second copy of Firefox occasionally completely > independent of my 'main' running copy of Firefox. > > This is possible by setting up a new profile and using the -no-remote > option to Firefox so it doesn't try to sue the existing Firefox > instance. > > However I have the following in my .fvwm2rc file:- > > Style Firefox-bin StartsOnPage 1 0 0, SkipMapping > > > How can I give my new copy of Firefox a different name so that it > doesn't get put on the same page as my main Firefox? You can't, firefox does not seem to have any option for that, and I see no way to satisfy your needs in fvwm. > Firefox doesn't > have the -name command line parameter, is there any way that I can > identify it as a different window to FVWM? No, fvwm has no way of guessing if a given window was created by one instance of an application or by a different one. The only way I can think of to solve your problem would be to run a nested X server with xnest in a window and start your sencond copy of firefox there. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: SnapAttraction
On Mon, Jan 07, 2008 at 10:16:28PM +0100, Peder Stray wrote: > On Mon, 7 Jan 2008, Dominik Vogt wrote: > > >On Mon, Jan 07, 2008 at 04:36:01PM +0100, Peder Stray wrote: > >>The documentation for SnapAttraction in the manpage for 2.5.24 seems to > >>be missing many parts that were in the 2.5.23 manpage. I guess > > > >>someone > > > >Me. It's all in the NEWS and doc/ChangeLog. > > > >>updated the command to say is is deprecated but forgot to actually move > >>the documentation to the style-section. > > > >I didn't *move* the documentation but mostly *rewrote* it. It's > >definitely in the released tarball. However, the new documentation is > >not on the web page because I don't know how to do this. > > Probably me thats blind... or just too used to one option per paragraph... > I see in the next one now :) > But the syntax for it is only where it says > its deprecated though, not where the syntax is explained. Yes, hm. The manpage does not list any syntax descriptions for the Style command. I don't like that, and in this particular case it refers to named arguments that are mentioned nowhere else. :-/ Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: SnapAttraction
On Mon, Jan 07, 2008 at 04:36:01PM +0100, Peder Stray wrote: > The documentation for SnapAttraction in the manpage for 2.5.24 seems to > be missing many parts that were in the 2.5.23 manpage. I guess > someone Me. It's all in the NEWS and doc/ChangeLog. > updated the command to say is is deprecated but forgot to actually move > the documentation to the style-section. I didn't *move* the documentation but mostly *rewrote* it. It's definitely in the released tarball. However, the new documentation is not on the web page because I don't know how to do this. > As the documentation says > > SnapAttraction [proximity [behaviour] [Screen]] > > Specifying > 'Style * SnapAttract 15 Screen' ^^^ SnapAttraction > should work, but fvwm > seems to ignore Screen in that case. It works fine with '15 All Screen' > though, > so i guess the documentation is missing a pair of [] > > SnapAttraction [proximity [[behaviour] [Screen]]] No, it's a bug. Consider it fixed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Commands NOT executed sequentially?
On Tue, Jan 01, 2008 at 04:58:44PM -0500, Emilie Ann Phillips wrote: > On Jan 1, 2008 4:49 PM, Attila Nemeth <[EMAIL PROTECTED]> wrote: > > DestroyFunc HelperFnc > > AddToFunc HelperFnc > > + I ThisWindow Exec exec echo $[w.y]:$[w.x]:$[w.id] >>~/.fvwm/wlist.txt > > > > DestroyFunc WSelect > > AddToFunc WSelect > > + I Exec exec rm -f ~/.fvwm/wlist.txt ; touch ~/.fvwm/wlist.txt > > + I All (!Iconic, CurrentPage, AcceptsFocus) HelperFnc > > + I PipeRead "~/.fvwm/SelectWindow.sh" > > > > Now, all this is not relaible. Most of the time it works, but somtimes > > the wlist.txt file ends up empty or missing some windows. Like if the > > PipeRead kicked in too early. Is it possible that the lines in an fvwm > > function (WSelect in this case) are NOT executed sequentially? > > If you look at the documentation for Exec > (http://fvwm.org/documentation/manpages/unstable/fvwm.php#lbBW) it > specifies that Exec doesn't wait for the command to complete. So what > is probably happening is that you are starting to run SelectWindow.sh > before you finish writing to wlist.txt Yes. If you want fvwm to execute the command synchronously, use PipeRead instead of Exec and make sure that your script does not write to stdout. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Problems with qt4 and FVWM 2.5
On Thu, Dec 13, 2007 at 02:25:26PM +0100, Philipp Kolmann wrote: > >>See this little video I took: > >> > >>http://wspk.zid.tuwien.ac.at/philipp/qt4-fvwm-move.avi > >> > >>Maybe I have something f***ed up in my conf. > > > >I see. Try this with an empty configuration file and then add > >commands to see where the problem is. Some styles with "fixed" > >or "ewmh" may be responsible for this in the config file. > > Ok, I started with a complete empty .fvwm dir and just started an xterm > and still see the same problem. > > I have here the Debian SID packages installed. Which packages do you use? I always have the latest code from CVS. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Problems with qt4 and FVWM 2.5
On Thu, Dec 13, 2007 at 11:28:18AM +0100, Philipp Kolmann wrote: > Dominik Vogt wrote: > >Works fine for me: I move the first window by dragging the mouse, > >and when I release the mouse button, the second window moves too. > >Maybe you expected that the second window moves immediately while > >you drag the first one? That is not possible without the > >cooperation of the application; fvwm can only move one window at a > >time, and it was never possible to move multiple windows in a > >group. > > > >However, if your application supports some special EWMH protocol, > >the *application* can move both windows at the same time. Such > >applications usually have some area inside the client window where > >you can click to move the window. Your test application does not > >have anything like this. > > hmm. Well the second window is stuck here. > > See this little video I took: > > http://wspk.zid.tuwien.ac.at/philipp/qt4-fvwm-move.avi > > Maybe I have something f***ed up in my conf. I see. Try this with an empty configuration file and then add commands to see where the problem is. Some styles with "fixed" or "ewmh" may be responsible for this in the config file. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Problems with qt4 and FVWM 2.5
On Wed, Dec 12, 2007 at 12:04:56PM -0500, Joel J. Adamson wrote: > Philipp Kolmann <[EMAIL PROTECTED]> writes: > > > Dominik Vogt wrote: > > The program does the following: > > > > If the first window get's moved, this gets signalled and the first > > window calls a move function for the second window (testwin.cpp -> > > mymove) to move. > > > > The second window uses qt's move call to move the window to another > > position. But this currently doesn't work. > > Does it work in KDE? I don't understand the question. Fvwm does not work any differently when running under KDE. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Problems with qt4 and FVWM 2.5
On Wed, Dec 12, 2007 at 02:59:55PM +0100, Philipp Kolmann wrote: > Dominik Vogt wrote: > >On Mon, Dec 10, 2007 at 09:09:35AM +0100, Philipp Kolmann wrote: > >>while doing my first steps in qt4 I discovered that the move of a window > >>>from a program doesn't work as expected with qt4 and FVWM 2.5. > >> > >>I talked to Trolltech about it and they said it works in FVWM 2.4 but > >>not in 2.5. And since 2.5 is devel snapshot I should raise the issue > >>here, so it might get fixed by FVWM. > >> > >>I have added a small test-app that creates 2 Windows. > >> > >>If you move the first window, the second window should also get > >>replaced. You see the move-events in the textboxes. Currently if I move > >>the "Move me" Window the other window doesn't get moved. > >> > >>Could you please have a look, what's wrong. > > > >I could take a look if could compile the test program (see below). > >Also, you did not tell us your fvwm version. It would also be > >helpful if you explained how your program works internally: I > >have never seen a qt program before. > > Sorry: Details follow: > > fvwm 2.5.23 > qt4 4.3.3 > > To compile the program, you need to generate the makefile: > > first call qmake-qt4 or if you only have qt4 it might be just qmake > > then you have the makefile, so you can just make the binary. > > The program does the following: > > If the first window get's moved, this gets signalled and the first > window calls a move function for the second window (testwin.cpp -> > mymove) to move. Works fine for me: I move the first window by dragging the mouse, and when I release the mouse button, the second window moves too. Maybe you expected that the second window moves immediately while you drag the first one? That is not possible without the cooperation of the application; fvwm can only move one window at a time, and it was never possible to move multiple windows in a group. However, if your application supports some special EWMH protocol, the *application* can move both windows at the same time. Such applications usually have some area inside the client window where you can click to move the window. Your test application does not have anything like this. > The second window uses qt's move call to move the window to another > position. But this currently doesn't work. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Problems with qt4 and FVWM 2.5
On Mon, Dec 10, 2007 at 09:09:35AM +0100, Philipp Kolmann wrote:
> while doing my first steps in qt4 I discovered that the move of a window
> >from a program doesn't work as expected with qt4 and FVWM 2.5.
>
> I talked to Trolltech about it and they said it works in FVWM 2.4 but
> not in 2.5. And since 2.5 is devel snapshot I should raise the issue
> here, so it might get fixed by FVWM.
>
> I have added a small test-app that creates 2 Windows.
>
> If you move the first window, the second window should also get
> replaced. You see the move-events in the textboxes. Currently if I move
> the "Move me" Window the other window doesn't get moved.
>
> Could you please have a look, what's wrong.
I could take a look if could compile the test program (see below).
Also, you did not tell us your fvwm version. It would also be
helpful if you explained how your program works internally: I
have never seen a qt program before.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
$ g++ -o movetest *.cpp
main.cpp:1:24: error: QApplication: No such file or directory
In file included from main.cpp:3:
myqtapp.h:4:24: error: ui_myqtapp.h: No such file or directory
In file included from myqtapp.h:5,
from main.cpp:3:
testwindow.h:4:27: error: ui_testwindow.h: No such file or directory
main.cpp:5:20: error: qevent.h: No such file or directory
testwindow.h:7: error: expected class-name before ',' token
testwindow.h:7: error: 'Ui' has not been declared
testwindow.h:7: error: expected `{' before 'testwindowDLG'
testwindow.h:7: error: invalid function declaration
myqtapp.h:9: error: expected class-name before ',' token
myqtapp.h:9: error: 'Ui' has not been declared
myqtapp.h:9: error: expected `{' before 'myQtAppDLG'
myqtapp.h:9: error: invalid function declaration
main.cpp: In function 'int main(int, char**)':
main.cpp:9: error: 'QApplication' was not declared in this scope
main.cpp:9: error: expected `;' before 'app'
main.cpp:10: error: invalid use of undefined type 'class myQtApp'
myqtapp.h:9: error: forward declaration of 'class myQtApp'
main.cpp:11: error: invalid use of undefined type 'class testwindow'
testwindow.h:7: error: forward declaration of 'class testwindow'
main.cpp:13: error: invalid use of undefined type 'class myQtApp'
myqtapp.h:9: error: forward declaration of 'class myQtApp'
main.cpp:14: error: invalid use of undefined type 'class testwindow'
testwindow.h:7: error: forward declaration of 'class testwindow'
main.cpp:16: error: invalid use of undefined type 'class myQtApp'
myqtapp.h:9: error: forward declaration of 'class myQtApp'
main.cpp:18: error: 'app' was not declared in this scope
myqtapp.cpp:1:18: error: QtGui: No such file or directory
myqtapp.cpp:2:20: error: qevent.h: No such file or directory
In file included from myqtapp.cpp:4:
myqtapp.h:4:24: error: ui_myqtapp.h: No such file or directory
In file included from myqtapp.h:5,
from myqtapp.cpp:4:
testwindow.h:4:27: error: ui_testwindow.h: No such file or directory
testwindow.h:7: error: expected class-name before ',' token
testwindow.h:7: error: 'Ui' has not been declared
testwindow.h:7: error: expected `{' before 'testwindowDLG'
testwindow.h:7: error: invalid function declaration
myqtapp.h:9: error: expected class-name before ',' token
myqtapp.h:9: error: 'Ui' has not been declared
myqtapp.h:9: error: expected `{' before 'myQtAppDLG'
myqtapp.h:9: error: invalid function declaration
myqtapp.cpp:9: error: expected constructor, destructor, or type conversion
before '(' token
myqtapp.cpp:16: error: invalid use of undefined type 'class myQtApp'
myqtapp.h:9: error: forward declaration of 'class myQtApp'
myqtapp.cpp: In member function 'void myQtApp::setTestWin(testwindow*)':
myqtapp.cpp:18: error: 'tw' was not declared in this scope
myqtapp.cpp:19: error: 'textEdit' was not declared in this scope
myqtapp.cpp: At global scope:
myqtapp.cpp:22: error: invalid use of undefined type 'class myQtApp'
myqtapp.h:9: error: forward declaration of 'class myQtApp'
myqtapp.cpp:22: error: 'QMoveEvent' was not declared in this scope
myqtapp.cpp:22: error: expected primary-expression before ')' token
testwindow.cpp:1:18: error: QtGui: No such file or directory
testwindow.cpp:2:20: error: qevent.h: No such file or directory
In file included from testwindow.cpp:4:
testwindow.h:4:27: error: ui_testwindow.h: No such file or directory
testwindow.cpp:6:23: error: QTextStream: No such file or directory
testwindow.h:7: error: expected class-name before ',' token
testwindow.h:7: error:
Re: FVWM: have style changes go into effect immediately?
On Mon, Dec 03, 2007 at 07:10:47PM -0500, C Thala wrote: > > Styles take effect immediately if you have a fairly recent fvwm > > version. The latest stable (2.4.x) and development versions(2.5.x) > > are fine. > > I'm using fvwm-2.4.19. > > > > > You may be using the wrong style name: > > Use > > Style ... NoTitle, HandleWidth 0 > > Style ... NoTitle, BorderWidth 0 > > This is what I have in my .fvm2rc: > > > DestroyFunc xterm-fullscreen > AddToFunc xterm-fullscreen > + I Style "xterm*" UseStyle XtermFSStyle > + I Resize 142c 68c > + I Move 0 -0 Warp > > Style XtermFSStyle \ > NakedTransient ,\ > NoIcon ,\ > NoTitle,\ > MouseFocus ,\ > UseDecor NormalDecor ,\ > BorderWidth 0 ,\ > HandleWidth 0 ,\ > ForeColor Black,\ > BackColor dimgrey > > Key F6 WM Function xterm-fullscreen > > > It mostly works, but the xterm in question doesn't lose the border. I > have to open another xterm for this style to go into efffect. The UseStyle style is one of the few styles that is not applied immediately (UpdateStyles won't help either). Set the styles directly: DestroyFunc xterm-fullscreen AddToFunc xterm-fullscreen + I Style "xterm*" NakedTransient, NoIcon, ... + I Resize 142c 68c + I Move 0 -0 Warp > > > Is there any way that I can have the Style command go into effect +immediately? > > > > I think you are looking for WindowStyle > > Interesting, I have 2.4.19, and this term (WindowStyle) is not > mentioned anywhere in the man page. WindowStyle is new in 2.5.8 or later. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: have style changes go into effect immediately?
On Thu, Nov 29, 2007 at 10:34:21PM -0500, C Thala wrote: > Sometimes I want my xterms to "full screen" in X. Similar to PuTTY's > alt-enter full-screen behavior on win32 platforms. > > > So I have a style defined that removes the borders from an xterm and > resize is to full screen. > > The problem is that the Style command does not go into effect for the > current xterm, but subsequently created ones. Styles take effect immediately if you have a fairly recent fvwm version. The latest stable (2.4.x) and development versions(2.5.x) are fine. You may be using the wrong style name: Use Style ... NoTitle, HandleWidth 0 For windows with "handles", i.e. a border split into eight parts. And use Style ... NoTitle, BorderWidth 0 if your windows don't have handles. > This is not too much of a problem, since I use screen, so I just > detach from that particular xterm, close the xterm, and then start a > new xterm. > > Is there any way that I can have the Style command go into effect immediately? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: closing an existing menu and opening another with one keystroke
On Thu, Nov 22, 2007 at 04:22:10PM -0500, Dan Espen wrote: > "robert muth" <[EMAIL PROTECTED]> writes: > > On 11/22/07, Dan Espen <[EMAIL PROTECTED]> wrote: > > > "robert muth" <[EMAIL PROTECTED]> writes: > > > > I have a bunch of menus assigned to function keys. > > > > When I want to browse them, I have close the previous > > > one using say the ESC key before open a new one. > > > > Is there a way to combine them into one? > > > > > > Make the other menus you want to use submenus with hotkeys assigned. > > > > Hmm, all my menues are top level menus. > > I could move them into a container parent menu > > but would prefer them to be stand alone. > > I don't think it is currently possible. > The current development copy lets you do custom kebindings > for menus but they are restricted to the operations: > > MenuClose > MenuEnterContinuation > MenuEnterSubmenu > MenuLeaveSubmenu > MenuMoveCursor > MenuCursorLeft > MenuCursorRight > MenuSelectItem > MenuScroll > MenuTearOff > > so if you want the menu to popup another menu there > has to be an item in the menu for that action. I have just committed a patch that implements the new command MenuCloseAndExec for menu bindings that does exactly this. Try this: Key F1 MTI[]-_ A MenuCloseAndExec Menu RootMenu With this binding, pressing F1 in any menu closes the menu and opens the RootMenu (without closing a tear off menu). You need the latest code from CVS for this. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Layers
On Sat, Oct 13, 2007 at 12:21:30AM +0400, George 'Nephrite' Potapov wrote: > Is there any limitation on window Layer? The layer must be positive or 0 and no higher than 2147483647. Other values are ignored and replaced by 0. Ciao Dominik ^_^ ^_^ -- Dominik Vogt signature.asc Description: Digital signature
Re: FVWM: Bug in "EnvMatch" return code
On Fri, Oct 05, 2007 at 08:16:41PM -0700, Gautam Iyer wrote: > The following is a bug in Fvwm: > > SetEnv FOO=:0.0 > Test (EnvMatch FOO :2.*) Echo "Match" > TestRc (Match)Echo "Did not match" > > The first Test does not match. However the following TestRc succeeds > (which it should not). From the man page: The TestRc command can only be used inside functions. The above commands can not work because when they are executed, fvwm has no context to store the return code in. Ciao Dominik ^_^ ^_^ -- Dominik Vogt signature.asc Description: Digital signature
Re: FVWM: Adding a "screen w" feature
On Tue, Oct 02, 2007 at 01:13:13PM -0700, Gautam Iyer wrote: > On Tue, Oct 02, 2007 at 01:17:31PM +0200, Dominik Vogt wrote: > > > > I was wondering if it would be possible to add a "screen w" feature to > > > the Xinearama support. > > > > > > Quite often, I decide I want to move the current window to the center of > > > the screen (or just place it again using MinOverlap... features). > > > Unfortunately when fvwm does this it always does this according to a > > > global screen number, or the current screen (i.e. screen containing the > > > mouse pointer). It would be nice if Fvwm could do this based on the > > > screen the window is currently in! Thus my suggestion of "screen w" to > > > move arguments. > > > > > > Any chance of this happening? > > > > Actually, that should have worked out of the box but didn't. I > > have fixed it in CVS. > > Hmm. Don't follow: You mean in CVS "Move screen c 50-50w 50-50w" will > move the window to the center of the screen it is in (regardless of the > screen the pointer is in, or the primary screen number etc). I mean that "move screen w x y" now moves the window to position x/y on that screen. Ciao Dominik ^_^ ^_^ -- Dominik Vogt signature.asc Description: Digital signature
Re: FVWM: Adding a "screen w" feature
On Mon, Oct 01, 2007 at 01:39:12PM -0700, Gautam Iyer wrote: > I was wondering if it would be possible to add a "screen w" feature to > the Xinearama support. > > Quite often, I decide I want to move the current window to the center of > the screen (or just place it again using MinOverlap... features). > Unfortunately when fvwm does this it always does this according to a > global screen number, or the current screen (i.e. screen containing the > mouse pointer). It would be nice if Fvwm could do this based on the > screen the window is currently in! Thus my suggestion of "screen w" to > move arguments. > > Any chance of this happening? Actually, that should have worked out of the box but didn't. I have fixed it in CVS. Ciao Dominik ^_^ ^_^ -- Dominik Vogt signature.asc Description: Digital signature
Re: FVWM: MinWindowSize
On Sun, Sep 30, 2007 at 05:02:44PM +0200, Sven Geggus wrote: > Dominik Vogt schrieb am Sonntag, den 30. September um 16:39 Uhr: > > > At the moment, MinWindowSize and MaxWindowSize do not support > > sizes given in characters. All you can do is give the desired > > minimum size in pixels. > > This does not come very handy in conjunction with Terminal emulators > like rxvt as pixel sizes depend on font-sizes which could even change > during runtime. > > Would it be difficult to patch fvwm to support sizes in characters > for MinWindowSize and MaxWindowSize in addition to pixels? No, not difficult, just a bit of standard work. Currently, the min and max size is calculated immediately when the style is parsed (file style.c). Currently it can be given as a percentage of the screen size (no suffix) or in pixels (suffix 'p'). In both cases it is stored in the style structure expressed in pixels. This data structure needs some extension to describe the fact that the size limits can be expressed in characters. > Looking at the manpage I get the impression, that some commands (e.g. > Resize) already do support something like this. > > Thus my proposed feature would be something like this: > > MinWindowSize 80c 24c Yes. Ciao Dominik ^_^ ^_^ -- Dominik Vogt signature.asc Description: Digital signature
Re: FVWM: MinWindowSize
On Sat, Sep 22, 2007 at 12:22:21AM +0200, Sven Geggus wrote: > as fvwm 2.5.23 has entered Debian unsable I'm just fiddling with > MinWindowSize Option. > > Unfortunately it does not seem to be possible to give a Textual > geometry instead of pixel sizes. > > What I try to achieve is to make rxvt windows not getting resized to > something smaller than 80x24. At the moment, MinWindowSize and MaxWindowSize do not support sizes given in characters. All you can do is give the desired minimum size in pixels. Ciao Dominik ^_^ ^_^ -- Dominik Vogt signature.asc Description: Digital signature
Re: FVWM: windows losing focus while moving through icon manager
On Thu, Aug 16, 2007 at 05:26:26PM +0100, Julian Bradfield wrote: > In article <[EMAIL PROTECTED]> =?ISO-8859-1?B?SmVz+nM=?= Guerrero <[EMAIL > PROTECTED]> writes: > [...] > >> > What I find really odd is that I'm running the exact same fvwm binaries > >> > (fvwm 2.4.18 (or 2.4.20 - it doesn't matter)) > [...] > >I think he should upgrade. That is quite old. > > Er, according to www.fvwm.org, 2.4.20 is the latest stable release. Yes, 2.4.20 is fine, it is still maintained. Please send the information I requested so I requested earlier. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: FVWM: windows losing focus while moving through icon manager under FC6
On Thu, Aug 16, 2007 at 03:22:34PM +0100, Julian Bradfield wrote: > My department has just "upgraded" me to a new machine running FC6 - > I was previously running FC5. What version of fvwm is that? > Among the several things that no longer work properly, one is > window-manager related, but rather odd. Here's what happens. > > I have a very simple desktop: a few windows, mostly xterms and > emacsen, controlled by an IconMgr in the top right. I use SloppyFocus. > > The following undesired behaviour happens: > get a window (xterm) say, move the mouse in, and type - all ok. > move the mouse to the icon manager entry for the window, and then > through the entries for some iconified windows - our window should > remain focussed. Move the mouse out in to the root window. Our window > should still have focus. Indeed, it is still highlighted, but it loses > keyboard focus - or at least doesn't respond to keyboard events. It > doesn't regain focus until the mouse has been moved into another open > window and back again. > > I most often see this when opening a window from the icon manager: > usually I then don't have keyboard focus in it. > However, it's not quite that simple, as occasionally things work when > I expect them not to. > > What I find really odd is that I'm running the exact same fvwm binaries > (fvwm 2.4.18 (or 2.4.20 - it doesn't matter)) as I was before in FC5, but > still this odd behaviour happens, so there must be some change in the > X server or the libraries to make it happen. > > Any ideas? Can you make a minimal sample configuration and exact step by step instructions so that I can try to reproduce it here? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: FVWM: Double click time
On Wed, Aug 15, 2007 at 11:54:34PM -0500, Gautam Iyer wrote: > On Thu, Aug 16, 2007 at 01:21:31PM +1000, Scott Smedley wrote: > > > > Is there any way I can set the double click time in Fvwm? I find the > > > default way too fast for me, and I can never successfully double click. > > > > http://www.fvwm.org/doc/unstable/commands/ClickTime.html > > Thanks. Though that looks like it's setting the time after which mouse > clicks are treated as hold / drag's. > > I was hoping for an option that would increase the interval during which > two clicks would be considered as a double click! I find it almost > impossible to double click as fast as Fvwm expects me to. http://www.fvwm.org/doc/unstable/commands/ClickTime.html :-) Have you *tried* it? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: FVWM: Window placement
On Wed, Jul 25, 2007 at 01:57:49PM -0700, Perry Hutchison wrote: > > > Style ... FixedUSPosition, FixedPPosition > > > Style ... !UsePPosition, !UseUSPosition > > > Style ... FixedUSSize, FixedPSize > > > > > > If that helps, try removing some of the styles. > > > > It semi-worked with all three style lines added. > > However, after placing the window, I could not move it. > > > > I removed the first style line above and the window > > warped back to the center of the screen. > > It's beginning to sound as if FVWM may need to add an > "IgnoreAllClientPlacement" style to handle this sort of > client breakage :( There are three types of window movement: a) Movement cause by input from the program. b) Movement cause by input from the program, and the program claims the user requested it. c) Movement cause by direct interaction between the user and fvwm. Fvwm should always honour (b) and (c), unless the user has explicitly disabled this. The problem is that some programs just claim (b) when they want to move windows to coax the window manager into moving the window. At the moment the code does not differentiate between (b) and (c) anyway. Maybe it should. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: FVWM: Window placement
On Wed, Jul 25, 2007 at 09:11:51PM +0200, Dominik Vogt wrote: > On Tue, Jul 24, 2007 at 03:41:30PM -0400, Ryan Daly wrote: > > On Tue, 2007-07-24 at 20:25 +0100, Thomas Adam wrote: > > > On Tue, Jul 24, 2007 at 03:22:27PM -0400, Ryan Daly wrote: > > > > It's the Black Box ServSelect IP Software. I'm 99% certain it is a Java > > > > application. > > > > > > That doesn't surprise me. Java's a bag of crap. > > > > > > > I tried the above and the only difference is that I cannot move the > > > > window once it warps back to the center of the screen. > > > > > > Ah, damn -- so it's placement _really_ does want to be in the centre of > > > the > > > screen then? That's not good at all. > > > > No, and I gather from your disgust that there's no way to get around it, > > either? > > Try > > Style ... FixedUSPosition, FixedPPosition > Style ... !UsePPosition, !UseUSPosition > Style ... FixedUSSize, FixedPSize > > If that helps, try removing some of the styles. And if it does not help, try out the latest code from CVS. Fvwm was ignoring the Fixed... styles in one specific EWMH message. I have fixed that. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: FVWM: Window placement
On Tue, Jul 24, 2007 at 03:41:30PM -0400, Ryan Daly wrote: > On Tue, 2007-07-24 at 20:25 +0100, Thomas Adam wrote: > > On Tue, Jul 24, 2007 at 03:22:27PM -0400, Ryan Daly wrote: > > > It's the Black Box ServSelect IP Software. I'm 99% certain it is a Java > > > application. > > > > That doesn't surprise me. Java's a bag of crap. > > > > > I tried the above and the only difference is that I cannot move the > > > window once it warps back to the center of the screen. > > > > Ah, damn -- so it's placement _really_ does want to be in the centre of the > > screen then? That's not good at all. > > No, and I gather from your disgust that there's no way to get around it, > either? Try Style ... FixedUSPosition, FixedPPosition Style ... !UsePPosition, !UseUSPosition Style ... FixedUSSize, FixedPSize If that helps, try removing some of the styles. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: FVWM: ModulePath (was: Pager not appearing)
On Wed, Jun 06, 2007 at 02:04:38PM -0400, Dan Espen wrote: > "Thomas Adam" <[EMAIL PROTECTED]> writes: > > On 06/06/07, Scott Smedley <[EMAIL PROTECTED]> wrote: > > > > > Comment out the line that starts > > > > > with "ModulePath" in your .fvwm2rc -- this is about the only thing > > > > > likely to cause the pager not to load. > > > > > > > > Thank you, that solved the problem. > > > > > > Should we consider outputting a warning message when ModulePath is used? > > > Or even obsoleting this command? > > > > I'd vote for "no". It's useful (for those who know what they're > > doing) to be able to change it, The only time I know of any users who > > have used it is often a hang-on from an upgrade of 2.2.X -> 2.4.X -> > > 2.5.X where redefining the ModulePath was quite common for configs > > distributed along with distributions (think AnotherLevel, for > > instance). It's not often we see these sorts of questions, anyway. > > The 2.2 and 2.4 conversion scripts both warned about ModulePath. > It used to be necessary, but now should only be used for user written > modules and should normally only add to the path not reset it. I need it for my non-default install method: ModulePath $HOME/bin This is where all built in modules and all the modules I've written myself are installed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: FVWM: possible StickAcrossPages bug
On Fri, Jun 01, 2007 at 08:11:41PM -0500, Jonathan Kotta wrote: > When I FlipFocus, my windows lose the StickAcrossPages property (plain > Stick seems to be fine), after doing a WindowStyle IconOverride. Here > is a minimal config to reproduce the problem: > > AddToFunc TestFunc > + I WindowStyle IconOverride > + I Next FlipFocus > > Key F11 A A Pick StickAcrossPages > Key F12 A A TestFunc > > Start a few xterms and stick one, then press F12. The order of the > commands in TestFunc doesn't really matter. I can not reproduce this problem. Could you provide step by step instructions, please? Do you have a 64 bit machine? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: FVWM: Resizing windows accross page borders, behaviour changed?
On Wed, May 16, 2007 at 11:38:16AM +0200, Bert 'theBlackDragon' Geens wrote: > I used to be able to move pages whie dragging a window to a differnet > page by passing the page's edge, but when resizing a window the page > edge blocked further movement. > > Now, starting from 2.5.20 I noticed that suddenly when resizing a > window it'll go over the border of the page, setting EdgeResistance > doesn't provide a solution as it allows me to drag windows to the > another page, but it no longer automatically switches pages while > dragging. > > Minimum config required to reproduce: > EdgeScroll 0 0 > > Then resize a window over the border of the page to see the behaviour > I described above. > > Is this an unintended side effect of a change that has happened > recently? In any case I'd like to have the old behaviour back. Thomas > already provided me a patch that restores the previous behaviour and, > which I'm sure, he'll be happy to share, but I'd like official word on > this. It's actually a bugfix. Resizing over the screen edges was documented but never worked. However, a patch that allows to switch that behaviour on and off would be welcome. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: Fwd: FVWM: window placement preference
On Thu, Jan 25, 2007 at 04:38:49PM +0100, Hans Voss wrote: > Hmm. Google Mail somehow forgot that I wanted to write to the list. > Here's the mail again. > > -- Forwarded message -- > From: Hans Voss <[EMAIL PROTECTED]> > Date: Jan 25, 2007 4:36 PM > Subject: Re: FVWM: window placement preference > To: Emilie Ann Phillips <[EMAIL PROTECTED]> > > > Yeah, it is the second monitor setup that does weird things. FVWM > "CenterPlacement" still sees both monitors as one large screen and > tries to place the window in the center of it. [Try that with the > primary on the right and secondary on the left, (so: SEC.|PRI. instead > of PRI.|SEC.). FVWM still thinks the "large desktop" is build as > PRI.|SEC. even though explicit placement on a screen upholds the > correct placement of primary and secondary screens]. Well, have you Xinerama compiled in (see "fvwm --version") and enabled? > On 1/25/07, Emilie Ann Phillips <[EMAIL PROTECTED]> wrote: > >> > and then cascade rather than from left to right? > >> I don't understand what you want. > > > >I mistyped. What I meant was the first window gets placed in the > >center, and subsequent windows get tiled to the left and the right of > >the center and then when all the screen has been taken up, the windows > >get cascaded over top of each other out from the center. > > > >I just tried Style * CenterPlacement and the behavior I got was a little > >odd. > >If my cursor is over my left monitor, the new window gets placed in > >the center of that monitor. If my cursor is over my right monitor, the > >new window gets placed at the very left of that monitor. > > > >And, there doesn't appear to be any tiling or cascading. All windows > >appear in the same spot. (which fits the description in the man page) > > > >I then tried MinOverlapPlacement to see how it worked, and it also > >gave me bizarre behavior on the right monitor but did what I expected > >on the left monitor. > > > >As far as I know, I don't have anything special set up for my two monitors. > >I am using fvwm 2.5.19 and fedora core 5. > > > >For now, I'll just go back to using the default TileCascadePlacement Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: window placement preference
On Tue, Jan 23, 2007 at 12:04:13PM -0500, Emilie Ann Phillips wrote: > Is it possible to have windows default placement to be at the center > of the page, Sure, with CenterPlacement. > and then cascade rather than from left to right? I don't understand what you want. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: FW by linux4miche...@freenet.de : fvwm does not more use libfribidi
On Tue, Jan 16, 2007 at 06:51:29PM +0100, Michelle Konzack wrote: > Hello, I am forwarding this E-Mail I have written to the > Debian BTS to you directly now, since it is too important... > > > - Forwarded message from Michelle Konzack <[EMAIL PROTECTED]> - > Package: fvwm > Version: 1:2.5.18-2 > Severity: grave > > Error description: > > After upgrading my windowmanager to the above version, I have no BIDI > support... Using which package from which source, or was it built from source? If so, what does the configure summary say? > Please look at my package "tdmenu" and the screenshoots > > <http://freenet-homepage.de/linux4michelle/tdmenu/tdmenu.ar.menu.png> > <http://freenet-homepage.de/linux4michelle/tdmenu/tdmenu.he.menu.png> > > On the left side you see the correct versions created with "katoob" and > "gimp". > > This BUG will break ALL installations which need "arabic" and "hebrew" > and since I am owner of a Cybercenter Network/Education Centers in > Morocco, Palestine, Lebanon and Iran it will break in one time over 500 > Debian installations. > > Be sure there are more Installations as my 500... > > This Version of fvwm will bring you enemies if it can not be solved. I don't like being threatened for my *volunteer* work. > -- System Information > Debian Release: 4.0 > Kernel Version: Linux michelle1.private 2.4.32-michelle1 > > > Versions of the packages fvwm depends on: > ii debconf1.4.30.13 Debian configuration management system > ii gdk-imlib1 1.9.14-16.2imaging library for use with gtk (using libp > ii libc6 2.3.2.ds1-22sa GNU C Library: Shared libraries and Timezone > ii libfontconfig1 2.3.1-2generic font configuration library (shared l > ii libfreetype6 2.1.7-6FreeType 2 font engine, shared library files > ii libfribidi00.10.4-6 Free Implementation of the Unicode BiDi algo > ii libglib1.2 1.2.10-9 The GLib library of C routines > ii libgtk1.2 1.2.10-17 The GIMP Toolkit set of widgets for X > ii libice64.3.0.dfsg.1-1 Inter-Client Exchange library > ii libncurses55.4-4 Shared libraries for terminal handling > ii libpng12-0 1.2.8rel-1 PNG library - runtime > ii libreadline5 5.0-10 GNU readline and history libraries, run-time > ii librplay3 3.3.2-8Shared libraries for the rplay network audio > ii libsm6 4.3.0.dfsg.1-1 X Window System Session Management library > ii libstroke0 0.5.1-4support for mouse strokes like those in Ment > ii libx11-6 4.3.0.dfsg.1-1 X Window System protocol client library > ii libxext6 4.3.0.dfsg.1-1 X Window System miscellaneous extension libr > ii libxft22.1.7-1FreeType-based font drawing library for X > ii libxi6 4.3.0.dfsg.1-1 X Window System Input extension library > ii libxpm44.3.0.dfsg.1-1 X pixmap library > ii libxrender10.8.3-7X Rendering Extension client library > ii xlibs 4.3.0.dfsg.1-1 X Keyboard Extension (XKB) configuration dat > ii zlib1g 1.2.2-4.sarge. compression library - runtime > debconf Version: 1.4.30.13 (Provides virtual package debconf-2.0) > ii debconf1.4.30.13 Debian configuration management system > ^^^ (Provides virtual package debconf-2.0) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: Disabling Stroke
On Tue, Aug 29, 2006 at 08:13:03AM -0400, Murphy Hunter Allen wrote: > The subject line reflects both my desire to turn off mouse gestures and > what I feel I've suffered while they are turned on. I know that I can > recompile fvwm without stroke support, and that removing libstroke should > also solve the problem, but I was hoping for a .fvwm2rc based solution. I > can't find any information on disabling the stroke feature and was hoping > someone here could help. I understand your problem. If you don't want mouse gestures, then do not use the feature. Any gesture has to be configured in the config file. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: PATCH: move/resize window grid
On Tue, Aug 29, 2006 at 12:47:49AM +0200, Kobus Retief wrote: > Hi all > > I think the previous mail might be a tad buggered -- the patch wasn't > included as plain text. I blame Sylpheed; fortunately Mutt's still > around to sort out the problem. Anyway, as before: desktop move/resize > grid looks a tad clunky, modified to simple window outline. Desktop > looks cleaner, code looks cleaner, my level of happiness increases ;-) > > Patch against 2.5.17: Thanks for the patch. We have discussed this issue a couple of years ago and decided that we'd rather have the "archaic look" than lose the additional information of the grid lines. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: PATCH: nautilus desktop click-to-focus policy
On Tue, Aug 29, 2006 at 12:52:51AM +0200, Kobus Retief wrote: > Hi all (once again) > > I ran into a bit of trouble when I started playing with nautilus a while > ago -- turns out that ClickToFocusPassesClick does not pass the click > through to the desktop window. For an example: > > -> "Style * ClickToFocus, ClickToFocusPassesClick" > -> Run nautilus as desktop manager > -> open an application window (say, gcalctool) > -> ensure said window is focused > -> try to click on a desktop icon > > Instead of opening said desktop icon, the desktop window is focused. > You'll have to click again to get something done. > > Patch is against 2.5.17 Thank you. I have applied the patch. > diff -Nurp fvwm-2.5.17/fvwm/ewmh.c fvwm-2.5.17-new/fvwm/ewmh.c > --- fvwm-2.5.17/fvwm/ewmh.c 2005-08-04 11:13:07.0 +0200 > +++ fvwm-2.5.17-new/fvwm/ewmh.c 2005-09-22 17:08:24.0 +0200 > @@ -1346,10 +1346,10 @@ int ewmh_HandleDesktop(EWMH_CMD_ARGS) > FPS_GRAB_FOCUS(S_FOCUS_POLICY(SCC(*style)), 1); > > /* ClickToFocusPassesClick */ > - FPS_PASS_FOCUS_CLICK(S_FOCUS_POLICY(SCF(*style)), 0); > + FPS_PASS_FOCUS_CLICK(S_FOCUS_POLICY(SCF(*style)), 1); > FPS_PASS_FOCUS_CLICK(S_FOCUS_POLICY(SCM(*style)), 1); > FPS_PASS_FOCUS_CLICK(S_FOCUS_POLICY(SCC(*style)), 1); > - FPS_PASS_RAISE_CLICK(S_FOCUS_POLICY(SCF(*style)), 0); > + FPS_PASS_RAISE_CLICK(S_FOCUS_POLICY(SCF(*style)), 1); > FPS_PASS_RAISE_CLICK(S_FOCUS_POLICY(SCM(*style)), 1); > FPS_PASS_RAISE_CLICK(S_FOCUS_POLICY(SCC(*style)), 1); Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: fvwm and (un)fullscreen
On Sat, Jul 29, 2006 at 07:43:47PM +0100, Thomas Adam wrote:
> On Sat, 29 Jul 2006 09:12:53 -0600
> "Scott Horowitz" <[EMAIL PROTECTED]> wrote:
>
> > I've noticed a strange issue in fvwm that does not occur in xfwm4 and
> > metacity, for example. I wrote a quick pygtk app to demonstrate the
> > problem:
> > http://www.theskyiscrape.com/scott/test.py
> >
> > Essentially, ./test.py will open a gtk window in fullscreen - if you
> > then press 'f' to toggle fullscreen mode, it successfully
> > unfullscreens, but remains maximized as opposed to reverting to the
> > default_size of 100x100 that I specified. However, if I then toggle
> > the window back to fullscreen and unfullscreen again, it does revert
> > to the non-maximized default_size, and continues to do this every
> > additional time. I think it would be consistent (and the expected
> > behavior) if the application was removed from maximized state after
> > the first unfullscreen.
>
> I think you'll find this to be an issue with GTK as opposed to FVWM
> mishandling anything.
I don't know. The reason is this code in ewmh_events.c:
if (...)
{
execute_function_override_window(NULL, NULL, "Maximize off", 0, fw);
}
else
{
/* the application started fullscreen */
SET_HAS_EWMH_INIT_FULLSCREEN_STATE(fw, EWMH_STATE_NO_HINT);
SET_EWMH_FULLSCREEN(fw, False);
if (DO_EWMH_USE_STACKING_HINTS(fw))
{
new_layer(fw, fw->ewmh_normal_layer);
}
apply_decor_change(fw);
/* the client should resize itself */
}
So, the window is not unmaximized when it leaves fullscreen state
for the first time if it had been created in fullscreen state. The
comment at the end suggests this is on purpose. THe EWMH spec
specifically states that the window manager has to resize the
window, so I think it is a bug.
I'll commit a fix.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: FVWM: Color / ForeColor no longer supported?
On Sun, Jul 23, 2006 at 11:32:05PM +0200, Peter Daum wrote:
> Thomas Adam wrote:
> > You should be using Colorsets regardless in 2.5.X -- deprecation of
> > {Fore,Back}Color is definitely on the cards, and has been for a while.
>
> Is this your personal opinion or general consensus?
General consensus.
> In the past, features always had been marked in the documentation
> as obsolete for quite a while (usually also with sensible
> recommendations what to use instead) before finally stripping
> them - so far the man page says nothing about deprecating direct
> color specifications and it would be pretty bad style to just let
> it fall apart.
Well, if 3.0 is ever released, it won't have much in common with
the current interfaces. It would be useless to mark 50% or more
of the syntax as becoming obsolete.
> In this case it would be particularly regrettable, because the
> colorset mechanism for most purposes is not an equivalent
> alternative. It is mostly tailored to give new users quick eye
> candy - certainly not a bad thing (even though I strongly doubt
> whether these are the kind of people likely to use fvwm). It's
> strength is to quickly adopt the whole desktop to some new
> "Look&Feel"(tm). For people who have made excessive use of the
> possibility to specify different styles for different
> applications/window classes or whatever (not necessarily to
> fulfill aesthetic needs but to facilitate orientation), colorsets
> are just an additional indirection that make a complex setup of
> this flavor more bloated and difficult to maintain.
Colour sets actually make the setup smaller and easier to maintain,
unless you want a different look for every part of the desktop.
Once there are predefined colour sets that define the default
colours of common desktop elements, they will be even easier to
use than the current syntax.
> I personally have a pretty extensive fvwm configuration heavily
> based on m4 (which among other things has provided a simple
> mechanism for consistent colors from fvwm's very beginnings) that
> gradually evolved over more than a decade - a continuity that I
> have always been grateful for ...
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: FVWM: Color / ForeColor no longer supported?
On Mon, Jul 24, 2006 at 01:41:26PM +0200, Peter Daum wrote: > Dan Espen wrote: > > See this thread: > > > > http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/msg15103.html > > Thanks a bunch - this clears things up! > (I reverted the changes identified in > http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/msg15111.html > and can confirm that this was indeed the problem) By the way, help to solve this problem is very welcome. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: Moving iconified windows with 'NoIcon' style across pages
On Mon, Jul 17, 2006 at 02:04:15AM +0400, Serge (gentoosiast) Koksharov wrote: > Hello, > > I'm interested why it's impossible to move iconified windows with > enabled 'NoIcon' style (I prefer 'FvwmIconMan' module) across pages. > Command 'Next (AppName) MoveToPage' simply does nothing. Try it > yourself: > > 1) set 'NoIcon' style for application: 'Style AppName NoIcon' > 2) iconify it > 3) switch to another page > 4) launch 'FvwmConsole' and type 'Next (AppName) MoveToPage' > > Nothing happens :( I can reproduce it. Looks like a bug to me. I'll try to take a look at the problem later. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: Start a window shaded
On Mon, Jul 17, 2006 at 10:56:56AM +0100, Leon wrote: > Hi there, > > I know there is an option to start a window iconic. I have searched the > manual and the internet, it looks to me there is no such option to start > a window shaded? No, there isn't. > Of course we can achieve this by adding a conditional command to > StartFunction or using FvwmEvent. > > It will be nice to have a Style option similar to StartIconic. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: FVWM, GNOME and preloading GNOME libs
On Thu, Jul 13, 2006 at 01:31:25PM +0300, Andrei Popov wrote: > I have FVWM and lots of GTK/GNOME apps. I've noticed that if I run, > say, gedit under GNOME, its starts up significantly faster compared to > starting it under pure FVWM. > > When I run it under FVWM there's some intense disk activity (I take it > some GNOME libs get loaded), and only then the app starts. > > Is there any way to add a line to my ~/.fvwm/config or .xsession that > would preload or cache the essential GNOME libs at FVWM start-up? You could add some dummy Gnome application to your start function. I think it takes so long because the first Gnome app starts a process called gconfd-2 from some obscure library. I've no idea how to start it manually, and frankly I'd prefer if application ran without it - but gnumeric for example refuses to start without it. In older versions it was possible to rename libgconf-2 and gnumeric still started :-( > I googled and read the man but to no avail. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: debian fvwm-gnome
On Wed, Jul 12, 2006 at 07:06:23PM +0100, Thomas Adam wrote: > On Wed, Jul 12, 2006 at 05:02:23PM -, Eduardo Gargiulo wrote: > > Which could be the (dis)advantages on using fvwm-gnome instead of > > fvwm? > > A shed-load of useless libraries you won't ever need. fvwm-gnome > represents everything that the idiot of a maintainer has done in seeing > FvwmGTK and thinking "ooh, GNOME!" and henceforth linked all manner of > superfluous libs against it. See here: > > http://fvwmwiki.org/Installation/InstallationPackages So, what does this "gnome supprt in fvwmgtk" actually do? Is it good for anything? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: Some windows cross the page border
On Tue, Jul 11, 2006 at 11:53:08PM +0200, Frank Hart wrote: > On Tue, Jul 11, 2006 at 09:22:44PM +0200, Dominik Vogt wrote: > > Please add this line to your config file: > > bugopts explainwindowplacement > > That's a nice tip. Unfortunately, the output from a well behaving window > is identical to the offending window: > > Nice window: > [FVWM][__explain_placement]: placed new window 0xe00022 'ssh': > desk 0 (current desk) > current page > screen: current screen: 0 0 1280x1024 (current screen) > position 566 364, placed by fvwm (normal placement) > placement method: MinOverlapPercent > > Offending window: > [FVWM][__explain_placement]: placed new window 0x1a04757 'gmpc - id3 info': > desk 0 (current desk) > current page > screen: current screen: 0 0 1280x1024 (current screen) > position 291 688, placed by fvwm (normal placement) ^^^ Is this the position the window ends up in? If not, the application has moved the window afterwards (it's possible to suppress that). > placement method: MinOverlapPercent > > I also see this output from a few windows (these are behaving correctly): > [FVWM][__explain_placement]: placed new window 0x2400584 'Gajim': > desk 0 (specified by style) > current page > screen: current screen: 1280 0 1280x1024 (current screen) > position 1280 430, placed by fvwm (ignored program specified position) > placement method: MinOverlapPercent > > > If you can't figure out what's wrong from that output, post it to the > > mailing list. > > I obviously can't ;) I can't either because you cut your original message from the context of your reply and I usually don't keep copies of mails to which I replied with context. Please reply to this mail and attach the original message again. ;-) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: Some windows cross the page border
On Tue, Jul 11, 2006 at 05:58:24PM +0200, Frank Hart wrote: > My problem: most windows behave correctly but some applications open > their windows partly in the next page, which is not what I want. > Examples are: btdownloadgui.bittornado, seahorse (the enter passphrase > dialog) and gmpc. It's difficult to tell from afar why a window has been placed where. Please add this line to your config file: bugopts explainwindowplacement And then open the offending window. Fvwm will then print an explanation of how the window was placed to the console. If you can't figure out what's wrong from that output, post it to the mailing list. > I use Xinerama with DesktopSize 4x1 and MinOverlapPercentPlacement > style. Could MinOverlapPercentPlacement be the problem? > > full config: > http://www.xs4all.nl/~frhart/config > > current situation: > http://www.xs4all.nl/~frhart/screenshot_bad.png (notice the "gmpc - id3 > info" window) > > how it should be: > http://www.xs4all.nl/~frhart/screenshot_good.png Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: Eclipse - Terrible Performance
On Thu, Jun 15, 2006 at 12:30:29AM +0200, Ulrich Mueller wrote: > maybe BugOpts FlickeringMoveWorkaround ConfigureNotify and so on... > just found about them in man fvwm MISCELLANOUS COMMANDS Please post your replies below the quoted text on this mailing list (i.e. don't "top post"). FlickeringMoveWorkaround won't help in this case because it modifies focus handling, not window movement. > On Mon, 12 Jun 2006, Jake Colman wrote: > > I am trying to run Eclipse v3.1.2 on FVWM 2.5.7. Performance in this > > environment is abysmal. Screen painting is sluggish, dragging a scroll bar > > causes much flickering. The whole thing is a mess. > > > > By contrast, running Eclipse under CDE (everything else is identical) and > > the > > Eclipse executes quite smoothly. > > > > I'm sure that there is something I can configure to make FVWM shine. Where > > should I begin to look? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: Using WindowShade
On Fri, Jun 02, 2006 at 01:02:47PM +0200, stu wrote: > Hello, > > Using fvwm 2.5.16 I've added window shading functionality to my setup, and > encountered a few problems on the way :) I found that when I shaded a window > to the left or to the right (west or east), the window title would disappear. > To get the title to display on a shaded-left or -right window, I created the > following variable and function : > > SetEnv UNSHADE_TITLE_POS "TitleAtTop" > > DestroyFunc Move-Raise-or-Shade > AddToFunc Move-Raise-or-Shade > + I Raise > + M Move > + D Current (!Shaded) Style "$[w.name]" $1 > + D TestRc (NoMatch) Style "$[w.name]" $[UNSHADE_TITLE_POS] > + D WindowShade $0 > > I have it bound to a double-click in the window border like so : > > Mouse 1 - A Move-Raise-or-Shade N TitleAtTop > Mouse 1 [ A Move-Raise-or-Shade W TitleAtLeft > Mouse 1 ] A Move-Raise-or-Shade E TitleAtRight > Mouse 1 _ A Move-Raise-or-Shade S TitleAtBottom > > With this setup one can double-click in the north, south, east or west borders > of a window and it will shade in that direction and always have its title > displayed. A double-click on the shaded window restores the title to the top > as I have set up. > > Problems : > > 1) When shading a window to left or right the window title disappears. Not > knowing a better way to work around this, I implemented the Style command to > set the window title where I want it to be. However, Style cannot be applied > to a window id, which is unique, so as used above the Style command gets > applied to all windows with the same name. For example, if I have three > windows (ie xterms) on a page, all with the same window title, and I shade one > to the left, the titles of the other two are also moved to the left. I want > them to stay where they are, but I'm not sure what to do now. > > 2) When shading to the right a window who's border is on the right-hand side > of a page, the resulting shaded window is half off the page and half onto the > next page. This doesn't happen with left-, top- or bottom-shaded windows. Try these functions: addtofunc shadewithdir + I thiswindow windowstyle $0 + i thiswindow refreshwindow + I thiswindow windowshade $1 addtofunc shaderight + I thiswindow (shaded) shadewithdir titleattop off + i testrc (nomatch) thiswindow shadewithdir titleatright right addtofunc shadeleft + I thiswindow (shaded) shadewithdir titleattop off + i testrc (nomatch) thiswindow shadewithdir titleatleft left addtofunc shadeup + I thiswindow (shaded) shadewithdir titleattop off + i testrc (nomatch) thiswindow shadewithdir titleattop up addtofunc shadeup + I thiswindow (shaded) shadewithdir titleattop off + i testrc (nomatch) thiswindow shadewithdir titleatbottom down Mouse 1 - A shadeup Mouse 1 [ A shadeleft Mouse 1 ] A shaderight Mouse 1 _ A shadedown > 3) This is minor, but a man page entry for example WindowShade mouse > bindings is incorrect. The man page reads : > > WindowShade [bool] | [[ShadeAgain] direction] > > > > Style * WindowShadeShrinks, \ > WindowShadeSteps 20, WindowShadeLazy > Mouse 1 S - WindowShade North > Mouse 1 S [ WindowShade West > Mouse 1 S ] WindowShade E > Mouse 1 S _ WindowShade S > ^^^ > This should probably be changed to something like : It's already corrected in the current man page. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: how to grow up
On Thu, Jun 01, 2006 at 04:51:06PM +, Mikhael Goikhman wrote:
> On 30 May 2006 12:53:35 +, pipehappy wrote:
> >
> > I tried
> >
> > Maximize 0 growup
> >
> > And it only can grow up to the upper edge of screen if there is no
> > other window(Yes, I also find it in man page).
> >
> > So can anyone give me some tips on how to make the window grow up to
> > the upper edge of the screen no matter there is a window above it or
> > not?
>
> It seems you ask for this:
>
> Pick ResizeMoveMaximize keep w+$[w.y]p w 0
>
> Or "ResizeMove" with the same parameters, depending on what you want.
> Accourding to the man page it should work, but the construction w+10p
> mentioned in the example does not work for me (no time to check why).
No, the example in the man page is totally screwed. There is no
'w' prefix for the resize commands.
I'll commit a patch for that, so the line you posted works; or
better:
Pick ResizeMoveMaximize keep w+$[w.y]p keep 0
> The best I can suggest for now as a replacement for this line is:
>
> FvwmPerl -x
> Pick . ResizeMoveMaximize keep %{ $[cw.height] + $[w.y] }%p w 0
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: FVWM: Counterintuitive menu behaviour near edges of screen
On Thu, Jun 01, 2006 at 07:40:29PM +0400, Serge (gentoosiast) Koksharov wrote: > On Thu, Jun 01, 2006 at 12:55:46PM +0200, Dominik Vogt wrote: > > > With 'AnimationOff' MenuStyle if I open menu close to the right edge of > > But that is not true. The submenu is just shifted left far enough > > to fit onto the screen. > > You described menu behaviour with 'Animation' MenuStyle turned on. No, I didn't; I just forgot about the menu position hints I use (which disabled the pop-up-left feature). > On > the contrary I'm in my post talking about behaviour then 'AnimationOff' > MenuStyle is set. I know. > > ...The menu code can not know if the menu will fit when drawing the > > parent because the submenu may be created on the fly, so it's > > virtually impossible to find out if submenus should be to the left or > > right. > > But I'm talking about the case when submenu _already_ opened up to the > left. It's already opened to the left of the parent menu. The menu code > can know that submenu was posted to the left of its parent? If so, this > edge cases can be easily handled. All we have to do: reverse 'Left > Arrow' & 'Right Arrow' keys which descend to this submenu. I just think doing it the other way round is even less intuitive: 1. The submenu arrow points in the wrong direction (and it can not be draw in the correct direction before actually painting the submenu). 2. In the same parent menu, you may need the "left" key to enter one submenu and the "right" key for another (smaller) one. 3. You have to look at the screen to operate the menu. 4. To leave a series of menus, you may have to press "right" a couple of times followed by several "left" keystrokes. However - ignoring the fact that a series of menus that bounces off the screen edges several times - it may be a good idea to reverse the general submenu direction if the parent menu is so close to the screen edge that the submenu direction would be reverted. (I.e. the menu layout is reversed). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: Counterintuitive menu behaviour near edges of screen
On Thu, Jun 01, 2006 at 01:30:34PM +0400, Serge (gentoosiast) Koksharov wrote: > Hi, > > With 'AnimationOff' MenuStyle if I open menu close to the right edge of > screen submenus appear to the left of the parent menu (because to the > right isn't enough screen space to open them). But that is not true. The submenu is just shifted left far enough to fit onto the screen. > That's OK. But to descend > to this submenu I still need to press "Cursor-Right" key. If I press > "Cursor-Left", parent menu closes and this makes me angry. I'm sure that > in this case 'Left' & 'Right' keys should be also reversed. What your > opinion about this? Maybe, if not all users agree, individual MenuStyle > can be made? The arrow on the submenu item indicates which direction key you have to press. The menu code can not know if the menu will fit when drawing the parent because the submenu may be created on the fly, so it's virtually impossible to find out if submenus should be to the left or right. Personally, I operate many menus without even looking at the screen. If I had to remember where the menu is it would slow me down a lot. Granted - submenus near the screens edge don't work very well anyway. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: 'Iconifiable' condition isn't working properly
On Sun, May 28, 2006 at 10:47:05PM +0400, Serge (gentoosiast) Koksharov wrote: > Hello, > > It looks like 'Iconifiable' condition returns all windows, even windows > with '!Iconifiable' style set. > > For example, I have following style in my config: > > Style FvwmTaskBar !Iconifiable > > Then if I execute command 'All (Iconifiable) Echo $[w.class]' in > .xsession-errors messages among regular window classes, FvwmTaskBar > class is printed. So, I assume it is a bug in the FVWM. You are right. These conditions work only for the first window in the window list. I have committed a fix. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: xpad incorrect behaviour under FVWM
On Wed, Apr 12, 2006 at 12:02:08PM +0200, Viktor Griph wrote: > On Mon, 10 Apr 2006, Serge (gentoosiast) Koksharov wrote: > > >On Fri, Apr 07, 2006 at 05:55:25PM -0400, Dan Espen wrote: > >>When I turn on edit lock, fvwm interprets the first click > >>(and every click) as a request to move the window. > >>The window-move feedback window appears. > > > >Yes, exactly. But in other WMs which I tried, double LMB click allows you > >to > >edit note's text. So, it's xpad behaving incorrectly or FVWM lacks some > >functionality? > > > > I don't think niether fvwm nor xpad behaves incorrectly. However, the way > fvwm deals with xpad's request to move the window causes xpad to recive a > focus out event, and then lock the edit box again. So while no party > really doesn't do anything wrong they don't work well together. The focus > change occurs as fvwm grabs the keyboard to allow for keyboard movement of > the window. > > I beleive that a client should not expect not to lose focus during a > movement, but the EWMH-specification dodn't state anything about it. But if xpad triggers an action on the first button press and still expects to be able to detect double clicks it *is* doing something wrong. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: FvwmButtons panles
On Thu, Mar 30, 2006 at 09:24:57AM +0200, Viktor Griph wrote: > Is it possible to bind both a Panel and an Action to button in > FvwmButtons? Not directly. > I'm shifting layers of my FvwmButtons and would like any > panel to show up on the same layer as the FvwmButtons currently reside > when the Panel is opened. Is it possble to achive that in any way? > > I've been trying with > *FvwmButtons: (Action "PointerWindow All (PanelWindow) Layer 0 $[w.layer], > Panel PanelWindow PanelCommand) (You did not close the double quotes.) > without success. With 2.5.17 (aka CVS) you can do this: *FvwmButtons: (Action (Mouse 1) foo, Panel PanelWindow PanelCommand) addtofunc foo + i PointerWindow All (PanelWindow) Layer $[w.layer] + i sendtomodule FvwmButtons PressButton 3 3 However, the foo function is not just executed when the panel is opened but also when it is closed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: Default Actions for Menues
On Tue, Apr 04, 2006 at 11:32:39AM +0200, Ulrich Mueller wrote: > > Hallo, > > fvwm is great, but to make it greater, > I just thought it would be nice to have actions for menues, > for instance > > AddToMenu MenuTerms "Terminals" Title Exec exec xterm > + "XTerm" Exec exec xterm > + "Rxvt" Exec exec rxvt > + "mlTerm" Exec exec mlterm > > This "default action" could be executed > whenever instead of one entry the title is choosen, > or the superior menu entry which pops up this menu, > the last could be useful even for popup menus without the Title keyword. > > I haven't read the sources yet, > but I imagine this not to be too difficult, > and easily integrable into the existing structure, > maybe some of you has deeper insight, > or is there already some patch of this kind around? There already are default actions for menus which are activated by double clicking to open the menu (or pressing a key twice), e.g. Mouse 1 1 A Menu WindowMenu Delete Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: acroread window problem
On Tue, Mar 28, 2006 at 05:35:55PM +0200, Lucio Chiappetti wrote: > I have been away for some weeks, but now I'm trying to solve my problem of > acroread invoked by a link in firefox (the acroread window is lowered > under the browser window) > > On Wed, 8 Mar 2006, Thomas Adam wrote: > > > > What happens is that, when I click on the pdf URL, firefox first > > > correctly displays the "Opening something.pdf" transient window, then [...] I know it's not a solution to your problem. But have you considered switching from acroread to xpdf? It has become very good lately and has none of the many glitches that acroread has. And it is free, faster (and the command has less letters to type ;-) ). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: Possible bug with TitleWarp and EWMHBaseStruts
On Sun, Mar 26, 2006 at 07:42:30PM -0500, slakmagik wrote: > fvwm 2.5.16 compiled on Feb 14 2006 at 16:37:48 > with support for: ReadLine, XPM, PNG, Shape, XShm, SM, XRender, XFT > Slackware-current > > I usually have TitleWarpOff for my menu, but I was playing with turning > it on. I also have EWMHBaseStruts 0 0 0 1. When I'm in that zone and > open the menu via mouse, title warping fails. If I'm two pixels above > and out of that zone, it works. Is this intended? Because I could see > the EWMHBaseStruts meaning "certain things don't happen here" but > wouldn't expect title warping to be one of them. > > Not a big deal to me, as I'll just turn it back off, but curious. You are right, that behaviour is not correct. However, it has nothing to do with EWMHBaseStruts. The manual page says that TitleWarp works only if the pointer is over the newly mapped menu. Actually that is not the case, given that the relief around the menu does not count as part of the menu. Anyway, TitleWarp should do nothing for root menus. I'll fix that. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: acroread window problem
On Wed, Mar 08, 2006 at 02:07:53PM +0100, Lucio Chiappetti wrote: > On Wed, 8 Mar 2006, Dominik Vogt wrote: > > > Does this help: > > Style * !RaiseTransient, !LowerTransient, !StackTransientParent > > Unfortunately not. Hm, since you did not say which fvwm version you have the correct stylenames may be Style * DontRaiseTransient, DontLowerTransient, DontStackTransientParent > I do not pretend to understand what the above should do, but I do not > think that Acrobat Reader as started by firefox is "transient" (maybe the > popup window which asks me whether I want to save to disk or display with > is a transient of firefox, but acroread should be a totally separated > application, I presume) But you said the "opening pdf blabla" window is transient. The above styles may cause a transient window or its "transientfor" window to be raised or lowered in sometimes unpredictable ways. Firefox or acroread may use different methods to raise their windows. Please try all of the following lines one by after the other in the config file. # This may disable fullscreen mode in Firefox Style * EWMHIgnoreStateHints DestroyFunc EWMHActivateWindowFunc DestroyFunc UrgencyFunc DestroyFunc UrgencyDoneFunc and as a last resort: Style * IgnoreRestack (and make sure you don't have FvwmAuto or FvwmEvent running and raising windows). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: acroread window problem
On Wed, Mar 08, 2006 at 12:18:42PM +0100, Lucio Chiappetti wrote: > I'm experiencing the following problem with acrobat reader windows which > are started clicking on a "pdf" URL (http://somewhere/something.pdf) from > my firefox browser. > > I'd like to make a set of web pages for a presentation, and keep some > auxiliary material in PDF files I can "recall". I'd like to keep the > firefox window as large as possible (maybe even full screen although I > usually do not use it) > > What happens is that, when I click on the pdf URL, firefox first correctly > displays the "Opening something.pdf" transient window, then Acrobat Reader > starts, but is immediately lowered behind the firefox window, before I can > even move to give focus to it. > > This is highly inconvenient. > > I'd like to have the acrobat window on top, so that I can give focus (with > the mouse), move it so that it overlaps only partially the browser window > and toggle front/back (with mouse focus, or eventually menu buttons) > > > This is an extract of my .fvwm2rc of what I think are relevant parts > > ... some general styles > > Style "*" SmartPlacement > Style "*" NoPPosition > Style "*" HilightBack Red > Style "*" SloppyFocus > Style "*" DecorateTransient > Style * ManualPlacementIgnoresStartsOnPage, > ActivePlacementIgnoresStartsOnPage > > ... things related to the browsers > > Style Gecko StartsOnPage 1 0 0, SkipMapping, NoPPosition > Style Netscape StartsOnPage 1 0 0, SkipMapping, NoPPosition > Style mozilla-bin StartsOnPage 1 0 0, SkipMapping, NoPPosition > > ... things related to acrobat (part of standard config file distributed > with SuSE 9.2, I did not write this). I've no idea what the bug number > refers to. > > # see bug #36189 > Style "AcroRead" SmartPlacement, RandomPlacement > > > I tried adding StaysOnBottom to the browsers, but that is not what I want, > since I cannot raise the browser window any more. > > I tried replacing all in Style AcroRead with StartsRaised but does not > look to work (it does the first time, then if window is lowered, acrobat > remembers ... could it be ?) > > I tried adding StaysOnTop to Style AcroRead ... which again is not what I > want. I could force acroread into another page, but I'd prefer to have it > on front in the same page. Does this help: Style * !RaiseTransient, !LowerTransient, !StackTransientParent ? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: warp and move
On Mon, Mar 06, 2006 at 05:31:17PM -0700, Jonathan Kotta wrote: > I'm trying to make a function to warp the pointer to the middle of a > window and then move it, so I can do moves with the keyboard. The > reason I want to warp is because if the pointer is outside of the > window, it eventually gets to the edge sometimes and causes a page > flip. With the obvious solution > > DestroyFunc WarpAndMove > AddToFunc WarpAndMove > + I WarpToWindow 50 50 > + I Move > > the pointer warps to the middle of the window, and then the window > moves as if the move had started before the warp. This doesn't seem > very intuitive to me. Am I missing something? Is there a work > around? It's a bug. I'll have comitted a fix. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: SkipMapping doesn't work with Gaim2-beta2
On Fri, Mar 03, 2006 at 03:32:20PM +0100, Petr Vopalensky wrote: > Dominik Vogt <[EMAIL PROTECTED]> wrote: [snip] > > If the problem is still there, even with "Style * SkipMapping", > > then gaim is using some other way to switch pages. Try out the > > style > > > > Style * GNOMEIgnoreHints > > it doesn't work -- no change in behavior > > > But I don't think that will help. Gaim is probably using the > > > > _NET_DESKTOP_VIEWPORT > > > > or the > > > > _NET_CURRENT_DESKTOP > > > > message to switch viewports (I may add styles to override them). > > i am not fvwm/gaim/gnome/whatever :-) guru, does it means it can't be > set up in fvwm2? It's one of that *stupid* EWMH (Extended Window Manager Hints) features that allows applications override window management policy set up by the user. It allows *applications* to switch desks and pages. This is useful for third party pagers, but gaim misuses it for its own purposes. It would be best if the gaim developers removed this mis-feature. There isn't even a way to disable it selectively in the window manager because the request isn't tied to a window. All I can do is write a command that disables these messages completely, i.e. for *all* applications. Would you contact the gaim developers and ask them to remove this again? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: SkipMapping doesn't work with Gaim2-beta2
On Fri, Mar 03, 2006 at 11:17:42AM +0100, Petr Vopalensky wrote: > Dominik Vogt <[EMAIL PROTECTED]> wrote: > > On Mon, Feb 20, 2006 at 06:09:00PM +0100, Petr Vopalensky wrote: > > > Thomas Adam <[EMAIL PROTECTED]> wrote: > > > > On Mon, Feb 20, 2006 at 05:09:42PM +0100, Petr Vopalensky wrote: > > > > > Style "Gaim" SkipMapping, StartsOnPage 0 2 0, NoPPosition > > > > > > > > > > what is wrong? > > > Put this line in your config file: > > > > bugopts explainwindowplacement on > > > > Then start gaim and check the console output. Fvwm should give > > detailed information how it placed the window. > > > > Ciao > > > > Dominik ^_^ ^_^ > > hi, > > i have got: > -- > [FVWM][__explain_placement]: placed new window 0x1c0003a 'Buddy List': > desk 0 (specified by style) > page 2 0 (specified by style) > position 2800 -1050, placed by fvwm (ignored program specified position) > placement method: TileCascade > -- Is that all? Aren't the further messages for other gaim windows? If fvwm had switched pages during window placement you should have a line (switched to page) right below "page 2 0 ...". Please add "Style * SkipMapping" to your config and check is the problem persits. If not, there's some window with an unexpected name/class/resource. In that case double check the output of the explainwindowplacement option. There should be one with the "(switched to page) message". If the problem is still there, even with "Style * SkipMapping", then gaim is using some other way to switch pages. Try out the style Style * GNOMEIgnoreHints But I don't think that will help. Gaim is probably using the _NET_DESKTOP_VIEWPORT or the _NET_CURRENT_DESKTOP message to switch viewports (I may add styles to override them). > to be sure i set following lines to .fvwm2rc: > Style "gaim" SkipMapping, StartsOnPage 0 2 0, NoPPosition > Style "Gaim" SkipMapping, StartsOnPage 0 2 0, NoPPosition > Style "Buddy List" SkipMapping, StartsOnPage 0 2 0, NoPPosition > > but still the same effect :-( (it moves me to page 0 2 0) > > FvwmIdent says: > Name:Buddy List > Icon Name: Buddy List > Class: Gaim > Resource:gaim > > br,, petr > > -- Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: Titlebar button placement
On Fri, Feb 24, 2006 at 07:25:20AM -0500, Desmond Rivet wrote: > Hi all, > > I see from the fvwm man page that the placement of the titlebar buttons > goes like this: > > 1 3 5 7 90 8 6 4 2 > > Is there any way to change this placement? Let's say I want to shift the > right side buttons to the left by a certain number of pixels...is there > a way to do that? No, unfortunately not. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: SkipMapping doesn't work with Gaim2-beta2
On Mon, Feb 20, 2006 at 06:09:00PM +0100, Petr Vopalensky wrote: > Thomas Adam <[EMAIL PROTECTED]> wrote: > > On Mon, Feb 20, 2006 at 05:09:42PM +0100, Petr Vopalensky wrote: > > > Style "Gaim" SkipMapping, StartsOnPage 0 2 0, NoPPosition > > > > > > what is wrong? > > > > My first suggestion to you would be to use FvwmIdent, or xwininfo to > > make sure that the window name and/or class and/or resource does match > > exactly that of 'Gaim'. It might be that gaim2 has changed slightly in > > that regard. > > > > -- Thomas Adam > > > > -- > > I've been too honest with myself, I should have lied like everybody else. > > yes i checked it at first, but it isn't my problem -- gaim is normally > starting on page 2 0 (it means that style-rule is right, i hope). > besides fvwmident tells that class/resource is still "Gaim" Put this line in your config file: bugopts explainwindowplacement on Then start gaim and check the console output. Fvwm should give detailed information how it placed the window. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: Titlebar code broken?
On Tue, Feb 14, 2006 at 07:23:09PM +0100, Viktor Griph wrote: > On Fri, 10 Feb 2006, Dominik Vogt wrote: > > >On Fri, Feb 10, 2006 at 06:53:07PM +0300, George 'Nephrite' Potapov wrote: > >>Looks like titlebar code ignores color setting for titlebar text. > >>Neither ForeColor/HiliteFore nor Colorset works. > >> > >>Is that a bug or we are in the middle of something? > >It may be the fix I committed yesterday. Can you try again with > >an older version of libs/Flocale.c? Did someone try this out? If not, can anyone please do it? I made a patch that may directly affect the foreground colour of window titles. > I did some tests with the latest CVS vesrion, and I figure it's still > working with colorstets, at least. It's just the behaviour that has > changed some: > Earlier the fg color of the colorset specified with a TitleStyle command > would be used for the text of no-hilight colors if no Colorset style > existed. Now a Colorset style is also required. > > It may still be that ForeColor/HiliteFore are broken, but HilightColorset > and Colorset do work. > > One thing that I also noticed while testing this is that comments on style > lines are broken (i.e It's not possible to comment out a tailing colorset > option of the style list). Of course that's not possible. But it's not nroken - it was never meant to work. > This could be a reasoun to observing things > that really shouldn't happen according to your config. This seems to be > the case with the released 2.5.16 as well (I've not tested this specific > on any other version) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: Titlebar code broken?
On Fri, Feb 10, 2006 at 06:53:07PM +0300, George 'Nephrite' Potapov wrote: > Looks like titlebar code ignores color setting for titlebar text. > Neither ForeColor/HiliteFore nor Colorset works. > > Is that a bug or we are in the middle of something? It may be the fix I committed yesterday. Can you try again with an older version of libs/Flocale.c? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: tearoff menu move
On Thu, Feb 09, 2006 at 11:37:45AM +0100, Daniel Vrcic wrote: > * Mikhael Goikhman <[EMAIL PROTECTED]> [06-02-09 10:13]: > > Do you mean this: > > Style fvwm_menu ManualPlacement > > No. > > > Or you ask how to bind a Move dragging to window decorations? > > Ops, I _forgot_ to tell you that I have no window decorations on TearOff > menus (Style fvwm_menu UsePPosition, NoTitle), sorry! :( But lets just > say that I would like the same thing with root menu. > > What I would like is, for example, to click with mouse button 1 on > SidePic (TearOff) or title (root menu/submenu) and by holding that click > move that menu across the page as I'm moving mouse. You know, just like > fluxbox is doing. :) With this you can get pretty close: style fvwm_menu nobutton 0, nobutton 2, nobutton 4, nobutton 6, nobutton 8 style fvwm_menu nobutton 1, nobutton 3, nobutton 5, nobutton 7, nobutton 9 style fvwm_menu title, handlewidth 0, borderwidth 0 You'll get menus without borders and title buttons, but with a normal window title replacing the menu title. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: Synchronisation problem with FvwmRearrange?
On Wed, Feb 08, 2006 at 10:38:54PM +, Mikhael Goikhman wrote: > On 08 Feb 2006 14:52:29 +0100, David Vilar wrote: > > > > I have a problem with FvwmRearrange. I have two functions like this > > (in a simplified form): > > > > DestroyFunc Expose > > AddToFunc Expose > > + I ModuleSynchronous FvwmRearrange -tile -maximize -m -mn 3 > > + I NoWindow Pick DeExpose [w.id] > > > > DestroyFunc DeExpose > > AddToFunc DeExpose > > + I All (CurrentPage, !Iconic, CirculateHit, !Sticky) Maximize Off > > + I WindowId $0 WarpToWindow 50 50 > > > > The goal is to show an overview of all the windows (inspired by the > > expose of MacOS), and then to be able to select a window, which will > > get focus, and the rest of the windows go back to their initial > > sizes and positions. > > > > The problem I have is that the "NoWindow Pick DeExpose..." line gets > > executed before the windows get reorganized by FvwmRearrange, even > > though I use the ModuleSynchronous command. Is this a bug in > > FvwmRearrange or am I doing something wrong? > > A module should implement an intended synchronization (if applicable) for > ModuleSynchronous to have any effect. Some modules work asynchronously by > default even if you invoke them using ModuleSynchronous, and require an > option (like: FvwmM4 -lock), some other modules work synchronously with > ModuleSynchronous and have an opposite option (FvwmPerl --nolock). > > You may add support for synchronization in FvwmRearrange if you need it. FvwmRearrage really should run synchronously. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: is there a way besides recapture....
On Thu, Feb 09, 2006 at 04:28:38AM +, Mikhael Goikhman wrote: > On 08 Feb 2006 20:54:26 -0500, Peter Williams wrote: > > > > According to FvwmDebug, there are no configure_window messages posted > > to the modules that FvwmPager could latch on to in order to detect > > when a window backcolor changes. The only messages sent to the modules > > in my case (restyling as a result of a window name change) are > > m_visible_name, m_icon_name, and m_window_name. > > > > FvwmPager could check for backcolor when it receives one of those but > > that seems kind of silly... alternatively fvwm could brodcast an > > m_configure_window message to the modules whenever a window style > > changes. > > > > Does that sound reasonable? > > Theoretically this is correct (every change in M_CONFIGURE_WINDOW values > should be reported in one or another way). Practically this will make > this packet even more floody. > > M_CONFIGURE_WINDOW and M_FOCUS_CHANGE should be redesigned. I am not sure > sending fore_color and back_color to the modules is a good idea. I would > send a window colorset number instead. The colorsets are the way to go, > some pager options (like Window3DBorders) only work with colorsets. > > I think the correct things to do in the future is to alter the content of > M_CONFIGURE_WINDOW as I described, send it on every "Style Colorset", and > alter the pager to support colorsets per window (i.e. use the colorset > number sent in the packet, unless global WindowColorsets is defined). Just what I am thinking. I may get around taking a look at the code in the next couple of days. > I see no good reason to support "Style BackColor", since it is scheduled > to be removed in the future. Colorsets should be used instead. Right. I'm not going to write any fixes to the old options. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: is there a way besides recapture....
On Wed, Feb 08, 2006 at 11:28:00AM +, seventh guardian wrote: > On 2/8/06, Peter Williams <[EMAIL PROTECTED]> wrote: > > FvwmPager correctly updates the window titles whenever they change, > > but only updates the backcolors occasionally, in response to focus > > events. > > > > Any suggestions for how to force the pager to redraw? > > > > Hum.. I believe there's no command to force a redraw. I'll look to the > source code and see if I find something to trigger the redraw. I don't > know if that "something" even exists.. There is no way and no reason to trigger redraws manually. It's a bug in FvwmPager. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: FvwmBacker, Pages with pics and slideshow
On Fri, Feb 03, 2006 at 05:05:04PM +0100, Dominik Vogt wrote: > On Thu, Feb 02, 2006 at 04:21:25PM +0100, Michelle Konzack wrote: > > Hello *, > > > > I have a "DeskTopSize 2x1" and want to have in the first > > page a Still-Image and on the second one a Slideshow. > > > > I have tried > > > > __( '/home/michelle.konzack/.fvwm/modules/FvwmBacker' )_ > > / > > | *FvwmBacker: Command (Desk 0, Page 0 0) Exec xpmroot > > $HOME/wall/1024x768.dgse.xpm > > | *FvwmBacker: Command (Desk 0, Page 1 0) Exec tdwallpaperslideshow -d > > $HOME/wall/iraq > > \ > > > > but it does not work. The slideshow is in all two Pages. > > How to solv this? > > I guess the tdwallpaperslideshow runs continually in the > background. It does not know anything about fvwm pages, so it > just overwrites the current background image. And if I'm right, a > new tdwallpaperslideshow is started each time you switch to page > 1 0. > > Ideally it would be possible to reconfigure FvwmBacker at run > time, a la > > # this does *not* work: > FvwmCommand "SendToModule FvwmBacker \ > Command (Desk0, Page 1 0) xpmroot some_picture.xpm" > > Then you could make a script that informs FvwmBackker every n > seconds of a new image: [snip] I just noticed that it's much easier. FvwmBacker accepts new config lines after startup, so you can say something like DestroyModuleConfig FvwmBacker* *FvwmBacker: Command (Desk 0) -solid black *FvwmBacker: Command (Desk 1) -solid blue and FvwmBacker automatically uses the new config. It's not possible to delete config lines, though. And of course you can use colour sets, but it's a waste of memory as the image is buffered in memory. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: FvwmBacker, Pages with pics and slideshow
On Thu, Feb 02, 2006 at 04:21:25PM +0100, Michelle Konzack wrote: > Hello *, > > I have a "DeskTopSize 2x1" and want to have in the first > page a Still-Image and on the second one a Slideshow. > > I have tried > > __( '/home/michelle.konzack/.fvwm/modules/FvwmBacker' )_ > / > | *FvwmBacker: Command (Desk 0, Page 0 0) Exec xpmroot > $HOME/wall/1024x768.dgse.xpm > | *FvwmBacker: Command (Desk 0, Page 1 0) Exec tdwallpaperslideshow -d > $HOME/wall/iraq > \ > > but it does not work. The slideshow is in all two Pages. > How to solv this? I guess the tdwallpaperslideshow runs continually in the background. It does not know anything about fvwm pages, so it just overwrites the current background image. And if I'm right, a new tdwallpaperslideshow is started each time you switch to page 1 0. Ideally it would be possible to reconfigure FvwmBacker at run time, a la # this does *not* work: FvwmCommand "SendToModule FvwmBacker \ Command (Desk0, Page 1 0) xpmroot some_picture.xpm" Then you could make a script that informs FvwmBackker every n seconds of a new image: #!/bin/sh while true; do image=`pick_new_image` FvwmCommand "SendToModule FvwmBacker \ Command (Desk0, Page 1 0) xpmroot '$image'" sleep 15 done But FvwmBacker does not support that yet (anybody is welcome to code the SendToModule stuff). All I can think of is to kill FvwmBacker, reconfigure it with the new image and restart it: #!/bin/sh while true; do FvwmCommand "PipeRead backer_restart_script" sleep 15 done And in the restart script: #!/bin/sh echo KillModule FvwmBacker echo DestroyModuleConfig FvwmBacker* echo "*FvwmBacker: Command (Desk 0, Page 0 0) Exec xpmroot $HOME/wall/1024x768.dgse.xpm" image=`pick_new_image` echo "*FvwmBacker: Command (Desk0, Page 1 0) xpmroot '$image'" echo FvwmBacker (I did not test any of this). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: GTK problem
On Sat, Jan 28, 2006 at 12:16:30PM +0100, Greg BOGNAR wrote: > Dear fvwmers, > > I am afraid this might not properly be an fvwm problem, but it may be > relevant for those of us who care about a consistent-looking Fvwm > desktop. > > I use fvwm mainly with GTK2 applications. All window menus, etc. get > the appropriate decorations, except for OpenOffice, which comes up > with a very ugly interface. But it does get the decorations under > Gnome and Xfce. So what is it that forces OpenOffice to look like a > Gtk application under them? Is there something I should run under > Fvwm to get the desired effect? No, ist's the program itself that draws the menus. There is no other way than rewriting the program itself. The window manager has no part in this at all. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: How to get two lines of text in a MiniButton?
On Mon, Jan 23, 2006 at 09:28:30PM +, Chris Green wrote: > The title says it all really, is it possible to get two lines of text > in a Mini Button? > > I want a button that says:- > > HP > Toolbox > > > I've tried:- > > *MiniButtons "HP > Toolbox" - Exec > > > and I've tried:- > *MiniButton "HP\ > Toolbox" - Exec > > > and I've tried > *MiniButton "HP\nToolbox" - Exec > > > > None of these does what I want. The only way I can think of is to mane an icon with the text on it. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: Problem with FvwmConsole (and other modules) in AFS home
On Thu, Jan 26, 2006 at 04:04:29PM +0100, Friedrich Delgado Friedrichs wrote: > Hi! > > At work, my homedirectory is in AFS, a distributed file system that > has many useful features, but is limited in the kind of files that > it allows. Specifically it's not possible to create a socket in > AFS space. > > Unfortunately that means that I can't use FvwmConsole. > > FvwmConsole tries to setup a socket in $HOME/.fvwm/ by default and > it appears there is no way around this, other than changing the > sourcecode. If you set the environment variable FVWM_USERDIR to a directory name, fvwm uses this directory instead of $HOME/.fvwm. > Other software sets up sockets or named pipes in $TMP or elsewhere > in /var and ensures they are placed in a subdirectory that is only > accessible to the user, as in /tmp/orbit-$USER, /var/run/uscreens > etc. > > I wonder if FvwmConsole could be adapted in a similar way and how > to do this correctly and portably. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: icons sizes
On Tue, Jan 17, 2006 at 10:33:23AM +0100, [EMAIL PROTECTED] wrote: > On Wed, 11 Jan 2006, Dominik Vogt wrote: > > > The only way to get full titles at the moment is to > >disable icon images: > > > > style * icon, iconoverride > > > >(and delete all other icons specifications from the config file). > >thank you for this information > >I tried it, and it works fine for xterms windows (it actually gives as >icon the >reduced image of the original window, which is more informative than >the picture of a terminal...). >It doesn't work for some other programs (gvim, elvis) which have >built-in icons, but it seems that there is nothing to do, except trying >to disable the icon at the program call. Thats what the iconoverride style is good for. The icon related styles work somewhat differently than all other styles. Double check that there are no further icon definitions in your config file. If all else fails, you can specify an icon pixmap that does not exist: style * nonexist.xpm, iconoverride Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: xcompmgr and fvwm bug
On Sat, Jan 14, 2006 at 05:47:03PM -0600, Jonathan Kotta wrote: > I realize that xcompmgr is not supposed to be stable, but it's so > close, and so nice. I don't use the shadows, just transparency. It's > useful to look through a window I'm typing in to see information in > the window beneath it. I've been using it for a couple of weeks, and > I've found these problems: > > - Text display in Motif apps is buggy (OK, I only have one that I really use) > - Shading with multiple steps is buggy (OK, just use steps = 0) I don't think I'm going to fix this one. It's been very tedious to do it right without the new features :-/ > - Edges stop working after xcompmgr is started/stopped (OK, just restart FVWM) > - icons (Not OK, read on) > Symptoms: > Xorg and fvwm use a lot of CPU. Sometimes X uses more, sometimes > fvwm. xcompmgr sometimes starts leaking memory at around 1 MB/sec. This can happen if an application receives messages from the X server faster than it can process them. > Steps to reproduce: > Run FVWM with a null config. Open an app, iconify it, and somehow > remove the icon from view. The apps I was able to reproduce the > problem with were the GIMP, GQView, gnome-terminal, Firefox, and > FrostWire. I think the common trait is that all of them supply an > icon pixmap. It doesn't matter if a window is moved over the icon or > if the window is already over where the icon appears (icons are > automatically lowered). It seems that the icon has to be completely > covered. It happens even if you move to a different page. I've tried > using twm to reproduce the error, no go. > > Fixes: > Kill xcompmgr, the iconified app, or uncover the icon. > > If anyone has encountered this icon problem too, let me know so I know > it's not just my system. I'm using FVWM 2.5.14, Xorg 6.8.2, xcompmgr > from cvs, Ubuntu Breezy, and nVidia drivers 1.0-8178. I'd love to debug this problem, but I'm still stuck with XFree. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: move relative to screen?
On Fri, Jan 13, 2006 at 11:33:50PM +0100, Peter Daum wrote: > Dominik Vogt wrote: > > >It looks like I forgot the Move function. You can simulate it > >with > > > > # third arg = screen number > > addtofunc move_with_screen > > + i move $0 $1 > > + i $2 > > > >In the next release (fvwm-2.5.15) you can say > > > > Thanks a lot for this quick solution! > (Shouldn't "ResizeMove" and "ResizeMoveMaximize" also be adapted?) They share the same option parsing code, so they get the new option automatically. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM: move relative to screen?
On Thu, Jan 12, 2006 at 07:27:23PM +0100, Peter Daum wrote: > Hi, > > I recently added a 2nd monitor to my system (and generally, > I was pleased, how little changes to my fvwm configuration, > were necessary :) > > A little question: For many commands/options there are provisions > to specify a screen, but I couldn't find anything like this regarding > "move". Did I overlook something? > > "Move 0 0" for example always moves to the upper left corner of the left > screen - is there any way to move to the top left of the current screen? It looks like I forgot the Move function. You can simulate it with # third arg = screen number addtofunc move_with_screen + i move $0 $1 + i $2 In the next release (fvwm-2.5.15) you can say Move screen 1 50 50 Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
