Re: FVWM: can xcompmgr work in fvwm config?
On Feb 6, 2008 9:56 AM, Jesús Guerrero [EMAIL PROTECTED] wrote: On Wed, 6 Feb 2008 20:31:34 +1100 Cameron Simpson [EMAIL PROTECTED] wrote: (...) | and it doesn't use any | hardware acceleration. It will eat your cpu if you need to move a bin window | from one page to another. It was just a tool designed to showcase xcomposite, | xdamage and all the new technologies that arised in xorg. But it is just that: | a toy. I had presumed that xcomposite and friends took care of the hw acceleration if the video driver supported it. Certainly on my laptop it is an utter dog, but on the machine at work it's pretty snappy with the swanky NVidia card and nvidia driver. So much faster that the card _must_ be doing a lot of work. Xcompmgr does not take advantage of any advanced feature, like the GLX_EXT_texture_from_pixmap extension that I talked about on the other thread. In fact, that extension is way too recent, and xcompmgr has not been updated since 2005, I think. I just talk by experience, I don't know anything about xcompmgr, but my card and my drivers DO support that extension, and cpu usage in beryl is next to zero, while with Xcompmgr it is awful. I would like to hear a more technical explanation as well, I don't know anything about the internals of this all. Xcompmgr doesn't use that extension because it is not opengl accelerated. On the other hand, I believe compiz is (or was) opengl accelerated, which required some nested X hacks for it to work. But being opengl accelerated has little to do with being hardware accelerated, as opengl is only a high level API to the hw 3d engine. The XRender extension is hw accelerated, and even fvwm takes advantage from it when acceleration is enabled. I believe (haven't looked at the code) that xcompmgr is using the XRender acceleration. I believe the xorg.conf option for nvidia closed source driver is IIRC this: Option RenderAccel true For the open source hw accelerated driver (nouveau) that I'm currently using, use this: Option AccelMethod EXA Hope this helps. Cheers, Renato
Re: FVWM: Fvwm vs. Compiz / Compiz Fusion
On Feb 5, 2008 3:25 PM, Hans Voss [EMAIL PROTECTED] wrote: Hi all, During the last couple of days I had to use the latest Ubuntu release a lot (7.10 I believe). It had the beautiful graphics from Compiz Fusion running (transparencies, desktop cube, burn on close). Now, of course this is in NO way a productivity item, but it helps to poke some eyes People tend to focus on eye candy, but the technology allows for productive improvements! Think of shrinking windows instead of iconifying them. You'd get the space you need on the desktop, yet you can see what is going on inside the window. People currently use ImageMagik to screenshot a window and then make an icon out of the image. I used to use it, but it is really slow.. With a composite manager it is a matter of directly using the image from memory, or even just paint it directly to the screen.. and after even a couple of minutes I was having withdrawal symptoms for FVWM. I tend to have them too.. Xcompmgr is the closest I get.. ;) However, I got wondering, is there anyway that fvwm might, someday, be able to use/create/do such graphical stunt work as well? (I don't want much, I know ;-). I believe the first part of the work would be to make fvwm support ARGB visuals. Then, having a proper composite manager module would be good. As for the effects, it's all in the composite manager code.. Or is this something that just cannot be done (without replicating all the work Compiz and predecessors have done)? And why we would even want that is yet another discussion all together. (I think, basically, just to poke other people (Vista users, Mac users) in the eye). As I said, the main work is in the composite manager I guess. But currently Compiz requires some hacks to be opengl accelerated, which are not wanted.. Maybe the recent EXA extension would help while the XGL server isn't ready for production.. Cheers, Renato
Re: FVWM: Fvwm vs. Compiz / Compiz Fusion
On Feb 5, 2008 4:35 PM, Dominik Vogt [EMAIL PROTECTED] wrote:
On Tue, Feb 05, 2008 at 03:51:09PM +, seventh guardian wrote:
(...)
I believe the first part of the work would be to make fvwm support
ARGB visuals. Then, having a proper composite manager module would be
good. As for the effects, it's all in the composite manager code..
Note that I have an ARGB patch lying on my disk that is more or
less an Xorg specific hack. I wasn't able to find out how to
properly detect ARGB visuals. The patch looks like this:
/* We assume that a truecolour visual of depth 32 is
* actually an ARGB visual (hard to detect otherwise)
* in this case, clone the window visual/cmap etc. */
if (
fw-attr_backup.visual-class == TrueColor
fw-attr_backup.depth == 32)
{
/* ARGB visual */
...
}
Since it's such a blatant hack I refused to apply the patch yet.
I've asked on #xorg-devel and there is a non-hackish way of doing it.
I'll try to update the patch accordingly.
Cheers,
Renato Caldas
Re: FVWM: Fvwm vs. Compiz / Compiz Fusion
On Feb 5, 2008 7:02 PM, Dominik Vogt [EMAIL PROTECTED] wrote:
On Tue, Feb 05, 2008 at 04:48:05PM +, seventh guardian wrote:
On Feb 5, 2008 4:35 PM, Dominik Vogt [EMAIL PROTECTED] wrote:
On Tue, Feb 05, 2008 at 03:51:09PM +, seventh guardian wrote:
(...)
I believe the first part of the work would be to make fvwm support
ARGB visuals. Then, having a proper composite manager module would be
good. As for the effects, it's all in the composite manager code..
Note that I have an ARGB patch lying on my disk that is more or
less an Xorg specific hack. I wasn't able to find out how to
properly detect ARGB visuals. The patch looks like this:
/* We assume that a truecolour visual of depth 32 is
* actually an ARGB visual (hard to detect otherwise)
* in this case, clone the window visual/cmap etc. */
if (
fw-attr_backup.visual-class == TrueColor
fw-attr_backup.depth == 32)
{
/* ARGB visual */
...
}
Since it's such a blatant hack I refused to apply the patch yet.
I've asked on #xorg-devel and there is a non-hackish way of doing it.
I'll try to update the patch accordingly.
Have you any written piece of information on this topic?
Only some scattered pieces, and the procedure fredrikh at
#xorg-devel described.
XGetVisualInfo returns a filtered list of supported visuals:
http://tronche.com/gui/x/xlib/utilities/XGetVisualInfo.html
http://tronche.com/gui/x/xlib/utilities/visual.html
We should filter the list for 32 bit visuals, and then iterate over
the list for visuals which have a nonzero alpha mask (which means they
have an alpha channel). The checking is done by calling
XRenderFindVisualFormat with the appropriate visual id, and checking
the returning struct for the appropriate values.
On annex is the standalone code I used for testing.
Cheers,
Renato
#include X11/Xlib.h
#include X11/Xutil.h
#include X11/extensions/Xrender.h
#include stdio.h
int main()
{
Display *dpy;
XVisualInfo *vinfo;
XVisualInfo vinfo_template;
int vinfo_n, i;
XRenderPictFormat *format;
dpy = XOpenDisplay(0);
/* change the target depth here to test */
vinfo_template.depth=32;
vinfo = XGetVisualInfo(dpy, VisualDepthMask, vinfo_template, vinfo_n);
for (i=0; ivinfo_n; i++)
{
format=XRenderFindVisualFormat(dpy, vinfo[i].visual);
if (format-type==PictTypeDirect
format-direct.alphaMask 0)
{
printf(has alpha!\n);
}
}
XFree(vinfo);
printf(%d visual(s) found\n, vinfo_n);
return 0;
}
Re: FVWM: possible FvwmConsole bug
On 8/27/07, Jonathan Kotta [EMAIL PROTECTED] wrote: If I open a console and don't type anything except CTRL-D into it, fvwm will crash. If I type something in it first (even backspace, return, etc.) it will not crash after typing CTRL-D. If I open a new console after closing the first, it will not crash. It is not just CTRL-D that triggers a crash, closing the xterm will do it as well. fvwm 2.5.21 compiled on Jun 16 2007 at 23:28:26 with support for: ReadLine, XPM, PNG, Shape, XShm, SM, Xinerama, XRender, XFT, NLS I believe it's a known bug in the module interface code. I also believe it is fixed in CVS (couldn't trigger it here). You may try it out and see.. Cheers, Renato
Re: FVWM: FVWM Environment variables
On 7/12/07, Ryan Daly [EMAIL PROTECTED] wrote: Hans Voss said: You CAN actually use them in shells and all other programs started from FVWM. (FVWM is the parent and propagates its environment to its children). I even use fvwm to set some environment variables for my shells instead of in .bashrc or some-such. I have converted my config to use the FVWM SetEnv instead of via .cshrc or the like. One issue I appear to be having, though, is that when the root user logs in, I do not see the various environment variables if I issue an 'env'. However, I do feel they're getting set because various settings (ImagePath for one) relies on these environment variables. Is there any reason why root wouldn't see these variables? If the vars are set by a user then root can't see them, and the same applies the other way round. (I guess, can't test that now..) Renato
Re: FVWM: [list admin] - Subscribe new mail address to the list
On 6/3/07, Jesús Guerrero [EMAIL PROTECTED] wrote: Hello, I am in the process of migrating to an alternate mail accound. And having some trouble, as usual in these cases. [EMAIL PROTECTED] is having some problems, mainly related to spam (I know, the name of the account doesn't help either :P ). So, I will soon close it. I want to subscribe [EMAIL PROTECTED] instead, and remove [EMAIL PROTECTED] from the three fvwm lists (announces, workers and the users list). However, I have tried at least in three ocassions and it didn't succeed for any reason. All the times I get similar messages to this one: [quote] The subscribe command did not succeed. The request subscribe fvwm Jesus Guerrero [EMAIL PROTECTED] must be confirmed. Confirmation instructions have been mailed to Jesus Guerrero [EMAIL PROTECTED] in a separate message. Valid commands processed: 1 0 succeeded, 1 stalled, and 0 failed. Use the following command: sessioninfo 6db3d68afa813e3cbb0f40432da8acb4cda9e226 to see technical information about this session. [/quote] For each one of the three lists. I don't know if this is some problem with majordomo or something. But I can't subscribe. For that same reason, I haven't still tried to unsubscribe this one ([EMAIL PROTECTED]). If someone could help, that would be nice. As I said, I want to subscribe [EMAIL PROTECTED] to the three FVWM mailing lists. Sorry if this is not a good place to ask this, but I found no other way around. My advice is that you contact Jason Tibbitts directly, since he's the one who manages the mailing list. Unless he has already seen this mail and contacted you.. Cheers, Renato
Re: FVWM: a drag
On 5/9/07, Bernard Lang [EMAIL PROTECTED] wrote: * Thomas Adam [EMAIL PROTECTED], le 09-05-07, a �crit: On Wed, May 09, 2007 at 07:15:31PM +0200, Bernard Lang wrote: I used to drag windows by pressing mouse-left on the title-bar, dragging and releasing in the right place. Oh that. Yes, that behaviour changed. If you want the old behaviour, bind the Move command in a function as you probably already had, as opposed to just binding 'Move' to something directly. I think I've understood you properly. :) but I would like to drop the window whenever I just release the mouse button, without having to click. Then see above, just bind 'Move' directly, without it being in a function. thanks for the reply I do not really understand what you mean. This is what I have Mouse 1 TS A Function Move-or-Raise AddToFunc Move-or-Raise H Move + C Raise + D RaiseLower (before I had M instead of H) How should I change it ? I could have Mouse 1 TS A Move but then I would have only a single behavior (and I am not even sure that works) I do not spend my life configuring FVWM, and going back to it is always painful ... not a criticism ... it is just that I have to relearn things. And I have been unable to understand much of the mousecommand in the manual ... especially concerning the context P. I should probably experiment ... but no time. Isn't this by any chance a laptop? I say this because people tend to use the IgnoreModifiers on desktops because they keep the numlock on. On the other hand, it doesn't make sense to keep the numlock turned on on a laptop, so this is a common issue. Remove the IgnoreModifiers directive from your config and see. Of course this doesn't apply (?) in the case of a desktop.. Cheers, Renato
Re: FVWM: Beginners-Infos /Example-Files(simple,please) ?
On 4/17/07, Oliver Bandel [EMAIL PROTECTED] wrote:
On Mon, Apr 16, 2007 at 11:22:12PM +0100, Thomas Adam wrote:
On Tue, Apr 17, 2007 at 12:14:02AM +0200, Oliver Bandel wrote:
Hello,
are there simple Beginners-Infos zu start with fvwm(2)?
http://www.zensites.net/fvwm/guide/
What I want to achieve at first, is:
- xeyes, xclock and Pager on all desktops
Then the possibility of two separated dektops
(not reachable via crossing screen-edges with the mouse)
would be fine.
DesktopSize 1x1
DestopName 0 Desk0
DesktopName 1 Desk1
EdgeScroll 0 0
What's about starting xterms?
In my Xorg-config I have entries to start some
windows; is it better todo this in the fvwm-config?
Style foo1 StartOnDesk 0
AddToFunc StartFunction I Exec exec xterm -T foo1
OK, this does not work, it must be StartsOnDesk,
notStartOnDesk.
But it does not work there is no Window
named foo1, when I start fvwm.
What is missing?
This doesn't work because your xterm is configured to change its title
to the command being run.. It's normal on some distros.
If you have this:
# Change the window title of X terminals
case $TERM in
xterm*|rxvt|Eterm|eterm)
PROMPT_COMMAND='echo -ne
\033]0;[EMAIL PROTECTED]:${PWD/$HOME/~}\007'
;;
screen)
PROMPT_COMMAND='echo -ne
[EMAIL PROTECTED]:${PWD/$HOME/~}\033\\'
;;
esac
or something like this in your ~/.bashrc you could try commenting it.
Then setting the title to foo1 should work..
Cheers,
Renato
Re: FVWM: Beginners-Infos /Example-Files(simple,please) ?
On 4/16/07, Oliver Bandel [EMAIL PROTECTED] wrote: On Mon, Apr 16, 2007 at 11:22:12PM +0100, Thomas Adam wrote: On Tue, Apr 17, 2007 at 12:14:02AM +0200, Oliver Bandel wrote: Hello, are there simple Beginners-Infos zu start with fvwm(2)? http://www.zensites.net/fvwm/guide/ What I want to achieve at first, is: - xeyes, xclock and Pager on all desktops Then the possibility of two separated dektops (not reachable via crossing screen-edges with the mouse) would be fine. DesktopSize 1x1 DestopName 0 Desk0 DesktopName 1 Desk1 EdgeScroll 0 0 [...] But when I also want to have desktops, reachable via a mouse that crosses the edges of a screen? DesktopSize 3x3 DestopName 0 Desk0 DesktopName 1 Desk1 EdgeScroll 100 100 Can this be mixed, or do I have to decide between these two options? Lots of things can be done, but you need to take a look at the documentation. Don't expect us do give you an on-demand config ;) Cheers Renato
Re: FVWM: Labelling windows in the FvwmPager
On 4/5/07, Lucio Chiappetti [EMAIL PROTECTED] wrote: On Wed, 4 Apr 2007, Parv wrote: wrote Lucio Chiappetti thusly... while for moving windows the most frequent way for me is to stick it to all pages and desks, change page, then eventually unstick it. Second choice is drag in the pager. Yet another way, similar to (un)sticking a window, is to iconify the window on the current page; switch to your destination page; uniconify previously iconified window. That's true. I forgot. The fact is that, since when I use fvwm (or any other multi-desktop Wm) I tend to iconize windows much less than I did on older single-page WMs (to make room). Actually I find a bit disturbing the feature that an iconized window belongs to all pages and desktops. My natural expectation would be that an iconized window remain quiescent just on the original page. Is there some fvmw trick to obtain that ? Style * SlipperyIcon Cheers Renato
Re: Sticky Icons (was: FVWM: Labelling windows in the FvwmPager)
On 4/5/07, Lucio Chiappetti [EMAIL PROTECTED] wrote: On Thu, 5 Apr 2007, Rainer Koehler wrote: Actually I find a bit disturbing the feature that an iconized window belongs to all pages and desktops. Sure, just _don't_ use the style option StickyIcon ;-) Thanks to everybody who replied. In fact I had StickyIcon in an unedited part of the .fvwm2rc inherited from the SuSE default configuration. Apparently commenting that out, or using Style * SlipperyIcon (is there any difference ?) reverts back to the sensible default behaviour. SlipperyIcon is the deprecated negation of StickyIcon. You should use !StickyIcon instead, it's the same thing. I've just dug it up from my config file, sorry for the outdated info :) Cheers, Renato
Re: FVWM: FVWM and KDM
On 3/16/07, Arvin Schnell [EMAIL PROTECTED] wrote: Hi, since I could not find examples about controlling KDM from FVWM I figured it out myself. You can see my results here: http://arvin.schnell-web.net/linux/kdm-fvwm.html Maybe you want to include this in your examples distributed with FVWM or in your FAQ. I find this very interesting. In fact I wanted to do this back when I used kdm. Now that I use qingy I want a way to do this with it, but that's yet to be implemented, I believe. Cheers Renato
Re: FVWM: Tcl's 'Iconwindow' not working with fvwm-2.5.18-1 (repost)
On 3/13/07, Robert Heller [EMAIL PROTECTED] wrote: At Mon, 12 Mar 2007 00:04:01 + seventh guardian [EMAIL PROTECTED] wrote: Does it work when not using the module? That is, using fvwm's built-in iconbox style? I asked to see if it was a fvwm bug or just a module bug. Apparently the problem is just with the module, so things are narrowed out. This may be relevant: http://wiki.tcl.tk/270 Did not help me (other than tell me what I already know), except maybe FVWM 2.5's IconBox module just does not support icon windows, only static icon images (which is false, since it does seem to support FireFox's icon window, I think, unless FireFox is doing something terribly clever). OR Tcl is broken somehow. I really can't tell.. OK, after a bit of poking around in the FVWM 2.5.18 source code for the FvwmIconBox module (and not finding anything obvious), I'm still looking for a solution. I've created a minimual test case (binary for Linux x86 (using tclkit-linux-x86) and Tcl/Tk source code): http://www.deepsoft.com/minimualiconwindow-0.0-linux.tar.gz http://www.deepsoft.com/minimualiconwindow-0.0.tar.gz If anyone who knows the inner workings of the FvwmIconBox module AND knows about Tcl/Tk iconwindow functionallity can figure out what is going on, it would be helpful... I don't fit in any of those, but I can check the module's code. But I'm a bit (..ok, a lot! ) busy this month.. Cheers, Renato Caldas
Re: FVWM: FVWM should be shipped with...
On 3/13/07, Dedeco [EMAIL PROTECTED] wrote: One can easily install it to $HOME in those rare cases the sysadmin refuses to install it globally. Think about QUOTA spaces. Not the best, IMO. I personally have fvwm-cvs along with several other apps installed in my 50M quota at the university. 50M is really little space, specially considering you have all your configs/works there, but you can be clever. I have all the apps compressed upon logout and decompressed to /tmp upon login. Then I have the install prefix ($HOME/apps) linked to /tmp/apps, so everything should work perfectly. Or it should, if the sysadmins weren't so dumb (window$ fans..) that the computer freezes from time to time due to nfs connectivity problems. They can really get unusable, specially under heavy network load, so I finally decided to invest in a laptop. Too bad the course is almost finished So it's really just a matter of finding clever solutions to deal with dumb admins :) Cheers, Renato Caldas
Re: FVWM: Tcl's 'Iconwindow' not working with fvwm-2.5.18-1 (repost)
Please do not repost.. (and sorry for the delay) On 2/21/07, Robert Heller [EMAIL PROTECTED] wrote: I use several Tcl/Tk programs (exmh, plus some homegrown ones) that use Tcl's 'iconwindow' function to create dynamic window manager icons. I also use FVWM's IconBox module. Does it work when not using the module? That is, using fvwm's built-in iconbox style? For some reason, those applications that use Tcl's 'iconwindow' function, don't get their proper icons in the IconBox. Instead they get the 'default' generic icon. This *used* to work just fine back when I was using fvwm-2.4.mumble. What has changed? Do I need to add something to my .fvwmrc file? This may be relevant: http://wiki.tcl.tk/270 Cheers Renato
Re: FVWM: Extern build Fvwm-Modules
On 3/2/07, Thomas Adam [EMAIL PROTECTED] wrote: On Fri, 2 Mar 2007 17:22:59 +0100 Michelle Konzack [EMAIL PROTECTED] wrote: Currently I am coding an FvwmOsd (On Screen Display), which I need This was already done I believe: http://home.gna.org/felidae/FvwmOsd.html The link is dead.. Cheers, Renato
Re: FVWM: Extern build Fvwm-Modules
On 2/26/07, Michelle Konzack [EMAIL PROTECTED] wrote: Am 2007-02-21 17:53:27, schrieb Thomas Adam: On 21/02/07, Michelle Konzack [EMAIL PROTECTED] wrote: Hello *, I have coded some Fvwm-Moduled for Embedded-Systems (used in my Motor- caravan) and it is the hell to include it always in the original Source and compile the whole thing from scratch... It takes ages!!! Is this using the C bindings, or Perl bindings? It seems you have not understood me... If I have the source of a new Fvwm* Module I need to put it into the OriginalSource and add it so it get all the Headers... Do you just need the headers? Or do you also need functions from fvwmlib? But this mean, I have tho compile the WHOLE fvwm including my Fvwm* Module which is written in C. If you need functions from fvwmlib, then you obviously need it compiled. And it does take time, no workaround for that (fvwm IS fvwmlib plus some specific stuff). Unless the debian maintainer includes the fvwmlib library in the deb file (which is not correct to do right now anyway). Maybe in the future fvwmlib (or sub-libraries) will be suited to be installed. But as it is now, it's not meant for that. Why? You don't need one. Just downloading the FVWM source from fvwm.org is sufficient, given that one just has to: If I have only the right header the fvwm* Module can be compiled in 10-15 seconds Then do it that way. No need to make simple things difficult. Right and if I want to compile it outside of fvwm I need forcement the hneccesary eaders. I wanted to make a module communication library some time ago. Maybe after the module communication stuff is cleaned up I'll do so.. Right now I'm a bit out of time. Cheers Renato
Re: FVWM: Passing keys through FVWM
On 2/8/07, Perry Hutchison [EMAIL PROTECTED] wrote: I have a Linux system in a VM host. When I have the console up and I need to send the VM host a ctrl-alt-f4 (or similar), my local desktop intercepts those keys and sends me to the 4th TTY. Is there a way to have FVWM ignore that and just pass it through? AFAIK, the CtrlAltFx combinations are picked off by the console driver and used to switch virtual consoles before anything in X (including FVWM) sees them. I'd suggest checking the docs for the virtual console subsystem to see if it can be set to use a different key combination (or maybe you can find a way to exclude virtual console support from your Linux configuration). No, it's trapped by the X server and sent to the console driver. You can disable it in the xorg.conf file. Just put Option DontVTSwitch in the Server Flags section of your xorg,conf and it will ignore those keys. So they will be passed to the applications instead. Unless you want to keep the ability to switch vts, so then you would need to remap some other key combination to send fake ctrl+alt+f4 key strokes to the host. You would do that the way Thomas Adam suggested. Cheers Renato
Re: FVWM: window placement preference
On 1/25/07, Dominik Vogt [EMAIL PROTECTED] wrote: On Tue, Jan 23, 2007 at 12:04:13PM -0500, Emilie Ann Phillips wrote: Is it possible to have windows default placement to be at the center of the page, Sure, with CenterPlacement. and then cascade rather than from left to right? I don't understand what you want. Is it this? (image in annex) Cheers Renato cascade.png Description: PNG image
Re: FVWM: procedure for configuring FVWM with Fedora-5
On 10/14/06, stan mcintosh [EMAIL PROTECTED] wrote: I have installed the RPM, but cannot get FVWM to show as one of the session choices when logging in. After spending some time searching list archives and with Dogpile, I am asking if someone here knows of a tutorial on getting FVWM to show as one of the login WM options. This is not the concern of fvwm, so it depends on the dm, like Thomas said. You can just put exec fvwm on a file called .xsession in your homedir and then run startx. Or you can use the suggestion from Leo for some dm (is it kdm? I have no idea...). Searching your dm's documentation is the way to go. I personally use qingy, which uses yet another method of storing the session info.. Cheers Renato Thanks. stan mcintosh
Re: FVWM: Mouse related questions
On 10/13/06, me again me [EMAIL PROTECTED] wrote: Look at the CursorMove and WarpToWindow commands. Sorry I wasn't clear. I meant: a way of issuing commands using only the mouse( no keyboard ), like edgecommand Or mousebutton as modifier Or DestroyFunc winmou AddToFunc winmou + M WindowList -50p +0p Mouse 2 A N winmou But do you want to issue those commands by a middle-click? Then how do you expect to choose between paste and the defined command? Are you sure this isn't a numlock issue? Positive, this is not related to numlock . See this post please (if you haven't) http://www.mail-archive.com/fvwm@lists.math.uh.edu/msg7.html - Can you be more specific about this? About what ? Khotkeys? khotkeys allows the use of the middle mouse button for making mouse gestures while retaining the middle-click to paste feature and other middle click features. Yes, but then it uses the middle mouse drag, which is not the middle mouse click. Cheers Renato
Re: [patch]: detecting gdk-imlib11 by configure
On 9/4/06, Harald Dunkel [EMAIL PROTECTED] wrote: seventh guardian wrote: I see your point, and I agree that things may not be working correctly. But what you did is a hack. You just changed the test program to detect imlib when it is not there. Even if it works that way, it should be done properly. Probably a cleanup would be good.. There's a bunch of dup/unused code in that file.. Since no part of fvwm (except for acinclude.m4) makes use of imlib-dev, would it be OK to remove the tests for imlib-dev in acinclude.m4 (afap), and keep just the tests for gdk-imlib-dev? Just to reduce the number of lines of code to cleanup? Its not that simple, acinclude is a bunch of functions included by configure.ac. Both files would need to be revised. But the idea is correct: to remove the tests for imlib and cleanup the ones for gdk-imlib. Any second opinions about this? Cheers Renato Regards Harri
Re: [patch]: detecting gdk-imlib11 by configure
On 9/4/06, Dominik Vogt [EMAIL PROTECTED] wrote: On 9/4/06, Harald Dunkel [EMAIL PROTECTED] wrote: seventh guardian wrote: I see your point, and I agree that things may not be working correctly. But what you did is a hack. You just changed the test program to detect imlib when it is not there. Even if it works that way, it should be done properly. Probably a cleanup would be good.. There's a bunch of dup/unused code in that file.. Since no part of fvwm (except for acinclude.m4) makes use of imlib-dev, would it be OK to remove the tests for imlib-dev in acinclude.m4 (afap), and keep just the tests for gdk-imlib-dev? Just to reduce the number of lines of code to cleanup? Its not that simple, acinclude is a bunch of functions included by configure.ac. Both files would need to be revised. But the idea is correct: to remove the tests for imlib and cleanup the ones for gdk-imlib. Any second opinions about this? If we really do not use implib I'm all for removing the test. It's causing endless troubles for me. Ok, done. It's strange, but it seems that the imlib test macro was realy never used! So it's strange how it affected the compilation under Debian.. Harald does it work now? Cheers Renato Ciao Dominik ^_^ ^_^ -- Feel free – 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
Re: [patch]: detecting gdk-imlib11 by configure
On 9/3/06, Harald Dunkel [EMAIL PROTECTED] wrote:
Hi folks,
Of course I haven't tried all different Linux distros. but
for Debian Etch I have to apply the appended patch to make
detecting gdk-imlib11 work. imlib11 (without gdk-)
does not seem to be necessary. Imlib.h doesn't appear
anywhere in the code, except for acinclude.m4.
You are changing what I believe is the test for Imlib. There is
already a test for gdk_imlib bellow (which also includes gdk_imlib.h),
but I don't know why it doesn't work for you..
Is this patch OK? Could somebody please verify and apply?
Of course the patched fvwm built cleanly (at least on my
Debian box).
I think you are doing the wrong thing, as you are tricking the
system to inclue gdk_imlib when it detects plain imlib. You should try
to figure out why it isn't detecting gdk_imlib..
Cheers
Renato
Many thanx
Harri
Before:
FVWM Configuration:
Version: 2.5.18 (from cvs)
Executables: /usr/local/bin
Man pages: /usr/local/man
Modules: /usr/local/libexec/fvwm/2.5.18
Data files: /usr/local/share/fvwm
Perl lib:/usr/local/share/fvwm/perllib
Locale msg: /usr/local/share/locale ar de fr sv_SE zh_CN
With Asian bi-direct. text support? yes
With Gettext Native Lang support? yes (libc)
With GTK+ required for FvwmGtk? yes
With GDK image support in FvwmGtk? no: Failed on gdk-imlib, see config.log
With GNOME libs support in FvwmGtk? yes
With Iconv support? yes (from C library)
With Mouse strokes (gestures)? yes
With PNG image support? yes
With ReadLine sup. in FvwmConsole? yes
With RPlay support in FvwmEvent?yes
With Shaped window support? yes
With Shared memory for XImage? yes
With Session Management support?yes
With Xinerama multi-head support? yes
With Xft anti-alias font support? yes (version 2)
With XPM image support? yes
With Xrender image support? yes
After:
FVWM Configuration:
Version: 2.5.18 (from cvs)
Executables: /usr/local/bin
Man pages: /usr/local/share/man
Modules: /usr/local/libexec/fvwm/2.5.18
Data files: ${prefix}/share/fvwm
Perl lib:${prefix}/share/fvwm/perllib
Locale msg: ${prefix}/share/locale ar de fr sv_SE zh_CN
With Asian bi-direct. text support? yes
With Gettext Native Lang support? yes (libc)
With GTK+ required for FvwmGtk? yes
With GDK image support in FvwmGtk? yes
With GNOME libs support in FvwmGtk? yes
With Iconv support? yes (from C library)
With Mouse strokes (gestures)? yes
With PNG image support? yes
With ReadLine sup. in FvwmConsole? yes
With RPlay support in FvwmEvent?yes
With Shaped window support? yes
With Shared memory for XImage? yes
With Session Management support?yes
With Xinerama multi-head support? yes
With Xft anti-alias font support? yes (version 2)
With XPM image support? yes
With Xrender image support? yes
Index: acinclude.m4
===
RCS file: /home/cvs/fvwm/fvwm/acinclude.m4,v
retrieving revision 1.54
diff -u -u -r1.54 acinclude.m4
--- acinclude.m42 Mar 2006 11:38:35 - 1.54
+++ acinclude.m43 Sep 2006 14:25:08 -
@@ -589,7 +589,7 @@
AC_TRY_RUN([
#include stdio.h
#include stdlib.h
-#include Imlib.h
+#include gdk_imlib.h
ImlibImage testimage;
@@ -648,7 +648,7 @@
LIBS=$LIBS $IMLIB_LIBS
AC_TRY_LINK([
#include stdio.h
-#include Imlib.h
+#include gdk_imlib.h
], [ return 0; ],
[ echo *** The test program compiled, but did not run. This usually
means
echo *** that the run-time linker is not finding IMLIB or finding the
wrong
@@ -728,7 +728,6 @@
AC_TRY_RUN([
#include stdio.h
#include stdlib.h
-#include Imlib.h
#include gdk_imlib.h
/* migo: originally it was GdkImLibColor with incorrect spelling */
@@ -794,7 +793,6 @@
LIBS=$LIBS $GDK_IMLIB_LIBS
AC_TRY_LINK([
#include stdio.h
-#include Imlib.h
#include gdk_imlib.h
], [ return 0; ],
[ (echo *** The test program compiled, but did not run. This usually
means 5) 2/dev/null || \
Index: ChangeLog
===
RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v
retrieving revision 1.2756
diff -u -u -r1.2756 ChangeLog
--- ChangeLog 31 Aug 2006 11:36:56 - 1.2756
+++ ChangeLog 3 Sep 2006 14:25:31 -
@@ -1,3 +1,8 @@
+2006-09-03 Harald Dunkel [EMAIL PROTECTED]
+
+ * acinclude.m4:
+ drop obsolete dependency upon Imlib.h
+
2006-08-31 Dominik Vogt dominik(dot)vogt(at)gmx(dot)de
* fvwm/ewmh.c (atom_get):
Re: [patch]: detecting gdk-imlib11 by configure
On 9/3/06, Harald Dunkel [EMAIL PROTECTED] wrote: Hi Renato, seventh guardian wrote: On 9/3/06, Harald Dunkel [EMAIL PROTECTED] wrote: Hi folks, Of course I haven't tried all different Linux distros. but for Debian Etch I have to apply the appended patch to make detecting gdk-imlib11 work. imlib11 (without gdk-) does not seem to be necessary. Imlib.h doesn't appear anywhere in the code, except for acinclude.m4. You are changing what I believe is the test for Imlib. There is already a test for gdk_imlib bellow (which also includes gdk_imlib.h), but I don't know why it doesn't work for you.. On Debian (and Ubuntu?) imlib-dev and gdk-imlib-dev are seperate packages, built from the same source package. They do not rely upon each other, AFAICS. Same goes for the packages providing the runtime libraries. AFAICS fvwm doesn't make use of imlib, but of gdk-imlib. For building and running fvwm you just need gdk-imlib-dev and gdk-imlib. But to make the tests in the unpatched acinclude.m4 succeed you have to install both gdk-imlib-dev and imlib-dev, plus the appropriate runtime library packages. IMHO this is not correct. Is this patch OK? Could somebody please verify and apply? Of course the patched fvwm built cleanly (at least on my Debian box). I think you are doing the wrong thing, as you are tricking the system to inclue gdk_imlib when it detects plain imlib. You should try to figure out why it isn't detecting gdk_imlib.. The patched acinclude.m4 _does_ detect gdk-imlib. Imlib (without gdk-) is not installed on my PC, and yet I can build and run fvwm including all features, as shown in a previous post in this thread. I see your point, and I agree that things may not be working correctly. But what you did is a hack. You just changed the test program to detect imlib when it is not there. Even if it works that way, it should be done properly. Probably a cleanup would be good.. There's a bunch of dup/unused code in that file.. Cheers Renato % ldd /usr/lib/fvwm/2.5.18/FvwmGtk libSM.so.6 = /usr/lib/libSM.so.6 (0x2ae71a6d7000) libICE.so.6 = /usr/lib/libICE.so.6 (0x2ae71a7e1000) libXext.so.6 = /usr/lib/libXext.so.6 (0x2ae71a8fd000) libX11.so.6 = /usr/lib/libX11.so.6 (0x2ae71aa0e000) libm.so.6 = /lib/libm.so.6 (0x2ae71abe9000) libgtk-1.2.so.0 = /usr/lib/libgtk-1.2.so.0 (0x2ae71ad6d000) libgdk-1.2.so.0 = /usr/lib/libgdk-1.2.so.0 (0x2ae71afd3000) libgmodule-1.2.so.0 = /usr/lib/libgmodule-1.2.so.0 (0x2ae71b111000) libglib-1.2.so.0 = /usr/lib/libglib-1.2.so.0 (0x2ae71b215000) libdl.so.2 = /lib/libdl.so.2 (0x2ae71b34) libXi.so.6 = /usr/lib/libXi.so.6 (0x2ae71b443000) libgdk_imlib.so.2 = /usr/lib/libgdk_imlib.so.2 (0x2ae71b54c000) libc.so.6 = /lib/libc.so.6 (0x2ae71b671000) libXau.so.6 = /usr/lib/libXau.so.6 (0x2ae71b8ad000) libXdmcp.so.6 = /usr/lib/libXdmcp.so.6 (0x2ae71b9b) /lib64/ld-linux-x86-64.so.2 (0x2ae71a5bf000) % dpkg-query -S libgdk_imlib.so.2 gdk-imlib11: /usr/lib/libgdk_imlib.so.2 gdk-imlib11: /usr/lib/libgdk_imlib.so.2.0.0 Regards Harri
Re: some 64bit cleanup on CVS head (XGetWindowProperty())
On 9/1/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Thu, Aug 31, 2006 at 04:13:56PM +0100, seventh guardian wrote: On 8/31/06, Harald Dunkel [EMAIL PROTECTED] wrote: There is another broken call to XGetWindowProperty() in ewmh.c, which seems to have been introduced recently. Attached is the patch. I guess it was already corrected? I've tried the patch, but it seemed that the changes were already there.. That's because I already committed the fix. There should have been a CVS mail about it. Ops yes, there was :) it was the same as the map/unmap fix, so it went unnoticed.. Cheers Renato Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFE+GAtmeSprTOr4tgRAlpCAJ9e0ESoydohPvZ2UdLswvRB098nlQCghrGF O9D38PibCnYKn/Ie6ns7UQ8= =E3+w -END PGP SIGNATURE-
Re: some 64bit cleanup on CVS head (XGetWindowProperty())
On 8/31/06, Harald Dunkel [EMAIL PROTECTED] wrote: There is another broken call to XGetWindowProperty() in ewmh.c, which seems to have been introduced recently. Attached is the patch. I guess it was already corrected? I've tried the patch, but it seemed that the changes were already there.. Cheers Renato Hope this helps. Regards Harri --- fvwm-snap-20060830/fvwm/ewmh.c~ 2006-08-30 10:00:03.0 +0200 +++ fvwm-snap-20060830/fvwm/ewmh.c 2006-08-31 08:16:41.0 +0200 @@ -394,7 +394,7 @@ retval = NULL; length = 0x7fff; ok = XGetWindowProperty( - dpy, win, to_get, 0, length, False, type, type_ret, + dpy, win, to_get, 0L, length, False, type, type_ret, format_ret, num_ret, bytes_after, retval); if ((ok == Success) (retval) (num_ret 0) (format_ret 0))
Re: some 64bit cleanup on CVS head (XGetWindowProperty())
On 8/31/06, Harald Dunkel [EMAIL PROTECTED] wrote: Hi Renato, The snapshot of today still uses 0 instead of 0L in the argument list for XGetWindowProperty. Maybe you have a modified version, or you are working on a different branch? I've updated now from cvs, and it uses 0L... Maybe the snapshot is outdated. Probably tomorrow it gets updated. (?) BTW, if you are actively working on fvwm, I sugest you use cvs instead of the snapshots. There are times when there is no activity at all, but there are also times where several changes are made in a few hours. It usually pays off to work with the latest code. Cheers Renato PS: Please reply to the list! Yeah, sometimes it happens to me too :) Regards Harri == seventh guardian wrote: On 8/31/06, Harald Dunkel [EMAIL PROTECTED] wrote: There is another broken call to XGetWindowProperty() in ewmh.c, which seems to have been introduced recently. Attached is the patch. I guess it was already corrected? I've tried the patch, but it seemed that the changes were already there.. Cheers Renato Hope this helps. Regards Harri --- fvwm-snap-20060830/fvwm/ewmh.c~ 2006-08-30 10:00:03.0 +0200 +++ fvwm-snap-20060830/fvwm/ewmh.c 2006-08-31 08:16:41.0 +0200 @@ -394,7 +394,7 @@ retval = NULL; length = 0x7fff; ok = XGetWindowProperty( - dpy, win, to_get, 0, length, False, type, type_ret, + dpy, win, to_get, 0L, length, False, type, type_ret, format_ret, num_ret, bytes_after, retval); if ((ok == Success) (retval) (num_ret 0) (format_ret 0)) -- Dipl.-Ing. Harald Dunkel | The bureaucratic mentality is Muehlenbachstr. 3| the only constant in universe. 52134 Herzogenrath, Germany | +49 2407 565 105 | Dr. Leonard (Bones) McCoy
Re: some 64bit cleanup on CVS head (XGetWindowProperty())
On 8/31/06, seventh guardian [EMAIL PROTECTED] wrote: On 8/31/06, Harald Dunkel [EMAIL PROTECTED] wrote: Hi Renato, The snapshot of today still uses 0 instead of 0L in the argument list for XGetWindowProperty. Maybe you have a modified version, or you are working on a different branch? I've updated now from cvs, and it uses 0L... Maybe the snapshot is outdated. Probably tomorrow it gets updated. (?) BTW, if you are actively working on fvwm, I sugest you use cvs instead of the snapshots. There are times when there is no activity at all, but there are also times where several changes are made in a few hours. It usually pays off to work with the latest code. Also, it helps with the network traffic. With cvs you only download what changes, while with the snapshot you download the full fvwm code every time.. Renato Cheers Renato PS: Please reply to the list! Yeah, sometimes it happens to me too :) Regards Harri == seventh guardian wrote: On 8/31/06, Harald Dunkel [EMAIL PROTECTED] wrote: There is another broken call to XGetWindowProperty() in ewmh.c, which seems to have been introduced recently. Attached is the patch. I guess it was already corrected? I've tried the patch, but it seemed that the changes were already there.. Cheers Renato Hope this helps. Regards Harri --- fvwm-snap-20060830/fvwm/ewmh.c~ 2006-08-30 10:00:03.0 +0200 +++ fvwm-snap-20060830/fvwm/ewmh.c 2006-08-31 08:16:41.0 +0200 @@ -394,7 +394,7 @@ retval = NULL; length = 0x7fff; ok = XGetWindowProperty( - dpy, win, to_get, 0, length, False, type, type_ret, + dpy, win, to_get, 0L, length, False, type, type_ret, format_ret, num_ret, bytes_after, retval); if ((ok == Success) (retval) (num_ret 0) (format_ret 0)) -- Dipl.-Ing. Harald Dunkel | The bureaucratic mentality is Muehlenbachstr. 3| the only constant in universe. 52134 Herzogenrath, Germany | +49 2407 565 105 | Dr. Leonard (Bones) McCoy
Re: Tracking flag changes from modules
On 8/23/06, Jacob Bachmeyer [EMAIL PROTECTED] wrote: Dominik Vogt wrote: On Tue, Aug 08, 2006 at 04:31:00PM +0100, Thomas Adam wrote: On Tue, 8 Aug 2006 16:18:41 +0100 seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes there could be provided a command that the modules could use to request an alias. This way the module would parse the command line alias options and request the attribution of an alias. So old configs would still work properly!! :) Strange thing now looking through module_interface.c: there is already a string array called pipeAlias!! Is it possible that the infrastructure is already there?? YES! Strangely enough, the infrastructure is there!! You can actually send commands to specific aliased modules! Just use the module alias instead of the name, and voila! Except pipeAlias is never properly written. It seems that someone started the job but didn't get to finish it. The code is as good as it could be at the time Mikhael wrote it. It's not much more than a hack that tries to guess whether the first argument of a module was intended to be an alias (i.e. not an option etc.). It fails in a number of cases, but we can not do much better without rewriting the interface of some modules. So what could be the solution to the initial problem without any kind of rewrite? There isn't, I'm afraid. I can perfectly understand and see the logic behind why the flags should be sent in the packet information -- however in order for there to be a solution to what you're proposing, it is going to mean a rewrite most likely. This was discussed here on this list a few months ago. If you like I will dig through the on-line archives for you. But there is a soulution. Extend the config win packet with a flag that indicated whether a window can be moved by the user, i.e. the return code of the function that determines whether the window can be moved or not. As a possibility for 3.0, could the module interface be reworked perhaps more extensively? I had an idea for an ICE-based module interface that would, if well done, be more flexible and extensible than the current system. (It's biggest change would be that modules would no longer need to be children of the fvwm process.) It could solve this problem by defining a query-flag operation, with an upward-compatible way of specifying flags. FVWM already links libICE (session management uses it), so this wouldn't add much to the size of the running process. Is the time right to start discussing major changes for 3.0, or should I hold this a while longer? This may not be the right time to start the final discussion, but I guess no one will complain about us spaming the fvwm mailing list :P As for this discussion, IMHO the best thing to do first is to abstract ourselves from the actual communication method. We first define an interface over a generic bidirectional stream, then we can implement it over any kind of mechanisms. Being it pipes, ICE, DBUS, dynamic loaded libraries, TCP/IP. If we manage to work out a good abstract interface, it wouldn't be hard to implement it using ICE.. Cheers Renato
Re: FVWM: DjView fullscreen issue
On 8/11/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: On Thu, Aug 10, 2006 at 01:56:48PM +0100, seventh guardian wrote: After some messing around with qmake and the generated makefile I managed to compile the program (having both qt3 and qt4 installed gets messy..). There's one catch with it, which makes it impossible to test for the problem with djview: it already starts as fullscreen. It should be started in a normal window and then asked to go fullscreen. This way we get to see if fvwm reparents the window or not.. BTW, DjView can also be initially started in fullscreen mode: djview -fs /path/to/document.djvu. Unfortunately, it is also not working under FVWM. Yes it is! I tryed the above command and it went fullscreen without any problem. The problem appeared when I tryed to exit fullscreen mode, because then fvwm reparented the window, and it kept its full screen size.. So, the question remains, why did fvwm reparent the window.. Dominik can you help us with this? Cheers Renato http://doc.trolltech.com/3.3/qwidget.html#showFullScreen There is this in the online documentation: quote Full-screen mode works fine under Windows, but has certain problems under X. These problems are due to limitations of the ICCCM protocol that specifies the communication between X11 clients and the window manager. ICCCM simply does not understand the concept of non-decorated full-screen windows. Therefore, the best we can do is to request a borderless window and place and resize it to fill the entire screen. Depending on the window manager, this may or may not work. The borderless window is requested using MOTIF hints, which are at least partially supported by virtually all modern window managers. /quote I think MOTIF hints are implemented in FVWM as Style 'MwmDecor': MwmDecor makes fvwm attempt to recognize and respect the mwm decoration hints that applications occasionally use. To switch this style off, use the NoDecorHint style. But setting it on/off don't have any effect on discussed application. Bye -- 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
Re: FVWM: DjView fullscreen issue
On 8/11/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: On Thu, Aug 10, 2006 at 01:56:48PM +0100, seventh guardian wrote: After some messing around with qmake and the generated makefile I managed to compile the program (having both qt3 and qt4 installed gets messy..). There's one catch with it, which makes it impossible to test for the problem with djview: it already starts as fullscreen. It should be started in a normal window and then asked to go fullscreen. This way we get to see if fvwm reparents the window or not.. BTW, DjView can also be initially started in fullscreen mode: djview -fs /path/to/document.djvu. Unfortunately, it is also not working under FVWM. Yes it is! I tryed the above command and it went fullscreen without any problem. The problem appeared when I tryed to exit fullscreen mode, because then fvwm reparented the window, and it kept its full screen size.. So, the question remains, why did fvwm reparent the window.. Dominik can you help us with this? Cheers Renato http://doc.trolltech.com/3.3/qwidget.html#showFullScreen There is this in the online documentation: quote Full-screen mode works fine under Windows, but has certain problems under X. These problems are due to limitations of the ICCCM protocol that specifies the communication between X11 clients and the window manager. ICCCM simply does not understand the concept of non-decorated full-screen windows. Therefore, the best we can do is to request a borderless window and place and resize it to fill the entire screen. Depending on the window manager, this may or may not work. The borderless window is requested using MOTIF hints, which are at least partially supported by virtually all modern window managers. /quote I think MOTIF hints are implemented in FVWM as Style 'MwmDecor': MwmDecor makes fvwm attempt to recognize and respect the mwm decoration hints that applications occasionally use. To switch this style off, use the NoDecorHint style. But setting it on/off don't have any effect on discussed application. Bye -- 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
Re: FVWM: DjView fullscreen issue
On 8/10/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, On Wed, Aug 09, 2006 at 02:21:12PM +0100, seventh guardian wrote: On 8/9/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, Renato, On Wed, Aug 09, 2006 at 12:40:18AM +0100, seventh guardian wrote: Small notice: kate uses qt4, while djview uses qt3!! Serge, what were you compiling your app against? qt 3 or 4? Both sample app DjView were compiled against Qt 3.3.6. Very well.. I'll try kate-3.. Could you send me the sample app? See attached source file. It is very simple, but it proves that showFullScreen() method of Qt toolkit works fine with FVWM. See its description in Qt documentation: file:///usr/qt/3/doc/html/qwidget.html#showFullScreen After some messing around with qmake and the generated makefile I managed to compile the program (having both qt3 and qt4 installed gets messy..). There's one catch with it, which makes it impossible to test for the problem with djview: it already starts as fullscreen. It should be started in a normal window and then asked to go fullscreen. This way we get to see if fvwm reparents the window or not.. http://doc.trolltech.com/3.3/qwidget.html#showFullScreen There is this in the online documentation: quote Full-screen mode works fine under Windows, but has certain problems under X. These problems are due to limitations of the ICCCM protocol that specifies the communication between X11 clients and the window manager. ICCCM simply does not understand the concept of non-decorated full-screen windows. Therefore, the best we can do is to request a borderless window and place and resize it to fill the entire screen. Depending on the window manager, this may or may not work. The borderless window is requested using MOTIF hints, which are at least partially supported by virtually all modern window managers. /quote Can someone more comfortable with fvwm's internals give their opinion on the implications of this? On the other hand and after looking at djview's code, things get a bit messy because djview also uses direct X calls! The problem can be an interaction between these calls and those from qt. So lets first check why is fvwm reparenting the window, and only then consider submitting a report upstream. Any ideas on how to check this out? It would be best to deal with this in the workers list now. Cheers Renato Bye 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
Re: FVWM: DjView fullscreen issue
On 8/10/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, On Wed, Aug 09, 2006 at 02:21:12PM +0100, seventh guardian wrote: On 8/9/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, Renato, On Wed, Aug 09, 2006 at 12:40:18AM +0100, seventh guardian wrote: Small notice: kate uses qt4, while djview uses qt3!! Serge, what were you compiling your app against? qt 3 or 4? Both sample app DjView were compiled against Qt 3.3.6. Very well.. I'll try kate-3.. Could you send me the sample app? See attached source file. It is very simple, but it proves that showFullScreen() method of Qt toolkit works fine with FVWM. See its description in Qt documentation: file:///usr/qt/3/doc/html/qwidget.html#showFullScreen After some messing around with qmake and the generated makefile I managed to compile the program (having both qt3 and qt4 installed gets messy..). There's one catch with it, which makes it impossible to test for the problem with djview: it already starts as fullscreen. It should be started in a normal window and then asked to go fullscreen. This way we get to see if fvwm reparents the window or not.. http://doc.trolltech.com/3.3/qwidget.html#showFullScreen There is this in the online documentation: quote Full-screen mode works fine under Windows, but has certain problems under X. These problems are due to limitations of the ICCCM protocol that specifies the communication between X11 clients and the window manager. ICCCM simply does not understand the concept of non-decorated full-screen windows. Therefore, the best we can do is to request a borderless window and place and resize it to fill the entire screen. Depending on the window manager, this may or may not work. The borderless window is requested using MOTIF hints, which are at least partially supported by virtually all modern window managers. /quote Can someone more comfortable with fvwm's internals give their opinion on the implications of this? On the other hand and after looking at djview's code, things get a bit messy because djview also uses direct X calls! The problem can be an interaction between these calls and those from qt. So lets first check why is fvwm reparenting the window, and only then consider submitting a report upstream. Any ideas on how to check this out? It would be best to deal with this in the workers list now. Cheers Renato Bye 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
Re: FVWM: Environment variable referencing
On 8/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: All: I just installed Fedora Core 5, and am now seeing strange behavior. When starting the X session with 'startx', things are fine. When I log in through XDM, I see the following: [FVWM][Read]: ERROR file '$[FVWM_DATADIR]/.fvwm/conf.d/fvwm2rc.functions' not found in /root/.fvwm or /usr/share/fvwm [FVWM][Read]: ERROR file '$[FVWM_DATADIR]/.fvwm/conf.d/fvwm2rc.pager' not found in /root/.fvwm [FVWM][Read]: ERROR file '$[FVWM_DATADIR]/.fvwm/conf.d/fvwm2rc.menu' not found in /root/.fvwm or /usr/share/fvwm As a general linux advice, you shouldn't be logging in to X as root! Allways use a normal user account, and if required, su for root access from within a console. Renato FVWM_DATADIR is defined as /usr/share/fvwm. This worked fine before upgrading to FC5. Is the problem with FVWM or something else? I'm at a loss... Thanks! --
Re: CVS griph: * make non-icon mode pager use fvwm command for moving
On 8/9/06, Viktor Griph [EMAIL PROTECTED] wrote: On Wed, 9 Aug 2006, FVWM CVS wrote: * don't add title height and border width to coordinates on pager move I think that this chagen is correct. I did some tests without it, and is seems as if high-title windows would slip down the screen without it. At least it was definately wrong for TitleAtLeft/Right styles. I #if 0:ed the code, so someone else can look at it and see if I'm correct in that it was incorrect before. I've noticed another problem with my icons. They are usually on the bottom left corner of the screen, and in the pager they are a bit lower (partialy in the screen bellow). This may mean the coordinates sent from fvwm are not being correctly used by the pager. This may be part of the problem above. Cheers Renato /Viktor
Re: FVWM: DjView fullscreen issue
On 8/9/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, Renato, On Wed, Aug 09, 2006 at 12:40:18AM +0100, seventh guardian wrote: Small notice: kate uses qt4, while djview uses qt3!! Serge, what were you compiling your app against? qt 3 or 4? Both sample app DjView were compiled against Qt 3.3.6. Very well.. I'll try kate-3.. Could you send me the sample app? Cheers Renato Bye -- 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
Re: FVWM: DjView fullscreen issue
On 8/9/06, seventh guardian [EMAIL PROTECTED] wrote: On 8/9/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, Renato, On Wed, Aug 09, 2006 at 12:40:18AM +0100, seventh guardian wrote: Small notice: kate uses qt4, while djview uses qt3!! Serge, what were you compiling your app against? qt 3 or 4? Both sample app DjView were compiled against Qt 3.3.6. Very well.. I'll try kate-3.. Could you send me the sample app? OOps.. kate was already using qt3.. My mistake. So why the heck is fvwm reparenting djview? :( Cheers Renato Cheers Renato Bye -- 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
Re: Tracking flag changes from modules
On 8/8/06, Viktor Griph [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006, seventh guardian wrote: On 8/7/06, Dominik Vogt [EMAIL PROTECTED] wrote: Is there any way that the module interface allows keeping track of changes to the window flags of a window? Currently FvwmPager allows moving of FixedPosition mini-windows, but the main window does not move. Just checking for IS_FIXED in MoveWindow doesn't work if the FixedPosition flag was set after the window was added to the pager (i.e with 'WindowStyle FixedPosition') since the flags get outdated. I've been looking some at the module interface, but I think that no message exist to indicate change in window flags. Is this correct? Actually, the window flags are part of some message, but they should not be used. Looking at a flag does not solve the problem anyway because the decision whether a window can be moved or not is much more complex (affected by a number of styles). What about providing modules a way to ask fvwm to move the windows instead of the module moving them through X calls? This way the sanity checks would be done in fvwm, leaving all these problems to the window manager. It would work the same as moving the viewport. The pager asks fvwm to move the viewport, it doesn't directly move all the windows. But it would require a rewrite of the pager, and some major changes to the fvwm code.. :( not a task for 2.5 I guess... Even so, can this be a 2.6 feature? The mechanism for asking fvwm to move a window is already there. It's just to send the Move command. However, this does not fix the problem, since there is no way for the pager to know if the move was successful or not. It could move the mini window back to te original position on button release and then send the move command and wait for a corresponding configure-package to know the new position if the window was moved. This however would cause windows jumping back and forth in the pager. Some sort of meanpath would be to add a message for ignored requests and have it have the same info as the configure window package, but that's definately a hack. Both these 'solutions' would allow the miniature window to move, but have them jump back on non-moveable windows. The best thing would be to not allow movement on non-moveable windows to start in the pager view. Well, it could work properly. Just ask for a null move (move the window to its current position) as soon as the user tries to move the miniwindow. If the command was rejected fvwm issues a simple error packet. The Pager now knows it can't move the window. If the command wasn't rejected then the pager can send the real Move command, to move the window to its new position. What about adding a command to check for movement ability (CanMove or something like this)? This way fvwm would tackle the multiple style conflicts, and the pager needed to know nothing about the actual flags and stuff. Also, no new packet would be required. It would work the same way as the above solution, so the above could be simpler. Cheers Renato
Re: Tracking flag changes from modules
On 8/8/06, Viktor Griph [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006, seventh guardian wrote: On 8/8/06, Viktor Griph [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006, seventh guardian wrote: On 8/7/06, Dominik Vogt [EMAIL PROTECTED] wrote: Is there any way that the module interface allows keeping track of changes to the window flags of a window? Currently FvwmPager allows moving of FixedPosition mini-windows, but the main window does not move. Just checking for IS_FIXED in MoveWindow doesn't work if the FixedPosition flag was set after the window was added to the pager (i.e with 'WindowStyle FixedPosition') since the flags get outdated. I've been looking some at the module interface, but I think that no message exist to indicate change in window flags. Is this correct? Actually, the window flags are part of some message, but they should not be used. Looking at a flag does not solve the problem anyway because the decision whether a window can be moved or not is much more complex (affected by a number of styles). What about providing modules a way to ask fvwm to move the windows instead of the module moving them through X calls? This way the sanity checks would be done in fvwm, leaving all these problems to the window manager. It would work the same as moving the viewport. The pager asks fvwm to move the viewport, it doesn't directly move all the windows. But it would require a rewrite of the pager, and some major changes to the fvwm code.. :( not a task for 2.5 I guess... Even so, can this be a 2.6 feature? The mechanism for asking fvwm to move a window is already there. It's just to send the Move command. However, this does not fix the problem, since there is no way for the pager to know if the move was successful or not. It could move the mini window back to te original position on button release and then send the move command and wait for a corresponding configure-package to know the new position if the window was moved. This however would cause windows jumping back and forth in the pager. Some sort of meanpath would be to add a message for ignored requests and have it have the same info as the configure window package, but that's definately a hack. Both these 'solutions' would allow the miniature window to move, but have them jump back on non-moveable windows. The best thing would be to not allow movement on non-moveable windows to start in the pager view. Well, it could work properly. Just ask for a null move (move the window to its current position) as soon as the user tries to move the miniwindow. If the command was rejected fvwm issues a simple error packet. The Pager now knows it can't move the window. If the command wasn't rejected then the pager can send the real Move command, to move the window to its new position. While this could work, it probably requires a largeer rewrite of the pager code to allow it to wait for a response from fvwm before starting the move. This resoponse can come mixed with several other messages that has to be taken care of in the normal way. What about adding a command to check for movement ability (CanMove or something like this)? This way fvwm would tackle the multiple style conflicts, and the pager needed to know nothing about the actual flags and stuff. Also, no new packet would be required. It would work the same way as the above solution, so the above could be simpler. A CanMove command is not needed, and not desireable. Instead it should be a 'Movable' conditional, which probably is quite easy to add. There is still one problem, that already affects the code somewhat: The SendToModule command can be used to send instructions back to the module on a successful test. However, it can only direct the messages by name, which mean that they might get to multiple instances of a module. Properly designed messages, in combination with the module knowing which messages it's waiting for can solve this, but it would be nice for a way for a module to uniqely define itself to fvwm as a recipent in a SendToModule command. It would be easy to uniquely identify the modules if the alias' were managed by fvwm instead of the modules. This way fvwm would know which specific module was listening on which pipe. As a (positive) side effect, modules wouldn't need to know their alias, which in turn would make the message requesting/parsing easyer. I've already suggested this, but it was said to be too complicated to be worth implementing before 2.6.. Things that needed to change: -Change of the module interface code in fvwm. -Add a command/style to specify the module alias in the config file. - VISIBLE (new feature) -Minor changes to the module's config parsing code. -The module's parsing cmd line options (now reject the alias options). - VISIBLE (could break backward-compatibility) As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes
Re: Tracking flag changes from modules
On 8/8/06, seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Viktor Griph [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006, seventh guardian wrote: On 8/8/06, Viktor Griph [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006, seventh guardian wrote: On 8/7/06, Dominik Vogt [EMAIL PROTECTED] wrote: Is there any way that the module interface allows keeping track of changes to the window flags of a window? Currently FvwmPager allows moving of FixedPosition mini-windows, but the main window does not move. Just checking for IS_FIXED in MoveWindow doesn't work if the FixedPosition flag was set after the window was added to the pager (i.e with 'WindowStyle FixedPosition') since the flags get outdated. I've been looking some at the module interface, but I think that no message exist to indicate change in window flags. Is this correct? Actually, the window flags are part of some message, but they should not be used. Looking at a flag does not solve the problem anyway because the decision whether a window can be moved or not is much more complex (affected by a number of styles). What about providing modules a way to ask fvwm to move the windows instead of the module moving them through X calls? This way the sanity checks would be done in fvwm, leaving all these problems to the window manager. It would work the same as moving the viewport. The pager asks fvwm to move the viewport, it doesn't directly move all the windows. But it would require a rewrite of the pager, and some major changes to the fvwm code.. :( not a task for 2.5 I guess... Even so, can this be a 2.6 feature? The mechanism for asking fvwm to move a window is already there. It's just to send the Move command. However, this does not fix the problem, since there is no way for the pager to know if the move was successful or not. It could move the mini window back to te original position on button release and then send the move command and wait for a corresponding configure-package to know the new position if the window was moved. This however would cause windows jumping back and forth in the pager. Some sort of meanpath would be to add a message for ignored requests and have it have the same info as the configure window package, but that's definately a hack. Both these 'solutions' would allow the miniature window to move, but have them jump back on non-moveable windows. The best thing would be to not allow movement on non-moveable windows to start in the pager view. Well, it could work properly. Just ask for a null move (move the window to its current position) as soon as the user tries to move the miniwindow. If the command was rejected fvwm issues a simple error packet. The Pager now knows it can't move the window. If the command wasn't rejected then the pager can send the real Move command, to move the window to its new position. While this could work, it probably requires a largeer rewrite of the pager code to allow it to wait for a response from fvwm before starting the move. This resoponse can come mixed with several other messages that has to be taken care of in the normal way. What about adding a command to check for movement ability (CanMove or something like this)? This way fvwm would tackle the multiple style conflicts, and the pager needed to know nothing about the actual flags and stuff. Also, no new packet would be required. It would work the same way as the above solution, so the above could be simpler. A CanMove command is not needed, and not desireable. Instead it should be a 'Movable' conditional, which probably is quite easy to add. There is still one problem, that already affects the code somewhat: The SendToModule command can be used to send instructions back to the module on a successful test. However, it can only direct the messages by name, which mean that they might get to multiple instances of a module. Properly designed messages, in combination with the module knowing which messages it's waiting for can solve this, but it would be nice for a way for a module to uniqely define itself to fvwm as a recipent in a SendToModule command. It would be easy to uniquely identify the modules if the alias' were managed by fvwm instead of the modules. This way fvwm would know which specific module was listening on which pipe. As a (positive) side effect, modules wouldn't need to know their alias, which in turn would make the message requesting/parsing easyer. I've already suggested this, but it was said to be too complicated to be worth implementing before 2.6.. Things that needed to change: -Change of the module interface code in fvwm. -Add a command/style to specify the module alias in the config file. - VISIBLE (new feature) -Minor changes to the module's config parsing code. -The module's parsing cmd line options (now reject the alias options). - VISIBLE (could
Re: Tracking flag changes from modules
On 8/8/06, seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Viktor Griph [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006, seventh guardian wrote: On 8/8/06, Viktor Griph [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006, seventh guardian wrote: On 8/7/06, Dominik Vogt [EMAIL PROTECTED] wrote: Is there any way that the module interface allows keeping track of changes to the window flags of a window? Currently FvwmPager allows moving of FixedPosition mini-windows, but the main window does not move. Just checking for IS_FIXED in MoveWindow doesn't work if the FixedPosition flag was set after the window was added to the pager (i.e with 'WindowStyle FixedPosition') since the flags get outdated. I've been looking some at the module interface, but I think that no message exist to indicate change in window flags. Is this correct? Actually, the window flags are part of some message, but they should not be used. Looking at a flag does not solve the problem anyway because the decision whether a window can be moved or not is much more complex (affected by a number of styles). What about providing modules a way to ask fvwm to move the windows instead of the module moving them through X calls? This way the sanity checks would be done in fvwm, leaving all these problems to the window manager. It would work the same as moving the viewport. The pager asks fvwm to move the viewport, it doesn't directly move all the windows. But it would require a rewrite of the pager, and some major changes to the fvwm code.. :( not a task for 2.5 I guess... Even so, can this be a 2.6 feature? The mechanism for asking fvwm to move a window is already there. It's just to send the Move command. However, this does not fix the problem, since there is no way for the pager to know if the move was successful or not. It could move the mini window back to te original position on button release and then send the move command and wait for a corresponding configure-package to know the new position if the window was moved. This however would cause windows jumping back and forth in the pager. Some sort of meanpath would be to add a message for ignored requests and have it have the same info as the configure window package, but that's definately a hack. Both these 'solutions' would allow the miniature window to move, but have them jump back on non-moveable windows. The best thing would be to not allow movement on non-moveable windows to start in the pager view. Well, it could work properly. Just ask for a null move (move the window to its current position) as soon as the user tries to move the miniwindow. If the command was rejected fvwm issues a simple error packet. The Pager now knows it can't move the window. If the command wasn't rejected then the pager can send the real Move command, to move the window to its new position. While this could work, it probably requires a largeer rewrite of the pager code to allow it to wait for a response from fvwm before starting the move. This resoponse can come mixed with several other messages that has to be taken care of in the normal way. What about adding a command to check for movement ability (CanMove or something like this)? This way fvwm would tackle the multiple style conflicts, and the pager needed to know nothing about the actual flags and stuff. Also, no new packet would be required. It would work the same way as the above solution, so the above could be simpler. A CanMove command is not needed, and not desireable. Instead it should be a 'Movable' conditional, which probably is quite easy to add. There is still one problem, that already affects the code somewhat: The SendToModule command can be used to send instructions back to the module on a successful test. However, it can only direct the messages by name, which mean that they might get to multiple instances of a module. Properly designed messages, in combination with the module knowing which messages it's waiting for can solve this, but it would be nice for a way for a module to uniqely define itself to fvwm as a recipent in a SendToModule command. It would be easy to uniquely identify the modules if the alias' were managed by fvwm instead of the modules. This way fvwm would know which specific module was listening on which pipe. As a (positive) side effect, modules wouldn't need to know their alias, which in turn would make the message requesting/parsing easyer. I've already suggested this, but it was said to be too complicated to be worth implementing before 2.6.. Things that needed to change: -Change of the module interface code in fvwm. -Add a command/style to specify the module alias in the config file. - VISIBLE (new
Re: Tracking flag changes from modules
On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes there could be provided a command that the modules could use to request an alias. This way the module would parse the command line alias options and request the attribution of an alias. So old configs would still work properly!! :) Strange thing now looking through module_interface.c: there is already a string array called pipeAlias!! Is it possible that the infrastructure is already there?? YES! Strangely enough, the infrastructure is there!! You can actually send commands to specific aliased modules! Just use the module alias instead of the name, and voila! Except pipeAlias is never properly written. It seems that someone started the job but didn't get to finish it. The code is as good as it could be at the time Mikhael wrote it. It's not much more than a hack that tries to guess whether the first argument of a module was intended to be an alias (i.e. not an option etc.). It fails in a number of cases, but we can not do much better without rewriting the interface of some modules. So what could be the solution to the initial problem without any kind of rewrite? The very first issue is that there is no defined way of choosing the alias. From what I see in the code, it was suposed to have the very first user argument as an alias (standard). Since some modules don't use (respect?) this, I guess the effort was undermined by the back-compat issues.. But this can be partially tackled if we add a command for the modules to request their alias in the fvwm internal data. Is it worth continuing the job? Is it safer to start an experimental side branch on this? Well, shouldn't we try to stabilise 2.5.x now, release it an then think about big changes in the module interface? Yes.. But we are constantly facing problems that would either be solved by some kind of rewrite or by hacks.. 2.5 is mostly stable. It's definitely more stable than some other release programs Cheers, Renato Ciao Dominik ^_^ ^_^ -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: FvwmIconMan: debug code cleanup
On 8/7/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, Here some documentation fixes and debug code cleanups in FvwmIconMan. Please see attached patch's ChangeLog section for more information. Hello! Your patch seems ok to me :) BTW, I've seen some references of manger replaced by manager. I guess having so many of them could mean the intended word was indeed manger. After a search in the dictionary, manger means something like a cattle pen (a fenced place where you put livestock). This would definitely fit the module, as it is indeed a fenced place for icons :) Could there have been a misunderstanding of the Man short word right in the begining? Can the original author clear this up? I'll let you all think about that :) Cheers Renato Bye. -- 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
Re: Tracking flag changes from modules
On 8/8/06, Thomas Adam [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006 16:18:41 +0100 seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes there could be provided a command that the modules could use to request an alias. This way the module would parse the command line alias options and request the attribution of an alias. So old configs would still work properly!! :) Strange thing now looking through module_interface.c: there is already a string array called pipeAlias!! Is it possible that the infrastructure is already there?? YES! Strangely enough, the infrastructure is there!! You can actually send commands to specific aliased modules! Just use the module alias instead of the name, and voila! Except pipeAlias is never properly written. It seems that someone started the job but didn't get to finish it. The code is as good as it could be at the time Mikhael wrote it. It's not much more than a hack that tries to guess whether the first argument of a module was intended to be an alias (i.e. not an option etc.). It fails in a number of cases, but we can not do much better without rewriting the interface of some modules. So what could be the solution to the initial problem without any kind of rewrite? There isn't, I'm afraid. I can perfectly understand and see the logic behind why the flags should be sent in the packet information -- however in order Should they? I don't agree. The modules shouldn't have to deal with fvwm's internals. The module interface should be as clean as possible.. As Dominik said, it is a hack. for there to be a solution to what you're proposing, it is going to mean a rewrite most likely. This was discussed here on this list a few months ago. If you like I will dig through the on-line archives for you. Well, shouldn't we try to stabilise 2.5.x now, release it an then think about big changes in the module interface? Yes.. But we are constantly facing problems that would either be solved by some kind of rewrite or by hacks.. 2.5 is mostly stable. It's definitely more stable than some other release programs There's still one or two things that need fixing before I would deem 2.5.X as a release candidate. There's no rush. :) I'd much rather see it done proper than released; pampering to the possible cries of the users that so desperately want it. :) Anything that wouldn't require a rewrite/hack? Cheers Renato -- Thomas Adam -- ThisWindow (thomas_adam) Destroy
Re: icon movement tracking
On 8/7/06, Viktor Griph [EMAIL PROTECTED] wrote: Should the flag tracking icon movement be set by MoveToPage? Currently it's not, which makes icons jump back to the initial page if do for example 'Style * IconTitle' if an icon has been moved to another page by MoveToPage. On a sidenote the same problem exists whenever moving icons with the pager, even if they are kept on the same page. I can confirm this behaviour, it's wrong IMHO. I guess the flag should be set. Cheers Renato /Viktor
Re: FvwmIconMan: debug code cleanup
On 8/8/06, Thomas Adam [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006 16:39:42 +0100 seventh guardian [EMAIL PROTECTED] wrote: On 8/7/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, Here some documentation fixes and debug code cleanups in FvwmIconMan. Please see attached patch's ChangeLog section for more information. Hello! Your patch seems ok to me :) BTW, I've seen some references of manger replaced by manager. I guess having so many of them could mean the intended word was indeed manger. After a search in the dictionary, manger means something like a cattle pen (a fenced place where you put livestock). This would definitely fit the module, as it is indeed a fenced place for icons :) Indeed -- have you never sung the Christmas carol Away in a Manger? No.. I'm portuguese.. but the word mangedoura exists here too with the same meaning :) Could there have been a misunderstanding of the Man short word right in the begining? Can the original author clear this up? It depends in what context the word 'manger' is being used (I haven't looked). It does seem awfully like a typo to me. :) Yes, but it does appear several times.. spooky :) Renato -- Thomas Adam -- ThisWindow (thomas_adam) Destroy
Re: FvwmIconMan: debug code cleanup
On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Tue, Aug 08, 2006 at 12:16:44AM +0400, Serge (gentoosiast) Koksharov wrote: Hello, Here some documentation fixes and debug code cleanups in FvwmIconMan. Please see attached patch's ChangeLog section for more information. The patch looks fine. Any volunteers to commit it? Good, I'll do it then. Cheers, Renato Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFE2NVwmeSprTOr4tgRAgWCAJ9l7GcGSKVpXC9TFus00+aIDgocpwCcC4VG IsHE3z8MgyhJdnwqv8CL+bU= =VAt2 -END PGP SIGNATURE-
Re: FvwmIconMan: debug code cleanup
On 8/8/06, seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Tue, Aug 08, 2006 at 12:16:44AM +0400, Serge (gentoosiast) Koksharov wrote: Hello, Here some documentation fixes and debug code cleanups in FvwmIconMan. Please see attached patch's ChangeLog section for more information. The patch looks fine. Any volunteers to commit it? Good, I'll do it then. BTW, do you think typo corrections should be mentioned in the changelog? I'm tempted to remove them, but need a core-dev opinion.. :) Cheers Renato Cheers, Renato Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFE2NVwmeSprTOr4tgRAgWCAJ9l7GcGSKVpXC9TFus00+aIDgocpwCcC4VG IsHE3z8MgyhJdnwqv8CL+bU= =VAt2 -END PGP SIGNATURE-
Re: Tracking flag changes from modules
On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Tue, Aug 08, 2006 at 04:31:00PM +0100, Thomas Adam wrote: On Tue, 8 Aug 2006 16:18:41 +0100 seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes there could be provided a command that the modules could use to request an alias. This way the module would parse the command line alias options and request the attribution of an alias. So old configs would still work properly!! :) Strange thing now looking through module_interface.c: there is already a string array called pipeAlias!! Is it possible that the infrastructure is already there?? YES! Strangely enough, the infrastructure is there!! You can actually send commands to specific aliased modules! Just use the module alias instead of the name, and voila! Except pipeAlias is never properly written. It seems that someone started the job but didn't get to finish it. The code is as good as it could be at the time Mikhael wrote it. It's not much more than a hack that tries to guess whether the first argument of a module was intended to be an alias (i.e. not an option etc.). It fails in a number of cases, but we can not do much better without rewriting the interface of some modules. So what could be the solution to the initial problem without any kind of rewrite? There isn't, I'm afraid. I can perfectly understand and see the logic behind why the flags should be sent in the packet information -- however in order for there to be a solution to what you're proposing, it is going to mean a rewrite most likely. This was discussed here on this list a few months ago. If you like I will dig through the on-line archives for you. But there is a soulution. Extend the config win packet with a flag that indicated whether a window can be moved by the user, i.e. the return code of the function that determines whether the window can be moved or not. Elegant enough :) Viktor will you do it? Cheers Renato Well, shouldn't we try to stabilise 2.5.x now, release it an then think about big changes in the module interface? Yes.. But we are constantly facing problems that would either be solved by some kind of rewrite or by hacks.. 2.5 is mostly stable. It's definitely more stable than some other release programs There's still one or two things that need fixing before I would deem 2.5.X as a release candidate. There's no rush. :) I'd much rather see it done proper than released; pampering to the possible cries of the users that so desperately want it. :) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFE2Nh3meSprTOr4tgRAhSYAKCtVnMulvIbWYgQDdaODNvDkH1lkACfRjuT EUZJPAB99lkRifhELOa88TI= =lp+7 -END PGP SIGNATURE-
Re: FVWM: DjView fullscreen issue
On 8/8/06, Thomas Adam [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006 23:02:40 +0400 Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: On Tue, Aug 08, 2006 at 04:45:49PM +0100, Thomas Adam wrote: Serge -- On Tue, 8 Aug 2006 15:59:10 +0400 Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, Thomas, On Mon, Aug 07, 2006 at 09:43:41PM +0100, Thomas Adam wrote: Can you attach a full xprop output for this fullscreened window, please? Sure, see attached text file. Is DjView working properly on your machine? I also tried it on another computer with FVWM which ships with SUSE 10.0, still same problems. Going fullscreen was disasterous on my machine -- all it did was to reposition the window to the bottom right and remove the menubar. It's an EWMH issue most likely -- I can't tell you much more than that. As a work around, if you completely maximise the window and then go fullscreen that seems to work OK (removing parts of the window decor is something you can do in your own time. :) You said you were using EWMHBaseStruts? You'll probably have to add the style option of: EWMHMaximizeIgnoreWorkingArea For this application, although I would assume the way FVWM handles this is to implicitly assume that when a window is being fullscreened to ignore any EWMHBaseStruts set. -- Thomas Adam -- ThisWindow (thomas_adam) Destroy So, is it some unimplemented functionality on our side, or bugs of 3rd party application? If second case, I'll try to convince its authors to make it FVWM compatible. BTW, I looked in its code, I'm not a C++ guru, but it seems to me it simply calling showFullScreen() function of Qt toolkit. I've written compiled test Qt application using this function and it worked fine under FVWM. So it's really strange why it not working... Thanks for workaround. I am not too sure who's to blame for this. Whilst not all the EWMH are supported in FVWM, given the error you have below, I can only assume this to be an error on behalf of the application. Also, while switching to and from fullscreen it periodically spits following warning to the console: QT Warning: X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 Minor opcode: 0 Resource id: 0x8018cc This makes sense to me. I don't have my Xlib programming book -- so I hope someone will correct me if I am a little inaccurate. As far as I know, BadWindow errors are typically thrown from functions that manipulate things like XSizeHints (hence as an example, the XSetWMSizeHints() function). In this case, what I assuming to tbe the error is that the window is probably trying to keep a track of its size, but fails because the parameters passed to whichever function is being used fails to specify the correct Window parameter. In this case major opcode 3 means the BadWindow error was thrown in a GetWindowAttributes request to the X server. I also get some opcode 20 (GetPropery), opcode 15 (QueryTree) and opcode 40 (TranslateCoords). I found a thing that might be the cause of the problem. When the window requests full screen it gets reparented by fvwm. (is this the correct behaviour?) But some calls are still made regarding the old fvwm parent window, which doesn't exist anymore. So the window doesn't get resized at all. You probably don't see this in a sample app because it doesn't have 7 (seven!) sub-windows :) (just do a xwininfo -children on djview) That being the case, I can only conclude it's a bug with the application. The problem is the interaction between fvwm and qt.. it's probably a matter of timing, as it gets reparented as it is being fullscreened. The app gets the parent's ID, fvwm reparents it and it then uses the outdated ID.. It can be a fvwm bug, or a qt one.. Can someone shed some light over this? Cheers Renato How correct am I with that, anyone? -- Thomas Adam -- ThisWindow (thomas_adam) Destroy
Re: FVWM: DjView fullscreen issue
On 8/9/06, seventh guardian [EMAIL PROTECTED] wrote: On 8/9/06, seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Thomas Adam [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006 23:02:40 +0400 Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: On Tue, Aug 08, 2006 at 04:45:49PM +0100, Thomas Adam wrote: Serge -- On Tue, 8 Aug 2006 15:59:10 +0400 Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, Thomas, On Mon, Aug 07, 2006 at 09:43:41PM +0100, Thomas Adam wrote: Can you attach a full xprop output for this fullscreened window, please? Sure, see attached text file. Is DjView working properly on your machine? I also tried it on another computer with FVWM which ships with SUSE 10.0, still same problems. Going fullscreen was disasterous on my machine -- all it did was to reposition the window to the bottom right and remove the menubar. It's an EWMH issue most likely -- I can't tell you much more than that. As a work around, if you completely maximise the window and then go fullscreen that seems to work OK (removing parts of the window decor is something you can do in your own time. :) You said you were using EWMHBaseStruts? You'll probably have to add the style option of: EWMHMaximizeIgnoreWorkingArea For this application, although I would assume the way FVWM handles this is to implicitly assume that when a window is being fullscreened to ignore any EWMHBaseStruts set. -- Thomas Adam -- ThisWindow (thomas_adam) Destroy So, is it some unimplemented functionality on our side, or bugs of 3rd party application? If second case, I'll try to convince its authors to make it FVWM compatible. BTW, I looked in its code, I'm not a C++ guru, but it seems to me it simply calling showFullScreen() function of Qt toolkit. I've written compiled test Qt application using this function and it worked fine under FVWM. So it's really strange why it not working... Thanks for workaround. I am not too sure who's to blame for this. Whilst not all the EWMH are supported in FVWM, given the error you have below, I can only assume this to be an error on behalf of the application. Also, while switching to and from fullscreen it periodically spits following warning to the console: QT Warning: X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 Minor opcode: 0 Resource id: 0x8018cc This makes sense to me. I don't have my Xlib programming book -- so I hope someone will correct me if I am a little inaccurate. As far as I know, BadWindow errors are typically thrown from functions that manipulate things like XSizeHints (hence as an example, the XSetWMSizeHints() function). In this case, what I assuming to tbe the error is that the window is probably trying to keep a track of its size, but fails because the parameters passed to whichever function is being used fails to specify the correct Window parameter. In this case major opcode 3 means the BadWindow error was thrown in a GetWindowAttributes request to the X server. I also get some opcode 20 (GetPropery), opcode 15 (QueryTree) and opcode 40 (TranslateCoords). I found a thing that might be the cause of the problem. When the window requests full screen it gets reparented by fvwm. (is this the correct behaviour?) But some calls are still made regarding the old fvwm parent window, which doesn't exist anymore. So the window doesn't get resized at all. You probably don't see this in a sample app because it doesn't have 7 (seven!) sub-windows :) (just do a xwininfo -children on djview) That being the case, I can only conclude it's a bug with the application. The problem is the interaction between fvwm and qt.. it's probably a matter of timing, as it gets reparented as it is being fullscreened. The app gets the parent's ID, fvwm reparents it and it then uses the outdated ID.. It can be a fvwm bug, or a qt one.. Can someone shed some light over this? Making a small test with kate (the smallest qt full-screening app I could remember) it shows that the problem is specific to djview. Even though the app window ID is the same, fvwm chooses to reparent the djview window (for no reason? There must be a reason..) and not kate. Small notice: kate uses qt4, while djview uses qt3!! Serge, what were you compiling your app against? qt 3 or 4? Renato Cheers Renato Cheers Renato How correct am I with that, anyone? -- Thomas Adam -- ThisWindow (thomas_adam) Destroy
Re: Tracking flag changes from modules
On 8/7/06, Dominik Vogt [EMAIL PROTECTED] wrote: Is there any way that the module interface allows keeping track of changes to the window flags of a window? Currently FvwmPager allows moving of FixedPosition mini-windows, but the main window does not move. Just checking for IS_FIXED in MoveWindow doesn't work if the FixedPosition flag was set after the window was added to the pager (i.e with 'WindowStyle FixedPosition') since the flags get outdated. I've been looking some at the module interface, but I think that no message exist to indicate change in window flags. Is this correct? Actually, the window flags are part of some message, but they should not be used. Looking at a flag does not solve the problem anyway because the decision whether a window can be moved or not is much more complex (affected by a number of styles). What about providing modules a way to ask fvwm to move the windows instead of the module moving them through X calls? This way the sanity checks would be done in fvwm, leaving all these problems to the window manager. It would work the same as moving the viewport. The pager asks fvwm to move the viewport, it doesn't directly move all the windows. But it would require a rewrite of the pager, and some major changes to the fvwm code.. :( not a task for 2.5 I guess... Even so, can this be a 2.6 feature? Cheers Renato Ciao Dominik ^_^ ^_^ -- Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit! Feel free mit GMX DSL: http://www.gmx.net/de/go/dsl
Re: New MenuStyle which forbids tear off
On 8/4/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, I want new MenuStyle which disables ability to tear off menu. Reason: because I have some dynamic menues like this: Mouse 3 IST A Menu winmenu +0m +0 DestroyMenu winmenu AddToMenu winmenu Window menu: Title + DynamicPopupAction Function MakeWinMenu DestroyFunc MakeWinMenu AddToFunc MakeWinMenu + I DestroyMenu recreate winmenu + I AddToMenu winmenu Window menu $[w.class]: Title + I ThisWindow (Shaded) + %menu-cbox_on.png%UnShade WindowShade + I TestRc (NoMatch) + %menu-cbox_off.png%Shade WindowShade ...skipped... When user tear offs such dynamic menu, menu items in it no longer working, because functions called without window context. I already coded a patch which adds MenuStyle 'AllowTearOff/!AllowTearOff' (feel free to offer another name for it) and I'll send it to the list if: - core developers agree that proposed functionality is useful I'm not a core dev, but I think this can be useful. On the other hand, the menu only tears off if you specifically ask it to. So unless the desktop is used by someone else, I guess I can live with just not tearing it off in the first place :) - there are no other ways to solve described problem without this new MenuStyle. Cheers Renato Best wishes -- 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
Where did the MenuStyle ActiveBack go?
Hello. I found this unusual thing in the manual. There is a reference to ActiveBack/ActiveBackOff all over the place, but aparently the style doesn't exist any more. It is not documented at all, nor is mentioned in (both) the ChangeLogs.. Not even in any part of the source code. Is there a replacement for it? Should I just delete the references? What now? Cheers Renato PS: Sounds like it was silenced by fvwm secret services ;)
Re: Where did the MenuStyle ActiveBack go?
On 7/25/06, Dominik Vogt [EMAIL PROTECTED] wrote: I found this unusual thing in the manual. There is a reference to ActiveBack/ActiveBackOff all over the place, but aparently the style doesn't exist any more. It is not documented at all, nor is mentioned in (both) the ChangeLogs.. Not even in any part of the source code. Is there a replacement for it? Should I just delete the references? What now? Ah, It's a relic of the patch splitting AftiveFore and HilightBack. I probably thought about renaming HilightBack, but gave up the idea in favour of the ActiveColorset option. It's safe to remove it from the man page (or replace it with HighlightBack where appropriate). Done. It had already been replaced by HilightBack, except the old ActiveBack was also there. Cheers Renato Ciao Dominik ^_^ ^_^ -- Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit! Feel free mit GMX DSL: http://www.gmx.net/de/go/dsl
Re: CVS renato: Created a ! flag explanation in Style similar to the one in MenuStyle
On 7/25/06, FVWM CVS fvwm-workers@fvwm.org wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: renato 06/07/25 09:24:00 Modified files: . : ChangeLog fvwm : fvwm.1.in Log message: Created a ! flag explanation in Style similar to the one in MenuStyle Moved the deprecated reference of some styles to a centralized place (NoTitle, StippledTitleOff, NoHandles,NoButton, NoIconTitle) Oops.. Looks like I did a mess with these changes above. I'll revert them for now, and review them as soon as I can. Cheers renato Removed the ActiveBack relics from the man page
Re: Man page changes - negation method
On 7/24/06, Thomas Adam [EMAIL PROTECTED] wrote: On 24/07/06, Jacob Bachmeyer [EMAIL PROTECTED] wrote: seventh guardian wrote: On 7/23/06, Jacob Bachmeyer [EMAIL PROTECTED] wrote: seventh guardian wrote: Ok, what about this: Some options are now deactivated by prefixing ! to the option. This will eventually be the default, and the old negative options are now deprecated. This is a list of MenuStyle deprecated negative options: AutomaticHotkeysOff, HilightBackOff, TitleWarpOff It's a bit more conservative, yet should still be useful :) Cheers Renato the default in that could be confusing to new users, how about the preferred form? (default could be taken as all options will be default off.) You're right. But it will not be the preferred method, it will be the only method (hence the other methods being deprecated). Can you find me a word for the only method that fits here? :) Cheers Renato This would be: Some options are now deactivated by prefixing ! to the option. This will eventually be the preferred form, and the old negative forms are now deprecated. Ok, how about: Some options are now deactivated by prefixing ! to the option. This I wouldn't use that word. This seems to be becoming more complex when it's actually very simple. Rewording the sentence above, and adding what you have below should be sufficient. I would simply reword that sentence as: Some options can now be negated by prefixing ``!'' to the option. Sounds good. will soon be the preferred form for all such options. Any negatable option for which ! does not work should be reported as a bug. The other ^^^ This is unnecessary, at least for now, as we should know what doesn't work. Besides, it is obvious that things that _are_documented_ and don't work as documented should be reported as bugs. negative forms are now deprecated and will be removed in FVWM X.Y. ^^ In here I would prefer the future. Because we don't really know when it will be removed. I would prefer it being removed previous to the 2.6 release, as we are growing to have more compatibility options than real options :P . But I bet thats not the opinion of most of us, so.. Future it should be :) Does everybody agree with something like this: Some options are now negated by prefixing ! to the option. This will soon be the preferred form for all such options. The other negative forms are now deprecated and will be removed in the future. Cheers Renato -- Thomas Adam
Re: FVWM: Latest Beta and Eclipse
On 7/24/06, Jake Colman [EMAIL PROTECTED] wrote: FDF == Friedrich Delgado Friedrichs [EMAIL PROTECTED] writes: FDF Hi! FDF You asked: Am I the only FVWM + Eclipse user out here? FDF No. FDF I'm using eclipse 3.1.2 with fvwm 2.5.16 and Xorg 7.0.0 on an Athlon FDF 550 with 448 MB of ram. It's quite a bit sluggish and I have to take FDF care not to run too many other memory- or cpu-hungry applications at FDF the same time (e.g. firefox is out of the question, while opera is FDF ok), but I don't see any of the problems you describe. FDF I just tested it... I displayed the help contents and then Help - FDF About Eclipse - Plugin Details and scrolled it... I could see no FDF repainting or flicker in the window below it. FDF I doubt that this will help you... FDF Your description sounds like you run the CDE + eclipse combination on FDF the same machine as the fvwm + eclipse combination, but let me FDF specifically ask if this is actually the case. FDF Everything else is identical means it's the same box + OS + other FDF software? FDF Which hardware, operating system, (distribution, if applicable), X FDF Window versions do you use? The output of xdpyinfo might also be FDF interesting. FDF What about running eclipse in twm? Can you try this? FDF Looking through the mailing list archives I just noticed that I FDF already gave that statement and asked the same question but received FDF no answer from you as yet. Friedrichs, Yes, the two machines are identical; only the WM is different. I am executing on a Sparc Sun-Fire V440, running Solaris 8. I use a RealVNC VNC Server as my X Server and a Tight VNC client from a Win2k PC as my client. Executing a VNC Server with twm as the WM works fine (as does CDE as I previously posted). Older versions of FVWM with the same VNC Server also work fine. The output of xdpyinfo is as follows: name of display:pennsylvania:99.0 version number:11.0 vendor string:The X.Org Group vendor release number:6600 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, MSBFirst, 32 image byte order:MSBFirst number of supported pixmap formats:2 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0x28d, revert to Parent number of extensions:18 BIG-REQUESTS DEC-XTRAP DOUBLE-BUFFER DPMS Extended-Visual-Information FontCache LBX MIT-SHM MIT-SUNDRY-NONSTANDARD RECORD SECURITY SHAPE SYNC TOG-CUP VNC-EXTENSION XC-APPGROUP XC-MISC XTEST default screen number:0 number of screens:1 screen #0: dimensions:1400x1050 pixels (356x267 millimeters) resolution:100x100 dots per inch depths (2):1, 24 root window id:0x26 depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x21 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store YES, save-unders YES largest cursor:1400x1050 current input event mask:0xda003f KeyPressMask KeyReleaseMask ButtonPressMask ButtonReleaseMaskEnterWindowMask LeaveWindowMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask PropertyChangeMask ColormapChangeMask number of visuals:2 default visual id: 0x22 visual: visual id:0x22 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x23 class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits Thanks for your help! -- Jake Colman Sr. Applications Developer Principia Partners LLC Harborside Financial Center 1001 Plaza Two Jersey City, NJ 07311 +1 (201) 209-2467 www.principiapartners.com
Re: Man page changes - negation method
On 7/23/06, Jacob Bachmeyer [EMAIL PROTECTED] wrote: seventh guardian wrote: Ok, what about this: Some options are now deactivated by prefixing ! to the option. This will eventually be the default, and the old negative options are now deprecated. This is a list of MenuStyle deprecated negative options: AutomaticHotkeysOff, HilightBackOff, TitleWarpOff It's a bit more conservative, yet should still be useful :) Cheers Renato the default in that could be confusing to new users, how about the preferred form? (default could be taken as all options will be default off.) You're right. But it will not be the preferred method, it will be the only method (hence the other methods being deprecated). Can you find me a word for the only method that fits here? :) Cheers Renato This would be: Some options are now deactivated by prefixing ! to the option. This will eventually be the preferred form, and the old negative forms are now deprecated.
Re: FVWM: Color / ForeColor no longer supported?
On 7/23/06, Thomas Adam [EMAIL PROTECTED] wrote:
On 23/07/06, Peter Daum [EMAIL PROTECTED] wrote:
Hi,
already for a while now (I think it started shortly after 2.5.15)
the specification of a foreground color for a window (something
like Style * Color red/green or ForeColor red) has been
silently ignored.
That is strange. I have my config working perfectly with ForeColor
etc. (fvwm cvs)
Are these commands obsoleted by the newer colorset stuff and only
the documentation not yet adjusted or is it just a bug (background
is still honored). Is there a simple workaround?
You should be using Colorsets regardless in 2.5.X -- deprecation of
{Fore,Back}Color is definitely on the cards, and has been for a while.
Then I guess there should be at least some note in the manual page..
Cheers
Renato
-- Thomas Adam
Re: FVWM: Fvwm and kde
On 7/22/06, Imbaud Pierre [EMAIL PROTECTED] wrote: Hi, Denis, I have been an fvwm user for years, but the lazy kind, I didnt catch up with technical changes. I began to use kde too, for 2 functions I cant find with fvwm: - Multiple X session, and switching betweeen them You can do this using qingy. You just Ctrl+Alt+F* to switch vt, and start another session with X. And then you can Ctrl+Alt+F* to switch between them. Btw, this is not suposed to be the task of fvwm. - suspending computer (kde: kmenu--logout--suspend computer) Once again, qingy can do this. Logout fvwm and then on qingy select suspend. Once again, this is not the task of fvwm. Kde interacts with kdm to achieve the above. Btw, qingy is a logon manager, just like kdm, and being independent allows it to be more flexible than kdm. Cheers Renato You say I'm using fvwm with KDE (nice combination !), makes me think you master the combination. I proceed in a quite clumsy way: first logon KDE, then open a new session under fvwm, and every time I want to suspend go back to kde first. Do you run fvwm as the kde WM, as suggested in http://fvwm.org/documentation/faq? Does it give you access to all the kde functions? Do you know if there is a specific howto, that could help me in this setup? Thanks a lot! Denis Prost a écrit : Hi, I'm new to the list. I'm using fvwm with KDE (nice combination !). Everything works fine except two small problems : 1) the icons in the kde systray are not properly displayed for a few applications : - korn (tells you how many mails are in your mailbox) : the button size for each mailbox, sometimes fits, sometimes does not fit the systray size - klipper, kmix : the icon is not properly centered in the systray 2) Pressing the button for the focused window on the kde taskbar does not iconify it (it does with kwin), while right clicking on it and selecting minimize works. Any hint about it ? Thanks, Denis
Re: FVWM: Fvwm and kde
On 7/22/06, seventh guardian [EMAIL PROTECTED] wrote: On 7/22/06, Imbaud Pierre [EMAIL PROTECTED] wrote: Hi, Denis, I have been an fvwm user for years, but the lazy kind, I didnt catch up with technical changes. I began to use kde too, for 2 functions I cant find with fvwm: - Multiple X session, and switching betweeen them You can do this using qingy. You just Ctrl+Alt+F* to switch vt, and start another session with X. And then you can Ctrl+Alt+F* to switch between them. Btw, this is not suposed to be the task of fvwm. - suspending computer (kde: kmenu--logout--suspend computer) Once again, qingy can do this. Logout fvwm and then on qingy select suspend. Once again, this is not the task of fvwm. Kde interacts with kdm to achieve the above. Btw, qingy is a logon manager, just like kdm, and being independent allows it to be more flexible than kdm. Forgot to mention, qingy is a framebuffer logon manager, while kdm runs under X. Both ways have their pros and cons.. Renato Cheers Renato You say I'm using fvwm with KDE (nice combination !), makes me think you master the combination. I proceed in a quite clumsy way: first logon KDE, then open a new session under fvwm, and every time I want to suspend go back to kde first. Do you run fvwm as the kde WM, as suggested in http://fvwm.org/documentation/faq? Does it give you access to all the kde functions? Do you know if there is a specific howto, that could help me in this setup? Thanks a lot! Denis Prost a écrit : Hi, I'm new to the list. I'm using fvwm with KDE (nice combination !). Everything works fine except two small problems : 1) the icons in the kde systray are not properly displayed for a few applications : - korn (tells you how many mails are in your mailbox) : the button size for each mailbox, sometimes fits, sometimes does not fit the systray size - klipper, kmix : the icon is not properly centered in the systray 2) Pressing the button for the focused window on the kde taskbar does not iconify it (it does with kwin), while right clicking on it and selecting minimize works. Any hint about it ? Thanks, Denis
Re: CVS scott fvwm-web: Updated on-line man pages for 2.5.17.
On 7/21/06, FVWM CVS fvwm-workers@fvwm.org wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by: scott 06/07/20 22:30:23 Modified files: documentation/manpages/unstable: FvwmAnimate.php FvwmAuto.php FvwmBacker.php FvwmBanner.php FvwmButtons.php FvwmCommand.php FvwmConsole.php FvwmConsoleC.pl.php FvwmCpp.php FvwmDebug.php FvwmDragWell.php FvwmEvent.php FvwmForm.php FvwmGtk.php FvwmGtkDebug.php FvwmIconBox.php FvwmIconMan.php FvwmIdent.php FvwmM4.php FvwmPager.php FvwmPerl.php FvwmProxy.php FvwmRearrange.php FvwmSave.php FvwmSaveDesk.php FvwmScript.php FvwmScroll.php FvwmTabs.php FvwmTaskBar.php FvwmTheme.php FvwmWharf.php FvwmWinList.php FvwmWindowMenu.php focus-link.php fvwm-bug.php fvwm-config.php fvwm-convert-2.2.php fvwm-convert-2.4.php fvwm-convert-2.6.php fvwm-menu-desktop.php fvwm-menu-directory.php fvwm-menu-headlines.php fvwm-menu-xlock.php fvwm-perllib.php fvwm-root.php fvwm.php index.php Log message: Updated on-line man pages for 2.5.17. Hi! Could there be an easy way to do the update automatically? Renato
Man page changes - negation method
Hello all. After some thought and reasoning, here's a preliminary solution to the man page entry regarding the style negation method. I followed Thomas' sugestion and here's what is done for the menu styles. Since I hadn't done any change to this section yet, I've updated the HilightBackOff option to !HilightBack as an example. The big change: @@ -2948,6 +2948,11 @@ triples with a '/' in between. These options exclude each other. All paired options can be negated to have the effect of the counterpart option by prefixing ! to the option. +Deactivating an option is done by prefixing ! to the option. This is +the prefered negation method, and other methods are now deprecated. + +This is a list of MenuStyle deprecated negative options: +HilightBackOff .IR Fvwm , Mwm , Win reset all options to the style with the same name in former Please comment :) The diff goes atached. Cheers, Renato patch Description: Binary data
MenuStyle options - negate or not to negate?
Hi. Some of the MenuStyle (an maybe Style too) options don't have a negative form on the man page. But the truth is that some can be negated. So in order to unify the whole thing, what should be done to those? Should we add the negative forms to the man page to the ones missing, or should we remove them from the ones which have a !* negation form? Example: MouseWheel TrianglesUseFore / !TrianglesUseFore should become MouseWheel / !MouseWheel TrianglesUseFore / !TrianglesUseFore or MouseWheel TrianglesUseFore ? Let us consider now that the way to negate the styles is now explained on the man page. Opinions? Renato Caldas
Re: MenuStyle options - negate or not to negate?
On 7/21/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Fri, Jul 21, 2006 at 03:56:00PM +0100, seventh guardian wrote: Hi. Some of the MenuStyle (an maybe Style too) options don't have a negative form on the man page. But the truth is that some can be negated. So in order to unify the whole thing, what should be done to those? Should we add the negative forms to the man page to the ones missing, or should we remove them from the ones which have a !* negation form? Example: MouseWheel TrianglesUseFore / !TrianglesUseFore should become MouseWheel / !MouseWheel TrianglesUseFore / !TrianglesUseFore This is the right decision. Great :) As soon as we agree on the ! notice on the man page I'll do this. One thing at a time :) or MouseWheel TrianglesUseFore Nope. Let us consider now that the way to negate the styles is now explained on the man page. Note that there are many more styles and options that could have a !-negation, bui I don't want to tackle them now. Ok. My new proposal accounts for this. Cheers Renato Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEwQ1RmeSprTOr4tgRAt/MAJ9+9tRrSI8uafiuIffHJvGQrBKzQwCeOZhW G/MlmWG1JgXJ1+BuGsEW1PU= =dK69 -END PGP SIGNATURE-
Re: Man page changes - negation method
On 7/21/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Fri, Jul 21, 2006 at 03:38:40PM +0100, seventh guardian wrote: Hello all. After some thought and reasoning, here's a preliminary solution to the man page entry regarding the style negation method. I followed Thomas' sugestion and here's what is done for the menu styles. Since I hadn't done any change to this section yet, I've updated the HilightBackOff option to !HilightBack as an example. The big change: @@ -2948,6 +2948,11 @@ triples with a '/' in between. These options exclude each other. All paired options can be negated to have the effect of the counterpart option by prefixing ! to the option. '!' --^^^ +Deactivating an option is done by prefixing ! to the option. This is '!' -^^^ +the prefered negation method, and other methods are now deprecated. But ... as far as I know it's not true. Not all options can be negated with the !-prefix. I eventually want to get there, but it's not true at the moment. Ok, what about this: Some options are now deactivated by prefixing ! to the option. This will eventually be the default, and the old negative options are now deprecated. This is a list of MenuStyle deprecated negative options: AutomaticHotkeysOff, HilightBackOff, TitleWarpOff It's a bit more conservative, yet should still be useful :) Cheers Renato +This is a list of MenuStyle deprecated negative options: +HilightBackOff Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEwQ4+meSprTOr4tgRAg1pAJ9qGCNJJXQVfyeX2RkYS0Q93s6ZEQCeLD0R BstZkG0kfP95hpeQg1MwTXA= =Kj8o -END PGP SIGNATURE-
Re: Flags - is negation prefered?
On 7/18/06, seventh guardian [EMAIL PROTECTED] wrote: On 7/18/06, Viktor Griph [EMAIL PROTECTED] wrote: On Mon, 17 Jul 2006, Dominik Vogt wrote: On Mon, Jul 17, 2006 at 03:47:13PM +0100, seventh guardian wrote: Hi. I have a question. Is the flag vs. !flag syntax the prefered one? I ask this because even though some styles only have the !(stylename) counterpart, some are still documented as (stylename)Off. So if the flag negation is prefered to the (stylename) vs. (stylename)Off, or the other way round, then it should be explicit in the man page. This is the only way we can avoid compatibility confusion in a future version. My opinion is that the flag vs. !flag style is simpler to parse, and it should be prefered. the (stylename)Off code should be maintained for compatibility's sake, but marked as deprecated. The ! negation style is preferred. I coded it for exactly the reasons you describe. There are so many different typed of on/off syntax. Should the old style negation options be deprecated in the code (give warnings) before 2.6? I vote yes ;) Regarding my docs intervention, I finished my last exam today, so hopefuly I have some spare time now. One question though: (bump) The question remains.. If noone is against, then I'll do my best :) Cheers, Renato I think it's better to mention the fact that the !* is now prefered (and the other negations are deprecated) only once, instead of mentioning it in every command description. This way we have a man page section with something like: NoButton - !Button NoTitle - !Title (...) or even something like: These negation styles are deprecated. Please use now the ! sign to negate the styles. The list: NoButton, NoTitle, (...) I think this clears up the manpage and concentrates the info about deprecated styles in only one place (easyer to maintain and to track). Any opinions on this, and if agreed, on how should this be done? It's a major doc cleanup process, so it should be well done. Cheers, Renato
Re: Flags - is negation prefered?
On 7/18/06, Viktor Griph [EMAIL PROTECTED] wrote: On Mon, 17 Jul 2006, Dominik Vogt wrote: On Mon, Jul 17, 2006 at 03:47:13PM +0100, seventh guardian wrote: Hi. I have a question. Is the flag vs. !flag syntax the prefered one? I ask this because even though some styles only have the !(stylename) counterpart, some are still documented as (stylename)Off. So if the flag negation is prefered to the (stylename) vs. (stylename)Off, or the other way round, then it should be explicit in the man page. This is the only way we can avoid compatibility confusion in a future version. My opinion is that the flag vs. !flag style is simpler to parse, and it should be prefered. the (stylename)Off code should be maintained for compatibility's sake, but marked as deprecated. The ! negation style is preferred. I coded it for exactly the reasons you describe. There are so many different typed of on/off syntax. Should the old style negation options be deprecated in the code (give warnings) before 2.6? I vote yes ;) Regarding my docs intervention, I finished my last exam today, so hopefuly I have some spare time now. One question though: I think it's better to mention the fact that the !* is now prefered (and the other negations are deprecated) only once, instead of mentioning it in every command description. This way we have a man page section with something like: NoButton - !Button NoTitle - !Title (...) or even something like: These negation styles are deprecated. Please use now the ! sign to negate the styles. The list: NoButton, NoTitle, (...) I think this clears up the manpage and concentrates the info about deprecated styles in only one place (easyer to maintain and to track). Any opinions on this, and if agreed, on how should this be done? It's a major doc cleanup process, so it should be well done. Cheers, Renato
Re: FVWM: FvwmScript periodic tasks and date command
On 7/18/06, seventh guardian [EMAIL PROTECTED] wrote:
On 7/18/06, Yuri Arapov [EMAIL PROTECTED] wrote:
Hi list!
I started experimenting with FvwmScript and ran into this weird
thing: output of date command called every second in
PeriodicTasks section of the script skips ever second
second. So I see
Tue Jul 18 19:45:03 MSD 2006
Tue Jul 18 19:45:05 MSD 2006
Tue Jul 18 19:45:07 MSD 2006
etc.
instead of
Tue Jul 18 19:45:03 MSD 2006
Tue Jul 18 19:45:04 MSD 2006
Tue Jul 18 19:45:05 MSD 2006
etc.
Just to compare: the following one-liner works fine in xterm:
while date; do sleep 1; done
Script that reproduces this effect is attached. To play with
it start fvwm console and type
Module FvwmScript /full/name/of/the/script Enter
I tried this script on 2 different boxes, same results.
My distro is current Debian unstable.
Fvwm version is 2.5.16.
Any clue where to search for the fix?
It is possible that the script takes more than 1 second to run. Give
it a 2 or 5 second interval and see if the problem persists.
Try this for the periodic task:
PeriodicTasks
Begin
Do {Echo periodic task}
If (RemainderOfDiv (GetTime) 3)==0 Then
ChangeTitle 1 (GetOutput {date} 1 -1)
End
It works perfectly (3 secs interval). If you change the 3 to 2 it
works perfectly, but in a 2 second interval. Changing to 1 doesn't
work, because the script takes more than 1 second to run.
The problem is probably in using GetOutput, because it takes some time
to launch the date program.. Expect something like this (or worst)
whenever you use GetOutput.
Cheers,
Renato
Cheers,
Renato
Best regards,
Yuri
--
Yuri Arapov [EMAIL PROTECTED]
Re: FVWM: FvwmScript periodic tasks and date command
On 7/18/06, Yuri Arapov [EMAIL PROTECTED] wrote: Hi list! I started experimenting with FvwmScript and ran into this weird thing: output of date command called every second in PeriodicTasks section of the script skips ever second second. So I see Tue Jul 18 19:45:03 MSD 2006 Tue Jul 18 19:45:05 MSD 2006 Tue Jul 18 19:45:07 MSD 2006 etc. instead of Tue Jul 18 19:45:03 MSD 2006 Tue Jul 18 19:45:04 MSD 2006 Tue Jul 18 19:45:05 MSD 2006 etc. Just to compare: the following one-liner works fine in xterm: while date; do sleep 1; done Script that reproduces this effect is attached. To play with it start fvwm console and type Module FvwmScript /full/name/of/the/script Enter I tried this script on 2 different boxes, same results. My distro is current Debian unstable. Fvwm version is 2.5.16. Any clue where to search for the fix? It is possible that the script takes more than 1 second to run. Give it a 2 or 5 second interval and see if the problem persists. Cheers, Renato Best regards, Yuri -- Yuri Arapov [EMAIL PROTECTED]
Re: FVWM: Latest Beta and Eclipse
On 7/18/06, Jake Colman [EMAIL PROTECTED] wrote: Several weeks ago I posed a problem with the display performance of Eclipse when using FVWM 2.5.7. A reasonable poster suggested that I should at least upgrade to a newer version. I jave just installed v2.5.16 and Eclipse performance now seems reasonable and roughly equivalent to using it under CDE. My problem now is with screen flicker. If I display a modal dialgoue (e.g., the plugins list on top of the Help dialogue), as I scroll the plugins list the Help dialogue is constantly being repainted. This is certainly annoying and also makes the display less responsive. Are there configuration settings that I should be looking at, or are there settings that I should be posting, that might explain some of this? Does the redrawing only happen when you scroll up/down? It can be a problem with X. Can you try it out without a window manager or with the default X one (twm)? Cheers Renato TIA! ...Jake -- Jake Colman Sr. Applications Developer Principia Partners LLC Harborside Financial Center 1001 Plaza Two Jersey City, NJ 07311 +1 (201) 209-2467 www.principiapartners.com
Re: FVWM: FVWM, GNOME and preloading GNOME libs
On 7/17/06, Andrei Popov [EMAIL PROTECTED] wrote: Hello Dominik and thanks for you response. You could add some dummy Gnome application to your start function. I'm sorry, dummy Gnome application doesn't sound too clear to me, and Google didn't help me either =) Can you perhaps provide an example? Start something like the gnome calculator.. What you need is a small gnome program so that it loads the gnome libs at startup. You can then kill it.. If you want to you can make a real dummy program only with gnome_init and a few other functions tha just starts itself and then exits. I think it takes so long because the first Gnome app starts a process called gconfd-2 from some obscure library. Maybe so. After some googling I came across a GDM speedup tip that I thought could apply to my situation. I didn't see any visible improvements though after I followed the steps successfully and rebooted. http://blogs.sun.com/roller/page/jmr?entry=jds_gnome_performance_leaner_meaner This seems to be just a _gnome_ speed improvement. It doesn't start gconfd-2, so you have no real _startup_ speed improvement. It may help on the performance once all gnome libs are loaded though.. Cheers Renato -- WBR, Andrei Popov Using FVWM 2.5.16 on Debian GNU/Linux
Re: FVWM: How to use StippledTitleOff
On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 10:35:15AM +0100, Leon wrote: Thomas Adam [EMAIL PROTECTED] writes: On Sun, Jul 16, 2006 at 05:56:18PM +0100, Leon wrote: However it seems it does nothing at all. All the icons still have sticky title. Any ideas? Of course -- the style StippledTitleOff is only applicable to non-sticky windows which have been told to use StippledTitle -- it doesn't work for sticky windows. Humm first of all this now should be a flag StippledTitle vs !StippledTitle. I will correct the man page. -- Thomas Adam I misunderstood StippledTitleOff. Is there any way to tell sticky icons to use a normal title? Thanks, -- Leon No, there isn't. I did send a patch in last year to address this problem, but it was mostly ignored. Style only works with window/class names. So there's no easy way of telling fvwm just to stipple sticky windows. (Like Style Sticky !StippledTitle). Perhaps this could be done with conditional commands, but it's not an easy thing. The imediate solution would be to add another style to set/reset the StippledTitle flag only on the sticky windows, or globally (like Style * NeverStipple) but in my oppinion this is wrong.. But the long term solution would be to extend the Style command not just for window/class names but also for Window states (Style Icon (...) or Style Sticky (...)). Dominik? Finally as a personal oppinion, I see no utility in the current StippledTitle style, so maybe Thomas' patch could be re-discussed? Cheers, Renato -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Flags - is negation prefered?
Hi. I have a question. Is the flag vs. !flag syntax the prefered one? I ask this because even though some styles only have the !(stylename) counterpart, some are still documented as (stylename)Off. So if the flag negation is prefered to the (stylename) vs. (stylename)Off, or the other way round, then it should be explicit in the man page. This is the only way we can avoid compatibility confusion in a future version. My opinion is that the flag vs. !flag style is simpler to parse, and it should be prefered. the (stylename)Off code should be maintained for compatibility's sake, but marked as deprecated. Comments? Renato
Re: FVWM: How to use StippledTitleOff
On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 03:26:32PM +0100, seventh guardian wrote: On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 10:35:15AM +0100, Leon wrote: Thomas Adam [EMAIL PROTECTED] writes: On Sun, Jul 16, 2006 at 05:56:18PM +0100, Leon wrote: However it seems it does nothing at all. All the icons still have sticky title. Any ideas? Of course -- the style StippledTitleOff is only applicable to non-sticky windows which have been told to use StippledTitle -- it doesn't work for sticky windows. Humm first of all this now should be a flag StippledTitle vs !StippledTitle. I will correct the man page. Most commands should be using !Foo in the negatory sense. Style only works with window/class names. So there's no easy way of Name, Class, Resource. telling fvwm just to stipple sticky windows. (Like Style Sticky !StippledTitle). Perhaps this could be done with conditional commands, but it's not an easy thing. How do you mean? It's perfectly simple to add something like: Style * StickyStipples Style * !StickyStipples ... Which might apply to windows which have been declared as sticky. Yes, but then you'd end up with lots of equal styles applying to different situations.. The imediate solution would be to add another style to set/reset the StippledTitle flag only on the sticky windows, or globally (like Style * NeverStipple) but in my oppinion this is wrong.. Maybe it is, but then you can turn that around and say that stippling sticky windows in the first place is also wrong. Yes, I did say that :) but it's just my opinion.. But the long term solution would be to extend the Style command not just for window/class names but also for Window states (Style Icon (...) or Style Sticky (...)). Dominik? I don't like this, since you would probably extend it to include things like: Style Shaded (...) Style HasTitle (...) It gets too boring, unmanagable, and ultimately wrong. The stylation of window *states* (as in the above) just doesn't make logical sense to me. It would allow us for instance to use a different color style for sticky windows, instead of just allowing stippling.. It would allow setting different colors to the iconified windows. This currently can only be done with the use of colorsets, which I belive is a broken behaviour. And the list goes on. It's a flexible solution that follows the same philosophy that was behindreplacing all sorts of old fvwm commands with their Style counterpart.. Cheers, Renato -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: Flags - is negation prefered?
On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 03:47:13PM +0100, seventh guardian wrote: Hi. I have a question. Is the flag vs. !flag syntax the prefered one? I ask this because even though some styles only have the !(stylename) counterpart, some are still documented as (stylename)Off. So if the flag negation is prefered to the (stylename) vs. (stylename)Off, or the other way round, then it should be explicit in the man page. This is the only way we can avoid compatibility confusion in a future version. My opinion is that the flag vs. !flag style is simpler to parse, and it should be prefered. the (stylename)Off code should be maintained for compatibility's sake, but marked as deprecated. Comments? Renato Yes -- I thought 2.5.X was having the !Foo syntax as the preferred one, removing any old Foo versus NoFoo options. Of course, it's currently on FVWM 2.4.X which still exhibits this. Yes, but then the 2.5 manual should be updated. I'll start doing that.. Renato -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: Flags - is negation prefered?
On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 04:02:47PM +0100, seventh guardian wrote: Yes, but then the 2.5 manual should be updated. I'll start doing that.. Don't be too hasty. :) Things like: Style foo !Icon Won't work. Yes, I know :) But in any case, I'll test things before changing the manpage.. Renato -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: Flags - is negation prefered?
On 7/17/06, Viktor Griph [EMAIL PROTECTED] wrote: On Mon, 17 Jul 2006, Thomas Adam wrote: On Mon, Jul 17, 2006 at 04:02:47PM +0100, seventh guardian wrote: Yes, but then the 2.5 manual should be updated. I'll start doing that.. Don't be too hasty. :) Things like: Style foo !Icon Won't work. Another thing to remember is that all options that still are supported, but not preferred should still be documented, or someone searching for what an option in a config file does might not find it. Yes, I also adressed that. I hope the first three items are good. I'll continue tomorrow after my last exam.. :) Cheers, Renato /Viktor
Re: FVWM: How to use StippledTitleOff
On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 04:36:08PM +0100, seventh guardian wrote: On the other hand, BackColor and ForeColor apply to both situations. Don't get too attached to those though -- they're deprecated in favour of using colorsets. :) So you can only set a specific icon color if using a colorset, and never directly like you do to a window. This is why I believe the behaviour is broken. I like this aproach. But it would be more clear if was something like: Style (name=foo | class=foo) Stick That's horrible. I really don't want to see any C idioms like that. :) Most people that use FVWM aren't programmers -- enforcing something like that on them might make them run away. :) Lol.. Yes, but how do you specify if its an and or an or? Renato The comma is a bit ambiguous.. at least for a C programmer ;) I guess these two ways of parsing could eventually be merged. I like the comma because it separates out the different clauses, just like most other commands are delimited in this way in FVWM. It also doesn't enforce a prepositional meaning with '' -- which, unless you're a programmer, you're not going to necessarily grok at first. But this idiom doesn't add anything new, it just organizes the way style works. It could be extended in the same way to accept window states as an argument: It does add something new in that the conjunctions are now considered as one, as opposed to separately, which is how FVWM would currently interpret them as. Granted it adds no new options to the styles, but think about how powerful that would be. Style (name=foo winstate=iconic) That might be a little better, yes. (Again, losing the '' syntax in preference of a comma). I might look into this if I get some time. -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Adding the possibility of not compiling deprecated code ?
Hi. This idea just came into my head: why not #ifdef'ing the deprecated code and having configure.ac option --disable-backcompat? Examples: User A has an old config. So he downloads the new package, compiles it and installs it just like he allways did. User B has a new config and wants to compile fvwm so that it doesn't waste time/space looking for deprecated options. This could make fvwm run a tiny bit faster (?), and also would allow user B to see if its config is up-to-date (i.e., not using deprecated options). He downloads the new package, runs configure --disable-backcompat and compiles it. The performance gain may not be that noticeable, but it would allow us to mark clearly deprecated code and test if things work without it. Maybe it would make it easyer to remove in the future (?). It would also be useful for users who want to make sure they have an up-to-date config, being this a way to enforce that. What do you think? Renato
Re: FVWM: How to use StippledTitleOff
On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 04:56:18PM +0100, seventh guardian wrote: Lol.. Yes, but how do you specify if its an and or an or? Just have two separate lines for them? Style (title=foo, winstate=normal) . Style (title=fii, winstate=iconic) . Touche.. :) Renato -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: bugfix with clearing 'NoIcon' style
On 7/16/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: On Sun, Jul 16, 2006 at 12:51:55PM +0200, Dominik Vogt wrote: On Sat, Jul 15, 2006 at 03:55:17AM +0400, Serge (gentoosiast) Koksharov wrote: On Fri, Jul 14, 2006 at 12:28:45AM +0200, Dominik Vogt wrote: Um, if the manpage is not clear enough, it should be reworded. The NoIcon style is *of course* overridden by specifying an icon, Oh, I missed this nuance. But I still think that my change is useful. Author which implemented current logic most likely assumed that 'NoIcon' hides icon completely. But it's not true. For example, user using 'FvwmIconBox' module may want to change icon of one of his applications. And with current code 'NoIcon' style will be reset which not that he wants. I.e., 'NoIcon' doesn't hide icons, all this style does is hide them from root window but they still can be used in modules. I'm not sure I understand what you are saying. Can you please rephrase that and add an example, that shows in which way things work differently with that patch? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Hello, Dominik, I'll try. Many users may prefer not to use icons on desktop at all, so they keep 'NoIcon' style set for all their applications. But icons are still useful to them if they use module like 'FvwmIconBox' which can display them. But with current code in CVS if they, for example, change icon on the fly, 'NoIcon' style will be disabled automatically, which not that they want. If my patch will be accepted this will not happen anymore. And example: from 'FvwmConsole' execute following commands: Style * NoIcon Module FvwmIconBox Style SomeApp Icon /path/to/another/icon See? Icon for 'SomeApp' again appeared on desktop and to hide it you need to execute 'Style SomeApp NoIcon'. With my patch this extra command no longer needed. Hope, this time I made this clear enough. I believe this can be solved with UseIcon vs !UseIcon for showing vs not showing the desktop icon, and the Icon or IconPath style just to set the icon path. But NoIcon would go away. It's intuitive and simple.. Cheers, Renato Best wishes -- 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
Re: FAQ Q7.17 error?
On 7/13/06, Scott Smedley [EMAIL PROTECTED] wrote: Hi Serge, In question 7.17 of the FVWM FAQ Autohiding FvwmButtons or other windows module FvwmAuto launched like this: + I Module FvwmAuto FvwmAutohide -menter enter_handler But from reading manpage source code of this module I figured out that it doesn't accept aliases, right? You are correct that the FvwmAuto module does not use aliases. However, the FvwmAuto module is hardcoded to treat the 1st argument as a timeout value. So, I think module invocation should look like this: + I Module FvwmAuto -menter enter_handler The correct command should be: + I Module FvwmAuto 1 -menter enter_handler I will update docs/FAQ. Do I need to do anything to regenerate the FAQ page for the website? I guess you have to edit the webpage in cvs: http://www.fvwm.org/documentation/dev_cvs.php#fvwm-web Renato Scott. :)
Re: Removing gnome support from FvwmGtk
On 7/13/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Thu, Jul 13, 2006 at 12:18:02AM +0100, seventh guardian wrote: On 7/13/06, Olivier Chapuis [EMAIL PROTECTED] wrote: seventh guardian a écrit : On 7/12/06, Thomas Adam [EMAIL PROTECTED] wrote: On Wed, Jul 12, 2006 at 11:24:57PM +0100, seventh guardian wrote: Hello. Having looked at FvwmGtk code, I realise there's no need for gnome support, as no gnome specific functions are used. So, there's no advantage of calling gnome_init vs gtk_init. And from what I see, the gnome support has been several times mis-used by precompiled distros (forcing the instalation of gnome libs when they are not required at all). So, I ask if we can remove the gnome support from FvwmGtk. I've been saying this for years -- yet no one would listen. I am in favour of it. Humm.. After a bit more dig up, it seems that gnome support is not just that.. It's also the gnome wm hints support.. it may be important, as this allows fvwm to integrate with gnome desktop (pagers and stuff). So, what does this section from the FvwmGtk-manpage mean: .IP *FvwmGtk: RCFile \fBfile\fP Note that this command should be issued before defining any menus or dialog. Hint for GNOME users: If you add instances of this command for the standard GNOME rc files, switching themes via the control-center will apply to FvwmGtk widgets as well, giving a very integrated appearance of the desktop. Well, Gtk themes are defined in $HOME/.gtkrc.. I supose gnome control center also updates this file (?) It's just a matter of telling FvwmGtk where to look for the gtk configs.. yes, but only for gnome 1, so ... Oh! Didn't know that. But in what refers to FvwmGtk, it works exactly the same without gnome support. The final question is, is it worth remove gnome support from FvwmGtk if the rest of fvwm still needs it... Not exactly (bug report system, if I remember some discussions on this list). This known as, I am in favor of removing gnome support in FvwmGtk. And considering the above, what about removing the whole gnome support from fvwm? If you're referring to the gnome libs: FvwmGtk is the orly place where they are needed. If you mean the GNOMe WM hints: we should keep them. I was refering to the hints.. Gnome 1 is obsolete, so it's a matter of deciding which degree of compatibility we want to keep. The same happens with rplay, but that's a matter for another mail :) Cheers, Renato Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEthdCmeSprTOr4tgRAkjeAKDPbFoiPDrzpi0X6D1LQb9PIs8ZMQCgwUbq 3stH7fxGfUBp5BDVXSr0SrI= =a6fF -END PGP SIGNATURE-
Re: Bees
On 7/14/06, Scott Smedley [EMAIL PROTECTED] wrote: Damn this list is busy! http://gmane.org/plot-rate.php?group=gmane.comp.window-managers.fvwm.develwidth=1000height=400color=red,orange,%234000title=fvwm-workerssmooth=exp Not that I'm complaining. Yes.. Summer hollydays are comming in :) I can't wait to finish my exams!! Renato Scott. :)
Re: ChangeLog vs modules/ChangeLog ?
On 7/12/06, Dan Espen [EMAIL PROTECTED] wrote: seventh guardian [EMAIL PROTECTED] writes: Hi. I have a question regarding the use of the ChangeLogs. Obviously, changes to the fvwm core are reported in the root ChangeLog. But what about changes to modules? I ask this because I've allways logged my changes to the root one, but now think I should have done it to modues/ChangeLog. On the other hand, there are lots of module changes in the root changelog.. So, what is our ChangeLog policy? If it is module stuff - modules/ChangeLog, rest - ChangeLog, then I guess module stuff should be moved to the correct modules/ChangeLog. If not, then we would be better served with just one ChangeLog, in wich case we should merge both. The Changelogs were getting huge so they were split up. Using Emacs, you find the right one using C-x 4 a. Otherwise it's the first one above the directory your in. Hum.. Ok, then there are lots of entries in the root ChangeLog not belonging there.. Should they be moved to the right place? Renato -- Dan Espen E-mail: [EMAIL PROTECTED]
Removing gnome support from FvwmGtk
Hello. Having looked at FvwmGtk code, I realise there's no need for gnome support, as no gnome specific functions are used. So, there's no advantage of calling gnome_init vs gtk_init. And from what I see, the gnome support has been several times mis-used by precompiled distros (forcing the instalation of gnome libs when they are not required at all). So, I ask if we can remove the gnome support from FvwmGtk. BTW, please correct me if I'm wrong. Cheers, Renato
Re: Removing gnome support from FvwmGtk
On 7/12/06, Thomas Adam [EMAIL PROTECTED] wrote: On Wed, Jul 12, 2006 at 11:24:57PM +0100, seventh guardian wrote: Hello. Having looked at FvwmGtk code, I realise there's no need for gnome support, as no gnome specific functions are used. So, there's no advantage of calling gnome_init vs gtk_init. And from what I see, the gnome support has been several times mis-used by precompiled distros (forcing the instalation of gnome libs when they are not required at all). So, I ask if we can remove the gnome support from FvwmGtk. I've been saying this for years -- yet no one would listen. I am in favour of it. Humm.. After a bit more dig up, it seems that gnome support is not just that.. It's also the gnome wm hints support.. it may be important, as this allows fvwm to integrate with gnome desktop (pagers and stuff). But in what refers to FvwmGtk, it works exactly the same without gnome support. The final question is, is it worth remove gnome support from FvwmGtk if the rest of fvwm still needs it... Renato -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: Removing gnome support from FvwmGtk
On 7/13/06, Olivier Chapuis [EMAIL PROTECTED] wrote: seventh guardian a écrit : On 7/12/06, Thomas Adam [EMAIL PROTECTED] wrote: On Wed, Jul 12, 2006 at 11:24:57PM +0100, seventh guardian wrote: Hello. Having looked at FvwmGtk code, I realise there's no need for gnome support, as no gnome specific functions are used. So, there's no advantage of calling gnome_init vs gtk_init. And from what I see, the gnome support has been several times mis-used by precompiled distros (forcing the instalation of gnome libs when they are not required at all). So, I ask if we can remove the gnome support from FvwmGtk. I've been saying this for years -- yet no one would listen. I am in favour of it. Humm.. After a bit more dig up, it seems that gnome support is not just that.. It's also the gnome wm hints support.. it may be important, as this allows fvwm to integrate with gnome desktop (pagers and stuff). yes, but only for gnome 1, so ... Oh! Didn't know that. But in what refers to FvwmGtk, it works exactly the same without gnome support. The final question is, is it worth remove gnome support from FvwmGtk if the rest of fvwm still needs it... Not exactly (bug report system, if I remember some discussions on this list). This known as, I am in favor of removing gnome support in FvwmGtk. And considering the above, what about removing the whole gnome support from fvwm? Olivier
Re: FVWM: debian fvwm-gnome
On 7/12/06, Eduardo Gargiulo [EMAIL PROTECTED] wrote: Hi all, looking at debian cache, I found a package called fvwm-gnome. After install, it replace fvwm, but the documentation is the same for both packages. The package description says: Unlike fvwm, this has been compiled with GNOME support (at this point, this means that the fvwmGTK modules is a GNOME application, not a gtk application. but this may change). If you have the gnome libraries installed, fvwmGTK will use them instead of GTK. If not it will only use the ones from GTK. For pre-compiled packages, if you choose fvwmGnome then you must have the gnome libs installed. Which could be the (dis)advantages on using fvwm-gnome instead of fvwm? Gnome libs are built on top of gtk, and in case of FvwmGtk it's kind of the same thing. If you do have gnome libs installed for some other application, then it may be good to use fvwmGnome. If you don't, then it's better just to use the non-gnome fvwm and save the hard-drive space. Thanks in advance, and sorry for my english. Cheers, Renato --ejg @sf.net
Re: FVWM: debian fvwm-gnome
On 7/12/06, Thomas Adam [EMAIL PROTECTED] wrote: On Wed, Jul 12, 2006 at 05:02:23PM -, Eduardo Gargiulo wrote: Which could be the (dis)advantages on using fvwm-gnome instead of fvwm? A shed-load of useless libraries you won't ever need. True, but that's what you get when you use a precompiled distro.. It's a one-package-for-all compromise.. fvwm-gnome represents everything that the idiot of a maintainer has done in seeing FvwmGTK and thinking ooh, GNOME! and henceforth linked all manner of superfluous libs against it. As I said, you probably wouldn't need bidi support, but if some guy needs it the package must have it precompiled. Being a static program, this is the only solution. The only way fvwm could be compiled in a one-package-for-all without requiring all these libs was using *.so 's.. Renato See here: http://fvwmwiki.org/Installation/InstallationPackages -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: FVWM: debian fvwm-gnome
On 7/12/06, seventh guardian [EMAIL PROTECTED] wrote: On 7/12/06, Thomas Adam [EMAIL PROTECTED] wrote: On Wed, Jul 12, 2006 at 05:02:23PM -, Eduardo Gargiulo wrote: Which could be the (dis)advantages on using fvwm-gnome instead of fvwm? A shed-load of useless libraries you won't ever need. True, but that's what you get when you use a precompiled distro.. It's a one-package-for-all compromise.. fvwm-gnome represents everything that the idiot of a maintainer has done in seeing FvwmGTK and thinking ooh, GNOME! and henceforth linked all manner of superfluous libs against it. As I said, you probably wouldn't need bidi support, but if some guy needs it the package must have it precompiled. Being a static program, this is the only solution. The only way fvwm could be compiled in a one-package-for-all without requiring all these libs was using *.so 's.. Let me correct myself ;) fvwm is not static! The question is, can it handle the absense of some required lib.. Renato Renato See here: http://fvwmwiki.org/Installation/InstallationPackages -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: KillModule fix
On 7/11/06, Scott Smedley [EMAIL PROTECTED] wrote: Hi Renato, The attached patch fixes the broken KillModule command. Can someone please apply it? Done. How long was it broken? Not long. Since 2006/06/24. Ok, that explains why yesterday I couldn't kill FvwmPager. I didn't give it much attention though.. I should have By the way, I've long wanted to know the significance of seventh guardian ... ? LOL Well, seven is kind of a mystical number, it´s the last day of the week. I'm kind of the last guardian for something.. I'm yet to discover what.. Anyway, I created this alternative identity during my early adolescence (it's a long story..), and it remained.. It's my nickname for everything, from IRC to CounterStrike.. But for grown up projects I use my real name ;) SCoTT. :) Cheers, Renato
Re: FvwmPager: Compilation fix when --enable-debug-msgs is set
On 7/11/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, With current state of things it's impossible to compile 2.5.17 CVS branch with --debug-msgs configure option. I investigated created a patch which fixes this problem. OOPS that was my fault.. Appiled. BTW, is it my impression or you don't have an @ on your ChangeLog email? Best wishes -- 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
ChangeLog vs modules/ChangeLog ?
Hi. I have a question regarding the use of the ChangeLogs. Obviously, changes to the fvwm core are reported in the root ChangeLog. But what about changes to modules? I ask this because I've allways logged my changes to the root one, but now think I should have done it to modues/ChangeLog. On the other hand, there are lots of module changes in the root changelog.. So, what is our ChangeLog policy? If it is module stuff - modules/ChangeLog, rest - ChangeLog, then I guess module stuff should be moved to the correct modules/ChangeLog. If not, then we would be better served with just one ChangeLog, in wich case we should merge both. Cheers, Renato
Re: CVS renato: Removed the warning about the obsolete option -blackout.
On 7/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Sun, Jul 09, 2006 at 01:00:08AM +0100, seventh guardian wrote: On 7/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: Well, we have been very *very* conservative in the past about backwards compatibility - and that patch breaks it. It's no longer possible to start fvwm with -blackout. I don't think this is the right time to remove it. Of course it's obsolete and useless, but in the 2.x series we tried to keep compatibility as much as possible. The ominous 3.0 release (which is meant to remove a lot of old and obsolete stuff) would be the place to clean everything up. Well, it wasn't even useful to 2.4, and I doubt people would keep configs from pre-2.4.. So I thought it wouldn't matter. My fault. Sometimes it is surprising how long it can take until everybody has switched to a more recent release. Some people stick to 2.2.x for no other reason than that it is smaller. How can I reverse the change? With a bit of CVS magic. First, find out the revision numbers of the changed files before and after the change. For example, for fvwm.c do $ cvs log -N fvwm.c ... revision 1.375 date: 2006/07/07 23:34:31; author: renato; state: Exp; lines: +0 -8 Removed the warning about the obsolete option -blackout. Removed its reference from the manual. revision 1.374 ... (The relevant numbers are 1.374 and 1.375 here). Next, generate a patch for that change: $ cvs diff -u -r 1.374 -r 1.375 fvwm.c blackout.patch (Double check that the patch contains only the changes you want to reverse; edit the patch file if necessary). Finally reverse-apply the patch: $ patch -p0 -R blackout.patch Repeat this for all affected files. Well, although I've now done the change myself locally, I leave it to you as it is a good practive for using cvs :-) Ok, done. Thanks for the tip :) -- While you're at it you can change the warning (and todo-3.0 file) to inform the user that -blackout *will* be removed in 3.0. Done. I've also added the the info about its future removal to the manual (hope it's ok). Cheers, Renato I'm still a bit overwelmed by the commit access, so I triple-check (instead of double-check) what I do :) ... Sorry, you're right.. Won't happen again :) There's really no reason to feel disheartened. I appreciate your work very much and other surely do too. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEsMFJmeSprTOr4tgRAjAsAKCNDMZXYYvLWDBa5bv0Dd/Cacbx1QCghVlJ MYfu0Uj0Wl3JmlIiK+4Cgik= =NOZ/ -END PGP SIGNATURE-
Re: CVS renato:
On 7/8/06, FVWM CVS fvwm-workers@fvwm.org wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: renato 06/07/08 09:57:42 fvwm/compat Update of /home/cvs/fvwm/fvwm/compat In directory util9.math.uh.edu:/tmp/cvs-serv3957/compat Log Message: Directory /home/cvs/fvwm/fvwm/compat added to the repository OOPS sorry.. I should have done that only locally... Will never hapen again :) Renato
