headers
Stefano | 1 Feb 2009 09:53
Picon
Gravatar

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
Permalink | Reply | 0 comments |
headers
Julien Danjou | 1 Feb 2009 10:23
Gravatar

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
Permalink | Reply | 9 comments |
headers
Nikos Ntarmos | 2 Feb 2009 00:59
Picon
Favicon
Gravatar

[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
Permalink | Reply | 4 comments |
headers
Nikos Ntarmos | 2 Feb 2009 01:02
Picon
Favicon
Gravatar

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)

Permalink | Reply | 3 comments |
headers
Julien Danjou | 2 Feb 2009 08:11
Gravatar

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
Permalink | Reply | 0 comments |
headers
Pierre Habouzit | 2 Feb 2009 16:50
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)

Permalink | Reply | 1 comment |
headers
Nikos Ntarmos | 2 Feb 2009 21:01
Picon
Favicon
Gravatar

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)

Permalink | Reply | 0 comments |
headers
[AvataR] | 4 Feb 2009 19:40
Picon

Float on top


Hi! How can I take some floating window always on top of all, even
c:raise() used on other windows?
Permalink | Reply | 1 comment |
headers
Frank Blendinger | 4 Feb 2009 21:20
Gravatar

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)
Permalink | Reply | 0 comments |
headers
Frank Blendinger | 5 Feb 2009 10:01
Gravatar

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)

Permalink | Reply | 2 comments |

Gmane