Some features from Ion?

Re: Some features from Ion?

hi,
> The first impressions are positive, but I miss some handy features from Ion,
> mainly the actions bound under the F keys:
> 
> F1 - query for a manpage to show in a $TERMINAL via $PAGER
> F3 - query for a program to run
> F4 - query for a host to ssh to
> 
> Is there any way to achieve this in awesome without having to run a new
> terminal and then typing the command?

I use dmenu from the dwm project for such issues.

Regards
Daniel

Re: Some features from Ion?

On Dec 1, 2007 4:30 AM, <daniel-iyk/aG80cdUb1SvskN2V4Q@public.gmane.org> wrote:

I use dmenu from the dwm project for such issues.

Thanks!

I had always skipped dmenu because from its description I never figured out how it could be useful to me. After your comment I gave it a try and with a bit of scripting it does all I want.

Frank

Re: Some features from Ion?

At 1196512233 time_t, daniel@... wrote:
> I use dmenu from the dwm project for such issues.

And for the record, there are plans to include dmenu style stuff in
future awesome version.

Cheers,
--

-- 
Julien Danjou
// ᐰ <julien@...>   http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD

Re: Some features from Ion?

On Sat, Dec 01, 2007 at 01:36:25PM +0100, Julien Danjou wrote:
> And for the record, there are plans to include dmenu style stuff in
> future awesome version.

Yeah! Hopefully done even better but i am sure about that ;)
PS: ion3 query module is a good one IMHO, it lists completions _much_
better than dmenu, and can also complete filename arguments.

--
Martin

rga@...: Re: [dwm] dwm-4.6 / dmenu-3.4])

On 23:55 Sat 27 Oct     , Michal Nowak wrote:
> On 23:03 Sat 27 Oct     , Julien Danjou wrote:
> > I remember someone here had a problem running slock.
> > Here is a workaround grabbed on dwm list, confirmed by another one.
> > 
> > ----- Forwarded message from Ruben Gonzalez Arnau <rga@...> -----
> > > Using sleep 1 && slock works for me, maybe is is a 'bad' workaround, but
> > > it works :)
> 
> I confirm it working. Another workaroud I found is to run slock and
> right after another one (press shortcut and then again).
> 
> That's what I put to .awesomerc
> 
>    key
>    {
>        modkey = {"Mod1", "Shift"}
>        key = "l"
>        command = "spawn"
>        arg = "exe=`sleep 1` && exec slock"
>    }
> 
> and it works.
> 
> Thanx Julien for tip.

Just for the record.

The exe=`sleep 1` part is not need in recent slock-0.7

--MN

GTK+ combo box goes lower

Hi.

Having this in .awesomerc:

125     rule
126     {
127         # Programe name (regexp)
128         name = "Gimp"
129         # Program tags (regexp)
130         tags = "8"
131         # Should we set this program to floating mode?
132         float = true
133         # Physical screen to map this windows to
134         screen = 0
135     }

It happens with general GTK+ app but Gimp is where is pains me most.

Run Gimp, select some window on the tag, but not the Gimp main one, than
select the Gimp main, click New and you can see somethink like [1].

It happens whith all that rollete based GTK+ stuff. I remember it was
happening in DWM too. This bug occures only in client being float(ing).

Unsure whether it is GTK+ or awesome/DWM fault but saw it only there.

--MN

[1] attached image of situation

Re: GTK+ combo box goes lower

On Sun, Dec 02, 2007 at 10:20:09PM +0100, Michal Nowak wrote:
> Hi.
> 
> Having this in .awesomerc:
> 
> 125     rule
> 126     {
> 127         # Programe name (regexp)
> 128         name = "Gimp"
> 129         # Program tags (regexp)
> 130         tags = "8"
> 131         # Should we set this program to floating mode?
> 132         float = true
> 133         # Physical screen to map this windows to
> 134         screen = 0
> 135     }
> 
> It happens with general GTK+ app but Gimp is where is pains me most.
> 
> Run Gimp, select some window on the tag, but not the Gimp main one, than
> select the Gimp main, click New and you can see somethink like [1].
> 
> It happens whith all that rollete based GTK+ stuff. I remember it was
> happening in DWM too. This bug occures only in client being float(ing).
> 
> Unsure whether it is GTK+ or awesome/DWM fault but saw it only there.

Hi there.

I've also been bitten by this, but was too busy to look into it. If you
click on the drop-down again so that it closes and then click on it once
more, it will open above the floating window just fine. At first I
thought this could somehow be related to the click-to-raise patchset,
but if memory serves me well, it first appeared many commits after that.
I'll do some bisect'ing later tonight and see if I can pinpoint the
commit that introduced this behavior.

L8r...

\n\n

root mouse bindings (bug?)

Hi all.

root { button = "1" command = "client_focusprev" }

when I click on the root, it should (or not?) focus the next
client, but it does not here.

Cheers
marco

--

-- 
   (o_  It rocks: LINUX + Command-Line-Interface
   //\
   V_/_                     http://www.calmar.ws

Re: GTK+ combo box goes lower

On Mon, Dec 03, 2007 at 12:43:42AM +0200, Nikos Ntarmos wrote:
> On Sun, Dec 02, 2007 at 10:20:09PM +0100, Michal Nowak wrote:
> > Hi.
> > 
> > Having this in .awesomerc:
> > 
> > 125     rule
> > 126     {
> > 127         # Programe name (regexp)
> > 128         name = "Gimp"
> > 129         # Program tags (regexp)
> > 130         tags = "8"
> > 131         # Should we set this program to floating mode?
> > 132         float = true
> > 133         # Physical screen to map this windows to
> > 134         screen = 0
> > 135     }
> > 
> > It happens with general GTK+ app but Gimp is where is pains me most.
> > 
> > Run Gimp, select some window on the tag, but not the Gimp main one, than
> > select the Gimp main, click New and you can see somethink like [1].
> > 
> > It happens whith all that rollete based GTK+ stuff. I remember it was
> > happening in DWM too. This bug occures only in client being float(ing).
> > 
> > Unsure whether it is GTK+ or awesome/DWM fault but saw it only there.
> 
> Hi there.
> 
> I've also been bitten by this, but was too busy to look into it. If you
> click on the drop-down again so that it closes and then click on it once
> more, it will open above the floating window just fine. At first I
> thought this could somehow be related to the click-to-raise patchset,
> but if memory serves me well, it first appeared many commits after that.
> I'll do some bisect'ing later tonight and see if I can pinpoint the
> commit that introduced this behavior.

It turned out that it was my fault after all (hand over that pointy hat,
will you? :).

Please try the attached patch, against v2.0-rc2-3-g6f995ad. It fixes
things for me (and the logic seems correct).

Thanks.

\n\n

diff --git a/event.c b/event.c
index 5ebc72d..ca9916f 100644
--- a/event.c
+++ b/event.c
 <at>  <at>  -197,13 +197,13  <at>  <at>  handle_event_buttonpress(XEvent * e, awesome_config *awesomeconf)

     if((c = get_client_bywin(awesomeconf->clients, ev->window)))
     {
-        XAllowEvents(c->display, ReplayPointer, CurrentTime);
         focus(c, ev->same_screen, &awesomeconf[c->screen]);
         if(CLEANMASK(ev->state, c->screen) != awesomeconf[c->screen].modkey)
         {
            if (ev->button == Button1)
            {
                restack(&awesomeconf[c->screen]);
+               XAllowEvents(c->display, ReplayPointer, CurrentTime);
                grabbuttons(c, True, True, awesomeconf->modkey, awesomeconf->numlockmask);
            }
         }