On Tue, Jan 22, 2013 at 06:34:41PM +0100, Marco wrote: > On 2013–01–21 Andre Klärner wrote: > > > > I don't know how other window managers deal with this issue. Do they > > > all completely lose the state and fall back to the default window > > > configuration? > > > > Well, I for my part also had the problem that the state got lost, but I was > > also annoyed by the fact, that on each boot (and my work-machine has to be > > powered on and off each day) I have to start all applications again and > > move them to the right tag, and so on. So I looked around and found rules > > and shifty. > > Rules are a very powerful tool that I appreciate since my first day > of using awesome. They are great for setting up static and > predictable applications such as web browser, IRC client, mail > reader, etc. > > However, they are only usable if the setup can be expressed as a > rule (this applied to shifty as well, since shifty is also driven by > rules). One problem you already mentioned yourself: some things are > hard or impossible to express as a rule.
Well, I also thought that of most of my rules I have today (e.g. one of the first: how do I get pidgin of the rightmost screen at home, while on the primary at work) are harder to discribe at first, but once you got the first idea it takes only minutes to complete this to perfection. > Awesome allows for manual adjustment of tiling layout, window > proportions (mwfact), number of master windows, etc. If everything > could be expressed as a rule these functions would not be necessary. > Tagging clients manually would also be superfluous. Yet, there is a > reason that all these adjustments can be done manually and people > use it for good reasons. And it's exactly those settings that get > lost when awesome restarts, those settings that can't be expressed > by rules because they were set up during the work flow, like your > VLC or virtualbox setup. Well, but I (IMHO) consider the manual changes to be not valuable. I use quite often one up to ten terminals to our jump host at work, but the sizes of them always depend on what I am doing that day. If I am batch-running SLES upgrades I have no need to manuall adjust anything, but if I repair a database server I need to connect and do stuff on a small term while watching the long lines in another widescreen term. So this isn't hard-programmable, but in this case the change of mwfact is matter of seconds if I really need to restore it after an undock event. > Rules can surely reduce the mess created during a restart, but they > don't solve the foundational problem of forgetting the state. Well, someone posted a while ago the following git-repo: https://github.com/dodo/uzful/blob/master/restore.lua If I remember right it should do exactly that: remembering (some) state. Anyway I still know that there are things that annoy me: my new 27" screen at home is connected via displayport, so if I power it down the gfx card disables this screen via xrandr and let's awesome restart, while when I power it back on the same happens again.. Well, this will drive me to finally do what I wanted to do for a while: write a applet that runs the urxvt->screen->ssh path to any of my machines and let's me reconnect to them, while creating a tag for each of them in shifty.. ;) Regards, Andre -- Andre Klärner
smime.p7s
Description: S/MIME cryptographic signature
