Re: Is 257 some sort of magic number?
On Thu, 8 Aug 2002, Tim Phipps wrote:
[SNIP]
I can't help feeling that 257 is the wrong number for all this stuff and
256 is the correct number. It might be better to just leave most of
these things as unsigned shorts or pass XColor's around and convert to
byte size pieces as late as possible.
/257 will take ages on any processor, /256 will take one cycle on most.
257 is the correct scale factor for conversion between 8- and
16-bit colors: 257==0x101, so that e.g. 0xFF becomes 0x if multiplied
by 0x101, not 0x100. Most of XFree86 code uses 0x101 as conversion factor
(see xc/{lib/X11/LRGB.c,programs/xcmsdb/xcmsdb.c}. Of course, when
scaling from 16 down to 8 bits 256 will work almost as good as 257, but
unification-wise 257 is better.
_
Dmitry Yu. Bolkhovityanov
The Budker Institute of Nuclear Physics
Novosibirsk, Russia
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: [Patch] MinIconSize/MaxIconSize
On Sun, 23 Jun 2002, Steve Talley wrote: Since this is the main usage, is this possible to change the syntax to: Style * IconSize x y[, x2 y2] where one pair means both min and max values? Excellent idea. Certainly simplifies the syntax. A small comment: IconSize suggests that icons fill be somehow forced (shrinked/grown) to specified size. Isn't IconSizeLimits a more intuitive name? _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: gcc warnings
On Tue, 21 May 2002, Dan Espen wrote: I don't know if its just my compiler, but current CVS generates this warning: ../../fvwm2_5_2/fvwm/colorset.h:28:8: warning: extra tokens at end of #endif directive Too bad, it sure makes the #endif directive more readable. Maybe its my version of gcc, after all, the token is #defined to nothing. Usually it is enough to change from #endif TOKEN to #endif /* TOKEN */ _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: libtoolization ?
On Fri, 29 Mar 2002, Olivier Chapuis wrote: - if shared is enabled (and the system support shared lib) fvwm will build and install a sharable library libfvwm.so-version and fvwm2 and the modules will be dynamically linked to this library. Of course the system must be able to perform the dynamic link (e.g., for Linux either updating /etc/ld.so.conf and run ldconfig or adding the directory lib directory in LD_LIBRARY_PATH after the install). ELF allows to embed this directory into the binary, so there's no need to touch either ld.so.conf or LD_LIBRARY_PATH [1]. This is achieved with -rpath option to the linker. According to Linux's ld(1), Solaris also supports this feature, and SunOS additionaly requires -rpath-link. I've checked DEC OSF1 4.0 and IRIX 6.5, and both of them do support -rpath. In OpenBSD this switch is called -R, but at least in 2.7 -rpath is also accepted for compatibility with GNU ld. [1] Both of these decisions are not so handy: ld.so.conf is only root-writable, so that user wouldn't be able to install a custom shared copy of fvwm; LD_LIBRARY_PATH should be set (in fact, added to) in the user's login file, name of which isn't known (.profile | .bash_profile | .zshenv | .tcshrc | .whatever ...). _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
configure and gnomeConf.sh
Hi! I've just downloaded fvwm-snap-20020206 and tried to compile it with installdir ~/usr/ . The commandline was ./configure --prefix=$HOME/usr There was a line in configure output: checking for gnomeConf.sh file in /export/ring1/bolkhov/usr/lib... not found (my $HOME is /export/ring1/bolkhov) and finally a With GNOME support in FvwmGtk? no: Can't find working gnome-config There is /usr/lib/gnomeConf.sh, so I modified the command line to ./configure --prefix=$HOME/usr --with-gnome-libs=/usr/lib/ but that had no effect -- configure still looks in ~/usr/lib/. I've skimmed through the script itself, and there's a code to set $gnome_prefix to the argument of --with-gnome-libs, but later there's some alchemy with --with-gnome, which probably overrides the value of $gnome_prefix. Not that I care about Gnome, but just for correctness... Am I missing something, or is there really a mistake in configure script? _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: CHARSET environment variable
On Fri, 1 Feb 2002, Olivier Chapuis wrote: So nl_langinfo and iconv should not be used :o) but it does not seem that there are obvious (portable) replacement (XFree =4.0.2 has some Xutf8 functions, we may try to use if available). Please, please, please don't use Xutf8*() functions -- they are absolutely unportable. They were introduced due to the inadequacy (sp?) of the current X locale model: only one locale at one moment, so Xutf8*() are current-locale-independent. But their unportability completely outweighs their advantage. _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: changes to fvwm that have not been included in 2.4.5 for unknown reasons
On Tue, 29 Jan 2002, Dominik Vogt wrote: Actually, I'm guessing that setpgrp with 2 parameters takes the same arguments as setpgid. I don't have any documentation about that version. Can anybody help me out here? From OpenBSD 2.7 setpgid(2): COMPATIBILITY setpgrp() is identical to setpgid(), and is retained for calling conven- tion compatibility with historical versions of BSD. BSD/OS 3.1 has a similar statement. BTW, I've checked OSF1 4.0 and Solaris 2.5.1 (both are POSIX-compliant and have setpgrp(void)), and from their manpages setpgrp() has the same effect as setpgid(0,0). _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Unconstrained Move
On Wed, 30 Jan 2002, Mikhael Goikhman wrote: On 30 Jan 2002 13:56:24 +0100, Dominik Vogt wrote: On Wed, Jan 30, 2002 at 11:59:11AM +, Mikhael Goikhman wrote: I want to add an option to interactive Move, so snap is ignored. What do you think is a preferable syntax approach? I may think about 2 possible solutions. 1) New command UnconstrainedMove with the same arguments as Move. 2) An option to Move and AnimatedMove (other *Move* commands are not interactive) called NoSnap. Why? What is the advantage to turning SnapAttraction off before moving and enabling it afterwards? This is not only SnapAttraction, but SnapGrid and EdgeResistance too. There is no way to restore their previous state. Thinking about this, it may be done by adding a new command Snap: Snap Disable Snap Enable This would affect snap in interactive Move and interactive placement. Still having an option to do an unconstrained Move would be ok. I myself would bind it to decoration dragging when shift is pressed. Wouldn't it be better to simply modify the behaviour of Move instead of adding new command? I.e., use the Alt/Meta modifier interactively to switch off snapping/edgeresistance? (Shift and Ctrl are already used for large/precise movement via keyboard.) This approach gives the user an ability to change his mind on the fly and is consistent with behaviour in many other programs (Gimp uses Shift in pencil tool to draw lines; Windoze Explorer uses Shift/Ctrl to force move/copy when dragging a file; and there is definitely some prog which uses modifiers exactly to switch off snapping (was it XFig?)). _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: redesign of wire frame move/resize look?
On Tue, 29 Jan 2002, Dominik Vogt wrote: Um, I wanted to suggest to remove the lines inside the window. Now: +---+ | | | | +---+ | | | | +---+ | | | | +---+ After the suggested change: +---+ | | | | | | | | | | +---+ This is a relic from twm. I can't think of any other window manager that still has these additional lines in the middle of the window. In fact, there IS a case when these lines are usable: when some app maps a huge window, which doesn't fit to screen (a frequent case is a Netscape driven by poorly written javascript). And with these two additional rectangles you can at leat understand how much of a window is on the screen when you drag it. BTW, what's that with these frames which makes the code much more complicated and slower? The get_outline_rects() looks simple. _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Remaining UTF troubles | was (Re: fvwm is absolutely unusable with UTF-8 locales)
On Fri, 25 Jan 2002, Olivier Chapuis wrote: [SNIP] I am not sure that it is so easy to remove these 3 bytes (which are not only 3 bytes and which can be found at different place in the string). Basically, we have to rewrite the XmbTextPropertyToTextList function (maybe in a weak form). Hmmm... Those 3 bytes (generally, much more) are ISO2022 escape sequences. The 2022 is a very complex encoding (AFAIR, 2022 interpreter is a state machine). It is documented somewhere, but those docs are hard to read. I'll ask Juliusz Chroboczek about how to strip 2022 tags in the easiest way. But I'm sure the reply wouldn't be fast -- he is quite busy with upcoming XFree 4.2.0 now. I wouldn't use any Xmb function to do it though. On Solaris, all the Xmb functions are in a separate shared library. I think if you use that function you'll cause another shared library to be loaded. I think the sequence is Esc ( B or Esc B ( (I forget which). Do I have to apply such changes to 2.4.5? Not for my benefit. Hum I do not know what we should do. But it seems that since the 2002-01-01 all the Europe (East and West) needs to use a locale with a non iso8859-1 charset. Also, I think that a lot of people outside of the Europe will want the EuroSign. The problem is not that people need the EuroSign in window titles, the problem is that if you use a charset != iso8859-1 and if the window title of an xterm (and of a lot of others programs) contains non ascii characters, then the window title is not displayed in the good way. The only thing that we can respond to this bug is --enable-multibyte (which is now my default). And there are problems with the I18N_MB patch. What you would say if you have to use --enable-multibyte for the $ characters :o) We may add --enable-us? or --disable-8bits? :o) Really, I do not know what we should do. For 2.6.x we must improve the I18N_MB patch (and fix the utf8 problem), but for 2.4.x? YES. Definitely yes. Alexander had posted a screenshot with cyrillic titles from XTerm -- you can see that the result is hardly readable. The same happens with Netscape and almost all other apps -- they are correctly i18n'ed on Xlib layer. BTW, while just stripping 2022 tags wouldn't be a correct solution, it will work at least for koi8-r, iso8859-* and for other singlebyte charsets. The trick is that (at least in Russia) in case of locale with FOO-N charset the fonts which are default (i.e. used by fvwm, first dir in fontpath etc.) are *-FOO-N. And singlebyte encodings are represented in 2022 as-is (e.g. koi8-r text is escape for koi8-rthat text in koi8-r). So, we'll display FOO-N-encoded strings with FOO-N-font, which is right. Of course, visiting chinese or even polish websites when in russian locale will give funky titles, but that's what we had in old days. _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Regarding WindowShade again
Hi! A few days ago here was a discussion about Olivier's patches for smooth windowshading. I haven't tried CVS version yet, so, maybe this is about nothing. Everything below applies to 2.4.4. Anyway: when a window is shaded which overlaps other windows, borders of those windows aren't redrawn until the shading is complete. As I understand, this is because shading is done in a loop which doesn't do anything besides taking care of the window being shaded, right? And the second thing regarding 2.4.4: when I issue Style * WindowShadeSteps 100 command, it doesn't affect already mapped windows, only Recapture solves the problem. This wasn't the case in 2.4.0. _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Bug#98091: that's not good enough
On Wed, 9 Jan 2002, Dominik Vogt wrote: If I remember, one of the complaints about the server grab is that xmms stopped playing. That was the easiest-to-reproduce example I could think of. You might consider filing a bug report with the xmms folks. Not a bad idea... This is *definitely* an xmms bug. It is perfectly legal for any application to grab the X server at any time, although it should be released as fast as possible. Running tasks that work in real time in the same process/thread as X11 calls is simply stupid. If we'd fix that in fvwm there are thousands of other programs that can potentially cause similar problems. Just for a record: RealPlayer for Linux also has this bug. I've looked through the Preferences dialog, and it doesn't seem to have a play in separate thread flag, while the program runs as several processes. Probably just a bad coding. The version is 8.0.3.421, linux-2.0-libc6-i386-gcc2.95. I don't think that filing a bug report to Real would help anything. _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: CVS olicha: * Fixed transparent animated menu
Hi! Nice to hear that fvwm will have support for that fancy transparency feature. Just a few comments. On Sat, 5 Jan 2002, Dominik Vogt wrote: [SNIP] Unfortunately, it does not seems that there is a standard for this but some programs use the ESETROOT_PMAP_ID and the _XROOTPMAP_ID atoms. Anyway, ParentRelative doe not really give transparency for top level windows. You don't see what is behind the window, only the contents of the root window there. Of course, ParentRelative gives you not the contents of the parent window, but only its BackgroundPixmap with a correct offset. So, if there's something more than just a wallpaper on a root window (e.g. Windoze-style icons/shortcuts), they aren't copied. Of course, unless they are drawn on the same pixmap that is a BackgroundPixmap. [SNIP] In any case, a pixmap copy of the root window may be better than the ParentRelative pixmap under certain situation. Both approchaes have one big problem: X doesn't do the updates itself. When you move a 'transparent' window, X moves whatever background it has. You have to redraw the background yourself. This looks very unpleasant. The right way to do transparency in X is to use the Shape extension. But then, applications have to be specifically written to use it. You don't have to redraw the background yourself, all you have to do is call XClearArea(). The server will update the background itself and send you an ExposeEvent, upon receipt of which the app should only redraw all foreground elements. I.e., in no case should the app redraw the background -- if either the BackgroundPixmap or BackgroundPixel are specified, the server will do the dirty work itself. This feature significantly improves performance, especially if the server and the app are on different machines. The only exception is when BackgroundPixmap=None, but that means that app knows what it is doing. [SNIP] Also, remember that a copy of the screen can be very big:i 1600x1200 pixels with 32 bit planes = 7.5 MB. That's the reason why I did not go this way in the past. But what do you mean by double buffer. Keep a copy of the screen in a pixmap, draw into the pixmap, then copy the pixmap (or parts of it) onto the screen. There's an extension of double buffering: when the same pixmap is used as a BackgroundPixmap and as a shadow buffer. In that case one has to manually copy parts of that pixmap onto the screen only upon changes, and all the subsequent redraws are done by the server -- the app may completely ignore Expose events for such shadow-buffered windows. As to ParentRelative in general: I've tried to use it in Motif apps to make nice wallpapered dialog windows. This feature *is* useful, since you don't have to manually put/assign parent's background pixmap to all widgets (labels, checkboxes etc.). But a lot of work yet have to be done by the program, since the top/bottom shadows, focused widget rectangles etc. should be correctly generated taking the background into account. _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: [PATCH] kill menus with Ctrl-G (as in emacs)
On Sat, 5 Jan 2002, Tony Finch wrote: --- ./fvwm/menus.c.orig Sat Jan 5 04:19:21 2002 +++ ./fvwm/menus.cSat Jan 5 04:31:46 2002 @@ -1053,6 +1053,7 @@ case XK_Escape: case XK_Delete: case XK_KP_Separator: + case XK_g: /* emacs */ /* abort */ saction = SA_ABORT; break; In fact, this will have an effect of cancelling the menu by just g, no matter whether the Ctrl is pressed or not. Sure, there's no problem, since menu items' accelerators are checked first, so that menu item with g hotkey will still work. But description in the manpage is incorrect. _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Cursor colors (Was Re: CVS dane: * libs/Makefile.am (libfvwm_a_SOURCES): Add new file.)
On Tue, 9 Oct 2001, Dan Espen wrote: Fine, but it would be nice to add pointer fore/back colors too similarly to CursorStyle command. I myself do not use black on white pointers when possible. Yep, XEmacs is fun: Emacs*pointerBackground: red Emacs*spacePointer: sailboat Emacs*modeLinePointer: spider Emacs*selectionPointer: trek Maybe a bit offtopic, but I have a question: which colors people on this list prefer to use for pointers? When we began using 4 monitors on one PC, a problem of finding where the cursor is had appeared; the same problem was noted by people who use big resolutions (like 1600x1200). I did some research, and it resulted in fgcolor=red, bgcolor=white (BTW, that's a default in SGI's Motif). I even did a patch for XFree86 which allows to change default blackwhite colors and optionally doublesize the pointer. So, what colors do you prefer? _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: A small question regarding titles and borders
On Sun, 7 Oct 2001, Mikhael Goikhman wrote: On 07 Oct 2001 12:29:49 +0700, Dmitry Yu. Bolkhovityanov wrote: How to specify a shadow thickness for raised/sunk titles and borders? There's no shadow thickness flag in TitleStyle/BorderStyle commands, and there's no thickness attribute in colorsets. On the other hand, at least Kendrick Vargas' screenshot shows a sunk title with thickness of 1 instead of default 2. So, how? You can't, it is hardcoded to 2 when raised/sunk. I didn't see Kendrick's config, but it is clear to me that he uses flat, not sunk title, everything is pixmap based. I.e. it only works with TitleStyle Height 19 in his case. And what about http://fvwm-themes.sourceforge.net/windowdecors/decor-2[14].jpg ? Or these two are also flat with pixmap bg which work for specific height only? As for borders, the shadow/hilite colors depend on the border width and some more flags, also hardcoded. And it is not symmetrical at different sides. Borders are hardly configurable. Aha... So, these should go to a wish list together with offsettable buttons and an ability to specify separate thicknesses for left/right/up/down borders? _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
A small question regarding titles and borders
Hi! How to specify a shadow thickness for raised/sunk titles and borders? There's no shadow thickness flag in TitleStyle/BorderStyle commands, and there's no thickness attribute in colorsets. On the other hand, at least Kendrick Vargas' screenshot shows a sunk title with thickness of 1 instead of default 2. So, how? TIA, Dmitry _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Some Xinerama problems
On Fri, 28 Sep 2001, Olivier Chapuis wrote: Hello, I make some Xinerama test recently using Sls 1x2 on my poor 800x600 screen: --- | | | | 0 | 1 | | | | --- The support seems really great! (BTW, does there exits laptop with a double head video card?). Most modern laptops are dual-headed: first head is laptop's flat panel, the second is VGA output. While VGA typically duplicates the panel, at least those with ATI cards (e.g. Compaq Presario 1700 with ATI Rage Mobility M2) and with Permedia ones are able of displaying different pictures on these heads, and even with different resolutions. _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: SGI Xinerama API
On Wed, 26 Sep 2001, Stephane Rosa wrote: Hi, I'm preparing an SGI package of fvwm and I have a couple issues with your implementation of Xinerama. SGI is currently developing the Xinerama library as per the latest spec (Actually SGI is even beyond the spec for certain things) It sounds like you're using an old spec. A couple differences : Bool XineramaActive() replaces char XineramaIsActive() XineramaScreenInfo *XineramaQueryScreens(disp, count) along with the typedef struct are not in the spec anymore. An equivalent could be found by using XineramaGetScreenCount and XineramaGetScreenSize, but the very latest spec will show up a new function, XineramaGetData so... a couple questions: - how do we keep up on API spec changes (very often yet) All the Xinerama-API-related functionality is in libs/FScreen.c::FScreenInit(), and what it really needs is a) a function to check if Xinerama is present at all, b) a way to get a list of screen rectangles (viewports to global screen). Since all APIs (except old PanoramixNNN one) supply these, it is a matter of simple configure script logic plus a few #ifdef's in FScreen.c (like #if defined(XINERAMA_API_XFREE86) ... #elif defined(XINERAMA_API_XORG) ... #endif - is anybody following this very close ? I'm the person who tries to track Xinerama API flavors. - I'll patch 2.4.2 for SGI use. Want the spec ? Yes, the spec is very welcome. BTW, which spec is it? There are at least four APIs: 1) old PanoramixNNN; 2) XFree86's XineramaNNN (which is the only API currently in use by WMs and toolkits); 3) Xinerama project API (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xinerama/xinerama/xc/doc/XineramaApi.txt?rev=1.2content-type=text/vnd.viewcvs-markup); 4) X.org Xinerama task force product (which isn't published). Probably #3 and #4 are related, but I'm not sure. _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Java's AWT misbehaves
On Mon, 24 Sep 2001, Sidik Isani wrote: [SNIP] We run jdk-1.3.1. Windows pop up in the wrong places under FVWM1, but the sizes are correct. Under FVWM2, windows themselves, or sometimes the widgets within the windows, pop up as 0x0! Then when you try to resize the window, they flip back to the right size. Needless to say, this is pretty unusable for most people. I'm guessing Java is doing something non-standard, because FVWM2 has been working quite flawlessly with every other application. (Although, I did have a search string not found popup from netscape which also came up 0x0 size just once ... strange.) I've experimented with all of the *Transient options, BackingStore (which, by the way, causes the window to be blank most of the time!?), No/UsePPosition,No/UseTransientPPosition,No/UseUSPosition, No/UseTransientUSPosition, SkipMapping, etc. Nothing helps. Has anyone seen this before? Some kind of hack Style which we could apply to AWT* in our .fvwm2rc's as a work-around could be useful. Reportedly, CDE, KDE, and Enlightenment now work (but Sun supposedly put a special hack into Java just for Enlightenment). FVWM1 also kind of worked. Do they do anything fundamentally differently from FVWM2? I've experienced different (but probably closely related) problem with Java. That was jdk-1.1.5 (yes, I know it is very old) and Miralilis' ICQJava (yes, I know that it is totally a bugware). When using fvwm-2.4, all ICQ popup windows (e.g. user info, messages etc.) flash for a moment and disappear. If the same is done under TWM (which uses ManualPlacement), each window appears *twice* -- first in some random place (under the mouse?), and than in exactly the same place. Fvwm-2.2.4 didn't have this problem, so this supposedly can (should?) be fixed, but I don't have a precise idea about why it works as it works. Can somebody please make comments on it (in fact, general notes regarding Java + WM, or some pointers to such info) will be very interesting. _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM2 Xinerama patches
On Sun, 23 Sep 2001, Sidik Isani wrote: Hello - I have a suggestion for Xinerama, but I don't know enough about automake to provide a patch: we could use configure options telling fvwm2 where to look for the library and include files. Also related to Xinerama, here are better versions of some patches I posted before (now everything properly goes through the FScreen layer to calculate Xinerama screen coordinates.) We're upgrading from isolated multi-head displays to Xinerama, and with the following patches, we were able to keep the same geometry resources we use on separate DISPLAY's (:0.0, :0.1, :0.2, :0.N) and translate them to '*wmscreen: N' resources. FVWM2 looks very stable so far on our Linux/Solaris/HP-UX mix. Thanks a lot to all who worked on this. XINERAMA PATCH 1: Adds a new function to FScreen to convert global coords. XINERAMA PATCH 2: Adds a check for a *wmscreen resource. XINERAMA PATCH 3: Uses function in PATCH 1 to make USPosition windows obey StartsOnScreen Style/*wmscreen resource. XINERAMA PATCH 4: Uses PATCH 1 to cause window positions displayed while moving a window to be screen-relative whenever possible. I might not be good to put any of this in the 2.4.3 release, but I hope it is useful to someone. #4 probably needs a config file option associated with it to turn it on/off. Adding @N to the string it displays would make it nicer too. Please let me know if there's anything else needed to make these patches generally useful. Just two notes. First, isn't FScreenGetScreenXY() just a FScreenGetScrRect(arg, FSCREEN_XYPOS, dst_x, dst_y, NULL, NULL) (well, a separate call may be more handy, but Dominik has removed most of FScreenGetZZZScrRect() in favour of FScreenGetScrRect, an that looks reasonable)? Second, regarding translation of program-supplied geometry to non-global screen: what will happen to those programs which save their windows' geometries on exit and use them on restart? Wouldn't the following happen: app is started on current screen +---+---+---+ 1024*3 | 0 | 1 | 2 | +---+---+---+ (which is #1, +1024+0), it saves window position (e.g. +1030+10), and on next run (current screen is still #1) supplies it to fvwm, which translates to +(1030+1024)+10, so that the window effectively goes to screen #2? Patch #3 doesn't include %'ing the coords, which was present in previous version (yet not sure if that did the right thing). Of course, a good program should specify PPosition in this case, not USPosition, but a) I haven't tested what such apps supply (and those (mainly commercial or binary-only) progs are known to be bogus in many aspects); b) do patch #3 belongs to PPosition branch only? Hope this is a false alarm, but I think it is worth mentioning. (An obvious question is why specifying StartsOnScreen for such programs?, but this feature is so handy that there's a desire to use Style * StartsOnScreen c). _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Several things
On Sun, 16 Sep 2001, Dominik Vogt wrote: On Sat, Sep 15, 2001 at 08:42:21PM +0700, Dmitry Yu. Bolkhovityanov wrote: On Thu, 13 Sep 2001, Dominik Vogt wrote: On Thu, Sep 13, 2001 at 03:29:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: 2. Somewhere after 2.2.4, the decoration code was changed so that borders became wider. This had several visible effects, all of which are IMHO negative: a) windows occupy more space (with 2.2.4 on 1152x864 screen xterm with lucidatypewriter-12 font could be tall-maximized to occupy exactly full screen with 64 lines, and xterm with lucidatypewriter-10 could be wide-maximized to use exactly full screen width; now there are unused gaps); The size of the decorations *didn't* change internally in fvwm. If things don't fit nicely anymore then either the font in your xterms has changed or fvwm's title font (TitleFont foo) or the width of the window borders (HandleWidth and BorderWidth styles). No. See below and screenshot. Nope, window borders have always been 7 pixels wide, and they are too in 2.2.x. I don't know where this setting is coming from, but it's definitely not the default. You can verify that by running fvwm without a config file b) hilited parts of titlebar buttons stick -- see topmost scanline of buttons ##0,8. I'm not sure what you mean. Can you perhaps just provide a screenshot? A screenshot is attached. The left window is fvwm-2.2.4 (RedHat 6.2), the right is fvwm-cvs-2001-Sep-10 (compiled and run on RedHat 7.1). Both xterms were run from the same host and on the same X server, with a command xterm -fn lucidasanstypewriter-12 -geom 20x5, fvwm configuration is the same AnotherLevel-1.0.1-1 from RedHat-6.2. There are several things to notice: - 2.4 makes an additional dark border around the window, hence the window is 2px wider and 1px taller. See my comment above. With an empty config file, borders look the same in 2.4 and 2.2.5. [SNIP] - On the upper [right resize corner]=[vertical part]=[hilite right vertical line] runs 1px higher than it should. This reminds a bug I reported on spring... I see it on your screenshot, but I don't see it here. Could you provide all your border/title/button related config lines, please? Two screenshots are attached, null224.gif is fvwm-2.2.4 (from ftp.fvwm.org), null24.gif is fvwm-cvs-2001-Sep-10 (cvs checkout, not ftp snapshot). Both were made with ./configure --prefix=dir; make; make install, with no other options specified. Both were run with dir/bin/fvwm2 -f /dev/null. While both of these screenshots are 1px less tall than their yesterday's AnotherLevel-based analogs (due to lack of buttons?), the picture is the same -- 2.4 is 2px wider and 1px taller than 2.2.4. However, I didn't check 2.2.5 yet (in fact, I never used it). The extra hilited pixel is also there. System information: viper:~% uname -mrsp Linux 2.4.2-2 i686 unknown viper:~% cat /etc/redhat-release Red Hat Linux release 7.1 (Seawolf) viper:~% rpm -q glibc glibc-2.2.2-10 viper:~% rpm -q XFree86-devel XFree86-devel-4.0.3-5 (almost a stock RedHat 7.1). _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics null224.gif Description: GIF image null24.gif Description: GIF image
FYI: Official Xinerama API spec
Hi! As was mentioned some time ago, Xinerama API implementation in XFree86 isn't an official X.org standard. And X environments other than XFree86 use different (and incomplete, and undisclosed) Panoramix API. A draft of upcoming standard API is available at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xinerama/xinerama/xc/doc/XineramaApi.txt?rev=1.2content-type=text/vnd.viewcvs-markup Differences from XFree86's implementation are very subtle and can be easily handled within FScreen.c with a little assistance from configure script. Additionally, Mark Vojkovich states at http://www.xfree86.org/pipermail/xpert/2001-September/011340.html that XFree86 will support both when the X.Org protocol is finalized. BTW, I'm going to contact him regarding our findings (like a desire to have a Pointer changed physical screen event). Are there any other similar things which will require assistance from X server and API? _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Several things
On Thu, 13 Sep 2001, Dominik Vogt wrote: On Thu, Sep 13, 2001 at 03:29:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: Hi! First, a pair of questions regarding window decorations. 1. Is it possible to make titlebar buttons appear not side by side to each other and to borders, but at some offset? So that it would be possible to make a setup similar to OpenWindows (where the window ops button is at some distance from the left) and to MacOS/Aqua-alikes (where buttons are disjoint)? Its not possible with vector buttons but can be done with pixmap buttons. The following lines come from the system.fvwm2rc-sample-95: ButtonStyle 1 MiniIcon (-- flat) ButtonStyle all -- UseTitleStyle Flat AddButtonStyle 2 Pixmap mini.winXX-close.xpm AddButtonStyle 4 Pixmap mini.winXX-maximize.xpm AddButtonStyle 6 Pixmap mini.winXX-minimize.xpm Just give the pixmaps a transparent border in the dimensions you like. Unfortunatey you'll have to draw a separate pixmap for each button state if you need depressed and toggled looks. Yes, that's a known solution, but it has at least three disadvantages. First, as you stated, one has to draw pixmaps for each state. Second, such buttons aren't scalable (as vector buttons are), so they wouldn't follow the title font size. Third, such buttons wouldn't really be offset -- there will be invisible areas, which still can be clicked on, and this is confusing (a similar bug/feature exists in WinAmp/XMMS, where skin elements are separated from actual mouse handling code, and it is IMHO very irritating). Can an offset feature be treated as a TODO item? It doesn't seem hard to implement. 2. Somewhere after 2.2.4, the decoration code was changed so that borders became wider. This had several visible effects, all of which are IMHO negative: a) windows occupy more space (with 2.2.4 on 1152x864 screen xterm with lucidatypewriter-12 font could be tall-maximized to occupy exactly full screen with 64 lines, and xterm with lucidatypewriter-10 could be wide-maximized to use exactly full screen width; now there are unused gaps); The size of the decorations *didn't* change internally in fvwm. If things don't fit nicely anymore then either the font in your xterms has changed or fvwm's title font (TitleFont foo) or the width of the window borders (HandleWidth and BorderWidth styles). No. See below and screenshot. b) hilited parts of titlebar buttons stick -- see topmost scanline of buttons ##0,8. I'm not sure what you mean. Can you perhaps just provide a screenshot? A screenshot is attached. The left window is fvwm-2.2.4 (RedHat 6.2), the right is fvwm-cvs-2001-Sep-10 (compiled and run on RedHat 7.1). Both xterms were run from the same host and on the same X server, with a command xterm -fn lucidasanstypewriter-12 -geom 20x5, fvwm configuration is the same AnotherLevel-1.0.1-1 from RedHat-6.2. There are several things to notice: - 2.4 makes an additional dark border around the window, hence the window is 2px wider and 1px taller. - 2.4 title is less tall, but percents in vector buttons are somehow larger (the shapes are thicker); but that indifferent -- both cases are OK. - 2.4's titlebar buttons stick to each other (the topmost bright line runs from leftmost button to rightmost one uninterrupted), while in 2.2.4 buttons are separated. - On the upper [right resize corner]=[vertical part]=[hilite right vertical line] runs 1px higher than it should. This reminds a bug I reported on spring... BTW, about two months ago I ran than-current fvwm on a clockwise-rotated screen under Xvesa (RandR-enabled KDrive server). Xvesa is very slow in this mode, and I noticed that some pixels (those on the border between hilited and darkened parts) of the frame are redrawn several times. _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics fvwm_decors.gif Description: GIF image
Patch for fvwm modules man pages
Hi! Attached is a patch which a) adds a formal description of how fvwm maintains module's configs; b) corrects man pages for individual modules. Changelog entry: * Add a formal description of how fvwm maintains module's configs * Change manpages of individual modules to refer to fvwm2(1) for details about specifying configuration Previously many man pages contained a sentense like During initialization FvwmFoo reads the same config file as fvwm. The replacement template is On startup | During initialization | /*optional*/ \fBFvwmFoo\fP gets config info from \fBfvwm\fP's module configuration database (see .IR fvwm2 (1), section .BR MODULE COMMANDS ). Additionally, some manpages (e.g. FvwmScroll) included two references to config file: first in DESCRIPTION and than in INITIALIZATION. In such cases the one in DESCRIPTION is removed, since it is redundant. BTW1: I changed only those manpages which included those wrong sentences, but it is probably worth modifying other manpages too. BTW2: FvwmSave manpage wasn't changed, since it is completely broken: most text in it refers to NoClutter (?!?!?!). _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics Index: fvwm/fvwm2.1 === RCS file: /home/cvs/fvwm/fvwm/fvwm/fvwm2.1,v retrieving revision 1.400 diff -u -r1.400 fvwm2.1 --- fvwm/fvwm2.12001/09/05 16:39:56 1.400 +++ fvwm/fvwm2.12001/09/15 14:15:39 @@ -7179,6 +7179,28 @@ .SS MODULE COMMANDS +Fvwm maintains a database of module configuration lines in a form +.EX +.BI * ModuleName : Config-Resource +.EE +where +.I ModuleName +is either a real module name or an alias. + +This database is initially filled from config file (or from +output of +.B \-cmd +config command), and can be later modified either by user (via +.BR FvwmCommand ) +or by modules. + +When modules are run, they read appropriate portion of database. +(The concept of this database is similar to one used in X resource +database). + +Commands for manipulating module configuration database are +described below. + .TP .BI * module_config_line Defines a module configuration. Index: modules/FvwmAnimate/FvwmAnimate.1 === RCS file: /home/cvs/fvwm/fvwm/modules/FvwmAnimate/FvwmAnimate.1,v retrieving revision 1.13 diff -u -r1.13 FvwmAnimate.1 --- modules/FvwmAnimate/FvwmAnimate.1 2001/07/03 07:23:04 1.13 +++ modules/FvwmAnimate/FvwmAnimate.1 2001/09/15 14:15:48 @@ -51,8 +51,11 @@ the \fBFvwmAnimate\fP module, you don't really have to know what any of the configuration commands are. This section describes them anyway. -\fBFvwmAnimate\fP reads the same \fI.fvwm2rc\fP file as \fBfvwm\fP -reads when it starts up. +\fBFvwmAnimate\fP gets config info from \fBfvwm\fP's module configuration +database (see +.IR fvwm2 (1), +section +.BR MODULE COMMANDS ). In addition, \fBFvwmAnimate\fP reads the file $HOME/.FvwmAnimate, and accepts commands from fvwm and its modules as it runs. Index: modules/FvwmBacker/FvwmBacker.1 === RCS file: /home/cvs/fvwm/fvwm/modules/FvwmBacker/FvwmBacker.1,v retrieving revision 1.9 diff -u -r1.9 FvwmBacker.1 --- modules/FvwmBacker/FvwmBacker.1 2001/08/25 14:45:19 1.9 +++ modules/FvwmBacker/FvwmBacker.1 2001/09/15 14:15:49 @@ -24,9 +24,12 @@ for any purpose as long as the copyright is kept intact. .SH INITIALIZATION -During initialization, \fIFvwmBacker\fP will scan the same -configuration file that FVWM used during startup to find the options -that pertain to it. These options are discussed in a later section. +During initialization, \fIFvwmBacker\fP gets config info from +\fBfvwm\fP's module configuration database (see +.IR fvwm2 (1), +section +.BR MODULE COMMANDS ). +Available options are discussed in a later section. .SH INVOCATION FvwmBacker can be invoked by fvwm during initialization by inserting Index: modules/FvwmDragWell/FvwmDragWell.1 === RCS file: /home/cvs/fvwm/fvwm/modules/FvwmDragWell/FvwmDragWell.1,v retrieving revision 1.6 diff -u -r1.6 FvwmDragWell.1 --- modules/FvwmDragWell/FvwmDragWell.1 2001/08/02 23:06:18 1.6 +++ modules/FvwmDragWell/FvwmDragWell.1 2001/09/15 14:15:51 @@ -15,9 +15,12 @@ drops of type text/uri-list. .SH INITIALIZATION -During initialization, \fIFvwmDragWell\fP will search a configuration -file which is the same file that fvwm used during initialization. If -the FvwmDragWell executable is linked to another name, i.e. ln -s +During initialization, \fIFvwmDragWell\fP gets config info from +\fBfvwm\fP's module configuration database (see +.IR fvwm2 (1), +section +.BR MODULE COMMANDS ). +If the FvwmDragWell
Several things
Hi! First, a pair of questions regarding window decorations. 1. Is it possible to make titlebar buttons appear not side by side to each other and to borders, but at some offset? So that it would be possible to make a setup similar to OpenWindows (where the window ops button is at some distance from the left) and to MacOS/Aqua-alikes (where buttons are disjoint)? 2. Somewhere after 2.2.4, the decoration code was changed so that borders became wider. This had several visible effects, all of which are IMHO negative: a) windows occupy more space (with 2.2.4 on 1152x864 screen xterm with lucidatypewriter-12 font could be tall-maximized to occupy exactly full screen with 64 lines, and xterm with lucidatypewriter-10 could be wide-maximized to use exactly full screen width; now there are unused gaps); b) hilited parts of titlebar buttons stick -- see topmost scanline of buttons ##0,8. (heh, I just liked previous version more ;). The question is -- can this be fixed, or, can somebody please point me to appropriate place in list archives where this change is discussed? Second, Dominik, can bug #732 have a simple fix -- since this effect isn't so fatal with non-animated shading, maybe add something like if (border_width == 0 has_no_title) steps = 1 to CMD_WindowShade()? Third, I've filed a bug report to RedHat, stating that they still package an old version, and response was that it is too late for next release, but they'll update in RawHide (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=53030). _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Regarding fvwm and modules man files
Hi! First, some time ago here was expressed a strong intent to split fvwm2.1 into fvwm2.1 (giving a description of fvwm and its commandline options) and fvwm2rc.1 (listing all config-file options). Is this still going to be done? Second, regarding modules' configurations... Fvwm maintains a database of *ModuleName... lines (a-la X resource database) and gives them to modules via GetConfigLine(), right? But several man pages in modules/ still include statements like On startup FvwmFoo reads the same .fvwm2rc config file as fvwm, which are technically wrong. It seems worth changing all such things into a unified reference to some part of fvwm2rc(5) (MODULE COMMANDS?). Here is a list of such incorrect man pages (to the right are patterns used for grepping): FvwmAnimate.1 reads the same FvwmBacker.1scan the same FvwmDragWell.1 same file that fvwm used during initialization FvwmEvent.1 reads the same FvwmGtk.1 reads the same FvwmIconBox.1 reads the same FvwmIdent.1 reads the same FvwmPager.1 same file that fvwm used during initialization FvwmSave.1 same file that fvwm used during initialization FvwmScript.1??? FvwmScroll.1same file that fvwm used during initialization FvwmWharf.1 configuration file will be the FvwmWinList.1 the same configuration file I can do appropriate modifications, but I'm not so sure in my english, so hope this list is of some help. BTW, there's a statement in fvwm2.1::ANATOMY OF A WINDOW: The default configuration has a title-bar button on each side of the title-bar. ... That's not true: fvwm2 -f /dev/null gives *no* titlebar buttons. _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Q about fvwm relations with RedHat
Hi! I've noticed that RedHat, both 7.2beta (Roswell (UFO?:)) and RawHide still contain 2.2.5. So, they probably should be pushed to move to 2.4. The question is: are there any existing contacts between fvwm team and RedHat? If not, I can mail [EMAIL PROTECTED] (listed as last person who touched the .spec file), or maybe somebody else, having more experience in this area, is willing to do it? _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: One more Xinerama patch for FvwmWharf
On Thu, 23 Aug 2001, Dominik Vogt wrote: On Sat, Aug 18, 2001 at 08:28:54PM +0700, Dmitry Yu. Bolkhovityanov wrote: Hi! This patch deals with withdrawing Wharf to corners and with in which direction panels should open. Appliet. BTW, could you please include ChangeLog entries with your patches? Ok. For this one it is Make FvwmWharf use current Xinerama screen for choosing in which direction to slide panels and for withdrawn position calculation (khm, a bit too long, shame on me...). BTW, there's a strange error in drawing the panel's host button. When a vertical Wharf is at the right border (and a panel slides to the left), after a panel completely appears, the host button is in two halves: the right half is pressed, while the left one is depressed. Can you post a config to demonstrate this? Well, that's just AnotherLevel. I append all *FvwmWharf lines in m4-preprocessed form at the end of this mail (long lines are marked with \s). Presence of this effect depends on X server, but I can 100% reproduce it in Xnest ran on Matrox G450 under XFree86 4.0.3 (RH7.1, AnotherLevel). Interestingly, on the host server itself the effect seems to be 100% unreproducible. I can post a screenshot of this effect if required. You're using XNest? Usually I don't debug problems with XNest which seems to have a lot of bugs. Did you ever see this with a real X server? Yes. It is the same problem which was 100% reproducible with 2.3.28 under XFree86 3.3.2 with Matrox Millenium II (that was my previous machine). And it is still reproducible under XFree86 4.0.3 on our 4-monitor PC (Matrox G450DualHead + 2 x Millenium II), the same problem on any head. That machine has RedHat 6.2 (kernel 2.2.16) with glibc-2.1.3. U... Actually, I ran fvwm over a 100Mbit Ethernet from another machine, and my oldie was P166MMX; so, maybe there's some timing problem? CUT HERE Style FvwmWharf StaysOnTop,Sticky, WindowListSkip,CirculateSkip, \ ClickToFocus, NoTitle,NoHandles,BorderWidth 0 *FvwmWharfAnimate *FvwmWharfAnimateMain *FvwmWharfGeometry -0+0 *FvwmWharfColumns 1 *FvwmWharfTextureType 255 *FvwmWharfBgColor gray51 *FvwmWharf AfterStep AfterStep.xpm Folder *FvwmWharf Shutdown ShutDown.xpm Quit *FvwmWharf xlock KeysOnChain.xpm FvwmForm XLock *FvwmWharf ~Folder *FvwmWharf xclock nil Swallow xclock xclock -bg #8e8a9e -fg \ #3f -geometry 45x45-1-1 -padding 0 *FvwmWharf xbiff nil Swallow xbiff xbiff -bg #8e8a9e -fg \ #3f -geometry 45x45-1-1 *FvwmWharf xload nil Swallow xload xload -nolabel -hl black -bg \ #8e8a9e -geometry 48x48-1-1 *FvwmWharf xload nil Exec xterm -ut -T top -e top *FvwmWharf Pager nil Swallow FvwmPager Module FvwmPager 0 0 *FvwmWharf xterm monitor-check.xpm Exec xterm -bg black -geometry \ 80x25 -sl 500 -sb -ls -T 'xterm: [EMAIL PROTECTED]' *FvwmWharf emacs text.xpm Exec emacs *FvwmWharf gimp 3dpaint.xpm Exec gimp *FvwmWharf pine writeletter.xpm Exec xterm -T pine -e pine *FvwmWharf Netscape netscape3.xpm Exec netscape *FvwmWharf Recycler recycler.xpm Restart fvwm2 CUT HERE _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: CVS domivogt: * Applied Xinerama patch for Maximize command but changed syntax to
On Sun, 19 Aug 2001, FVWM CVS wrote: Log message: * Applied Xinerama patch for Maximize command but changed syntax to Maximize Screen screen-spec. fvwm.org seems to be offline, so the question: would it be possible to maximize on the same screen where the window currently is? I.e., if the window is completely on screen 2, and I'm issuing Next (WINNAME) Maximize from FvwmCommand on screen 3 (i.e. c==3), the window gets geometry [EMAIL PROTECTED] _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Problems with maillist?
Hi! On 18-Aug I've submitted a patch for Wharf which haven't popped in the list. Our mail server's /var/log/maillog shows that for msgid=[EMAIL PROTECTED] relay=karazm.math.uh.edu, Message accepted for delivery, but... Maybe I should resend the message? _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama support for IconBox style?
On Mon, 20 Aug 2001, Dan Espen wrote: Dominik Vogt fvwm-workers@fvwm.org writes: Currently, fvwm uses the icon boxes in the order of creation. So, if one icon box is created on screen 0 and one is created on screen 1, all icons are placed on screen 0 until the icon box is full, then all icons are put on screen 1. My question was if it is necessary to skip icon boxes that are not on the same screen as the window. I don't think we'd want to apply the same screen test unless the user indicated that the iconbox was for a specific screen. Right now, theres no way to do that. Would it be possible to remember the screen# together with translated geometry? I don't think that just because the iconbox lies completely within a screen is sufficient reason to only use it for one screen. Since I don't have a setup, I can only guess, but my guess is that we don't need a iconbox for each screen feature. Well, maybe not iconbox for each screen, but iconify on the same screen. It seems most natural that windows iconify on the same screen where they are. A possible way to achieve this behaviour is to define a floating iconbox: i.e. IconBox -80x200-1-1 will create an iconbox which will be treated as @w (w is window's current screen). Not sure about implementation details, though -- I'm speaking of this mainly as a user of several multiheaded machines. BTW, there's a little problem with specifying iconboxes separately for each screen: this is okay for a static configuration, but what about an XDM server which works for several different-headed machines? So there's a need in a single command to bind iconboxes to all screens. I have yet to test the latest CVS, so sorry if everything is already done. _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
One more Xinerama patch for FvwmWharf
Hi! This patch deals with withdrawing Wharf to corners and with in which direction panels should open. BTW, there's a strange error in drawing the panel's host button. When a vertical Wharf is at the right border (and a panel slides to the left), after a panel completely appears, the host button is in two halves: the right half is pressed, while the left one is depressed. Presence of this effect depends on X server, but I can 100% reproduce it in Xnest ran on Matrox G450 under XFree86 4.0.3 (RH7.1, AnotherLevel). Interestingly, on the host server itself the effect seems to be 100% unreproducible. I can post a screenshot of this effect if required. BTW2: wouldn't it be wise to add an item 15.5.5.5 to todo-3.0, stating Remove FvwmWharf (It's an FvwmButtons with trivial enhancements)? _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics wharf.diff.gz Description: Binary data
Re: Xinerama patch for Maximize
On Fri, 17 Aug 2001, Dominik Vogt wrote: On Fri, Aug 17, 2001 at 11:46:45AM +0700, Dmitry Yu. Bolkhovityanov wrote: On Thu, 16 Aug 2001, Dominik Vogt wrote: On Wed, Aug 15, 2001 at 08:30:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: I've added an optional global switch, which means that maximization should be made on a global screen, otherwise it is made on the screen where the center of a window is. grow* are also adjusted (that turned to be the easiest part of the task). I have been thinking about an entirely different approach that uses XGeometry specs: Maximize on [EMAIL PROTECTED] The problem here is to specify the resize unit (screen % or pixels) and where to place the grow option. The same syntax could be used for the Move, Resize and ResizeMove commands. IMHO these two approaches aren't contradictory That's true, but I don't think we would want to develop a second syntax. My idea was to support maximizing/moving/resizing only with the new, X geometry like syntax and phase out the old one. Okay, but there are two issues. First, while the geometry syntax is mathematically okay, it is just too complicated (messy?) for an ordinary user -- like a Perl program for a person which knows only Pascal. I don't want to say that users are silly, but 640pxgrow-5+0p is a bit too much. BTW, this syntax employs latin letters for three different uses: 1) unit size (p); 2) keywords (grow); 3) times/multiplication operator (x); and all these go without any separators. While this is definitely parseable, it isn't very fancy and is too error-prone. Anyway, can you please post a formal definition of new syntax, like a BNF? Sorry for only criticizing, but I yet have to find out some reasonable suggestions. Second, due to compatibility reasons, the old syntax should still be supported. Otherwise most users of =2.4 (especially those with 1 monitor) will live with old versions, and in some cases even fvwmNN_convert wouldn't be able to help them (think about AnotherLevel and alikes). _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama patch for Maximize
On Thu, 16 Aug 2001, Dominik Vogt wrote: On Wed, Aug 15, 2001 at 08:30:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: I've added an optional global switch, which means that maximization should be made on a global screen, otherwise it is made on the screen where the center of a window is. grow* are also adjusted (that turned to be the easiest part of the task). I have been thinking about an entirely different approach that uses XGeometry specs: Maximize on [EMAIL PROTECTED] The problem here is to specify the resize unit (screen % or pixels) and where to place the grow option. The same syntax could be used for the Move, Resize and ResizeMove commands. IMHO these two approaches aren't contradictory -- yours allows more flexibility, while the logic im my patch is required in case when no parameters are specified (i.e. just Maximize) or the old syntax is used (incl. e.g. grow). But, of course, with some efforts old syntax parser can be changed to generate an appropriate on geometry spec. There's a pitfall in geometry syntax for Maximize: what would mean Maximize [EMAIL PROTECTED] if applied to a window on different page/desk? Would it be current screen where the *pointer* is, or the screen, where that *window* is (more precisely, where it *would* be when Focus applied)? And what to do in case when current page doesn't start on a page boundary? _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Xinerama patch for Maximize
Hi! This patch touches solely the move_resize.c. I've tried to modify fvwm2.1, but my roff skills seem to be below what required to keep Maximize description in the same style (the latter seems a bit wrong BTW -- too many spaces). I've added an optional global switch, which means that maximization should be made on a global screen, otherwise it is made on the screen where the center of a window is. grow* are also adjusted (that turned to be the easiest part of the task). There are some problems with maximizing windows that aren't on the current page when the page itself doesn't start on a page boundary, but that effect existed before anyway. And there is a comment maximize on visible page after IsRectangleOnThisPage() check, which doesn't seem to be correct -- somehow it happens that windows are maximized on visible page even if they are by some part (not entirely) on it. BTW, Dominik, was it done intentionally that in Xinerama emulation mode the vertical separator doesn't separate, but in fact overlaps two left pixels of the second pseudo-screen? The result seems a bit confusing ;-) _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics maximize.diff.gz Description: Binary data
Re: a naive Xinerama question
On Thu, 9 Aug 2001, Olivier Chapuis wrote: Well, Some users may want to have an application which is always on the current screen. Typically, if I get a double head I would like to have my FvwmPager and my WLM (TaskBar, WinList, IconMan or IconBox) always in the current screen. The solution is to run two such modules (it is the reason I added aliases support in TaskBar, WinList and IconBox recently). But a solution which seems better is that the application follows the pointer. Moreover, for some applications, running as many sticky copies of an application than screens will be not a solution to get it always on the current screen: for example with an xterm we lost the historic. So I think that an EnterScreenNotify event will be a good thing for a window manager: it will be able to manage a new/strong sticky mode for any applications. Well, that sounds very reasonable (now I understand my mistake -- I was thinking about something similar to FvwmBacker, but for Xinerama screens, which is a nonsense ;-). We have an option to add such functionality right now, but with fvwm tracking screens itself (this is needed anyway for emulated Xinerama), and later check for real EnterScreenNotify availability in configure script. IMHO currently the best way to go is collecting various reasons for such an event, and later discuss it with X people. Looking at Xserver and libXinerama sources, I can easily work out a patch for this thingie (the server internally has a ChangeScreen event, since it has to move cursor between screens). _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: A naive Xinerama question
On Tue, 7 Aug 2001, Olivier Chapuis wrote: Hello, I have a very naive Xinerama question: Is it possible to send to modules a M_NEW_SCREEN message when the mouse pointer change of screen? Technicaly it isn't possible -- X server wouldn't generate EnterScreenNotify events, since Xinerama screens look like a single large screen. If this behaviour is really needed, fvwm itself should always check if XineramaScreen(curx,cury)!=XineramaScreen(oldx,oldy), which can be time consuming. And there's another pitfall -- screens may overlap, so that screen where the pointer on concept becomes somewhat dubious (but that's a pathological case, and we use this concept anyway for determining a rectangle to clip menus etc. to). BTW, Olivier, can you please tell where this behaviour can be useful? I tried to imagine such situations with no results, but something tells me they *must* exist. _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: a naive Xinerama question
On Wed, 8 Aug 2001, Matthias Clasen wrote: On Tue, 7 Aug 2001, Olivier Chapuis wrote: Hello, I have a very naive Xinerama question: Is it possible to send to modules a M_NEW_SCREEN message when the mouse pointer change of screen? Technicaly it isn't possible -- X server wouldn't generate EnterScreenNotify events, since Xinerama screens look like a single large screen. But it would certainly be a useful addition to the Xinerama extension to send EnterXineramaHead and LeaveXineramaHead events - IIRC X extensions can introduce new events. If these events contain the a head number, interested applications can then easily maintain information about the set of heads the pointer is in (even for the pathological case of overlapping heads). Well, this *can* be a useful addition if we find a real case when it is needed. Than we can try to persuade Mark Vojkovich to add this functionality to X (BTW, what is interesting -- he also uses fvwm). But there must be some real, hard arguments, otherwise this definitely wouldn't pass the X Xinerama group. _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Patch for possible if-else syntax
Hi!
I've made a patch which implements a simple if-else syntax.
A new Otherwise command is introduced (wouldn't clash with possible
future syntax enhancements, right?), which executes supplied command only if
previous command was unsuccessful. So the syntax is:
AddToFunc Do-this-or-that
+ I Next (SomeProggie) Close
+ I Otherwise SomeProggie
(this implements Dominik's example of if some window exists, kill it,
otherwise start it).
Each command may return a True/False value, which defaults to True.
This logic is implemented in execute_complex_function(), which sets the
current return value to True before calling a command. There's no change
in command calling conventions, since return value of this command and
return value of previous command are global variables (sic!). Changed are
only conditional commands, which set return value to False when
unsuccessful. I also investigated if it would be possible to place these
two vars into exec_func_args_type, but those structs aren't passed between
*execute*function().
Since return values are stored in global vars,
execute_complex_function() saves previous state and restores it on exit.
Unfortunately, it contained a number of returns, which had to be replaced
with goto END_OF_FUNCTION (I wish C had Ada/Perl break from a block
feature...).
Of course, calling Otherwise outside a complex function is senseless.
Man page modification isn't included.
___
Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA
phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics
| Lab. 5-13This message contains a file prepared for transmission using the
MIME BASE64 transfer encoding scheme. If you are using Pegasus
Mail or another MIME-compliant system, you should be able to extract
it from within your mailer. If you cannot, please ask your system
administrator for help.
File information ---
File: OTHERW.DIF
Date: 7 Aug 2001, 23:04
Size: 7906 bytes.
Type: Binary
OTHERW.DIF
Description: Binary data
Re: Pegasus Mail
Ok, folks, I know that I have to do something to this thing. I'm using PMail mainly because all my correspondence since 1995 is kept there, plus Novell is the most supported service in our institute. And yes, it doesn't support In-reply-to even in the Windows version (at least our Novell guru and PMail translator S.Dubrov says so). And I'm stuck with Dos version anyway (because of DosEmu ;-). Well, thanks for all suggestions, and again sorry for breaking this thread too ;-). BTW, what's with *.fvwm.org? www is inaccessible, as well as cvs... ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
A pair of questions regarding FVWM setup
Hi!
First, is it possible to do a Windows-3.1-like windows and menus? The
problem with borders is that in case of BorderStyle -- flat handles are
invisible even without HiddenHandles. The accompanying problem with menus
is that there's only BorderWidth flag, without an ability to switch
3D-ness off (with Nops too). Both seems to be caused by lack of
BorderColor concept. Am I missing something?
Second, is it possible to create an if-then-else construct in a
function? I tried to emulate the behaviour of Win9x's TaskBar, which can be
described as:
if (Iconic || !Raised)
{
Iconify Off
Raise
Focus
}
else
{
Iconify On
}
(i.e. deiconify if iconified, otherwise raise of not raised, otherwise
iconify).
But this can't be done with a syntax of if-then; if-then, since the
following happens:
AddToFunc Deiconify-Raise-Focus
+ I Iconify Off
+ I Raise
+ I Focus
AddToFunc Deiconify-or-Raise-or-Iconify
+ I Current (Iconic) Deiconify-Raise-Focus
+ I Current (!Raised) Raise
+ I Current (Raised, !Iconic) Iconify On
but by the time the last line is reached, the window will *always* be raised
and deiconified. Is this fixable somehow?
TIA,
Dmitry
___
Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA
phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics
| Lab. 5-13
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: What to do for next release?
BTW, would it be possible to make --enable-multibyte a default in 2.4.1? As I understand, most of the people are lucky with 8859-1, but that's not the case for us, koi8-r'ers. In most of the modern apps (Netscape is most popular) russian titles are displayed as raw 2022 strings, i.e. the titles are interweaved with koi8-r strings and 2022 escapes. (Sure, my students now better understand how i18n works in X, but I'd prefer them to use their time for other work.) Is there something critical and untested in multibyte code? ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: A pair of questions regarding FVWM setup
On 4 Aug 01 at 11:35, [EMAIL PROTECTED] wrote:
On 04 Aug 2001 16:15:37 +0700, Dmitry Yu. Bolkhovityanov wrote:
First, is it possible to do a Windows-3.1-like windows and menus? The
problem with borders is that in case of BorderStyle -- flat handles are
invisible even without HiddenHandles. The accompanying problem with menus
is that there's only BorderWidth flag, without an ability to switch
3D-ness off (with Nops too). Both seems to be caused by lack of
BorderColor concept. Am I missing something?
Windows have BorderColor concept. Style * [Hilight]BorderColorset.
Menus have BorderColor concept (kind of) using MenuStyle MenuColorset
and ActiveColorset; you may specify sh and hi colors in these colorsets.
I don't remember how should look windows-3.1 windows and menus, so I can't
say whether something is missing to fully or partially emulate the look.
It is hard to believe someone is interesting in microsoft solutions. :)
Thanks, I'll try it.
In fact, it isn't mocrosoft solutions, but just a simple,
lightweight, etc. interface -- the same basic concepts (i.e. no 3D, but
black borders around objects) were used in many Dos apps, and are still used
on handhelds like Palm and cellular phones. I used Win31 just as a most
well-known example. ;-)
Second, is it possible to create an if-then-else construct in a
function? I tried to emulate the behaviour of Win9x's TaskBar, which can be
described as:
if (Iconic || !Raised)
{
Iconify Off
Raise
Focus
}
else
{
Iconify On
}
(i.e. deiconify if iconified, otherwise raise of not raised, otherwise
iconify).
We discussed adding shell abilities to fvwmrc two years ago and the
decission was not to do this, since preprocessors and PipeRead can do it.
But if-else construct does not seem too hard to implement. If we do this
we may have if, else, endif commands, so braces are not needed.
if (Iconic || !Raised)
Iconify Off
else
if (!Iconic)
Iconify On
endif
endif
This only seems complex, in fact it is simple. There is a list of boolean
conditions (one for each level of if) and the current command is
executed or skipped depending on the last boolean. (if, else, endif)
commands only manipulate this list of booleans (push, not, pop).
Well, it isn't complex at all -- elsif is just a shortcut for else if
in most modern languages.
As to using SetEnv+PipeRead -- yes, it's a neat hack ;-)
___
Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA
phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics
| Lab. 5-13
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: ButtonStyle Vector enhancements
On 1 Aug 01 at 15:34, [EMAIL PROTECTED] wrote: I have applied a small patch that adds 2 more colors to button vectors. There is a thread with this feature request and some discussion: http://www.hpc.uh.edu/fvwm/archive/0105/msg00294.html There are now 4 colors from a colorset, 0 to 3: shadow, hilight, bg, fg. So something like this is possible: ButtonStyle 8 Vector 10 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] \ [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ButtonStyle 0 Vector 10 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] \ [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] The first color in Vector is not used, so it is good to be always 2 (bg). As I mentioned in the linked thread, lines are more suitable for a relief shadow drawing, to draw using fg and bg colors shapes are more suitable. Probably later it makes sense to have pseudocommands: MoveToPoint, LineToPoint, RectangleToPoint, CircleOfRadius and so on. Currently there is only a LineToPoint functionality. Any suggestions are welcome. This may be done (or not) after we open the next branch for beta features. This would be a very useful feature. I don't know the reasons of the guy in referred thread, but the case when it is useful is buttons in Win9x style -- those should grow with title font size, and pixmap buttons are absolute unsuitable here. Just two notes. First, in addition to lines/rects/circles a filled polygon is needed (to draw all those [X] and alikes). Second, IMHO, names of the commands should be as short as possible -- like lineto, rectto, etc. Otherwise definitions will look just too heavy. BTW, is it currently possible to lift the pen with AddButtonStyle, i.e. draw two disjoint shapes? ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama w/ EdgeResistance problem
On 28 Jul 01 at 18:00, [EMAIL PROTECTED] wrote: There is a problem with Xinerama Edgeresistance and different screen sizes on the screens: Layout: screen 1 screen 2 +--++ | |+--+| | || || | ||window|| | || || +--+| || |+--+| || ++ When you move a window that is taller than screen 1 along the top edge of screen 2 and finally move it against or over the border between the screens it will then snap to the bottom border of screen 1: +--+ +--| |-+ | | | | | | | | | | | | | +--+ | +--+| || || ++ This can be very confusing, especially if the pointer is still on the second screen. One way to handle this may be to snap only to the screen that contains the pointer (?) There's no such thing as the decision for this problem. Some people will prefer current behaviour, while some -- current-pointer-screen-based one you suggest. IMHO the current bahaviour can be left as is to watch feedback after 2.4.1 release. EdgeResistance is a non-trivial concept on itself (remember what happens to windows with e.g. widthscreen_width widthscreen_width+edge_moving), and when combined with even more non-trivial concept of Xinerama, it can really confuse people (they wouldn't know themselves what they want fvwm to do). ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama merger -- part 1
On 28 Jul 01 at 18:15, [EMAIL PROTECTED] wrote: [SNIP] The point is not cleaning the code, but a correct operation of modules -- do you need a pager on non-primary screen? I don't quit understand the question. Of course I'd usually prefer the pager on the primary screen, but perhaps I wnat one on both screens. What I meant is that introducing Xinerama support into fvwm2 binary, but leaving modules still use XParseGeometry() is inconsistent -- the pieces of code responsible for window's placement should be modified too (sorry for my not-so-perfect english ;-). Otherwise in the case of the following layout: +--++ | 1024 |800 | | 768 |600 | | ++ +--+ too many things will tend to place themselves into the void. ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama merger -- part 1
).
BTW, if there is any risk, that rewriting the modules' placement
code may screw things up, that part should wait until after 2.4.1.
Cleaning up the code ca not be a priority in stable releases. Of
course you can still include the appropriate patches in your code,
but please comment them by ifdefs for now.
No, there's no risk at all. I changed only XParseGeometry plus related
calculations, which are always easily understandable (well, not so easily in
case of FvwmButtons ;) and hence have a very predicatble result. There'll
be no problems with #ifdef's -- I always change code in that way. ;-)
The point is not cleaning the code, but a correct operation of modules --
do you need a pager on non-primary screen?
P.S. Agreed about XiSuppClipToScreen -- I looked through modules, and only
one of them needs to pass at_x==*x and at_y==*y..
___
Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA
phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics
| Lab. 5-13This message contains a file prepared for transmission using the
MIME BASE64 transfer encoding scheme. If you are using Pegasus
Mail or another MIME-compliant system, you should be able to extract
it from within your mailer. If you cannot, please ask your system
administrator for help.
File information ---
File: XISU_DIF.GZ
Date: 28 Jul 2001, 20:10
Size: 2929 bytes.
Type: Binary
XISU_DIF.GZ
Description: Binary data
Re: Xinerama merger -- part 1
On 27 Jul 01 at 11:56, fvwm-workers@fvwm.org wrote: - Code is written with 80 characters per line, a basic indentation width of 2. - Always compile the code with and without your ifdefs. Remove all warnings (compile with 'make CFLAGS=-Wall -Werror -g). Okay. I usually set CFLAGS=-W -Wall -- this gives more interesting info. - Please keep in mind that that fvwm is controlled and configured by configuration commands, not by environment variables. It's not necessary to make features configurable via the environment. (I'll remove the corresponding code). As to this point, one reason was an ability to pass these parameters to modules (so that they will automatically be inherited via environment), and another is that some other proggies can theoritically use XiSupp.c (think about XMMS and various toolkits) or a similar thing, and they have no standard means of communicating to FVWM. Sure, modules interface can (and should?) be extended to accept PrimaryScreen change, but this is mostly irrelevant -- primary screen is usually taken into account only at startup. - Please try to use one of the formatting styles that is used in the fvwm code (indentation style). Try not to put commands on the same line as a condition. BTW, I looked for some style guide inside fvwm sources, but didn't find any. Your recommendations are definitely worth putting to some fvwm_style_guide.txt. - RandR support will certainly be no part of 2.4.1. You should really try to split the patches you made on your disk into several patch files that can be applied individually. Well, the RandR support can be at the same position as multibyte support - it is present but switched off by default. When HAS_RANDR is undefined, RandR will have no effect at all -- nothing will be queried in XiSupp.c, and no RandR handlers will be called in events.c and FvwmPager.c. I added RandR support as an additional step forward -- it enables to understand which currently used concepts will become obsolete in some near future, and what should be changed for more flexibility. That was the main goal, not an ability to use resize feature of yet very rarely used KDrive. ;-) One question about the XiParseGeometry function: I don't understand why is does so many things. It really shouldn't do more than just parsing the geometry string like XParseGeometry does and use the same signature. I'll comment out all the extra stuff for now. The answer is that modules do way too many calculations themselves (negative handling, gravity selection, etc.). Much of them are duplicates, and with submitted XiParseGeometry() modules become much simpler -- you add one/two lines and remove sometimes several dozens (look at patches for modules). Well, maybe XiParseGeometry is not a very appropriate name, in fact what this function does is very similar to XWMGeometry. ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Xinerama merger -- part 1
Hi!
That's part 1 of XineramaSupport v2 merger. It contains
libs/XineramaSupport.[ch] as drop-in replacements. Next part will be
configure script, followed by modules.
The only change required is to fvwm/menus.c -- to use
XiSuppClipToScreenAt() instead of XiSuppClipToScreen() (the first of them
appeared in XiSupp after february version).
Dominik, I have a question/correction regarding your changes to XiSupp.c.
The XiSuppDisable() was intended as a mechanism to hard-disable Xinerama,
while XiSuppSetState() -- to turn it on/off on the fly. As I understood,
you changed XiSuppSetState() to be internal call, while
XiSupp{Enable,Disable} are used as previously XiSuppSetState(). Am I right?
___
Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA
phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics
| Lab. 5-13This message contains a file prepared for transmission using the
MIME BASE64 transfer encoding scheme. If you are using Pegasus
Mail or another MIME-compliant system, you should be able to extract
it from within your mailer. If you cannot, please ask your system
administrator for help.
File information ---
File: FXNR_P1.TGZ
Date: 26 Jul 2001, 17:17
Size: 7298 bytes.
Type: Binary
FXNR_P1.TGZ
Description: Binary data
Regarding XQueryPointer
Hi! Forgot to ask before: what's the performance problem with XQueryPointer? Is it because this query syncs the X connection, or something else? And how did you notice it? I have only 10/100Mb ethernet and can't correctly slow it down to effectively simulate modem connection, so haven't noticed any problems. ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Solaris Xinerama
On 25 Jul 01 at 10:06, [EMAIL PROTECTED] wrote: Based on the man page, Solaris 8's Xserver supports Xinerama. There is no libXinerama so the configure test fails. There is also no header in X11/extensions. Can you compile fvwm w/Xinerama under XFree86 and run it with -display to Solaris' X? Or simply do xdpyinfo on Solaris box and look if XINERAMA is present in the list of extensions. Sun had a habit of shipping various libraries and utilities in separate optional packages, so... Anyway, find / | egrep -i 'xinerama|panoramix' will be a good source of information (Panoramix is Xinerama's old name). I don't know if there is some other way to detect Xinerama. I didn't see anything obvious in libs/XineramaSupport.c. No, AFAIK, what is currently used is the only way (well, how can we support Xinerama w/o libXinerama)? BTW, official X.org's R6.5.1 (or whatever is current) is a good place to look at, I'll do it. ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Solaris Xinerama
On 25 Jul 01 at 21:24, [EMAIL PROTECTED] wrote: I don't know if there is some other way to detect Xinerama. I didn't see anything obvious in libs/XineramaSupport.c. No, AFAIK, what is currently used is the only way (well, how can we support Xinerama w/o libXinerama)? BTW, official X.org's R6.5.1 (or whatever is current) is a good place to look at, I'll do it. Done. R6.6 ships with only panoramiX, which is absolutely unsatisfactory (while is also supported by libXinerama). The main problem in PanoramiX interface is insufficient screen info -- it doesn't supply screen origins, only sizes. This is solved in Xinerama interface, which was written by Mark Vojkovich for XFree86, and hence is currently XFree86-specific. ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Solaris Xinerama
On 25 Jul 01 at 11:04, [EMAIL PROTECTED] wrote: [SNIP] Odd that it doesn't list Xinerama. The Xsun man page says I should do xinit +xinerama to get Xinerama support. Perhaps the extension only shows when you do that. Right. An interesting fact is that Xnest also supports Xinerama (and it shows in a list of extensions if +xinerama is specified), but all screens always share the same (0,0) position, and I haven't find a way to configure it. I don't know if there is some other way to detect Xinerama. I didn't see anything obvious in libs/XineramaSupport.c. No, AFAIK, what is currently used is the only way (well, how can we support Xinerama w/o libXinerama)? I did find this: http://mail.gnome.org/archives/gtk-devel-list/2001-June/msg00279.html Well, people in that thread give the same result -- Solaris machines look like non-Xinerama-enabled. Mark V. pointed me to X.org's Xinerama task force, but they haven't released any docs/standards yet, and god knows when they will. Anyway, current XFree's interface is already widespread (it is used by at least E, SawFish (or is it SawMill?), Oroborus and Gnome). Even if the interface changes in the future, we'll have no problems adapting to it -- everything is incapsulated in XineramaSupport::XineramaSupportInit() (plus little checks in configure). P.S. There's no need to CC -- I'm on the list. ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama patch -- v2
On 23 Jul 01 at 18:55, fvwm-workers@fvwm.org wrote: On Mon, Jul 23, 2001 at 06:34:52PM +0700, Dmitry Yu. Bolkhovityanov wrote: Content-Description: Mail message body Hi! Attached is a new version of Xinerama patch. The .tgz contains a diff file (against 05-Jul-2001 snapshot), two new files in libs/, and a description of what was done. Could you by any chance update this patch for the current CVS version? The risk that I do something wrong if I merge the patch with the current code is way too high. This patch has a very basic RandR support, which is disabled by default. Also new from previous version is XiSuppParseGeometry(), which implements a concept of primary screen. To enable lots of debug info, -DDEBUG_PRINTS=1 can be used. Since some Xinerama support was already added to CVS, I decided to post this patch immediately and not spend time adapting it to current CVS (which will advance even further by the time adaptation is finished ;-). Well, either you adapt it or I do. Sice you wrote the patch yourself it's safer if you do it. Don't believe merging the patch is less work just because someone else does it ;-) Well, we should first decide who does it (sorry for such a bureacracy ;-) -- there's a 100%-possibility of conflict when simultaneously making changes to the same pieces of code. I'll have time for it about friday. The point is that new version should be integrated as soon as possible, for next changes to be based on it instead of older one. As I understand, all modifications to the modules/ can be performed safely, since you didn't touch them yet, right? And, BTW, the patch contained a slightly modified version of TaskBar patch (with revealed-when- focused functionality), which is already in CVS. So, if you do it now -- okay; if you give me a timeslot on friday -- I'll do it myself. ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama to-do
On 22 Jul 01 at 16:05, [EMAIL PROTECTED] wrote:
On Sun, Jul 22, 2001 at 09:32:38PM +0700, Dmitry Yu. Bolkhovityanov wrote:
[SNIP]
7) Maximizing windows
[SNIP]
Implementation of 7 also doesn't look problematic, I can do it.
Perhaps we should first discuss how to implement the new syntax in
general. There are several places where Xinerama specific
parameters would be useful (Move, Resize, ResizeMove, Maximize,
MoveToPage and others).
As to Maximize, the syntax can be extended with a single optional switch:
Maximize [absolute] ...
By default maximization occurs on a window's screen, but if absolute is
specified, the global screen is used instead (that's how it is done in E).
I'm not sure what to do with Move/Resize. These *can* also use an
optional absolute parameter, but Move should allow inter-screen moving by
default. Resize, on the other hand, can benefit from such a constraint.
Yuck, the Move is already constrained by inter-xinerama-screen
EdgeResistance, so applying optional absolute to resizing will be enough.
And what do you mean in 10 -- should Pager draw each page as a complex
shape, consisting of several rectangles, with possible blank areas,
instead of current simple rectangle? And should it limit moving mini-
windows as moving real ones are limited to existing screen space?
At least it would be nice to optionally have some kind of
separator similar to page separators. Also, the blank areas
should be visible and it shouldn't be possible to move windows
entirely into them.
Okay -- than we'll have to add XiSuppGetScreens or, better,
int XiSuppGetScreensCount(void)
void XiSuppGetNScrRect(int N, int *x, int *y, int *w, int *h).
But that must be re-queried on every XineramaUse/XineramaIgnore to keep
pager's list coherent with XineramaSupport's. Anyway, users of this
interface should be limited to Pager.
However some of the
Xinerama functions poll the pointer position which reduces
performance a lot, especially in the move and resize loops.
Is there any current-pointer-position cache in Xlib, which can be
queried instead of always calling XQueryPointer()? That could be fine.
I don't think so.
Otherwise we should add something like XineramaSupportNextEvent, which
could do caching instead.
Another solution would be to allow screen coordinates as optional
parameters to the XineramaSuporrt... function calls. The pointer
would only be queried if no position was given. I'm not yet sure
what the best solution would be.
I have been thinking about fvwm replacements for X and other
library funtions for a while. It may be a good idea to drop in
functions a la FvwmNextEvent as replacements for the X functions
and somehow automatically create a compiler error for all places
where the original function is used.
Optional parameters decision will require such parameters to too many
calls (some of the cases are not obvious). It seems better to introduce
FvwmNextEvent and make it call XiSuppSetMouseXY():
Bool cur_ms_coords_set = False;
void XiSuppSetMouseXY(int x, int y)
{
cur_ms_x = x;
cur_ms_y = y;
cur_ms_coords_set = True;
}
static void GetMouseXY(int *x, int *y)
{
if (cur_ms_coords_set)
{
*x = cur_ms_x;
*y = cur_ms_y;
}
else
XQueryPointer(...);
}
The cur_ms_coords_set guard is for just-started proggies, when no events
are received yet, but we need to know current pointer position.
BTW, are there any cases when a module will require XiSupp to do a
current-screen-based decision, while not feeding up-to-date XY info
beforehand (e.g., when the pointer is moved to other screen, and not above
that module's window)?
[SNIP]
As to general, standard X geometry specification turned to be
insufficient for Xinerama, so new XineramaSupport.c enables one to specify
[EMAIL PROTECTED], where optional S parameter is a screen.
Then we need an enhanced version of XParseGeometry() too?
Yes, that's the XineramaSupportParseGeometry() ;-)
The screen can be either a number or one of g (global -- emulates
XParseGeometry), c (current -- where pointer is), p -- primary (usually
1st screen, unless changed), this is the default.
Plus a concept of primary screen, where main controls are located
(Pager, Wharf, TaskBar (sic!)). (Since XFree86 4.1 XDM places its login
window to the 1st Xinerama screen too.)
Yes, the concept of a primary screen is a good idea - my primary
screen is right of the second one, so all kinds of windows don't
appear where I would like them to. Does it make sense to not use
the second screen at all unless the user explicitly moves or
starts applications there?
IMHO it is sane to obey sizehints when they request placing on non-
primary screen, and always try to start app on current screen. In most
cases current will be primary, so if the user wants a window on non-
primary screen, he should either move the pointer
Re: Regarding Xinerama support
On 22 Jul 01 at 13:37, [EMAIL PROTECTED] wrote: What is RandR? RandR is a Resize and Rotate extension -- an ability to change screen dimensions of a live X server. It is available in the CVS version of XFree86, and is currently limited to KDrive (aka TinyX). But it is being ported to mainstream XAA-based servers. A brief discussion of RandR is at http://www.xfree86.org/~keithp/talks/randr/ ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Xinerama patch -- v2
Hi!
Attached is a new version of Xinerama patch. The .tgz contains a diff
file (against 05-Jul-2001 snapshot), two new files in libs/, and a
description of what was done.
This patch has a very basic RandR support, which is disabled by default.
Also new from previous version is XiSuppParseGeometry(), which
implements a concept of primary screen.
To enable lots of debug info, -DDEBUG_PRINTS=1 can be used.
Since some Xinerama support was already added to CVS, I decided to post
this patch immediately and not spend time adapting it to current CVS (which
will advance even further by the time adaptation is finished ;-).
___
Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA
phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics
| Lab. 5-13This message contains a file prepared for transmission using the
MIME BASE64 transfer encoding scheme. If you are using Pegasus
Mail or another MIME-compliant system, you should be able to extract
it from within your mailer. If you cannot, please ask your system
administrator for help.
File information ---
File: FVWMXINR.TGZ
Date: 23 Jul 2001, 17:13
Size: 27149 bytes.
Type: Binary
FVWMXINR.TGZ
Description: Binary data
Re: Notification: incoming/743
On 21 Jul 01 at 19:36, [EMAIL PROTECTED] wrote: The subject says it all -- if one presses keys when a shaded window is focused, that app receives key events. Since shading is like iconifying (i.e. minimizing a space, occupied by a window, to some icon), it is wise to prevent keys from going to shaded windows. Other WMs (at least AfterStep) do so. Yes, shading is like iconifying. Fvwm treats shaded windows like iconified ones: they both get keyboard input. This can come in handy if you have to paste the same text into 20 windows. This was a very conscious choice we made (okay: I made). Where exactly is the problem? No, *iconified* windows don't get keyboard input. Test it with e.g. sample.fvwmrc/system.fvwm2rc. The same happens with AnotherLevel. As to where is the problem... It is a very unusual and un-intuitive behaviour (IMHO, of course). I can live with it, and can be even very happy with it (your example with 20 windows seems reasonable). But users get confused. ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Regarding Xinerama support
Hi! I've almost made a very improved version (as compared to February), but still have to spend a few days finishing it. It is now based on 2.4 instead of 2.3.28. As I understood from conversation in the list, there were plans to do 2.4.1 as a bugfix-only release, so I didn't hurry (mea culpa...). Now I'm finishing adding basic RandR support, but there are two choices: 1) comment out RandR-handling and post diff immediately; 2) spend those few days and post somewhere near wednesday. What will be preferred? ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: CVS domivogt: * First version of Xinerama support.
On 22 Jul 01 at 1:48, [EMAIL PROTECTED] wrote: On 21 Jul 2001 14:29:27 -0500, FVWM CVS wrote: Log message: * First version of Xinerama support. I don't think that HAS_XINERAMA is ever defined (because XINERAMA_CPPFLAGS is nowhere used) and thus parts of the xinerama code are ever compiled in, although it is reported as such. It is also buggy. Windows get Y coordinate -9, i.e. disappear, when trying to move them... Seems very strange. I haven't tested current CVS version, but such an effect should never happen -- XineramaSupport falls back to global screen, which is DisplayWidth()xDisplayHeight()+0+0, so I have no idea where -9 came from (there *theoretically* can be -32767 from XiSuppGetResistanceRect(), but not -9). Probably a result of not-yet- complete checkin? I don't have any real hardware xinerama setup, but X supports it. XineramaSupport is designed to be always active -- no matter if real XINERAMA extension is present/enabled -- in the latter case it will look as only one screen, having DisplayWidth*DisplayHeight size. ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/741
On 17 Jul 01 at 12:41, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
When I run this with 1.3 or 1.2 FvwmIdentify reports no name or icon
label as would be expected. If you run win.setTitle(to some title);
I don't know how you could be getting the title you depict in your
screenshot.
This rings an ancient bell, it might be something in the environment
(like $LANG or something) that swing is picking up. I used to get funny
chars in the title of CDE apps when I had LANG=uk or whatever the
default was on my system. I think it might be a hacky thing in swing
that should go away when everything move to the new window manager hints
standard.
Actually this looks like a vt100/iso2022 escape sequence ('=','(','B'
is ESC ( B -- select default mapping (see console_codes(4)). So the
problem seems to be i18n-related.
I've seen similar artefacts with AbiWord in russian locale -- in that
case fvwm-2.4 displays iso2022 escape sequences mixed with actual title
text. And ESC ( B is also a valid is2022 sequence for selecting US ASCII.
Probably compilation with --enable-multibyte fill fix the situation.
___
Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA
phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics
| Lab. 5-13
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Regarding fvwm-2.4 RPM
Hi! First, the package is named fvwm, not fvwm2, which prevents it from being a drop-in replacement for RedHat's RPM. It -provides the fvwm capability, which is a bit wrong, since there's no fvwm binary inside. Additionaly, some people still use fvwm-1.24, and naming the current version simply fvwm will confuse them (since recommended rpm -Uvh will remove fvwm-1). Is it possible to rename the package to fvwm2? (Yes, fvwm2-2.4 looks a bit weird, but it is an existing practice). Second, the fvwm-2.4.0-2.rh7.rpm doesn't include any config files in proper places, so that when a freshly installed fvwm2 is run, it complains: [FVWM][main]: ERROR Cannot read startup file, tried: /export/viper/rabbit/.fvwm/.fvwm2rc /export/viper/rabbit/.fvwm2rc /usr/share/fvwm/.fvwm2rc /usr/share/fvwm/system.fvwm2rc /usr/etc/system.fvwm2rc BTW, it should also try /etc/X11/system.fvwm2rc and/or /etc/X11/fvwm2/system.fvwm2rc (see FHS section 3.7.5.2). If nobody else bothers, I can make appropriate patch for spec file. ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: LDFLAGS or LD_OPTIONS or LDOPTS
On 27 May 01 at 9:21, [EMAIL PROTECTED] wrote: Our INSTALL.fvwm file suggests that the user should export LDFLAGS on Solaris (for example). The Solaris man pages for Solaris 2.6 and 2.8 identify LD_OPTIONS as the right variable. HPUX11.11 uses LDOPTS. AIX 4.3 doesn't seem to have anything. Anyone know where LDFLAGS works? All the following supposes that you refer to Make (is there such a thing as non-GNU autoconf?). Well, of course in GNU `Make' it is well documented ;-) * Solaris 2.5 (uname -sr: SunOS 5.5.1) make(1): mentions $(LDFLAGS) in all LINK.* rules. * Digital UNIX (OSF1 V4.0) make(1): LDFLAGS For ld flags. Default is null. * IRIX (IRIX64 6.5) make(1): LFLAGS= LDFLAGS= and later .c: $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $ (what is interesting that it actually places $(LDFLAGS) *at the end* of commandline: sky:~% export LDFLAGS=-zzz sky:~% make -n -f /dev/tty req req: req.c Ctrl+D cc -O -o req req.c -zzz ) * FreeBSD (very old, FreeBSD 2.2-970625-RELENG): make(1) doesn't mention LDFLAGS, but it works exactly as specified in IRIX make(1). * OpenBSD (OpenBSD 2.7) behaves exactly as FreeBSD. * BSD/OS (BSD/OS 3.1, old -- 1998) doesn't mentions any *FLAGS (except MAKEFLAGS) in man(1), doesn't seem to honour $LDFLAGS and strings `which make` shows that the binary doesn't contain any references to it. ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Icon titles not retracting
On 8 May 01 at 1:59, [EMAIL PROTECTED] wrote: On 07 May 2001 13:47:22 +0200, Dominik Vogt wrote: When had this changed? Fvwm 2.2.4 had this behaviour at least with AnotherLevel (i.e. the icon title shown expanded while the icon had focus)... and the users got accustomed to it. Hm, now that you say it, I can vaguely remember. Expanding the title when the pointer is over the icon was introduced in 2.3.2. I guess there is some relation to the new feature. Fixed. I don't think this is a good change. We discussed this 2 years ago and agreed (at least Dominik, Matthias and me) that leaving an icon should collapse the icon title. http://www.hpc.uh.edu/fvwm/archive/9904/msg00609.html The opposite behaviour is very annoying if you don't have other focusable windows on a page just to shutdown that long icon title. Dmitry, are you sure you prefer that old behavior? :) I think we should restore the behavior we had for more than 2 years now. We may have an option later if anyone really prefers another one. Well, in fact for *me* it doesn't matter -- I rarely use Iconify, since multiple screens/desktops are better. A quick poll between our personnel shown that they simply don't realize the difference -- Style * SloppyFocus, so in presence of many windows on the screen both behaviours are very similar. As I understand, the new behaviour is the same as in Win98/ME/2k -- those show yellow tips containing long titles when mouse enters the icon. The only difference is that the tips are of different color and are understood as such. But this isn't important, so the current expand-when- mouse-on-icon is good. ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: fvwm-ewmh pre-announce
On 6 May 01 at 21:28, [EMAIL PROTECTED] wrote: Any way, I am interested by the utf 8 stuff. It is a good solution for supporting all the languages. So, maybe I will implement the utf-8 part of the spec. in the future. At the present time I have to take a look at the different C libraries available. Any suggestion is welcome. AFAIK, the most ubiquitous charset conversion library is libiconv. GNU libiconv is available at http://clisp.cons.org/~haible/packages-libiconv.html . If you wish to *display* utf8 strings, there is a Xutf8* family by Bruno Haible in XFree86 = 4.0.2, but these are experimental and their inclusion caused great scandal in i18n@xfree86.org (CJK people disliked this interface very much). ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
