Re: Deprecation: Let's talk once more about removing $STUFF...
> > I still have FvwmWinList on a button in case I get some rogue window > > that FvwmProxy doesn't represent, but, honestly, it isn't a big deal. > I'd consider that a bug in FvwmProxy, in which case, please fix it. > FvwmWinList is going the way of the Dodo... I think "suppression" is a better description than "bug". Right now, I can see that I have no proxy for conky, gnome-panel, and FvwmPager. I think it is because they are sticky. You can also turn off proxies for all iconified windows. I don't know why you would want to, so I guessing that was a feature request. FvwmPager and FvwmProxy are the only modules I use all the time.
Re: Deprecation: Let's talk once more about removing $STUFF...
> I'll leave CPP and M4 for now as I'd like to try something with them. Is there something we're supposed to be using to replace FvwmM4? I set it up in my .fvwm2rc 25 years ago and it seems to still be working fine. As far as I recall, it is just include(), define(), ifdef(), and ifelse(). Also, I am quietly watching to make sure you don't mention any module I am critically dependent on. We are still out here even when we're silent. If you are about to remove something or make a substantial change, just make sure to use an appropriately provocative subject line. I still have FvwmWinList on a button in case I get some rogue window that FvwmProxy doesn't represent, but, honestly, it isn't a big deal.
Re: windows deserve walls
On Wed, Dec 1, 2010 at 4:52 PM, Thomas Adam wrote: > Hi -- > > On Tue, Nov 30, 2010 at 05:44:28PM -0800, Jason Weber wrote: >> On Sun, Nov 28, 2010 at 5:37 AM, Thomas Adam wrote: >> > Hi -- >> > >> > On Mon, Nov 22, 2010 at 11:44:56PM -0800, Jason Weber wrote: >> >> Screen Edge Avoidance >> >> - >> >> Screen edges now repel proxies. In reasonable situations, >> >> proxies will never be pushed off screen. >> > >> > This sounds like a bug-fix to me? Or is this so in-grained with everything >> > else. separating this out isn't possible? >> >> It probably could be separated out. The current diff is rather large, >> so it just means sifting through all that to pick out a few changes. > > Ok. Can you do that? Yes, I should try. >> FlickeringMoveWorkaround is boolean and removes all those in-motion events. >> The ConfigureSkipLimit can just reduce the number of configure events, >> such as every sixteenth one and also whenever the event stream goes idle. > > It only removes sending repeated ConfigureNotify events (there are no other > "in-motion events" to speak of here). Why is a threshold value needed here, > and how would in interaction of such a BugOpts setting affect FvwmProxy? > This still seems very odd to me. > > Why do you think this is needed -- I mean, what problem is this solving? > > -- Thomas Adam Ok, when you move windows around, proxies (when shown) will drag along with them. Now with four walls, you have five windows to drag along instead of one. And the windows that aren't moving still need refresh more with the always-on-top proxies and walls. If you get a Configure for nearly every pixel step, that can put a heavy load of redraws in the pipe and it can even take a couple seconds of lag time to catch up even after you've stopped any movement (it seems more sluggish on my faster RedHat work machine than my home Ubuntu machine, but there are probably too many details to figure out why they are different). If I ignore all but every 16th configure, it still has fully responsive primary window motion and I get decent (adjustably stuttering) feedback for the moving walls and proxies. Essentially, if you turn on walls and you are configured to show all the proxies, then showing proxies will temporarily multiply your mapped window count for the current desk by 6. With 10 to 15 windows per desk, that number can get pretty big. Would using FlickeringMoveWorkaround mean I don't get any redraws until the move is complete? I still get all the primary window redraws which seem really quick. ConfigureSkipLimit only affects the proxy and wall windows. -- Jason Weber
Re: windows deserve walls
On Sun, Nov 28, 2010 at 5:37 AM, Thomas Adam wrote:
> Hi --
>
> On Mon, Nov 22, 2010 at 11:44:56PM -0800, Jason Weber wrote:
>> Screen Edge Avoidance
>> -
>> Screen edges now repel proxies. In reasonable situations,
>> proxies will never be pushed off screen.
>
> This sounds like a bug-fix to me? Or is this so in-grained with everything
> else. separating this out isn't possible?
It probably could be separated out. The current diff is rather large,
so it just means sifting through all that to pick out a few changes.
>> Configure Skip Limit
>>
>> To optimize performance, repeated configure events to the same
>> window can be reduced. If non-zero, ConfigureSkipLimit will
>> ignore repeated configure events up to the number given.
>> If another window receives and event, or the limit is reached,
>> or the event buffer becomes empty, the last ignored configure
>> event is recalled and processed as normal.
>
> Hmm -- this should work in the same way as "BugOpts FlickingMoveWorkaround"
> does. I find it very odd exposing some limit in this way as a configuration
> option.
>
> -- Thomas Adam
>
> --
> "Deep in my heart I wish I was wrong. But deep in my heart I know I am
> not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
FlickeringMoveWorkaround is boolean and removes all those in-motion events.
The ConfigureSkipLimit can just reduce the number of configure events,
such as every sixteenth one and also whenever the event stream goes idle.
-- Jason Weber
windows deserve walls
Release Notes for FvwmProxy - pending Walls - Windows can now display walls using the directive *FvwmProxy: ShowWalls True Walls appear when proxies are shown. They are drawn as colored boxes just inside the window borders. Walls for grouped windows are drawn with the same color as the group. Other walls are drawn in white. Walls are surrounded by a black border. Selected proxies are highlighted by a thick black centerline. Focused proxies are highlighted by using a thicker color bar. This can help in determining which set of four walls is associated with each proxy. A quick brush of the mouse pointer across a proxy gives a quick flash that is generally adequate to bring attention to its walls. The dimensions of walls relative to each window can be adjusted with WallThickness, WallShrink, WallRecede, WallInsetFocus, WallInsetNormal, and WallInsetSelect. Proxy Window Colors --- Each proxy grouping rule can have a unique Colorset. The general proxy colorset is now the default. The colorsets for selected and iconified windows take precedence when a window is in one of those states. Any proxy rule can be set to Disjoint which stops automatic grouping but still allows specification of colors. Proxy Occupation The proxy group colors currently in use are now shown in every other proxy as a smaller highlighted box inside the faded full size box. Switch All -- Pressing the right mouse button on a proxy slot will change all windows in the same group. Pressing a window's current group color will ungroup the entire group. Pressing a different color from the current color simply switches the entire group. If the other color is already occupied, the groups will be merged. Screen Edge Avoidance - Screen edges now repel proxies. In reasonable situations, proxies will never be pushed off screen. Connection Checking --- In addition to the provocation prefixes No and Inherit, the Connect prefix can be used to only act between windows that are touching or overlapping. Solitary Windows The SolitaryToggle command can activate a mode to prevent auto-grouping. A solitary window loses its faded group colors and shows the proxy window background through all the slots. The AutoSolitary flag for a proxy rule will start any window under that rule as solitary. Inter-Process Auto Grouping --- Windows of different processes can now be automatically grouped in a variety of ways. The AutoStick flag will instruct windows of different processes matching that same proxy rule to join together if their edges ever touch. The AutoIsolate will similarly join and also trigger isolation if to windows are co-located with the four edges aligned. Both of these commands also help to preserve manually arranged groups during a window manager reset. It is probably unlikely that AutoIsolate will be triggered except during an window manager reset. Windows can be protected from auto-grouping be setting them to solitary. It is recommended that SolitaryToggle be assigned to a proxy command slot, perhaps an an alternate mouse button to any existing command slot, such as a right click on an IsolateToggle button that previously just watched for a left click. Edge Matching - The AutoEdge flag for a proxy rule will attempt to grow a window as it joins a group using AutoStick. This process tries to match the edge of the window to where it just got stuck. It will not expand over top of any window in that group. Configure Skip Limit To optimize performance, repeated configure events to the same window can be reduced. If non-zero, ConfigureSkipLimit will ignore repeated configure events up to the number given. If another window receives and event, or the limit is reached, or the event buffer becomes empty, the last ignored configure event is recalled and processed as normal. <>
Re: FvwmProxy update pending
On Mon, Nov 22, 2010 at 5:12 PM, Thomas Adam wrote:
> On Mon, Nov 22, 2010 at 04:31:51PM -0800, Jason Weber wrote:
>> Well, I think the postponed E7 is fixed in the mentioned update.
>
> OK. That sounds good.
>
>> The screen edges now produce collisions, so a bunched up group of windows
>> near a screen edge will get their proxies pushed inwards.
>>
>> I'll should go ahead and write up a page on the update.
>> There is a whole new concept that will be introduced.
>>
>> Is there an interest in any workers getting a preview in binary,
>> source, or patch?
>
> Yes, sure. As I mentioned before, patches I am happy to look at. But
> introducing new functionality, I am not interested in, because that's
> radically changing the state of something which has been declared as
> "working"; confer bug-fixes.
>
> -- Thomas Adam
>
> --
> "Deep in my heart I wish I was wrong. But deep in my heart I know I am
> not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
I was hoping to see if anyone who was already using the existing FvwmProxy
wanted to test the newer version. I've been using it for quite a
while, but there
are sure to be a variety of configs that will challenge differing aspects.
I didn't specifically intend to distract you from what you are working on.
-- Jason Weber
Re: FvwmProxy update pending
On Fri, Nov 19, 2010 at 7:57 AM, Thomas Adam wrote: > On Fri, Nov 19, 2010 at 07:50:27AM -0800, Jason Weber wrote: >> It seems that I should wait. When should we expect the dev cycle to get >> to new features again? > > When 2.6.0 is released. See "Section A" in the following: > > https://github.com/ThomasAdam/fvwm/blob/master/docs/todo-2.6 > > When that is done, then who knows? Note that for a lot longer than I've > really been pedalling this concept, we've been in a feature freeze a lot > longer than this policy has been strictly enforced. It's just that now > we're so much closer to attaining 2.6.0, enforcing this *now* is a lot > easier. > > So please, hold off. And by all means help out with things under section A. > :) > > -- Thomas Adam > > Well, I think the postponed E7 is fixed in the mentioned update. The screen edges now produce collisions, so a bunched up group of windows near a screen edge will get their proxies pushed inwards. I'll should go ahead and write up a page on the update. There is a whole new concept that will be introduced. Is there an interest in any workers getting a preview in binary, source, or patch? -- Jason Weber
Re: FvwmProxy update pending
On Fri, Nov 19, 2010 at 5:26 AM, Thomas Adam wrote: > Hi Jason -- > > On Thu, Nov 18, 2010 at 08:55:24PM -0800, Jason Weber wrote: >> I've got a substantial feature set update to FvwmProxy about ready to check >> in. > > Hmm -- are they bug-fixes? We're in a feature freeze, Jason, and I am > really anal/crabby/disinterested/against any form of changes which introduce > features right now. > >> I've tried to avoid C++ syntax and the like, but there will probably >> be a few compile issues >> that don't show up on my Linux build. > > How are you compiling this? --std-c89 and the like? > >> Is this a good time? > > Possibly. Can you email out your patches for cursory review so that I (and > others) can perhaps protect any obvious errors before they break anything? > That way, I can also tell you if what you're proposing to update are > features. ;) > > -- Thomas Adam The update is pretty much entirely new features, although a few things might be considered refinements. I just call make. I don't think it is restrained to C by the default config. It seems that I should wait. When should we expect the dev cycle to get to new features again? -- Jason Weber
FvwmProxy update pending
I've got a substantial feature set update to FvwmProxy about ready to check in. I've tried to avoid C++ syntax and the like, but there will probably be a few compile issues that don't show up on my Linux build. Is this a good time? -- Jason Weber
physical screen boundaries
How would a module determine the boundaries between physical screens? EdgeMoveResistance snapping seems to know about it, so the data is in there somewhere. For example, if I have two monitors 1600x1200 and 1920x1200, querying X11 about the screen dimensions seems to give me the full 3520x1200. I'd like to know about the implicit barrier at x=1600. -- Jason Weber
Re: FvwmProxy Group AutoInclude does not work
On Tue, Jun 23, 2009 at 11:54 AM, Manoj Srivastava wrote: > Hi, > > This was reported by a Debian user. Please retain > 426222-forwar...@bugs.debian.org in your responses, so that the Debian > BTS may have a copy of your response. > > Version: 2.5.21 to current > > utomatic grouping of windows with FvwmProxy (a rather new feature I > wanted to try) does not work. Manual grouping works, though. > > You can try: > > killall FvwmProxy > > Then paste into FvwmConsole: > > DestroyModuleConfig FvwmProxy: * > *FvwmProxy: Width 250 > *FvwmProxy: Height 140 > *FvwmProxy: ShowMiniIcons true > *FvwmProxy: EnterSelect true > *FvwmProxy: ProxyMove true > *FvwmProxy: ProxyIconified true > *FvwmProxy: Action Click2 Move > *FvwmProxy: Action ModifierRelease 4M SendToModule FvwmProxy Hide > > *FvwmProxy: Group "Gimp" Include "Gimp" > *FvwmProxy: Group "Gimp" AutoInclude > Module FvwmProxy > > Windows matching "Gimp" will not be grouped automatically (they don't > move/iconify in unison and the edges are not glued together as they do > when they are grouped manually by selecting a coloured group). > > > Thanks, > > Manoj > -- > Ralph's Observation: It is a mistake to let any mechanical object > realise that you are in a hurry. > Manoj Srivastava <http://www.golden-gryphon.com/> > 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C Group name matching works like Style commands. In this case, I think the current main window is called "The GIMP". Use 'xprop' and look for the WM_NAME. I think WM_CLASS also works. So try: Include "The GIMP" or some pattern like "*GIMP*". The pattern might help if they change the title later, but you risk having a name collision with something you didn't expect. I don't really use GIMP very much, but this is my current setup: *FvwmProxy: Group "GIMP" SoftInclude "The GIMP" *FvwmProxy: Group "GIMP" SoftInclude "Module Manager" *FvwmProxy: Group "GIMP" SoftInclude "Unit Editor" *FvwmProxy: Group "GIMP" AutoInclude *FvwmProxy: Group "GIMP" AutoSoft *FvwmProxy: Group "GIMP" Exclude "Preferences" Hard inclusion seemed annoying for all the little config windows, so I went all soft. I think that makes my second and third lines redundant, but I keep things around to remember window names. Perhaps you have an old man page. The current CVS one use "The GIMP" in the example. The most recent version has fine tuning of the individual behaviors as well as an option for weak inclusion that helps alleviate name collisions with common titles. My latest thought is to be able to allow stickiness in the vertical and horizontal to be activated independently. I often have columns of shells where I wouldn't want to the horizontal separators catching each other. It might also be nice to have multiple isolated groups stick together, but I'm not sure what sort of UI would allow that to be intuitive. -- Jason Weber
Re: CVS jpweber: FvwmProxy new features
Sorry, proxy labels are replaced stacking order index as a debug. I'll fix that tonight. -- Jason Weber On Mon, May 25, 2009 at 12:10 PM, FVWM CVS wrote: > CVSROOT: /home/cvs/fvwm > Module name: fvwm > Changes by: jpweber 09/05/25 14:10:31 > > Modified files: > modules : ChangeLog > modules/FvwmProxy: FvwmProxy.1.in FvwmProxy.c FvwmProxy.h > > Log message: > FvwmProxy new features > > >
Re: XRestackWindows
On Sun, Apr 19, 2009 at 3:44 PM, Jason Weber wrote: > On Sun, Apr 19, 2009 at 7:40 AM, Thomas Adam wrote: >> 2009/4/17 Jason Weber : >>> Attached in function Restack(). Work in progress, etc. >>> >>> -- Jason Weber >>> >>> On Fri, Apr 17, 2009 at 10:30 AM, Thomas Adam >>> wrote: >>>> 2009/4/17 Jason Weber : >>>>> I've been trying to switch series of XRaiseWindow/XLowerWindow calls >>>>> to a singular XRestackWindows, >>>>> but it doesn't seem to have any affect. I send it an array of Window >>>>> values. >>>>> It just responds with a bunch of: >>>>> >>>>> non-fatal X error as follows, display 0xe8e500 op 12:0 >>>>> "X_ConfigureWindow" serial 183 error 8 >> >> So I added the following debug: >> >> @@ -703,6 +734,8 @@ >> error_event->request_code,error_event->minor_code, >> function,(unsigned int)error_event->serial, >> error_event->error_code); >> + if( error_event->error_code == BadMatch && >> error_event->request_code == X_ConfigureWindow ) >> + fprintf(stderr, "BadMatch Raised! This shouldn't >> happen!\n"); >> >> >> ... to FvwmProxy.c:myXErrorHandler(). From the XRestackWindows man >> page (and my dusted-off XLib programmers' reference manual): >> >> You seem to be hitting the BadMatch error which suggests that the >> window specified aren't a sibling of one another. Coupled with the >> fact you're only receiving ConfigureNotify requests with this >> condition suggests that: >> >> If the override-redirect attribute of a window is False and some >> other client has selected SubstructureRedirectMask on the parent, the X >> server generates ConfigureRequest events for each window whose >> override-redirect flag is not set, and no further processing is >> performed. Otherwise, the windows will be restacked in top-to-bottom >> order. >> >> >> I am not sure who's at fault here -- I suspect FVWM is to blame. >> >> -- Thomas Adam >> >> > > I got a similar impression from the man pages, but those also implied that > the singular raise/lower requests would be similarly intercepted. However, > they seem to go through fine. > > As I understand, the primary windows are all children of the root, > so they are all siblings, but maybe restack only works on subwindows. > In FvwmPager, it seems to be used only for the little mini-windows it owns. > > Any ideas for an alternative method or a way we can evaluate this further? > > Is there a way to probe these masks on windows? I don't see it on xprop. > > -- Jason Weber > I've given up on the XRestackWindows and wrote my own restack that compares the current and desired stacks and sends out a bunch of raise/lower calls. It's similar to what I had before, but now it cares about retaining the order within window groups. I'll run it locally for a while before checking in. I've implemented a better proxy shifting algorithm that should tend to nicely vertically center proxies of coincident windows (like in isolated "tab" mode) instead of running them off them bottom of the screen. I also added a ShowOnly option to reduce the number of proxies shown, All (default), Active, Cover, and Group. Active just shows the active proxy (the active window is not always the focused window). Cover mode adds proxies that overlap the active window. Just using Active mode can result in untouchable proxies. Group mode supersets Cover mode, showing proxies of windows in the same window group as the active window. Where are we in the Fvwm release cycle? Is this a good time for introducing new features? -- Jason Weber
Re: XRestackWindows
On Sun, Apr 19, 2009 at 7:40 AM, Thomas Adam wrote: > 2009/4/17 Jason Weber : >> Attached in function Restack(). Work in progress, etc. >> >> -- Jason Weber >> >> On Fri, Apr 17, 2009 at 10:30 AM, Thomas Adam >> wrote: >>> 2009/4/17 Jason Weber : >>>> I've been trying to switch series of XRaiseWindow/XLowerWindow calls >>>> to a singular XRestackWindows, >>>> but it doesn't seem to have any affect. I send it an array of Window >>>> values. >>>> It just responds with a bunch of: >>>> >>>> non-fatal X error as follows, display 0xe8e500 op 12:0 >>>> "X_ConfigureWindow" serial 183 error 8 > > So I added the following debug: > > @@ -703,6 +734,8 @@ > error_event->request_code,error_event->minor_code, > function,(unsigned int)error_event->serial, > error_event->error_code); > + if( error_event->error_code == BadMatch && > error_event->request_code == X_ConfigureWindow ) > + fprintf(stderr, "BadMatch Raised! This shouldn't happen!\n"); > > > ... to FvwmProxy.c:myXErrorHandler(). From the XRestackWindows man > page (and my dusted-off XLib programmers' reference manual): > > You seem to be hitting the BadMatch error which suggests that the > window specified aren't a sibling of one another. Coupled with the > fact you're only receiving ConfigureNotify requests with this > condition suggests that: > > If the override-redirect attribute of a window is False and some > other client has selected SubstructureRedirectMask on the parent, the X > server generates ConfigureRequest events for each window whose > override-redirect flag is not set, and no further processing is > performed. Otherwise, the windows will be restacked in top-to-bottom > order. > > > I am not sure who's at fault here -- I suspect FVWM is to blame. > > -- Thomas Adam > > I got a similar impression from the man pages, but those also implied that the singular raise/lower requests would be similarly intercepted. However, they seem to go through fine. As I understand, the primary windows are all children of the root, so they are all siblings, but maybe restack only works on subwindows. In FvwmPager, it seems to be used only for the little mini-windows it owns. Any ideas for an alternative method or a way we can evaluate this further? Is there a way to probe these masks on windows? I don't see it on xprop. -- Jason Weber
XRestackWindows
I've been trying to switch series of XRaiseWindow/XLowerWindow calls to a singular XRestackWindows, but it doesn't seem to have any affect. I send it an array of Window values. It just responds with a bunch of: non-fatal X error as follows, display 0xe8e500 op 12:0 "X_ConfigureWindow" serial 183 error 8 non-fatal X error as follows, display 0xe8e500 op 12:0 "X_ConfigureWindow" serial 184 error 8 non-fatal X error as follows, display 0xe8e500 op 12:0 "X_ConfigureWindow" serial 185 error 8 non-fatal X error as follows, display 0xe8e500 op 12:0 "X_ConfigureWindow" serial 186 error 8 non-fatal X error as follows, display 0xe8e500 op 12:0 "X_ConfigureWindow" serial 187 error 8 What is a best way to change order of a bunch of windows at once? -- Jason Weber
Re: FvwmProxy keyboard handling
On Tue, Mar 17, 2009 at 7:56 AM, Jason Weber wrote: > On Tue, Mar 17, 2009 at 2:01 AM, Dominik Vogt wrote: >> On Mon, Mar 16, 2009 at 11:36:33PM -0700, Jason Weber wrote: >>> On Mon, Mar 16, 2009 at 3:34 PM, Dominik Vogt wrote: >>> > On Sun, Mar 15, 2009 at 06:08:19PM -0700, Jason Weber wrote: >>> > [snip] >>> >> > 1. Key polling >>> >> > >>> >> > I'm not completely sure what the current code does. I assume the >>> >> > keyboard map is polled every time an event occurs. However, there >>> >> > may be a possibility that the keyboard map changed but no event >>> >> > occurs. >>> >> > >>> >> > Earlier versions polled at a regular interval, which was >>> >> > inacceptable. >>> >> > >>> >> > We have to test this: >>> >> > >>> >> > * Invoke FvwmProxy by pressing a modifier key and configure it to >>> >> > terminate when the key is released. >>> >> > * Don't touch the mouse from now and make sure that no events >>> >> > occur that effect FvwmProxy. >>> >> > * Open a menu with the keyboard; fvwm grabs the keyboard. Make >>> >> > sure that the menu window does not overlap any FvwmProxy >>> >> > windows. >>> >> > * Release the modifier key inside the menu. >>> >> > * Close the menu by pressing Escape. >>> >> > >>> >> > Now, does FvwmProxy close or not? If so, the current polling of >>> >> > the keyboard map works acceptably. >>> >> >>> >> Yes, at the very end. >>> >> >>> >> (no touching the mouse) >>> >> Meta3-ESC: proxies up >>> >> Meta3-M: custom menu with some window ops pops up (proxies still up) >>> > >>> >> Release Meta3: nothing happens >>> > >>> > As expected while the keyboard is grabbed. >>> > >>> >> ESC: proxies and menu disappear >>> >> >>> >> It's the same results whether or not the menu and proxies window are >>> >> in contact. >>> > >>> > That's good, to make sure however, could you repeat that test but >>> > put an fprintf in Loop() that shows which events arrive after the >>> > menu is closed? >>> >>> FvwmProxy ProcessMessage M_STRING "Hide" >> >> Where did this come from? > > *FvwmProxy: Action ModifierRelease S3 SendToModule FvwmProxy Hide > >>> FvwmProxy ProcessMessage M_FOCUS_CHANGE >> >> Ah I see. We need to repeat this test in a way that focus is and >> remains on some unrelated window. > > Once the menu raises, the focus locks on whatever was focused > at the time. It doesn't change until the menu drops. > >> Can you print X events too? > > I do. I believe I only receive events to the proxy windows. > There are a bunch of Expose event when they raise. > The other events only happen when I play with the mouse > on the proxy window. > >>> >> > 2. Moving keyboard handling into the core >>> >> > >>> >> > Regardless, I don't want to have this code in a module. If it >>> >> > works, every module could benefit from it if we put it into the >>> >> > fvwm core. We can't rely on KeyRelease events, but the approach >>> >> > in FvwmProxy might work. SendCommand can be used to remote >>> > ^^^ >>> > SendToModule >>> > >>> >> > control FvwmProxy or any other modules. >>> >> > >>> >> > We need a final solution before the next stable release. If we >>> >> > don't find one, I'll either remove FvwmProxy or mark it as >>> >> > experimental and announce that its interface will be changed. >>> >> >>> >> So this means replacing XEvent ButtonPress/etc with an FvwmPacket, >>> >> say M_BUTTON or M_POINTER? >>> > >>> > No, it's already possible to reliable trigger actions in the core >>> > when mouse events occur. We'd just need some notion of key >>> > release handling, e.g. >>> > >>> > Mouse F1 A SC SendToModule FvwmProxy do_what_i_want >>> > >>> > Whenever Shift-Control-F1 is pressed, fvwm would se
Re: FvwmProxy keyboard handling
On Tue, Mar 17, 2009 at 2:01 AM, Dominik Vogt wrote: > On Mon, Mar 16, 2009 at 11:36:33PM -0700, Jason Weber wrote: >> On Mon, Mar 16, 2009 at 3:34 PM, Dominik Vogt wrote: >> > On Sun, Mar 15, 2009 at 06:08:19PM -0700, Jason Weber wrote: >> > [snip] >> >> > 1. Key polling >> >> > >> >> > I'm not completely sure what the current code does. I assume the >> >> > keyboard map is polled every time an event occurs. However, there >> >> > may be a possibility that the keyboard map changed but no event >> >> > occurs. >> >> > >> >> > Earlier versions polled at a regular interval, which was >> >> > inacceptable. >> >> > >> >> > We have to test this: >> >> > >> >> > * Invoke FvwmProxy by pressing a modifier key and configure it to >> >> > terminate when the key is released. >> >> > * Don't touch the mouse from now and make sure that no events >> >> > occur that effect FvwmProxy. >> >> > * Open a menu with the keyboard; fvwm grabs the keyboard. Make >> >> > sure that the menu window does not overlap any FvwmProxy >> >> > windows. >> >> > * Release the modifier key inside the menu. >> >> > * Close the menu by pressing Escape. >> >> > >> >> > Now, does FvwmProxy close or not? If so, the current polling of >> >> > the keyboard map works acceptably. >> >> >> >> Yes, at the very end. >> >> >> >> (no touching the mouse) >> >> Meta3-ESC: proxies up >> >> Meta3-M: custom menu with some window ops pops up (proxies still up) >> > >> >> Release Meta3: nothing happens >> > >> > As expected while the keyboard is grabbed. >> > >> >> ESC: proxies and menu disappear >> >> >> >> It's the same results whether or not the menu and proxies window are >> >> in contact. >> > >> > That's good, to make sure however, could you repeat that test but >> > put an fprintf in Loop() that shows which events arrive after the >> > menu is closed? >> >> FvwmProxy ProcessMessage M_STRING "Hide" > > Where did this come from? *FvwmProxy: Action ModifierRelease S3 SendToModule FvwmProxy Hide >> FvwmProxy ProcessMessage M_FOCUS_CHANGE > > Ah I see. We need to repeat this test in a way that focus is and > remains on some unrelated window. Once the menu raises, the focus locks on whatever was focused at the time. It doesn't change until the menu drops. > Can you print X events too? I do. I believe I only receive events to the proxy windows. There are a bunch of Expose event when they raise. The other events only happen when I play with the mouse on the proxy window. >> >> > 2. Moving keyboard handling into the core >> >> > >> >> > Regardless, I don't want to have this code in a module. If it >> >> > works, every module could benefit from it if we put it into the >> >> > fvwm core. We can't rely on KeyRelease events, but the approach >> >> > in FvwmProxy might work. SendCommand can be used to remote >> > ^^^ >> > SendToModule >> > >> >> > control FvwmProxy or any other modules. >> >> > >> >> > We need a final solution before the next stable release. If we >> >> > don't find one, I'll either remove FvwmProxy or mark it as >> >> > experimental and announce that its interface will be changed. >> >> >> >> So this means replacing XEvent ButtonPress/etc with an FvwmPacket, >> >> say M_BUTTON or M_POINTER? >> > >> > No, it's already possible to reliable trigger actions in the core >> > when mouse events occur. We'd just need some notion of key >> > release handling, e.g. >> > >> > Mouse F1 A SC SendToModule FvwmProxy do_what_i_want >> > >> > Whenever Shift-Control-F1 is pressed, fvwm would send the string >> > "do_what_i_want" over the module pipe to the module in an M_STRING >> > packet. Look at modules/FvwmButtons/FvwmButtons.c for an example. >> > >> >> If it's better for the core code, I'll be happy to adapt. >> > >> > Maybe something like >> > >> > WaitForKeyReleased F1 Action >> > >> > Fvwm could k
Re: FvwmProxy keyboard handling
On Mon, Mar 16, 2009 at 3:40 PM, Thomas Adam wrote: > 2009/3/16 Dominik Vogt : >> On Sun, Mar 15, 2009 at 06:08:19PM -0700, Jason Weber wrote: >> [snip] >>> > 1. Key polling >>> > >>> > I'm not completely sure what the current code does. I assume the >>> > keyboard map is polled every time an event occurs. However, there >>> > may be a possibility that the keyboard map changed but no event >>> > occurs. >>> > >>> > Earlier versions polled at a regular interval, which was >>> > inacceptable. >>> > >>> > We have to test this: >>> > >>> > * Invoke FvwmProxy by pressing a modifier key and configure it to >>> > terminate when the key is released. >>> > * Don't touch the mouse from now and make sure that no events >>> > occur that effect FvwmProxy. >>> > * Open a menu with the keyboard; fvwm grabs the keyboard. Make >>> > sure that the menu window does not overlap any FvwmProxy >>> > windows. >>> > * Release the modifier key inside the menu. >>> > * Close the menu by pressing Escape. >>> > >>> > Now, does FvwmProxy close or not? If so, the current polling of >>> > the keyboard map works acceptably. >>> >>> Yes, at the very end. >>> >>> (no touching the mouse) >>> Meta3-ESC: proxies up >>> Meta3-M: custom menu with some window ops pops up (proxies still up) >> >>> Release Meta3: nothing happens >> >> As expected while the keyboard is grabbed. > > I've had problems with FvwmProxy; I don't configure anything, but bind > the "showtoggle" option to a key. If I have two windows one stacked > on the other and group them, if I then focus between them with > FvwmProxy running (none of the proxy windows need to be visible, it's > enough to just have "Module FvwmProxy" loaded), FVWM (I assume) get's > in a continuous lopp constantly shifting focus between the two windows > which are stacked. > > I wonder if this is due to the default behaviour of WIndowListFunc somehow? > > [...] > > -- Thomas Adam > > I would need more details. Do you have auto-raise or something else going on other than simply a focus event? -- Jason Weber
Re: FvwmProxy keyboard handling
On Mon, Mar 16, 2009 at 3:34 PM, Dominik Vogt wrote: > On Sun, Mar 15, 2009 at 06:08:19PM -0700, Jason Weber wrote: > [snip] >> > 1. Key polling >> > >> > I'm not completely sure what the current code does. I assume the >> > keyboard map is polled every time an event occurs. However, there >> > may be a possibility that the keyboard map changed but no event >> > occurs. >> > >> > Earlier versions polled at a regular interval, which was >> > inacceptable. >> > >> > We have to test this: >> > >> > * Invoke FvwmProxy by pressing a modifier key and configure it to >> > terminate when the key is released. >> > * Don't touch the mouse from now and make sure that no events >> > occur that effect FvwmProxy. >> > * Open a menu with the keyboard; fvwm grabs the keyboard. Make >> > sure that the menu window does not overlap any FvwmProxy >> > windows. >> > * Release the modifier key inside the menu. >> > * Close the menu by pressing Escape. >> > >> > Now, does FvwmProxy close or not? If so, the current polling of >> > the keyboard map works acceptably. >> >> Yes, at the very end. >> >> (no touching the mouse) >> Meta3-ESC: proxies up >> Meta3-M: custom menu with some window ops pops up (proxies still up) > >> Release Meta3: nothing happens > > As expected while the keyboard is grabbed. > >> ESC: proxies and menu disappear >> >> It's the same results whether or not the menu and proxies window are >> in contact. > > That's good, to make sure however, could you repeat that test but > put an fprintf in Loop() that shows which events arrive after the > menu is closed? FvwmProxy ProcessMessage M_STRING "Hide" FvwmProxy ProcessMessage M_FOCUS_CHANGE >> > 2. Moving keyboard handling into the core >> > >> > Regardless, I don't want to have this code in a module. If it >> > works, every module could benefit from it if we put it into the >> > fvwm core. We can't rely on KeyRelease events, but the approach >> > in FvwmProxy might work. SendCommand can be used to remote > ^^^ > SendToModule > >> > control FvwmProxy or any other modules. >> > >> > We need a final solution before the next stable release. If we >> > don't find one, I'll either remove FvwmProxy or mark it as >> > experimental and announce that its interface will be changed. >> >> So this means replacing XEvent ButtonPress/etc with an FvwmPacket, >> say M_BUTTON or M_POINTER? > > No, it's already possible to reliable trigger actions in the core > when mouse events occur. We'd just need some notion of key > release handling, e.g. > > Mouse F1 A SC SendToModule FvwmProxy do_what_i_want > > Whenever Shift-Control-F1 is pressed, fvwm would send the string > "do_what_i_want" over the module pipe to the module in an M_STRING > packet. Look at modules/FvwmButtons/FvwmButtons.c for an example. > >> If it's better for the core code, I'll be happy to adapt. > > Maybe something like > > WaitForKeyReleased F1 Action > > Fvwm could keep a list of key and actions it's waiting to be > released. Whenever an event arrives while the list is not empty, > fvwm would query the keyboard map and check if any of the keys is > not pressed at the moment. If so, it would remove the entry from > the list and execute the action. It would also need to handle pure modifiers. We currently have: *FvwmProxy: Action ModifierRelease S3 SendToModule FvwmProxy Hide I don't know if key bindings are exclusive, but if not, something like KeyRelease * A 3 SendToModule FvwmProxy Hide But you know what I'm looking for, so I should be happy with whatever syntax is decided upon. >> > 3. Problems in window placement code >> > >> > The "while (collision == true)" in AdjustWindows() may loop >> > forever. I haven't tried to generate this situation though. It >> > also may shift proxy windows to the void outside the screen. We >> > need a more reliable algorithm. >> >> I suppose a maxCollisions would be prudent. >> >> Off the screen issues, that I am aware of. In really deep, but >> vertically short, >> stacks of virtual tabs, that does happen. I've been just rearranging >> windows. >> My #2 would help, but it could go a step further and actually push away from >> the edges. With such bounds, it is
Re: FVWM: stick between screen
I did a quick check this morning and that seemed to work. I had: Style "*" EdgeResistance 500 30 which didn't work [anymore] even if I added xinerama-scrolling. I'll have to read about the difference. Thanks for the assistance. -- Jason Weber On Mon, Mar 16, 2009 at 6:33 AM, Thomas Adam wrote: > 2009/3/16 Jason Weber : >> The right edge of the window sticks to the right edge of the left monitor, >> but the left edge of the window is unaffected by the left edge of the >> right monitor. > > Heh, I thought as much -- but then I did warn you. :) > > Before I think about this more, is not the following an acceptable > solution for you? > > Style * EdgeMoveResistance 900 90 xinerama-scrolling > > It more or less already *does* what you're wanting. > > -- Thomas Adam >
Re: FVWM: stick between screen
The right edge of the window sticks to the right edge of the left monitor, but the left edge of the window is unaffected by the left edge of the right monitor. -- Jason Weber On Sun, Mar 15, 2009 at 6:14 PM, Thomas Adam wrote: > 2009/3/15 Jason Weber : >> Start with one empty unified screen, two side by side monitors using >> twinview (same card, different plugs). >> >> Instance a new window, say a xterm. >> >> Slide it left and right so that the left or right edge passes from >> one monitor to the other. I believe that the window edge is supposed to >> snap with strong preference to keep the window on only one monitor. >> >> The only thing I know of that might be unusual is that my >> monitors' horizontal resolutions are different. > > Well as long as X reports things correctly then FVWM will honour that, > so I think this a red-herring. I'm not in a position to test this > myself as I am sans Xinerama, but does the following patch do anything > to help "fix" this? I warn you it's complete theory on my part, so > expect a quirk or fifty. ;) > > -- Thomas Adam > > P.S. Also Cc'ed fvwm-workers which is what you should have done from > the outset. >
Re: FvwmProxy keyboard handling
I've found the lists.math.uh.edu archive which is not the same as what is shown on the fvwm.org page. Apparently my emails did show up, but I haven't been receiving them at my gmail or my older account. Perhaps the fvwm.org contact page needs to be updated to get the proper archive and any other newer instructions. I cut&paste this prior mail off the archive. > From Dominik Vogt > Subject FvwmProxy keyboard handling > Date Sun, 15 Mar 2009 12:50:47 +0100 > > [Part 1 text/plain us-ascii (7.0 kilobytes)] (View Text in a separate window) > I've moved this discussion to a separate thread. > > > jpwe...@imonk.com wrote: > > On Sun, Mar 15, 2009 at 12:44:27AM +0100, Dominik Vogt wrote: > > > On Sat, Mar 14, 2009 at 12:24:57PM -0700, jpwe...@imonk.com wrote: > > > > On Sat, Mar 14, 2009 at 12:15:03AM +0100, Dominik Vogt wrote: > > > > > On Tue, Mar 10, 2009 at 10:34:38PM +, Mikhael Goikhman wrote: > > > > > > > > > > * FvwmProxy: unfinished and unmaintained > > > > > > > > Please send me the location of any feature requests or bug reports. > > > > > > > > Here's my list. > > > > > > > > 1. don't reorder others in group on raise > > > > 2. vertical centering of groups of proxies > > > > 3. SoftRaiseOff SoftDeskOff SoftDragOff Hard* likewise > > > > 4. option to only show proxy of active window > > > > > > > > No bugs I know, but 1 and 2 address suboptimal behavior. > > > > > > > > 3 is an idea for more detailed custom behavior. > > > > > > > > 4 is a request I saw on the list a while back. > > > > It's not something I would use, but it would probably > > > > be an easy add next time I visited the code. > > > > > > The issue of keyboard handling and/or grabbing is completely > > > unresolved. The original version did keyboard polling, which is > > > unacceptable. My attempts to make it listen to events never led > > > to anything usable, so basically there is not clean way to invoke > > > it the way it way meant to be invoked. > > > > You'll need to be more specific. From what I see, it is > > using FQueryPointer which is also in FvwmDragWell, FvwmIconMan, > > FvwmIdent, FvwmPager, FvwmTaskBar, FvwmWharf, and FvwmWinList. > > It calls this through a Loop function that is pretty much cut&paste > > from FvwmPager. And it doesn't require you to do this modifiers > > watch. You can use simply toggle proxies with explicit commands. > > If some non-xorg server is fussy, well, I'd hate to see all these > > capabilites effectively banned to console a few fringe users > > who may not otherwise get the full functionality. > > > > It seems FvwmPager and FvwmProxy are both spinning in Loop(). > > Does it really matter if I call FQueryPointer each time (when > > activated and proxies are visible)? It is immeasurable > > on the CPU, not even above any of "0%" cpu processes I see > > in 'top'. I do get 1% for the single time step that I open > > the proxies, so I know it's there. > > > > > And there's still the possibility of cpu lockups because of an > > > infinite loop. > > > We discussed both when we added FvwmProxy to cvs - they've been > > > in the todo-2.6 for ages. > > > > I use SendFvwmPipe and SendText. So does every nearly other module, > > it seems. I 'send' resize and move commands, as some others do. > > It seems more appropriate than XMoveResizeWindow and the like, > > which many modules have. Perhaps no other module reacts to its > > own move commands, maybe, but I've been using this 14 hours a day > > for nearing a decade (less comment to follow) and I haven't had > > it freeze for at least a couple of years, as long as I can remember > > at least. Are these current bugs or reports that were never rechecked? > > I went to the fvwm bug tracking system and a regex on > > fvwmproxy came up one fixed bug about a man page. > > It very difficult to debug speculations. > > > > > > I haven't had a compelling need to fiddle with something > > > > that works, mostly. Honestly, who has read through the > > > > whole current man page, set this module up correctly, > > > > used it for a while, and NOT seen huge benefits? Of course > > > > this tool was tailored to my vision, but I see things like > > > > Expose and other alt-tab alternatives and am amazed that > > > > people live with such limited capabilites. It's like it > > > > gives me xray vision. Add on the window grouping, sticky edges, > > > > virtual tab bar, and this is half of why I even use fvwm. > > > > > > I *know*. FvwmProxy has realy potential to become a very helpful > > > tool for many people (maybe except me, because I already have a > > > solution for the same problem). > > > > Please share. If you've reached to next plateau, > > I'd love to come up and take a look. > > > > >There are two bis problems that > > > need to be solved first (see above). > > > > > > > People at work say, 'wow, how do I get that' and I have to > > > > tell them it doesn't work with their KDE or gnome. > > > > All the existing fvwm users I've met
Re: Removing debian/ from FVWM CVS.
oint being, this is neither abandoned code or a curious experiment. It is heavily used by serious professionals. This module is not the focus of my work, by the productivity of all my other efforts hinges on this tool. I consider the availablilty of fvwm (and therein proxy) in making career decisions. I spent 18 months on a job a few years back with pure Win32 and you never get used to it once you know what real efficiency is like. It is a joke, a sad sad joke. FvwmPartition, in contrast, is an experiment and, as far I am concerned, the sticky edge and virtual tab capabilites of FvwmProxy now superset anything ion-like FvwmPartition would have contributed, so partitioning is an abandoned curious experiment. > > Ciao > > Dominik ^_^ ^_^ > > -- > > Dominik Vogt > -- Jason Weber
Re: FvwmProxy is broken
On Fri, Apr 20, 2007 at 11:48:11AM +0100, seventh guardian wrote: > On 4/20/07, Jason Weber <[EMAIL PROTECTED]> wrote: > >On Thu, Apr 19, 2007 at 11:11:58AM +0100, seventh guardian wrote: > >> Hello, > >> > >> FvwmProxy is somewhat broken. Clicking on it sometimes makes the > >> windows jump off the screen, or just jump half-screen to some > >> direction. Usually it happens when I click it to raise the proxyed > >> window. > > > >Before I get to this, some questions. What are RaiseUtils and LowerUtils? > >Who calls SuperOn? > > RaiseUtils and LowerUtils are functions that respectively raise and > lower a pager, a clock and the iconified windows. So basically I use > the toggle feature of the proxy to also toggle the "always-visibility" > of my desktop utilities. > > SuperOn is binded to the left Super key (the one with the window$ logo). > > >Have you tried without ProxyMove? I never really use it, > >so it is a likely candidate for neglect. > > Hum no I havent.. And in fact it does solve the problem! > > >Does it seem to happen more if there is some mouse motion when you click? > > Yup, it seems to. > > >Do you really use the ProxyMove feature? Would it be tragic if it > >disappeared? I utilize FvwmProxy 12+ hours a day with multiple window > >groups stacked four or five high and it never really occurs to me where I > >wish I could drag a window by its proxy, despite its floating-title-bar > >appearance. Maybe that's only because I never really drag by title bars, > >just with key mappings. > > I like the feature because it seems like a natural ability (as you > said, it feels like a floating title bar). But honestly I rarely use > it, because the main goal of my proxies is to replace a task-bar (that > is, to show which windows are open and to raise them). So it wouldn't > be much tragic if it went away.. > > >Does anyone have any feedback on the new(er) ion-like tab&pane > >functionality > >or the programmable toolbar? It's now hard for me to imagine life without > >it, > >but I haven't heard any comments one way or the other. > > Honestly I didn't have enough time to fiddle trough the docs.. I've > just bought a laptop and am in the process of creating a new config > for it. So you will hear from me as I go :) > > By the way, I'm having some trouble getting the mini-icons to show up > in the proxies.. I've tried resizing the window, changing the number > of groups, etc.. But nothing worked.. I suspect this may have > something to do with the bug reported by Robert Heller about > FvwmIconBox not displaying the icons from Tcl/Tk apps.. > > Cheers > Renato > I've made a fix to FvwmProxy's use of Move and ResizeMove to properly allow a window position change that would go negative. This was used by ProxyMove, as well as group motion where I saw a problem, but I'm not sure if it would affect the behavior you were seeing. When you get a chance, see if this changes anything for you. -- _ ( \ _ \/_ / _ _ Jason Weber Glendale, CA \|(\/)())) \/\/(-/_)(-/( http://www.imonk.com/baboon [EMAIL PROTECTED] // [EMAIL PROTECTED] (/
Re: FvwmProxy is broken
On Thu, Apr 19, 2007 at 11:11:58AM +0100, seventh guardian wrote: > Hello, > > FvwmProxy is somewhat broken. Clicking on it sometimes makes the > windows jump off the screen, or just jump half-screen to some > direction. Usually it happens when I click it to raise the proxyed > window. > > I've tried to reproduce this consistently, but have been unable to. So > currently I have to keep clicking fast on the lower-right corner of > the proxy window to make it "jump", which it does to the lower right > corner of the screen, sporadically. I doing the same with other > corners will result in an equivalent behavior. > > Jason can you reproduce this? Someone? > > My config: > > # FvwmProxy > #--- > > DestroyFunc ProxyStart > AddToFunc ProxyStart > + I Module FvwmProxy > > *FvwmProxy: ProxyMove true > *FvwmProxy: ShowMiniIcons true > *FvwmProxy: Action Show RaiseUtils > *FvwmProxy: Action Hide LowerUtils > *FvwmProxy: Colorset 0 > > DestroyFunc SuperOn > AddToFunc SuperOn > + I SendToModule FvwmProxy ShowToggle > > Cheers, > Renato > > PS: I should have said something before, but I was lacking time for > debuging (still am, but fvwm is kind of a catharsis now). > Before I get to this, some questions. What are RaiseUtils and LowerUtils? Who calls SuperOn? Have you tried without ProxyMove? I never really use it, so it is a likely candidate for neglect. Does it seem to happen more if there is some mouse motion when you click? Do you really use the ProxyMove feature? Would it be tragic if it disappeared? I utilize FvwmProxy 12+ hours a day with multiple window groups stacked four or five high and it never really occurs to me where I wish I could drag a window by its proxy, despite its floating-title-bar appearance. Maybe that's only because I never really drag by title bars, just with key mappings. Does anyone have any feedback on the new(er) ion-like tab&pane functionality or the programmable toolbar? It's now hard for me to imagine life without it, but I haven't heard any comments one way or the other. -- _ ( \ _ \/_ / _ _ Jason Weber Glendale, CA \|(\/)())) \/\/(-/_)(-/( http://www.imonk.com/baboon [EMAIL PROTECTED] // [EMAIL PROTECTED] (/
Re: FvwmProxy minor patch
The debug setting was unintentional. Beyond that, consider: Index: FvwmProxy.1.in === RCS file: /home/cvs/fvwm/fvwm/modules/FvwmProxy/FvwmProxy.1.in,v retrieving revision 1.6 diff -u -r1.6 FvwmProxy.1.in --- FvwmProxy.1.in 7 Oct 2006 07:27:40 - 1.6 +++ FvwmProxy.1.in 23 Dec 2006 13:25:47 - @@ -53,7 +53,21 @@ This is only meaningful in conjuction with the ProxyIconified option on. .IP "*FvwmProxy: Font \fIfont\fP" -Specifies the font used for all proxy window text. +Specifies the font used for large proxy window text. +This usually contains the icon string and is nearly vertically centered +in the proxy. +If there is no icon string, the title bar string is used. +If this text exceeds the width of the proxy, it is cropped on the right. +If no Font is specified, a default is used. + +.IP "*FvwmProxy: SmallFont \fIfont\fP" +Specifies the font used for the auxillary proxy window text. +This usually contains the title bar string, but is omitted if it +is identical to the icon string and that text was not cropped. +The text is drawn close to the bottom of the proxy and should +probably be the smallest legible font available. +If this text exceeds the width of the proxy, it is cropped on the left. +If no SmallFont is specified, this text is never drawn. .IP "*FvwmProxy: Width \fIw\fP" Specifies the size in X of each proxy window. @@ -187,7 +201,7 @@ The default is Noop. .IP "*FvwmProxy: UndoLimit \fIn\fP" -This specifies the number of entires in the undo buffer. +This specifies the number of entries in the undo buffer. this limits how far back you can undo. The default is 8. @@ -268,7 +282,7 @@ .IP "SendToModule FvwmProxy Redo" Attempt to redo the most recent Undo. If another move or resize occurs since the previous undo, -the redo buffer is cleared. +the redo buffer will be cleared. .SH SAMPLE CONFIGURATION The following are excerpts from a .fvwm2rc file which describe -- _ ( \ _ \/_ / _ _ Jason Weber Glendale, CA \|(\/)())) \/\/(-/_)(-/( http://www.imonk.com/baboon [EMAIL PROTECTED] // [EMAIL PROTECTED] (/ On Fri, Dec 22, 2006 at 11:32:40PM +0300, Serge (gentoosiast) Koksharov wrote: > Hello, > > Please see attached patch's ChangeLog. > > -- > Serge Koksharov, Free Software user & supporter > GPG public key ID: 0x3D330896 (pgp.mit.edu) > Key fingerprint: 5BC4 0475 CB03 6A31 0076 82C2 C240 72F0 3D33 0896 > diff -Naur fvwmCVS_orig/modules/ChangeLog fvwmCVS_fixed/modules/ChangeLog > --- fvwmCVS_orig/modules/ChangeLog2006-12-22 23:22:37.0 +0300 > +++ fvwmCVS_fixed/modules/ChangeLog 2006-12-22 23:28:39.0 +0300 > @@ -1,3 +1,18 @@ > +2006-12-22 Serge Koksharov > + > + * FvwmProxy/FvwmProxy.c: > + Changed PROXY_GROUP_DEBUG define directive to False. > + > + (My_XNextEvent): > + Removed useless exit message. > + > + * FvwmProxy/FvwmProxy.c: > + * FvwmProxy/FvwmProxy.h: > + Corrected VIM modelines. > + > + * FvwmProxy/FvwmProxy.1.in: > + Documented SmallFont configuration option. > + > 2006-12-10 Viktor Griph <[EMAIL PROTECTED]> > > * FvwmWinList/FvwmWinList.c (ProcessMessage): > diff -Naur fvwmCVS_orig/modules/FvwmProxy/FvwmProxy.1.in > fvwmCVS_fixed/modules/FvwmProxy/FvwmProxy.1.in > --- fvwmCVS_orig/modules/FvwmProxy/FvwmProxy.1.in 2006-12-22 > 23:22:35.0 +0300 > +++ fvwmCVS_fixed/modules/FvwmProxy/FvwmProxy.1.in2006-12-22 > 23:22:59.0 +0300 > @@ -55,6 +55,10 @@ > .IP "*FvwmProxy: Font \fIfont\fP" > Specifies the font used for all proxy window text. > > +.IP "*FvwmProxy: SmallFont \fIfont\fP" > +Specifies the font used for displaying window names. The default is to not > +display window names. > + > .IP "*FvwmProxy: Width \fIw\fP" > Specifies the size in X of each proxy window. > > diff -Naur fvwmCVS_orig/modules/FvwmProxy/FvwmProxy.c > fvwmCVS_fixed/modules/FvwmProxy/FvwmProxy.c > --- fvwmCVS_orig/modules/FvwmProxy/FvwmProxy.c2006-12-22 > 23:22:35.0 +0300 > +++ fvwmCVS_fixed/modules/FvwmProxy/FvwmProxy.c 2006-12-22 > 23:22:59.0 +0300 > @@ -1,4 +1,5 @@ > /* -*-c-*- */ > +/* vim: set ts=8 shiftwidth=8: */ > /* This module, FvwmProxy, is an original work by Jason Weber. > * > * This program is free software; you can redistribute it and/or modify > @@ -16,7 +17,6 @@ > * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > */ > > -/* vim:ts=8:shiftwidth=8: */ > > /* included header files > ---
