On Tue, Jun 07, 2011 at 03:25:53PM +, Bjartur Thorlacius wrote:
> [...]
> I wasn't thinking of a single string match, but a string match for
> about every application that maps a window.
> [...]
I don't know what kind of system you run, but on my machine, the
frequency with which new windows g
On 6/6/11, Ethan Grammatikidis wrote:
> most understandable! Seriously though, adding a single extra string match
> isn't going to make much difference, nothing like whatever Gtk+ 2 does. I
> wouldn't be surprised if the entire window-matching list of a large FVWM
> config fit in 1 page of virtual
On Tue, 7 Jun 2011 01:14:05 +0100
Connor Lane Smith wrote:
> Trouble is, finding that something else is difficult.
That I can agree with. ^^
Hey,
On 6 June 2011 23:28, Ethan Grammatikidis wrote:
> I'm a little bit.. scared of perfectly decent things being cut out in the
> name of sucklessness to be honest.
It's quite a difficult decision to make, I think. With some tools,
like terminals, if they don't appear instantly it gets quite
On Fri, 3 Jun 2011 23:16:49 +
Bjartur Thorlacius wrote:
> It's just that I believe spawning processes and creating windows
> should be dirt cheap operations. Optimally, almost nothing should be
> done in those functions.
With Gtk+ 2.OMGWANTMOARBLOAT invading computers everywhere, your belief
On 6/3/11, Ethan Grammatikidis wrote:
> This is normal proceedure for FVWM and worked very smoothly on 8MB 486s.
> Even the numerous restarts needed to fine-tune FVWM configuration weren't a
> terrible problem on that old 486. In contrast, today every app has all its
> own buttons and memory usage
On Fri, 3 Jun 2011 11:32:32 +
Bjartur Thorlacius wrote:
> On 6/3/11, Ethan Grammatikidis wrote:
> > I don't get it... Back & forward are native to the browser, running programs
> > is native to any WM of FVWM's era, and app-specific buttons are a native
> > feature of FVWM, and fairly simple
On Fri, Jun 3, 2011 at 7:32 AM, Bjartur Thorlacius wrote:
> Having every maprequest checked to see if it's from surf, in which
> case buttons are to be drawn, or if it's from {mplayer
> or VLC} in which case a button is to be drawn, etc,
> instead of the surf executable containing the relevant i
On 6/3/11, Ethan Grammatikidis wrote:
> I don't get it... Back & forward are native to the browser, running programs
> is native to any WM of FVWM's era, and app-specific buttons are a native
> feature of FVWM, and fairly simple to use as FVWM features go. What am I
> missing?
>
Having every mapre
On Fri, 3 Jun 2011 09:26:57 +
Bjartur Thorlacius wrote:
> On 6/3/11, Jon Bradley wrote:
> > Here is a patch I whipped up to add forward/back navigation with xprop.
> > I use it to put buttons on the fvwm windows title bar
> > of all surf instances.
> >
> At that point, wouldn't this be bett
On 6/3/11, Jon Bradley wrote:
> Here is a patch I whipped up to add forward/back navigation with xprop.
> I use it to put buttons on the fvwm windows title bar
> of all surf instances.
>
At that point, wouldn't this be better implemented in (a wrapper around) surf?
Here is a patch I whipped up to add forward/back navigation with xprop.
I use it to put buttons on the fvwm windows title bar
of all surf instances.
https://github.com/rabbitear/my-patches
Patched 0.4.1 and also the hg repo..
xprop -id -f _SURF_NAV 8s -set _SURF_NAV
-1 goes back one page.
-
12 matches
Mail list logo
