Javier Barroso | 2 Sep 09:57 2009
Picon

Control-C in xfce4-terminal

Hi,

Sometimes Control-C stop working in xfce4-terminal. I think this is a awesome issue, because when I was using xfce4 it didn't happen. And testing it with a new Xorg display it work fine.

I don't known exactly when it happens.

For example now I have 4 terminal opened and none of them is working with Control-C key. When I login into a server, it works fine until I return my host.

After closing 4 terminals, Control-C works again when I open a new.

When Control-C is lost ? How could I recover this usefull key combo in a terminal which is broken (reset command doesn't help)?

Anybody with the same symptoms?

Thank you

Julien Danjou | 2 Sep 10:01 2009

Re: Control-C in xfce4-terminal

At 1251878221 time_t, Javier Barroso wrote:
> Anybody with the same symptoms?

Did you try that latest version of awesome?

Cheers,
--

-- 
Julien Danjou
// ᐰ <julien <at> danjou.info>   http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
// This is the end of my signature.
Dominik Bruhn | 2 Sep 10:02 2009
Picon

Re: Control-C in xfce4-terminal

Hy,
I got the same problem some days ago. Updateing awesome (or one of its
libs) using "apt-get update/upgrade" and restarting fixed the issue for
me.

And yes: It's actually an awesome-fault: if you only start an terminal
(it doesnt depend on the terminal-app: xterm has the same problem)
without awesome everything works. As soon as you start awesome CTRL+C
stops from working.

Can anybody track this down? As I told I currently cant reproduce.

On Wed, Sep 02, 2009 at 09:57:01AM +0200, Javier Barroso wrote:
> Hi,
> 
> Sometimes Control-C stop working in xfce4-terminal. I think this is a
> awesome issue, because when I was using xfce4 it didn't happen. And testing
> it with a new Xorg display it work fine.
> 
> I don't known exactly when it happens.
> 
> For example now I have 4 terminal opened and none of them is working with
> Control-C key. When I login into a server, it works fine until I return my
> host.
> 
> After closing 4 terminals, Control-C works again when I open a new.
> 
> When Control-C is lost ? How could I recover this usefull key combo in a
> terminal which is broken (reset command doesn't help)?
> 
> Anybody with the same symptoms?
> 
> Thank you

--

-- 
Dominik Bruhn
mailto: dominik <at> dbruhn.de
Julien Danjou | 2 Sep 10:15 2009

Re: Control-C in xfce4-terminal

At 1251878536 time_t, Dominik Bruhn wrote:
> Can anybody track this down? As I told I currently cant reproduce.

Take a look on the changelog, it's rather clear:
http://awesome.naquadah.org/changelogs/v3.3.3

commit 47f3a4b3df2f1d31416331a675560596c70fdf09
Author: Uli Schlachter <psychon <at> znc.in>
Date:   Tue Aug 25 11:17:00 2009 +0200

    Clear the signal mask for child processes

    This adds a callback function which glib calls after it fork()'d and did all the
    necessary setup. This callback function clears our signal mask.

    This is necessary because libev 3.8 and later use signalfd and therefor have to
    add those signals to the signal mask. Processes started through awesome would
    inherit this signal mask and I can tell you, some app which ignores ctrl-c
    confuses people a lot.

    Signed-off-by: Uli Schlachter <psychon <at> znc.in>
    Signed-off-by: Julien Danjou <julien <at> danjou.info>

--

-- 
Julien Danjou
// ᐰ <julien <at> danjou.info>   http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
// I'm no superman.
Javier Barroso | 2 Sep 10:53 2009
Picon

Re: Control-C in xfce4-terminal

On Wed, Sep 2, 2009 at 10:01 AM, Julien Danjou <julien <at> danjou.info> wrote:
At 1251878221 time_t, Javier Barroso wrote:
> Anybody with the same symptoms?

Did you try that latest version of awesome?
Not the trunk. I'm in debian sid:


 $ dpkg -l awesome libev*
Desired=Unknown/Install/Remove/Purge/Hold
| Estado=No/Instalado/Config-files/Desempaquetado/Fallo-config/Medio-inst/espera-disparo/pendiente-disparo
|/ Err?=(ninguno)/Retenido/Requiere-reinst/X=ambos problemas (Estado,Err: mayúsc.=malo)
||/ Nombre                        Versión                      Descripción
+++-=============================-=============================-==========================================================================
ii  awesome                       3.3.3-2                       highly configurable, next generation framework window manager for X
ii  libev3                        1:3.8-1                       high-performance event loop library modelled after libevent
ii  libevent-1.4-2                1.4.12-stable-1               An asynchronous event notification library
ii  libevent1                     1.3e-3                        An asynchronous event notification library
ii  libevince1                    2.26.2-2                      Document (postscript, pdf) rendering library

So, reading your comment about libev3, should I open a debbug ?

Regards,
Alessandro Massignan | 2 Sep 11:21 2009
Picon

floating doubt

Hi all,

few days ago i give a chance to "awesome" because it really catches my
eyes :-), but
i have some problems/doubts with lua and awful library... Ehm, i
belong to the realm
of "newbieness" so prepare to flame ;-)
I try to set up a textbox to control mocp player and i wish to bind
the 2nd button
of my mice over it for spawning a xterm executing the player and i
wish to have it
as a floating xterm.
Is there a trick to do that over the awful call:

[...]
terminal = "xterm"
[...]
testwidget:buttons({
  [...]
  button({ }, 2, function () awful.util.spawn(terminal .. " -e mocp") end),
  [...]
})

? Or have i to set the terminal name and setup a rule that make the xterm float?
Thanks to the developer and community for that could be a great window manager
(let my doubts flow while i'm newbie ;-).

See you.
ff0000

Gregor Best | 2 Sep 11:36 2009
Picon

Re: floating doubt

The most usable approach would indeed be to set the terminal name (for
example to mocp_float) and to add a floatapps entry for it. On the other
hand, if you don't want to clutter your floatapps, you could set some
global variable to true before spawning the xterm. Then check in your
manage hook if that variable is true and if so, set the managed client
floating and the variable to false (i.e. something like
float_next_client or something). The first approach is much more sane
and error-proof though.

--

-- 
GCS/IT/M d- s+:- a-- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o--
K- w--- ?O M-- ?V PS++ PE- Y++ PGP+++ t+ 5 X+ R tv b+++ DI+++
D+++ G+ e h! r y+

    Gregor Best
Julien Danjou | 2 Sep 11:43 2009

Re: Control-C in xfce4-terminal

At 1251881588 time_t, Javier Barroso wrote:
> So, reading your comment about libev3, should I open a debbug ?

Well, it should work correctly with 3.3.3, so if you still have this
issue, there might be something else wrong.

Can you reproduce the problem with the default configuration?

--

-- 
Julien Danjou
// ᐰ <julien <at> danjou.info>   http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
// My root password is
Javier Barroso | 2 Sep 12:19 2009
Picon

Re: Control-C in xfce4-terminal

Hi,
On Wed, Sep 2, 2009 at 11:43 AM, Julien Danjou <julien <at> danjou.info> wrote:

At 1251881588 time_t, Javier Barroso wrote:
> So, reading your comment about libev3, should I open a debbug ?

Well, it should work correctly with 3.3.3, so if you still have this
issue, there might be something else wrong.

Can you reproduce the problem with the default configuration?
I'll try it. I tried it with other user and it seems like it works. Which config could have the cause?

Now I merged my config with the last rc.lua provided, my (significatives) changes were:

$ diff ~/.config/awesome/rc.lua.3.3.3-mio ~/.config/awesome/rc.lua
212c212
<     mytaglist[s] = awful.widget.taglist.new(s, awful.widget.taglist.label.all, mytaglist.buttons)
---
>     mytaglist[s] = awful.widget.taglist(s, awful.widget.taglist.label.all, mytaglist.buttons)
215,217c215,217
<     mytasklist[s] = awful.widget.tasklist.new(function(c)
<                                                   return awful.widget.tasklist.label.currenttags(c, s)
<                                               end, mytasklist.buttons)
---
>     mytasklist[s] = awful.widget.tasklist(function(c)
>                                               return awful.widget.tasklist.label.currenttags(c, s)
>                                           end, mytasklist.buttons)
336c336,337
<     table.foreach(awful.key({ modkey }, i,
---
>     globalkeys = awful.util.table.join(globalkeys,
>         awful.key({ modkey }, i,
342,343c343,344
<                   end), function(_, k) table.insert(globalkeys, k) end)
<     table.foreach(awful.key({ modkey, "Control" }, i,
---
>                   end),
>         awful.key({ modkey, "Control" }, i,
349,350c350,351
<                   end), function(_, k) table.insert(globalkeys, k) end)
<     table.foreach(awful.key({ modkey, "Shift" }, i,
---
>                   end),
>         awful.key({ modkey, "Shift" }, i,
355,356c356,357
<                   end), function(_, k) table.insert(globalkeys, k) end)
<     table.foreach(awful.key({ modkey, "Control", "Shift" }, i,
---
>                   end),
>         awful.key({ modkey, "Control", "Shift" }, i,
361,362c362,363
<                   end), function(_, k) table.insert(globalkeys, k) end)
<     table.foreach(awful.key({ modkey, "Shift" }, "F" .. i,
---
>                   end),
>         awful.key({ modkey, "Shift" }, "F" .. i,
370c371
<                    end), function(_, k) table.insert(globalkeys, k) end)
---
>                    end))
440c441
<     elseif floatapps[inst] then
---
>     elseif floatapps[inst] ~= nil then

I'm writting this because it if where possible these changes could fix the issue (I doubt it)

Regards,

Alessandro Massignan | 2 Sep 12:58 2009
Picon

Re: floating doubt

Hi Gregor,

> The most usable approach would indeed be to set the terminal name (for
> example to mocp_float) and to add a floatapps entry for it. On the other
> hand, if you don't want to clutter your floatapps, you could set some
> global variable to true before spawning the xterm. Then check in your
> manage hook if that variable is true and if so, set the managed client
> floating and the variable to false (i.e. something like
> float_next_client or something). The first approach is much more sane
> and error-proof though.
Mmmh... I give it a try... Another boring question, are floatapps' name
"string value matched" or through "pattern matching":

floatapps = {
  ...
  ["__FLOAT__"] = true,
  ...
}

If i spawn a "xterm -e mocp -n test__FLOAT__", will it be matching the
floatapps' rule (since it contains "__FLOAT__") or i have to spawn as
"xterm -e mocp -n __FLOAT__"?

Thanks a lot.
ff0000


Gmane