On Thu, Oct 7, 2010 at 5:16 PM, Benjamin R. Haskell
<[email protected]> wrote:
> On Thu, 7 Oct 2010, Mihai Basa wrote:
>>
>> On Thu, Oct 7, 2010 at 3:01 PM, Thomas Adam wrote:
>>>
>>> On 7 October 2010 14:55, Mihai Basa wrote:
>>>>
>>>> On Wed, Oct 6, 2010 at 9:21 PM, Marc Lehmann wrote:
>>>>>
>>>>> Any function that you want to apply to random windows should go into
>>>>> the wm. that's what it is for - managing windows.
>>>>
>>>> No WM is wise enough to know whether the window you are closing has any
>>>> data to lose. Is it just a desktop calculator, or are you writing your
>>>> thesis there? The WM doesn't know. The application does, and it's the one
>>>> that should ask for confirmation before discarding user data.
>>>
>>> Point of principal. I can't believe I'm having to go off-topic here, but
>>> FVWM has a FvwmEvent module which allows you to trap XEvents, which will
>>> allow you to run xmessage or some other program to first make you sure you
>>> *really* mean to close this program. Likewise, there is also the
>>> "!Closable" style condition. No, I am not intereted in WM wars here -- I am
>>> proving to you that the responsibility really *is* at the WM level.
>>
>> If you are "proving" this to me why did you pick FVWM for your example? Is
>> it maybe because you don't know of any other major window manager that has
>> this feature? What would you say *that* proves?
>
> Just because GNOME and KDE don't have this doesn't make it unreasonable to
> expect the WM to handle it. "Major" WMs don't really do much to "manage"
> windows.
>
>
>>> Whining for it here isn't going to help you -- you could have since gone
>>> away and invested the time adding such functionality into evilwm.
>>>
>>> -- Thomas Adam
>>
>> I asked for pointers on how to implement this myself from the very
>> beginning. If asking for help on contributing to the project and arguing my
>> position is considered "whining", then going away is exactly what I'll do.
>
> If you can ignore the hostility with which most suggestions are met on the
> rxvt-unicode list, it's actually quite nice. Generally the backlash has
> reason behind it. And for this particular feature, it seems like there's
> about a 0% chance of getting this into the official version.
>
> In any case, if you really want the misfeature, the documentation for the
> on_destroy Perl hook seems to indicate that returning a true value will
> treat the event as 'consumed'. But, a quick test, adding this to an
> existing plugin of mine:
>
> sub on_destroy { 1 }
>
> Seems to indicate that it doesn't work. (Adding a print to a file shows
> that it's getting called, but the boolean-true return value doesn't seem to
> matter.)
>
> Regardless, even if you don't handle it at the WM level, it still seems
> easier to handle at a level higher than urxvt. Right now you want this
> feature in urxvt, next you'll want it in some other program, slippery slope,
> yada yada. If you instead write some program to wrap an arbitrary program
> window in this way (urxvt supports XEmbed), you'd be better off.
>
> --
> Best,
> Ben
Thanks Ben! I think this is exactly the kind of insight I was hoping
for. I looked into the perl hooks, and modified the tabbed extension
somewhat in the sense that you suggested. It does work! Instead of
capturing on_destroy, though, I commented out the destroy call in
on_wm_delete_window:
sub on_wm_delete_window {
my ($self) = @_;
#$_->destroy for @{ $self->{tabs} };
1
}
Urxvt now only closes only when all tabs exit, which is perfect from
my point of view. It's more hackish than I wished for, but seeing that
something more integrated is not considered a useful feature I will
leave it as is.
Thanks again.
Mihai
_______________________________________________
rxvt-unicode mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
