New MenuStyle which forbids tear off
Hello, I want new MenuStyle which disables ability to tear off menu. Reason: because I have some dynamic menues like this: Mouse 3 IST A Menu winmenu +0m +0 DestroyMenu winmenu AddToMenu winmenu Window menu: Title + DynamicPopupAction Function MakeWinMenu DestroyFunc MakeWinMenu AddToFunc MakeWinMenu + I DestroyMenu recreate winmenu + I AddToMenu winmenu Window menu $[w.class]: Title + I ThisWindow (Shaded) + %menu-cbox_on.png%UnShade WindowShade + I TestRc (NoMatch) + %menu-cbox_off.png%Shade WindowShade ...skipped... When user tear offs such dynamic menu, menu items in it no longer working, because functions called without window context. I already coded a patch which adds MenuStyle 'AllowTearOff/!AllowTearOff' (feel free to offer another name for it) and I'll send it to the list if: - core developers agree that proposed functionality is useful - there are no other ways to solve described problem without this new MenuStyle. Best wishes -- Serge Koksharov, Free Software user supporter GPG public key ID: 0x3D330896 (pgp.mit.edu) Key fingerprint: 5BC4 0475 CB03 6A31 0076 82C2 C240 72F0 3D33 0896 pgpguHLUMK3ej.pgp Description: PGP signature
Re: New MenuStyle which forbids tear off
On 8/4/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, I want new MenuStyle which disables ability to tear off menu. Reason: because I have some dynamic menues like this: Mouse 3 IST A Menu winmenu +0m +0 DestroyMenu winmenu AddToMenu winmenu Window menu: Title + DynamicPopupAction Function MakeWinMenu DestroyFunc MakeWinMenu AddToFunc MakeWinMenu + I DestroyMenu recreate winmenu + I AddToMenu winmenu Window menu $[w.class]: Title + I ThisWindow (Shaded) + %menu-cbox_on.png%UnShade WindowShade + I TestRc (NoMatch) + %menu-cbox_off.png%Shade WindowShade ...skipped... When user tear offs such dynamic menu, menu items in it no longer working, because functions called without window context. I already coded a patch which adds MenuStyle 'AllowTearOff/!AllowTearOff' (feel free to offer another name for it) and I'll send it to the list if: - core developers agree that proposed functionality is useful I'm not a core dev, but I think this can be useful. On the other hand, the menu only tears off if you specifically ask it to. So unless the desktop is used by someone else, I guess I can live with just not tearing it off in the first place :) - there are no other ways to solve described problem without this new MenuStyle. Cheers Renato Best wishes -- Serge Koksharov, Free Software user supporter GPG public key ID: 0x3D330896 (pgp.mit.edu) Key fingerprint: 5BC4 0475 CB03 6A31 0076 82C2 C240 72F0 3D33 0896
CVS renato: Added the notice that the ! is prefered in the MenuStyle command.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: renato 06/07/25 05:36:23 Modified files: . : ChangeLog fvwm : fvwm.1.in Log message: Added the notice that the ! is prefered in the MenuStyle command. Created a centralized list of deprecated negative commands.
Where did the MenuStyle ActiveBack go?
Hello. I found this unusual thing in the manual. There is a reference to ActiveBack/ActiveBackOff all over the place, but aparently the style doesn't exist any more. It is not documented at all, nor is mentioned in (both) the ChangeLogs.. Not even in any part of the source code. Is there a replacement for it? Should I just delete the references? What now? Cheers Renato PS: Sounds like it was silenced by fvwm secret services ;)
Re: Where did the MenuStyle ActiveBack go?
I found this unusual thing in the manual. There is a reference to ActiveBack/ActiveBackOff all over the place, but aparently the style doesn't exist any more. It is not documented at all, nor is mentioned in (both) the ChangeLogs.. Not even in any part of the source code. Is there a replacement for it? Should I just delete the references? What now? Ah, It's a relic of the patch splitting AftiveFore and HilightBack. I probably thought about renaming HilightBack, but gave up the idea in favour of the ActiveColorset option. It's safe to remove it from the man page (or replace it with HighlightBack where appropriate). Ciao Dominik ^_^ ^_^ -- Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit! Feel free mit GMX DSL: http://www.gmx.net/de/go/dsl
Re: Where did the MenuStyle ActiveBack go?
On 7/25/06, Dominik Vogt [EMAIL PROTECTED] wrote: I found this unusual thing in the manual. There is a reference to ActiveBack/ActiveBackOff all over the place, but aparently the style doesn't exist any more. It is not documented at all, nor is mentioned in (both) the ChangeLogs.. Not even in any part of the source code. Is there a replacement for it? Should I just delete the references? What now? Ah, It's a relic of the patch splitting AftiveFore and HilightBack. I probably thought about renaming HilightBack, but gave up the idea in favour of the ActiveColorset option. It's safe to remove it from the man page (or replace it with HighlightBack where appropriate). Done. It had already been replaced by HilightBack, except the old ActiveBack was also there. Cheers Renato Ciao Dominik ^_^ ^_^ -- Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit! Feel free mit GMX DSL: http://www.gmx.net/de/go/dsl
CVS renato: Created a ! flag explanation in Style similar to the one in MenuStyle
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: renato 06/07/25 09:24:00 Modified files: . : ChangeLog fvwm : fvwm.1.in Log message: Created a ! flag explanation in Style similar to the one in MenuStyle Moved the deprecated reference of some styles to a centralized place (NoTitle, StippledTitleOff, NoHandles,NoButton, NoIconTitle) Removed the ActiveBack relics from the man page
Re: CVS renato: Created a ! flag explanation in Style similar to the one in MenuStyle
On 7/25/06, FVWM CVS fvwm-workers@fvwm.org wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: renato 06/07/25 09:24:00 Modified files: . : ChangeLog fvwm : fvwm.1.in Log message: Created a ! flag explanation in Style similar to the one in MenuStyle Moved the deprecated reference of some styles to a centralized place (NoTitle, StippledTitleOff, NoHandles,NoButton, NoIconTitle) Oops.. Looks like I did a mess with these changes above. I'll revert them for now, and review them as soon as I can. Cheers renato Removed the ActiveBack relics from the man page
MenuStyle options - negate or not to negate?
Hi. Some of the MenuStyle (an maybe Style too) options don't have a negative form on the man page. But the truth is that some can be negated. So in order to unify the whole thing, what should be done to those? Should we add the negative forms to the man page to the ones missing, or should we remove them from the ones which have a !* negation form? Example: MouseWheel TrianglesUseFore / !TrianglesUseFore should become MouseWheel / !MouseWheel TrianglesUseFore / !TrianglesUseFore or MouseWheel TrianglesUseFore ? Let us consider now that the way to negate the styles is now explained on the man page. Opinions? Renato Caldas
Re: MenuStyle options - negate or not to negate?
On Fri, Jul 21, 2006 at 03:56:00PM +0100, seventh guardian wrote: Hi. Some of the MenuStyle (an maybe Style too) options don't have a negative form on the man page. But the truth is that some can be negated. So in order to unify the whole thing, what should be done to those? Should we add the negative forms to the man page to the ones missing, or should we remove them from the ones which have a !* negation form? Example: MouseWheel TrianglesUseFore / !TrianglesUseFore should become MouseWheel / !MouseWheel TrianglesUseFore / !TrianglesUseFore This is the right decision. or MouseWheel TrianglesUseFore Nope. Let us consider now that the way to negate the styles is now explained on the man page. Note that there are many more styles and options that could have a !-negation, bui I don't want to tackle them now. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Added SkipSection MenuStyle option.
This is a rather esoteric patch, but one of the things I disliked about
the current menu behaviour is that pressing Ctrl-Tab on a menu would
jumpt to the next section delimited via separators. I wanted to turn
this feature off, which I've now done by adding: SkipSection /
!SkipSection menustyle options.
Please find the patch enclosed, it's patched against CVS. I apologise
slightly for not using 'cvs diff' for most of the patches I write -- but
for very small things like this, I find going down the .orig route
easier.
-- Thomas Adam
--
If I were a witch's hat, sitting on her head like a paraffin stove, I'd
fly away and be a bat. -- Incredible String Band.
--- ./menustyle.c.orig 2006-02-09 11:49:33.0 +
+++ ./menustyle.c 2006-07-21 18:29:22.0 +0100
@@ -396,6 +396,7 @@
PopupActiveArea,
PopupIgnore, PopupClose,
MouseWheel, ScrollOffPage,
+ SkipSection,
TrianglesUseFore,
TitleColorset, HilightTitleBack,
TitleFont,
@@ -1479,11 +1480,14 @@
case 57: /* ScrollOffPage */
ST_SCROLL_OFF_PAGE(tmpms) = on;
break;
-
- case 58: /* TrianglesUseFore */
+ case 58:
+ /* SkipSection */
+ ST_SKIP_SECTION(tmpms) = on;
+ break;
+ case 59: /* TrianglesUseFore */
ST_TRIANGLES_USE_FORE(tmpms) = on;
break;
- case 59: /* TitleColorset */
+ case 60: /* TitleColorset */
if (GetIntegerArguments(args, NULL, val, 1) == 0 ||
*val 0)
{
@@ -1498,11 +1502,11 @@
}
has_gc_changed = True;
break;
- case 60: /* TitleHilightBack */
+ case 61: /* TitleHilightBack */
ST_DO_HILIGHT_TITLE_BACK(tmpms) = on;
has_gc_changed = True;
break;
- case 61: /* TitleFont */
+ case 62: /* TitleFont */
if (arg1 != NULL
!(new_font = FlocaleLoadFont(dpy, arg1, FVWM)))
{
@@ -1529,8 +1533,6 @@
}
has_gc_changed = True;
break;
-
-
#if 0
case 99: /* PositionHints */
/* to be implemented */
--- ./menustyle.h.orig 2006-02-09 11:49:33.0 +
+++ ./menustyle.h 2006-07-21 18:01:06.0 +0100
@@ -129,6 +129,8 @@
/* feel */
#define ST_IS_ANIMATED(s) ((s)-feel.flags.is_animated)
#define MST_IS_ANIMATED(m)((m)-s-ms-feel.flags.is_animated)
+#define ST_SKIP_SECTION(s) ((s)-feel.flags.skip_section)
+#define MST_SKIP_SECTION(m) ((m)-s-ms-feel.flags.skip_section)
#define ST_DO_POPUP_IMMEDIATELY(s)((s)-feel.flags.do_popup_immediately)
#define MST_DO_POPUP_IMMEDIATELY(m)\
((m)-s-ms-feel.flags.do_popup_immediately)
@@ -217,6 +219,7 @@
unsigned use_automatic_hotkeys : 1;
unsigned mouse_wheel : 2;
unsigned scroll_off_page : 1;
+ unsigned skip_section : 1;
} flags;
int PopdownDelay10ms;
int PopupOffsetPercent;
--- ./menus.c.orig 2006-03-27 21:29:19.0 +0100
+++ ./menus.c 2006-07-21 18:40:33.0 +0100
@@ -1110,7 +1110,13 @@
break;
case 2:
/* ctrl-tab */
- fSkipSection = True;
+ /* Negatable via the !SkipSection style flag */
+ if (!MST_SKIP_SECTION(mr))
+ {
+ fSkipSection = True;
+ } else {
+ fSkipSection = False;
+ }
break;
case 3:
/* ctrl-meta-tab */
--- ./fvwm.1.in.orig2006-07-21 19:15:27.0 +0100
+++ ./fvwm.1.in 2006-07-21 19:05:49.0 +0100
@@ -3514,6 +3514,12 @@
.I !ScrollOffPage
disables this behaviour.
+.I SkipSection
+removes the ability to have the first item of each section (when using
+menus separators) to be selected when pressing Ctrl-Tab on a menu.
+.I !SkipSection
+enables this behaviour.
+
.I TrianglesUseFore
draws sub menu triangles with the foreground color of the menu colorset
(normally drawn with the hilight color).
Re: MenuStyle options - negate or not to negate?
On 7/21/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Fri, Jul 21, 2006 at 03:56:00PM +0100, seventh guardian wrote: Hi. Some of the MenuStyle (an maybe Style too) options don't have a negative form on the man page. But the truth is that some can be negated. So in order to unify the whole thing, what should be done to those? Should we add the negative forms to the man page to the ones missing, or should we remove them from the ones which have a !* negation form? Example: MouseWheel TrianglesUseFore / !TrianglesUseFore should become MouseWheel / !MouseWheel TrianglesUseFore / !TrianglesUseFore This is the right decision. Great :) As soon as we agree on the ! notice on the man page I'll do this. One thing at a time :) or MouseWheel TrianglesUseFore Nope. Let us consider now that the way to negate the styles is now explained on the man page. Note that there are many more styles and options that could have a !-negation, bui I don't want to tackle them now. Ok. My new proposal accounts for this. Cheers Renato Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEwQ1RmeSprTOr4tgRAt/MAJ9+9tRrSI8uafiuIffHJvGQrBKzQwCeOZhW G/MlmWG1JgXJ1+BuGsEW1PU= =dK69 -END PGP SIGNATURE-
CVS domivogt: * Fixed copying of TitleColorset menustyle.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/07/17 15:24:29 Modified files: . : ChangeLog fvwm : menustyle.c Log message: * Fixed copying of TitleColorset menustyle.
Re: MenuStyle ActiveColorset and the need of HilightBack/ActiveFore
On Wed, Jan 18, 2006 at 10:45:08AM +0100, Viktor Griph wrote: On Wed, 18 Jan 2006, Viktor Griph wrote: Hi When using the ActiveColorset menustyle, you also have to specify HiglightBack and/or ActiveFore (without arguments) in order to make the style use the colorset. Just using ActiveAcolorset has no effect what-so-ever. I think it would be good to make ActivColorset imply ST_DO_HILIGHT_FORE and ST_DO_HILIGHT_BACK. I don't think many users use a colorset, of which they only want to use one (or no) color. By leaving the ability to turn off the use of the colors the current behaviour could be restored with a minor addition to a config file. Alternatively one could make ActiveCColorset imply ST_DO_HILIGHT_FORE and ST_DO_HILIGHT_BACK as long as none of those stiles have been used, which would only change behaviour for the few users that have an active colorset not used at the cost of one extra bit per menustyle. Ok, I just realized why HilightBack can't be on by default, so I guess I'll have to withdraw my opinion. Yeah, if I had the chance to write all the menu styles from scratch, I'd do it in a different way. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
CVS griph: applied patch by Malcolm Still adding TrianglesUseFore MenuStyle option.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 05/12/21 04:05:33 Modified files: . : AUTHORS ChangeLog NEWS fvwm : fvwm.1.in menuitem.c menustyle.c menustyle.h Log message: applied patch by Malcolm Still adding TrianglesUseFore MenuStyle option.
Re: MenuStyle
On Thu, Oct 20, 2005 at 07:42:36AM +0200, Viktor Griph wrote:
Hi
I am looking into the MenuStyle code trying to understand how some things
are done. I plan to enable negation of all on/off menu styles by prefixing
! to them. However looking at the code raise some questions:
First of all what exactly does FreeColors free up?
In certain modes, X colours are managed in so called colour cells.
There may be a limited number of available cells. They are
reserved with XAllocColor and freed with XFreeColor. Because
colours are used in many places inside fvwm (colour sets!), fvwm
keeps a reference counter for the allocated colours. The
corresponding code may be a bit difficult to understand
(libs/PictureUtils.c).
FreeColors eventually decreases the reference counters and frees
the cells if the reference count drops to 0. Actually the process
is more complicated. I think Olivier has written most of the
code.
Answering this might
answe some of my other questions; at least if it has some special
functionality.
Second: The styles HilightBack and ActiveFore do free the colors if the
style have them. Howver the corresponding off-styles does not free them.
Is there any reason for this?
No, it's a bug. Both must free these colours also. Note that
nobody ever actually tested the code to free colours. I'm sure
fvwm still has many colour leaks.
Last: This can't be right can it?:
-- from menustyle.c: menustyle_copy
/* HilightBack */
if (ST_HAS_ACTIVE_BACK(destms))
{
FreeColors(ST_MENU_ACTIVE_COLORS(destms).back, 1, True);
}
ST_HAS_ACTIVE_BACK(destms) = ST_HAS_ACTIVE_BACK(origms);
memcpy(ST_MENU_ACTIVE_COLORS(destms),
ST_MENU_ACTIVE_COLORS(origms), sizeof(ColorPair));
ST_DO_HILIGHT_BACK(destms) = ST_DO_HILIGHT_BACK(origms);
/* ActiveFore */
if (ST_HAS_ACTIVE_FORE(destms))
{
FreeColors(ST_MENU_ACTIVE_COLORS(destms).fore, 1, True);
}
--
It looks to me as it frees the active fore color after having it copied
over, thus freeing the source's color instead of the overwritten.
Yes, without checking what the ST_MENU_ACTIVE_COLORS actually are,
I think you're right.
Furthermore I think the colour reference counts have to be
increased when a menustyle is copied. Consider this:
* Menustyle A has a colour x with reference count 1.
* Copy menustyle A to some other menustyle B. x still has a
reference count of 1.
* Copy A over b again. The reference count of x is decreased to
0 and never increased again. Ouch.
We should have a CopyColor function somewhere in PictureUtils.c
that takes care of this situation, e.g.
CopyColor(
sometype* dest_color, sometype* src_color,
int do_free_dest_color);
(where do_free_dest_color indicates whether the destination
colour should be freed).
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: MenuStyle
On Thu, Oct 20, 2005 at 11:06:36AM +0200, Dominik Vogt wrote: On Thu, Oct 20, 2005 at 07:42:36AM +0200, Viktor Griph wrote: Hi I am looking into the MenuStyle code trying to understand how some things are done. I plan to enable negation of all on/off menu styles by prefixing ! to them. However looking at the code raise some questions: First of all what exactly does FreeColors free up? In certain modes, X colours are managed in so called colour cells. There may be a limited number of available cells. They are reserved with XAllocColor and freed with XFreeColor. Because colours are used in many places inside fvwm (colour sets!), fvwm keeps a reference counter for the allocated colours. The corresponding code may be a bit difficult to understand (libs/PictureUtils.c). FreeColors eventually decreases the reference counters and frees the cells if the reference count drops to 0. Actually the process is more complicated. I think Olivier has written most of the code. Yes, the code is complex. It allows, in particular, to save in a fast way the allocated pixels for an image or a gradient with minimal memory usage. Before that, colours leak was systematic with gradients and images. Any way, colours management (sharing) at depth 8 is a mess in the X world, I discourage any one to try to understand the problems :o) Note that we do not receive complaint anymore on colours at depth 8 on fvwm-users. Maybe, no body have to use anymore these applications which need depth 8 to work properly. Olivier
Re: MenuStyle
On Thu, 20 Oct 2005, Dominik Vogt wrote:
On Thu, Oct 20, 2005 at 07:42:36AM +0200, Viktor Griph wrote:
Hi
I am looking into the MenuStyle code trying to understand how some things
are done. I plan to enable negation of all on/off menu styles by prefixing
! to them. However looking at the code raise some questions:
First of all what exactly does FreeColors free up?
In certain modes, X colours are managed in so called colour cells.
There may be a limited number of available cells. They are
reserved with XAllocColor and freed with XFreeColor. Because
colours are used in many places inside fvwm (colour sets!), fvwm
keeps a reference counter for the allocated colours. The
corresponding code may be a bit difficult to understand
(libs/PictureUtils.c).
FreeColors eventually decreases the reference counters and frees
the cells if the reference count drops to 0. Actually the process
is more complicated. I think Olivier has written most of the
code.
Answering this might
answe some of my other questions; at least if it has some special
functionality.
Second: The styles HilightBack and ActiveFore do free the colors if the
style have them. Howver the corresponding off-styles does not free them.
Is there any reason for this?
No, it's a bug. Both must free these colours also. Note that
nobody ever actually tested the code to free colours. I'm sure
fvwm still has many colour leaks.
Last: This can't be right can it?:
-- from menustyle.c: menustyle_copy
/* HilightBack */
if (ST_HAS_ACTIVE_BACK(destms))
{
FreeColors(ST_MENU_ACTIVE_COLORS(destms).back, 1, True);
}
ST_HAS_ACTIVE_BACK(destms) = ST_HAS_ACTIVE_BACK(origms);
memcpy(ST_MENU_ACTIVE_COLORS(destms),
ST_MENU_ACTIVE_COLORS(origms), sizeof(ColorPair));
ST_DO_HILIGHT_BACK(destms) = ST_DO_HILIGHT_BACK(origms);
/* ActiveFore */
if (ST_HAS_ACTIVE_FORE(destms))
{
FreeColors(ST_MENU_ACTIVE_COLORS(destms).fore, 1, True);
}
--
It looks to me as it frees the active fore color after having it copied
over, thus freeing the source's color instead of the overwritten.
Yes, without checking what the ST_MENU_ACTIVE_COLORS actually are,
I think you're right.
Furthermore I think the colour reference counts have to be
increased when a menustyle is copied. Consider this:
* Menustyle A has a colour x with reference count 1.
* Copy menustyle A to some other menustyle B. x still has a
reference count of 1.
* Copy A over b again. The reference count of x is decreased to
0 and never increased again. Ouch.
We should have a CopyColor function somewhere in PictureUtils.c
that takes care of this situation, e.g.
CopyColor(
sometype* dest_color, sometype* src_color,
int do_free_dest_color);
(where do_free_dest_color indicates whether the destination
colour should be freed).
I found Pixel fvwmlib_clone_color(Pixel p) in ColorUtils.c which can be
used to reallocate a color. With that creating a CopyColor function is no
problem.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
New MenuStyle options
Hello, The first patch I send (menustyle_options.patch.gz) adds four new options for menus: CaseSensitiveHotkeys, CaseSensitiveHotkeysOff, HotkeysRunConfirmation and HotkeysRunConfirmationOff. CaseSensitive ones are to make hot-key feature see the difference between upper and lowercase letters. The last two options allow instructing fvwm to wait for key press or mouse click before executing selected command (popups are not affected). Since I don't know the fvwm code really well, I read changes associated with AutomaticHotkeys options and put mine in the same places. I'm not sure if I did it right, so I'd be glad if someone could read and comment my work. The second patch is definitelly not a ready-to-apply one. I send it just to show the concept. The idea is to add the cursor position limits to EdgeCommand. If the pointer is within them apropriate function is run, if not everything stays normal (ex. the EdgeScroll can still be enabled). I use GetIntegerArguments insted of GetSuffixedIntegerArguments and probably there are other problems with it. But before making it usable I wanted to ask if there is a need for something like that. BTW is there any prefered coding style? I tried to stay consistent with the code I was changing but it is difficult sometimes. Regards, -- Marcin Pawlik menustyle_options.patch.gz Description: Binary data edge_command.patch.gz Description: Binary data
Re: ActiveColorset in MenuStyle does not work properly
On 06 Jun 2002 23:17:47 -0500, [EMAIL PROTECTED] wrote: Message summary for PR#894 From: [EMAIL PROTECTED] Subject: ActiveColorset in MenuStyle does not work properly I am running Debian unstable, fvwm-2.4.7-2. I am trying to update my config file to use colorsets; everything else works great, but ActiveColorset (via MenuStyle does not work). Using the following .fvwm2rc lines: MenuStyle * MenuColorset 7 MenuStyle * ActiveColorset 2 I pop up a menu and mouse over some of the items. The hilighting (that is, the borders) of the active menu item correctly uses the background color from Colorset 2; the text color is the foreground color of Colorset 2. The background color of the active menu item is the background color of Colorset 7. It works without problems for me. What is your colorset 2 definition? A non-solid background (Pixmap, ?Gradient) can't be used with ActiveColorset (only with MenuColorset, because this is not implemented), but a solid color (bg) definitely works. If you don't specify bg, the default gray is used. There are minor glitches in 2.4.x, but not something that you normally notice unless you completely redefine ItemFormat. Regards, Mikhael. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: ActiveColorset in MenuStyle does not work properly
On 07 Jun 2002 08:09:49 -0500, [EMAIL PROTECTED] wrote: It works without problems for me. What is your colorset 2 definition? Well, ok, you should specify: Style * HilightBack HilightBackOff will give the effect you describe. Specifying MenuStyle * ActiveColorset 2 MenuStyle * HilightBack seems to work properly (HilightBackOff does not work). This seems vaguely unintuitive--although it *is* documented in the manual (doh!). Was there a reason for this choice? HilightBack was introduced long before colorsets were invented. MenuStyle fvwm (this is a default) and mwm both imply HilightBackOff. I didn't worried about this, because for ages we have MenuStyle * MenuFace, ActiveFore, HilightBack hardcoded in fvwm-themes, so menu colorsets are fully respected. But it probably makes sence for ActiveColorset to imply HilightBack and probably ActiveFore, and for MenuColorset to imply MenuFace. I will not change this though. If Dominik agrees he may do this. My opinion is to remove these 3 options in the future anyway. Regards, Mikhael. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: 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 URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: 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. 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 URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: 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 URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: MenuStyle problem: menu style * is in use
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. Regards, Mikhael. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
MenuStyle problem: menu style * is in use
After any tear-off menu is created (and possibly closed), MenuStyle * something refuses to work until restart: [FVWM][NewMenuStyle]: ERROR menu style * is in use Regards, Mikhael. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: core dump in MenuStyle
Fixed, Olivier -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: core dump in MenuStyle
On Mon, Feb 11, 2002 at 05:36:04PM +, Mikhael Goikhman wrote: When trying http://problemlos.ch/tmp/fvwm2rc with the current cvs: The core dump is caused by the new multibyte code. I will take a look on this soon. Do you use --enable-multibyte? Olivier -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Default MenuStyle also resets colour sets.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/08/13 07:25:27 Modified files: . : ChangeLog libs : defaults.h modules: ChangeLog modules/FvwmTheme: FvwmTheme.1 Log message: * Default MenuStyle also resets colour sets. * Typo fix in FvwmTheme man page. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
