Xinerama support for IconBox style?
Dan, I looked at the icon box code in style.c because I wanted to make it work with changes of the Xinerama state, but the matter is too complex to write a patch in short time for me. What I want to do: 1) Default to using the primary screen for icon box specs (already works for X geometry like specs and is easy to do for the other syntax). 2) Recalculate all icon boxes when the Xinerama layout of the screen changes (switched on or off). The difficult part is (2) because all the calculations are done when the style is defined. The precise spec string is thrown away afterwards. So doing this requires to remove the calculations from style.c and do them somewhere is icons.c. Can you take a look at this, please? I think this could wait until after 2.4.1. 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: Xinerama patch for "Maximize"
On Sat, Aug 18, 2001 at 06:59:56PM +0700, Dmitry Yu. Bolkhovityanov wrote:
> 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.
Well, the ordinary user would not use that syntax at all but stick
with
Maximize on
Maximize on 100 0
Maximize on 0 100
Anyway, as nice as a common syntax for all the resizing/moving
commands would be, its not the proper time to do this.
> 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.
Yes, and my X11 book says: "If the [parse]string is not in Host
Portable Character Encoding, the result is
implementation-dependent."
> Anyway, can you please post a formal definition of new syntax,
> like a BNF?
No, I can't. I don't even know the correct definition of the
standard X11 geometry spec.
> Sorry for only criticizing, but I yet have to find out some
> reasonable suggestions.
Let's skip my idea for now and update the old syntax.
> Second, due to compatibility reasons, the old syntax should still
> be supported.
Of course. I only though about not writing new features for the
old syntax.
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: 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 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 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. > -- 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. Basically, the parser would have to do the same as the non geometry based dimension/position parsers we have. For each bit of the geometry spec it should optionally accept a suffix to the number, e.g. 100px100p+0m+0m, and possibly a list of key words. This way it would finally possible to have something like this: Maximize 640pxgrow-5+0p (maximized window is placed 5% of the screen width off the right border and ant the top of the screen with a width of 640 pixels and whatever height fits). Of course this requires a pre parsing pass over the geometry string that filters out all the fancy suffices and key words before calling ...ParseGeometry. int FancyParseGeometry( char *geom, int *ret_x, int *ret_y, int *ret_w, int *ret_h, char *xy_suffix_array, int *xy_units_array, char **xy_keywords, int *ret_x_unit, int *ret_y_unit, char *wh_suffix_array, int *wh_units_array, char **wy_keywords, int *ret_w_unit, int *ret_h_unit, int *ret_w_keyword, int *ret_h_keyword); Pretty complex I guess, but very useful. > 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? As usual, @c would address the screen that contains the pointer, possibly projected to other pages or desks. To force the window into the current viewport, the MoveToDesk/Page/Screen commands can be used. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- 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 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 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 Wed, Aug 15, 2001 at 08:30:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: > 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). 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. > 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. I see. Consider it fixed :) > 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. The comment should better read: maximize on the page where the center of the window is, but if any part of the window is on the current page, maximize it there. > 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 ;-) You would have to ask Olivier. He wrote that stuff. Anyway, I don't really care about this. It is only meant as visible feedback for testing and debugging. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- 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 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 Mon, Aug 13, 2001 at 10:27:12AM -0400, Dan Espen wrote:
> Dominik Vogt writes:
> > On Tue, Aug 07, 2001 at 01:05:22PM +0200, Olivier Chapuis wrote:
> > > BTW, I think that the change Xinerama{Enable,Disable} -> Xinerama
> > > is not very good: it is difficult to a configuration tool or a user
> > > new to Xinerama to know if Xinerama is enabled or not.
> >
> > Er, what is the big difference between
> >
> > XineramaEnable
> > XineramaDisable
> >
> > and
> >
> > Xinerama on
> > Xinerama off
> >
> > ? It just saves the additional commands. And I can't think of
> > any fvwm command that has an "off" and an "on" version.
>
> Iconify on
> Iconify off
That's what I said. You have one command with an "on" and an
"off" option instead of "Iconify" and "Deiconify". This makes
toggling these settings possible in the first place. My wording
was a bit unfortunate, perhaps.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, email: [EMAIL PROTECTED]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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: A naive Xinerama question
Dominik Vogt writes:
> On Tue, Aug 07, 2001 at 01:05:22PM +0200, Olivier Chapuis wrote:
> > BTW, I think that the change Xinerama{Enable,Disable} -> Xinerama
> > is not very good: it is difficult to a configuration tool or a user
> > new to Xinerama to know if Xinerama is enabled or not.
>
> Er, what is the big difference between
>
> XineramaEnable
> XineramaDisable
>
> and
>
> Xinerama on
> Xinerama off
>
> ? It just saves the additional commands. And I can't think of
> any fvwm command that has an "off" and an "on" version.
Iconify on
Iconify off
--
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: * Finished Xinerama support for modules.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/08/11 16:28:18 Modified files: . : todo-xinerama libs : XineramaSupport.c modules: ChangeLog modules/FvwmButtons: FvwmButtons.c modules/FvwmIconMan: FvwmIconMan.1 FvwmIconMan.c FvwmIconMan.h fvwm.c globals.c readconfig.c x.c modules/FvwmIdent: FvwmIdent.c modules/FvwmPager: FvwmPager.c x_pager.c modules/FvwmWinList: FvwmWinList.c FvwmWinList.h Log message: * Finished Xinerama support for modules. * Fixed"transient" option of FvwmPager. * Allow "Transient" as well as "-Transient" in various modules. -- 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: * Updated Xinerama module interface description.
CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by: domivogt01/08/11 03:28:36 Modified files: . : ChangeLog mod_f2m_communication.html Log message: * Updated Xinerama module interface description. -- 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: a naive Xinerama question
> By the way, Matthias, is there anything that has to be done to > make FvwmGtk Xinerama compatible? Well, its been a long time since I last looked at that code... "compatible" is perhaps not the right term here. Any X application should be Xinerama compatible, since after all its just an extension that can be ignored. If you ask for "Xinerama-aware", then the answer would probably be: make gtk+ Xinerama-aware. Which won't happen before gtk+ is extended for multiple screens/displays. Which won't happen before gtk+ 2.2. Matthias -- 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: a naive Xinerama question
By the way, Matthias, is there anything that has to be done to make FvwmGtk Xinerama compatible? 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: a naive Xinerama question
> > 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. All the same reasons why you want to get enter and leave events on the root window in multi-screen scenarios, I guess. Of course, the application with the strongest interest in such information is the window manager, but toolkits could also use it as a low-overhead way to find the necessary information for e.g. restricting menus to be completely onscreen (or rather "onxineramascreen"). In fact, I would thing that enter/leave notification would be a very natural feature and I can't think of any possible reasons for the X Xinerama group to not accept it. Matthias -- 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: a naive Xinerama question
On Thu, Aug 09, 2001 at 09:37:50PM +0700, Dmitry Yu. Bolkhovityanov wrote: > 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. I don't think this can be solved inside fvwm to our satisfaction. Polling the mouse pointer wastes lots of CPU and tracking the pointer via MotionNotify events does not work when the pointer is grabbed. > 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). That would be the right place to implement this functionality. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- 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: 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 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, Aug 08, 2001 at 07:47:03PM +0700, Dmitry Yu. Bolkhovityanov wrote: > 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. > 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. Olivier -- 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: * Place windows on given Xinerama screen; new style option StartsOnScreen
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/08/08 17:13:25 Modified files: . : ChangeLog NEWS todo-xinerama fvwm : add_window.c fvwm.h fvwm2.1 icons.c placement.c placement.h style.c style.h libs : XineramaSupport.c Log message: * Place windows on given Xinerama screen; new style option StartsOnScreen (defaults to 'c'). * Fixed handling of default_screen argument in XineramaSupportParseScreenBit(). * Keep expanded icon titles on screen. * Default icon box fills only the primary 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: 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 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, Aug 07, 2001 at 01:05:22PM +0200, Olivier Chapuis wrote:
> BTW, I think that the change Xinerama{Enable,Disable} -> Xinerama
> is not very good: it is difficult to a configuration tool or a user
> new to Xinerama to know if Xinerama is enabled or not.
Er, what is the big difference between
XineramaEnable
XineramaDisable
and
Xinerama on
Xinerama off
? It just saves the additional commands. And I can't think of
any fvwm command that has an "off" and an "on" version. On the
other hand it makes module configuration a lot easier. Fvwm can
simply send the whole string after "Xinerama" to the module which
in turn passes it to a Xinerama library function to configure
itself. Also, many commands already use the boolean argument
type, so why not this one?
> With
> Xinerama{Enable,Disable} we know where we go as with the Xinerama
> command even an experimented user should try a command or an action
> to see if Xinerama is enabled or not and predict the effect of this
> command.
It almost never makes sense to turn off Xinerama anyway. If there
is only one screen it is a no-op. If you have more than one
screen, not using Xinerama support is a pain. The only situation
I can think of where this is not desirable is with a very big,
tiled screen composed of many monitors, e.g. on a trade fair. In
this case we can expect that the tech people are able to read the
man page.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, email: [EMAIL PROTECTED]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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: 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 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 naive Xinerama question
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?
BTW, I think that the change Xinerama{Enable,Disable} -> Xinerama
is not very good: it is difficult to a configuration tool or a user
new to Xinerama to know if Xinerama is enabled or not. With
Xinerama{Enable,Disable} we know where we go as with the Xinerama
command even an experimented user should try a command or an action
to see if Xinerama is enabled or not and predict the effect of this
command.
Olivier
--
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 support in FvwmRearrange, FvwmIdent and FvwmScroll.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/08/06 17:50:22 Modified files: . : todo-xinerama fvwm : placement.c modules: ChangeLog modules/FvwmIdent: FvwmIdent.c Makefile.am modules/FvwmRearrange: FvwmRearrange.c Makefile.am modules/FvwmScript: FvwmScript.c Makefile.am modules/FvwmScroll: FvwmScroll.c GrabWindow.c Log message: * Added Xinerama support in FvwmRearrange, FvwmIdent and FvwmScroll. -- 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: * Replaced XineRamaEnable/Disable commands with plain "Xinerama".
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/08/05 19:20:36 Modified files: . : ChangeLog NEWS todo-xinerama fvwm : commands.h functions.c functions.h fvwm2.1 move_resize.c move_resize.h virtual.c libs : Makefile.am WinMagic.c XineramaSupport.c XineramaSupport.h fvwmlib.h modules: ChangeLog modules/FvwmButtons: FvwmButtons.c modules/FvwmDragWell: fvwmDragWell.c modules/FvwmForm: FvwmForm.c modules/FvwmIconBox: FvwmIconBox.c modules/FvwmIconMan: fvwm.c readconfig.c modules/FvwmPager: FvwmPager.c FvwmPager.h modules/FvwmTaskBar: FvwmTaskBar.1 FvwmTaskBar.c Goodies.c List.c List.h modules/FvwmWharf: FvwmWharf.c Log message: * Replaced XineRamaEnable/Disable commands with plain "Xinerama". * New commands MoveToScreen. * NewFvwmTaskBar options PageOnly and ScreenOnly. * Full Xinerama support in TaskBar, Pager, IconBox, Wharf. * Xinerama placement in FvwmIconMan. * Fixed Xinerama placement w/ negative geometries. * Fixed button grabbing in FvwmTaskBar. * Fixed negative geometries in FvwmWharf. -- 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: * Updated xinerama to do list.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/08/02 18:08:47 Modified files: . : todo-xinerama Log message: * Updated 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 domivogt: * Added Xinerama support to FvwmButtons and FvwmDragWell.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/08/02 18:06:20 Modified files: . : ChangeLog NEWS todo-xinerama fvwm : fvwm2.1 menus.c style.c virtual.c libs : XineramaSupport.c XineramaSupport.h modules: ChangeLog modules/FvwmBanner: FvwmBanner.c modules/FvwmButtons: FvwmButtons.c FvwmButtons.h Makefile.am parse.c modules/FvwmDragWell: FvwmDragWell.1 Makefile.am fvwmDragWell.c modules/FvwmForm: FvwmForm.1 FvwmForm.c FvwmForm.h modules/FvwmIconBox: FvwmIconBox.c Makefile.am modules/FvwmIconMan: Makefile.am x.c modules/FvwmPager: FvwmPager.c Makefile.am modules/FvwmTaskBar: FvwmTaskBar.c Makefile.am modules/FvwmWharf: FvwmWharf.c Makefile.am modules/FvwmWinList: FvwmWinList.c Makefile.am Log message: * Added Xinerama support to FvwmButtons and FvwmDragWell. * Updated Xinerama support for FvwmBanner and FvwmForm. * Various geometry parsing bug fixes in FvwmButtons, FvwmForm and FvwmDragWell. * Use Xinerama geometry parsing everywhere. * Started to implement Xinerama support in all modules that called XParseGeometry(). * Menu position hint geometry (rectangle) uses Xinerama style geometries. * Same for Icon box geometries. * XineramaEnable command takes the primary screen as its argument. * Fixed button and key event handling over pan frames (bug #752). * Fixed Xinerama placement of menus without options. * Finished XineramaSupportParseGeometry() function. -- 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: * Xinerama / menu placement fix.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/08/02 14:14:51 Modified files: . : ChangeLog fvwm : events.c events.h menus.c virtual.c Log message: * Xinerama / menu placement fix. * Fixed button/key events over pan frames (bug #742). -- 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 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 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 Sun, Jul 29, 2001 at 02:13:56PM +0700, Dmitry Yu. Bolkhovityanov wrote: > 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. Ah, yes, of course. I did not think about this. Bye Dominik ^_^ ^_^ P.S.: Please keep the discussion on the workers list. -- 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: Xinerama w/ EdgeResistance problem
On Sun, Jul 29, 2001 at 02:07:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: > 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. width>screen_width && width 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). I think it's easy to describe what the average user wants: When (s)he move the window to the left (s)he expects that the left edge of the window will be aligned with the left edge of the screen respectively the right edge of other windows. It would also be desirable that a previous alignment with the top/bottom edges is not broken while moving to the left. But (s)he would definitely not expect to align window on the right side. The same applies to all other directions, of course. The problem is that fvwm usually can't guess in which direction the user wants to move a window and mouse input is way too unreliable. At present I am using big values for SnapAttraction (20), SnapGrid (8 8) and EdgeResistance (128) for a screen with quite a few windows and it often causes trouble. 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: 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. width>screen_width && widthhttp://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 13:07, [EMAIL PROTECTED] wrote:
> > > - 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.
>
> Ah, okay. The solution to both problems is the module interface.
> Some settings like "Colorset" are communicated to the modules over
> the module pipe. The state of Xinerama{En,Dis}abled can be easily
> communicated too. In fact I have already done this. Take a look
> at the code in virtual.c:
>
> void CMD_XineramaDisable(F_CMD_ARGS)
> {
> XineramaSupportDisable();
> BroadcastConfigInfoString("XineramaDisable");
> }
>
> Any module listening for M_CONFIG_INFO packets will receive the
> string "XineramaDisable" when the function is called an can react
> properly. I think I still forgot to send this string when the
> module is initially started, so the module's Xinerama state may
> not match fvwm's state at first. I will take care of this.
>
> Any program that wants to communicate to fvwm tightly should be
> written as an fvwm module. Another way would be to communicate
> via FvwmCommand, but that is inefficient and littl internal
> information about fvwm's state it communicated this way.
>
> > 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.
The problem of other programs remain -- they should *not* communicate to
fvwm, they should work with *any* WM. In fact, the problem here is lack
of X.org specification. IMHO the natural way will be to use a root window
property -- like _XINERAMA_PRIMARY_SCREEN. In that case any program could
request notification of property's change. This isn't urgent, but AFAIK
nobody have done something in this area yet, so if we do, this can become a
standard.
[SNIP]
> > > - 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.
> > ;-)
>
> Let me explain why I commented it (actually, commenting it made a
> huge, big mess of XineramaSupport.c): The risk that new problems
> are introduced in the *stable* 2.4.1 release has to be minimised.
Can you please explain about a mess? If I did something too interveawed
with other code, I need to know :-).
> > > 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.
>
> Well, then let's split up the function. XiParseGeometry() does
> exactly what XParseGeometry() does but with the additional
> "@" parsing. Another function could take its output as
> input and do the additiona
Re: Xinerama merger -- part 1
On Sat, Jul 28, 2001 at 09:42:42PM +0700, Dmitry Yu. Bolkhovityanov wrote:
Content-Description: Mail message body
> On 28 Jul 01 at 13:07, [EMAIL PROTECTED] wrote:
>
> > > > - 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.
> >
> > Ah, okay. The solution to both problems is the module interface.
> > Some settings like "Colorset" are communicated to the modules over
> > the module pipe. The state of Xinerama{En,Dis}abled can be easily
> > communicated too. In fact I have already done this. Take a look
> > at the code in virtual.c:
> >
> > void CMD_XineramaDisable(F_CMD_ARGS)
> > {
> > XineramaSupportDisable();
> > BroadcastConfigInfoString("XineramaDisable");
> > }
> >
> > Any module listening for M_CONFIG_INFO packets will receive the
> > string "XineramaDisable" when the function is called an can react
> > properly. I think I still forgot to send this string when the
> > module is initially started, so the module's Xinerama state may
> > not match fvwm's state at first. I will take care of this.
> >
> > Any program that wants to communicate to fvwm tightly should be
> > written as an fvwm module. Another way would be to communicate
> > via FvwmCommand, but that is inefficient and littl internal
> > information about fvwm's state it communicated this way.
> >
> > > 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.
>
> The problem of other programs remain -- they should *not* communicate to
> fvwm, they should work with *any* WM. In fact, the problem here is lack
> of X.org specification. IMHO the natural way will be to use a root window
> property -- like _XINERAMA_PRIMARY_SCREEN. In that case any program could
> request notification of property's change. This isn't urgent, but AFAIK
> nobody have done something in this area yet, so if we do, this can become a
> standard.
Writing a standard for this would clearly be something that should
go into the "Enhanced Window Manager Hints" spec. In any case,
it's much better to do it as a root window property. But I since
nobody is writing applications especially for fvwm, any property
we define would not be used anyway.
> > Well, then let's split up the function. XiParseGeometry() does
> > exactly what XParseGeometry() does but with the additional
> > "@" parsing. Another function could take its output as
> > input and do the additional calculations. Or if that won't work,
> > there should at least be an alias of the function that can be
> > called like XParseGeometry().
>
> Okay, lets do int XiParseGeometry(char *str, int *{x,y,w,h,scr}) and
> XiGetGeometry(), which will do the actual calculations. The thing is that
> "screen" parameter is not very useful outside XineramaSupport.c, since list
> of screens shouldn't be visible outside.
No, it shouldn't be visible outside. Don't return it through the
interface. If you want a function that returns more than x/y/w/h,
don't call it ...ParseGeometry(). This will just be confusing. As
far as I can see the knowledge of the screen is not needed
awterwards. If you need that information to call another
function, you can write an internal variant of the
...ParseGeometry() function that returns screen numbers too. Then
call it from your XiWMGeometry() function and from
XiParseGeometry(). But you should not change standard interfaces.
> The patch is attached (I'm very-very sorry for uppercase, that's my
> Pegasus Mail for Dos ;-).
Eeeek!
> It is cvs diff -u (similar-looking functions made
> diff slightly insane, so the patch layout looks a bit inoptimal).
Don't care
> ...
> 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.
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: * Rewrote module interface for Xinerama support.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/07/28 18:59:10 Modified files: . : ChangeLog todo-xinerama fvwm : modconf.c module_interface.c libs : XineramaSupport.c XineramaSupport.h defaults.h modules: ChangeLog modules/FvwmBanner: FvwmBanner.c Makefile.am modules/FvwmForm: FvwmForm.c Log message: * Rewrote module interface for Xinerama support. * Adapted FvwmForm to new interface. * FvwmBanner uses 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]
Xinerama w/ EdgeResistance problem
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 (?) 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: * Fix for snapping at Xinerama screen edges.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/07/28 10:53:33 Modified files: . : ChangeLog fvwm : move_resize.c libs : XineramaSupport.c Log message: * Fix for snapping at Xinerama screen edges. -- 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 merger -- part 1
On Fri, Jul 27, 2001 at 09:35:49PM +0700, Dmitry Yu. Bolkhovityanov wrote:
> 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.
Ah, okay. The solution to both problems is the module interface.
Some settings like "Colorset" are communicated to the modules over
the module pipe. The state of Xinerama{En,Dis}abled can be easily
communicated too. In fact I have already done this. Take a look
at the code in virtual.c:
void CMD_XineramaDisable(F_CMD_ARGS)
{
XineramaSupportDisable();
BroadcastConfigInfoString("XineramaDisable");
}
Any module listening for M_CONFIG_INFO packets will receive the
string "XineramaDisable" when the function is called an can react
properly. I think I still forgot to send this string when the
module is initially started, so the module's Xinerama state may
not match fvwm's state at first. I will take care of this.
Any program that wants to communicate to fvwm tightly should be
written as an fvwm module. Another way would be to communicate
via FvwmCommand, but that is inefficient and littl internal
information about fvwm's state it communicated this way.
> 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.
Another one of the things that nobody has the time and leisure to
do. The common practice is that everybody formats his code pieces
as he likes. Whenever one of the more active developers works a
lot with a certain piece of code (mostly me) he is free to
reformat that code as he likes. I think there would be a lot of
potential for an extensive religios war about brace, whitepace and
comment placement if we really tried to write something down :-)
> > - 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.
> ;-)
Let me explain why I commented it (actually, commenting it made a
huge, big mess of XineramaSupport.c): The risk that new problems
are introduced in the *stable* 2.4.1 release has to be minimised.
> > 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).
>
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 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: * More Xinerama patch changes.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/07/27 04:58:23 Modified files: libs : XineramaSupport.c Log message: * More Xinerama patch changes. -- 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 merger -- part 1
On Thu, Jul 26, 2001 at 05:43:39PM +0700, Dmitry Yu. Bolkhovityanov wrote:
Content-Description: Mail message body
> 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?
I just took the time to start merging the patch. Please try to
write code keeping this in mind:
- 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").
- 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).
- 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.
- 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.
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.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, email: [EMAIL PROTECTED]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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: * Applied next Xinerama patch with some modifications, commented out a lot of
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/07/27 04:55:15 Modified files: . : ChangeLog libs : XineramaSupport.c XineramaSupport.h Log message: * Applied next Xinerama patch with some modifications, commented out a lot of stuff (code duplication, randr, env variables ...). -- 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 merger -- part 1
On Thu, Jul 26, 2001 at 05:43:39PM +0700, Dmitry Yu. Bolkhovityanov wrote:
Content-Description: Mail message body
> 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).
I will start applying your patches as soon as possible. Since my
mother pays me a visit this weekend I can't promise that I'll have
the time.
> 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?
Yes. I did not understand this logic and I did not want that the
interface of XiSetState() was visible outside the module because
it has an interface that can be called in a way that would crash
fvwm later. I think a simple on/off call is enough. Also, it is
more flexible if you can't disable Xinerama support completely.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, email: [EMAIL PROTECTED]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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 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
Re: Solaris Xinerama
On Wed, Jul 25, 2001 at 11:04:43AM -0400, Dan Espen wrote: > > Sun had a habit of shipping various libraries and utilities in separate > > optional packages, so... Anyway, > > > > find / | egrep -i 'xinerama|panoramix' > > A find like that would run for months on our file systems, For installed Solaris packages (assuming you haven't messed with the installation), you can run that grep on /var/sadm/install/contents. I find that to be incredibly useful. Nothing turns up in the filesystem, but /usr/openwin/bin% nm Xsun | grep -i xinerama [5176] |702552| 60|FUNC |GLOB |0|9 |ForceXineramaApiImport [1661] |934356| 384|FUNC |LOCL |0|9 |ProcXineramaGetInfo [1535] |887704| 384|FUNC |LOCL |0|9 |ProcXineramaInfo [4029] |935088|1648|FUNC |GLOB |0|9 |XineramaGetImageData [4787] |973208| 128|FUNC |GLOB |0|9 |XineramaGetScreenList [5303] |973336| 44|FUNC |GLOB |0|9 |XineramaGetXIDList [3102] |973160| 48|FUNC |GLOB |0|9 |isXineramaScreen [1684] | 0| 0|FILE |LOCL |0|ABS|xinerama_api.c /usr/openwin/lib% nm -A *.so | grep -i xinerama libXext.so: [428] | 80156| 404|FUNC |GLOB |0|10 |XGetXineramaInfo libXext.so: [383] | 80576| 704|FUNC |GLOB |0|10 |XineramaGetCenterHint libXext.so: [277] | 79688| 468|FUNC |GLOB |0|10 |XineramaGetInfo libXext.so: [395] | 79616| 72|FUNC |GLOB |0|10 |XineramaGetState libdga.so: [256]| 29548| 380|FUNC |GLOB |0|10 |XDgaGetXineramaInfo Doesn't look like there are any mentions of it in any header files, though, so you'd have to provide the declarations yourself. HTH, Danek -- 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: 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 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 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
"Dmitry Yu. Bolkhovityanov" <[EMAIL PROTECTED]> writes:
> 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?
Not right now.
> Or simply do xdpyinfo on Solaris box and look if XINERAMA is
> present in the list of extensions.
That I can do:
name of display::0.0
version number:11.0
vendor string:Sun Microsystems, Inc.
vendor release number:6410
maximum request size: 262140 bytes
motion buffer size: 256
bitmap unit, bit order, padding:32, MSBFirst, 32
image byte order:MSBFirst
number of supported pixmap formats:4
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
keycode range:minimum 8, maximum 132
focus: window 0x141, revert to Parent
number of extensions:28
AccessX
Adobe-DPS-Extension
DOUBLE-BUFFER
DPMS
DPSExtension
Extended-Visual-Information
FBPM
LBX
MIT-SCREEN-SAVER
MIT-SHM
MIT-SUNDRY-NONSTANDARD
Multi-Buffering
RECORD
SECURITY
SHAPE
SUN_ALLPLANES
SUN_DGA
SUN_OVL
SUN_SME
SYNC
SolarisIA
TOG-CUP
XC-APPGROUP
XC-MISC
XIE
XInputDeviceEvents
XInputExtension
XTEST
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.
I'm not at work so I can't do that right now.
> 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).
A find like that would run for months on our file systems,
even if I pruned out the 11 .snapshot subdirectories from our
NetApp filers.
Running it against /usr/openwin turns up nothing.
> > 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
> BTW, official X.org's R6.5.1 (or whatever is current) is a good place to
> look at, I'll do it.
--
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: 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 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]
Solaris Xinerama
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. I don't know if there is some other way to detect Xinerama. I didn't see anything obvious in libs/XineramaSupport.c. Perhaps the man page should identify this as an XFree86 only feature. -- 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: * Reduce number of XQueryPointer calls in move/resize lopps w/ Xinerama.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/07/24 19:18:19 Modified files: . : ChangeLog NEWS todo-xinerama fvwm : builtins.c fvwm.c move_resize.c move_resize.h virtual.c libs : XineramaSupport.c XineramaSupport.h defaults.h modules: ChangeLog modules/FvwmForm: FvwmForm.c Log message: * Reduce number of XQueryPointer calls in move/resize lopps w/ Xinerama. * Fixed a problem that could cause windows to be lost off screen with interactive window motion. * Moved some constants to libs/defaults.h * Reworked calculation of the geometry window size. * Grid outline is deleted before moving the geometry window to a new place. * Changed the interface of the MoveOutline stuff. * Fixed resizing geometry window before creating it. -- 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 patch -- v2
On Tue, Jul 24, 2001 at 09:48:02PM +0700, Dmitry Yu. Bolkhovityanov wrote: > 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 ;-) Okay, then you should do it. I and Olivier already made some changes to the libs/Xinerama... files. If you spent any time patching menus.c, don't include it in the patch but instead make a separate patch with a description of the changes. I will then do all the work in the menu code. > -- 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. If you actively develop code, the best way ist to always keep up to date with CVS always. The conflicts are much easier to resolve at the moment they occur. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- 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 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 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: * Make the blank area in Xinerama emulation usable again.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/07/23 17:38:29 Modified files: . : ChangeLog todo-xinerama fvwm : menus.c menus.h windowlist.c libs : XineramaSupport.c Log message: * Make the blank area in Xinerama emulation usable again. * Menus are resized properly to adapt to the Xinerama screen they use. -- 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 olicha: * Draw the xinerama simulation screens with some orr windows
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: olicha 01/07/23 15:23:02 Modified files: libs : XineramaSupport.c . : ChangeLog Log message: * Draw the xinerama simulation screens with some orr windows -- 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 patch -- v2
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 ;-) Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- 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 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: 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 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
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 mak
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]
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]
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]
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: 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]
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]
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]
Re: CVS domivogt: * First version of Xinerama support.
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... I don't have any real hardware xinerama setup, but X supports it. 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: added xinerama support
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: migo01/07/21 19:58:28 Modified files: . : configure.in utils : ChangeLog fvwm-config.in Log message: added 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: * First version of Xinerama support.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/07/21 14:29:27 Modified files: . : ChangeLog NEWS configure.in fvwm : Makefile.am builtins.c functions.c functions.h fvwm.c fvwm2.1 menus.c move_resize.c move_resize.h screen.h virtual.c virtual.h libs : Makefile.am defaults.h modules/FvwmForm: FvwmForm.c Makefile.am tests/menus: menus.read Log message: * First version of Xinerama support. * Reformatted man page suorce to improve readability. -- 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: * Set development version to 2.4.0.1 (for xinerama support in 2.4.1).
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/07/01 10:57:22 Modified files: . : ChangeLog NEWS configure.in Log message: * Set development version to 2.4.0.1 (for xinerama support in 2.4.1). -- 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]
