CVS domivogt: * Several menu placement/Xinerama fixes.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/07/22 19:56:03 Modified files: . : ChangeLog fvwm : menus.c windowlist.c Log message: * Several menu placement/Xinerama fixes. -- Visit the official FVWM web page at 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 Sun, Jul 22, 2001 at 09:32:38PM +0700, Dmitry Yu. Bolkhovityanov wrote:
> On 22 Jul 01 at 12:57, [EMAIL PROTECTED] wrote:
>
> > Here is a list of features Xinerama support may or may not
> > support:
> >
> > 1) Window placement
> > 2) Icon placement
> > 3) Menu placement
> > 4) Menu position hints
> > 5) Sizing menus for different screen sizes
> > 6) Position of the geometry window
> > 7) Maximizing windows
> > 8) Limit SnapAttraction to windows on same screen.
> > 9) Enable and Disable Xinerama on the fly (including modules)
> > 10) Xinerama support in Pager
> > 11) Xinerama support in WindowList
> > 12) XineramaSupport in various icon managers (IconMan, WinList)
> > 13) EdgeScrolling between Xinerama screens.
> > 14) Handle Xinerama screens in Move/Resize parameters.
> >
> > Currently, 3, 6, 9 and 13 are implemented.
>
> I've already implemented 11 (i.e. FvwmWinList obeys current xinerama-
> screen when managing its geometry, but should we introduce
> "ShowCurrentScreen" option? I think no).
With 11 I meant the WindowList command, not the FvwmWinList
module. Of course it should be done in the module too.
> 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).
> BTW, did you mean "EdgeResistance" in 13?
Yes.
> 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.
> > 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.
> > Consider this layout of a Xinerama screen consisting of two
> > physical screens:
> >
> > Xinerama screen
> > +-+--+
> > | | |
> > | | |
> > | | |
> > | | |
> > | | screen 2|
> > | screen 1| |
> > | | |
> > | | |
> > | | |
> > | | |
> > +-+ |
> > | blank area| |
> > | | |
> > +-+--+
> >
> >
> > At the moment, the most annoying problems are:
> >
> > - Fvwm happily places windows and icons in blank areas.
> > - Menus are sized for the whole screen. If a menu that is as
> >tall as screen 2 is opened on screen 1, the bottom items are
> >not accessible.
> > - Maximizing windows always covers the whole screen, not only
> >the sub screen with the window.
> >
> > In another step it may be worthwhile to put all code dealing with
> > screen dimensions in a single library libs/Screen.c instead of
> > libs/XineramaSupport.c. This libraray could handle all
> > arithmetics with screen dimensions and would be the only place
> > that knows about Xinerama at all.
>
> It is exactly the point which was taken when designing XineramaSupport --
> to make an abstract "screen geometry" layer. RandR support fits fine into
> this model. "Screen.c" seems to be a reasonable name (I already thought
> about using AdvScrn.c ("advanced screen management"), and hence "AdvScrn"
> prefix for all its functions -- "XineramaSupportXXX" is s long. :-)
How about "FvwmAdvancedScreenManagementModule" as a prefix ;-) I
guess "fvwmlib_..." would do, or perhaps "fvwmlib_screen_..." (I
prefer underscores to capitals, but I won't make it
CVS domivogt: * Fixed placement of menus that reach beyound the left edge of a Xinerama
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/07/22 18:56:18 Modified files: . : ChangeLog fvwm : menus.c Log message: * Fixed placement of menus that reach beyound the left edge of a Xinerama screen. -- Visit the official FVWM web page at 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/742
On Tue, Jul 17, 2001 at 04:06:21AM -0500, fvwm-bug wrote: > FVWM Bug Tracking notification > > new message incoming/742 > > Message summary for PR#742 > From: [EMAIL PROTECTED] > Subject: PRIVATE: modal windows > Date: Tue, 17 Jul 2001 04:06:19 -0500 > 0 replies 0 followups > > Full_Name: Wojciech Karas > Version: 2.4.0 > CVS_Date: > OS: Linux 2.4.5 > X_Server: Xfree 3.3.6 > Submission from: (NULL) (149.156.101.90) > > > The modal windows ( like for instnse "settings" in kmail ) are hiding > behind > the root window after first attempt to use them. You can pull them back > then > by ALT+TAB but it's tedious. I have tested this behavior on a Tcl based > application and to be sure in Netscape. Can you please provide more details? What exactly are you doing - could you give us detailed instructions along with your config file? Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at 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: man page formatting
On Sun, Jul 22, 2001 at 12:35:06PM -0400, Dan Espen wrote: > Dominik Vogt <[EMAIL PROTECTED]> writes: > > On Sun, Jul 22, 2001 at 10:48:41AM -0400, Dan Espen wrote: > > > It looks to me like the Linux .BI command is dependent on groff's > > > ".while" command which doesn't appear to available on Solaris. > > > > And what about macros like .BR or .IR? Do they suffer from the > > same problem? > > Yes they do, but I didn't see any instances of those macros > with more than 6 arguments. > > The only man page I've looked at so far is the fvwm man page. The other man pages still use the \f... approach. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at 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]
CVS domivogt: * Fixed -99999 y position when moving windows that was broken w/ the Xinerama
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/07/22 18:38:20 Modified files: . : ChangeLog NEWS todo-xinerama fvwm : fvwm2.1 menus.c menus.h move_resize.c virtual.c windowlist.c libs : XineramaSupport.c XineramaSupport.h Log message: * Fixed -9 y position when moving windows that was broken w/ the Xinerama patch. * Menu position hints properly handle Xinerama screens. * New context rectangle "XineramaRoot" for Menu and Popup commands. * Mention all changes in NEWS. * Some preliminary changes in Xinerama interface. -- Visit the official FVWM web page at 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 Sun, Jul 22, 2001 at 06:18:57PM +, Mikhael Goikhman wrote: > On 22 Jul 2001 16:49:43 +, Mikhael Goikhman wrote: > > > > Yes, Xinerama support is on after "configure; make install". > > The same problem happens with "configure --disable-xinerama". > > BTW, I can't reproduce the problem with WindowShade now. > Only interactive Move is problematic. Somehow, several dozens lines of old or trash code had slipped into DoSnapAttraction() in move_resize.c. I have removed this code and it works for me again. The problem only showed up if you did not use SnapGrid. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at 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 2001 16:49:43 +, Mikhael Goikhman wrote: > > Yes, Xinerama support is on after "configure; make install". The same problem happens with "configure --disable-xinerama". BTW, I can't reproduce the problem with WindowShade now. Only interactive Move is problematic. Regards, Mikhael. -- Visit the official FVWM web page at 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]
CVS migo: * removed previous incorrect fix added by error
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: migo01/07/22 13:14:42 Modified files: . : ChangeLog libs : Makefile.am Log message: * removed previous incorrect fix added by error -- Visit the official FVWM web page at 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 12:57, [EMAIL PROTECTED] wrote:
> Here is a list of features Xinerama support may or may not
> support:
>
> 1) Window placement
> 2) Icon placement
> 3) Menu placement
> 4) Menu position hints
> 5) Sizing menus for different screen sizes
> 6) Position of the geometry window
> 7) Maximizing windows
> 8) Limit SnapAttraction to windows on same screen.
> 9) Enable and Disable Xinerama on the fly (including modules)
> 10) Xinerama support in Pager
> 11) Xinerama support in WindowList
> 12) XineramaSupport in various icon managers (IconMan, WinList)
> 13) EdgeScrolling between Xinerama screens.
> 14) Handle Xinerama screens in Move/Resize parameters.
>
> Currently, 3, 6, 9 and 13 are implemented.
I've already implemented 11 (i.e. FvwmWinList obeys current xinerama-
screen when managing its geometry, but should we introduce
"ShowCurrentScreen" option? I think no).
Implementation of 7 also doesn't look problematic, I can do it.
BTW, did you mean "EdgeResistance" in 13?
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?
> 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.
Otherwise we should add something like "XineramaSupportNextEvent", which
could do caching instead.
> Consider this layout of a Xinerama screen consisting of two
> physical screens:
>
> Xinerama screen
> +-+--+
> | | |
> | | |
> | | |
> | | |
> | | screen 2|
> | screen 1| |
> | | |
> | | |
> | | |
> | | |
> +-+ |
> | blank area| |
> | | |
> +-+--+
>
>
> At the moment, the most annoying problems are:
>
> - Fvwm happily places windows and icons in blank areas.
> - Menus are sized for the whole screen. If a menu that is as
>tall as screen 2 is opened on screen 1, the bottom items are
>not accessible.
> - Maximizing windows always covers the whole screen, not only
>the sub screen with the window.
>
> In another step it may be worthwhile to put all code dealing with
> screen dimensions in a single library libs/Screen.c instead of
> libs/XineramaSupport.c. This libraray could handle all
> arithmetics with screen dimensions and would be the only place
> that knows about Xinerama at all.
It is exactly the point which was taken when designing XineramaSupport --
to make an abstract "screen geometry" layer. RandR support fits fine into
this model. "Screen.c" seems to be a reasonable name (I already thought
about using AdvScrn.c ("advanced screen management"), and hence "AdvScrn"
prefix for all its functions -- "XineramaSupportXXX" is s long. :-)
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.
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.)
And what is completely broken by Xinerama is TaskBar with its autohiding
logic (AutiStick, however, is fixable). I've spent a lot of time trying to
make it work, but seems that it will be *much* easier to implement
Style AutoHide. The latter is more correct, BTW, since some aspects are
absolutely impossible to do in a module instead of WM itself.
(It seems I write too much this evening, time to go to sleep ;-)
___
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 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 2001 09:29:00 +0200, Dominik Vogt wrote: > > On Sun, Jul 22, 2001 at 01:48:00AM +, Mikhael Goikhman 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. > > I don't know. At least for my Xinerama setup it works: the > Xinerama code is compiled in. The code in configure.in sure looks > different. Shouldn't this HAS_XINERAMA macro end up in config.h? > Perhaps this would be a good practice for me to learn writing > configure code. Do you say you ever got "Xinerama" in "fvwm -version"? I don't think so. You almost fixed it on the second commit, but did a typo s/XINERAMA/HAVE_XINERAMA/. Also building of libfvwm.a failed, because -lXinerama was not passed to it. Now it should work. > > It is also buggy. Windows get Y coordinate -9, i.e. disappear, when > > trying to move them... > > I don't have this problem. Was Xinerama support compiled in? > Can you have a look what's happening? Yes, Xinerama support is on after "configure; make install". I have a single screen. When a window is dragged (mouse moved) or a window is shaded, it gets Y coordinate -9. When printing xl and yt in moveLoop() before loop or even on MotionNotify they seem ok, although I don't understand their exact meaning yet. But on ButtonRelease yt becomes -9. The window disappear when mouse is moved, not only when mouse is released. In addition, the feedback window is not visible. > > I don't have any real hardware xinerama setup, but X supports it. > > I will add some code to simulate Xinerama on a single screen. Ok, I may try it later, but for now I have problems without simulating black holes on a single screen. Regards, Mikhael. -- Visit the official FVWM web page at 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: man page formatting
Dominik Vogt <[EMAIL PROTECTED]> writes: > On Sun, Jul 22, 2001 at 10:48:41AM -0400, Dan Espen wrote: > > Dan Espen <[EMAIL PROTECTED]> writes: > > > Dominik Vogt <[EMAIL PROTECTED]> writes: > > > > On Sat, Jul 21, 2001 at 07:48:17PM +, Mikhael Goikhman wrote: > > > > > On 21 Jul 2001 19:26:09 +0200, Dominik Vogt wrote: > > > > > > > > > > > > The recent fixes in the man page for Solaris etc. (\f...) broke > > > > > > the bold typeface of the reformatted sections. For example: > > > > > > > > > > > > .TP > > > > > > .BI "Menu " menu-name " [ " position " ] [ " double-click-action > > > > > > > > > > > > was changed to > > > > > > > > > > > > .IP "Menu \fImenu-name\fP [ \fIposition\fP ] [ \fIdouble-click-ac > > > > I meant to mark them as bold, oh, I see, the first 2 that I did > > I copied verbatim from the 2.2.x version of the manual. > > > > ... > > > > > I tried using multiple .BI commands but the text ran into the paragraph. > > > > > > I wonder if the .BI command used in Linux would work with the vendors > > > nroff/troff, perhaps all we need to do is copy the .BI macro into the > > > file(s) we need it in. > > > > > > Maybe I'll have some time to check later... > > > > It looks to me like the Linux .BI command is dependent on groff's > > ".while" command which doesn't appear to available on Solaris. > > And what about macros like .BR or .IR? Do they suffer from the > same problem? Yes they do, but I didn't see any instances of those macros with more than 6 arguments. The only man page I've looked at so far is the fvwm man page. -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- Visit the official FVWM web page at 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]
CVS domivogt: * Added xinerama to do list.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/07/22 11:26:47 Added files: . : todo-xinerama Log message: * Added xinerama to do list. -- Visit the official FVWM web page at 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]
CVS migo: * configure: finally make #ifdef'd xinerama code be ever compiled in;
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: migo01/07/22 11:15:00 Modified files: . : ChangeLog configure.in libs : Makefile.am utils : ChangeLog fvwm-config.in Log message: * configure: finally make #ifdef'd xinerama code be ever compiled in; _ fixed linking of libfvwm.a by adding -lXinerama; small corrections * fvwm-config: added shape support and resorting -- Visit the official FVWM web page at 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: man page formatting
On Sun, Jul 22, 2001 at 10:48:41AM -0400, Dan Espen wrote: > Dan Espen <[EMAIL PROTECTED]> writes: > > Dominik Vogt <[EMAIL PROTECTED]> writes: > > > On Sat, Jul 21, 2001 at 07:48:17PM +, Mikhael Goikhman wrote: > > > > On 21 Jul 2001 19:26:09 +0200, Dominik Vogt wrote: > > > > > > > > > > The recent fixes in the man page for Solaris etc. (\f...) broke > > > > > the bold typeface of the reformatted sections. For example: > > > > > > > > > > .TP > > > > > .BI "Menu " menu-name " [ " position " ] [ " double-click-action " > > > > > ]" > > > > > > > > > > was changed to > > > > > > > > > > .IP "Menu \fImenu-name\fP [ \fIposition\fP ] [ > > > > > \fIdouble-click-action > > I meant to mark them as bold, oh, I see, the first 2 that I did > I copied verbatim from the 2.2.x version of the manual. > > ... > > > I tried using multiple .BI commands but the text ran into the paragraph. > > > > I wonder if the .BI command used in Linux would work with the vendors > > nroff/troff, perhaps all we need to do is copy the .BI macro into the > > file(s) we need it in. > > > > Maybe I'll have some time to check later... > > It looks to me like the Linux .BI command is dependent on groff's > ".while" command which doesn't appear to available on Solaris. And what about macros like .BR or .IR? Do they suffer from the same problem? Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at 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: Regarding Xinerama support
On Sun, Jul 22, 2001 at 07:51:14PM +0700, Dmitry Yu. Bolkhovityanov wrote: > 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. Hey, you were doing this in secret? :-) Didn't I say that I would keep the patch up to date? Actually, I did this and checked it in now. I made several enhacements regarding efficiency (don't poll the mouse with only one screen), usability (enable/disable on the fly, renamed commands to XineramaEnable/XineramaDisable), configure (HAVE_XINERAMA is put into config.h), general code structure (changed library user interface a bit), xinerama emulation (for people with one monitor). As you may have noticed I already started another thread to discuss the details of the Xinerama implementation. Before we continue patching we should think about the right way > 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...). Gee, the plans were overridden by me committing the Xinerama patch ;-) I plan to add Xinerama support along with the first bugfixing release. I don't think it will take this much time. It will suffice to support a minimal set of Xinerama features at first and circumvent the problems I described in my other mail. The fancy gimmicks can wait for a future release. > Now I'm finishing adding basic RandR support, but there are two choices: > 1) comment out RandR-handling and post diff immediately; If you already have both patches in your code it is best to check out a fresh fvwm from cvs and re-add your Xinerama changes there. I think the last time you sent the Xinerama patch there was another non-xinerama patch in the diff (Bindings.c, but I'm not sure). > 2) spend those few > days and post somewhere near wednesday. What will be preferred? What is RandR? Anyway, as soon as 2.4.1 with Xinerama is released, the stable versions get their own branch and development on the main branch will (hopefully) start with full force. Until then it would help most if we all concentrate on the Xinerama patch (and bug fixes) before adding new features. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at 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]
CVS dane: * fvwm/fvwm2.1: Remove some test code, fix remaining .IP commands.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: dane01/07/22 09:59:30 Modified files: . : ChangeLog fvwm : fvwm2.1 Log message: * fvwm/fvwm2.1: Remove some test code, fix remaining .IP commands. -- Visit the official FVWM web page at 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: man page formatting
Dan Espen <[EMAIL PROTECTED]> writes: > Dominik Vogt <[EMAIL PROTECTED]> writes: > > On Sat, Jul 21, 2001 at 07:48:17PM +, Mikhael Goikhman wrote: > > > On 21 Jul 2001 19:26:09 +0200, Dominik Vogt wrote: > > > > > > > > The recent fixes in the man page for Solaris etc. (\f...) broke > > > > the bold typeface of the reformatted sections. For example: > > > > > > > > .TP > > > > .BI "Menu " menu-name " [ " position " ] [ " double-click-action " ]" > > > > > > > > was changed to > > > > > > > > .IP "Menu \fImenu-name\fP [ \fIposition\fP ] [ \fIdouble-click-action I meant to mark them as bold, oh, I see, the first 2 that I did I copied verbatim from the 2.2.x version of the manual. ... > I tried using multiple .BI commands but the text ran into the paragraph. > > I wonder if the .BI command used in Linux would work with the vendors > nroff/troff, perhaps all we need to do is copy the .BI macro into the > file(s) we need it in. > > Maybe I'll have some time to check later... It looks to me like the Linux .BI command is dependent on groff's ".while" command which doesn't appear to available on Solaris. -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- Visit the official FVWM web page at 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/743
On Sun, Jul 22, 2001 at 07:36:54PM +0700, Dmitry Yu. Bolkhovityanov wrote:
> 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.
But they do. They may not *take* keyboard input, but that is the
choice of the application. For example, xemacs and rxvt take
keyboard input while iconified out of the box. xterm does not
normally use keyboard input, but if started with the active icon
feature it does ("xterm +ai", must be compiled in). Other
applications may or may not accept keyboard input in the iconified
state.
> 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.
I guess there wouldn't be much confusion if it were possible to
explicitly remove the focus from the window, e.g.
function my_windowshade
+ I Current (!Shaded) UnfocusWindow
+ I WindowShade toggle
This would unfocus the newly shaded window but still allow to
explicitly focus it again with the mouse to give it keyboard
input.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
Visit the official FVWM web page at 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 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 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 Sun, Jul 22, 2001 at 01:48:00AM +, Mikhael Goikhman 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. I don't know. At least for my Xinerama setup it works: the Xinerama code is compiled in. The code in configure.in sure looks different. Shouldn't this HAS_XINERAMA macro end up in config.h? Perhaps this would be a good practice for me to learn writing configure code. > It is also buggy. Windows get Y coordinate -9, i.e. disappear, when > trying to move them... I don't have this problem. Was Xinerama support compiled in? Can you have a look what's happening? > I don't have any real hardware xinerama setup, but X supports it. I will add some code to simulate Xinerama on a single screen. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at 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 to-do
Here is a list of features Xinerama support may or may not support: 1) Window placement 2) Icon placement 3) Menu placement 4) Menu position hints 5) Sizing menus for different screen sizes 6) Position of the geometry window 7) Maximizing windows 8) Limit SnapAttraction to windows on same screen. 9) Enable and Disable Xinerama on the fly (including modules) 10) Xinerama support in Pager 11) Xinerama support in WindowList 12) XineramaSupport in various icon managers (IconMan, WinList) 13) EdgeScrolling between Xinerama screens. 14) Handle Xinerama screens in Move/Resize parameters. Currently, 3, 6, 9 and 13 are implemented. However some of the Xinerama functions poll the pointer position which reduces performance a lot, especially in the move and resize loops. Consider this layout of a Xinerama screen consisting of two physical screens: Xinerama screen +-+--+ | | | | | | | | | | | | | | screen 2| | screen 1| | | | | | | | | | | | | | +-+ | | blank area| | | | | +-+--+ At the moment, the most annoying problems are: - Fvwm happily places windows and icons in blank areas. - Menus are sized for the whole screen. If a menu that is as tall as screen 2 is opened on screen 1, the bottom items are not accessible. - Maximizing windows always covers the whole screen, not only the sub screen with the window. In another step it may be worthwhile to put all code dealing with screen dimensions in a single library libs/Screen.c instead of libs/XineramaSupport.c. This libraray could handle all arithmetics with screen dimensions and would be the only place that knows about Xinerama at all. Any comments and help with the implementation are welcome. For those who don't have a second monitor I added the configure option --enable-xinerama-emulation. The Xinerama code is enabled on a single screen with the above layout, including the blank area. For testing, it is probably best to fill the blank area with a single window so you can see when the pointer or a window or menu reaches into the forbidden zone. You do not need the Xinerama extension in your X server for this to work. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at 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/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 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]
CVS domivogt fvwm-web: * Minimalistic description of Xinerama support.
CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by: domivogt01/07/22 07:27:19 Modified files: . : ChangeLog mod_f2m_communication.html Log message: * Minimalistic description of Xinerama support. -- Visit the official FVWM web page at 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]
CVS domivogt: * Added Xinerama emulation (configure with --enable-xinerama-emulation).
CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: domivogt01/07/22 07:26:25
Modified files:
. : ChangeLog acconfig.h configure.in
fvwm : Makefile.am fvwm.c fvwm2.1 module_interface.c
module_interface.h virtual.c
libs : XineramaSupport.c
modules: ChangeLog
modules/FvwmEvent: FvwmEvent.c
modules/FvwmForm: Makefile.am
modules/FvwmScript: Instructions.c
modules/FvwmWharf: FvwmWharf.c
Log message:
* Added Xinerama emulation (configure with --enable-xinerama-emulation).
* Added configure checks for shape extension.
* Added #include to several files.
* Communicate Xeinerama{En,Dis}able to modules.
* Sorted configure summary.
--
Visit the official FVWM web page at 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]
