Re: old gtk1 dependency
On Tue, Mar 10, 2009 at 02:21:04AM +, Mikhael Goikhman wrote: > On 09 Mar 2009 23:16:21 +, Thomas Adam wrote: > > > > 2009/3/9 Mikhael Goikhman : > > > On 09 Mar 2009 10:21:05 -0500, Jonathan Kotta wrote: > > >> > > >> I use Ubuntu, and use `make deb-inplace` to build fvwm .debs. ?Nothing > > >> in my system needs libgtk1.x, and I can imagine many people could say > > >> the same. ?Should fvwm get rid of this dependency? > > > > > > This question is actually two. Whether we should have FvwmGtk (I think, > > > yes). And whether libgtk1 should be forced for deb generation (I think, > > > no, it should ideally be synced with ./configure detection). > > > > I say we drop it -- no one uses FvwmGTK anymore. No one has bothered > > or felt the urge to port it to use GTK2. > > I don't know whether this is a good reason to remove this module. > Noone felt urge to do many things in fvwm. This is the chicken and egg > question. An idea to have a full GTK integration seems nice (menus, > dialogs). Possibly even more appealing to me than an idea to have module > managed window decorations. My position is although I don't use a lot of > features in fvwm, I would not suggest to break or remove anything. > At least without showing what is gained by this. And giving enough time > in advance to notify all potential users. > > BTW, in fvwm-themes, "Configuration / Theme Settings (gtk)" dialog uses > it (if you configured the FvwmGtk support in fvwm). > > > Note also FvwmGtkDebug -- last I checked that suffers from a similar > > dependency. > > I use it, and I think it is a must see for every new fvwm developer, > to understand and possibly debug the module communication. It is > probably a good idea to convert it from gtk1 to gtk2, but I didn't see > a good reason, since it just works and should not be funcy. I think > there is a debian package libgtk-perl, and on the latest Fedora > installing perl-GTK-0.7009-5mdv2008.1 rpm from Mandriva (use --nodeps) > works fine. http://packages.debian.org/search?keywords=libgtk-perl etch was the lsat Debian release to have libgtk-perl, the current Debian release lenny that came out this year no longer has the package, lenny does have libgtk2-perl instead. > In any case, FvwmGtkDebug is pretty different from FvwmGtk. First, > there is no any dependency on build time; like anything perl related a > missing package may be installed at any time later. And this module is > intended for developers, not regular users. > > Regards, > Mikhael. -- David Fries http://fries.net/~david/ (PGP encryption key available)
Re: [PATCH] fix edge bump and window jump bug
On Mon, Mar 09, 2009 at 11:44:31AM +, Thomas Adam wrote: > 2009/3/4 David Fries : > > On Tue, Mar 03, 2009 at 09:41:58AM +0100, Dominik Vogt wrote: > >> On Sun, Mar 01, 2009 at 04:08:57PM -0600, David Fries wrote: > >> > history and bug report: > >> > I just upgraded fvwm and saw an edge bump behavior at the outside > >> > paging border when moving a window. ?When a window was moved into the > >> > panning window the poiner and window would be bumped so the pointer > >> > was moved outside the panning window. ?This jumping was annoying and > >> > was causing me to drop windows a pixel or two from the border, which I > >> > would have to pickup and move again. > >> > >> I don't understand the problem exactly. ?Can you give me precise > >> instructions with a minimal config file? > > > > Just ConfigFvwmDefaults, > > touch /tmp/empty > > ./fvwm -c /tmp/empty > > left click background for menu, click Issue fvwm commands, > > `OpaqueMoveSize 200` ? ?(optional) > > `Move` > > Click and drag from the lower part of the window, and drag it to the > > top of the screen. ?Keep pushing up and you'll see the pointer and > > window jitter as it jumps between the top pixel of the screen and two > > pixels down. > > I bet this is due to panframes. Add to your instructions: > > OpaqueMoveSize 200 > EdgeThickness 0 > Move > > Does it disappear then? (The use of OpaqueMoveSize is completely > unnecessary here, FWIW.) Yes it is gone. > In which case, the problem is most likely the events the pan window > receives as the window is moved across it (and hence the pointer is > then inside of the panwindow also.) Not no this case. I'm at the top of the top virtual page without edge wrap, which is just the same as any other outside border. Panning frames are only placed on borders which have a virtual page in that direction, the outside border doesn't. > I don't believe your patch to be a good enough fix though for this -- > it seems to be orthogonal to the problem; at least in terms of how I > am able to reproduce it and potentially "fix" the issue. > > -- Thomas Adam Care to explain? It fixes the problems I'm seeing, and I'm not seeing any new ones. Have you tried my patch? What behavior are you seeing before or after? The two files are fixing two separate bugs which I gave in the original e-mail, the virtual.c 1.187 revision masked the move_resize.c __move_loop problem. fvwm/virtual.c revision 1.187 date: 2007/09/11 18:48:57; author: domivogt; state: Exp; lines: +7 -7 * Fixed jumping windows under some circumstances when releasing the button in interactive motion while hitting the desktop's edge. -- David Fries http://fries.net/~david/ (PGP encryption key available)
Re: old gtk1 dependency
On 09 Mar 2009 23:16:21 +, Thomas Adam wrote: > > 2009/3/9 Mikhael Goikhman : > > On 09 Mar 2009 10:21:05 -0500, Jonathan Kotta wrote: > >> > >> I use Ubuntu, and use `make deb-inplace` to build fvwm .debs. Nothing > >> in my system needs libgtk1.x, and I can imagine many people could say > >> the same. Should fvwm get rid of this dependency? > > > > This question is actually two. Whether we should have FvwmGtk (I think, > > yes). And whether libgtk1 should be forced for deb generation (I think, > > no, it should ideally be synced with ./configure detection). > > I say we drop it -- no one uses FvwmGTK anymore. No one has bothered > or felt the urge to port it to use GTK2. I don't know whether this is a good reason to remove this module. Noone felt urge to do many things in fvwm. This is the chicken and egg question. An idea to have a full GTK integration seems nice (menus, dialogs). Possibly even more appealing to me than an idea to have module managed window decorations. My position is although I don't use a lot of features in fvwm, I would not suggest to break or remove anything. At least without showing what is gained by this. And giving enough time in advance to notify all potential users. BTW, in fvwm-themes, "Configuration / Theme Settings (gtk)" dialog uses it (if you configured the FvwmGtk support in fvwm). > Note also FvwmGtkDebug -- last I checked that suffers from a similar > dependency. I use it, and I think it is a must see for every new fvwm developer, to understand and possibly debug the module communication. It is probably a good idea to convert it from gtk1 to gtk2, but I didn't see a good reason, since it just works and should not be funcy. I think there is a debian package libgtk-perl, and on the latest Fedora installing perl-GTK-0.7009-5mdv2008.1 rpm from Mandriva (use --nodeps) works fine. In any case, FvwmGtkDebug is pretty different from FvwmGtk. First, there is no any dependency on build time; like anything perl related a missing package may be installed at any time later. And this module is intended for developers, not regular users. Regards, Mikhael.
Re: old gtk1 dependency
Hello, I am not sure if this has any value for the thread, so please, if it doesn't just ignore this post and forgive me for disrupting the discussion. I just wanted to illustrate the current state of this in Gentoo, since other people around already did the same for debian based distros. El Mar, 10 de Marzo de 2009, 0:16, Thomas Adam escribió: > > Note also FvwmGtkDebug -- last I checked that suffers from a similar > dependency. In the gentoo ebuild, Gtk.pm and *FvwmGtkDebug* are removed unconditionally since I cleaned up the whole think (for 2.5.25 I think, it's been long since), and no one has even complained about it. This is true for both the official ebuild for 2.5.26 and the unofficial cvs one. Note that this stuff would anyway need gtk-perl, which was gone off the portage tree long ago, so, the official portage can't support that feature unless we add another gtk1-based package that's already deprecated and probably unmaintained. The rest of gtk1 support should work (never used it myself though) and is controlled via an USE flag, but I don't know about anyone using it either. So, I don't think that Gentoo users in general would care about you dropping gtk1 at all. Nowadays no one is going to add any gtk1 based package into portage unless it's needed to save a kitten from an horrible death or something like that. :) -- Jesús Guerrero
Re: Google summer of code
2009/3/9 Viktor Griph : > I think it would be great if fvwm could apply as a mentoring organization in > this year's GSOC. I would be interested in working as a student on fvwm if > anyone has the time to mentor me. This will most likely be the last summer > I'll be eligible to participate as a student, and I'd really like to work > with fvwm full time this summer. And so to go back to roots... Assuming no one else on this list objects, I am going to step up to this and nominate myself as an official point of contact for this -- including writing a proposal for FVWM -- at least I assume that's what I would have to do. I actually have the time to devote to this which is nice, and something I'd like to do. Viktor, do you have information I would need to fill out to support FVWM's chances for GSOC this year? To anyone else following this: I've witnessed several FOSS projects last year have great success with GSOC (Git being one of them), and some projects had co-mentoring. So If anyone at this early stage (and there's no guarantees of course that we'd be successful with Google) thinks they might have time to pitch in, do speak up. :) -- Thomas Adam
Re: old gtk1 dependency
On Mon, Mar 09, 2009 at 03:26:19PM +, Thomas Adam wrote: > 2009/3/9 Jonathan Kotta : > > I use Ubuntu, and use `make deb-inplace` to build fvwm .debs. Nothing > > in my system needs libgtk1.x, and I can imagine many people could say > > the same. Should fvwm get rid of this dependency? > > We should be removing that directory entirely from FVWM to be honest. Fine with me. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: old gtk1 dependency
2009/3/9 Mikhael Goikhman : > On 09 Mar 2009 10:21:05 -0500, Jonathan Kotta wrote: >> >> I use Ubuntu, and use `make deb-inplace` to build fvwm .debs. Nothing >> in my system needs libgtk1.x, and I can imagine many people could say >> the same. Should fvwm get rid of this dependency? > > This question is actually two. Whether we should have FvwmGtk (I think, > yes). And whether libgtk1 should be forced for deb generation (I think, > no, it should ideally be synced with ./configure detection). I say we drop it -- no one uses FvwmGTK anymore. No one has bothered or felt the urge to port it to use GTK2. Note also FvwmGtkDebug -- last I checked that suffers from a similar dependency. -- Thomas Adam
Re: old gtk1 dependency
On 09 Mar 2009 10:21:05 -0500, Jonathan Kotta wrote: > > I use Ubuntu, and use `make deb-inplace` to build fvwm .debs. Nothing > in my system needs libgtk1.x, and I can imagine many people could say > the same. Should fvwm get rid of this dependency? This question is actually two. Whether we should have FvwmGtk (I think, yes). And whether libgtk1 should be forced for deb generation (I think, no, it should ideally be synced with ./configure detection). > --- fvwm-2.5.27-old/debian/control.in 2007-08-07 15:17:42.0 -0500 > +++ fvwm-2.5.27/debian/control.in 2009-03-09 10:05:07.0 -0500 > @@ -3,7 +3,7 @@ > Priority: optional > Maintainer: Fvwm Workers <@FVWMWORKERSLIST@> > Build-Depends: debhelper (>>4.0.0), file, autotools-dev, xlibs-dev, > - libgtk1.2-dev || libgtk1.4-dev, libncurses5-dev, libreadline5-dev, > + libncurses5-dev, libreadline5-dev, > libpng3-dev, libimlib2-dev, gdk-imlib1-dev | gdk-imlib-dev, > libstroke0-dev, libfribidi-dev, libxft-dev, libfreetype6-dev, > librsvg2-dev (>= 2.13.92), libxcursor-dev Well, if you drop libgtk1.*-dev, then you may as well drop gdk-imlib*-dev that is also used in FvwmGtk only. And possibly libimlib2-dev too. I have no deb system at hand to verify. Possibly there should be no library dependancies in Build-Depends at all, just like the rpm procedure does not list them. The whole idea is for the users to be able to build their own custom rpm or deb packages as an alternative to "make install". Suppose we drop all lib*-dev here (or move them to Build-Suggests). I would like you to confirm that this does the intended. I.e. if a user has libgtk1.4 and imlib, then working FvwmGtk is included in the generated deb, otherwise not included, and if he has libpng then fvwm in this deb is built with this support and all corresponding deb dependencies are automatically set. Regards, Mikhael.
Re: Google summer of code
2009/3/9 Viktor Griph : > On Mon, 9 Mar 2009, Thomas Adam wrote: >>> >>> * style/state rewrite >>> - unify the syntax for styles and states of windows, and make all states >>> matchable with conditionals >> >> This is *huge* -- not something I would recommend as an undertaking of >> GSOC. > > You are probably right. I think that trying to combine this with the > matching against calss/reasource/name was the reason why the CVS branch on > that kind of died. That and a sudden increase in work load. It might be > possible to refine the task into several smaller tasks. Splitting the stlye > command into an InitialStyle and a State command, keeping Style Wired a both > of them for backwords compatibility, could maybe be more doable task to > start with, While adding matching on window states sould be a different > task. Yes -- there's two problems with InitWindowState: 1. There's large areas of code that would need rewriting. 2. It would change the syntax of one's .fvwm2rc. Point 2., is of sufficient consideration that it would mean post 2.6 -- of course there's nothing wrong with that, but it would need to be fleshed out to define what it might look like. Plus you have to have a way of making current FVWM builtins no longer standalone -- i.e., they now have an assumed window context. But then not every FVWM builtin is sufficient to operate like this, so you'd need to enumerate them also. (If that makes sense?) For example, I started to play around with this -- and have thus far: * Defined several new structs/enums to support window states / styles. * Ripped some of styles.c out to accommodate that. * Messed around in add_window.c to support windows both pre/post mapping for checking window states, etc. And even then that's just basic groundwork. I don't know though -- maybe it's worth working on, but I would be hard pushed (personally) to spec this out before Friday. I would rather see work done on: Style (name=foo,resource=bar,Class=MyClass) InitMapCommand Raise For instance. >>> - update test cases >>> - fix bugs >> >> I don't see there being sufficient work for a student to work on this >> myself. I might be wrong though. > > It's hard to say, but I think you are probably right. 2.6 isn't that far > away. The testcases need a big overhaul, which is boring work, but probably > not enough to occupy a student a full summer. (Even though it probably would > take a week just to figure out what changes that have been done that have no > tests, and then there is the question of writing the tests for them.) Yes. I would skip this. It's the sort of thing that is best done in one's spare time, and wouldn't hold anyone's interest over the summer. >>> * move advanced decorations to a module >>> - add a style DecoratedByModule >>> - change to module interface to allow window decorations to be handled >>> by a module (Should be able to have more than one decor module >>> running, so there must be a way to control which windows are >>> decorated by which module.) >>> - move the deprecated decor stuff to a separate module >> >> This needs a lot of discussion and is something I'd always planned to >> see post 2.6 as I have a number of opinions/ideas on this myself. >> (Changing the module communication is one *large* facet itself, and is >> perhaps a separate task in its own right.) > > Yes. This one really needs discussion, and it should probably be split into > smaller tasks. Just making it possible for a module to decorate a window, > with all wat is means for dealing with user interaction needs is probably > lare enough for a single task. Not having thought a lot about it I can think Well, it's sufficiently interesting that I could probably spec this out before Friday -- but I wouldn't want to do this on my own, I would need the consensus of the other people on this list first of all. > of two ways to deal with it. Either the module is responsible for sending > commands when a user interacts with a button/frame in the decor, or the > module should provide fvwm with window ids for all interactable components > that are included in the decoration. The former has the advantage of > allowing decor modules to rethink the interaction model, but it will pose > problems on execting compex functions based on the click on a decoration > part. The latter has the advantage of leaving most of the frane interaction > code as it is, by having fvwm process the events of the decoration parts, > and also keeps the module communication at a lower level. The latter please. I had always thought of allowing the module to define this. > Needless to say this one need lots of discussion, and design descitions, and > probable is hard to mentor. Yes it will be -- I wish there'd have been more time, but I don't think this is a go-er for Friday. Sorry. > Another possble addition to the list is: > * Add/change to communication channel of FvwmCommand. > - possible channels include a UNIX socket, ICE pr
Re: Google summer of code
On Mon, 9 Mar 2009, Thomas Adam wrote: * style/state rewrite - unify the syntax for styles and states of windows, and make all states matchable with conditionals This is *huge* -- not something I would recommend as an undertaking of GSOC. You are probably right. I think that trying to combine this with the matching against calss/reasource/name was the reason why the CVS branch on that kind of died. That and a sudden increase in work load. It might be possible to refine the task into several smaller tasks. Splitting the stlye command into an InitialStyle and a State command, keeping Style Wired a both of them for backwords compatibility, could maybe be more doable task to start with, While adding matching on window states sould be a different task. * fine grained style matching. - continue the work on the CVS branch with contaiing stlye matching by reasource, class or name specified. This is better -- and self-contained enough that it would be possible, but bear in mind it's still a stop-gap measure for the much larger ideals of applying styles, those styles having states (based on the window) etc. Perhaps this could form one piece of that puzzle. - update test cases - fix bugs I don't see there being sufficient work for a student to work on this myself. I might be wrong though. It's hard to say, but I think you are probably right. 2.6 isn't that far away. The testcases need a big overhaul, which is boring work, but probably not enough to occupy a student a full summer. (Even though it probably would take a week just to figure out what changes that have been done that have no tests, and then there is the question of writing the tests for them.) * move advanced decorations to a module - add a style DecoratedByModule - change to module interface to allow window decorations to be handled by a module (Should be able to have more than one decor module running, so there must be a way to control which windows are decorated by which module.) - move the deprecated decor stuff to a separate module This needs a lot of discussion and is something I'd always planned to see post 2.6 as I have a number of opinions/ideas on this myself. (Changing the module communication is one *large* facet itself, and is perhaps a separate task in its own right.) Yes. This one really needs discussion, and it should probably be split into smaller tasks. Just making it possible for a module to decorate a window, with all wat is means for dealing with user interaction needs is probably lare enough for a single task. Not having thought a lot about it I can think of two ways to deal with it. Either the module is responsible for sending commands when a user interacts with a button/frame in the decor, or the module should provide fvwm with window ids for all interactable components that are included in the decoration. The former has the advantage of allowing decor modules to rethink the interaction model, but it will pose problems on execting compex functions based on the click on a decoration part. The latter has the advantage of leaving most of the frane interaction code as it is, by having fvwm process the events of the decoration parts, and also keeps the module communication at a lower level. Needless to say this one need lots of discussion, and design descitions, and probable is hard to mentor. I think that the primary focus should be on 2.6, but it does not hurt to to have some ideas for post 2.6 in there as well. I'm most interested in working on the two first points on the list, but would like to see 2.6 released this year, and there are still several things things to do. The requisite for all of these useful suggestions you've outlined here come at a price: no one here has really fleshed them out fully -- and ideally, I'd like a proposal feature to have been mapped out in sufficient enough detail for a prospective GSOC student such as yourself, if only because it saves time; to introduce a topic and then not know what it is really supposed to do is wasteful. They were just ideas, all open for discussion. GSoC deadline for mentor organization submissions is this Friday, and if fvwm should apply we need a list of ideas. Might be tahat it only contains a few well defined ones, but seeing the short timespan I thought I'd start some discussion. Another possble addition to the list is: * Add/change to communication channel of FvwmCommand. - possible channels include a UNIX socket, ICE protocol This is an isolated task, but I'm not sure of the size of it. If it's just to change the FIFOs used today to a socket, then it probably isn't big enough, but if it also is to add an alternative channel (i.e ICE) to allow communication with FvwmCommand over X rather than on the machine running fvwm. /Viktor
Re: Google summer of code
2009/3/9 Yuri Bushmelev : > Hello! > >> There are several items that can be added to an ideas list for fvwm. Here >> are just a few ideas from the top of my head. Some need refinement, and >> some are probably not good at all. > > I'll add two things I want to see in fvwm to use it on handhelds and MID's: > - fvwm-lua module (like fvwm-perl one) That's not too difficult actually. > - support for screen-rotating without doing full restart of fvwm (like > matchbox does) (is it RANDR?) Yes it is. -- Thomas Adam
Re: Google summer of code
Hello! > There are several items that can be added to an ideas list for fvwm. Here > are just a few ideas from the top of my head. Some need refinement, and > some are probably not good at all. I'll add two things I want to see in fvwm to use it on handhelds and MID's: - fvwm-lua module (like fvwm-perl one) - support for screen-rotating without doing full restart of fvwm (like matchbox does) (is it RANDR?) -- Yuri Bushmelev
Re: Google summer of code
2009/3/9 Viktor Griph : > I think it would be great if fvwm could apply as a mentoring organization in > this year's GSOC. I would be interested in working as a student on fvwm if > anyone has the time to mentor me. This will most likely be the last summer > I'll be eligible to participate as a student, and I'd really like to work > with fvwm full time this summer. I'll jump at this in that I'd love to participate also, but not as a student; I am not one anymore. But I certainly have the time. > There are several items that can be added to an ideas list for fvwm. Here > are just a few ideas from the top of my head. Some need refinement, and some > are probably not good at all. > > * style/state rewrite > - unify the syntax for styles and states of windows, and make all states > matchable with conditionals This is *huge* -- not something I would recommend as an undertaking of GSOC. > * fine grained style matching. > - continue the work on the CVS branch with contaiing stlye matching by > reasource, class or name specified. This is better -- and self-contained enough that it would be possible, but bear in mind it's still a stop-gap measure for the much larger ideals of applying styles, those styles having states (based on the window) etc. Perhaps this could form one piece of that puzzle. > * help finalizing fvwm 2.6 > - write a fvwm-convert-2.6 script This is something I've already done; just not made any noise about it yet. > - update test cases > - fix bugs I don't see there being sufficient work for a student to work on this myself. I might be wrong though. > * add support for RANDR This is a good one actually -- and worthwhile. > * add support for some other XExtention/library > > * move advanced decorations to a module > - add a style DecoratedByModule > - change to module interface to allow window decorations to be handled > by a module (Should be able to have more than one decor module > running, so there must be a way to control which windows are > decorated by which module.) > - move the deprecated decor stuff to a separate module This needs a lot of discussion and is something I'd always planned to see post 2.6 as I have a number of opinions/ideas on this myself. (Changing the module communication is one *large* facet itself, and is perhaps a separate task in its own right.) > I think that the primary focus should be on 2.6, but it does not hurt to to > have some ideas for post 2.6 in there as well. I'm most interested in > working on the two first points on the list, but would like to see 2.6 > released this year, and there are still several things things to do. The requisite for all of these useful suggestions you've outlined here come at a price: no one here has really fleshed them out fully -- and ideally, I'd like a proposal feature to have been mapped out in sufficient enough detail for a prospective GSOC student such as yourself, if only because it saves time; to introduce a topic and then not know what it is really supposed to do is wasteful. -- Thomas Adam
Google summer of code
I think it would be great if fvwm could apply as a mentoring organization in this year's GSOC. I would be interested in working as a student on fvwm if anyone has the time to mentor me. This will most likely be the last summer I'll be eligible to participate as a student, and I'd really like to work with fvwm full time this summer. There are several items that can be added to an ideas list for fvwm. Here are just a few ideas from the top of my head. Some need refinement, and some are probably not good at all. * style/state rewrite - unify the syntax for styles and states of windows, and make all states matchable with conditionals * fine grained style matching. - continue the work on the CVS branch with contaiing stlye matching by reasource, class or name specified. * help finalizing fvwm 2.6 - write a fvwm-convert-2.6 script - update test cases - fix bugs * add support for RANDR * add support for some other XExtention/library * move advanced decorations to a module - add a style DecoratedByModule - change to module interface to allow window decorations to be handled by a module (Should be able to have more than one decor module running, so there must be a way to control which windows are decorated by which module.) - move the deprecated decor stuff to a separate module I think that the primary focus should be on 2.6, but it does not hurt to to have some ideas for post 2.6 in there as well. I'm most interested in working on the two first points on the list, but would like to see 2.6 released this year, and there are still several things things to do. /Viktor
Re: old gtk1 dependency
2009/3/9 Jonathan Kotta : > I use Ubuntu, and use `make deb-inplace` to build fvwm .debs. Nothing > in my system needs libgtk1.x, and I can imagine many people could say > the same. Should fvwm get rid of this dependency? We should be removing that directory entirely from FVWM to be honest. -- Thomas Adam
old gtk1 dependency
I use Ubuntu, and use `make deb-inplace` to build fvwm .debs. Nothing in my system needs libgtk1.x, and I can imagine many people could say the same. Should fvwm get rid of this dependency? --- fvwm-2.5.27-old/debian/control.in 2007-08-07 15:17:42.0 -0500 +++ fvwm-2.5.27/debian/control.in 2009-03-09 10:05:07.0 -0500 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Fvwm Workers <@FVWMWORKERSLIST@> Build-Depends: debhelper (>>4.0.0), file, autotools-dev, xlibs-dev, - libgtk1.2-dev || libgtk1.4-dev, libncurses5-dev, libreadline5-dev, + libncurses5-dev, libreadline5-dev, libpng3-dev, libimlib2-dev, gdk-imlib1-dev | gdk-imlib-dev, libstroke0-dev, libfribidi-dev, libxft-dev, libfreetype6-dev, librsvg2-dev (>= 2.13.92), libxcursor-dev -- Thanks, Jonathan Kotta Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Re: [PATCH] fix edge bump and window jump bug
2009/3/4 David Fries : > On Tue, Mar 03, 2009 at 09:41:58AM +0100, Dominik Vogt wrote: >> On Sun, Mar 01, 2009 at 04:08:57PM -0600, David Fries wrote: >> > history and bug report: >> > I just upgraded fvwm and saw an edge bump behavior at the outside >> > paging border when moving a window. When a window was moved into the >> > panning window the poiner and window would be bumped so the pointer >> > was moved outside the panning window. This jumping was annoying and >> > was causing me to drop windows a pixel or two from the border, which I >> > would have to pickup and move again. >> >> I don't understand the problem exactly. Can you give me precise >> instructions with a minimal config file? > > Just ConfigFvwmDefaults, > touch /tmp/empty > ./fvwm -c /tmp/empty > left click background for menu, click Issue fvwm commands, > `OpaqueMoveSize 200` (optional) > `Move` > Click and drag from the lower part of the window, and drag it to the > top of the screen. Keep pushing up and you'll see the pointer and > window jitter as it jumps between the top pixel of the screen and two > pixels down. I bet this is due to panframes. Add to your instructions: OpaqueMoveSize 200 EdgeThickness 0 Move Does it disappear then? (The use of OpaqueMoveSize is completely unnecessary here, FWIW.) In which case, the problem is most likely the events the pan window receives as the window is moved across it (and hence the pointer is then inside of the panwindow also.) I don't believe your patch to be a good enough fix though for this -- it seems to be orthogonal to the problem; at least in terms of how I am able to reproduce it and potentially "fix" the issue. -- Thomas Adam
