Stefano | 1 Feb 09:53 2009
Picon

Re: Titlebars to dialog windows

On Sat, Jan 31, 2009 at 12:38 PM, Frank Blendinger
<fb <at> intoxicatedmind.net> wrote:
> I tried doing this by putting
>
>    if c.type == "dialog" then
>        awful.titlebar.add(c, { modkey = modkey })
>    end
>
> in the manage hook, which should usually do the job. To my surprise it
> did not.
> [...]
> Are dialog windows handled differently somehow? I suppose this might be
> a bug. The code above should work.

That's exactly the point. Does anybody has a clue?

Thanks
--
Stefano Verna
mail/gtalk: stefano.verna <at> gmail.com
http://www.downthemall.net

Julien Danjou | 1 Feb 10:23 2009

Re: Titlebars to dialog windows

At 1233434315 time_t, Frank Blendinger wrote:
> Are dialog windows handled differently somehow? I suppose this might be
> a bug. The code above should work.

Nop. It should work.

--

-- 
Julien Danjou
// ᐰ <julien <at> danjou.info>   http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
Nikos Ntarmos | 2 Feb 00:59 2009
Picon

[RFC] gperf 2.7.2 vs 3.0.3 in FreeBSD

Hi all.

I just stumbled upon this and thought I'd better ask here to save some
time digging around the gperf internals. FreeBSD (for which I'm the port
maintainer) has a gperf executable in the base system, identified as GNU
gperf 2.7.2 in the 7-STABLE branch. There is also the devel/gperf port,
containing GNU gperf 3.0.3. I'd like to keep the dependencies as low as
possible for our package so I tried to generate tokenize.{c,h} with the
base version. To start with, it required an extra -D argument as there
were a couple of "duplicate" symbols. Now, the resulting .h file is
identical among the two versions, but the (attached) .c file is
obviously different. I'm running a version with the attached tokenize.c
file. Can one of you gperf gurus out there see something notably wrong
with it?

Cheers.

\n\n

Nikos Ntarmos | 2 Feb 01:02 2009
Picon

Re: [RFC] gperf 2.7.2 vs 3.0.3 in FreeBSD

On Mon, Feb 02, 2009 at 01:59:56AM +0200, Nikos Ntarmos wrote:
> Hi all.
> 
> I just stumbled upon this and thought I'd better ask here to save some
> time digging around the gperf internals. FreeBSD (for which I'm the port
> maintainer) has a gperf executable in the base system, identified as GNU
> gperf 2.7.2 in the 7-STABLE branch. There is also the devel/gperf port,
> containing GNU gperf 3.0.3. I'd like to keep the dependencies as low as
> possible for our package so I tried to generate tokenize.{c,h} with the
> base version. To start with, it required an extra -D argument as there
> were a couple of "duplicate" symbols. Now, the resulting .h file is
> identical among the two versions, but the (attached) .c file is
> obviously different. I'm running a version with the attached tokenize.c
> file. Can one of you gperf gurus out there see something notably wrong
> with it?
> 
> Cheers.
> 
> \n\n

... and the attachments... I'm testing the v2.7.2 one right now, which
is the one I'd ideally like to keep. However, I'm afraid of losing some
functionality somewhere. Not that I've seen something different so far.

Please comment...

\n\n
Attachment (tokenize.base.c): text/x-csrc, 9 KiB
Attachment (tokenize.c): text/x-csrc, 10 KiB
(Continue reading)

Julien Danjou | 2 Feb 08:11 2009

Re: [RFC] gperf 2.7.2 vs 3.0.3 in FreeBSD

At 1233532926 time_t, Nikos Ntarmos wrote:
> On Mon, Feb 02, 2009 at 01:59:56AM +0200, Nikos Ntarmos wrote:
> ... and the attachments... I'm testing the v2.7.2 one right now, which
> is the one I'd ideally like to keep. However, I'm afraid of losing some
> functionality somewhere. Not that I've seen something different so far.

I'm not a guru, but well, if it compile and works for you, we very
very probably did not lose anything in the process.

Cheers,
--

-- 
Julien Danjou
// ᐰ <julien <at> danjou.info>   http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
Pierre Habouzit | 2 Feb 16:50 2009
X-Face

Re: [RFC] gperf 2.7.2 vs 3.0.3 in FreeBSD

On Mon, Feb 02, 2009 at 12:02:06AM +0000, Nikos Ntarmos wrote:
> On Mon, Feb 02, 2009 at 01:59:56AM +0200, Nikos Ntarmos wrote:
> > Hi all.
> > 
> > I just stumbled upon this and thought I'd better ask here to save some
> > time digging around the gperf internals. FreeBSD (for which I'm the port
> > maintainer) has a gperf executable in the base system, identified as GNU
> > gperf 2.7.2 in the 7-STABLE branch. There is also the devel/gperf port,
> > containing GNU gperf 3.0.3. I'd like to keep the dependencies as low as
> > possible for our package so I tried to generate tokenize.{c,h} with the
> > base version. To start with, it required an extra -D argument as there
> > were a couple of "duplicate" symbols. Now, the resulting .h file is
> > identical among the two versions, but the (attached) .c file is
> > obviously different. I'm running a version with the attached tokenize.c
> > file. Can one of you gperf gurus out there see something notably wrong
> > with it?
> > 
> > Cheers.
> > 
> > \n\n
> 
> .... and the attachments... I'm testing the v2.7.2 one right now, which
> is the one I'd ideally like to keep. However, I'm afraid of losing some
> functionality somewhere. Not that I've seen something different so far.

You won't lose anything, just have a slightly less efficient lookup in
the worst case scenario, which you don't care about.

--

-- 
·O·  Pierre Habouzit
(Continue reading)

Nikos Ntarmos | 2 Feb 21:01 2009
Picon

Re: [RFC] gperf 2.7.2 vs 3.0.3 in FreeBSD

On Mon, Feb 02, 2009 at 04:50:25PM +0100, Pierre Habouzit wrote:
> On Mon, Feb 02, 2009 at 12:02:06AM +0000, Nikos Ntarmos wrote:
> > On Mon, Feb 02, 2009 at 01:59:56AM +0200, Nikos Ntarmos wrote:
> > > Hi all.
> > > 
> > > I just stumbled upon this and thought I'd better ask here to save some
> > > time digging around the gperf internals. FreeBSD (for which I'm the port
> > > maintainer) has a gperf executable in the base system, identified as GNU
> > > gperf 2.7.2 in the 7-STABLE branch. There is also the devel/gperf port,
> > > containing GNU gperf 3.0.3. I'd like to keep the dependencies as low as
> > > possible for our package so I tried to generate tokenize.{c,h} with the
> > > base version. To start with, it required an extra -D argument as there
> > > were a couple of "duplicate" symbols. Now, the resulting .h file is
> > > identical among the two versions, but the (attached) .c file is
> > > obviously different. I'm running a version with the attached tokenize.c
> > > file. Can one of you gperf gurus out there see something notably wrong
> > > with it?
> > > 
> > > Cheers.
> > > 
> > > \n\n
> > 
> > .... and the attachments... I'm testing the v2.7.2 one right now, which
> > is the one I'd ideally like to keep. However, I'm afraid of losing some
> > functionality somewhere. Not that I've seen something different so far.
> 
> You won't lose anything, just have a slightly less efficient lookup in
> the worst case scenario, which you don't care about.

Thanks Pierre. I finally went the safe way and added a build-time
(Continue reading)

[AvataR] | 4 Feb 19:40 2009
Picon

Float on top


Hi! How can I take some floating window always on top of all, even
c:raise() used on other windows?

Frank Blendinger | 4 Feb 21:20 2009
Picon

Re: Float on top

Hi.

On Wed 2009-02-04 20:40, [AvataR] <public.avatar <at> gmail.com> proclaimed:
> Hi! How can I take some floating window always on top of all, even
> c:raise() used on other windows?

c.ontop = true

Greetings,
Frank

--

-- 
Frank Blendinger | fb(at)intoxicatedmind.net | GPG: 0x0BF2FE7A
Fingerprint: BB64 F2B8 DFD8 BF90 0F2E 892B 72CF 7A41 0BF2 FE7A
  "Just because I don't care doesn't mean I don't understand."
                                               (Homer Simpson)
Frank Blendinger | 5 Feb 10:01 2009
Picon

Putting (fullscreen) mplayer on a certain screen in a Xinerama setup

Hi,

as some of you probably know, mplayer does some nasty movement things,
which makes it a pain in the ass to control its positioning with
awesome, at least in a multihead environment.

I managed to write some lines of Lua that take care of some of the
problems, which I will present at the end of this mail. This is actually
very hackish and I don't like it at all, therefore I am asking for help
or suggestions how to do it better. I don't think I am the only one that
tries to cope with mplayer's weird behavior.

My current setup is Xinerama (actually the "TwinView" mode of the nvidia
driver, but how I understood the manual this is a proper Xinerama mode)
with two screens, a TV set to 800x600 that is positioned to left of a
LCD at 1680x1050, which gives me a total screen size of 2480x1050.

The LCD is set up as screen 1, the TV as screen 2 (``Option
"TwinViewXineramaInfoOrder" "DFP-0 TV-0"'' in xorg.conf), awesome
detects this well. Unfortunately mplayer does not. Launching mplayer
with a default rc.lua results in a floating mplayer window centered on
screen 2 (the TV on the left). The window appears for a very short time
at the position one would expect it to be, at the top left on screen 1,
but then "moves" to screen 2 - I am quite sure that this is done by
mplayer itself (which sucks).

I worked around this in a really ugly way: waiting for a short amount of
time and calling awful.client.movetoscreen. The waiting is necessary,
you can't do it right away in the manage hook, because mplayer is not
done its crappy moving thing then.
(Continue reading)


Gmane