FVWM: Feature Request

2015-07-31 Thread Michelle Konzack
Hello *

long time ago, FVM supported # comments at the end of a line, but now,
lines like

Style * Title   # !Title
Style * TitleAtTop  # TitleAtLeft | TitleAtRight | 
TitleAtBottom
Style * LeftTitleRotatedCCW # LeftTitleRotatedCW
Style * RightTitleRotatedCW # RightTitleRotatedCCW
Style * TopTitleNotRotated  # TopTitleRotated
Style * BottomTitleNotRotated   # BottomTitleRotated
Style * !UseTitleDecorRotation  # UseTitleDecorRotation
Style * !StippledTitle  # StippledTitle
Style * !StippledIconTitle  # StippledIconTitle

produce errors of

Reading /home/michelle.konzack/.fvwm/Styles.d/02_WindowStyles.conf...
[fvwm][style_parse_and_set_window_style]: WARNING Unconsumed argument in 
Title  # !Title: # !Title
[fvwm][style_parse_and_set_window_style]: WARNING Unconsumed argument in 
TitleAtTop # TitleAtLeft | TitleAtRight | TitleAtBottom: # 
TitleAtLeft | TitleAtRight | TitleAtBottom
[fvwm][style_parse_and_set_window_style]: WARNING Unconsumed argument in 
LeftTitleRotatedCCW# LeftTitleRotatedCW: # LeftTitleRotatedCW
[fvwm][style_parse_and_set_window_style]: WARNING Unconsumed argument in 
RightTitleRotatedCW# RightTitleRotatedCCW: # 
RightTitleRotatedCCW
[fvwm][style_parse_and_set_window_style]: WARNING Unconsumed argument in 
TopTitleNotRotated # TopTitleRotated: # TopTitleRotated
[fvwm][style_parse_and_set_window_style]: WARNING Unconsumed argument in 
BottomTitleNotRotated  # BottomTitleRotated: # BottomTitleRotated
[fvwm][style_parse_and_set_window_style]: WARNING Unconsumed argument in 
!UseTitleDecorRotation # UseTitleDecorRotation: # 
UseTitleDecorRotation
[fvwm][style_parse_and_set_window_style]: WARNING Unconsumed argument in 
!StippledTitle # StippledTitle: # StippledTitle
[fvwm][style_parse_and_set_window_style]: WARNING Unconsumed argument in 
!StippledIconTitle # StippledIconTitle: # StippledIconTitle
[fvwm][style_parse_one_style_option]: ERROR Option: # is not valid with 
StartShaded
[fvwm][style_parse_and_set_window_style]: WARNING Unconsumed argument in 
!StartShaded   # StartShaded: StartShaded

which is not nice!

Can the # comment at the end of a Line re-introduced please?

Thanks
Michelle

-- 
Michelle KonzackITSystems
GNU/Linux Developer 0049-176-86004575



Re: FVWM: Feature request: desktop pages larger than the screen?

2005-10-01 Thread Zack Brown
On Sat, Oct 01, 2005 at 10:55:27AM +0200, Viktor Griph wrote:
 On Fri, 30 Sep 2005, Zack Brown wrote:
 I've confirmed that there is no way to control scrolling over an xorg 
 virtual
 desktop. If the mouse brushes the edge of the screen, you scroll. Period. 
 :-(
 
 So this too turns out not to solve my basic problem: How can I have
 over-maximized xterms, with the window decorations off the screen, without
 encroaching on neighboring pages?
 
 My sense here is just that it can't be done, and I'll be stuck with one of
 the suboptimal workarounds already suggested here. And I guess my 
 suggestion
 still stands, that FVWM implement some kind of control over the page-size,
 to decouple the page size and screen size.
 
 You can emulate most of the functionality you want with a proper fvwm 
 configuration. Sett the attached config as an example. It can of cource be 
 extended to do more things. Right now it defines a function 
 MaximizeFullScreen that Maximize a window to cover the entire screen and 
 not have borders. It then uses EdgeCommand to fake scrolling up to a 
 hidden title outside the screen at north edge, and scrolling down at the 
 south. It uses FvwmEvent to make sure nothing goes over to another page 
 after a page jump.

That's very impressive.

I may try that, but for now I seem to be having success with the
every-other-page approach.

Thanks for all the help. I now have pretty much everything I want:

1) very large desktop grid
2) oversized xterms that emulate text mode
3) one key Raise and Lower Pager
4) memory of the screen location on each desktop
5) automatic memory of xterm locations, directories, and running applications,
for instant restart after a crash

I'm pretty well fixed now. Thanks again!

Be well,
Zack

 
 Note that the config requires 2.5.14 or later for the use of the -x option 
 of FvwmPerl.
 
 /Viktor



-- 
Zack Brown



Re: FVWM: Feature request: desktop pages larger than the screen?

2005-09-30 Thread Zack Brown
On Thu, Sep 29, 2005 at 09:56:16PM +, Mikhael Goikhman wrote:
 On 29 Sep 2005 13:35:57 -0700, Zack Brown wrote:
  
  On Thu, Sep 29, 2005 at 04:53:35PM +, Mikhael Goikhman wrote:
   On 29 Sep 2005 09:04:06 -0700, Zack Brown wrote:

It would be nice to be able to specify the page size at startup. A lot
of folks run maximized xterms with no window decorations, just because
if they expanded the window to keep the decorations outside of the
screen, the decorations would encroach on neighboring pages. Having a
page size larger than the screen size would fix this.
   
   I think you simply want to have a command to switch a window
   into full-screen mode and back. Just use this:
   
 DestroyFunc FuncFvwmMaximizeFullScreen
 AddToFunc   FuncFvwmMaximizeFullScreen
 + I ThisWindow (Maximized) WindowStyle Title, Borders
 + I TestRc (!Match) WindowStyle !Title, !Borders
 + I TestRc (!Match) Raise
 + I TestRc (!Match) UpdateStyles
 + I Maximize ewmhiwa
   
 Key F11  A  SC  Pick FuncFvwmMaximizeFullScreen
  
  I considered this, but there are problems. For one thing, having maximized,
  borderless xterms right next to each other leaves no empty desktop area to 
  click
  in to call up a menu.
 
 This is not really a priblem, you may bind any mouse or keyboard action
 in W (client window). And if you prefer an empty desktop place, then
 do Maximize 100 95 or something like this.
 
  For another, a maximized xterm with no borders will extend
  slightly into the neighbording pages, which is ugly.
 
 This is not true, a maximized window fully fits one page only.
 In the case of a terminal (that defines a step-like resize) there will
 be usually a free space left even with Maximize 100, not the other way.
 
Variable page sizes would solve this problem elegantly.
   
   I don't think so.
  
  Can you give some reason? I don't see any drawback to variable-sized
  pages. It's just an elegant solution to any situation where you want
  portions of the window to extend beyond the edge of the screen, without
  encroaching on neighboring pages.
 
 I don't see how variable-sized pages may solve any problem at all.

They solve the problem of window decorations encroaching on neighboring pages.

 Do you also mean one page may be 800x600 and another 1200x900?
 Will sticky windows just disappear in the hole?

I don't mean that each page will have a variable size relative to each other
page. I mean that all pages will have the same size, but they will not have a
1-to-1 ratio with the screen.

So, I may have an 800x600 screen, and all my pages could be set to 830x630.

See? It's the same grid, no weird shapes in the grid, no bizarre twists. Just
the screen is a little smaller than each grid element.

 
 Please give concrete numbers, what is your resolution, what is your
 border width, title height, and what do you suggest for the page size.

So, I have my 800x600 screen in this hypothetical example. I set my page size to
830x630 in the FVWM config file. I also set my desktop to have 30x40 pages. And
I set myself to have 12 desktops.

Now I start up FVWM. The monitor goes to graphics mode. My background color pops
up. The pager pops up. I'm ready to use X.

I give the hotkey to pop up an xterm. The xterm pops up, black background, white
text. It is over-maximized, so the window decoration is outside the screen. I
start working on my favorite coding project.

Now I want to do a compile. I give the hotkey to go one page to the right. I
give the hotkey to create another xterm. this will be my compile window.

I start the compile going, and give the hotkey to go back to my coding page,
i.e. one page to the left.

Now I do more coding for awhile, but I want to check email. I give the hotkey to
flip over to desktop 3, where I usually do email. I create a new xterm and start
reading email.

Now I want to code again. I flip back to deskop 0, to the page I was at
previously. I keep coding.

You get the picture. I keep working in this fashion, creating one xterm per
page, in clusters of pages that represent a single project. Over time, and with
good organizational habits, I have 50 or so page clusters holding my ongoing
projects.

At some point I want to access the menus for this window. I press the mouse
against the top of the screen. The screen scrolls up slightly, exposing the
window decorations. These decorations do not encroach on the screen above
because the page size is big enough to accomodate them.

Now I click on one of the buttons in the window decoration, and make my
selection. Some operation is performed. I press the mouse against the bottom of
the screen, and the screen scrolls down, bringing me back to my full-screen
xterm.

I continue my work.

See? This is a nice, elegant way to work, made possible by page sizes that are
larger than the actual screen.

Be well,
Zack

 
 Regards,
 Mikhael.

-- 
Zack Brown



Re: FVWM: Feature request: desktop pages larger than the screen?

2005-09-30 Thread Dominik Vogt
On Fri, Sep 30, 2005 at 12:58:02PM -0700, Zack Brown wrote:
 On Fri, Sep 30, 2005 at 11:52:53AM +0200, Dominik Vogt wrote:
  On Thu, Sep 29, 2005 at 11:05:23PM -0700, Zack Brown wrote:
   
   So, I have my 800x600 screen in this hypothetical example. I set my page 
   size to
   830x630 in the FVWM config file.
  
  I think you want that virtual desktop size feature of X.  It does
  exactly what you describe without involving the window manager.
 
 You're right. That looks like exactly what I need. Thanks! Sorry for making
 unnecessary noise.
 
 So, I added a Virtual line in my xorg.config file, and it now gives me the
 extra space around my screen, where I can store window decorations and access
 the desktop background for menus and whatnot.
 
 The only problem is that now when my mouse bumps the edge of the screen,
 I get this smooth scrolling action that moves my screen off the window. Is
 there a way to change this, maybe tie it to FVWM's EdgeResistance? Once I
 start scrolling around the 'virtual' page, it's hard to recenter since the
 scrolling is so smooth. Is there a way to tie recentering to a keypress or
 something?

I honestly don't know.  The window manager does not have any part
in it, and I don't know where to start looking in the X.org
documentation.

Ciao

Dominik ^_^  ^_^

 --
Dominik Vogt, [EMAIL PROTECTED]


signature.asc
Description: Digital signature


FVWM: Feature request: desktop pages larger than the screen?

2005-09-29 Thread Zack Brown
Hi folks,

It would be nice to be able to specify the page size at startup. A lot of folks
run maximized xterms with no window decorations, just because if they expanded
the window to keep the decorations outside of the screen, the decorations would
encroach on neighboring pages. Having a page size larger than the screen size
would fix this.

There are other workarounds for this. You can define your own grid on the
desktop, where each grid element is the size you want, and you can use Scroll to
jump between them. When switching desktops (if you want the system to remember
where you were on each desktop), you can use a combination of GotoDeskAndPage,
and a complex Scroll calculation, to align yourself with your grid element. The
drawback of this is the complex calculations, and the fact that you have to
sacrifice much of Fvwm's navigational simplicity and do everything by hand.

Another workaround is to only use every other page on the desktop. Then your
decorations will only encroach on empty pages. You can Scroll + or - 200 to get
between used pages. This has other drawbacks, such as only making use of 1/4 of
the total number of pages. Also, the windows are so far apart in this case, that
it's impossible to scroll partway between them for a quick cut-and-paste from
one to the other.

Variable page sizes would solve this problem elegantly. Pages could be just
large enough to accomodate windows, decorations, and a small amount of
surrounding space. Every page on the desktop could be used; and at need it would
be possible to partially scroll between windows.

Be well,
Zack

-- 
Zack Brown



Re: FVWM: Feature request: desktop pages larger than the screen?

2005-09-29 Thread Zack Brown
On Thu, Sep 29, 2005 at 04:53:35PM +, Mikhael Goikhman wrote:
 On 29 Sep 2005 09:04:06 -0700, Zack Brown wrote:
  
  It would be nice to be able to specify the page size at startup. A lot
  of folks run maximized xterms with no window decorations, just because
  if they expanded the window to keep the decorations outside of the
  screen, the decorations would encroach on neighboring pages. Having a
  page size larger than the screen size would fix this.
 
 I think you simply want to have a command to switch a window
 into full-screen mode and back. Just use this:
 
   DestroyFunc FuncFvwmMaximizeFullScreen
   AddToFunc   FuncFvwmMaximizeFullScreen
   + I ThisWindow (Maximized) WindowStyle Title, Borders
   + I TestRc (!Match) WindowStyle !Title, !Borders
   + I TestRc (!Match) Raise
   + I TestRc (!Match) UpdateStyles
   + I Maximize ewmhiwa
 
   Key F11  A  SC  Pick FuncFvwmMaximizeFullScreen

I considered this, but there are problems. For one thing, having maximized,
borderless xterms right next to each other leaves no empty desktop area to click
in to call up a menu. For another, a maximized xterm with no borders will extend
slightly into the neighbording pages, which is ugly.

 
  Variable page sizes would solve this problem elegantly.
 
 I don't think so.

Can you give some reason? I don't see any drawback to variable-sized pages. It's
just an elegant solution to any situation where you want portions of the window
to extend beyond the edge of the screen, without encroaching on neighboring
pages.

Be well,
Zack

 
 Regards,
 Mikhael.

-- 
Zack Brown



FVWM: Feature request: display icon titles as tooltips.

2005-09-29 Thread Giovanni Tumiati

Hi all, I'd like to suggest / request a feature:

To allow icons to be displayed without their titles, and such that when 
the cursor is placed over an icon i.e. hovering to have the full title 
of the icon displayed - just like a tooltip.


This currently occurs  when placing the mouse cursor over the mini 
windows in the panels.


But as well, note that currently the default title of an icon is 
truncated to fit into the specified
icon size...however when the cursor *is* placed over icon, then the full 
title is displayed.

I'm suggesting to allow the suppression of the default truncated title.

Perhaps something like:
...
*FvwmIconBox: IconTitles Always | Never | Tooltip
...

where:
Always = current functionality
Never = always suppress icon titles
ToolTip = display titles only when mouse cursor hovers over icon.

Thanks.




Re: FVWM: Feature request: desktop pages larger than the screen?

2005-09-29 Thread Mikhael Goikhman
On 29 Sep 2005 13:35:57 -0700, Zack Brown wrote:
 
 On Thu, Sep 29, 2005 at 04:53:35PM +, Mikhael Goikhman wrote:
  On 29 Sep 2005 09:04:06 -0700, Zack Brown wrote:
   
   It would be nice to be able to specify the page size at startup. A lot
   of folks run maximized xterms with no window decorations, just because
   if they expanded the window to keep the decorations outside of the
   screen, the decorations would encroach on neighboring pages. Having a
   page size larger than the screen size would fix this.
  
  I think you simply want to have a command to switch a window
  into full-screen mode and back. Just use this:
  
DestroyFunc FuncFvwmMaximizeFullScreen
AddToFunc   FuncFvwmMaximizeFullScreen
+ I ThisWindow (Maximized) WindowStyle Title, Borders
+ I TestRc (!Match) WindowStyle !Title, !Borders
+ I TestRc (!Match) Raise
+ I TestRc (!Match) UpdateStyles
+ I Maximize ewmhiwa
  
Key F11  A  SC  Pick FuncFvwmMaximizeFullScreen
 
 I considered this, but there are problems. For one thing, having maximized,
 borderless xterms right next to each other leaves no empty desktop area to 
 click
 in to call up a menu.

This is not really a priblem, you may bind any mouse or keyboard action
in W (client window). And if you prefer an empty desktop place, then
do Maximize 100 95 or something like this.

 For another, a maximized xterm with no borders will extend
 slightly into the neighbording pages, which is ugly.

This is not true, a maximized window fully fits one page only.
In the case of a terminal (that defines a step-like resize) there will
be usually a free space left even with Maximize 100, not the other way.

   Variable page sizes would solve this problem elegantly.
  
  I don't think so.
 
 Can you give some reason? I don't see any drawback to variable-sized
 pages. It's just an elegant solution to any situation where you want
 portions of the window to extend beyond the edge of the screen, without
 encroaching on neighboring pages.

I don't see how variable-sized pages may solve any problem at all.
Do you also mean one page may be 800x600 and another 1200x900?
Will sticky windows just disappear in the hole?

Please give concrete numbers, what is your resolution, what is your
border width, title height, and what do you suggest for the page size.

Regards,
Mikhael.



Re: FVWM: Feature request: desktop pages larger than the screen?

2005-09-29 Thread Dan Espen
Zack Brown [EMAIL PROTECTED] writes:
   It would be nice to be able to specify the page size at startup. A lot
   of folks run maximized xterms with no window decorations, just because
   if they expanded the window to keep the decorations outside of the
   screen, the decorations would encroach on neighboring pages. Having a
   page size larger than the screen size would fix this.

If you don't want overlap, use desks, not pages.

-- 
Dan Espen   E-mail: [EMAIL PROTECTED]



Re: FVWM: Feature request: desktop pages larger than the screen?

2005-09-29 Thread Zack Brown
On Thu, Sep 29, 2005 at 06:58:21PM -0400, Dan Espen wrote:
 Zack Brown [EMAIL PROTECTED] writes:
It would be nice to be able to specify the page size at startup. A lot
of folks run maximized xterms with no window decorations, just because
if they expanded the window to keep the decorations outside of the
screen, the decorations would encroach on neighboring pages. Having a
page size larger than the screen size would fix this.
 
 If you don't want overlap, use desks, not pages.

But that would lose all the 2D navigation ability of having xterms in different
pages of a desktop.

Be well,
Zack

 
 -- 
 Dan Espen   E-mail: [EMAIL PROTECTED]

-- 
Zack Brown



FVWM: Feature request -- trap keys after focus change

2005-07-31 Thread felix
I am not sure if a window manager is the right place to do this, but I
thought I'd at least throw this out so the kind list readers can tell
me where it has already been suggested and why it wouldn't work the
way I hope :-)

One of the most annoying things about Mozilla / Firefox is the way it
will raise itself to the top when it has a new cookie to confirm, or a
trashwave plugin to be denied installation yet again.  I use focus
follows mouse, and it is intensely annoying to be typing in anything
else, form details, email in another program, shell command, whatever,
and suddenly find the last few keystrokes have gone to the popped up
window, especially if one of them happens to be ENTER or some other
action key.

Would it be possible to add a window manager configuration option to
trap keys and mouse clicks in the second or two (configurable) after a
focus change like this?  I think it only matters when a program
changes its own focus, either directly or indirectly.

It seems to me in my naivete that a window manager is an excellent
place to do this, but it also seems to me that it would be pretty
inefficient for X to route all keystrokes and button clicks thru the
window manager rather than directly to the app in question.  Is this
the kind of thing that could be done but at the loss of efficiency?

-- 
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
 Felix Finch: scarecrow repairman  rocket surgeon / [EMAIL PROTECTED]
  GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o



Re: FVWM: Feature request -- trap keys after focus change

2005-07-31 Thread Dominik Vogt
On Sun, Jul 31, 2005 at 12:55:51PM -0700, [EMAIL PROTECTED] wrote:
 I am not sure if a window manager is the right place to do this, but I
 thought I'd at least throw this out so the kind list readers can tell
 me where it has already been suggested and why it wouldn't work the
 way I hope :-)
 
 One of the most annoying things about Mozilla / Firefox is the way it
 will raise itself to the top when it has a new cookie to confirm, or a
 trashwave plugin to be denied installation yet again.  I use focus
 follows mouse, and it is intensely annoying to be typing in anything
 else, form details, email in another program, shell command, whatever,
 and suddenly find the last few keystrokes have gone to the popped up
 window, especially if one of them happens to be ENTER or some other
 action key.
 
 Would it be possible to add a window manager configuration option to
 trap keys and mouse clicks in the second or two (configurable) after a
 focus change like this?  I think it only matters when a program
 changes its own focus, either directly or indirectly.
 
 It seems to me in my naivete that a window manager is an excellent
 place to do this, but it also seems to me that it would be pretty
 inefficient for X to route all keystrokes and button clicks thru the
 window manager rather than directly to the app in question.  Is this
 the kind of thing that could be done but at the loss of efficiency?

What you need is already in fvwm.  Try

  Style * DontRaiseTransient, DontLowerTransient

to prevent dialog windows from being raised/lowered when the
transientfor window is raised or lowered.  Add

  Style * DontStackTransientParent

to prevent raising the transientfor window (i.e. the mozilla
main window) from being raised when a dialog pops up.  Use

  Style * GrabFocusTransientOff

to prevent dialog windows from stealing focus, or even

  Style Mozilla GrabFocusOff, GrabFocusTransientOff

to do the same for all mozilla windows, or even

  Style * GrabFocusOff, GrabFocusTransientOff

for *all* windows.  Finally, you may want to force all mozilla
windows and dialog windows on a separate page and not switch to
this page when they appear:

  Style Mozilla StartsOnPage 1 1, SkipMapping

Ciao

Dominik ^_^  ^_^

 --
Dominik Vogt, [EMAIL PROTECTED]


signature.asc
Description: Digital signature


FVWM: feature request (window cycling)

2004-10-05 Thread Andrew Dolgov

I've seen metacity and openbox recently and noted a feature which
would be (I think) nice to have in FVWM.

When you cycle windows in those WMs black empty frame is drawn showing
geometry of obscured windows.

FvwmProxy does something remotely like that, but does not visually show
window geometry. Maybe it is possible to hack FvwmProxy instead?

I suck at unix programming, so won't be able to write a patch, but maybe
this could be added into todo list or something? :)


-- 
Andrew   fox(at)madoka.spb.ru.

--
Visit the official FVWM web page at URL: http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm in the body of a
message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


Re: FVWM: [feature request] Double inset

2002-06-01 Thread Mikhael Goikhman
On 01 Jun 2002 23:39:41 +0200, Riswick, J.G.A. van wrote:
 
 I've been tweaking my fvwm setup and have been looking
 quite a lot at cde/motif. One thing I saw in that setup
 is a 'double inset' around the inner rim of the window
 border. With the current mwm border style, the client area
 of the window appears sunken relative to the title bar and
 window border. When a second inset, with reversed colors is
 displayed, the client area appears on the same level as the 
 title bar, ie 'raised'. This looks really good for 
 dialogs and other windows containing gui elements. Please
 compare the two dialogs in the image below, one without
 double inset, one with double inset:
 
 http://www.xs4all.nl/~josvanr/inset.png
 
 Maybe this would be a nice and not too difficult feature 
 to implement some time.

It is a function of a client window to draw the main area raised, lowered
or flat. Only client knows which shadow and higlight colors to use (based
on the background), FVWM has no any idea which colors to use for the
raised client effect.

Also a menu may be drawn even more raised by a toolkit.

  http://www.plig.org/xwinman/screenshots/dtwm-lally.gif

BTW, why don't you use border handles, real CDE has them. :)

Regards,
Mikhael.
--
Visit the official FVWM web page at URL: http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm in the body of a
message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


RE: FVWM: [feature request] Double inset

2002-06-01 Thread Riswick, J.G.A. van
 
HI!

(wow still working late..)

Yes I guess you are right, maybe I should look at the 
gtk-theme engine for doing this instead...

About the border handles, in cde, normal windows have them,
but popup dialogs don't. The image I referred to in my mail
was a screenshot (edited) from a cde session. Is there a way in fvwm
to give popup dialogs a different decoration?

regards

jos

-Original Message-
From: Mikhael Goikhman

It is a function of a client window to draw the main area raised,
lowered
or flat. Only client knows which shadow and higlight colors to use
(based
on the background), FVWM has no any idea which colors to use for the
raised client effect.

Also a menu may be drawn even more raised by a toolkit.

  http://www.plig.org/xwinman/screenshots/dtwm-lally.gif

BTW, why don't you use border handles, real CDE has them. :)

Regards,
Mikhael.

--
Visit the official FVWM web page at URL: http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm in the body of a
message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]


Re: FVWM: [feature request] Double inset

2002-06-01 Thread Mikhael Goikhman
On 02 Jun 2002 00:54:23 +0200, Riswick, J.G.A. van wrote:
 
 Yes I guess you are right, maybe I should look at the 
 gtk-theme engine for doing this instead...
 
 About the border handles, in cde, normal windows have them,
 but popup dialogs don't. The image I referred to in my mail
 was a screenshot (edited) from a cde session. Is there a way in fvwm
 to give popup dialogs a different decoration?

If you have Style * MwmFunctions (as opposite to NoFuncHint), windows
with the no-resize hint are automatically drawn without handles (like
with NoHandles).

Regards,
Mikhael.
--
Visit the official FVWM web page at URL: http://www.fvwm.org/.
To unsubscribe from the list, send unsubscribe fvwm in the body of a
message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]