Re: [STUMP] Placement rules, automatic group create/restore

[Morgan Veyret]

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