headers
awesome | 1 Mar 2012 04:53
Gravatar

[awesome bugs] #964 - Unmaximizing in git/master (Attachment added)

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#964 - Unmaximizing in git/master
User who did this - Ignas Anikevicius (gns_ank)

----------
Here is my hackish attempt to solve the problem. If you think, that the x,width and y,height values should be
stored in the same table entry, let me know, I will rewrite it. But otherwise, it is working fine here. :)
----------

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=964#comment2870

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 Mar 2012 05:02
Gravatar

[awesome bugs] #964 - Unmaximizing in git/master (Attachment added)

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#964 - Unmaximizing in git/master
User who did this - Ignas Anikevicius (gns_ank)

----------
Disregard the previous patch, as it was a silly way to solve the problem. Everything should be fixed now.
----------

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=964#comment2871

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
Anurag Priyam | 1 Mar 2012 07:33
Picon
Gravatar

Re: gradients in master

On Wed, Feb 29, 2012 at 2:57 PM, Uli Schlachter <psychon <at> znc.in> wrote:
> On 26.02.2012 05:01, Anurag Priyam wrote:
>> [...]
>> +    elseif type(col) == "table" then
>> +        local t = col.type
>>
>> `type` is a core Lua function.  I wonder if it is a good practice to
>> use it is a variable name in our code.  Might it be a better idea to
>> redefine the standard `type` as `__type` instead?
>
> Uhm? Variable? Where? Also, if someone breaks lua by overwriting standard
> functions, that's their bug and only half mine.
>
> And if you mean "col.type":I don't think that really counts as a variable name.
> I think there is no place in lua where there would be any ambiguity.
> Still, if you think it should be changed, patches welcome. What should be used
> instead of "type" for the type?
> (cairo calls it "type", too, cairo_pattern_get_type())

Ok.  I was just thinking out loud.  I would wait for it to actually
break or come up with a more concrete reasons before sending a patch
:).  There are more fun things to hack on for now, like libnotify 1.1
spec for naughty.

--

-- 
Anurag Priyam
Permalink | Reply | 0 comments |
headers
Julien Danjou | 1 Mar 2012 10:09
Gravatar

Re: Shadows below the titlebar

On Wed, Feb 29 2012, Uli Schlachter wrote:

> Having said all that, dodo's titlebar code is just a rewrite of 3.4's titlebars
> ontop of master and thus has the same flaws. Since this code isn't in the C
> core, it might have more flaws. From a quick look at the code, I have no idea
> how the client is made "smaller" so that the titlebar contribute's to the
> clients geometry.
> In other words: Shouldn't the titlebar in a tiled layout overlap with the bottom
> edge of the client north of it? If this is only useful with floating clients,
> then I'd give this a NAK.

Ok, it's not that interesting. My original plan IIRC was to add the
possibility for wiboxes to reparent clients and use them as widgets. So
you can just use client as a widget and do "titlebars" that can be any
way you want. :)

> Uli,
> who isn't much of a titlebar fan. :-(

/me neither, spent too much time of this f*cking code :)

--

-- 
        Julien
Permalink | Reply | 1 comment |
headers
Uli Schlachter | 1 Mar 2012 10:52
Picon
Gravatar

Re: Shadows below the titlebar

On 01.03.2012 10:09, Julien Danjou wrote:
> On Wed, Feb 29 2012, Uli Schlachter wrote:
>
>> Having said all that, dodo's titlebar code is just a rewrite of 3.4's titlebars
>> ontop of master and thus has the same flaws. Since this code isn't in the C
>> core, it might have more flaws. From a quick look at the code, I have no idea
>> how the client is made "smaller" so that the titlebar contribute's to the
>> clients geometry.
>> In other words: Shouldn't the titlebar in a tiled layout overlap with the bottom
>> edge of the client north of it? If this is only useful with floating clients,
>> then I'd give this a NAK.
>
> Ok, it's not that interesting. My original plan IIRC was to add the
> possibility for wiboxes to reparent clients and use them as widgets. So
> you can just use client as a widget and do "titlebars" that can be any
> way you want. :)

Perhaps it shouldn't be made all that flexible for now. Instead some kind of 
"window container" object is introduced. A client can only have one window 
container, but a window container gets multiple clients and drawins. Each window 
gets a geometry relative to the container and lua then has to make sure stuff 
"works as expected".

Properties like tags, fullscreen, ... are moved from client to window container. 
Since a client can only have a single client container, all EWMH properties get 
updated by the values from the container.

(Compared to turning clients into widgets, this actually does not break EWMH 
properties. Drawins get reparented, too, so that layouts can continue to work, 
else there would be need for some kind of "this part is invisible" in the widget
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anurag Priyam | 1 Mar 2012 10:52
Picon
Gravatar

Re: [patch] awful.menu: enable keyboard navigation by default

On Wed, Feb 29, 2012 at 3:59 PM, Uli Schlachter <psychon <at> znc.in> wrote:
> On 26.02.2012 05:56, Anurag Priyam wrote:
[...]
>> Here is the correct patch, tested on both values (keygrabber =
>> true/false) this time.  But before this patch is applied, we should
>> perhaps consider removing keygrabber support from menu instead.
>
> So should I merge this or not? Sending a patch with the words "but before this
> patch is applied" feels wrong (but has it's uses...).

Right.  I am sorry.  I wanted to know your take on it first :).

>> Optionally allowing keygrabbers adds to the complexity of the code.
>> And for what gains?  Without keygrabber enabled, you can't even close
>> the menu by pressing 'Escape' key (this is what prompted me to change
>> the default to true).
>
> I guess I wouldn't mind. If it simplifies the code a lot, I'm all settled for
> this. However, I don't really have the time to look closely into this.

Patch attached.  If you like it, let's scrap the previous one
(keygrabber = true by default).

> Anyone out there who opens up a popup menu, then clicks somewhere else and
> expects the menu to stay open? If yes, speak up now or stay quiet forever!

Yeah, this is another thing that annoys me.  Though I am not sure how
I can fix it.  I need to determine that mouse was clicked outside
menu.  So maybe I can attach a handler to 'press' signal on mouse, but
if it was not clicked on any visible menu (not sure how to determine
(Continue reading)

Permalink | Reply | 1 comment |
headers
Uli Schlachter | 1 Mar 2012 17:08
Picon
Gravatar

Re: [patch] awful.menu: enable keyboard navigation by default

On 01.03.2012 10:52, Anurag Priyam wrote:
> On Wed, Feb 29, 2012 at 3:59 PM, Uli Schlachter <psychon <at> znc.in> wrote:
>> On 26.02.2012 05:56, Anurag Priyam wrote:
[...]
>>> Optionally allowing keygrabbers adds to the complexity of the code.
>>> And for what gains?  Without keygrabber enabled, you can't even close
>>> the menu by pressing 'Escape' key (this is what prompted me to change
>>> the default to true).
>>
>> I guess I wouldn't mind. If it simplifies the code a lot, I'm all settled for
>> this. However, I don't really have the time to look closely into this.
> 
> Patch attached.  If you like it, let's scrap the previous one
> (keygrabber = true by default).

Pushed, thanks.

>> Anyone out there who opens up a popup menu, then clicks somewhere else and
>> expects the menu to stay open? If yes, speak up now or stay quiet forever!
> 
> Yeah, this is another thing that annoys me.  Though I am not sure how
> I can fix it.  I need to determine that mouse was clicked outside
> menu.  So maybe I can attach a handler to 'press' signal on mouse, but
> if it was not clicked on any visible menu (not sure how to determine
> that), then close it?

Would need a mouse grabber. When someone dares to click elsewhere, the grabber
is stopped and the menu closed. (And the click which caused that is discarded,
but that's also what gtk/qt are doing)
(Continue reading)

Permalink | Reply | 0 comments |
headers
awesome | 1 Mar 2012 17:11
Gravatar

[awesome bugs] #964 - Unmaximizing in git/master

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#964 - Unmaximizing in git/master
User who did this - Uli Schlachter (psychon)

----------
Heh.

---  <at> release  <at> AWESOME_VERSION <at> 
+--  <at> release v3.4-624-ga0e21bb
----------

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

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 Mar 2012 17:12
Gravatar

[awesome bugs] #964 - Unmaximizing in git/master

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task is now closed:

FS#964 - Unmaximizing in git/master
User who did this - Uli Schlachter (psychon)

Reason for closing: Fixed
Additional comments about closing: commit e37efaeb8ad33693002280d6cea5c2c133639c78
Author: Ignas Anikevicius (gns_ank) <anikevicius <at> gmail.com>
Date:   Thu Mar 1 03:46:48 2012 +0000

    awful: ewmh.lua Fix unmaximization (#964)

    This makes awful not to overwrite the saved geometry by just storing the
    two geometries in separate places.

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

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
Ignas Anikevicius | 2 Mar 2012 00:15
Picon
Gravatar

[PATCH] Account for border-width when maximizing

Hello,

I realized how to fix this small issue which annoyed me slightly :).
Now it decreases the width of the client by twice the width of the
border-width so that a maximized client does not go off the screen.

Ignas A.
Attachment (0001-ewmh.lua-Account-for-the-border-width.patch): text/x-patch, 1728 bytes
Permalink | Reply | 3 comments |

Gmane