[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [STUMP] Placement rules, automatic group create/restore
From: |
Morgan Veyret |
Subject: |
Re: [STUMP] Placement rules, automatic group create/restore |
Date: |
Wed, 16 Jul 2008 14:35:24 +0200 |
User-agent: |
Mutt/1.4.2.3i |
On 13:31 Tue 15 Jul , Shawn wrote:
> Hi Morgan,
>
> Sorry for the delay in getting back to you. When I saw 4 patches I
> assumed it was a big gnarly patch and avoided it as long as I
> could. It turns out, the patch is fairly modest. Next time, can you
> send a single final patch instead of the intermediate patches? That
> would make it easier for me to review it and keep my nerves at ease :).
Well as soon as I find how to do it, yes this should be possible :)
>
> I have some questions about your patch.
>
> Where does the group get automatically dumped? I can't seem to find it.
>
There's no automatic dump, only automatic restore, but with your
*data-dir* patch this should be easy to add. For the moment I'm using
dump-group-to-file.
> Why not simply call (restore-desktop "~/mydesktop.dump") at the end of
> your rc file? I suppose it's nice that it's automatic...
>
Yes automatic is...nice. But the main reason is because I'm using the
same rc file on multiple computers some having multiple screens others
having only one. So per-group dump is easier to 'maintain'...
The other point is I don't want to have all groups all the time since I
find this annoying when using gnext/gprev commands.
Ho and last point, I don't always want an application to start on the
same screen, with automatic group restore I can have my layout on every
screen I want (yes I'm using separate X screens).
About this last point, one thing I find annoying now is errors when you
restore a dump on a screen with a different resolution. It 'works' if
you restore a smaller resolution dump but crash when you restore a
bigger one. IIRC male has some automatic dump resize code somewhere so I
didn't look into this problem so much but it could be nice to have such
a feature.
> Here are some notes I took while looking at the patch:
>
> > It add one parameter:
> > *group-dump-dir* which should point to a directory containing dumped
> > frames to restore if needed.
>
> This is a good thing to have! I added a macro and variable,
> with-data-file and *data-dir*, that can be used to store stumpwm
> relevant data.
>
This is a good idea !
> > And three parameters to rule definition:
> > :dump-name: key parameter defining the dump file to restore instead of a
> > one with the group name.
>
> Why is this in the frame rule? It seems like it should be stored per
> group somehow, not per frame.
>
I put this in the frame rule because I didn't want to break everything
by creating new rules only for groups. Ho and it's also usefull with the
'restore' flag which force group restore every time a rule matches.
One example for using this is editing some latex document in emacs, most
of the time I have emacs in its own group with only one frame. But when
editing this kind of document, I often want to have xdvi next to my
emacs frame. So when I launch xdvi a new rules match and restore a
specific layout for my emacs group (using another dump file) like this:
(define-frame-preference "Emacs"
(1 t t t t :dump-name "emacs-dvi-document" :title "...xdvi")
(0 t t t nil :class "Emacs"))
This is why I finally kept the per-frame create/restore parameters.
> > create: when set, a new group is created as needed and if a dump file
> > named as the group exists it is used to restore the group layout.
> > restore: force layout to be restored even if the group exists (this may
> > be used along with :dump-name option)
>
> I think it would be best for backwards compatibility if these were
> keyword arguments so that existing define-frame-preference calls
> aren't broken.
>
Yes, good idea too, I don't know why I've done it this way. Well the
&rest keys &keys arguments are a bit disturbing when you get into this
part of the code so I think it was easier to do it that way. But the
:dump-name argument makes me think I finally managed to do this. So...
well good idea, don't know why this is not already done...
> In get-window-placement, you do:
>
> (if group
> ...
> (if create
> ...
> ...))
>
> In this case you should use a cond:
>
> (cond (group
> ...)
> (create
> ...)
> (t
> ...))
>
> -Shawn
>
hehe, as always I tend to send patches before cleaning the code etc.
Since then I also found a bug when forcing group restore with a missing
dump file. This can be fixed by using the probe-file function. I can
send a patch for this too but the recent modifications in the git
repository may make this hard to apply... .
If you want some proper single patch against current git repository ask
me on #stumpwm (I may need some help to merge all commits in a single
patch).
>
> _______________________________________________
> Stumpwm-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/stumpwm-devel
--
Morgan Veyret (address@hidden)
http://appart.kicks-ass.net/patzy