Subject: Style Closable/Unclosable

From: Marcus Lundblad <[email-masked]>
Date: Sat, 14 Dec 2002 14:16:50 +0100 (CET)

I'm implementing new styles to control allowed operations on windows.
Looked at the code in decorations.c (is_function_allowed) I see that the
MWM hint Close disables both Close and Destroy.
So I'm not quite sure what is the best thing to do: Follow this behavoiur
with the new style, implement an additional style or always permit
Destroy,
There is also a comment in the code: 
/* shouldn't destroy always be allowed?? */

Maybe that should be so, Destroy should always be possible.
Thought I would want to hear som opinions.

//Marcus

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

---

From: Dan Espen <[email-masked]>
Date: Sat, 14 Dec 2002 08:31:56 -0500

> Thought I would want to hear som opinions.

Destroy is still possible, thru keybindings, mousebindings,
and root context menus.

The source code for mwm is now downloadable.
I'd say whatever mwm does is the right thing to do.

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Marcus Lundblad <[email-masked]>
Date: Sat, 14 Dec 2002 14:49:01 +0100 (CET)

> Destroy is still possible, thru keybindings, mousebindings,

Is Destroy handled specifically when it's used?
As far as I can see the code in is_function_allowed is the same for
Close and Destroy:

case F_CLOSE:
	if (IS_TEAR_OFF_MENU(t))
	{
		/* always allow this on tear off menus */
		break;
	}
	if (!(functions & MWM_FUNC_CLOSE))
	{
		return False;
	}
	break;
case F_DESTROY: /* shouldn't destroy always be allowed??? */
	if (IS_TEAR_OFF_MENU(t))
	{
		/* always allow this on tear off menus */
		break;
	}
	if (!(functions & MWM_FUNC_CLOSE))
	{
		return False;
	}
	break;

If I've not missed anything (have got an hangover today... ^^ ), this
could be written as:

case F_CLOSE:
case F_DESTROY:
if (IS_TEAR_OFF_MENU(t))
        {
                /* always allow this on tear off menus */
                break;
        }
        if (!(functions & MWM_FUNC_CLOSE))
        {
                return False;
        }
        break;

Also I'm thinking about wether Style Unclosable should apply also for
tear-off menus. 
The argument in favour: The user has requested this
expliciltly through a style
The arguments against: It is incosistent with how hints are handled and
there is no other way to close it (what does destroy do on a tear-off,
kill fvwm?). 

> I'd say whatever mwm does is the right thing to do.

Yes, I guess this would be a good idea.

I will look at this when I get time. During the holidays I will visit my
parents, unfortunatly they only have Win2000....

//Marcus

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 14 Dec 2002 13:51:44 +0000

> Thought I would want to hear som opinions.

I too feel that a window should always be destroyable by fvwm just like
xkill does it. But there is another solution to this.

You didn't say what Closable should mean, but I would think this is a
user's setting to disable closing of some otherwise closable window.
So it should affect all Delete, Close and Destroy to be useful.

I think the problem of window operations disabled by hints or style may be
solved by introducing a new command/prefix Force (like Silent) that would
force Move/Resize/Iconify/Close otherwise disabled.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Sat, 14 Dec 2002 10:09:24 -0500

>         if (!(functions & MWM_FUNC_CLOSE))

Hmm, hangover, I'LL TRY NOT TO SHOUT!

Yep, its the same.

> there is no other way to close it (what does destroy do on a tear-off,

It only takes a second to try it.
(No it doesn't kill Fvwm.)

I don't know why we would need a Style Unclosable.
We have more direct methods of removing the close button
from a titlebar.  (I know it affect context menus too.)

I think the idea of the MWM hint, is that applications that didn't
implement the delete window protocol would set the hint.  This
was to encourage the user to use other means to close the window,
perhaps the file->close menu entry.
It all seems pretty pointless anyway, Fvwm can still apply close/delete
to the window.  I always thought it was more for appearance.

---

From: Marcus Lundblad <[email-masked]>
Date: Sat, 14 Dec 2002 16:25:35 +0100 (CET)

> Hmm, hangover, I'LL TRY NOT TO SHOUT!

Thanks! :)
> from a titlebar.  (I know it affect context menus too.)

Well, too late :-)
I already implemented (Un)Maximizable, (Un)Iconifiable (spelleing?),
(Un)Closable.
I also implemented  AllowMaximizeFixedSize/DisallowMaximizeFixedSize
if DisallowMaximizeFixedSize is on, if resize is not permitted then
maximize is automatically also disabled (in is_function_allowed).
AllowMaximizeFixedSize gives the default behaviour ie. maximize is allowed
unless turned off by hints or through the style option.

> to the window.  I always thought it was more for appearance.

Yes, I guess it's more for appearance.
But I found a use for Uniconifiable. When using the icon box, either I
have to turn on icon for the icon box

Style * NoIcon
Style FvwmIconBox Icon

or assign a special menu for the icon box window that lacks an iconify
entry.
In my opinion the Uniconifiable style is more clear than using special
functions. And even if you replace all Iconify in the config with a
complex function it's still possible to use an FvwmConsole.

And so for consistency I thought I might as well implement the others.
And I guess I'll trow in conditionals for these 3 aswell.

//Marcus