Aliases and preserving window size in Awesome

DrKillPatient · 2011-08-21 00:12:18

I have a program, Dwarf Fortress, that starts through a script. I know that I can make a bash alias to make the command 'dwarfort' cd to the script and run it, but that doesn't make Awesome's mod+r dialog use that same alias. Can I get the aliases I use in bash to be recognized by mod+r?

Once Dwarf Fortress is started, it needs to stay at the resolution that it started at, otherwise the ASCII gets scaled wierdly. Is there a way to prevent Awesome from resizing it like other windows on startup?

Last edited by DrKillPatient (2011-08-22 02:53:31)

greyscale · 2011-08-21 00:21:45

Don't think awesome will honor your bash aliases, think there is a thread on the subject already so try searching for it.

About resizing the window you could add a rule to rc.lua that sets floating to true for that window (client).
Take a look at https://awesome.naquadah.org/wiki/FAQ#H … loating.3F

DrKillPatient · 2011-08-21 00:40:03

I have

{ rule = { name = "Dwarf Fortress" },
   properties = { floating = true } },

in rc.lua, but it doesn't seem to be affecting anything. When Dwarf Fortress starts, the window is indeed called "Dwarf Fortress". Should I use "df" instead, which is the script that starts it?

As for aliases, I found a thread here but I don't really understand it. Could someone perhaps explain it in greater detail?

greyscale · 2011-08-21 01:24:56

I'm guessing this game runs in your standard terminal, right?

I wanted to something like what you want but with mutt (running in xterm) and moving it to a specific tag.
I have a ~/.bin directory that is before /usr/bin in my path so I created a script in that directory called mutt

Here is the script:

#!/bin/bash
xterm -class MuttUXTERM -u8 -title Mutt -e /bin/bash -c /usr/bin/mutt $@

That will start a xterm, set the class to MuttUXTERM, set title etc and start mutt.
Then I added a rule in rc.lua

    { rule = { class = "MuttUXTERM" },                                                                                      
      properties = { tag = tags[1][9] } },

I always found it safer to using the class when writing the rules and xterm and most
other terminals allows you to set the class in similar way.

Pasting from awful's api doc:

name: The client title

So in that case you'll have to match the window title but if that is the same as your terminal name
you'll have to do something like what I did or the rule will match all your terminals.

Hope I still make some sense.. half past three in the morning here and I'm on my way to bed so

DrKillPatient · 2011-08-21 22:06:39

DF doesn't actually run in terminal, it has its own window. Can the window class be added to the startup script (or anywhere else)? Here it is:

#!/bin/sh
DF_DIR=$(dirname "$0")
cd "${DF_DIR}"
export SDL_DISABLE_LOCK_KEYS=1 # Work around for bug in Debian/Ubuntu SDL patch.
#export SDL_VIDEO_CENTERED=1 # Centre the screen.  Messes up resizing.
./libs/Dwarf_Fortress $* # Go, go, go! :)

Also, what do you mean by having ~/.bin before /usr/bin? You load it instead of or alongside /usr/bin? How do you do that exactly?

EDIT: and I assume any scripts in ~/.bin will be read as programs, so I can start them through Awesome's mod+r run dialog?

Last edited by DrKillPatient (2011-08-21 22:08:14)

greyscale · 2011-08-21 22:17:47

my $PATH looks something like PATH=/home/grey/.bin:/usr/bin etc..
that means that if it type mutt it will start looking for mutt in /home/grey/.bin if it doesn't find it
there it will look in /usr/bin and so on...

You can if you have added it to your PATH

If it starts in it's own window have you can get the class using xprop, see https://awesome.naquadah.org/wiki/FAQ#H … tifiers.3F
for more info. Then you can use the class you get from there iin your rule.

DrKillPatient · 2011-08-21 23:38:22

Xprop gives

_NET_WM_DESKTOP(CARDINAL) = 0
WM_STATE(WM_STATE):
                window state: Normal
                icon window: 0x0
WM_NORMAL_HINTS(WM_SIZE_HINTS):
_NET_WM_NAME(UTF8_STRING) = "Dwarf Fortress"
WM_NAME(STRING) = "Dwarf Fortress"
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW
WM_CLASS(STRING) = "Dwarf_Fortress", "Dwarf_Fortress"
WM_HINTS(WM_HINTS):
                Client accepts input or input focus: True

And in rc.lua I have

    { rule = { class = "Dwarf_Fortress" },
      properties = { floating = true } },

Yet it still doesn't seem to have an effect, if I'm in a tiling mode it will still stretch. Am I missing something?

EDIT: Actually it does seem to have an effect, since now it's spawning as a floating window, but the window still starts at the wrong size-- just slightly over the usual size... In addition, when I start Dwarf Fortress, my mouse changes to the 'loading' symbol indefinitely until I restart X if I run it through the script. Perhaps I've done something wrong in writing it?

#!/bin/bash
./Applications/Games/DwarfFortress/df/df
exit 1

Last edited by DrKillPatient (2011-08-22 00:52:02)

greyscale · 2011-08-22 01:35:55

Installed the game and the rules does make it floating as it should do but I see what you mean.
Why it does that I can't answer.

DrKillPatient · 2011-08-22 02:45:31

I seem to have accidentally fixed it by messing around with my theme, perhaps when I removed window borders. It sizes correctly now. However, do you know why my startup script (posted earlier) makes my mouse display the 'loading' symbol infinitely until I restart X?

Last edited by DrKillPatient (2011-08-22 02:55:45)

Delcaran · 2011-08-22 09:03:10

For the loading icon, there's a fix for that in the Awesome Wiki: https://awesome.naquadah.org/wiki/Disab … n_globally
BTW, I've installed the AUR package for DwarfFortress, and I don't need any script to run it..

DrKillPatient · 2011-08-22 16:20:47

I have the version downloaded from the main site, so it might differ from yours a bit. The 'df' file in the main directory is what starts the game for me. It seems to make a call to dwarfort.exe.

I've figured out what causes the scaling, though: when the game starts and the window it's in has borders, the borders aren't applied in addition to the window, rather, they are applied to the sides of the already existing space. Therefore, DF needs to move down one zoom level to fit itself completely. Can I somehow turn off the borders for that window class in the rules?

EDIT: and another somewhat related question; how can I run something in URxvt like Xterm? Usually I can just do "xterm [program name]", but URxvt can't run programs that way.

Last edited by DrKillPatient (2011-08-22 16:59:36)

Arch Linux

#1 2011-08-21 00:12:18

Aliases and preserving window size in Awesome

#2 2011-08-21 00:21:45

Re: Aliases and preserving window size in Awesome

#3 2011-08-21 00:40:03

Re: Aliases and preserving window size in Awesome

#4 2011-08-21 01:24:56

Re: Aliases and preserving window size in Awesome

#5 2011-08-21 22:06:39

Re: Aliases and preserving window size in Awesome

#6 2011-08-21 22:17:47

Re: Aliases and preserving window size in Awesome

#7 2011-08-21 23:38:22

Re: Aliases and preserving window size in Awesome

#8 2011-08-22 01:35:55

Re: Aliases and preserving window size in Awesome

#9 2011-08-22 02:45:31

Re: Aliases and preserving window size in Awesome

#10 2011-08-22 09:03:10

Re: Aliases and preserving window size in Awesome

#11 2011-08-22 16:20:47

Re: Aliases and preserving window size in Awesome

Board footer