Re: CVS domivogt: * Removed flash when maximizing rxvt windows.
On Tue, Mar 19, 2002 at 11:30:53AM -0500, Dan Espen wrote: > FVWM CVS writes: > > CVSROOT:/home/cvs/fvwm > > Module name:fvwm > > Changes by: domivogt02/03/19 10:17:36 > > > > Modified files: > > . : ChangeLog > > fvwm : frame.c > > > > Log message: > > * Removed flash when maximizing rxvt windows. > > I still see it. > I use the keyboard to maximize. > My rxvt windows have a background pixmap. On the way to my dancing training I came up with the idea why it flashes and a way to get rid of it once and for all. THe problem: With window gravities, you can tell X to automatically move child windows, but you can not tell it to resize them. Since the client window is a sub sub window of the frame, you can not resize or move it to its final position in the same operation as the parent and the frame. At the moment, when a window is maximized, the client is resized first (this generates a ConfigureNotify which may cause the client to redraw). Then the parent is resized, then the frame. Since fvwm and the client send their commands asynchronously to the server, the parent's or frame's background may become visible for a split second before the client gets Expose events and covers it. Because of the three tiers in the window hierarchy, it's impossible to prevent this effect completely. What happens is that some areas of the frame may get redrawn multiple times. This is not only visually disturbing but also slow. Here is the good news: it *is* possible to suppress all the superflous redraws. Set the background pixmap of the parent and the frame to 'None', resize them before resizing the client and then resize the client. Because of the undefined background, the X server simply keeps the contents of the now exposed areas. Let's try... Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Opinions on new frame layout code?
On Tue, Mar 19, 2002 at 03:26:24PM +, Tim Phipps wrote: > fvwm-workers@fvwm.org wrote: > > On Tue, Mar 19, 2002 at 09:47:56AM +, Tim Phipps wrote: > >>The -visual option for fvwm2 now doesn't work, well it works but the > >>borders, buttons and titles are left empty. > >> > > > > I have no way to test this. My display supports only TrueColor > > and DirectColor, and both work fine. Anyway, I forgot to change > > the depth and visual attributes when I removed the decor_w. That > > is probably the cause. Does it work with current CVS? > > > > Nearly, you have to specify a colormap and a border pixel when creating > non-root visual windows, and the gcs used to fill the borders have to be > created from an fvwm visual window. I've attached a patch from todays > snapshot but it may be out of date already. Ah yes, understood. The fix will be in my next commit. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Patch to prevent spurious M_NEW_PAGE being broadcast
On Mon, Mar 18, 2002 at 11:17:30AM +, Tim Phipps wrote: > [EMAIL PROTECTED] wrote: > >>I think it's the PipeRead but I'm not sure, anyway a sensible fix is to > >>not send an M_NEW_PAGE if the page hasn't changed and the attached patch > >>is very simple. Is there any reason to send M_NEW_PAGE when the page > >>doesn't change? > >> > > > > Yes. It's necessary to force a M_NEW_PAGE packet when the desk > > changes but the viewport does not move. Some of the modules need > > the message in this case. I can't remember which modules. > > I had a trawl through the recent module code and found the following > uses of M_NEW_PAGE and M_NEW_DESK: Okay. I think FvwmIconMan and/or FvwmPager were the culprits, but I seem to have fixed there problems already. I'll apply the patch. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: CVS domivogt: * Removed flash when maximizing rxvt windows.
On Tue, Mar 19, 2002 at 10:02:46PM +0100, Dominik Vogt wrote: > On Tue, Mar 19, 2002 at 11:30:53AM -0500, Dan Espen wrote: > > FVWM CVS writes: > > > CVSROOT: /home/cvs/fvwm > > > Module name: fvwm > > > Changes by: domivogt02/03/19 10:17:36 > > > > > > Modified files: > > > . : ChangeLog > > > fvwm : frame.c > > > > > > Log message: > > > * Removed flash when maximizing rxvt windows. > > > > I still see it. > > I use the keyboard to maximize. > > My rxvt windows have a background pixmap. > > On the way to my dancing training I came up with the idea why it > flashes and a way to get rid of it once and for all. [snip] Unfortunately, nothing of this is reliable. The is no way to prevent the flash in all cases. I believe, what you see is the background of the rxvt window right before it can resize its text window and the scrollbar. I can't think of any way to prevent this in fvwm. rxvt should set the bg pixmap to its top level window, but that isn't a solution. Since X doesn't support "recursive resizing", it can't be done. At least: I compared the current fvwm code with what about ten other WMs do (E, Afterstep, Blackbox, MWM, olvwm, kwin, ...) and none of them comes close to fvwm. They all flash and flicker like hell. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Opinions on new frame layout code?
On Sun, Mar 17, 2002 at 10:49:01PM +0100, Dominik Vogt wrote: > Apart from the apparent bugs (windowshade doesn't do anything, > the border layout of small windows is screwed, window corners > sometimes flash above the parent during opaque resizing), what do > you think about the now code (mostly in terms of speed, but feel > free to comment on other aspects too)? > > I'm not sure because my machine is so fast, but I think opaque > moving and resizing is already a lot faster. When the bugs in the > border layout are fixed, I'll switch to using background pixmaps > in the title bar too and then take a look at window shading. So, with my last commit, title buttons are drawn as smoothly as the borders. That part of the code isn't finished yet. Some features of the ButtonStyle are unavailable and the title window is blank, but it gives a good impression of the speed and smoothness with opaque resizing. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: vector buttons
On Wed, Mar 20, 2002 at 08:49:18PM +0100, Johannes Gajdosik wrote:
> Dear fvwm developers,
>
> I am using fvwm2 since a couple of months and I am very pleased with it.
> I liked the vector buttons very much and I was a little sad
> because a vector button can only have 31 lines and because
> these lines must always be connected to one another.
> Therefore I would like to propose a new fwwm-feature.
>
> This is the first open source project that I want to contribute,
> so please be patient with me.
> It would be a great honor if this feature could be introduced
> in one of the next versions.
> I am using it in version 2.4.6 and it works fine.
Well, I see no real reason why the number of lines is hard coded
to a maximum of 32. It can easily be changed. I have comitted a
patch to the development branch.
If you want to submit fvwm patches, please make sure you base them
on the latest development code or at least the latest snapshot.
Also, please use the diff program to generate patches that can be
applied with the "patch" program. Just copy all the files to a
file named old_name.orig:
$ cp borders.c borders.c.orig
Make your modifications and the run diff:
$ diff -u borders.c.orig borders.c
(or if your diff doesn't support the -u option, use -c instead).
We always appreciate optimizing the code. On the other hand, the
new feature can be implemented with a very small change. All you
have to do is skip the drawing command when a certain colour is
used. I have applied a patch that uses colour 4 for this feature.
If you want help cleaning this ugly mess up a bit, please download
the latest snapshot or code from cvs first and redo your changes.
I am currently busy with exactly the files you modified too, so it
can become a bit difficult to keep the patches up to date.
Finally, if you do download the development code, don't expect
much of it. It needs another week before window titles and window
shading work well again.
To comment on your code:
> --
>
> Feature description:
>
> the man-page says:
>
> > ...,num is a number of
> > point specifications of the form [EMAIL PROTECTED]
> > ... C specifies a line color
> > (0 - the shadow color, 1 - the highlight color, 2 -
> > the background color, 3 - the foreground color).
> > ... You can use up to 32 points in a line pattern.
>
> The new feature is:
> 1) You can use up to 1000 (or more?) points in a line pattern.
> 2) special color C=-1: no line is drawn.
> This is different from color C=2, because a line of color C=2
> makes that all pixels of this line get the background color
> and so are erased.
>
> The implementation affects 5 files.
>
> -
>
> 1) the man page:
> The new text should be:
> ... C specifies a line color
> (0 - the shadow color, 1 - the highlight color,
> 2 - the background color, 3 - the foreground color,
> -1 - special meaning: this line is not drawn).
> ... You can use up to 1000 points in a line pattern.
>
> --
>
> 2) screen.h
> Instead of
>
> >struct vector_coords
> >{
> > int num;
> > int *x;
> > int *y;
> > unsigned long line_style;
> > unsigned long use_fgbg;
> >} vector;
>
> I propose
>
> struct vector_coords
> {
>int num;
>struct vector_vertex {
> unsigned char x;
> unsigned char y;
> unsigned short color;
>} *vertices;
>unsigned long use_fgbg;
> } vector;
>
> Please observe that in the old code every point needs 8 bytes,
> in the new code only 4 bytes. Furthermore the color is not any more
> stored
> in the bits of two unsigned long variables(line_style,use_fgbg),
> but instead in just on variable(color), so the code becomes more
> readable.
Yes, very good work. I hope I didn't discourage you from
contributing that work is definitely helpful.
> The variable use_fgbg remains just because of an optimization when
> drawing the button.
Ah, forget it. A few extra CPU cycles are not worth the effort.
DrawLinePattern() can calculate what it needs to know when it's
called.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
rounding the window size
Tim, can you remember the logic behind rounding the window size up or down? Shouldn't it always be rounded down except for interactive resizing? Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: New proposed menu syntax
On Thu, Mar 21, 2002 at 12:47:11AM -0500, Daniel Henninger wrote: > Alrighty, so... I haven't heard any objections to this particular style, > and I like it. Shall I start working on doing it this way? Can we please wait another week before starting this? I know you're eager to begin the work, but I'm too busy to give that topic enough thoughts to come to a decision. It's a very difficult matter and we may very well regret some of the decisions if made hastily. Well, you could definitely start isolating parts of the current AddToMenu() function that may be called individually by the new function. If you do, please keep the old code as it is and write completely independent functions for the new syntax. Oh - and I'd like to splite all the menu code into smaller functions with fewer levels of indentation. So it is a good idea to write many small functions instead of the monolithic behemoths we have now. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Enh request: Silent something for non-existant something
On Thu, Mar 21, 2002 at 04:20:15PM +, Tim Phipps wrote:
> Configuration Information [Automatically generated, do not change]:
> uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10
> compiler flags: gcc -g -O2 -Wall -Wno-implicit-int
>
> FVWM Version: 2.5.1
> FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1
> FVWM_DATADIR: /u/phippst/sunos/share/fvwm
> FVWM_USERDIR: /u/phippst/.fvwm
>
> Description:
> FvwmCommand pants:
> [FVWM][execute_function]: <> No such command 'pants'
> FvwmCommand "Silent pants":
> [FVWM][execute_function]: <> No such command 'pants'
>
> It would be nice if the second one was quiet.
Ah, do you have a use for this in mind? Why would a user want to
not be informed about syntax errors in his commands?
> Index: fvwm/functions.c
> ===
> RCS file: /u/phippst/share/cvsroot/fvwm/fvwm/functions.c,v
> retrieving revision 1.26
> diff -u -r1.26 functions.c
> --- fvwm/functions.c2002/03/18 12:47:11 1.26
> +++ fvwm/functions.c2002/03/21 16:07:50
> @@ -1414,7 +1414,7 @@
> {
>if (executeModuleDesperate(
> efa->cond_rc, efa->eventp, w, efa->fw, efa->context, runaction,
> - &efa->module) == -1 && *function != 0)
> + &efa->module) == -1 && *function != 0 && !set_silent)
>{
> fvwm_msg(
> ERR, "execute_function", "No such command '%s'", function);
> Index: fvwm/fvwm2.1
> ===
> RCS file: /u/phippst/share/cvsroot/fvwm/fvwm/fvwm2.1,v
> retrieving revision 1.62
> diff -u -r1.62 fvwm2.1
> --- fvwm/fvwm2.12002/03/21 12:35:02 1.62
> +++ fvwm/fvwm2.12002/03/21 16:13:47
> @@ -7900,6 +7900,9 @@
> .BR Key ", " PointerKey " and " Mouse ,
> this disables error messages.
>
> +.B Silent
> +also disables the error message for non-existant commands.
> +
> Examples:
> .EX
> Silent Move 0 0
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
fribidi compile errors
With fresh sources right from CVS and fribidi 0.9.0 I get: ... gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/usr/X11R6/include-g -Wall -Werror -O2 -c FBidi.c In file included from /usr/include/fribidi/fribidi.h:27, from FBidi.c:27: /usr/include/fribidi/fribidi_types.h:32: parse error before `FriBidiChar' cc1: warnings being treated as errors /usr/include/fribidi/fribidi_types.h:32: warning: data definition has no type or storage class /usr/include/fribidi/fribidi_types.h:34: parse error before `FriBidiStrIndex' /usr/include/fribidi/fribidi_types.h:34: warning: data definition has no type or storage class /usr/include/fribidi/fribidi_types.h:226: parse error before `fribidi_char_from_type' /usr/include/fribidi/fribidi_types.h:226: warning: data definition has no type or storage class /usr/include/fribidi/fribidi_types.h:228: parse error before `*' /usr/include/fribidi/fribidi_types.h:228: warning: data definition has no type or storage class In file included from /usr/include/fribidi/fribidi_char_sets.h:28, from /usr/include/fribidi/fribidi.h:28, from FBidi.c:27: /usr/include/fribidi/fribidi_char_sets_cap_rtl.h:30: parse error before `*' /usr/include/fribidi/fribidi_char_sets_cap_rtl.h:30: warning: data definition has no type or storage class /usr/include/fribidi/fribidi_char_sets_cap_rtl.h:31: parse error before `fribidi_char_set_enter_cap_rtl' /usr/include/fribidi/fribidi_char_sets_cap_rtl.h:31: warning: data definition has no type or storage class /usr/include/fribidi/fribidi_char_sets_cap_rtl.h:32: parse error before `fribidi_char_set_leave_cap_rtl' /usr/include/fribidi/fribidi_char_sets_cap_rtl.h:32: warning: data definition has no type or storage class /usr/include/fribidi/fribidi_char_sets_cap_rtl.h:34: parse error before `fribidi_cap_rtl_to_unicode_c' /usr/include/fribidi/fribidi_char_sets_cap_rtl.h:34: parse error before `ch' ... Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: CVS domivogt: * Mostly finished title bar drawing code. Please report any anomalies.
On Sat, Mar 23, 2002 at 07:21:05AM +0100, Olivier Chapuis wrote: > On Fri, Mar 22, 2002 at 07:18:16PM -0600, FVWM CVS wrote: > > CVSROOT:/home/cvs/fvwm > > Module name:fvwm > > Changes by: domivogt02/03/22 19:18:15 > > > > Modified files: > > . : ChangeLog > > fvwm : add_window.c borders.c events.c ewmh_icons.c > > frame.c fvwm.c fvwm.h fvwm2.1 menus.c misc.c > > move_resize.c screen.h > > libs : Graphics.c > > > > Log message: > > * Mostly finished title bar drawing code. Please report any anomalies. > > * Numerous bug fixes. > > > > The result is really impressive. > Fortunately :o) I can see a few problems. The problems concern > window buttons. I should mention that I did not test much of the code that uses pixmap backgrounds, "fancy titlebars", gradient titles etc. > - With Vector buttons sometimes (after a fvwm-themes switching > between themes with vector buttons, e.g., luthien <-> default > [basic look]) the right button disapear. Recapture fix this. Can you give instructions to reproduce that without fvwm-theme? > - With Pixmap buttons the buttons are totally screwed. Recapture > fix nothing. Fixed. > - During playing with fvwm-themes theme switching I get some: > > [FVWM][FvwmErrorHandler]: <> *** internal error *** > [FVWM][FvwmErrorHandler]: <> Request 56, Error 4, EventType: 0 > > (X_ChangeGC = 56, BadPixmap = 4) Fixed. > - It seems that "background" buttons colors is ok only with > "UseTitleStyle". Doy you have an example? For my setup the color is correct. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Focus and override redirect window
On Mon, May 07, 2001 at 11:37:09AM +0200, Olivier Chapuis wrote: > Hello, > I do not know if we have to take care of that now. > Moreover, this problem is maybe a bug of the applications > and not a FVWM bug (I do not know). > Here the problem. > Say that we have a NeverFocus window A and a window B with the > focus (say SloppyFocus and ClickToFocusClickRaise). > Now if I pop up (and pop down) a menu of the window A (override redirect), > then some times: >(i) window B lost the keyboard input (always happen if A is a qt app) Fixed. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Demo of new windowshade features
Here is a little script that demonstrates what the new window shading code can do (ignore the border drawing problem, I'll fix that). If your machine is too fast or too slow, change the number behind windowshadesteps. --- snip style * windowshadesteps 200 style * windowshadeshrinks AddToFunc WindowShadeDemo + i windowshade n + i windowshade e + i windowshade s + i windowshade w + i windowshade ne + i windowshade sw + i windowshade se + i windowshade nw + i windowshade n + i windowshade ne + i windowshade e + i windowshade se + i windowshade s + i windowshade sw + i windowshade w + i windowshade off function WindowShadeDemo --- snip Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Demo of new windowshade features
On Sat, Mar 23, 2002 at 09:55:27PM -0500, Dan Espen wrote: > Dominik Vogt <[EMAIL PROTECTED]> writes: > > Here is a little script that demonstrates what the new window > > shading code can do (ignore the border drawing problem, I'll > > fix that). If your machine is too fast or too slow, change the > > number behind windowshadesteps. > > Wow! That is really cool. Yup, I could watch it for hours. And with a well written application you don't even see the redraws. Now, how about this function: exec xterm -T "kill me!" -e sleep 100 wait foobar AddToFunc my_destroy_window + i windowshade n + i windowshade nw + i destroy my_destroy_window Shading a window to the center would be nice also :) Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: CVS domivogt: * Fixed several layout and icon bugs et. al.
On Sun, Mar 24, 2002 at 07:09:09AM -0500, Dan Espen wrote: > FVWM CVS writes: > > CVSROOT:/home/cvs/fvwm > > Module name:fvwm > > Changes by: domivogt02/03/24 04:18:18 > > > > Modified files: > > . : ChangeLog > > fvwm : borders.c borders.h events.c ewmh_icons.c > > frame.c frame.h misc.c misc.h move_resize.c > > update.c > > libs : fvwmrect.c fvwmrect.h gravity.c > > > > Log message: > > * Fixed several layout and icon bugs et. al. > > Resizing a window causes a crash. I'll see if I can get a stack dump. Fixed. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
removed some styles (...CounterClockWise) et.al.
I have removed the styles (Left|Right)TitlesRotated[Counter]ClockWise Title(Left|Right) instead, the abbreviations (Left|Right)TitlesRotated[C]CW and the "at" versions TitleAt(Left|Right) must be used. I think all these different spellings were not worth the effort. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: new decoration code
On Sun, Mar 24, 2002 at 05:19:01PM +, Mikhael Goikhman wrote: > A few problems. > > When window is deiconified the decorations are not focused. Fixed. Now that the code makes proper checks which parts have to be drawn, many old 'bugs' surface. The code worked only by trial and error and was doomed to break when other things were changed. > Style NoButton n seems to work ok, but Button n requires Recapture. Fixed. The button window was not mapped. > Menu hints from window buttons and border work now, but not from title. > I.e. invoke a menu by clicking on a title. Fixed, but it works slightly different now. The menu can now use the full width of the window. > Some decorations look very strange with side titles. :) But maybe it's ok. > Ideally everything should be rotated in one or another direction, the same > setting as for title text may be used: pixmaps, button vectors, gradients. I'm reluctant to do this. We'd have to rotate the same pixmaps again and again when it would be so much easier to rotate them externally. > I did not test MultiPixmap titlebars yet. I never once took a look at that feature, so expect it to be badly broken. I had to do some changes that modify the semantics of some parts. > I am very pleased to see that there is no any flickering in decorations > and a title text whatever you do with windows. Even with pixmap titles. > Move/Resize/WindowShade are just perfect. Something I only dreamed about. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: CVS domivogt: * Mostly finished title bar drawing code. Please report any anomalies.
On Sat, Mar 23, 2002 at 01:02:22PM +0100, Dominik Vogt wrote: > On Sat, Mar 23, 2002 at 07:21:05AM +0100, Olivier Chapuis wrote: > > On Fri, Mar 22, 2002 at 07:18:16PM -0600, FVWM CVS wrote: > > > CVSROOT: /home/cvs/fvwm > > > Module name: fvwm > > > Changes by: domivogt02/03/22 19:18:15 > > > > > > Modified files: > > > . : ChangeLog > > > fvwm : add_window.c borders.c events.c ewmh_icons.c > > >frame.c fvwm.c fvwm.h fvwm2.1 menus.c misc.c > > >move_resize.c screen.h > > > libs : Graphics.c > > > > > > Log message: > > > * Mostly finished title bar drawing code. Please report any anomalies. > > > * Numerous bug fixes. > > > > > > > The result is really impressive. > > Fortunately :o) I can see a few problems. The problems concern > > window buttons. > > I should mention that I did not test much of the code that uses > pixmap backgrounds, "fancy titlebars", gradient titles etc. > > > - With Vector buttons sometimes (after a fvwm-themes switching > > between themes with vector buttons, e.g., luthien <-> default > > [basic look]) the right button disapear. Recapture fix this. > > Can you give instructions to reproduce that without fvwm-theme? Fixed. > > - It seems that "background" buttons colors is ok only with > > "UseTitleStyle". > > Doy you have an example? For my setup the color is correct. Still need the instructions. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
fribidi compile problem persists
The fribidi compile problem is still there, although the errors are different. I did a clean check out, ran configure from scratch and it still detects fribidi-0.9. --- snip - gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/usr/X11R6/include -I/usr/include/glib-1.2 -I/usr/lib/glib/include-g -Wall -Werror -O2 -c FBidi.c cc1: warnings being treated as errors FBidi.c: In function `FBidiIsApplicable': FBidi.c:32: warning: implicit declaration of function `fribidi_parse_charset' FBidi.c: In function `FBidiConvert': FBidi.c:66: warning: passing arg 3 of `fribidi_charset_to_unicode' makes pointer from integer without a cast FBidi.c:66: too many arguments to function `fribidi_charset_to_unicode' make[2]: *** [FBidi.o] Error 1 --- snip - Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
alloca question
I noticed this bit of code in DispatchEvent(), events.c: #ifdef C_ALLOCA /* If we're using the C version of alloca, see if anything needs to be * freed up. */ alloca(0); #endif Is is necessary or is that a relic of the time before our alloca replacement? Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: CVS domivogt: * Almost finished button drawing: memory leak
On Mon, Mar 25, 2002 at 10:43:03PM +0100, Johannes Gajdosik wrote: > > Log message: > > * Almost finished button drawing. > > * Fixed transparent vector lines. > > I have checked out your code from CVS > and you have implemented everything > I wanted to do with the vector buttons, although > in a differen way. Thank you! No problem. I had to change most of the code anyway because it was in my way with rewriting the window decoration code. > There also seems to be a new feature which > switches colors 0 and 1 when a vector is toggled. Nope, that's not new. > Nevertheless you seem to have forgotten to free > the array of the vector line colors in > FreeDecorFace (builtins.h, line 984). Thanks for the pointer. Will be fixed in a minute. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
fribidi detection - expected result?
With current cvs I get
With Bi-directional text support? no: Bad fribidi version, see config.log
Is that the expected result?
>From config.log:
- snip ---
configure:5956: checking for fribidi-config
configure:5973: found /usr/bin/fribidi-config
configure:5984: result: /usr/bin/fribidi-config
configure:5997: checking for fribidi_log2vis in -lfribidi
configure:6024: gcc -o conftest -g -O2 -Wall conftest.c -lfribidi -L/usr/lib
-lfribidi -lglib -I/usr/include/glib-1.2 -I/usr/lib/glib/include >&5
configure:6027: $? = 0
configure:6030: test -s conftest
configure:6033: $? = 0
configure:6044: result: yes
configure:6082: gcc -o conftest -g -O2 -Wall -I/usr/include/glib-1.2
-I/usr/lib/glib/include conftest.c -L/usr/lib -lfribidi -lglib >&5
configure: In function `main':
configure:6074: warning: implicit declaration of function
`fribidi_parse_charset'
configure:6075: warning: passing arg 3 of `fribidi_charset_to_unicode' makes
pointer from integer without a cast
configure:6075: too many arguments to function `fribidi_charset_to_unicode'
configure:6085: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 6066 "configure"
#include "confdefs.h"
#include
#include
int main()
{
FriBidiChar *logical_unicode_str =
(FriBidiChar *)malloc((4 + 1) * sizeof(FriBidiChar));
fribidi_charset_to_unicode(
fribidi_parse_charset("iso8859-8"), "test", 4,
logical_unicode_str);
return 0;
}
--------- snip ---
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, email: [EMAIL PROTECTED]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: CVS olicha: * Fixed compilation for system without XOpenOM in Xlib.h
On Wed, Mar 27, 2002 at 01:12:44AM -0600, fvwm-workers wrote: > CVSROOT: /home/cvs/fvwm > Module name: fvwm > Changes by: olicha 02/03/27 01:12:44 > > Modified files: > . : ChangeLog acconfig.h configure.in > fvwm : fvwm.c > libs : Ficonv.c FlocaleCharset.c > > Log message: > * Fixed compilation for system without XOpenOM in Xlib.h Hm, what's XOpenOM again? Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: core dumps
On Wed, Mar 27, 2002 at 08:00:04AM +0100, Olivier Chapuis wrote: > On Tue, Mar 26, 2002 at 09:21:06PM +, Mikhael Goikhman wrote: > > I get core dumps. The problem is that the stack trace is unusible. > > gdb complains about "DW_FORM_strp pointing outside of .debug_str section" > > and gives ??? in the stack. > > > > Maybe others may reproduce these core dumps and get a good stack. > > > > 1) Simply run kcalc shipped with kdeutils-2.2 -> core dump. > > I have all feature supports on (except for multibyte). > > > > So you compile fvwm with --disable-multibyte (it seems that > now multibyte is on by default). > > When I run kcalc I get the following core dump: > > [EMAIL PROTECTED] graphviz-1.7.15]$ gdb /opt/fvwm/bin/fvwm2 ~/core > GNU gdb 4.18 > Core was generated by `fvwm2 -f themes-rc'. > at misc.c:394 > #4 0x80725f9 in GetWindowSizeHints (tmp=0x818f9f0) at add_window.c:2655 Damn, that's because fvwm_msg is called with fvwm_msg(..., "...%s...", tmp->name); But tmp->name is a structure, not a string. gcc doesn't complain about that because it doesn't know that fvwm_msg uses printf syntax. I guess there are dozens of similar places in the code. Is there any way to inform gcc about the fvwm_msg syntax? Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: core dumps
On Wed, Mar 27, 2002 at 11:27:48AM +0100, fvwm-workers wrote: > On Wed, Mar 27, 2002 at 08:00:04AM +0100, Olivier Chapuis wrote: > > On Tue, Mar 26, 2002 at 09:21:06PM +, Mikhael Goikhman wrote: > > > I get core dumps. The problem is that the stack trace is unusible. > > > gdb complains about "DW_FORM_strp pointing outside of .debug_str section" > > > and gives ??? in the stack. > > > > > > Maybe others may reproduce these core dumps and get a good stack. > > > > > > 1) Simply run kcalc shipped with kdeutils-2.2 -> core dump. > > > I have all feature supports on (except for multibyte). > > > > > > > So you compile fvwm with --disable-multibyte (it seems that > > now multibyte is on by default). > > > > When I run kcalc I get the following core dump: > > > > [EMAIL PROTECTED] graphviz-1.7.15]$ gdb /opt/fvwm/bin/fvwm2 ~/core > > GNU gdb 4.18 > > Core was generated by `fvwm2 -f themes-rc'. > > at misc.c:394 > > #4 0x80725f9 in GetWindowSizeHints (tmp=0x818f9f0) at add_window.c:2655 > > Damn, that's because fvwm_msg is called with > > fvwm_msg(..., "...%s...", tmp->name); > > But tmp->name is a structure, not a string. gcc doesn't complain > about that because it doesn't know that fvwm_msg uses printf > syntax. I guess there are dozens of similar places in the code. > Is there any way to inform gcc about the fvwm_msg syntax? Ignore me. We already have this in the code - it had only to be enabled for fvwm_msg too. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: core dumps
On Tue, Mar 26, 2002 at 09:21:06PM +, Mikhael Goikhman wrote: > I get core dumps. The problem is that the stack trace is unusible. > gdb complains about "DW_FORM_strp pointing outside of .debug_str section" > and gives ??? in the stack. > > Maybe others may reproduce these core dumps and get a good stack. > > 1) Simply run kcalc shipped with kdeutils-2.2 -> core dump. > I have all feature supports on (except for multibyte). Fixed. BTW, kcalc requests a max_height of 0. Anybody cares to report this? Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: core dumps
On Wed, Mar 27, 2002 at 10:53:24AM +, Mikhael Goikhman wrote: > On 27 Mar 2002 08:00:04 +0100, Olivier Chapuis wrote: > > > > On Tue, Mar 26, 2002 at 09:21:06PM +, Mikhael Goikhman wrote: > > > > > > I have all feature supports on (except for multibyte). > > > > So you compile fvwm with --disable-multibyte (it seems that > > now multibyte is on by default). > > Actually, configure sets with_multibyte to "no", so it is reported as > missing in the listing and in fvwm-config, although MULTIBYTE is set. > Don't you get the same "no multibyte support"? I may fix this. You can't compile with --disable-multibyte anymore - it's unconditionally enableb. I didn't notice that it's reported as missing when I changed that. I'd like to remove that option completely in the near future. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: window not hilighted
On Thu, Mar 28, 2002 at 09:39:26AM +, Tim Phipps wrote: > Configuration Information [Automatically generated, do not change]: > uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 > compiler flags: gcc -g -O2 -Wall -Wno-implicit-int > > FVWM Version: 2.5.1 > FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 > FVWM_DATADIR: /u/phippst/sunos/share/fvwm > FVWM_USERDIR: /u/phippst/.fvwm > > Description: > The new window code sometimes does not hilight the focused window. > > Repeat-By: > > AddToFunc test > + I MoveToDesk 0 -1 > + I MoveTodesk 0 > Current test > > The focused window is moved to desk -1 and then back, the focus doesn't change > but the window borders are drawn as though it is unfocused. Fixed. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: window not hilighted
On Thu, Mar 28, 2002 at 09:39:26AM +, Tim Phipps wrote: > Configuration Information [Automatically generated, do not change]: > uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 > compiler flags: gcc -g -O2 -Wall -Wno-implicit-int > > FVWM Version: 2.5.1 > FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 > FVWM_DATADIR: /u/phippst/sunos/share/fvwm > FVWM_USERDIR: /u/phippst/.fvwm > > Description: > The new window code sometimes does not hilight the focused window. > > Repeat-By: > > AddToFunc test > + I MoveToDesk 0 -1 > + I MoveTodesk 0 > Current test > > The focused window is moved to desk -1 and then back, the focus doesn't change > but the window borders are drawn as though it is unfocused. There are - in my eyes - two bugs, possibly three. 1) The window border is not redrawn when the window is moved back to the current desk. Or maybe it is redrawn, but not correctly. 2) The window seems to be unhilighted when it's moved to a different desk. In fact, it should not be drawn at all since it's already unmapped. 3) Probably the reason for (1) and (2): Although the window is unmapped and moved to another desk, fvwm still thinks it holds the current desk's focus. This is why it receives focus when it's moved back to the current desk. In my eyes, this is a bug. The function above should remove focus from the window. Opinions? Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/863
On Sat, Mar 30, 2002 at 01:47:33PM -0600, fvwm-bug wrote: > FVWM Bug Tracking notification > > new message incoming/863 > > Full_Name: > Version: 2.4.2 > CVS_Date: > OS: Linux 2.4.8 > X_Server: XFree86 4.0 > Submission from: (NULL) (24.70.95.204) > > > Hello, > > There is a problem with fvwm2 displaying Java 1.3.1_02 Swing JFrame > windows > which are popped up from other JFrame windows. What fvwm2 often does with > these is it resizes them so that they are so small on the screen that the > user can hardly see them. Even when the user calls setSize(x, y) and > pack() > on the created JFrame fvwm2 often still does the resizing leading to 16x16 > windows or so. This happens roughly 60% of the time. This also happens > under the gnome window manager but never happens under window maker. > The code was compiled using Sun's JDK for Linux and other users > experienced the same problem with their own code. > > The other Java problem which has to do with window management is that > when setVisible(true) is called on the window often it appears as an > fvwm2 icon, which is not what is supposed to happen. When > setVisible(false) is called on a JDK JFrame the window is > supposed to disappear and when setVisible(true) is called > on that window later it is supposed to appear deiconified. If you provide *detailed* instructions on what you are doing, I can take a look at what happens. By detailed I mean: 1) A location with the Java package you are using (the exact version). If there is anything to take into account when installing it, please say so. 2) A piece of Java code that shows the problem. The code must run out of the box. 3) Any settings that have to be made to run that code. 4) Detailed instructions what to do with the program. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: libtoolization ?
On Fri, Mar 29, 2002 at 04:29:59PM +0100, Olivier Chapuis wrote: > Hello, > > At present time the fvwm lib is used in a totally static way. > Moreover, an external module should be compiled inside the fvwm > source tree to take advantage of the libs. > > One way to overcome these is to "libtoolize" fvwm by using the > libtool package (say version 1.4). These means that we have > two new configuration options --disable-shared and --disable-static > (or maybe better (reversed) default is --enable-shared and > --disable-static) > > - if shared is enabled (and the system support shared lib) fvwm > will build and install a sharable library libfvwm.so-version and > fvwm2 and the modules will be dynamically linked to this library. > Of course the system must be able to perform the dynamic link > (e.g., for Linux either updating /etc/ld.so.conf and run ldconfig > or adding the directory "lib" directory in LD_LIBRARY_PATH after > the install). > > - if static is enable a lib archive libfvwm.a (and libfvwm.la) > will be build and installed. Moreover, if shared is disabled > fvwm2 and the modules will be statically linked against the > lib (so we will build the same type of executable as now). > It seems that during alpha devel phase the default should > be: static enabled / shared disabled. > > - In "any" cases the fvwm libs headers will be installed > under includdir/fvwm/. Of course this is not needed for > running fvwm. Also if shared, libfvwm.a is not really needed > for running fvwm. So we may want to add a new config option > --disable-devel (or --enable-devel) that will cause fvwm to > install only what it is needed for running fvwm (maybe a bit > tricky). I see a number of reasons against a shared library: 1) It doesn't save a lot of memory. The whole library uses 17 bytes at the moment. A user who has to save memory would probably use no more than five different modules. Assuming that every module uses no more than 25% of the library, (s)he'd save only about 200k. The total size of all the .o files of the modules is 670k. The total size of the executables is 1725k, so you can probably not even save a megabyte if you run all 29 modules. All numbers calculated on an i386 CPU w/ Linux 2.4.something. 2) It makes fvwm a whole lot harder to maintain. Some users will have problems linking and installing. It is not trivial to get fvwm and the modules running against the correct library version. In addition, more configure options are added. I'd like to reduce the count of configure options that control some internal feature that does not require external libraries to zero (not counting debug options like xinerama emulation or efence). More options = more problems compiling/running fvwm. 3) Each library version is incompatible to all others. Due to the way the library is developed, the library has to be reinstalled every time we modify the code. The next refers only to the idea of exporting the library headers: 4) The library interface is in no shape to be exported. The library is just a pile of undesigned code. The library interface is going to be made "official" only over my dead body. Modules that use the library belong into the source tree. External modules are and should be limited to using the module interface. It is well documented and changes slowly. By no means are we prepared to maintaining a consistent feature set of the current library. > --- > executable size: > --- > static: (strip) | shared: (strip) > Modules: 9114k 1843k |5325k940k > fvwm2: 1576k 437k |1336k381k > libfvwm.so: 0k 0k | 426k426k > -- > Rtotal: 10690k 2280k | 7 087k 1747k > | (-3603k) (-533k) Ah, yes. So the we'd save about 500k *if* every single module is run on the system. Frankly, I think it's a waste of time to spend work on a shared library if the gain is so small. It seems you did not strib libfvwm.so. The libfvwm.a on my disk uses 170k. I can't imagine why a shared lib should be more than twice as large. > Test: Booting, start 5 fvwm "sessions" for each open a rxvt and send > the "free" output in a file. Then at the 5th session open top and > xemacs and cut and past the "fvwm" top info in xemacs. Um, what is the idea of running multiple sessions at the same time? Any decent OS should keep only one copy of the code in memory, regardless of how many times you run it. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: png loader
On Sat, Mar 30, 2002 at 03:11:56PM -0500, Suzanne Skinner wrote:
> > Hum, I do not promise alpha rendering (at least for the moment).
> > The first approach will map the alpha channel (which goes from 0 to 255)
> > to {0,1} something like: if alpha > 150 then render the point as is if
> > the alpha <= 150 put the point out of the mask.
>
> Well, given that foundation to work from, I may be able to hack alpha-blending
> myself :-)
>
> Either way, PNG support in Fvwm will be way cool.
Well, if you have time to spare you could take a look at the
FANCY_TITLE_BAR ifdefs. I didn't test that at all when I rewrote
the decoration layout code and it's very likely to be completely
broken now :-)
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: PositiveWrite problems
On Sat, Mar 30, 2002 at 12:20:15PM +, Mikhael Goikhman wrote: > I just enabled my FvwmEvent that listens to enter_window and leave_window, > similarly to what Dominik posted some time ago, and I see how to reproduce > the freeze for sure (just start the button bar that is auto raised/lowered > or shaded on enter/leave, then while it swallows xclock/xload, enter and > leave some window). I will debug this later. In this situation FvwmEvent > is killed after the freeze, not something that I experienced previously. > > It may be harder with FvwmEvent that listens to add_window, I still (for > months) can't find a way to reproduce the problem for sure and it was not > killed after the freeze for unknown reason. As I posted in the past, FvwmConsole and FvwmIconMan have similar problems. FvwmIconMan sometimes exits with the same message. FvwmConsole can be overrun by terminal input: paste long scripts into the FvwmConsole window fast and one of the pipes (either between FvwmConsole and FvwmConsoleC or between FvwmConsole and fvwm2, I don't know which) starts to lose some of the transmitted characters. This may or may not be related. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: png loader
On Sat, Mar 30, 2002 at 03:31:19PM +0100, Olivier Chapuis wrote: > On Sat, Mar 30, 2002 at 10:44:41AM +, Mikhael Goikhman wrote: > > On 30 Mar 2002 07:37:07 +0100, Olivier Chapuis wrote: > > > > > > I think it will be good that fvwm can load png images. The reason > > > is that png is a good format and that there is a lot of icons and > > > mini-icons in such format in the hd of a lot of machine (GNOME > > > and KDE version > 1 use this format). > > > > > > One possibility is to use an image library as imlib2. The advantage > > > is that if we do so fvwm will be able to load image in various > > > format (as jpg, tiff ...etc). Nevertheless, I do not think that this > > > is a good idea as IMHO we only need to add support for png image > > > and we do not need all the goodies of an image library. I mean > > > that I do not think that fvwm should depends on a given image > > > library (and we should write ourself our image goodies functions) > > > and then it will be absurd to use an image library for just loading > > > png images. > > > > I think imlib is installed on a lot modern systems. > > Yes, but here my objection: > - imlib is no more under development, it is replaced by imlib2. > - imlib is not used any more in GNOME (version >=2) and has a gtk+ > replacement in gtk+-2 (gtk-pixbuf or something like that). > - About imlib2: it seems to me that it is now a pure E library. > So it seems to me that imlib will progressively disappear and that > imlib2 will not have the same universality than imilib. > On the other hand libpng is used by every body. SOunds like libpng is the way to go. > > But using only libpng > > (that is a requirement for imlib anyway) to load png images is good too. > > Supporting gif and jpg images would be good, but png is more important. > > Yes, we may write gif and jpg loader (with libgif and libjpg). Gif and jpeg have a very low priority in my eyes. There are hardly andy icons in these formats on the net. The only module that would really profit is FvwmBacker - but FvwmBacker can easily use e.g. xv to display such images in the background. > > > So if there is no objection I will write a png loader (using > > > libpng) for fvwm (with the help of imlib2 source code). > > > > I am all for adding png support. > > You will have it in less than 7 days. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: png loader
On Sat, Mar 30, 2002 at 07:37:07AM +0100, Olivier Chapuis wrote: > Hello, > > I think it will be good that fvwm can load png images. The reason > is that png is a good format and that there is a lot of icons and > mini-icons in such format in the hd of a lot of machine (GNOME > and KDE version > 1 use this format). > > One possibility is to use an image library as imlib2. The advantage > is that if we do so fvwm will be able to load image in various > format (as jpg, tiff ...etc). Nevertheless, I do not think that this > is a good idea as IMHO we only need to add support for png image > and we do not need all the goodies of an image library. I mean > that I do not think that fvwm should depends on a given image > library (and we should write ourself our image goodies functions) > and then it will be absurd to use an image library for just loading > png images. > > So if there is no objection I will write a png loader (using > libpng) for fvwm (with the help of imlib2 source code). Of course, I'm against all new features ... ;-) That is, *unless* we take the chance to clean up the picture handling code :-) All that "#ifdef XPM" stuff could really be moved into a separate library. How about an Fpicture.c library with a sub module for xpm and png? Fpicture |_Fpm |_Fpng As usual, there should be only one fvwm picture structure that encapsulates all the details about the Xpm and png libraries. At present, there are 32 "#ifdef XPM"s in the code :-P BTW, I prefer to use libpng instead of imlib[2]. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/866
On Sun, Mar 31, 2002 at 05:49:24PM -0600, fvwm-bug wrote: > FVWM Bug Tracking notification > > new message incoming/866 > > Full_Name: jos > Version: 2.4.2 > CVS_Date: > OS: suse 7.3 > X_Server: > Submission from: (NULL) (194.109.171.157) > > > It would be nice if one could let the pager module pop up > >from the root window, as if it were a menu. Clicking the > root window once (without releasing) would pop up the pager. > While the button > is pressed one would select the window to go to, and then > one would actually go there by releasing the button again. > This would enable one to navigate really fast. > > Now, FvwmPager -transient only starts after the mouse > button was released. I tried to hack that into the code, but it's totally unusable with the pager: Button 1: To select a new viewport you have to press the button anyway. Button 2: To drag a window you have to release the button first to select a window or you have to push and multiple buttons. Very undesirable. Simply pushing the button on a window only raises it. That's not a very useful thing to do on a different page or desk, and on the current viewports there are better methods to do that. Button 3: This is the only binding that could profit, but since the desktop follows the motion of the pointer, the desktop just jumps around to funny places. In my eyes, it's useless for the pager. FvwmIconMan in transient mode could benefit, though. But then you might be better off using the built in WindowList. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: PositiveWrite problems
On Sun, Mar 31, 2002 at 10:17:11PM +0200, Dominik Vogt wrote: > On Sat, Mar 30, 2002 at 12:20:15PM +, Mikhael Goikhman wrote: > > I just enabled my FvwmEvent that listens to enter_window and leave_window, > > similarly to what Dominik posted some time ago, and I see how to reproduce > > the freeze for sure (just start the button bar that is auto raised/lowered > > or shaded on enter/leave, then while it swallows xclock/xload, enter and > > leave some window). I will debug this later. In this situation FvwmEvent > > is killed after the freeze, not something that I experienced previously. > > > > It may be harder with FvwmEvent that listens to add_window, I still (for > > months) can't find a way to reproduce the problem for sure and it was not > > killed after the freeze for unknown reason. > > As I posted in the past, FvwmConsole and FvwmIconMan have similar > problems. FvwmIconMan sometimes exits with the same message. > FvwmConsole can be overrun by terminal input: paste long scripts > into the FvwmConsole window fast and one of the pipes (either > between FvwmConsole and FvwmConsoleC or between FvwmConsole and > fvwm2, I don't know which) starts to lose some of the transmitted > characters. This may or may not be related. Finally tracked down the FvwmConsole problem: The mangled input comes from the getline() function (readline library). Filed a bug report there. Other apps using readline have the same problem (e.g. zsh). Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: fvwm20020401
On Mon, Apr 01, 2002 at 04:13:31PM -0800, Elliot Sowadsky wrote: > > problems w/ this snapshot: > (previous release used was fvwm20020326 on solaris 2.5.1) > > I still see border/titlebar discrepancies sometimes. *Please* be more detailed in you bug reports. Pretty pretty please! This is not helpful at all. If there is a problem, please describe exactly what happened and what you did when it happened. Screenshots might help too. Providing a config file won't hurt either. > fvwm pager, which was heavily changed between fvwm20020326 and fvwm20020401 > now has the top and left edges bordered by FvwmPagerColorset foreground. I don't understand what than means. > showstopper: hangs - and when hung, have seen app, fvwm or x-server being > the one using cpu. Um, so what is hanging? If it's the application or the X server I don't see a relation to fvwm. If fvwm hangs, please try to attach a debugger to it and see where it's looping. To do this, either escape to the console without killing the X server or log in from a different machine, then find out the process id with ps and run $ gdb fvwm2 Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/868
On Tue, Apr 02, 2002 at 10:14:39AM -0600, Jason L Tibbitts III wrote: > Crap, I actually approved that. I don't know where my mind was. Just take revenge and send them a mailbomb ;-) Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FvwmWinList scrambled by window closing
On Tue, Apr 02, 2002 at 03:54:24PM +0100, Tim Phipps wrote: > [EMAIL PROTECTED] wrote: > >Description: > > FvwmWinList gets messed up when the window at the top of the list > > closes. It looks like the old window names are not erased when the > > windowlist is redrawn. > > > >Repeat-By: > > *FvwmWinList: FollowWindowList > > Start several windows with different names > > Close on > > I think this might be a bit_gravity problem. I can't get FvwmWinList to > have a gravity of anything other than NorthWest. Does fvwm2 force this? Yes, it's essential to reduce redraws with opaque resize. I could restore the bit_gravity if that helps. But for me, the problem begins earlier: The FvwmWinList window does not resize at all. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: fvwm20020401
On Mon, Apr 01, 2002 at 04:13:31PM -0800, Elliot Sowadsky wrote: > showstopper: hangs - and when hung, have seen app, fvwm or x-server being > the one using cpu. I fixed a hang yesterday. If the problem remains, please report back. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: CVS olicha: * Added PNG support and Dominikisation of the XPM support
On Fri, Apr 05, 2002 at 03:24:36AM -0600, fvwm-workers wrote: > Log message: > * Added PNG support and Dominikisation of the XPM support ROFL :-)=) I'll be back to work this evening. Needed a week off. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Naming problems
On Sun, Apr 07, 2002 at 04:45:16PM -0400, Dan Espen wrote:
> Olivier Chapuis <[EMAIL PROTECTED]> writes:
> > Hello,
> >
> > I've a few (re)naming problems.
>
> Opinions follow.
>
> > 1 - As fvwm, XRender use Picture as its main "picture" structure.
> > This is currently solved by the following lines in Fft.h
> >
> > #ifdef HAVE_XFT
> > #define Picture XRenderPicture
> > #include
> > #undef Picture
> > #define Picture Picture
> > #endif
> >
> > Not terrible ... specially if we use XRender for alpha rendering.
> > So I suggest to rename the fvwm Picture structure by FvwmPicture.
> > And so also rename libs/Picture.{c,h}: FvwmPicture.{c,h} or
> > FPicture.{c,h}. Any better idea?
>
> FPicture.{c,h} is good.
The original idea was to replace the 'X' with an 'F' where
appropriate (Xft -> Fft, XShape -> FShape). If there is no chance
that we need FPicture for something different the name is good.
> > 3 - Now that xpmroot support PNG (and XBM) should we rename it (with a
> > symbolic link from xpmroot to the new name)? If yes one may think
> > that fvwm-root is a good name, but I do not think so because in fvwm
> > "-" separated names are scripts. FvwmRoot is obviously bad, but what
> > about "fvwmroot" ?
>
> fvwm-root, I don't see why the fvwm- rule can't be used for binaries.
I agree. Especially since there's some other tool named xpmroot
on the net.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, email: [EMAIL PROTECTED]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Fpng.h & Fxpm.h missing from libs/Makefile.am
On Mon, Apr 08, 2002 at 12:59:28PM +0100, tim phipps wrote: > Configuration Information [Automatically generated, do not change]: > uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 > compiler flags: gcc -g -O2 -Wall -Wno-implicit-int > > FVWM Version: 2.5.1 > FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 > FVWM_DATADIR: /u/phippst/sunos/share/fvwm > FVWM_USERDIR: /u/phippst/.fvwm > > Description: > Todays snapshot doesn't compile: > > FImageLoader.c:43: Fxpm.h: No such file or directory > FImageLoader.c:44: Fpng.h: No such file or directory Current CVS compiles well. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: patch - new build-in command EdgeCommand
On Mon, Apr 08, 2002 at 01:41:33PM -0400, Dan Espen wrote: > Uwe Pross <[EMAIL PROTECTED]> writes: > > On Mon, Apr 08, 2002 at 09:47:42AM -0400, Dan Espen wrote: > > > If someone were to read this, I think they'd be left with the > > > impression that these edges are on all 4 edges of the display. > ... > > I adapted the checkPanFrames() function that if a command is bound to > > a pan frame window it is always on the screen. > > OK, good. > > I think safestrdup does what the new duplicateString does. > > The east/west stuff and the 1 letter abbreviations aren't > documented. You could removed the east/west stuff, I don't > think its needed. I still have to document the possible values of the direction options. It's just code from the ParseDirectionArgument() function. > I think there should be some mention of the additional frames > when the commands are used. > > The FvwmAuto man page refers to an example in the fvwm2 man > page, but I couldn't find an example. > > The function StrEquals can be used for doing compares without > worring about case. > > I haven't applied the patch, I just reviewed it. If you think the patch is good, please apply it. I've a backlog of 150 mails, so it could take some time before I get to do it. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/872
On Tue, Apr 09, 2002 at 11:39:23AM -0500, fvwm-bug wrote: > FVWM Bug Tracking notification > > new message incoming/872 > > Full_Name: Edward Welbourne > Version: fvwm2/2.3, fvwm/2.4.6-1 > CVS_Date: > OS: Linux 2.2.19pre17; Debian 3.0 > X_Server: XFree86 > Submission from: (NULL) (193.69.113.22) > > > In the man page for fvwm2(1): > final paragraph of DESCRIPTION, just before OPTIONS: > >Other noteworthy differences between Fvwm and other X11 >window managers are the introduction of the SloppyFocus >and per-window focus methods. SloppyFocus is focus-fol- >lows-mouse, but focus is not removed from windows when the >mouse leaves a window and enters the root window. When >SloppyFocus is used as the default focus style, it is nice >to make windows in which you do not typically type into >(xmag, xman, xgraph, xclock, xbiff, etc.). NeverFocus, so >that your terminal window doesn't lose focus unnecessar- >ily. > > > > Should include NeverFocus with SloppyFocus in initial summary sentence. > Uses `windows in which you ... not type into' repeating `in' usage. > Last two `sentences' aren't sentences. Suggestion: > > Fvwm introduces some focus idioms improving greatly on other X11 > window managers. Focus policy can be specified for individual > windows. Windows using SloppyFocus acquire focus when the pointer > moves into them and retain focus until some other window acquires it. > The NeverFocus policy is provided for use with windows into which > one never types (e.g. [xo]clock, xbiff, xeyes, tuxeyes) - for example, if > a SloppyFocus terminal window has focus, moving the cursor over a > NeverFocus decoration window won't deprive the terminal of focus. > > Thanks for the pointer. I have applied this change with a little modification. > SloppyFocus rocks ;^) > Once experienced, all other focus policies hurt. In the mean time, many other window managers have implemented SloppyFocus too. > I've yet to try NeverFocus (new to me) but it sounds the perfect > accompaniment. Very usefull for FvwmPager, FvwmButtons, etc. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Menu code, again
On Wed, Apr 10, 2002 at 04:49:02PM -0400, Daniel Henninger wrote: > Hi folk, > > Things have calmed down again so... I'm looking into the menu code thing > again. I'm going to start working on separating out functions so they're > a bit cleaner and so it's easier to change the menu layout whenever we're > ready, if everyone is cool with that. That's a good place to start. I already begun to split menus.c into several files with a more limited scope, but it's hard to accomplish cleanly. If you have any ideas to improve the situation your work is very welcome. Before the actual implementation of the new menu syntax start we have to look back at the ideas and think about the right solution. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: czech keyboard and fvwm (incoming/837), patch
On Fri, Apr 12, 2002 at 05:18:23PM +0200, Jan Martinek wrote:
> Hello,
>
> my friend ( [EMAIL PROTECTED] ) made a patch for fixing the bad
> behaviour of czech keyboard in fvwm. He cannot write to you himself,
> because he must have gone to military service :-(((
> This is what ho wrote about the patch:
>
>
> The patch
> + solves our problem
> + shouldn't break other things more than they are now
> - is not particularly clean
> - doesn't solve the modifier problem generally
>
> * Czech (Slovak...) keyboard has traditionally two modes: Czech and English,
> with LShift-RShift or NumLock or something like that switching between
> them. This introduces another modifier, ``keyoard mode'', which actually
> gets its own bit in the `state' field assigned (on our machines it happens
> to be 0x2000, but I don't know how deterministic is it). This modifier
> doesn't really modify anything and should be completely ignored.
>
> * Generally, it doesn't make sense to keep any modifiers which are not in
> ALL_MODIFIERS (fvwm-2.2 did it approximately this way), however, fvwm-2.4
> keeps them all and ignores only explicitely specified (known) modifiers
> (why?).
Because accoridung to the spec there are no other modifiers than
Lock, Shift, Meta and 1 to 5.
> * Originally I thought mere adding `|~ALL_MODIFIERS' to `mods_unused' (i.e.
> setting all bits corresponding to should-be-ignored modifiers) would
> solve the problem, but it generated a HUGE number of following errors:
>
> [FVWM][<>]: FvwmErrorHandler *** internal error ***
> [FVWM][<>]: FvwmErrorHandler Request 33, Error 2, EventType: 20
>
> I don't understand why, but I didn't tried very hard to.
Don't fiddle with the unused modifiers. Fvwm tries to grab each
combination of unused modifiers. E.g. if Caps-Lock and Num-Lock
are ignored and you issue
key f1 a n bla
fvwm grabs (no modifiers), (caps-lock), (num-lock) and (num-lock +
caps-lock). If you add another 24 bits to the unused modifiers,
fvwm tries to grab 2^26 combinations of modifiers. Most of them
do not exist, hence the error messages.
> * At last, I modified CheckBinding() because it works, though it's probably
> quite dirty.
No, that is a good solution, but it may be incomplete. It is
never wrong to 'and' with ALL_MODIFIERS anywhere. There may be
more places that should have a similar patch applied.
> The fact I can't just modify `mods_unused' means either I'm
> completely wrong, or I don't understand all its uses, or there something
> broken in fvwm.
see above.
> I kept MatchBindingExactly() intact because it's never used (and maybe
> could
> be completely removed).
>
> * I can't check whether it breaks something with other strange national
> keyboards because I don't use them.
>
>
> --- fvwm-2.4.5.orig/libs/Bindings.c Wed Feb 20 20:19:35 2002
> +++ fvwm-2.4.5/libs/Bindings.cWed Feb 20 20:19:38 2002
> @@ -550,7 +550,7 @@
>Binding *b;
>unsigned int used_modifiers = ~dead_modifiers;
>
> - modifier &= used_modifiers;
> + modifier &= used_modifiers & ALL_MODIFIERS;
>
>for (b = blist; b != NULL; b = b->NextBinding)
>{
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, email: [EMAIL PROTECTED]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Colorsets
On Wed, Apr 17, 2002 at 12:00:49PM +0100, Tim Phipps wrote: > [EMAIL PROTECTED] wrote: > > >On 16 Apr 2002 15:13:30 +0100, Tim Phipps wrote: > > > >>Is it time to move the colorset handling from FvwmTheme to fvwm? > >> > >Actually moving the FvwmTheme code and replacing it with a pass-through > >module was on my todo list, near the top. But if you may do it, fine. > >I didn't plan to break any existing configs at this stage though. > > > OK, I'll do a patch that moves FvwmTheme into fvwm, I'll leave removing > stuff for later. > > >We should also add DeleteColorset somewhen to emulate DestroyModuleConfig. > > > There are problems with deleting colorsets that modules may be using > since they share the resources rather than copy them. Would it be > acceptable for DeleteColorset to reset the colorset to a simple default > rather than really delete it? What else could be done? The few bytes of wasted memory for the structure are irrelevant if the pixmaps are freed. > >>*) strip out every color type command from fvwm and all the modules > >> > >>Advantages: > >>*) Much less code in the modules for color handling so less bugs > >>*) Smaller man pages for the modules > >>*) Initializing colorset 0 to black/white with a stipled pixmap > >> background will enable monochrome monitors to have a 3d look and we > >> can lose all the "if (Pdepth < 2)" code > >>*) by default fvwm and the modules won't alloc any color cells > >> > >I don't know. I think this is 2 independent tasks. > > > >FvwmTheme may be obsoleted now without anyone noticing, but maybe removing > >non colorset color functionality may be done after 2.6.x, i.e. in 2.9.x? > > > OK, I just thought that now might be a good time since we've just > changed fvwm2 to fvwm. I'd rather leave the big changes for 3.0. Maybe we should make the 2.6 release in about half a year (I mean the release date, not the feature freeze). > >I am not sure about the last 2 advantages, maybe I don't understand it, > >but monochrome monitors don't really need to dictate the (ugly) default. > > > There are lots of instances of code that only get used on monochrome > monitors, do a grep for Pdepth and count the number of "if (Pdepth < > 2)"s. If fvwm's default colorset worked well on monochrome monitors we > could remove all this code. Yes, that would be a big step in the right direction. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Colorsets
On Wed, Apr 17, 2002 at 01:02:25PM +, Mikhael Goikhman wrote: > On 17 Apr 2002 12:00:49 +0100, Tim Phipps wrote: > > > > [EMAIL PROTECTED] wrote: > > > > > On 16 Apr 2002 15:13:30 +0100, Tim Phipps wrote: > > > > > > > > Advantages: > > > > *) Initializing colorset 0 to black/white with a stipled pixmap > > > >background will enable monochrome monitors to have a 3d look and we > > > >can lose all the "if (Pdepth < 2)" code > > > > *) by default fvwm and the modules won't alloc any color cells > > > > > > I am not sure about the last 2 advantages, maybe I don't understand it, > > > but monochrome monitors don't really need to dictate the (ugly) default. > > > > There are lots of instances of code that only get used on monochrome > > monitors, do a grep for Pdepth and count the number of "if (Pdepth < > > 2)"s. If fvwm's default colorset worked well on monochrome monitors we > > could remove all this code. > > Of course, this is a good thing, my point is that it may be better. > I don't like to have stippled black-white background on color monitors. > > Why not to have one "if (Pdepth < 2)" when defining colorset 0 or any > unused/deleted colorset? The default for normal depths could be as it is > now, 4 colors: black on rgb:be/be/be and its shadow/hilight. Good idea. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
colorsets are now completely broken
Wasn't it planned to make the new code complatible with the old FvwmTheme way? Now, all my colour sets are gone. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: colorsets are now completely broken
On Thu, Apr 18, 2002 at 11:33:29AM +0100, Tim Phipps wrote: > fvwm-workers@fvwm.org wrote: > > >Wasn't it planned to make the new code complatible with the old > >FvwmTheme way? Now, all my colour sets are gone. > > > >Bye > > > >Dominik ^_^ ^_^ > > > Yes, I don't know what's gone wrong. The differences between FvwmTheme.c > and colorset.c are fairly minor and I didn't have a problem with a > TrueColor display. I've switched to a PseudoColor and things are going > wrong. Things that have changed are: > >* The error handler, it used to core dump on just a few and was > silent on the rest, now it prints a message >* The cleanup routine that is used after a colorset pixmap is > changed, it used to wait for a period of inactivity before > deleting it, now it just waits 3 seconds for the change. > > Neither of these should have broken things badly, is it possible to get > an equivalnce check between the current colorset.c and the one I sent > in? I don't think the reformatting could have broken anything. No, that's not my problem. I fell for the renamed executable. I still started fvwm2 in my .xinitrc. Once I changed that, everything works fine here. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: colorsets are now completely broken
On Thu, Apr 18, 2002 at 11:15:13AM +, Mikhael Goikhman wrote: > On 18 Apr 2002 11:33:29 +0100, Tim Phipps wrote: > > > > fvwm-workers@fvwm.org wrote: > > > > >Wasn't it planned to make the new code complatible with the old > > >FvwmTheme way? Now, all my colour sets are gone. > > > > Yes, I don't know what's gone wrong. The differences between FvwmTheme.c > > and colorset.c are fairly minor and I didn't have a problem with a > > TrueColor display. I've switched to a PseudoColor and things are going > > wrong. Things that have changed are: > > > > * The error handler, it used to core dump on just a few and was > > silent on the rest, now it prints a message > > * The cleanup routine that is used after a colorset pixmap is > > changed, it used to wait for a period of inactivity before > > deleting it, now it just waits 3 seconds for the change. > > > > Neither of these should have broken things badly, is it possible to get > > an equivalnce check between the current colorset.c and the one I sent > > in? I don't think the reformatting could have broken anything. > > I just replaced the colorset.c in cvs with the one you sent (changing > s/FVWMTHEME_PRIVATE/FVWM_COLORSET_PRIVATE/) and I get exectly the same > results as mentioned in my other message with my depth 24, 16 and even 8. > > Everything works for me except for gradients. Well, this means most of > fvwm-themes colors@ work except for [EMAIL PROTECTED] that uses VGradient. > > I may suggest to temporarily comment out all *FvwmTheme ... VGradient. > Or you say anything else except for gradients are broken too? No, with the correct executable, everything works fine, even the gradients you mentioned. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Tear off menus stop module messages
On Fri, Apr 19, 2002 at 04:01:48PM +0100, tim phipps wrote: > Configuration Information [Automatically generated, do not change]: > uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 > compiler flags: gcc -g -O2 -Wall -Wno-implicit-int > > FVWM Version: 2.5.1 > FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 > FVWM_DATADIR: /u/phippst/sunos/share/fvwm > FVWM_USERDIR: /u/phippst/.fvwm > > Description: > When the pointer is on a tear off menu item fvwm stops processing > module messages. Yes, that's by design of the tear off menu code. I have no idea what to do about it (other that creating a separate instance of fvwm for each tear off menu). Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Tear off menus stop module messages
On Fri, Apr 19, 2002 at 12:59:10PM -0400, Dan Espen wrote: > Dominik Vogt writes: > > On Fri, Apr 19, 2002 at 04:01:48PM +0100, tim phipps wrote: > > > Configuration Information [Automatically generated, do not change]: > > > uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 > > > compiler flags: gcc -g -O2 -Wall -Wno-implicit-int > > > > > > FVWM Version: 2.5.1 > > > FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 > > > FVWM_DATADIR: /u/phippst/sunos/share/fvwm > > > FVWM_USERDIR: /u/phippst/.fvwm > > > > > > Description: > > > When the pointer is on a tear off menu item fvwm stops processing > > > module messages. > > > > Yes, that's by design of the tear off menu code. I have no idea > > what to do about it (other that creating a separate instance of > > fvwm for each tear off menu). > > Why can't the menu code be in a module? Of course menus *can* be a module. It's just that the menu code was not written to run independently of fvwm and is thus interwoven tightly with fvwm's data structures. Well, and as long as menus grab the pointer and the keyboard, processing module messages is pointless since the funtion execution code needs (?) to grab the pointer too. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/880
On Fri, Apr 19, 2002 at 08:32:51PM -0500, fvwm-bug wrote: > FVWM Bug Tracking notification > > new message incoming/880 > > Full_Name: Neil Zanella > Version: 2.4.6 > CVS_Date: > OS: > X_Server: > Submission from: (NULL) (129.128.206.232) > > > It would be nice if there were an option called ResizeUnshades such that > when a window is shaded and the user resizes it the window becomes > automatically unshaded so that when the mouse button is released > the whole window is visible once again. You don't need a new option to do this. Use this function: AddToFunc ResizeUnshade + I WindowShade off + I Resize $* Now, replace "Resize" with "ResizeUnshade" whereever you need it. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FvwmIconMan - "custom" sorting
On Sat, Apr 20, 2002 at 03:20:40PM -0700, Derek B. Noonburg wrote: > I added support to FvwmIconMan for a "custom" sort type, so you can do > stuff like this: > > *FvwmIconMan*sort custom > *FvwmIconMan*customsort 0 class=XTerm title=special > *FvwmIconMan*customsort 1 class=XTerm > *FvwmIconMan*customsort 2 class=Emacs title=hacking > *FvwmIconMan*customsort 3 class=Emacs > *FvwmIconMan*customsort 4 class=TkRat > *FvwmIconMan*customsort 5 class=Mozilla-bin > *FvwmIconMan*customsort 99 > > Now xterm windows with the title "special" go at the top, followed by > all other xterms, etc. The customsort option supports resource, class, > title, and icon (just like show/dontshow). > > If this sounds useful, I'll be happy to post the patch. (It's against > 2.4.7, not 2.5.x - sorry.) It sounds useful, but we still need the patch for the latest development verstion. You can download a snapshot or access CVS via anonymous ftp from our web site. The changes you have to do should be small - we didn't change FvwmIconMan much since 2.4.7. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Tear off menus stop module messages
On Mon, Apr 22, 2002 at 03:05:26PM -0400, Dan Espen wrote: > Dominik Vogt writes: > > On Fri, Apr 19, 2002 at 12:59:10PM -0400, Dan Espen wrote: > > > Why can't the menu code be in a module? > > > > Of course menus *can* be a module. It's just that the menu code > > was not written to run independently of fvwm and is thus > > interwoven tightly with fvwm's data structures. > > Well, and as long > > as menus grab the pointer and the keyboard, processing module > > messages is pointless since the function execution code needs (?) > > to grab the pointer too. > > I don't think I understand the point about the grab. > Its OK for menus to freeze FVWM so the grab should be OK. When any client grabs the pointer, fvwm basically stops processing most module messages too, at least if modules call complex functions. > I think putting the menu code in a module might simplify tear > off menus. I'm not sure of all the details but it just seems > like it might. Perhaps another copy of the menu module could be > started to handle the torn off menu (without grabs once its torn > off). Fvwm menus need to grab the keyboard to work properly. Pure mouse oparable menus would be useless to me. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Colorsets
On Tue, Apr 23, 2002 at 09:05:15AM +0100, Tim Phipps wrote: > [EMAIL PROTECTED] wrote: > > >I do not think the use of the SizeWindow was correct, it causes problem > >when you create the static gc in parse_colorset. If you take a look > >at the code the SizeWindow is created after the config file is read. > > > Sorry, that was my fault. My fvwmrc defines the colorsets as part of the > start function so I couldn't see the problem. > > >Also, since a long times it is the Scr.NoFocusWin which is used for > >loading FvwmPicture, so I used the Scr.NoFocusWin (which is created > >as soon as possible with the good parameters) and I saw no more > >FvwmErrorHandler error ... so I think the change is good :o) > > > Me too. Does this mean the mono gc in colorsets.c isn't needed? If not > it could use Scr.MonoGC. > > Is there anyone out there with a monochrome monitor that can test it? You can run XNest in monochrome mode. The X server has to support a monochrome visual though. Currently, I can't get it running again. Xnest -full -sync -depth 1 :1 Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: remaining decoration issues
On Mon, Apr 22, 2002 at 06:41:53PM +, Mikhael Goikhman wrote: > On 06 Apr 2002 03:02:35 -0500, Suzanne Skinner wrote: > > > > On Sun, Mar 31, 2002 at 10:33:42PM +0200, Dominik Vogt wrote: > > > > > Well, if you have time to spare you could take a look at the > > > FANCY_TITLE_BAR ifdefs. I didn't test that at all when I rewrote > > > the decoration layout code and it's very likely to be completely > > > broken now :-) > > > > Could do, if desired. > > We did not release 2.5.x for a long time. I think we should release 2.5.1 > in a week or so, since the new window decoration code works well now. > Basically everything seems to work now except for TitleStyle MultiPixmap > and ButtonStyle Solid. I would have fixed the solid button style already if somebody told me what was broken. I tried it and it works fine for me. I need a config example. > Suzanne, can you please estimate the amount of work needed? > Should we release 2.5.1 with or without working TitleStyle MultiPixmap? Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: remaining decoration issues
On Tue, Apr 23, 2002 at 12:51:45PM +, Mikhael Goikhman wrote: > On 23 Apr 2002 11:36:54 +0200, Dominik Vogt wrote: > > > > I would have fixed the solid button style already if somebody told > > me what was broken. I tried it and it works fine for me. I need > > a config example. > > Solid just does nothing. A minimal rc file: > > TitleStyle Inactive Solid darkcyan > ButtonStyle All Inactive Solid navy Fixed. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: make install
On Tue, Apr 23, 2002 at 02:05:12PM +, Mikhael Goikhman wrote: > On 23 Apr 2002 11:35:14 +0200, Dominik Vogt wrote: > > > > On Mon, Apr 22, 2002 at 08:56:19PM +, Mikhael Goikhman wrote: > > > On 22 Apr 2002 19:10:43 +0200, Dominik Vogt wrote: > > > > > > > > 1) "make install" does not work from within a running fvwm session > > > > (at least the last time I tried). It does not overwrite the > > > > running executables. > > > > > > I do "make install" with fvwm running for years. I think the problem was > > > prior to some linux version (2.0.x?), but it just always worked for me. > > > > > > > 2) It's ten times slower than my custom script that just overwrite > > > > the executables before restarting. > > > > > > On my 350MHz. 128Mb machine "make install" after "make" takes 20 seconds, > > > pretty acceptable. But I usually only do "make install" in the fvwm/ > > > directory if modules are not changed, this takes one second. > > > > > > > When I'm hacking away, I easily reinstall and restart fvwm 100 > > > > times per day. With my script, that takes about five to ten > > > > minutes, with "make install" it's one to two hours. > > > > > > I don't think so. You should do "make" anyway, it consumes all the time. > > > "make install" takes a constant time, 20 seconds on my machine. And if you > > > combine "make; make install" into one "make install" it takes even less. > > > > You see, the difference is 1 second with my script and 20 seconds > > with make install. The relation is pushed a bit in favour of make > > install because restarting takes constant time. > > > > > If you post your script, I can point out many problems with it as > > > compared to "make install". > > > > I'm fully aware of the many problems of the script. Usually I > > copy only the executables (and only if they changed). I didn't > > care to adapt copying of config files, utils and shell scripts for > > a long time. > > > > > The point is your script to work correctly > > > should reimplement what "make install" does, i.e. be equally slow. > > > > Sure, it should do that, but I don't need most of the make install > > functionality. But it would never become as slow because it has > > the paths of the files to install hard coded and doesn't have to > > start make five dozen times in various directories. > > Let's analize using facts, not conjectures. :) > > % make clean >/dev/null; time make install >/dev/null > Stat: User System Total time CPU Swaps Page faults > Time: 396.980 37.170 7:14.38 99.9% 0 636041/486483 > > % make clean >/dev/null; time make >/dev/null > Stat: User System Total time CPU Swaps Page faults > Time: 387.930 32.250 7:00.36 99.9% 0 493534/429114 Well, I'd never call make install to build the sources since I don't always get them installed and I'd have to take care what command I actually issue. Usually I press ctrl-alt-left to get to the shell from the xemacs window, the 'm' . That does not work if there are several commands beginning with 'm' that I use frequently. Therefore, I would use make install only when I want to install the sources, forcing me to traverse through the make tree once again. > I have 3 (actually more) cvs trees, in /data/cvs/fvwm/fvwm-2.2.x, > /data/cvs/fvwm/fvwm-2.4.x and /data/cvs/fvwm/fvwm, configured to install > everything to prefix /opt/fvwm-2.2, /opt/fvwm-2.4 and /opt/fvwm. > I have write permissions to all these directories. > > Now I do the following: > > % cd /data/cvs/fvwm/fvwm-2.4.x > % cvs update # or change sources > % make install > % FvwmCommand 'Restart /opt/fvwm-2.4/bin/fvwm -f ...' > > % cd /data/cvs/fvwm/fvwm > % cvs update # or change sources > % make install > % FvwmCommand 'Restart /opt/fvwm/bin/fvwm -f ...' > > This only rebuilds what was changed. > Please explain how your script does the same. $ make In fvwm (via FvwmButtons action): Restart /home/luthien/bin/restartfvwm In restartfvwm: ~/bin/fvwminstall exec ~/bin/fvwm2 $* In fvwminstall: rm ~/bin/fvwm2 cp $SRCDIR/fvwm/fvwm/fvwm2 ~/bin (same for all executables, optionally man pages and utils) > Moreover, I actually restart to /opt/fvwm-2.4/bin/fvwm-the
any reason to keep --disable-multibyte?
Now that multibyte support works nicely, itn't it time to remove the --(en|dis)able-multibyte configure options altogether? Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Colorsets
On Wed, Apr 24, 2002 at 06:15:18AM +0200, Olivier Chapuis wrote: > On Tue, Apr 23, 2002 at 09:05:15AM +0100, Tim Phipps wrote: > > [EMAIL PROTECTED] wrote: > > > > >I do not think the use of the SizeWindow was correct, it causes problem > > >when you create the static gc in parse_colorset. If you take a look > > >at the code the SizeWindow is created after the config file is read. > > > > > Sorry, that was my fault. My fvwmrc defines the colorsets as part of the > > start function so I couldn't see the problem. > > > > >Also, since a long times it is the Scr.NoFocusWin which is used for > > >loading FvwmPicture, so I used the Scr.NoFocusWin (which is created > > >as soon as possible with the good parameters) and I saw no more > > >FvwmErrorHandler error ... so I think the change is good :o) > > > > > Me too. Does this mean the mono gc in colorsets.c isn't needed? If not > > it could use Scr.MonoGC. > > > > Yes, I think it safe to use Scr.MonoGC for the mono gc. I will do > the change soon with adding XBM support to colorset. Just remember that the Scr.MonoGC is supposed to have some members (like tiling/stippling) set to specific values. If these are changed, the original values have to be restored after use. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: remaining decoration issues
On Wed, Apr 24, 2002 at 06:16:27AM +0200, Olivier Chapuis wrote: > On Mon, Apr 22, 2002 at 09:55:00PM -0400, Suzanne Skinner wrote: > > > I'll take a look at it and try to get a response back on this tonight. > > > > Hmm...I'm having a hard time getting the latest snapshot to compile. Maybe > > I should go All The Way to current CVS. > > > > I'm not sure if I'll be able to get the titlebars working again, but I'll > > give it a shot and probably let you guys know within a few days if I can > > manage it. > > > > What about using colorsets in the place of image files? That's an *excellent* idea. The colorset code is also the right place to implement pixmap rotation and/or mirroring if we want to go this way. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Tear off menus stop module messages
On Tue, Apr 23, 2002 at 06:05:06PM -0400, Dan Espen wrote: > Dominik Vogt writes: > > On Mon, Apr 22, 2002 at 03:05:26PM -0400, Dan Espen wrote: > > > Dominik Vogt writes: > > > > On Fri, Apr 19, 2002 at 12:59:10PM -0400, Dan Espen wrote: > > > > > Why can't the menu code be in a module? > > > > > > > > Of course menus *can* be a module. It's just that the menu code > > > > was not written to run independently of fvwm and is thus > > > > interwoven tightly with fvwm's data structures. > > > > Well, and as long > > > > as menus grab the pointer and the keyboard, processing module > > > > messages is pointless since the function execution code needs (?) > > > > to grab the pointer too. > > > > > > I don't think I understand the point about the grab. > > > Its OK for menus to freeze FVWM so the grab should be OK. > > > > When any client grabs the pointer, fvwm basically stops processing > > most module messages too, at least if modules call complex > > functions. > > I know that, but don't see that as a problem. We want FVWM > to freeze when a menu is popped up. > > > > I think putting the menu code in a module might simplify tear > > > off menus. I'm not sure of all the details but it just seems > > > like it might. Perhaps another copy of the menu module could be > > > started to handle the torn off menu (without grabs once its torn > > > off). > > > > Fvwm menus need to grab the keyboard to work properly. Pure mouse > > operable menus would be useless to me. > > I'm sorry if I'm wasting your time. Nonsense. > Maybe I don't understand what > a tear off menu is. I thought it was like one of those Openwin > menus that you use a pushpin to make it stay visible. Exactly. They are sometimes called pin up menus. I expect that torn off menus behave as any other application window does. This is very difficult to do if the torn off menus are handled directly in the fvwm code. > If I'm on the right track, then I think the menu would have to release > the grab once the menu is torn off. Well, it does release the grabs. But as it is now, whenever the pointer enters a tear off menu, fvwm makes the grabs again. As long as fvwm is in the menu loop it doesn't really matter if the grabs are made or not - it can't handle module input anyway in that code. > What I thought would happen > is the menu code would send a description of the menu to another > module and the module would create a normal window that looked > like the menu except that FVWM could reparent it, and if desired > frame, title and do other good things to it. Yes, I agree. In theory this sounds all very good. It's only that the menu code is woven into the fvwm framework so tightly that it's very hard to separate it and put it into a module. I don't like the idea of duplicationg the complete menu code either. I'm open to any ideas how to do this. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
another bidi compile error
make[2]: Entering directory `/net/lifelux/lifeshare/home/luthien/src/fvwm/libs' gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/usr/X11R6/include -g -O2 -Wall -Wno-implicit-int -c Flocale.c Flocale.c:739: macro `FBidiConvert' used with only 3 args (with bidi disables and --disable-multibyte). Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
bidi linkage error
Again, without using fribidi: gcc -DFVWM_MODULEDIR=\"/usr/local/libexec/fvwm/2.5.1\" -DFVWM_DATADIR=\"/usr/local/share/fvwm\" -DFVWM_CONFDIR=\"/usr/local/etc\" -g -Wall -Werror -O2 -o fvwm menus.o colorset.o style.o borders.o move_resize.o builtins.o events.o add_window.o module_interface.o icons.o stack.o functions.o virtual.o session.o fvwm.o placement.o focus.o read.o misc.o conditional.o colormaps.o repeat.o decorations.o bindings.o colors.o cursor.o update.o windowlist.o modconf.o gnome.o geometry.o icccm2.o ewmh.o ewmh_events.o ewmh_icons.o ewmh_names.o ewmh_conf.o schedule.o menuitem.o menustyle.o menudim.o menucmd.o windowshade.o frame.o -L../libs -L/usr/X11R6/lib -lfvwm -lXpm -lstroke -lSM -lICE -lXinerama -lXext -lX11 -lm -lXrender -lpng -lz session.o: In function `getUniqueStateFilename': /home/luthien/src/fvwm/fvwm/session.c:158: the use of `tempnam' is dangerous, better use `mkstemp' ../libs/libfvwm.a(Flocale.o): In function `FlocaleDrawString': /home/luthien/src/fvwm/libs/Flocale.c:736: undefined reference to `FlocaleGetBidiCharset' collect2: ld returned 1 exit status make[2]: *** [fvwm] Error 1 Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Tear off menus stop module messages
On Thu, Apr 25, 2002 at 12:24:25PM +0100, Tim Phipps wrote: > fvwm-workers@fvwm.org wrote: > > >On Tue, Apr 23, 2002 at 06:05:06PM -0400, Dan Espen wrote: > > > >>If I'm on the right track, then I think the menu would have to release > >>the grab once the menu is torn off > >> > >Well, it does release the grabs. But as it is now, whenever the > >pointer enters a tear off menu, fvwm makes the grabs again. As > >long as fvwm is in the menu loop it doesn't really matter if the > >grabs are made or not - it can't handle module input anyway in > >that code. > > > I think there might be a bug in the grabbing and it may be the reason > I'm seeing it as a problem. I don't mind fvwm stopping module messages > when the pointer is on the torn-off menu but it seems to keep the grab > when the pointer moves off and it only releases it when the pointer > enters another window. > Normally the grab is released when the pointer leaves the torn off menu > but if you use the keyboard to go from the torn off menu to a sub-menu > and the use the keyboard to go back to the torn off menu and then move > the pointer off the torn off menu the grab remains. You can see the grab > is active because the cursor stays the same as on the menu. Fixed. The although the grab was released, the pointer was immediately regrabbed because the menu code did not remove EnterNotify events from the queue. These were processed later by the main loop although the window had long been left again. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Patch - FvwmTaskBar Problem with StickyIcons when switching to another desk
On Tue, Apr 30, 2002 at 09:34:34PM +0200, Uwe Pross wrote: > Hi, > > Here is a very small patch which fixes the problem with FvwmTaskBar > and StickIcon style. It seems that the StickyIcon style has been > completly ignored by FvwmTaskBar. > I patched it against version 2.5.1 - hope the file FvwmTaskBar.c has > not been changed since then. If so maybe one of you guys can apply the > changes by hand. It is only one line in FvwmTaskBar.c. The same bug was in 2.4.7. I've applied the patch. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
autoconf weirdness
Recently I have a problem with autoconf/configure. This is probably caused by updating the system: m4-1.4o-76 automake-1.4_p5-44 autoconf-2.52-44 With "./configure --help" I get lines like these for the configure options that use the smr_SWITCH macro in acinclude.m4: --enable-command-log substr( , 11) enable command logging --enable-debug-msgs substr( , 10) enable debugging messages --disable-multipixmap-titles substr( , 18) disable fancy pixmap ti The responsible code from acinclude.m4: AC_DEFUN(smr_SWITCH, [ AC_MSG_CHECKING(whether to enable $2) AC_ARG_ENABLE( $1, ifelse($3, on, [ --disable-[$1]substr([ ], len([$1])) disable [$2]], [ --enable-[$1] substr([ ], len([$1])) enable [$2]]), ... It seems that the substr() m4 macro inside the ifelse() macro is no longer expanded but taken literally. I could not find a way to make the expansion work again. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: autoconf weirdness
On Sun, May 05, 2002 at 11:15:40AM +, Mikhael Goikhman wrote: > On 03 May 2002 12:58:10 +0200, Dominik Vogt wrote: > > > > Recently I have a problem with autoconf/configure. This is > > probably caused by updating the system: > > > > m4-1.4o-76 > > automake-1.4_p5-44 > > autoconf-2.52-44 > > I think it is a time to make autoconf-2.52 (or maybe 2.53?) a requirement > and start to use its features and bug fixes over autoconf-2.13. > > I am not sure yet about m4, I should see first how compatible are m4-1.4, > m4-1.4o and m4-1.4.1. > > > With "./configure --help" I get lines like these for the configure > > options that use the smr_SWITCH macro in acinclude.m4: > > > > --enable-command-log substr( , 11) enable command logging > > --enable-debug-msgs substr( , 10) enable debugging messages > > --disable-multipixmap-titles substr( , 18) disable fancy > > pixmap ti > > > > The responsible code from acinclude.m4: > > AC_DEFUN(smr_SWITCH, [ > > AC_MSG_CHECKING(whether to enable $2) > > AC_ARG_ENABLE( > > $1, > > ifelse($3, on, > > [ --disable-[$1]substr([ ], len([$1])) disable > > [$2]], > > [ --enable-[$1] substr([ ], len([$1])) enable > > [$2]]), > > ... > > > > It seems that the substr() m4 macro inside the ifelse() macro is > > no longer expanded but taken literally. I could not find a way to > > make the expansion work again. > > I will take a look at it after I get a chance to upgrade. > Currently you may remove substr(...) completely if it creates problems. Well, it's not really a serious problem. The 'substr(...)' part is simply displayed in the help message. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: MwmButtons and ButtonStyle All
On Sun, May 05, 2002 at 06:17:16PM -0600, S. Anderson wrote: > Hi > If I issue these: > > Style * MwmButtons > Mouse 0 2 A WindowShade > ButtonStyle 2 - MWMDecorShade > AddButtonStyle All ActiveUp solid blue > > After I push button 2, It doesnt have a green color. Should > "ButtonStyle All ActiveUp" apply blue to ToggledActiveUp too? I'm not sure where the green colour should come from in your example. This is how the button states work: ActiveUp = Window has focus and is not shaded, the button is not being currently pressed. ActiveDown = Window has focus and is not shaded, the button is being currently pressed. ToggledActiveUp = ActiveUp, but window is shaded. ToggledActiveDown = ActiveDown, but window is shaded. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Fixed bit_gravity problem
Tim, does my latest commit fix all the bit_gravity problems you encountered? Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/888
On Tue, May 07, 2002 at 06:36:37AM -0500, fvwm-bug wrote: > FVWM Bug Tracking notification > > new message incoming/888 > > Message summary for PR#888 > From: [EMAIL PROTECTED] > Subject: ClickToFocusDoesntRaise DoesntWork > Date: Tue, 07 May 2002 06:36:35 -0500 > 0 replies 0 followups > > Full_Name: Mark D > Version: 2.2.5 > CVS_Date: > OS: OpenBSD (default wm) > X_Server: XF86_SVGA (XFree 3.3.6) > Submission from: (NULL) (198.164.220.146) > > > Setting the 'ClickToFocusDoesntRaise' globalopt doesn't have desired > effect. > Clicking in the window frame raises the window nomatter how this option is > set. The following hack deactivates the offending behaviour, perhaps > inelegantly, but might be useful in tracking the problem. Fvwm 2.2.5 is > the > default window manager for OpenBSD to this day, so the problem is relevent > (at least to me!). This bug has long been fixed in later versions. Please upgrade to the latest stable release (2.4.7). The 2.2.x stable releases are no longer maintained (i.e. no bug fixes made). Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: core dump in colorset.c
On Tue, May 07, 2002 at 02:28:19PM +0100, tim phipps wrote: > Configuration Information [Automatically generated, do not change]: > uname: SunOS silver 5.5.1 Generic_103640-40 sun4u sparc SUNW,Ultra-5_10 > compiler flags: gcc -g -O2 -Wall -Wno-implicit-int > > FVWM Version: 2.5.2 > FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.2 > FVWM_DATADIR: /u/phippst/sunos/share/fvwm > FVWM_USERDIR: /u/phippst/.fvwm > > Description: > I get a core dump when executing this line: > Colorset 0 DGradient 100 #0f0f9f #ff, bg Average, fg Contrast, sh > #0f0f9f, hi #ff Fixed. Olivier, please take a look at colorset.c. There were a number of bugs with the cs->picture structure (accessing members when it was NULL, comparing the pointer with 'None' instead of NULL, checks in 'if' bodies where cs->picture wasn't used at all). I'm not sure I've done everything right. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Colorset ideas [Was Re: core dump in colorset.c]
On Tue, May 07, 2002 at 10:22:13PM +0200, Olivier Chapuis wrote: > About average and tinting. Tint/TintMask allows to tint a pixmap, > my pbs is: do we have to compute the average bg after tinting > or not. With Tint, as the bg is also tinted, it seems that we have > to compute the average bg before tinting (but sh/hi maybe "wrong") > as with TintMask nothing is clear for me. Can you post a few examples that demonstrate the new features? Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Colorset ideas
On Wed, May 08, 2002 at 07:28:29AM +0200, Olivier Chapuis wrote: > On Tue, May 07, 2002 at 10:43:08PM +, Mikhael Goikhman wrote: > > On 07 May 2002 22:22:13 +0200, Olivier Chapuis wrote: > > > > > About bitmap I think it will be good to be able to define the bg and > > > the fg of the bitmap. The bitmap currently used the fg and bg color > > > and this gives unreadable text (if you do not use a tint). Any > > > objection for a bitmap_bg and a bitmap_fg options to the colorset > > > command? > > > > I have no real objection, but I would rather prefer to add support for > > symbolic color names in xpm pixmaps. I.e. support xpm, not limited xbm. > > The names that CDE supports would be a good start (bottomShadowColor is > > sh, topShadowColor is hi, I am not sure about names they use for fg and > > bg), and all colorset colors may be handled, not only the main four. Now *that* would be a cool feature. I've been using FvwmCpp for years so I can have palettes (and font lists) with symbolic names. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Colorset ideas
On Tue, May 07, 2002 at 10:43:08PM +, Mikhael Goikhman wrote: > I can see a need in additional colors per colorset. Say, something that > could be used in Vector buttons, currently only fg, bg, sh and hi allowed. > So, we may add sh_vector, hi_vector. I don't like the idea over overloading individual colour sets with lots of colours. Tim and I discussed that back then when he wrote FvwmTheme cand came up with the four colour structure we have now. Mikhael, what you are probably seeing a colour set as a kind of 'theme' whereas I see it as a colour pair with options. I agree that there may be a need for more complex theme like structures. But I'd rather see them as a layer on top of colour sets. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Colorset ideas [Was Re: core dump in colorset.c]
On Wed, May 08, 2002 at 12:20:45PM +0200, Olivier Chapuis wrote: > On Wed, May 08, 2002 at 10:12:57AM +0200, Dominik Vogt wrote: > > On Tue, May 07, 2002 at 10:22:13PM +0200, Olivier Chapuis wrote: > > > About average and tinting. Tint/TintMask allows to tint a pixmap, > > > my pbs is: do we have to compute the average bg after tinting > > > or not. With Tint, as the bg is also tinted, it seems that we have > > > to compute the average bg before tinting (but sh/hi maybe "wrong") > > > as with TintMask nothing is clear for me. > > > > Can you post a few examples that demonstrate the new features? > > > > If it is the Tint feature you are intersted on here an example: > > Colorset 50 TiledPixmap background/fvwm-flying.xpm, NoTint > Colorset 51 TiledPixmap background/fvwm-flying.xpm, Tint blue 20 > Colorset 52 TiledPixmap background/fvwm-flying.xpm, Tint yellow 20 > Colorset 53 TiledPixmap background/fvwm-flying.xpm, Tint black 30 > > DestroyModuleConfig FvwmBacker: * > *FvwmBacker: Command (Desk 0) Colorset 50 > *FvwmBacker: Command (Desk 1) Colorset 51 > *FvwmBacker: Command (Desk 2) Colorset 52 > *FvwmBacker: Command (Desk 3) Colorset 53 > > So one xpm and 4 differents backgrounds for the 4 desks I use. > Now an example where average/contrast come into play with tint: > > # standard item > Colorset 17 fg contrast, bg average, \ > TiledPixmap background/stone.xpm, NoShape > # active item > Colorset 18 fg contrast, bg average, \ > TiledPixmap background/stone.xpm, Tint red 30, NoShape > # iconified item > Colorset 19 fg contrast, bg average, \ > TiledPixmap background/stone.xpm, Tint white 30, NoShape > # pointed item > Colorset 20 fg contrast, bg average, \ > TiledPixmap background/stone.xpm, NoShape > # modules special background > Colorset 12 fg black, bg rgb:80/A0/A0, \ > Transparent, NoShape > > *FvwmIconMan: *colorset 12 > *FvwmIconMan: *iconcolorset 19 > *FvwmIconMan: *plaincolorset 17 > *FvwmIconMan: *selectcolorset 20 > *FvwmIconMan: *focuscolorset 18 > *FvwmIconMan: *focusandselectcolorset 20 > > So again one xpm and various colors. plain iconman buttons are > ok. But, at the present time, others does not have good fg,sh and hi > colours as stone.xpm gives a dark average bg colors and the corresponding > sh, hi and contrast colors are computed from this colors. For example > all contrast fg colorset are almost white which is not correct for colorset > 19 which has grey bg in the average. Very nice. However, FvwmIconMan does not refresh the transparent parts of the background when they are obscured and revealed again. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Colorset ideas [Was Re: core dump in colorset.c]
On Wed, May 08, 2002 at 01:40:17PM +0200, Olivier Chapuis wrote: > On Wed, May 08, 2002 at 01:14:46PM +0200, Dominik Vogt wrote: > > On Wed, May 08, 2002 at 12:20:45PM +0200, Olivier Chapuis wrote: > > > # standard item > > > Colorset 17 fg contrast, bg average, \ > > > TiledPixmap background/stone.xpm, NoShape > > > # active item > > > Colorset 18 fg contrast, bg average, \ > > > TiledPixmap background/stone.xpm, Tint red 30, NoShape > > > # iconified item > > > Colorset 19 fg contrast, bg average, \ > > > TiledPixmap background/stone.xpm, Tint white 30, NoShape > > > # pointed item > > > Colorset 20 fg contrast, bg average, \ > > > TiledPixmap background/stone.xpm, NoShape > > > # modules special background > > > Colorset 12 fg black, bg rgb:80/A0/A0, \ > > > Transparent, NoShape > > > > > > *FvwmIconMan: *colorset 12 > > > *FvwmIconMan: *iconcolorset 19 > > > *FvwmIconMan: *plaincolorset 17 > > > *FvwmIconMan: *selectcolorset 20 > > > *FvwmIconMan: *focuscolorset 18 > > > *FvwmIconMan: *focusandselectcolorset 20 > > > > > > So again one xpm and various colors. plain iconman buttons are > > > ok. But, at the present time, others does not have good fg,sh and hi > > > colours as stone.xpm gives a dark average bg colors and the corresponding > > > sh, hi and contrast colors are computed from this colors. For example > > > all contrast fg colorset are almost white which is not correct for > > > colorset > > > 19 which has grey bg in the average. > > > > Very nice. However, FvwmIconMan does not refresh the transparent > > parts of the background when they are obscured and revealed again. > > > > I cannot reproduce this. Do you use the ParenatlRelativity style? > This style must be set for any apps which use a transparent colorset. > I've a plan to do this automaticaly. Actually, I just added your config on top of mine: *FvwmThemeColorset 2 fg red, bg green *FvwmThemeColorset 6 fg red, bg blue, cgradient 20 yellow orange Style FvwmIconMan NoTitle, Sticky, NoHandles, Icon toolbox.xpm Style FvwmIconMan WindowListSkip, CirculateSkip *FvwmIconMan*Action Mouse 3 N sendcommand close *FvwmIconMan*FollowFocus true *FvwmIconMan*Font 5x7 *FvwmIconMan*Format "%t" *FvwmIconMan*ManagerGeometry 2x5 *FvwmIconMan*Resolution page *FvwmIconMan*Title "" *FvwmIconMan*UseWinList true *FvwmIconMan*Action Mouse 2 N sendcommand Focus *FvwmIconMan*Colorset 6 *FvwmIconMan*FocusColorset 2 *FvwmIconMan*FocusAndSelectColorset 2 *FvwmIconMan*PlainColorset 6 *FvwmIconMan*SelectColorset 6 *FvwmIconMan*TitleColorset 6 *FvwmIconMan*FocusButton up *FvwmIconMan*PlainButton up *FvwmIconMan*SelectButton flat *FvwmIconMan*FocusAndSelectButton flat *FvwmIconMan*TitleButton flat Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Colorset ideas [Was Re: core dump in colorset.c]
On Wed, May 08, 2002 at 02:30:02PM +0200, Olivier Chapuis wrote: > On Wed, May 08, 2002 at 02:27:38PM +0200, Dominik Vogt wrote: > > > > > Actually, I just added your config on top of mine: > > > > Again you should add > > Style FvwmIconMan ParentalRelativity > > (and restart IconMan) so that transparent colorset can work. Ah, cool, I see. Sorry if I'm asking dumb questions. I didn't test much of the new functionality you and Mikhael have written in the last months. One thing that doesn't work though: when you start - say - FvwmButtons with a transparent colour set, but without ParentalRelativity: Cover it with a window, then reveal it again. The thransparent parts are not redrawn. Now switch to ParentalRelativity. The transparent parts are still not redrawn. This is done only when they are exposed again. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: fvwm20020401
On Wed, Apr 03, 2002 at 02:31:36PM -0800, Elliot Sowadsky wrote: > > > showstopper: hangs - and when hung, have seen app, fvwm or x-server being > > the one using cpu. > > I cant get fvwm to show debug info, but when it hanges, > these routines are on the (where) stack... > > XCheckIfEvent > _XEventsQueued > > > > I still see border/titlebar discrepancies sometimes. > > Affects xview clients... > > Open an xview window and some other window. > Select the other window. > Iconify it. > Maximize then unmaximize the xview window. > The xview window will now have parts of the border drawn active > and other parts not. Titlebar will be shown inactive. > > > Style * Colorset 3 > Style * HilightColorset 4 > Style * MWMBorder > Style * DecorateTransient > Style * BorderWidth 5, HandleWidth 5, ResizeOpaque, StartsAnyWhere, StaysPut, > UseIconPosition, NoIconTitle, ClickToFocus, MaxWindowSize 100 100 > Style * ClickToFocusRaisesOff # , CleverPlacement > Style StickyStyle Sticky, NoButton 3, NoButton 5, NoButton 7, NoButton 9 > Style Fvwm* NoTitle, Sticky, WindowListSkip > Style Iexplorer IconOverride, IgnoreRestack, Icon map.xpm Is that still happening? I can't reproduce this. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Active menu items drawn wrong outside the active area
On Wed, Apr 03, 2002 at 03:43:19PM +0100, Tim Phipps wrote: > Configuration Information [Automatically generated, do not change]: > uname: SunOS silver 5.5.1 Generic_103640-39 sun4u sparc SUNW,Ultra-5_10 > compiler flags: gcc -g -O2 -Wall -Wno-implicit-int > > FVWM Version: 2.5.1 > FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.1 > FVWM_DATADIR: /u/phippst/sunos/share/fvwm > FVWM_USERDIR: /u/phippst/.fvwm > > Description: > The test of items is drawn with the ActiveColorset even though > some parts of the text are outside the active area defined by the > ItemFormat. This means the coordinate part of the windowlist > is unreadable for the active item. > > Repeat-By: > > Set colorset 0 to be black on gray > Set colorset 1 to be gray on black > > MenuStyle * HilightBack > MenuStyle * MenuColorset 0 > MenuStyle * ActiveColorset 1 > MenuStyle * GreyedColorset 3, > MenuStyle * Hilight3DThick > MenuStyle * Animation > MenuStyle * PopupOffset 0 100 > MenuStyle * TrianglesSolid > MenuStyle * ItemFormat "%.4s%.5i%.1|%.5l%|%5.5r%.5r%5.5i%2.3>" > MenuStyle * AutomaticHotkeys > > WindowList > > > I think there might be something wrong with the triangles too, the solid > active triangle is drawn in what looks like the hilight color of the > MenuColorset All fixed. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Colorset ideas [Was Re: core dump in colorset.c]
On Wed, May 08, 2002 at 04:34:30PM +0200, Olivier Chapuis wrote: > On Wed, May 08, 2002 at 02:50:30PM +0200, Dominik Vogt wrote: > > On Wed, May 08, 2002 at 02:30:02PM +0200, Olivier Chapuis wrote: > > > On Wed, May 08, 2002 at 02:27:38PM +0200, Dominik Vogt wrote: > > > > > > > > > > > Actually, I just added your config on top of mine: > > > > > > > > > > Again you should add > > > > > > Style FvwmIconMan ParentalRelativity > > > > > > (and restart IconMan) so that transparent colorset can work. > > > > Ah, cool, I see. Sorry if I'm asking dumb questions. I didn't > > test much of the new functionality you and Mikhael have written in > > the last months. One thing that doesn't work though: when you > > start - say - FvwmButtons with a transparent colour set, but > > without ParentalRelativity: Cover it with a window, then reveal > > it again. The thransparent parts are not redrawn. Now switch to > > ParentalRelativity. The transparent parts are still not redrawn. > > This is done only when they are exposed again. > > > > Yes, ParentalRelativity is not dynamic. I think that it is not > a new miss feature. Tim? Couldn't you simply force a refresh of the window when ParentRelativity becomes set? Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Colorset ideas
On Wed, May 08, 2002 at 09:19:51PM +, Mikhael Goikhman wrote: > On 08 May 2002 10:21:35 +0200, Dominik Vogt wrote: > > > > On Tue, May 07, 2002 at 10:43:08PM +, Mikhael Goikhman wrote: > > > I can see a need in additional colors per colorset. Say, something that > > > could be used in Vector buttons, currently only fg, bg, sh and hi allowed. > > > So, we may add sh_vector, hi_vector. > > > > I don't like the idea over overloading individual colour sets with > > lots of colours. Tim and I discussed that back then when he wrote > > FvwmTheme cand came up with the four colour structure we have now. > > Mikhael, what you are probably seeing a colour set as a kind of > > 'theme' whereas I see it as a colour pair with options. I agree > > that there may be a need for more complex theme like structures. > > But I'd rather see them as a layer on top of colour sets. > > I see a colorset as the only way to define colors inside a rectangle box. > I don't think that 4 main colors are enough for all needs. IMHO, it is > sometimes better to extend a colorset a bit if this solves a class of > problems than to use a new colorset just for one single color (other 3 > colors and background image are unused). > > There is no much need for sh_vector and hi_vector, they were examples. > Although they don't consume more than some bytes and have good defaults. > > But do you have anything against adding fg_shadow color (or fgsh)? No, not at all. I've no problem as long as the colour in the colour set are usable regardless of the context (you could use a shadow colour anywhere where text is drawn). On the other hand, I wouldn't like to have - for example - icon specific colours in the colour set. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: fvwm20020401 bug
On Wed, May 08, 2002 at 04:58:00PM -0700, Elliot Sowadsky wrote: > > > but now the (xview) program requested resize (request while mouse is inside > > program window) is held off until the mouse is over the title/border. > > This is my own xview program. Then I can't help you unless you send me the sources and/or an executable. > But i figured narrowing the changes down to snapshots 331 -> 401 might make > it apparent what would cause fvwm to wait before doing the window change. > > I'm using clicktofocus. > > Just tried w/ clicktofocus commented out. > Still get wait to recognize new geometrybut also discovered that in > xview default focus will drop focus on exit, but not return it on > entry to xview window. Instead requires a click to focus That's the way focus in xview applications works. They explicitly ask for this focus scheme. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Colorset ideas
On Fri, May 10, 2002 at 10:33:32AM +0200, Olivier Chapuis wrote: > On Thu, May 09, 2002 at 12:48:28AM +0200, Dominik Vogt wrote: > > On Wed, May 08, 2002 at 09:19:51PM +, Mikhael Goikhman wrote: > > > On 08 May 2002 10:21:35 +0200, Dominik Vogt wrote: > > > But do you have anything against adding fg_shadow color (or fgsh)? > > > > No, not at all. I've no problem as long as the colour in the > > colour set are usable regardless of the context (you could use a > > shadow colour anywhere where text is drawn). On the other hand, > > I wouldn't like to have - for example - icon specific colours in > > the colour set. > > > > So if I well understand you are opposed to colorset options as: > > - IconTint colour percent / IconAlpha percent > > which whenever a (mini-)icon is implied in the drawn rectangle > tint this (mini-)icon with "colour" at percent rate "percent" > (apply the mini-icon with an additional alpha of "percent", > respectively). > ... But why make a special case if there is a mini icon? If we need a tint colour, shouldn't it be applicable to any forground, not just icons? I see no reason why, for example, text shouldn't benefit from tinting. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: CVS domivogt: * Fixed menu item hilighting outside the hilit area.
On Fri, May 10, 2002 at 08:19:05AM +0200, Olivier Chapuis wrote: > On Wed, May 08, 2002 at 05:39:10PM -0500, FVWM CVS wrote: > > CVSROOT:/home/cvs/fvwm > > Module name:fvwm > > Changes by: domivogt02/05/08 17:39:10 > > > > Modified files: > > . : ChangeLog > > fvwm : menuitem.c > > > > Log message: > > * Fixed menu item hilighting outside the hilit area. > > > > Since this commit I see that the hilight rectangle is drawn > on the main menu relief. This is really visible with a big > popup delay: MenuStyle * PopupDelayed, PopupDelay 2000 Oops. Fixed (as soon as our inet connection is up again). Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: fvwm/menuitem.c
On Fri, May 10, 2002 at 10:17:43AM +0200, Giuseppe Della Ricca wrote: > Hi Dominik, > > after your latest commit (fvwm/menuitem.c) I see that the left side of the > menu (its border) corresponding to the current item is (correctly) hilighted, > but when I move the pointer to a different item the border it is not > restored to the previous not-hilighted state. > > The menu title is never affected, since it is never hilighted. > > Some info from my setup: > > CleanupColorsets > Colorset 0 Foreground black, Background grey90 > Colorset 1 Foreground black, Background grey80 > Colorset 2 Foreground black, Background grey60 > Colorset 3 Foreground black, Background grey40 > > MenuStyle * Fvwm, Animation > MenuStyle * MenuColorset 1 > MenuStyle * ActiveColorset 0, HilightBack > MenuStyle * GreyedColorset 3 > > If you need some more informations, please let me know. Please CC for a > faster reply. Is it fixed with my latest commit? If not, can you make a minimal rc file that shows the problem? Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Colorset ideas
On Sat, May 11, 2002 at 08:21:17AM +0200, Olivier Chapuis wrote:
> On Fri, May 10, 2002 at 06:42:01PM +, Mikhael Goikhman wrote:
> > I didn't even mean that symbolic colors once xpm is loaded are dynamic,
> > but of course dynamic functionality would be good, i.e. if sh is changed,
> > the symbolic xpm in that colorset is reloaded.
> >
>
> For xpms into a colorset I do not think this is difficult.
>
> One problem I see here is the fg/fgsh colors. When you apply
> text on an picture it is not so good that the picture used the
> fg/fgsh colors. So we have only 3 relevant colors bg,sh and hi
> and for bitmap only one relevant color bg :o((. Maybe we can add
> one "icon" color to a colorset (corresponding to the cde SelectColor),
> say iconfg?
I'm more fond of colours that are referenced by their meaning, not
by their context. Is it really necessary to distinguish between
different kinds of foreground? After all, if text and a pixmap
are used in the same object, one can define a second colour set
for the pixmap. Hm, it might be difficult to understand which
colour set is used, for example, for the background colour.
In the long run, I think it's a good idea to put all the visual
effects into colour sets and provide a function
"render_into_area". With that, the drawing code in the
modules could be simplified a lot.
typedef struct
{
colorset text_colorset;
/* description of font and string to draw */
/* ... */
} render_text_object;
typedef struct
{
colorset picture_colorset;
/* ... */
} render_picture_object;
typedef struct
{
render_text_object *text;
render_picture_object *picture;
} render_object;
void render_gui_object_into_area(
Display *dpy, Drawable dest_d, XRectangle *dest_rect,
render_object *src_obj);
> Dominik an objection?
Not if we can find a good name that allows to use the additional
parts in a generic way.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, email: [EMAIL PROTECTED]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Colorset ideas
On Sat, May 11, 2002 at 06:38:25PM +0200, Olivier Chapuis wrote: > On Fri, May 10, 2002 at 12:33:47PM +0200, Dominik Vogt wrote: > > But why make a special case if there is a mini icon? If we need > > a tint colour, shouldn't it be applicable to any forground, not > > just icons? I see no reason why, for example, text shouldn't > > benefit from tinting. > > > > I do not think that tint should be applied to fg, *Gradient and > even the transparent part of the background of a pixmap (i.e., bg). > At the present time Tint tints the transparent part of the background > the cs pixmap for *Pixmap colorset (as TintMask does not) and now > I think this is not a good idea. > The reason is that I do not see the interset to tint a colour, > the user can do that by just changing the color in the Colorset > cmd. But the user does not know the algorithm in fvwm. Consider this: You have a button button with text and an icon in FvwmButtons. It shall visually indicate if the internet connection is up. One might want to do this by tinting the whole button. You could simply say Colorset 123 tint blue Very comfortable to use and very flexible. We might want to distinguish between a foreground and background tint. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
some eye candy
Just a little screen shot using a transparent FvwmButtons with swallowed apps that use the same background. Very good work on the ParentalRelativity style, Olivier! Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 trans_buttons.png Description: PNG image
Re: Colorset ideas
On Mon, May 13, 2002 at 04:40:20PM +0200, Olivier Chapuis wrote: > On Mon, May 13, 2002 at 12:07:20PM +0200, Dominik Vogt wrote: > > On Sat, May 11, 2002 at 06:38:25PM +0200, Olivier Chapuis wrote: > > > On Fri, May 10, 2002 at 12:33:47PM +0200, Dominik Vogt wrote: > > > > But why make a special case if there is a mini icon? If we need > > > > a tint colour, shouldn't it be applicable to any forground, not > > > > just icons? I see no reason why, for example, text shouldn't > > > > benefit from tinting. > > > > > > > > > > I do not think that tint should be applied to fg, *Gradient and > > > even the transparent part of the background of a pixmap (i.e., bg). > > > At the present time Tint tints the transparent part of the background > > > the cs pixmap for *Pixmap colorset (as TintMask does not) and now > > > I think this is not a good idea. > > > > > The reason is that I do not see the interset to tint a colour, > > > the user can do that by just changing the color in the Colorset > > > cmd. > > > > But the user does not know the algorithm in fvwm. Consider this: > > You have a button button with text and an icon in FvwmButtons. It > > shall visually indicate if the internet connection is up. One > > might want to do this by tinting the whole button. You could > > simply say > > > > Colorset 123 tint blue > > > > Very comfortable to use and very flexible. We might want to > > distinguish between a foreground and background tint. > > > > So we should have fgTint, bgTint (for the bg and the gradients), > PixmapTint (for the non transparent part of the pixmap) and > IconTint for the contextual (mini-)icon. > Pixmaptint and IconTint are really natural with Xrender Hm, why not make a whole 'tint colour set': Colorset 123 fg blue, bg red, sh orange, hi green Colorset 234 tintcolorset 123 That's the most flexible solution and it does not even have to extend colour sets. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Colorset ideas
On Mon, May 13, 2002 at 09:59:51PM +0200, Olivier Chapuis wrote:
> On Mon, May 13, 2002 at 12:02:13PM +0200, Dominik Vogt wrote:
> > On Sat, May 11, 2002 at 08:21:17AM +0200, Olivier Chapuis wrote:
> > > On Fri, May 10, 2002 at 06:42:01PM +, Mikhael Goikhman wrote:
> > > > I didn't even mean that symbolic colors once xpm is loaded are dynamic,
> > > > but of course dynamic functionality would be good, i.e. if sh is
> > > > changed,
> > > > the symbolic xpm in that colorset is reloaded.
> > > >
> > >
> > > For xpms into a colorset I do not think this is difficult.
> > >
> > > One problem I see here is the fg/fgsh colors. When you apply
> > > text on an picture it is not so good that the picture used the
> > > fg/fgsh colors. So we have only 3 relevant colors bg,sh and hi
> > > and for bitmap only one relevant color bg :o((. Maybe we can add
> > > one "icon" color to a colorset (corresponding to the cde SelectColor),
> > > say iconfg?
> > > Dominik an objection?
> >
> > I'm more fond of colours that are referenced by their meaning, not
> > by their context. Is it really necessary to distinguish between
> > different kinds of foreground? After all, if text and a pixmap
> > are used in the same object, one can define a second colour set
> > for the pixmap. Hm, it might be difficult to understand which
> > colour set is used, for example, for the background colour.
> >
> > [BottomToTop]
> >
> > Not if we can find a good name that allows to use the additional
> > parts in a generic way.
> >
>
> Really, I've not a more generic name than "iconfg" for this
> "foreground" icon colour. The reason is that I see that it will
> be good to have a new colour for Bitmap fg and xpms but
> I do not see where we can use an other colour at all. Of course,
> we can introduce fghi but I think that two colours is enough
> for text rendering and this will solve in the strange way
> this icon fg pbs.
> So I suggest "iconfg" as generic name, but any others idea
> and objections are welcome.
>
> >
> > In the long run, I think it's a good idea to put all the visual
> > effects into colour sets and provide a function
> > "render_into_area". With that, the drawing code in the
> > modules could be simplified a lot.
> >
>
> I think that I've begin this work.
>
> > typedef struct
> > {
> > colorset text_colorset;
> > /* description of font and string to draw */
> > /* ... */
> > } render_text_object;
> >
>
> We already have this one: the FlocaleWinString structure that
> I've introduced when I reworte the MB_I18N patch. Text rendering
> is now totatlly centralized in the libs.
>
> > typedef struct
> > {
> > colorset picture_colorset;
> > /* ... */
> > } render_picture_object;
> >
>
> If I well understand this is currently splited in two part(?)
> The colorset and its set background and relief rectangle functions.
> I imagine that the second part is the (mini-)icons, so we have
> the FvwmPicture and a small set of new libs functions to render
> FvwmPicture (or a set of pixmaps, eg. pixmap, mask and alpha) that
> I've introduced when I added XRender support. Unfortunately not all
> modules use FvwmPicture (and fvwm icons does not for maybe good
> reasons), however we are not so far from (mini-)icons rendering
> centralization.
>
> > typedef struct
> > {
> > render_text_object *text;
> > render_picture_object *picture;
> > } render_object;
> >
> > void render_gui_object_into_area(
> > Display *dpy, Drawable dest_d, XRectangle *dest_rect,
> > render_object *src_obj);
> >
>
>
> It is not totally clear for me that we should merge everything
> in one structure + one functions. The reason is flexibility.
> Anyway you can be sure that I take this direction.
Some day in the future I'd like to centralise the 'button' drawing
code. Most of the drawing in fvwm and the modules boils down to
drawing 'buttons' with a number of features:
- background image, colour or gradient
- text
- icon
- positioning of the background/foreground in the button
- raised, flat or sunken relief
- padding between relief and foreground
- transparency
- tinting
- alpha rendering
- ...
With the right structures and functions, all the drawing code can
be placed in fvwm or the library. What I really like about the
idea is that we could get rid of at l
Re: MenuStyle problem: menu style * is in use
On Mon, May 20, 2002 at 09:51:53PM +, Mikhael Goikhman wrote: > After any tear-off menu is created (and possibly closed), > "MenuStyle * something" refuses to work until restart: Hm. Of course it is in use. Making a copy of the whole menu style for each tear off menu seems to be overkill, though. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: gcc warnings
On Tue, May 21, 2002 at 09:30:12PM +0700, Dmitry Yu. Bolkhovityanov wrote: > On Tue, 21 May 2002, Dan Espen wrote: > > > > > I don't know if its just my compiler, > > but current CVS generates this warning: > > > > ../../fvwm2_5_2/fvwm/colorset.h:28:8: warning: extra tokens at end of > > #endif directive > > > > Too bad, it sure makes the #endif directive more readable. > > Maybe its my version of gcc, after all, the token is #defined to > > nothing. > > Usually it is enough to change from > > #endif TOKEN > > to > > #endif /* TOKEN */ Oops. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: MenuStyle problem: menu style * is in use
On Tue, May 21, 2002 at 01:49:21PM +, Mikhael Goikhman wrote: > On 21 May 2002 12:40:56 +0200, Dominik Vogt wrote: > > > > On Mon, May 20, 2002 at 09:51:53PM +, Mikhael Goikhman wrote: > > > After any tear-off menu is created (and possibly closed), > > > "MenuStyle * something" refuses to work until restart: > > > > Hm. Of course it is in use. Making a copy of the whole menu > > style for each tear off menu seems to be overkill, though. > > Why a menu style is in use after all tear-off menus are closed? > I.e. the question is why ST_USAGE_COUNT is not 0 in this case. Ah, I see. When the menu is torn off, the ST_USAGE_COUNT is decreased by 1 (to 0), but not increased again when the tear off menu is swallowed in the window frame. When it is finally closed, the usage count is decreased by another 1. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FvwmPager crashas
On Wed, May 22, 2002 at 11:12:41AM +0200, Giuseppe Della Ricca wrote: > Hi ! > > after the latest changes to FvwmPager.c > > * FvwmPager/FvwmPager.c (list_new_desk): > always display current desk in window title > > my FvwmPager randomly core dumps after desk switches. Is it fixed with my latest commit? Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Long pinup menus
On Tue, May 21, 2002 at 10:30:57AM -0400, Dan Espen wrote: > > I have a very long menu, its about 2 1/2 screens worth, > it has a "more..." leading to a "more...". > > If I pin up the first menu by clicking on the title with the > middle button, I get a frame and the "more..." line is > repeated twice. Both "more..." entries lead to the same > submenu, so I guess this is a bug. I'll check that. > I'm unable to pin up the submenu for the "more..." menu, > it has no title, so I don't see what to click on to > pin it up. The methods to pin menus still need some work in terms of usability. At the moment, the only reliable way to pin up a menu is by pressing backspace. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
