headers
awesome | 1 Jul 2012 11:28
Gravatar

[awesome bugs] #1012 - IntelliJ IDEA hangs while importing maven project, awesome-only (Attachment added)

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1012 - IntelliJ IDEA hangs while importing maven project, awesome-only
User who did this - Anton (zhuravlik)

----------
Added printf's. Results are attached.

For IDEA: opened xterm, launched IDEA, selected create new project -> import from external model -> maven
-> specified options -> next -> hang, killed IDEA, closed xterm
For MATLAB: opened xterm, launched MATLAB, opened several menus and switched focus between different
panes, closed MATLAB, closed xterm
----------

One or more files have been attached.

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1012#comment3077

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

--

-- 
To unsubscribe, send mail to awesome-devel-unsubscribe <at> naquadah.org.
Permalink | Reply | 0 comments |
headers
awesome | 1 Jul 2012 14:34
Gravatar

[awesome bugs] #1012 - IntelliJ IDEA hangs while importing maven project, awesome-only (Attachment added)

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1012 - IntelliJ IDEA hangs while importing maven project, awesome-only
User who did this - Uli Schlachter (psychon)

----------
Could you try how much the attached patch fixes and how much it breaks?

This should fix a case where awesome unfocuses a client with the nofocus hint set, but which was given the
input focus through some dark magic (globally active input model, I'm looking at you!) anyway.
----------

One or more files have been attached.

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1012#comment3078

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

--

-- 
To unsubscribe, send mail to awesome-devel-unsubscribe <at> naquadah.org.
Permalink | Reply | 0 comments |
headers
awesome | 1 Jul 2012 14:47
Gravatar

[awesome bugs] #1013 - Menubar: prefixes missing after porting to LUA v5.2

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task is now closed:

FS#1013 - Menubar: prefixes missing after porting to LUA v5.2
User who did this - Uli Schlachter (psychon)

Reason for closing: Fixed
Additional comments about closing: BTW I wouldn't mind getting patches via awesome-devel instead of flyspray.

commit fd4b3acbf5430d04c40a2b06994198a9216cbd7e
Author: Ignas Anikevicius (gns_ank) <anikevicius <at> gmail.com>
Date:   Sat Jun 30 20:51:11 2012 +0100

    Menubar: some more prefixes

    Signed-off-by: Ignas Anikevicius (gns_ank) <anikevicius <at> gmail.com>
    Signed-off-by: Uli Schlachter <psychon <at> znc.in>

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1013

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

--

-- 
To unsubscribe, send mail to awesome-devel-unsubscribe <at> naquadah.org.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Felix Bier | 1 Jul 2012 15:24

[PATCH] tag.viewidx-should-take-a-screen-index

Hello list,
this patch makes tag.viewidx take a screen index rather than a screen
object, complying with its doc string. This seems to be more consistent
with other parts of the API to me, and also fixes #963. Config breakage
should be minimal, since this function is usually called without the
screen parameter.
Felix
Attachment (2012-0701-0001-tag.viewidx-should-take-a-screen-index.patch): text/x-patch, 1024 bytes
Permalink | Reply | 2 comments |
headers
Felix Bier | 1 Jul 2012 15:26

[PATCH] Fix-spelling-in-doc-string

This fixes a minor spelling mistake.
Attachment (2012-0701-0002-Fix-spelling-in-doc-string.patch): text/x-patch, 882 bytes
Permalink | Reply | 1 comment |
headers
awesome | 1 Jul 2012 15:29
Gravatar

[awesome bugs] #1012 - IntelliJ IDEA hangs while importing maven project, awesome-only

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#1012 - IntelliJ IDEA hangs while importing maven project, awesome-only
User who did this - Anton (zhuravlik)

----------
This patch fixed nothing and broke nothing at all.

Still the same issues with MATLAB and IDEA after applying this patch.
Maybe these apps are poorly written, because with NetBeans, for example, there are and were no problems at all.
----------

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1012#comment3079

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

--

-- 
To unsubscribe, send mail to awesome-devel-unsubscribe <at> naquadah.org.
Permalink | Reply | 0 comments |
headers
awesome | 1 Jul 2012 17:21
Gravatar

[awesome bugs] #963 - Incorrect documentation in awful.viewnext and .viewprev

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task is now closed:

FS#963 - Incorrect documentation in awful.viewnext and .viewprev
User who did this - Uli Schlachter (psychon)

Reason for closing: Fixed
Additional comments about closing: commit fa36bd0a5964a3a5da31084541759666e7129777
Author: Felix Bier <flx.bier <at> googlemail.com>
Date:   Sun Jul 1 14:57:25 2012 +0200

    tag.viewidx should take a screen index

    This makes tag.viewidx take a screen index rather than a screen object,
    complying with its doc string. This fixes #963.

    Signed-off-by: Felix Bier <flx.bier <at> googlemail.com>
    Signed-off-by: Uli Schlachter <psychon <at> znc.in>

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=963

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

--

-- 
To unsubscribe, send mail to awesome-devel-unsubscribe <at> naquadah.org.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Uli Schlachter | 1 Jul 2012 17:21
Picon
Gravatar

Re: [PATCH] Fix-spelling-in-doc-string

On 01.07.2012 15:26, Felix Bier wrote:
> This fixes a minor spelling mistake.

Both patches merged.

--

-- 
- He made himself, me nothing, you nothing out of the dust
- Er machte sich mir nichts, dir nichts aus dem Staub
Permalink | Reply | 0 comments |
headers
Felix Bier | 1 Jul 2012 20:21

Re: [PATCH] tag.viewidx-should-take-a-screen-index

Am Sonntag, den 01.07.2012, 15:24 +0200 schrieb Felix Bier:
> Hello list,
> this patch makes tag.viewidx take a screen index rather than a screen
> object, complying with its doc string. This seems to be more consistent
> with other parts of the API to me, and also fixes #963. Config breakage
> should be minimal, since this function is usually called without the
> screen parameter.
> Felix

Unfortunately I noticed a problem with my patch when attempting to
switch tags via mouse wheel. When tag.viewprev or tag.viewnext is set as
a callback to a mouse button event for a tag, the screen parameter
passed to viewidx will in fact be the originating tag. This is the right
behaviour for  i. e. viewonly, but causes an error with my patch. I
guess this did not matter previously, because screen.index would
evaluate to nil. 

I am not sure how this should be handled. The attached patch checks
whether type(screen)=="number", which is the most simple fix, but not
exactly beautiful. Alternatively, the previous patch could be reverted
and this side effect be documented. The "right thing" would probably be
to wrap viewnext/viewprev like awful.button({}, 4, function()
awful.tag.viewnext() end), though that would be my least favourite
option, because it would break a lot of configs. Other opinions?

Felix
Attachment (0001-Follow-up-fix-for-tag.viewidx.patch): text/x-patch, 1049 bytes
Permalink | Reply | 1 comment |
headers
Uli Schlachter | 1 Jul 2012 20:28
Picon
Gravatar

Re: [PATCH] tag.viewidx-should-take-a-screen-index

On 01.07.2012 20:21, Felix Bier wrote:
> Am Sonntag, den 01.07.2012, 15:24 +0200 schrieb Felix Bier:
>> Hello list,
>> this patch makes tag.viewidx take a screen index rather than a screen
>> object, complying with its doc string. This seems to be more consistent
>> with other parts of the API to me, and also fixes #963. Config breakage
>> should be minimal, since this function is usually called without the
>> screen parameter.
>> Felix
> 
> Unfortunately I noticed a problem with my patch when attempting to
> switch tags via mouse wheel. When tag.viewprev or tag.viewnext is set as
> a callback to a mouse button event for a tag, the screen parameter
> passed to viewidx will in fact be the originating tag. This is the right
> behaviour for  i. e. viewonly, but causes an error with my patch. I
> guess this did not matter previously, because screen.index would
> evaluate to nil. 

Tags have a .screen property, too. So that code actually worked fine before.

> I am not sure how this should be handled. The attached patch checks
> whether type(screen)=="number", which is the most simple fix, but not
> exactly beautiful. Alternatively, the previous patch could be reverted
> and this side effect be documented. The "right thing" would probably be
> to wrap viewnext/viewprev like awful.button({}, 4, function()
> awful.tag.viewnext() end), though that would be my least favourite
> option, because it would break a lot of configs. Other opinions?

Welcome to git/master. Everyone switching from 3.4 to this will get some
breakage anyway, so I'm not too worried about this. So this last thing would be
(Continue reading)

Permalink | Reply | 0 comments |

Gmane