Re: Some questions from an awesome beginner

2013-10-30 Thread Marshall Mason
Hi Eugen,
>From your work flow, it sounds like awesome is perfect for you. The
arrangement of the windows you described sounds ideal for tiling. Find a
tiling scheme that works for you, and just let awesome do the arranging for
you. Never move or resize windows ever again. It's hard to tell from your
description which layout would be best. Play with them, and see what you
like.

Awesome does have minimize functionality. The default key binding is Mod4-n
to minimize and Mod4-Ctrl-n to unminimize. It's certainly possible to use
tags instead of minimizing, but not necessary.

Tags in awesome, like its predecessor dwm, are a very flexible and powerful
way to use multiple desktops. To truly leverage its power, use tags
heavily. Since it's so flexible, how you use them depends on your
preferences. Some people like to have all instances of any given
application in each tag. You can easily configure awesome to always open an
application in a specific tag.

The way I like to use it is to use a tag for each project I'm working on.
All the relevant browsers, editors, and terminals are in their project's
tag. I use minimize whenever I want to hide an application relevant to a
specific project. I used to minimize often for windows that belonged to
different project. Now that I use tags heavily, I rarely need to minimize.

Your Thunderbird window sounds like its of more general interest, something
you want quick access to wherever you are. You could assign it its own tag,
and then just go to that tag whenever you want to see it. But then
everything else you're doing wouldn't be visible. If it's something you
refer to a lot when you're in your other applications, this is an ideal
case for tagging an application with multiple tags. If you hit
Mod4-Shift-Control-#, it will add that tag to the application. So if it's
in tag 1, and you hit Mod4-Shift-Control-2, it will be visible in both tags
1 and 2. Then you can minimize it when you don't need it. It's also
possible to view multiple tags at once, but hitting Mod4-Control-#. So,
another approach is to have Thunderbird in its own tag, and then when
you're in another tag and want to see Thunderbird, you just view both tags.
It all depends on what feels the most intuitive to you.

dwm has a tag 0, which represents all tags. I found this incredibly useful.
Awesome isn't configured with it by default, but it was trivial for me to
add it. That's where awesome really shines. You can literally add entirely
new features with a few lines of Lua code.

Marshall


On Wed, Oct 30, 2013 at 9:47 AM, Eugen Dedu  wrote:

> On 30/10/13 16:49, Gabe Martin wrote:
>
>> a tag is just a group of applications. rather than minimising and
>> maximising things, you can assign applications to different tags. then,
>> when you want to view those things, you can toggle the tag to be visible
>> along with your current tag, and, when you're done, toggle that tag to be
>> invisible again.
>>
>
> So IF you put one app per tag, then minimising an app is equivalent to
> disabling a tag.  (Except that by default you do not see the apps from
> other tags, I suppose this can be changed if needed.)
>
> I suppose the benefit of using tags appears when you put several apps in
> one tag.  I still do not see the benefit.
>
> I gave you my work flow.  Could you give some test cases for tag usage (or
> your work flow)?  What do you put precisely in your tags and more
> importantly how do you use them?
>
> Note that permitting to have an app in several tags cannot be considered a
> reason to use tags.
>
>
> --
> Eugen
>
> --
> To unsubscribe, send mail to 
> awesome-unsubscribe@naquadah.**org
> .
>


Changing window geometry in non-floating layouts

2013-07-25 Thread Marshall Mason
Hi,
I'm a heavy user of dmenu and dzen2. I'm trying to figure out how to
configure Awesome so the clients move down and back up in the brief moments
that dmenu and dzen2 show up rather than just covering them over. I've got
this working nicely in floating mode. I just calculate new geometries for
each window. However, the non-floating layouts completely ignore attempts
to set the geometry. It looks like it changes it, but then overrides it and
changes it back.

The wibox visibility toggle seems to know how to do this, so I've used this
work-around:

-- Move clients down
if awful.layout.get(s) ~= awful.layout.suit.floating then
  mywibox[s].visible = true
end

-- Move clients back up
if awful.layout.get(s) ~= awful.layout.suit.floating then
  mywibox[s].visible = false
end

However, this is very kludgy, and I'd like to find a more elegant solution.
Is there a way to force non-floating modes to accept new geometries? Or
else is there some way to mimic the behavior of the wibox when toggling
visibility, i.e. telling all the clients to shrink?

Thanks,
Marshall


Gvim resizing

2013-07-12 Thread Marshall Mason
Hi,
Newbie here. :) I've been having great fun hacking away with the Lua API,
and it's been, well, awesome.

But I got stuck. I think this is more of a problem with Gvim than Awesome,
but it's happening in the context of the Lua API, and I doubt the Vim guys
know anything about that, so I'm hoping there's someone here who knows
Gvim's quirks enough to help.

Code speaks louder than words, so here goes.

function check_size()
  local geometry = client.focus:geometry()
  naughty.notify({
preset = naughty.config.presets.low,
title  = "Debug message",
height = 200,
width  = 400,
hover_timeout = 10,
text   = tostring(geometry.height)
  })
end

function test_resize()
  check_size()
  local adjustment = 3
  local geometry = client.focus:geometry()
  geometry.height = geometry.height - adjustment
  client.focus:geometry(geometry)
  check_size()
end

When I run test_resize(), it displays the height and height minus 3 just as
it should. It does this for Gvim as well. But for Gvim only, when I check
it again with check_size() it gives a completely new number, usually the
original height minus 15 or 20. I'm guessing this has to do with Gvim's
love for measuring geometry by number of characters rather than pixels.
There must be some way to force Gvim to obey the window manager. Otherwise,
the window manager has no precision in its control over window sizes.

I suspected size_hints_honor might have something to do with this, but the
problem exists no matter what size_hints_honor is set to. I'm running
Awesome 3.4.13-1 (Octopus) in Debian wheezy. Any ideas?

Marshall