Re: Flocale text width problem [Was: Notification: incoming/1397]
On Mon, 16 Aug 2004, Dominik Vogt wrote: On Sun, Aug 15, 2004 at 10:48:13AM -0500, fvwm-bug wrote: my MenuStyle is MenuStyle Black grey SlateGrey -*-helvetica-medium-o-*-*-12-*-*-*-*-*-*-* mwm if the last character of a menu entry is for example an l or an R, the upper right part of the glyph is not displayed, as if the width of the text would be measured at the base line and the slant causes the characters to go outside this box, the outside parts are not displayed. When i highlight the entry with the mouse, the missing part is drawn and stays this way (until the menu vanishes). I pinned down the problem, but have no fix. In Flocale.c, the function XmbTextEscapement is used to get the width of a string. It returns the offset from the start of the string where the next character would be printed, but for slanted fonts that is not the width of the bounding box: normal font: | | | | | ^ | start of next character, width = 1 slanted font: / / ^ / |___ width of bounding box = 5 / / ^ | start of next character, width = 1 Any idea what we can do about it? Is there some property of the font telling how much slated it is? (in radians, or so... :-) ) And then, there's also xft to take care of. Or perhaps the corresponding xft functions compensate for this? It was a while since I messed with that code. But I could do some research in the matter... //Marcus Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: crash FvwmForm when quitting
On Thu, 17 Jun 2004, Giuseppe Della Ricca wrote: Hi, I'm using fvwm from CVS, on RHEL 3, and since a week or so it crashes when I use it to quit fvwm, like this: Does it only crash (and generate a core) when you let it core? That's the behaviour I could reproduce. //Marcus DestroyModuleConfig FvwmForm-Quit: * *FvwmForm-Quit: GrabServer *FvwmForm-Quit: WarpPointer *FvwmForm-Quit: ActivateOnPress on *FvwmForm-Quit: Colorset 1 *FvwmForm-Quit: ItemColorset 1 *FvwmForm-Quit: Font-adobe-helvetica-bold-r-*-*-14-*-*-*-*-*-*-* *FvwmForm-Quit: ButtonFont -adobe-helvetica-bold-r-*-*-11-*-*-*-*-*-*-* *FvwmForm-Quit: InputFont -adobe-helvetica-bold-r-*-*-14-*-*-*-*-*-*-* *FvwmForm-Quit: TimeoutFont -adobe-helvetica-bold-r-*-*-14-*-*-*-*-*-*-* *FvwmForm-Quit: Line center *FvwmForm-Quit: Text Do you really want to exit FVWM? *FvwmForm-Quit: Line expand *FvwmForm-Quit: Button quit Logout ^M *FvwmForm-Quit: CommandQuit *FvwmForm-Quit: Button quit Cancel *FvwmForm-Quit: CommandNop *FvwmForm-Quit: Timeout20 Quit Automatic logout will occur in %% seconds. the core gives: #0 0x00247930 in _int_malloc () from /lib/tls/libc.so.6 (gdb) where #0 0x00247930 in _int_malloc () from /lib/tls/libc.so.6 #1 0x00246ced in malloc () from /lib/tls/libc.so.6 #2 0x08060c51 in safemalloc (length=3189400) at safemalloc.c:44 #3 0x0805c82f in CombineChars (str_visual=0x95cfa48 Cancel, len=6, comb_chars=0xbff3893c, l_to_v=0x0) at CombineChars.c:1916 #4 0x080522b5 in FlocaleEncodeString (dpy=0x95c3738, flf=0x95cd768, str=0x95cb4b8 Cancel, do_free=0xbff38934, len=157088335, nl=0xbff38938, is_rtl=0x19, comb_chars=0xbff3893c, l_to_v=0x0) at Flocale.c:453 #5 0x08052497 in FlocaleEncodeWinString (dpy=0x95c3738, flf=0x95cd768, fws=0x95cd7b8, do_free=0xbff38934, len=0xbff38938, comb_chars=0xbff3893c, l_to_v=0x0) at Flocale.c:560 #6 0x080545fa in FlocaleDrawString (dpy=0x95c3738, flf=0x95cd768, fws=0x95cd7b8, flags=1) at Flocale.c:1831 #7 0x0804ef8b in RedrawItem (item=0x95cd870, click=0, pev=0x95cb878) at FvwmForm.c:1921 #8 0x08050b53 in ReadXServer () at ReadXServer.c:440 #9 0x08050359 in MainLoop () at FvwmForm.c:2501 #10 0x0805074a in main (argc=7, argv=0xbff38de4) at FvwmForm.c:2702 I'll be happy to provide any additional information you will need. regards, Giuseppe. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: crash FvwmForm when quitting
On Thu, 17 Jun 2004, Marcus Lundblad wrote: On Thu, 17 Jun 2004, Giuseppe Della Ricca wrote: Hi, I'm using fvwm from CVS, on RHEL 3, and since a week or so it crashes when I use it to quit fvwm, like this: Does it only crash (and generate a core) when you let it core? I meant when you let it time out That's the behaviour I could reproduce. //Marcus DestroyModuleConfig FvwmForm-Quit: * *FvwmForm-Quit: GrabServer *FvwmForm-Quit: WarpPointer *FvwmForm-Quit: ActivateOnPress on *FvwmForm-Quit: Colorset 1 *FvwmForm-Quit: ItemColorset 1 *FvwmForm-Quit: Font-adobe-helvetica-bold-r-*-*-14-*-*-*-*-*-*-* *FvwmForm-Quit: ButtonFont -adobe-helvetica-bold-r-*-*-11-*-*-*-*-*-*-* *FvwmForm-Quit: InputFont -adobe-helvetica-bold-r-*-*-14-*-*-*-*-*-*-* *FvwmForm-Quit: TimeoutFont -adobe-helvetica-bold-r-*-*-14-*-*-*-*-*-*-* *FvwmForm-Quit: Line center *FvwmForm-Quit: Text Do you really want to exit FVWM? *FvwmForm-Quit: Line expand *FvwmForm-Quit: Button quit Logout ^M *FvwmForm-Quit: CommandQuit *FvwmForm-Quit: Button quit Cancel *FvwmForm-Quit: CommandNop *FvwmForm-Quit: Timeout20 Quit Automatic logout will occur in %% seconds. the core gives: #0 0x00247930 in _int_malloc () from /lib/tls/libc.so.6 (gdb) where #0 0x00247930 in _int_malloc () from /lib/tls/libc.so.6 #1 0x00246ced in malloc () from /lib/tls/libc.so.6 #2 0x08060c51 in safemalloc (length=3189400) at safemalloc.c:44 #3 0x0805c82f in CombineChars (str_visual=0x95cfa48 Cancel, len=6, comb_chars=0xbff3893c, l_to_v=0x0) at CombineChars.c:1916 #4 0x080522b5 in FlocaleEncodeString (dpy=0x95c3738, flf=0x95cd768, str=0x95cb4b8 Cancel, do_free=0xbff38934, len=157088335, nl=0xbff38938, is_rtl=0x19, comb_chars=0xbff3893c, l_to_v=0x0) at Flocale.c:453 #5 0x08052497 in FlocaleEncodeWinString (dpy=0x95c3738, flf=0x95cd768, fws=0x95cd7b8, do_free=0xbff38934, len=0xbff38938, comb_chars=0xbff3893c, l_to_v=0x0) at Flocale.c:560 #6 0x080545fa in FlocaleDrawString (dpy=0x95c3738, flf=0x95cd768, fws=0x95cd7b8, flags=1) at Flocale.c:1831 #7 0x0804ef8b in RedrawItem (item=0x95cd870, click=0, pev=0x95cb878) at FvwmForm.c:1921 #8 0x08050b53 in ReadXServer () at ReadXServer.c:440 #9 0x08050359 in MainLoop () at FvwmForm.c:2501 #10 0x0805074a in main (argc=7, argv=0xbff38de4) at FvwmForm.c:2702 I'll be happy to provide any additional information you will need. regards, Giuseppe. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS server
What's up with the CVS server? I keep getting: Message: cvs [update aborted]: recv() from server cvs.fvwm.org: Connection timed out When checking out from CVS Is it just me? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Problems with UTF-8 and illegal sequences
I just wanted to say that I started working on making the combining code more robust (the UTF-8 handling), and also check modules for malicious use FlocaleTextWidth (stepping one byte at a time is quite common). This will not be completed before a couple of weeks. Have had quite much work to do. And next week I'll go to Florida for the MySQL User's Conference. Anyone here going there too, by the way? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Solaris 8 and Iconv
I do not think that the Solaris 8 libc supports an UTF-8 locale. I don't see much more to do (the combining code uses 16-bit charcters internally, so converting to UTF-8 and then to 16-bit is needed). One alternative as a last emergency could be to write special code as fallback for at least ISO-8859-x to/from UTF-8, but this seems close to reimplementing Iconv. Hum, for which charset we need to combine characters? Do we need to combine for iso8859 1 or 15 charset for example? If yes can you give a concrete example. With bidi conversion are performed only for UTF-8, ISIRI-3342, ISO8859-6, ISO8859-9, CP1255 or CP1256. I suggest we do something like that for combining. Actually there could be more encodings that need combining (TIS 620, the Thai 8-bit encoding comes to mind). But for ISO 8859-1, 8859-2 etc., I guess you're right and we can skip it. I'll investigate this further. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Solaris 8 and Iconv
On Mon, 8 Mar 2004, Dan Espen wrote: Marcus Lundblad [EMAIL PROTECTED] writes: Markus can you check that all the new (vs 2.5.7) text conversion stuff are not used too often? I removed some redundant calls. Actually for example when drawing underlines, the width (in pixels) of one character is computed. In this case, if the character consists of one byte (ISO-8859-x) I make the assumption that the width is equal to the raw character corresponding to that byte. This will work exept for ISO-8859-6 (8-bit Arabic) which we don't support anyway (this would need joining characters using UTF-8 internally). I also included a check in the drawing routine so that character positions is only computed when combining characters are actually present in the string (redundant otherwise). Could somebody try this out in Solaris 8? It's definitely faster. The menus come up blank and the text appears 1/4 second later. On larger menus, I can see the text appear in blocks. How about using UTF-8 locale on Solaris 8? Is that implementation smart enough to just return imediatly when converting UTF-8 to UTF-8 (like in glibc, the pointer is just return back, the code in Flocale.c checks this)? I don't see much more to do (the combining code uses 16-bit charcters internally, so converting to UTF-8 and then to 16-bit is needed). One alternative as a last emergency could be to write special code as fallback for at least ISO-8859-x to/from UTF-8, but this seems close to reimplementing Iconv. Actually I find it amazing that implementation can be so slow. On my system, PII 400 MHz, I don't notice any abnormal delay even using the version before my last fix (though I use UTF-8 locale, so maybe that's the reason). //Marcus If I had to use a Solaris system, I would still want to disable iconv. -- Dan Espen E-mail: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Solaris 8 and Iconv
Markus can you check that all the new (vs 2.5.7) text conversion stuff are not used too often? I removed some redundant calls. Actually for example when drawing underlines, the width (in pixels) of one character is computed. In this case, if the character consists of one byte (ISO-8859-x) I make the assumption that the width is equal to the raw character corresponding to that byte. This will work exept for ISO-8859-6 (8-bit Arabic) which we don't support anyway (this would need joining characters using UTF-8 internally). I also included a check in the drawing routine so that character positions is only computed when combining characters are actually present in the string (redundant otherwise). Could somebody try this out in Solaris 8? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: cosmetic changes
On Thu, 12 Feb 2004, Kingsly John wrote: +++ [EMAIL PROTECTED] [2004-02-12 17:01:21]: hello, i would like to propose some minor cosmetic changes to fvwm. please have a look at http://helloworld.sh/wm/mod/ and let me know what you think. Could you also post the zoomed in pixel-by-pixel graph images for all the small images (both before and after the change) ? There's a link bigger that features xmag-like shots. But the shadow differs from MWM :-) And you should use these button styles if you want the perfect emulation: ButtonStyle 1 3 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] AddButtonStyle 1 3 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ButtonStyle 2 3 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] AddButtonStyle 2 3 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ButtonStyle 4 3 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] AddButtonStyle 4 3 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] :) //Marcus TIA Kingsly -- -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: cosmetic changes
I meant something like this http://helloworld.sh/wm/mwm-full.png But I think this is what I wanted to point out(I don't read/write vector-ese! ) And you should use these button styles if you want the perfect emulation: ButtonStyle 1 3 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] AddButtonStyle 1 3 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ButtonStyle 2 3 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] AddButtonStyle 2 3 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ButtonStyle 4 3 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] AddButtonStyle 4 3 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Does this make the dot and the vertical bar to be 2x2 and 2x7 pixels(excluding the 1 pixel border) in length ? Yes, depending on the font size, using a font the same height as on the screenshot (helvetica 12 currently on my desktop). Personally I prefer the current form of the buttons 3x3 and 3x9! Using the above setup (or simimlar) the dot is always the same size regardless of the font size (or rather titlebar height), if you want that. (similarly the bar is a fixed width and a fixed number of pixels from the edge at the left and right, and similar for the sqaure). //Marcus Kingsly -- -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Window operation-permitting styles and conditions
I was discussing with someone on #fvwm about the condition Iconifiable. Then it hit me I never implemented Style WindowShadable and the correspodning style. What's the opinion, I guess it should be there for consistency, but it's not urgent for me, since I don't need it. Should this be postponed to post-2.6? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FvwmScript and inputting UTF-8
FvwmScript seems to be broken when inputting text in UTF-8 locale. Inputting characters within ASCII (first 127) works as expected, but umlated characters and so on produces strange characters (and sometimes just a rectangle, the font's unknown characters). The font has the requested characters. I think there is something strange going on as to how keyboard input is handled, maybe just one byte is read for each keyboard event? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: is the iconv crash fixed?
On Thu, 11 Dec 2003, Dominik Vogt wrote: I remember we had a crash with Marcus' iconv patches a couple of weeks ago. Has it been fixed? I can't conclude that from the NEWS and the ChangeLog. I got the impression this was a problem the configure, and that it was fixed. Is the bug still in there? How can it be reproduced? //Marcus Ciao Dominik ^_^ ^_^ -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Unicode and sorting
After the diving tours into all of these combining characters and stuff, something hit me: how is string comparison (for sorting) done in Fvwm? Do we use strcasecmp or strcoll, if avaialble. I did some experiments using ls and different locales. I also looked at some discussion lists. It seems to me strcasecmp is simply something like return tolower(c1) tolower(c2) whereas strcoll is more locale-aware. But still strcoll (at least the one in glibc) doesn't handle combining characters at all. There is also an interering report at Unicode.org: http://www.unicode.org/reports/tr10/ I'm not sure if this should be implented in Fvwm, or if contacting glibc developers is the way to go... I will be away for the next week approximatly, will perhaps be able to read mail sporadically. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: utf-8 core dumped
On Sat, 12 Jul 2003, S. Anderson wrote: Hi, I was testing the new combining character feature with cvs fvwm (checked out on july 12 03). I found that I can make fvwm Segfault by doing the following: I found a bug that can cause FVWM to crash in some circumtances. I've checked in a bug-fix. So it should be OK in the next snapshot. By the way, I was thinking about generating random UTF-8 strings for testing. How did you generate these strings? Did you just pick some characters? I could see there is even runic letters in there (but the reading makes no sense...) And thank you for finding the bug. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Finding memory leaks
I was thinking about an aid in finding memory leaks. We already have wrappers for malloc,calloc,realloc. So it would be easy to make theese macros (to be able to print the name of the argument for debug) and also print-out the returned adress. Then the hard part: there will need to be a wrapper for free (safefree?) that can print the adress when debugging. So, here all occurences of free will have to be replaced. (By the way, free(ptr) is equivalent to realloc(ptr,0) ) Is this an idea that sounds interesting? Or am I the only one who think finding memory leaks can be tough? I know there is tests run with Purify at times, but this to me seems like a good thing. The problem is that it might get a lot of output for stuff that is not relevant when debugging some newly written code. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
The authors page
The link on the AUTHORS page to pictures (at the top) leads back to the same page... //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
todo-2.6
What are the rules for the section Closed resently? For how long will an item remain there? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Superimposing characters and non-UTF-8 locale
Now it should work to use a Unicde font in a non-UTF-8 locale (I tried using C and sv_SE) and use composing characters (tried with the Arabic strings Nadim supplied). I tested this with normal and rotated text using locales C, sv_SE and sv_SE.UTF-8. Nadim, do some of the Arabic combining characters have there equivalent in ISO-8859-6? Could you supply me with some strings in ISO-8859-6, I would like to test it. Thank you in advance. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
TODO, item B.5
Is someone able to reproduce bug B.5? I'm not able to reproduce it. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Bug C.17
I can not reproduce bug C.17 with Intellimouse scrollwheel (from that big company staring with an M) Reportedly, Olivier couldn't reproduce it on his touchpad wheel either... //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
The section on menus in the man page
It says: Popup command opens popup menus. Releasing a mouse button over a popup menu activates the item below the pointer and executes the associated action. Menu is a very similar command, but the menus it opens are slightly less transient. A separate click is required to activate a menu item - releas ing a mouse button does not activate it. but, releasing the mouse over an item activates it also using using the command Menu. Or did I misunderstand the sentance? A popup will get unposted on release, a Menu gets unposted by selecting a non-menu item or clicking outside. Isn't that correct? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Superimposing characters
Marcus, _very_ cool sorry for the delay in getting back to ya. I just downloaded 'fvwm-snap-20030707' and tried the Arabic sample I mailed you. It core dumps on me upon startup (well, fvwm never does startup) - you have all my files, you don't get coredumps ? I'll include the backtrace as well as what fvwm spewed out upon its exit (for grins), Yes, it works for me (although right now I'm rewriting the underline textdrawing, so at the moment it's not compiling). Could you please send me the output from ./configure Another thing is that I renamed some files on 20030706. Did you unpack the snapshot over an existing source? Could this be the problem, I don't think so, but maybe... I'll try to compile from the snapshot myself, and see what I find. //Marcus (gdb) where #0 FlocaleDrawString (dpy=0xd56a0, flf=0xf0500, fws=0xffbedf58, flags=0) at Flocale.c:1767 #1 0x51060 in border_draw_title_deep (fw=0xf10a0, td=0xffbee118, tdd=0xffbedf50, fstr=0xffbedf20, dest_pix=79691911, w=79691852) at borders.c:3574 #2 0x51404 in border_set_title_pixmap (fw=0xf10a0, td=0xffbee118, dest_pix=0xffbee054, w=79691852) at borders.c:3715 #3 0x51494 in border_draw_title (fw=0xf10a0, td=0xffbee118) at borders.c:3742 #4 0x527bc in border_draw_titlebar (cd=0x100, fw=0xf10a0, pressed_parts=PART_NONE, pressed_button=-1, force_draw_parts=PART_TITLEBAR, clear_parts=CLEAR_ALL, old_g=0x0, new_g=0xf1264, do_hilight=0) at borders.c:4337 #5 0x531a8 in border_draw_decorations (fw=0xf10a0, draw_parts=PART_ALL, has_focus=0, do_force=0, clear_parts=CLEAR_ALL, old_g=0x0, new_g=0xf1264) at borders.c:4723 #6 0x37ba0 in HandleMapNotify (ea=0xf10a0) at events.c:2466 #7 0x39194 in dispatch_event (e=0xffbee688) at events.c:3534 #8 0x3924c in HandleEvents () at events.c:3572 #9 0x5bd74 in main (argc=983488, argv=0xcdc00) at fvwm.c:2426 [FVWM][style_parse_and_set_window_style]: ERROR Bad style option: WindowList Skip FvwmButtons: No buttons defined. Quitting Cannot parse color black Cannot parse color white Cannot parse color black xterm: fatal IO error 32 (Broken pipe) or KillClient on X server :0.0 If I remove the Arabic strings, all works well. Let me know if you need more info. Regards, - Nadim __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Superimposing characters
Marcus, _very_ cool sorry for the delay in getting back to ya. I just
downloaded 'fvwm-snap-20030707' and tried the Arabic sample I mailed you.
It core dumps on me upon startup (well, fvwm never does startup) - you have
all my files, you don't get coredumps ? I'll include the backtrace as well
as what fvwm spewed out upon its exit (for grins),
I tried the snapshot.
It worked for me, but when checking the code from the snapshot against
your trace, I found a bug that might be the problem:
The goes like this:
char_len = 0;
i = 0;
while(fws-e_str[i] != 0 i len)
{
curr_len = FlocaleStringNumberOfBytes(
flf, fws-str + i);
char_len++;
i += curr_len;
}
this code calculates the number of characters (not number of bytes,
chars).
It traverses the string stepping for the amount of bytes comprising each
character. It stops when it encounters the NULL char OR when it has
traversed as much as the length specified.
But since here i is incremented by the number of bytes for each character,
if the string is invalid, i might be incremented past the end of the
string, if for example the last character is a 2-byte UTF-8 char but the
second last byte would indicate a 3-byte sequence. Then i would point PAST
the NULL-byte for the next check in the while-statement
So the conditions should be swapped (since C evaluates the second only if
the first was true).
char_len = 0;
i = 0;
while(i len fws-e_str[i] != 0)
{
curr_len = FlocaleStringNumberOfBytes(
flf, fws-str + i);
char_len++;
i += curr_len;
}
I'm not sure if this is why it crashes for you. But in that case running
with this rc-file should give strange results also in older snapshots.
I made the modification, but cannot commit right now, since I'm in a
non-working/compiling state...
//Marcus
(gdb) where
#0 FlocaleDrawString (dpy=0xd56a0, flf=0xf0500, fws=0xffbedf58, flags=0)
at Flocale.c:1767
#1 0x51060 in border_draw_title_deep (fw=0xf10a0, td=0xffbee118,
tdd=0xffbedf50, fstr=0xffbedf20, dest_pix=79691911, w=79691852)
at borders.c:3574
#2 0x51404 in border_set_title_pixmap (fw=0xf10a0, td=0xffbee118,
dest_pix=0xffbee054, w=79691852) at borders.c:3715
#3 0x51494 in border_draw_title (fw=0xf10a0, td=0xffbee118) at borders.c:3742
#4 0x527bc in border_draw_titlebar (cd=0x100, fw=0xf10a0,
pressed_parts=PART_NONE, pressed_button=-1,
force_draw_parts=PART_TITLEBAR, clear_parts=CLEAR_ALL, old_g=0x0,
new_g=0xf1264, do_hilight=0) at borders.c:4337
#5 0x531a8 in border_draw_decorations (fw=0xf10a0, draw_parts=PART_ALL,
has_focus=0, do_force=0, clear_parts=CLEAR_ALL, old_g=0x0,
new_g=0xf1264) at borders.c:4723
#6 0x37ba0 in HandleMapNotify (ea=0xf10a0) at events.c:2466
#7 0x39194 in dispatch_event (e=0xffbee688) at events.c:3534
#8 0x3924c in HandleEvents () at events.c:3572
#9 0x5bd74 in main (argc=983488, argv=0xcdc00) at fvwm.c:2426
[FVWM][style_parse_and_set_window_style]: ERROR Bad style option:
WindowList Skip
FvwmButtons: No buttons defined. Quitting
Cannot parse color black
Cannot parse color white
Cannot parse color black
xterm: fatal IO error 32 (Broken pipe) or KillClient on X server :0.0
If I remove the Arabic strings, all works well.
Let me know if you need more info.
Regards,
- Nadim
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Superimposing characters
Well, why don't you just fix it :-)
By the way, I don't understand why while loops are so popular. In
this case, you have all four parts of a for loop: initialisation,
condition, loop body and increment:
for (char_len = 0, i = 0;
i len fws-e_str[i] != 0;
char_len++, i += curr_len)
{
curr_len = FlocaleStringNumberOfBytes( flf, fws-str + i);
}
Easier to read and less error prone.
OK, now I've submitted code to handle underlining, together with the above
fix.
But, just now I reallised I've been testing using a UTF-8 locale.
I tried to run with a non-UTF-8 locale (sv_SE). Using the Arabic rc file,
it dumps core. But my usual configuration works (except Cond is no longer
valid...)
Now I feel so stupid... So the risk is the current snapshots only work
using Arabic in a UTF-8 locale.
I'll do further debugging ^_^
//Marcus
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Superimposing characters
Well, why don't you just fix it :-)
By the way, I don't understand why while loops are so popular. In
this case, you have all four parts of a for loop: initialisation,
condition, loop body and increment:
for (char_len = 0, i = 0;
i len fws-e_str[i] != 0;
char_len++, i += curr_len)
{
curr_len = FlocaleStringNumberOfBytes( flf, fws-str + i);
}
Easier to read and less error prone.
OK, now I've submitted code to handle underlining, together with the above
fix.
But, just now I reallised I've been testing using a UTF-8 locale.
I tried to run with a non-UTF-8 locale (sv_SE). Using the Arabic rc file,
it dumps core. But my usual configuration works (except Cond is no longer
valid...)
Now I feel so stupid... So the risk is the current snapshots only work
using Arabic in a UTF-8 locale.
I'll do further debugging ^_^
//Marcus
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: CVS malu: Removed F prefix on some files
Log message: Removed F prefix on some files Thanks. Bitte :-) I was the one guilty of decalaring a variable after a statement in a block. But I'm aware that this is not correct C. It was a mistake. I'm surprised that could compile. (I'm using gcc 3.3), is this a bug in gcc? That should only work in C++, shouldn't it? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: CVS malu: Removed F prefix on some files
But I'm aware that this is not correct C. It was a mistake. I'm surprised that could compile. (I'm using gcc 3.3), is this a bug in gcc? I love gcc :-P Yep, it's nice. That should only work in C++, shouldn't it? It's clearly not C and should not compile. In fact. it's legal in C99. http://www.cis.ohio-state.edu/cgi-bin/info/info/gcc,Mixed%20Declarations Maybe we should state that code must compile in C89 mode. A guess this is not anymore standard in gcc (I'm pretty sure it was in gcc 2.x). I guess -pendantic is a good idea to use. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: CVS malu: Removed F prefix on some files
Maybe we should state that code must compile in C89 mode. A guess this is not anymore standard in gcc (I'm pretty sure it was in gcc 2.x). I guess -pendantic is a good idea to use. That's declarations anywhere. I think Dominik was objecting to block declarations. By block declarations, do you mean to declare variables in any block, not just at the top of a function? Declaring variables in in arbitrary block (before real statements), I think has been allowed in C since at lest C89. //Marcus I'm not sure of the exact status of block declarations. I've been trying to find the standard with little luck. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Emacs and coding style
Is it possible to change the behaviour of the C mode in Emacs? It normally indents brases 2 columns from the parent line (if, while etc.) Or is there some alternative C mode recommended? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Problems building snap-20030702
I forgot to define the override macro when no FriBIDI (FBidiConvert) Thank you Jason! I'll make a test with FriBIDI disabled (it'll take some time, my machine is only 400 MHz, so it takes ages to compile, please be patient) //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Superimposing characters
I just commited my latest changes. Now FVWM can render combinational characters superimposed on top of the base character (even if there is no precomposed glyph). I tested the code with and without xft fonts and with rotated text. Please try make use of it to find any bugs. What remains is to fix the drawing of underlined characters, which I think is broken for BIDI locales (only partly related to combining charaacters). By the way, I forgot to include the function FlocaleTextWidth in one ChangeLog entry (only a minor change). Shall I commit just a ChangeLog entry for this? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FlocaleDrawUnderline and BIDI
On Mon, 30 Jun 2003, Olivier Chapuis wrote: On Sun, Jun 29, 2003 at 07:22:16PM +0200, Marcus Lundblad wrote: I'm almost done now with the implementation of superimposing combining characters. I wonder why the function FlocaleDrawUnderline doesn't call FlocaleEncodeWinString (to perform BIDI and so on). Probably a bug ... I never test underline with non standard strings. OK, I'll take a look at it. I guess we need to translate the positions from the original string to the corresponding positions in the new string. There is the ability to do so in FriBidi (I used it keep track of the positions of the combining characters. So I guess I'll add a the ability for FlocaleEncodeString to give back such an array mapping the positions, and then use that to to draw the underline. Should I put this in todo-2.6 as a normal bug (section B)? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FlocaleDrawUnderline and BIDI
I'm almost done now with the implementation of superimposing combining characters. I wonder why the function FlocaleDrawUnderline doesn't call FlocaleEncodeWinString (to perform BIDI and so on). Or did I misunderstand the code? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Xnest and Xft
Is it possible to use Xft with Xnest. I use to Xnest to debug FVWM when developing. I was about to try my patch with Xft fonts. But I get this message: Xlib: extension RENDER missing on display :1.0. And all title bars appears empty. I tried using the line: Style * Fontxft:Verdana:pixelsize=14 from the man page. It doesn't indicate that the font is missing, and if so wouldn't it use a default font? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xnest and Xft
On Sun, 29 Jun 2003, Tomas Ogren wrote: On 29 June, 2003 - Marcus Lundblad sent me these 0,6K bytes: Is it possible to use Xft with Xnest. I use to Xnest to debug FVWM when developing. I was about to try my patch with Xft fonts. But I get this message: Xlib: extension RENDER missing on display :1.0. Hm. That shouldn't be a problem. Maybe the first versions of Xft, but current versions and a while back can use RENDER to speed up antialiasing but work without.. I use it at work on the Solaris boxes which doesn't have a new enough X server to have RENDER.. What version of Xft are you using? I just installed Xft 2. xft-config says 2.0.0 but when I run configure (for FVWM), I get this: checking for xft-config... /usr/local/bin//xft-config checking for Xft - version = 2.0.0... no *** The Xft test program failed to run. If your system uses *** shared libraries and they are installed outside the normal *** system library path, make sure the variable LD_LIBRARY_PATH *** (or whatever is appropiate for your system) is correctly set. and if I run which xft-config from the command line, I get: /usr/local/bin/xft-config So, shouldn't it work? //Marcus /Tomas -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Support for combining/composing characters
On Wed, 11 Jun 2003, Nadim Shaikli wrote: Marcus, I just tried 'snap-20030611' with regard to combining (which also includes composing -- that's what unicode calls the act of 'superimposing of characters atop each other'). As far as arabic is concerned, still no composing is taking place. I'm wondering if you are abiding by the order of things that were suggested (it seemed like that was an issue before), http://www.hpc.uh.edu/fvwm/archive/0306/msg00042.html I can mail you sample test cases and fonts off-list if you'd like. Its rather simple really - you'll need, Yes, that would be nice. Thank you. + a font + a sample minimal .fvwm2rc + an xterm invoking script with the title to be composed + an image of the expected results (to compare against) I took a very quick peek at the code and don't see any considerations for true composing (and not replacing - what did I overlook ?). Case in point 0x0646 followed by 0x064E, don't see how composing is being taken care of (there is no resulting stand-alone glyph for what's noted) they need to be superimposed on top of each other. Yes, the first thing I did (which is in current CVS), is to combine for those characters were a composed glyph (equivalent to a base character and one or more combining characters) exists in Unicode. The next part (which I have more or less working, need some testing), is to pick out those remaining composing characters (like U+064E) into a list of (position,value) and also reoreder those positions after BIDI is applied. The next thing to do (the most complicated, I'm afraid), is to draw those composing characters on top of the normal characters. The hard thing, as it seems to me, is to calculate the position of each character in the ordinary string. One way is to draw each character separately and take care of all composing characters for a given character. The other might be to first draw the base string, then use the TextLength routine to backtrack the positions (in pixels) of each individual character. //Marcus Regards ( keep up the great work coming), Thank you! (Shukran) -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Getting re-ordering from FriBidi
I'm implementing the next step of combining characters. Separating out combining characters that couldn't be combined into a list for drawing as superimposed characters later on. So I gather these and there positions (the index of the last non-combining character). Then I need to know how characters are re-organised by the BIDI step. So I changed the call in FBidi.c to this: pos_l_to_v = (unsigned short int *)safemalloc((str_len + 1) * sizeof(unsigned short int)); fribidi_log2vis( logical_unicode_str, str_len, pbase_dir, visual_unicode_str, pos_l_to_v, NULL, NULL); where pos_l_to_v is upposed to contain a mapping afterwards. But when I fprintf the content, all I get is 135243992 135243992 135243992 135243992 135243992 135243992 135243992 135243992 135243992 135243992 135243992 135243992 135243992 135243992 135243992 (in this case) (The first string to be run through FlocaleEncodeString is + x + (for calculating geometry windows..) And also FVWM segfaults later on: (gdb) bt #0 0x400f2727 in XFindOnExtensionList () from /usr/X11R6/lib/libX11.so.6 #1 0x400ebf4c in XFreeFont () from /usr/X11R6/lib/libX11.so.6 #2 0x400eb8d1 in XLoadQueryFont () from /usr/X11R6/lib/libX11.so.6 #3 0x40024b4f in load_font () from /usr/X11R6/lib/X11/locale/common/xomGeneric.so.2 #4 0x40024c49 in _XomConvert () from /usr/X11R6/lib/X11/locale/common/xomGeneric.so.2 #5 0x40023b2d in _XomGenericTextEscapement () from /usr/X11R6/lib/X11/locale/common/xomGeneric.so.2 #6 0x40023b69 in _XmbGenericTextEscapement () from /usr/X11R6/lib/X11/locale/common/xomGeneric.so.2 #7 0x4011d9e7 in XmbTextEscapement () from /usr/X11R6/lib/libX11.so.6 #8 0x080bbd0d in FlocaleTextWidth (flf=0x810ffd8, str=0x3e07c725 Address 0x3e07c725 out of bounds, sl=1040697125) at Flocale.c:1735 #9 0x08066dbc in resize_geometry_window () at move_resize.c:621 #10 0x08088d5b in main (argc=3, argv=0xb224) at fvwm.c:2424 #11 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) If I change pos_l_to_v back to NULL in the call to FriBidi, it works as before. Am I foreseeing something here? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Getting re-ordering from FriBidi
Ooops. The information on FriBidi's webpage is not up to date. There it gives the lists as gint16, but in the actual headers there is a FriBidiStrIndex (which is defined as int). //Marcus On Mon, 9 Jun 2003, Marcus Lundblad wrote: I'm implementing the next step of combining characters. Separating out combining characters that couldn't be combined into a list for drawing as superimposed characters later on. So I gather these and there positions (the index of the last non-combining character). Then I need to know how characters are re-organised by the BIDI step. So I changed the call in FBidi.c to this: pos_l_to_v = (unsigned short int *)safemalloc((str_len + 1) * sizeof(unsigned short int)); fribidi_log2vis( logical_unicode_str, str_len, pbase_dir, visual_unicode_str, pos_l_to_v, NULL, NULL); where pos_l_to_v is upposed to contain a mapping afterwards. But when I fprintf the content, all I get is 135243992 135243992 135243992 135243992 135243992 135243992 135243992 135243992 135243992 135243992 135243992 135243992 135243992 135243992 135243992 (in this case) (The first string to be run through FlocaleEncodeString is + x + (for calculating geometry windows..) And also FVWM segfaults later on: (gdb) bt #0 0x400f2727 in XFindOnExtensionList () from /usr/X11R6/lib/libX11.so.6 #1 0x400ebf4c in XFreeFont () from /usr/X11R6/lib/libX11.so.6 #2 0x400eb8d1 in XLoadQueryFont () from /usr/X11R6/lib/libX11.so.6 #3 0x40024b4f in load_font () from /usr/X11R6/lib/X11/locale/common/xomGeneric.so.2 #4 0x40024c49 in _XomConvert () from /usr/X11R6/lib/X11/locale/common/xomGeneric.so.2 #5 0x40023b2d in _XomGenericTextEscapement () from /usr/X11R6/lib/X11/locale/common/xomGeneric.so.2 #6 0x40023b69 in _XmbGenericTextEscapement () from /usr/X11R6/lib/X11/locale/common/xomGeneric.so.2 #7 0x4011d9e7 in XmbTextEscapement () from /usr/X11R6/lib/libX11.so.6 #8 0x080bbd0d in FlocaleTextWidth (flf=0x810ffd8, str=0x3e07c725 Address 0x3e07c725 out of bounds, sl=1040697125) at Flocale.c:1735 #9 0x08066dbc in resize_geometry_window () at move_resize.c:621 #10 0x08088d5b in main (argc=3, argv=0xb224) at fvwm.c:2424 #11 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) If I change pos_l_to_v back to NULL in the call to FriBidi, it works as before. Am I foreseeing something here? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Support for combining characters
the crux of which is spelled out in (IMHO), http://www.hpc.uh.edu/fvwm/archive/0303/msg00199.html If I extend my function that does composing to fill in an array mapping character position in the in-string to their visual position. For example, let's say there is o + some obscure composing char + a, where there is no pre-composed form for an o with some obscure composing char, it would give an array: [0,0,1] That is the first 2 characters should get drawn in first square, the last in the second square. What could perhaps be tricky is to handle BIDI. The mapping array must be rearranged as characters are reorganised by the BIDI algorithm. I do not understand the problem, sorry. But two remarks/questions: What about merging FCombineChars, FBidi and FBidiJoin? I think, as was noted previously, the best approach to take here is to do the following (order matters - I'm listing in execution order), 1. Do Bidi - if needed of course 2. Do Shaping (sometimes described/termed joining) - Shaping/Joining is the morphing of characters based on their location within a word (initial/medial/final/stand-alone) 3. Do Combining - There are some characters out there that will need to be combined (meaning you take A+B - C -- yup, two characters result in one; this is a complete replacement act. C is brand new glyph) 4. Do Composing - This is the superimposition of one character on top of one that proceeds it (meaning you take E+F - G -- yup two characters result in one; the key here is that G is NOT a new glyph its simply E with F superimposed on it). Everything is currently coded-up (in one state or another) except for #4 above (its still a mystery to me how that is done, Olivier ?). I've done 4 also. But I do 3 and 4 before 1 and 2. maybe this is not so good. How does the BIDI handle combining characters? Does it preserve the order? So that for example Alef + combining character is not swapped. If that's the case, maybe I should do the combing and composing after BIDI and then extract remaining combining characters to allow for superimposing //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Support for combining characters
Yes, but I know nothing on combining, bidi and joint ... If I extend my function that does composing to fill in an array mapping character position in the in-string to their visual position. For example, let's say there is o + some obscure composing char + a, where there is no pre-composed form for an o with some obscure composing char, it would give an array: [0,0,1] That is the first 2 characters should get drawn in first square, the last in the second square. What could perhaps be tricky is to handle BIDI. The mapping array must be rearranged as characters are reorganised by the BIDI algorithm. I do not understand the problem, sorry. But two remarks/questions: What about merging FCombineChars, FBidi and FBidiJoin? Which charset (in the sense of the FlocaleCharsetTable from FLocaleCharset.c) needs Char Combining and which charset needs Joining (I know for Bidi)? Sometimes there is no character defined in Unicode for a specific combination of an ordinary character (for example an o) and some unusual combinational character. In this case, the best thing to do is to draw the combinational character at the same position as the o, to get an approximation of what the combined character would look like. I think the combination algorithm is a bit different from the contextual shaping used for Arabic. Also the Arabic joining and shaping is only done if BIDI is enabled (and using a charset needing BIDI). I think Arabic joining should only be done if BIDI is done. It seems to me it wouldn't make sense to do that without BIDI. Nadim, do you have an opinion? I found some case where the algorithm fails, so I will continue to refine it before making further descitions Can you send some relevant strings (in UTF-8 or/and others encoding) for adding test in purify.fvwm2rc? Yes, I will take care of this. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Support for combining characters
I implemented a first basic version of combining characters. What it does is compress sequences of characters to the canonical pre-composed form. Additionally a fix for superimposing needs to be added. Ie. combining characters that could not be composed into a pre-composed form should be drawn superimposed. Olivier, could you assist me a bit on this? If I extend my function that does composing to fill in an array mapping character position in the in-string to their visual position. For example, let's say there is o + some obscure composing char + a, where there is no pre-composed form for an o with some obscure composing char, it would give an array: [0,0,1] That is the first 2 characters should get drawn in first square, the last in the second square. What could perhaps be tricky is to handle BIDI. The mapping array must be rearranged as characters are reorganised by the BIDI algorithm. I hope my code is not crashing on anyone. Please test it. I have tested it, and it seems to work. But maybe I missed something critical. Also Nadim, could you test this with Arabic combining characters? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: in v2.5.6, cannot simply remove Mouse 2 binding via '-' function
On Fri, 25 Apr 2003, Dan Espen wrote: parv [EMAIL PROTECTED] writes: I cannot seem to remove default 'Mouse 2' binding to Builtin Menu by using '-' function, in fvwm 2.5.6 ... Mouse 2 R N - The built in binding is: Mouse 0 R N Menu MenuFvwmRoot Maybe this should be changed to Mouse 1 R N Menu MenuFvwmRoot Mouse 2 R N Menu MenuFvwmRoot Mouse 3 R N Menu MenuFvwmRoot because 0 will match all buttons, also the scrollwheel on such mice. Perhaps this is a bit annoying. On the other hand, there may be mice where button 4 is actually a real button. Is it possible to detect somehow? Does the X server report such things? If this would be so, it would be possible to redefine Mouse 0 to only match normal buttons. And perhaps Mouse U,Mouse D for scroll. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Switching to the new web design
On Sun, 20 Apr 2003, Mikhael Goikhman wrote: All pages seem to be converted. The new design is pretty usable now although it does not have yet all planned extra features. Please test it at http://fvwm.org/index.php I think we may make it the default today. The old pages may still be here, but they should be removed in some near future after error404 supports the old-to-new url mapping. The window decorations don't render properly in Netscape 6 under Windows. There is a grey border around, as if to much space is reserved before drawing. It works in IE 6, though... And using Mozilla 1.4beta (Linux) works nicely. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Composing characters
I started hacking in FBidiJoin.c to add the support for composing characters. But it seems shape_n_join() isn't called. configure reports FriBidi is used and I think I tried Arabic joining within FVWM some time ago. Or is it that stderr isn't output as expected? (I added fprintf to stderr as debugging). I started the my testing version of FVWM manually, so I think it should output stderr on the terminal... //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Composing characters
Are you sure you use an Arabic locale or text encoding? shape_n_join is only called from FBidiConvert which in turn is only called for bidi-requiring (i.e. right-to-left) encodings, see FlocaleCharsetTable in FlocaleCharset.c. OK, I see. I guess I'll take out this code from the BIDI stuff. And I suppose I should use the fuctions from Flocale.c and Ficonv.c to convert input string to Unicode. Should I run FiconvCharsetToUtf8 straight away? The comment says: /* conversion from the current charset to UTF8 */ But the the function takes an argument FlocaleCharset. What value is this supposed to have? Or do I already have this in FlocaleEncodeString, where I guess the calls to my routines would be. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Composing characters within fvwm
So if I well understand, FBidiJoint.c should be updated to handle some composing char. Nadim can you send a patch? An other issue is that FBidiJoint has nothing to do with bidi and it should be use even if libfribidi is not detected? I think the way to go is this: First map all characters to their combing class, (normal characters have combining class = 0, various combing chars have different combinging classes != 0). Then traverse the string, looking at pairs of chars: if combining-class(c1) combining-class(c2), swap c1 and c2 (and corresponding combining classes). Traverse one character at a time like this. Do this until no more swapping can be done. Now traverse the resulting string each pair of characters if there is a mapping for it to a precomposed form. For example: A + diaresis = Ä Repeat this until no replacing is done. Note that now multiple combination can be done like this: A + diaresis + acute = Ä + acute = A with diaresis and acute (don't have this character at hand...) Since the combinging characters are orderd, a mapping like this would work. Last we can take remaining combining charaters and superimpose them as Olivier suggests. I'm not sure though wether we need to do a step before all this that decomposes any eventual precomposed forms to make it correct. For example suppose we have: Ä + acute and Á + diaresis The first would yield a A with diaresis and acute but the second would give Á with diaresis, since there will be no mapping for this order of combinging, thus the superimposition would be used in this case. I don't know if this would be a problem. We might need to first apply a decomposistion: such that A with diaresis and acute will map to Ä + acute which will in turn become A + diaresis + acute //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Composing characters within fvwm
Maybe. Does a composing_char + a_given_char = another_given_char in UTF-8 or USC-2? If yes and a table can be found somewhere we can add an other converter (as FBidiJoint.c). If not we should draw string char by char and take care of these composing characters (I do not like so much this solution). A last solution is to use Pango, but it is not the direction we have taken so far. I think composing is a little more complicated than this. If I understand correctly the spec. several composing chars can follow a character forming a new character, so that for each composable character there is forms for all combinations of composing chars, but the order of composing chars is irrelevant. So for example a + umlaut + cedilla would be the same as a + cedilla + umlaut. So a solution would be to sort all composing characters following a character and map the resulting substring to a precomposed character. //Marcus Can you send me the fvwm config which allows you to produce composing_fvwm_bad.jpg. Regards, Olivier -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Composing characters within fvwm
Olivier, I don't think its another_given_char that needs to be produced. What needs to happen (per what unicode notes and what I've seen) is to super-impose the second character on _top_ of the first -- that's why those characters (including 'umlaut') have a dashed/dotted circle within their glyph representations in the various code charts. Those dashed/dotted circles are there to denote a hypothetical location of the character that proceeded it. Actually it needs to be replaced by a new glyph. For example: G + cedilla = G with a cedilla _under_ g + cedilla = g with a cedilla _above_ (U+0122 and U+0123) //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Composing characters within fvwm
Marcus, out of curiosity -- is this done visually only or is what's stored to disk actually changed ? ie. what is stored to disk (U+0047 + U+0327 or U+0122) ? Actually both ways can be used in cases where a precomposed form is present in Unicode. Although it's recommended to used composing characters. The characters in the Latin 1-part will mostly be stored in precomposed form due to tradition. Further, sorting is another interesting thing. Precomposed and composed variants is equal. And then there are different sorting order for different languages, but that's another story... I can see that there are a few exceptions to the superimposition (you note one above with U+0327 when its proceeded with g -- looks like the cedilla oddly enough goes from below to above mysteriously), but overall it would still visually look OK if things were superimposed given the exceptions were taken care of, check the various other characters - http://www.unicode.org/charts/PDF/U0100.pdf). I can only conclude one of two things at this point, 1. All composers are superimposed with a few exceptions in which replacements are used. -or- 2. There are two flavors of composing characters and their meaning. Some that get superimposed while others dictate the need to change a previous form. I would tend to think it'd be #1 I think using a precomposed form, if defined and available and superimpose otherwise is a good idea. By the way, how general is the shaping and joining code you wrote? Some other alphabets (besides Arabic) could make use of this (perhaps in a modified variant). //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Bug B.4, combining characters
Is the bug about combining characters in todo-2.6 really a bug? Is it supposed to work automatically. Is this supposed to be handled by the X-calls that are used? Wouldn't this have to be handled in the code (or a library used). I think Pango should be used for this, but it seems like a larger rewrite for this, is text rendering already done in libfvwm? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Getting output from FvwmCommand in a shell script
I'm writing a shell script to test the geometry styles and conditions.
I have the following function in my script:
TestCondition()
{
condition=$1
off=0
if [ $2 = off ]; then
echo negative cond
off=1
fi
if [ $off = 0 ]; then
result=`FvwmCommand All ('Test window' $condition) echo 'match'`
else
result=`FvwmCommand All ('Test window' \!$condition) echo
'match'`
fi
echo $result
if [ -z $result ]; then
return 0
else
return 1
fi
}
But the variable $result is always set to an empty string.
I see output in the shell like this:
[FVWM][Echo]: 'match'
Does the Echo command write to Fvwm's standard error?
//Marcus
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Request for feature: Sticky indicator toggle
Hi. The way I see it, there is currently no way to turn off these horizontal lines that are drawn on the title bars of sticky windows. They are mostly useless if you use a titlebar button to stick/unstick (+mwm hints), and sometimes simply look bad, especially on a textured titlebar. Would it be possible to add new style options, eg. ShowStickbars/!Stickbars? So that I could decide if I wish to see them or not? Well, maybe not as an style option, but an attribute to TitleStyle, like flat or noinset (TitleStyle -- nostickbars maybe?) It's nothing really important, but would be nice. Actually, I have planned to implement such a style. But it will be after 2.6 is released, so mayby in the next beta series. I also don't relly like the stiples. Mostly windows I have as sticky are obvious sticky ones, such as the pager, icon box, etc. I think it's a little redundent information to indicate on stickyness on these. Mayby as a part of TitleStyle is better, any more opinions anyone? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
RE: Request for feature: Sticky indicator toggle
Visually distinct sticky vs. slippery windows is one of the nice features we got when we changed from fvwm95 to fvwm2. The ribbed look is a plus - it's a good visual discriminator for our users, even for the Pager. A new Style/Titlestyle is fine, but my vote is to keep the ribs as the default for sticky's. Yes, I think the current behaviour is a good default. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Determining if a window is iconified.
Is there some good way (from a shell script) to determine if a window is iconified? I'm writing tests for the new Closable, Maximizable etc. styles. xwininfo gives the geometry of the windows normal size, so there is no difference when iconifiying. I guess an alternative is to have an interactive script where the user is asked wuestions interactivly. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Problems updateing colour sets for window titles
I have a menu to sets colour sets. It runs a script that generates colour sets (and also generates .gtkrc and sets X resources). It used to work flawless, but now the colour is only updeted for the active window. Changing focus updates windows to the new colour. And restartting also works. I have only used colour sets in 2.5.x, so I guess this doesn't happen in 2.4.x). //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: CVS malu: Fixed the Makefile for the hints test to link to libfvwm.a
Um, why do we have a plain Makefile in the CVS tree? Writing a Makefile.am is much easier and much more portable. Good question. I just wanted to run that test, so I temporarily updated the makefile. I guess it's not really that great to have a hardcoded makefile. Have to learn how automake works... //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Mysterious command
I looked at the content of the directory sample.fvwmrc, and found this command bound to a mouse-action on a title button: Replace Just curious if someone knows where this command comes from, was there a command like that before? And what did it do? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: CVS migo: * All single letter variables are depricated now.
If your mailer allows, please configure it to add a header Mail-Followup-To: fvwm-workers@fvwm.org to your messages to this list, so I and others with compliant mailers will not need to remove your address manually when replying to your messages. You will reduce a mail traffic after configuring the mailer this way. In mutt it is just a line subscribe fvwm-workers@fvwm.org in .muttrc. I'm using pine. I set the Reply-To: header for this list. I'm not sure if this is the correct way to do it. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: CVS migo: * All single letter variables are depricated now.
* Documented Closable and company, please keep NEWS up to date. Oops, I forgot to edit NEWS. I will also add the corresponding conditionals (Closable, etc.) //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
The name of the command WindowShade
Why is WindowShade not just called Shade? I was wondering, because I plan to add a style Shadable to match Closable etc. WindowShadeable looks a little weird to me. Is the command called like this to not confuse with shadows of colorsets? Would anyone have objections about a style Shadable? I'm not sure if I will add this before the feature freeze though. Since this will also call for a conditional Shadable and possible a style AllowShadeFixedSize. And also a style AllowIconifyFixedSize should probably be added for consistency. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FvwmIconBox
I made a patch for IconBox before (adds options to set the title reliefs for iconified/normal windows and turn off parenthesis around titles). It never got incorporated before. But I didn't here any complaints, so I guess it just got lost in the noise. If there is no objection, I'll commit it now. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FvwmIconBox, again
When looking through the Changelog, it seems my patch was commited. Strange, because when I do cvs update, it marks these files as modified. And doing diff shows the changes I made. Maybe I need to delete the files and upate again. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FvwmIconBox, again
On Mon, 6 Jan 2003, Dan Espen wrote: Marcus Lundblad [EMAIL PROTECTED] writes: When looking through the Changelog, it seems my patch was commited. Strange, because when I do cvs update, it marks these files as modified. And doing diff shows the changes I made. Maybe I need to delete the files and upate again. I believe the ChangeLog got updated from the patch of yours I applied. I thought you were including that for some prior patch you submitted that was missing a changelog. Yes, the patch wasn't really applied, it seems. Good I saved the diff //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: New non-window conditional command On
I think its clear that we have to stop adding things to 2.5.x and turn it into a stable release. For that, we need to make sure we have a complete set of features, get the documentation up to date and create test cases. I think I've seen todo lists from all the major players. Just keep publishing them. (And try to make them get smaller over time.) Make sure that test cases are part of your todo lists. My plan is to remove the unnessesay Closable,Maximizable,Iconifiable and AllowMaximizeFixedSize since they correspond to ! variants of Unclosable,Unmaximizable,Uniconifiable and DisallowMaximizeFixedSize Does it make sence to let the non-default styles be the only ones, and have the opposite styles as the default? I guess this should be done for all styles. But I guess this will be done for 3.0, since it breaks backwards compatablility. Also, I might add a DisallowIconifyFixedSize to complement DisallowMaximize fixed size. But I guess this would also call for a DisallowShadeFizedSize. Or maybe this better wait until after 2.6. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Icons (was: FvwmPager enhancements)
Speaking about this screenshot, the framed icons are already possible. Olivier, how about to rename IconBackgroundColorset to IconFrameColorset? Actually, in 4dwm (and mwm,dtwm etc.), the decoration (frame) is the same colour as the icon title (follows active/inactive state). So maybe there could be IconFrameColorset/HilightIconFrameColorset that defaults to IconTitleColorset/HilightIconTitleColorset. And a style IconBorderWidth that sets the width of the border, would default to 0, no border, the current behaviour. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Icons (was: FvwmPager enhancements)
how about to rename IconBackgroundColorset to IconFrameColorset? So maybe there could be IconFrameColorset/HilightIconFrameColorset that defaults to IconTitleColorset/HilightIconTitleColorset. I think the default should be like it is now - no icon frame colorset. Even if IconTitleColorset is defined. And a style IconBorderWidth that sets the width of the border, would default to 0, no border, the current behaviour. Which one from the current IconTitleRelief, IconBackgroundRelief, IconBackgroundPadding or IconSize do you mean? I was thinking that the border comes outside of the icon background as it is now. So there will be an inner rectangle corresponding to using: Style * IconBackgroundColorset whatever as it is now (including IconBackgroundRelief if not 0). Then Style * IconBorderWidth 5 (for example) will add a border outside the icon background rectangle. The question is if the the relief width of the border shall be the same as the relief of the title. And what happens if a user sets the border width smaller than the title relief. Maybe when using icon borders, the relief shall be conbined with the title relief. If you look carefully (xmag) on an MWM icon, you will see that the border relief is 2 pixels wide but the relief lines immediatly above the title (2 horizonal lines, one hilighted, one shadowed) is only 1 pixel wide. So the icon is drawed as one big rectangle with a 2 pixel relief. I made a screenshot show this (icon.png) I also made an image (icon2.png) show approximatly how a Style * IconBorderWidth 2 would (possibly) look like with a relief of 2 pixels (inner relief of border is 1 pixel), in combination with Style * IconBackgroundRelief 1 I'm not sure what IconBorderWidth would do when not using IconBackgroundColorset. Should the interiour region still be transparent? I see no problem in keeping the current behavoiur without IconSize, though. Let the interiour region be as big as the picture (+ padding if used) in this case. //Marcus icon.png Description: PNG image icon2.png Description: PNG image
CVS mode in Emacs.
Is it possible to use the CVS mode in emacs to commit changes? I'm wondering, since when comming in this mode, you are prompted for a description for each file you commit. Will this generate an email for each file? Or is there some other way to do it? I'm used to using Emacs for working with CVS, think it's quite handy. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Colorset wish-list
4) In FvwmPager it would be nice to have {Hilight}TitleColorset, the
current plain rectangle taken from HilightColorset is really not enough.
What does this mean? 2 different colorsets used to draw the mini-windows,
will the title colorsets be used to draw just the title part of the
mini-window?
Just curious.
//Marcus
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Colorset wish-list
They would be used to draw the title of the pager desks, not mini-windows. Run this command to see what this may mean: FvwmPager UnexistingConfig 0 3 So it would be possible to use different colour for the desk labels than the desk background (or use pixmaps as desk backgrounds and still have coloured labels), that's pretty nice. I was thinking about another feature for the pager. To allow to have an extra border around the desks that could be given different colours for active/not active desk. This way it would be easier to know which is the active desk when not using labels. It would also be possible to get a relief effect (so that for example the desks looks like buttons where the active one is pressed in). //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Colorset wish-list
Yes, the look of a pager could be improved, the only problem is that if it is only one solid colored line border it will not look nice. I was thinking about using highlight and shadom from a colourset to draw this border. This way it would be possible to get both a flat and a beveled look. Maybe the same thing could be done for the labels. This way it would for example be possible to have the labels act like buttons and have the active desktop surrounded by a distict coloured frame. I think it is pretty difficult to design a nice look that is also configurable. Yes, I agree. For example, I like the look of ov, the pager used by 4dwm in IRIX, but something like this would be quite specific. It is already possible to have raised in/out look if you use corresponding images. Not exactly what you want, but I am pretty satisfied with: Yes. But the problem is that the size can in some cases vary. For example if you use DeskTopScale and use workstations with different resolutions (or buy a bigger monitor :) ) http://fvwm-themes.sourceforge.net/tmp/migo-FvwmPager.png I don't know myself what I would prefer to see in place of Work title. So even if this HilightTitleColorset is implemented it is still not trivial to use it effectivelly. Of course, it would be better to have only Fun titles and not to have to work, but this is not an option... Yes, how about a new option: fvwm --do-all-my-work now ^_^ //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Issues with new icon styles
But when iconifiying an xeamcs, there is a black background around the icon picture (inside this is the icon picture provided by xemacs with a grey background). I think xemacs is not providing the black part. When running mwm there is no black background. The part outside the grey background area is coloured with the standard coulour of icons (a small band inside the icon border). Is this fixed now? Yes, now it gets the correct background colour. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Issues with new icon styles
I see a bug for icons _with_ a mask (XClock icon), the mask disappear when there is an icon bg cset: the transparent part has the colour of the title (Ooops fixed). But on the non transparent part (and so for monochrome icon without a shape mask) IMO it is normal that the colours of the icon follow the title colour (fg part of the icon). In the same way IconTint and IconAlpha colorset option are taken from the icon title colorsets and not from the icon bg one. I've just fixed a bug related to this. Can you try latest cvs and report this bug in a precise way if it is still there. I tried the later build (from yesterday), and that bug I was seeing before is gone. But when iconifiying an xeamcs, there is a black background around the icon picture (inside this is the icon picture provided by xemacs with a grey background). I think xemacs is not providing the black part. When running mwm there is no black background. The part outside the grey background area is coloured with the standard coulour of icons (a small band inside the icon border). Perhaps there is a problem with differenr visuals? By the way, I really like the new icon background feature. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Issues with new icon styles
I tried the new icon styles that Olivier added yesterday. There is one thing that is a bit odd. If I specify: Style * IconBackgroundColorset 1 and I have colorset 0 for active windows and colorset 1 for inactive windows. Then icons that are monochrome (it seems) still gets the background set to the colour of the title (as before). Maybe there shall be different Backgroundcolorsets for active and inactive and let them default to the same as the title? And also there seems to be a bug when using IconBackgroundPadding on such icons (the label doesn't adjust). //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: New style options and conditionals.
On Sat, 21 Dec 2002, Dan Espen wrote: That reminds me, the tests directory is not being updated. There will never be a 2.6 unless there is an adequate set of How much work is it to update the tests? I could perhaps dive into this at the end of next week. Unfortunatly right now I'm stuck with a Windows machine. (and downloading cygwin over a modem is not fun...) On Sat, 21 Dec 2002, Dan Espen wrote: Marcus Lundblad [EMAIL PROTECTED] writes: Here is the patch for the new styles: Closable, Iconifiable, Maximizable and AllowMaximizeFixedSize and conditionals Closable, Iconifiable and Maximizable The style AllowMaximizeFixedSize turns on and off the possibility to maximise windows that are fixed size (ie. the function Resize is not allowed). Well, I finally got around to applying this one. I did some tests and it seems to work as advertised. That reminds me, the tests directory is not being updated. tests. I had a question about this wording in the man page: .IR AllowMaximizeFixedSize enables the function .I Maximize to be performed on windows that are not resizable, unless maximisation has been disabled either using the style .I Unmaximizable or throuth WM hints, This on by default. .IR DisallowMaximizeFixedSize disables the function .I Maximize for all windows that are not resizable. Note that some applications set the window's minumum and maximum size the same and and expect this to mean that the size is fixed. This style forbids maximisation of such windows. The last 2 sentences seem to say the same thing, and seem to be out of place. Since this is disabling maximization, I don't thing anything is necessary. -- Dan Espen E-mail: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: New style options and conditionals.
On Sat, 21 Dec 2002, Dan Espen wrote: Marcus Lundblad [EMAIL PROTECTED] writes: Here is the patch for the new styles: Closable, Iconifiable, Maximizable and AllowMaximizeFixedSize and conditionals Closable, Iconifiable and Maximizable The style AllowMaximizeFixedSize turns on and off the possibility to maximise windows that are fixed size (ie. the function Resize is not allowed). Well, I finally got around to applying this one. I did some tests and it seems to work as advertised. That reminds me, the tests directory is not being updated. There will never be a 2.6 unless there is an adequate set of tests. I had a question about this wording in the man page: .IR AllowMaximizeFixedSize enables the function .I Maximize to be performed on windows that are not resizable, unless maximisation has been disabled either using the style .I Unmaximizable or throuth WM hints, This on by default. .IR DisallowMaximizeFixedSize disables the function .I Maximize for all windows that are not resizable. Note that some applications set the window's minumum and maximum size the same and and expect this to mean that the size is fixed. This style forbids maximisation of such windows. The last 2 sentences seem to say the same thing, and seem to be out of place. Since this is disabling maximization, I don't thing anything is necessary. Actually according to Dominic, setting min- and max-size doesn't inhibit maximisation, unless maximisation is explicitly forbidden (through mwm-hints or such). And setting style FixedSize doesn't automatically disable maximisation as one expects. So using Style !AllowMaximizeFixedSize always disables maximisation on windows that are not resizable. Maybe I was´a bit unclear in those sentences in the manual page. And thanks for applying the patch. And Merry Christmas, Ein frühlich Weinacht, God Jul and Happy New Year and so on... to all on this list. //Marcus -- Dan Espen E-mail: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
New style options and conditionals.
Here is the patch for the new styles: Closable, Iconifiable, Maximizable and AllowMaximizeFixedSize and conditionals Closable, Iconifiable and Maximizable The style AllowMaximizeFixedSize turns on and off the possibility to maximise windows that are fixed size (ie. the function Resize is not allowed). //Marcus newstyles.patch.gz Description: Binary data
Style Closable/Unclosable
I'm implementing new styles to control allowed operations on windows. Looked at the code in decorations.c (is_function_allowed) I see that the MWM hint Close disables both Close and Destroy. So I'm not quite sure what is the best thing to do: Follow this behavoiur with the new style, implement an additional style or always permit Destroy, There is also a comment in the code: /* shouldn't destroy always be allowed?? */ Maybe that should be so, Destroy should always be possible. Thought I would want to hear som opinions. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Style Closable/Unclosable
On Sat, 14 Dec 2002, Dan Espen wrote:
Marcus Lundblad [EMAIL PROTECTED] writes:
I'm implementing new styles to control allowed operations on windows.
Looked at the code in decorations.c (is_function_allowed) I see that the
MWM hint Close disables both Close and Destroy.
So I'm not quite sure what is the best thing to do: Follow this behavoiur
with the new style, implement an additional style or always permit
Destroy,
There is also a comment in the code:
/* shouldn't destroy always be allowed?? */
Maybe that should be so, Destroy should always be possible.
Thought I would want to hear som opinions.
Destroy is still possible, thru keybindings, mousebindings,
and root context menus.
Is Destroy handled specifically when it's used?
As far as I can see the code in is_function_allowed is the same for
Close and Destroy:
case F_CLOSE:
if (IS_TEAR_OFF_MENU(t))
{
/* always allow this on tear off menus */
break;
}
if (!(functions MWM_FUNC_CLOSE))
{
return False;
}
break;
case F_DESTROY: /* shouldn't destroy always be allowed??? */
if (IS_TEAR_OFF_MENU(t))
{
/* always allow this on tear off menus */
break;
}
if (!(functions MWM_FUNC_CLOSE))
{
return False;
}
break;
If I've not missed anything (have got an hangover today... ^^ ), this
could be written as:
case F_CLOSE:
case F_DESTROY:
if (IS_TEAR_OFF_MENU(t))
{
/* always allow this on tear off menus */
break;
}
if (!(functions MWM_FUNC_CLOSE))
{
return False;
}
break;
Also I'm thinking about wether Style Unclosable should apply also for
tear-off menus.
The argument in favour: The user has requested this
expliciltly through a style
The arguments against: It is incosistent with how hints are handled and
there is no other way to close it (what does destroy do on a tear-off,
kill fvwm?).
The source code for mwm is now downloadable.
I'd say whatever mwm does is the right thing to do.
Yes, I guess this would be a good idea.
I will look at this when I get time. During the holidays I will visit my
parents, unfortunatly they only have Win2000
//Marcus
--
Dan Espen E-mail: [EMAIL PROTECTED]
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm-workers in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Style Closable/Unclosable
On Sat, 14 Dec 2002, Dan Espen wrote: Marcus Lundblad [EMAIL PROTECTED] writes: On Sat, 14 Dec 2002, Dan Espen wrote: Hmm, hangover, I'LL TRY NOT TO SHOUT! Thanks! :) Yep, its the same. Also I'm thinking about wether Style Unclosable should apply also for tear-off menus. The argument in favour: The user has requested this expliciltly through a style The arguments against: It is incosistent with how hints are handled and there is no other way to close it (what does destroy do on a tear-off, kill fvwm?). It only takes a second to try it. (No it doesn't kill Fvwm.) I don't know why we would need a Style Unclosable. We have more direct methods of removing the close button from a titlebar. (I know it affect context menus too.) Well, too late :-) I already implemented (Un)Maximizable, (Un)Iconifiable (spelleing?), (Un)Closable. I also implemented AllowMaximizeFixedSize/DisallowMaximizeFixedSize if DisallowMaximizeFixedSize is on, if resize is not permitted then maximize is automatically also disabled (in is_function_allowed). AllowMaximizeFixedSize gives the default behaviour ie. maximize is allowed unless turned off by hints or through the style option. I think the idea of the MWM hint, is that applications that didn't implement the delete window protocol would set the hint. This was to encourage the user to use other means to close the window, perhaps the file-close menu entry. It all seems pretty pointless anyway, Fvwm can still apply close/delete to the window. I always thought it was more for appearance. Yes, I guess it's more for appearance. But I found a use for Uniconifiable. When using the icon box, either I have to turn on icon for the icon box Style * NoIcon Style FvwmIconBox Icon or assign a special menu for the icon box window that lacks an iconify entry. In my opinion the Uniconifiable style is more clear than using special functions. And even if you replace all Iconify in the config with a complex function it's still possible to use an FvwmConsole. And so for consistency I thought I might as well implement the others. And I guess I'll trow in conditionals for these 3 aswell. //Marcus -- Dan Espen E-mail: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
merge_styles(),handle_new_window_style
There is a comment in style.c that says that you have to add code for new styles in merge_styles() and handle_new_window_style(). In merge_styles I see only code for a few styles and a general merge routine. Is on-off-styles handled automatically? And how about new windows? It is my impression that the flag fields are zeroed on creation. If this is so I don't need to do any any special code here for my new styles. And as far as I can see it works. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: merge_styles(),handle_new_window_style
On Sat, 14 Dec 2002, Mikhael Goikhman wrote: On 14 Dec 2002 18:35:06 +0100, Marcus Lundblad wrote: There is a comment in style.c that says that you have to add code for new styles in merge_styles() and handle_new_window_style(). In merge_styles I see only code for a few styles and a general merge routine. Is on-off-styles handled automatically? And how about new windows? It is my impression that the flag fields are zeroed on creation. If this is so I don't need to do any any special code here for my new styles. And as far as I can see it works. The initial style value for bit options is zero by default. To define non zero default add a corresponding Style * in ConfigFvwmDefaults. Boolean style options are merged automatically if you set corresponding style masks using macros, so you only need to define macros and call them when Style command is issued. I hope you don't name your style options UnIconifiable, since you have !Iconifiable automatically, this would be the only syntax for boolean options. I added styles with and without Un for all three (opposites). Shall all opposite-names be removed? And only the !-variant work in the future? I added the Un variants to be consistent with the existing options. I guess removing redundant styles will not be done before 2.6 And yes, I defined macros to set the bit masks. So for Iconifiable for example the bitfield is named is_uniconifiable (since the default value, 0, means not uniconifiable ie. the default value). //Marcus Regards, Mikhael. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Plans, was: things to be done for 2.6
I have some plans for new menu functionallity. This will have to wait until after the feature freeze for 2.6, ofcourse. The idea (as discussed before) is to have conditional statements in menus. For example have conditionals to make an item inactive (greyed out), unavailable and choose different labels depending on conditionals. For example: AddToMenu WindowMenu + Inactive(!Maximized, !Iconified) Restore RestoreFunc ... + Skip(FixedSize) Size Resize ... + If(Sticky) Unstick Stick off Else Stick Stick on Suggestions are ofcourse welcome. I plan to use the code as the other conditional statements. And also I plan to add conditionals for all function hints (I implemented conditionals FixedSize and HasHandles). This would also involve new styles FixedPostion, Uniconifiable and so forth. Yes I know, many people hate when these hints are used. But after all these are styles so it means freedom for the user... //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Plans, was: things to be done for 2.6
On Mon, 9 Dec 2002, Mikhael Goikhman wrote: On 09 Dec 2002 20:34:04 +0100, Marcus Lundblad wrote: I have some plans for new menu functionallity. This will have to wait until after the feature freeze for 2.6, ofcourse. The idea (as discussed before) is to have conditional statements in menus. For example have conditionals to make an item inactive (greyed out), unavailable and choose different labels depending on conditionals. For example: AddToMenu WindowMenu + Inactive(!Maximized, !Iconified) Restore RestoreFunc ... + Skip(FixedSize) Size Resize ... + If(Sticky) Unstick Stick off Else Stick Stick on Suggestions are ofcourse welcome. I plan to use the code as the other conditional statements. And also I plan to add conditionals for all function hints (I implemented conditionals FixedSize and HasHandles). This would also involve new styles FixedPostion, Uniconifiable and so forth. Yes I know, many people hate when these hints are used. But after all these are styles so it means freedom for the user... You may read some discussions about a new menu syntax here: http://www.hpc.uh.edu/fvwm/archive/0203/msg00508.html As for your examples, I suggest to use only the conditions we have now in ThisWindow, i.e. (!Focused, !Maximized, !Iconic), not Inactive(...). Well, I inteded Inactive to describe the meu item (ie. shaded out) //Marcus Regards, Mikhael. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: things to be done for 2.6
On Sun, 8 Dec 2002, Dan Espen wrote: [EMAIL PROTECTED] writes: Here is a list of things that I think have to be done before 2.6 that you may not be aware of. I write them here specfically because I will most likely do none of them. My reasoning is: nobody is maintaining these features or taking care of them, and 2.6 is meant to be a *stable* release. But of course you can do what you want with them - it's all code under GPL. * Remove tear off menus. Either that or finish the menu rewrite (to allow full operation without grabbing pointer or keyboard from within menus). There is still some unfinished code in menus.c. I'd hate to see tear off menus go away. I use them and they seem to be problem free. Actually one problem is that new windows appear only after leaving the menu. If a menu item causes a new window to popup. I haven't looked any at the menu code, but I guess the event loop for menus don't check for this. With normal menus this is probably not a problem since the menu gets unposted at the time of the click //Marcus Just as important, tear off menus are one of the comparison points on the window managers page. Its an important feature from a visibility point of view. If they are causing a problem, I don't see it. In this case, I think you are setting your standards too high. -- Dan Espen E-mail: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Patch for conditionals
I added conditions FixedSize (matches unresizable windows) and HasHandles (matches windows without resize-handles). Now when I created the diff it also included changes I did to the IconBox that hasn't been checked in. Is there a way to create a diff with just the new changes? Would I need to remove the affected files from FvwmIconBox and cvs update and then do a diff and after that reapply my old patch? Seems a bit teedious. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Condition IsFixedSize
I added a field in window_flags in fvwm.h and parsing conditional.c But where do I do the checking against an actual window? The function MatchesConditionMask in conditional.c only checks few cases and always returns False for iconified windows. I can't find the place to evaluate the conditional. I tried to grep for flags.is_iconified (for example) and it only shows up add_window.c, events.c, and window_flags.h //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Condition IsFixedSize
On Tue, 3 Dec 2002, Marcus Lundblad wrote: I added a field in window_flags in fvwm.h and parsing conditional.c But where do I do the checking against an actual window? The function MatchesConditionMask in conditional.c only checks few cases and always returns False for iconified windows. OK, it ands iconified, transient and iconified by parent, not or:ing... ok, I missunderstood this part. But still I'm not sure where to do the check. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Condition IsFixedSize
On Tue, 3 Dec 2002 [EMAIL PROTECTED] wrote: On Tue, Dec 03, 2002 at 11:01:23PM +0100, Marcus Lundblad wrote: On Tue, 3 Dec 2002, Marcus Lundblad wrote: I added a field in window_flags in fvwm.h and parsing conditional.c But where do I do the checking against an actual window? The function MatchesConditionMask in conditional.c only checks few cases and always returns False for iconified windows. OK, it ands iconified, transient and iconified by parent, not or:ing... ok, I missunderstood this part. But still I'm not sure where to do the check. You do not need an additional flag - the code is already there. Call the is_function_allowed() function from decorations.c. But wouldn't I still have to in code that parses the condition string in CreateConditionMask and patch MatchesConditionMask to check is_function_allowed for the current window and resize? //Marcus Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Conditionals
I was was thinking about some new conditional operators (the same type like Current (sticky) ... I would like to be able to see if a window is resizable and minimisable, for example, to be able to define different menus for the window menu (for example) depending on what operations are available. Is this possible currently (except specifying for know windowclasses)? I guess if this is to be implemented, it's part of the conditional rewrite someone talkt about for 3.0 //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
New patch for FvwmIconBox
I added 2 more options: *FvwmIconBox: NormalTitleInvertedRelief *FvwmIconBox: IconifiedTitleInvertedRelief to get inverted, pressed in looking title reliefs. //Marcus FvwmIconBox.diff.gz Description: Binary data
Re: FvwmIconBox patch
Note that I am not against inverted reliefs in general, but only against the syntax using cryptic negative values for them. A separate option for reverted is fine with me. Fvwm already uses: raised/sunk/flat What would flat do? //Marcus since this controls width, its a bit like borderwidth. Maybe *FvwmIconBox: IconifiedTitleBorder flat|raised|sunk *FvwmIconBox: IconifiedTitleBorderWidth num -- Dan Espen E-mail: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FvwmIconBox patch
On Sat, 30 Nov 2002, Dan Espen wrote: Marcus Lundblad [EMAIL PROTECTED] writes: Note that I am not against inverted reliefs in general, but only against the syntax using cryptic negative values for them. A separate option for reverted is fine with me. Fvwm already uses: raised/sunk/flat What would flat do? There would be no 3d effect at all, just a border. I implemented relief widths so that the title is padded out to the maximum size of the reliefs for iconified and non iconified windows. So I think it would be a bit confusing to have flat as an option. Say I define: FvwmIconBox: NormalTitleRelief 0 FvwmIconBox: IconifiedTitleRelief 2 then this would be equivalent to setting a flat border of 2 pixels for uniconified windows. I think I would prefer options: FvwmIconBox: NormalTitleInvertedRelief FvwmIconBox: IconifiedTitleInvertedRelief //Marcus -- Dan Espen E-mail: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FvwmIconBox patch
I made a patch that adds the following options to FvwmIconBox.
*FvwmIconBox: NoIconifiedParenthese
Turns off the parenthesis around the titles of iconified windows.
*FvwmIconBox: NormalTitleRelief num
Sets the width of the relief for the title of uniconified windows (0 no
relief).
*FvwmIconBox: IconifiedTitleRelief num
Same for iconified windows.
I didn't implement inverted reliefs (as someone suggested), I could add
this also, if it's considered a useful feature.
//Marcus
? IconBox.diff
Index: ChangeLog
===
RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v
retrieving revision 1.2161
diff -u -u -r1.2161 ChangeLog
--- ChangeLog 2002/11/26 13:56:45 1.2161
+++ ChangeLog 2002/11/26 22:09:13
@@ -1,3 +1,14 @@
+2002-11-26 Marcus Lundblad [EMAIL PROTECTED]
+ * modules/FvwmIconBox/FvwmIconBox.c (RedrawIcon, CreateWindow,
+ParseOptions):
+ * modules/FvwmIconBox/icons.c (AdjustIconWindow):
+ impemented options for turning off parenthesisation of iconified
+ window title
+
+ * modules/FvwmIconBox/FvwmIconBox.1:
+ documented options for turning off parenthesisation of iconified
+ window title
+
2002-11-26 Mikhael Goikhman [EMAIL PROTECTED]
* fvwm/fvwm.c (InitVariables):
Index: modules/FvwmIconBox/FvwmIconBox.1
===
RCS file: /home/cvs/fvwm/fvwm/modules/FvwmIconBox/FvwmIconBox.1,v
retrieving revision 1.15
diff -u -u -r1.15 FvwmIconBox.1
--- modules/FvwmIconBox/FvwmIconBox.1 2002/04/25 16:34:29 1.15
+++ modules/FvwmIconBox/FvwmIconBox.1 2002/11/26 22:09:16
@@ -243,6 +243,20 @@
is *FvwmIconBox: NoIconAction SendToModule FvwmAnimate animate. A blank or
null
action turns this feature off.
+.IP *FvwmIconBox: NoIconifiedParentheses
+Tells FvwmIconBox to not enclose the title of an iconified window within
+parantheses.
+
+.IP *FvwmIconBox: NormalTitleRelief \fInum\fP
+Sets the width in pixels of the relief that is put around icon titles for
+windows that are not iconified. The default if this option is not specified is
+2 pixels.
+
+.IP *FvwmIconBox: IconifiedTitleRelief \fInum\fP
+Sets the width in pixels of the relief that is put around icon titles for
+windows that are iconified. The default if this option is not specified is
+2 pixels.
+
.SH SAMPLE CONFIGURATION
The following are excepts from a .fvwm2rc file which describe
FvwmIconBox initialization commands:
Index: modules/FvwmIconBox/FvwmIconBox.c
===
RCS file: /home/cvs/fvwm/fvwm/modules/FvwmIconBox/FvwmIconBox.c,v
retrieving revision 1.90
diff -u -u -r1.90 FvwmIconBox.c
--- modules/FvwmIconBox/FvwmIconBox.c 2002/11/13 22:37:43 1.90
+++ modules/FvwmIconBox/FvwmIconBox.c 2002/11/26 22:09:23
@@ -68,7 +68,6 @@
#include FvwmIconBox.h
-
char *MyName;
Display *dpy; /* which display are we talking to */
@@ -153,6 +152,12 @@
int margin1 = 8;
int margin2 = 6;
+/* true if iconified windows doesn't have () around the title */
+Bool iconified_has_normal_title = False;
+
+int normal_title_relief = 2;
+int iconified_title_relief = 2;
+
Pixmap IconwinPixmap = None;
char *IconwinPixmapFile = NULL;
@@ -760,6 +765,7 @@
{
int hr, len;
int diff, lm ,w, h, tw;
+ int title_relief;
char label[256];
int cs;
XRectangle inter;
@@ -885,17 +891,16 @@
{
if (item-icon_w 0 item-icon_h 0)
RelieveRectangle(dpy, item-icon_pixmap_w,
-0, 0, item-icon_w
-+icon_relief - 1,
+0, 0,
+item-icon_w + icon_relief - 1,
item-icon_h + icon_relief - 1,
IconReliefGC,
IconShadowGC, 2);
else
RelieveRectangle(dpy, item-icon_pixmap_w,
-0, 0, max_icon_width
-+ icon_relief - 1,
-max_icon_height +
-icon_relief - 1,
+0, 0,
+max_icon_width + icon_relief -
1,
+max_icon_height + icon_relief
- 1,
IconReliefGC,
IconShadowGC, 2);
}
@@ -909,12 +914,23
Re: Restarting from non desk 0 is broken
On Thu, 28 Nov 2002, Mikhael Goikhman wrote: For several days now I see this nasty problem. I have a lot of windows on 4 desks and 2x2 pages. I restart from non desk 0, say desk 1, and undecorated windows from the same page and any desk appear on the visual page during Restart, then fvwm changes desk and only the windows that were initially on that desk (and page) are reparented. Other windows (from desk 0 at least) stay as unmanaged on top of all managed ones. This is solved by doing Restart from desk 0. But then the previously unmanaged windows end up on Page 0 0 or in some invisible place. Can someone reproduce this or should I give more specific instructions? Yes, this happens for me too... //Marcus Regards, Mikhael. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Mail dissapeared
I sent a patch to the mailing list yesterday, but it seems to not have come through, did it got trapped in the spam filter? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FvwmIconBox patch
I made a patch that adds the following options to FvwmIconBox. *FvwmIconBox: NoIconifiedParenthese Turns off the parenthesis around the titles of iconified windows. *FvwmIconBox: NormalTitleRelief num Sets the width of the relief for the title of uniconified windows (0 no relief). *FvwmIconBox: IconifiedTitleRelief num Same for iconified windows. I didn't implement inverted reliefs (as someone suggested), I could add this also, if it's considered a useful feature. PS: The first time I sent this it didn't get to the list. Then I gzipped the patch. was it trapped in the spam-filter? //Marcus IconBox.diff.gz Description: Binary data
Naming of fvwm2rc inside directory .fvwm
I have a suggestion. When placing the file .fvwm2rc inside the directory .fvwm, I think it would seem more natural to allow the name fvwm2rc or fvwmrc (without . ), since this is inside a hidden directory. //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: IconBox options naming
On Mon, 18 Nov 2002, Mikhael Goikhman wrote: On 18 Nov 2002 22:36:57 +0100, Marcus Lundblad wrote: I'm implementing a few new options for the FvwmIconBox to allow to decide if iconified/uniconified window's labels are drawn with or without a relief and an option to disabled ( and ) around the titles of iconified windows. I need some feedback on names: IconifiedHasLabelRelief takes an argument with a value of True or False to enable/disable the drawing of reliefs for iconified windows. UnIconifiedHasLabelRelief the same for uniconified windows You may already do this if you define colorsets for iconified and normal windows with hi=sh=bg. If you still insist on having these options, I would do it similarly to: NormalTitleRelief width IconifiedTitleRelief width where 0 means no relief, positive means raised, negative means lowered relief of that width. Yes, that seems like a good idea. and IconifiedHasNormalTitle disables () around title for an iconified window. Maybe this should also have a boolean argument? NoIconifiedParentheses? Yes, good suggestion. Thanks! I also had some plans to enable reliefs for the icons themselfs also. And then adding window frames (like mwm). I think this will require adding some more coloursets (maybe allow different coloursets for label and icon background, so that you can have only the lables highlighting for example. And maybe 2 colursets for the window frame, this should probably use the same colourset as normal windows per default...) And I also looked at doing this for the ordinary icons. I need to figure out how to draw into the background of the icon window, they seem to use private visuals, I need to study up on this... //Marcus Regards, Mikhael. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
IconBox options naming
I'm implementing a few new options for the FvwmIconBox to allow to decide if iconified/uniconified window's labels are drawn with or without a relief and an option to disabled ( and ) around the titles of iconified windows. I need some feedback on names: IconifiedHasLabelRelief takes an argument with a value of True or False to enable/disable the drawing of reliefs for iconified windows. UnIconifiedHasLabelRelief the same for uniconified windows and IconifiedHasNormalTitle disables () around title for an iconified window. Maybe this should also have a boolean argument? //Marcus -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
