Re: Deprecation: Let's talk once more about removing $STUFF...Setup Form

On Thu, Jun 09, 2016 at 06:20:22PM -0600, Jaimos Skriletz wrote: > On Thu, Jun 9, 2016 at 4:45 AM, Thomas Adam wrote: > > > On Fri, Jun 03, 2016 at 02:21:51AM +0100, Thomas Adam wrote: > > Any lasting objections before this is merged and we can move onto the next > > phase with is introducing a d

Re: Deprecation: Let's talk once more about removing $STUFF...Setup Form

On Thu, Jun 9, 2016 at 4:45 AM, Thomas Adam wrote: > On Fri, Jun 03, 2016 at 02:21:51AM +0100, Thomas Adam wrote: > Any lasting objections before this is merged and we can move onto the next > phase with is introducing a default configuration? > > ​I have some ideas on a default configuration I w

Re: Deprecation: Let's talk once more about removing $STUFF...Setup Form

On Fri, Jun 03, 2016 at 02:21:51AM +0100, Thomas Adam wrote: > We put in place something different. We've had proposals about that in the > past (Nick Fortune). I'm wanting to hear from others about what that might > look like. Call for last orders, Gentlemen... Any lasting objections before th

Re: Deprecation: Let's talk once more about removing $STUFF...Setup Form

On Thu, Jun 02, 2016 at 09:08:24PM -0400, Dan Espen wrote: > What they gain, and what it was meant for, is new users curious about > Fvwm. Without a config, the casual user will get no where > and most likely look somewhere else. > The WM came up and you couldn't even create a window. > Previous t

Re: Deprecation: Let's talk once more about removing $STUFF...Setup Form

Thomas Adam writes: > On Thu, Jun 02, 2016 at 03:07:27PM -0400, Dan Espen wrote: >> In the case of FvwmForm and the Setup Form, I think you've eliminated >> something that I remember at least one poster using. It's not the >> best part of Fvwm, but the Setup Form gets a certain class of users >>

Re: Deprecation: Let's talk once more about removing $STUFF...

2016-05-19 17:18 GMT+02:00 Thomas Adam : > As I understand it, FVWM was written with extensibility in mind, and hence > could be extended through the use of modules. Although the core of FVWM is > quite a bit larger now (read: some of the things ther could be modules, but > hey-ho, one for another

Re: Deprecation: Let's talk once more about removing $STUFF...

On Thu, Jun 02, 2016 at 11:25:22PM +0200, Thomas Funk wrote: > On 06/02/2016 10:53 PM, Thomas Adam wrote: > > Perl is my $DAYJOB, I'm more than capable. It's just low on my list. > I don't want to offend you with my offer ... I'm only want to relieve you Oh, not at all. But there's a lot more to

Re: Deprecation: Let's talk once more about removing $STUFF...

On 06/02/2016 10:53 PM, Thomas Adam wrote: Perl is my $DAYJOB, I'm more than capable. It's just low on my list. I don't want to offend you with my offer ... I'm only want to relieve you But hey, no prob ... Best, Thomas -- -- "Two things are infinite: the universe and human stupidity; and I'

Re: Deprecation: Let's talk once more about removing $STUFF...

On Thu, Jun 02, 2016 at 10:50:50PM +0200, Thomas Funk wrote: > That's not completely true because Gtk3-Perl isn't that stable as Gtk2-perl. > That's the point why I decided to use Gtk2-perl for SimpleGtk2 [0]. There're > not much examples and documentation available as for Gtk2-perl. Gtk3-perl > s

Re: Deprecation: Let's talk once more about removing $STUFF...

On 06/02/2016 10:39 PM, Thomas Adam wrote: It has to transition to GTK3. Otherwise it's just as stale as GTK1.x is now in terms of how well it has not been maintained. That's not completely true because Gtk3-Perl isn't that stable as Gtk2-perl. That's the point why I decided to use Gtk2-perl f

Re: Deprecation: Let's talk once more about removing $STUFF...

On Thu, Jun 02, 2016 at 10:35:48PM +0200, Thomas Funk wrote: > I'm using its code as a base for a Fvwm module to use SimpleGtk2 for my > Fvwm-Nightshade GUIs invoked by Fvwm. It isn't a problem for me that you have > removed it but it shows very nice how to create a module derived from > FVWM::Modu

Re: Deprecation: Let's talk once more about removing $STUFF...

On 06/02/2016 09:50 PM, Thomas Adam wrote: Those people who do decide to use the mechanism of what the Setup forms provide, clearly can't be relying on much. So what do they gain by using these configs? Maybe it's the FvwmButtons configuration? I can't say, but I'd guess that over anything els

Re: Deprecation: Let's talk once more about removing $STUFF...

On Thu, Jun 02, 2016 at 03:07:27PM -0400, Dan Espen wrote: > In the case of FvwmForm and the Setup Form, I think you've eliminated > something that I remember at least one poster using. It's not the > best part of Fvwm, but the Setup Form gets a certain class of users > from befuddled to a working

Re: Deprecation: Let's talk once more about removing $STUFF...

Thomas Adam writes: > On Tue, May 31, 2016 at 08:44:23PM -0400, Dan Espen wrote: >> If you want to open this can of worms, I think some streamlining might >> be in order, that's up to you. I think it's a very good thing that Fvwm >> has at least a minimal way to create a working configuration wi

Re: Deprecation: Let's talk once more about removing $STUFF...

On Tue, May 31, 2016 at 08:44:23PM -0400, Dan Espen wrote: > If you want to open this can of worms, I think some streamlining might > be in order, that's up to you. I think it's a very good thing that Fvwm > has at least a minimal way to create a working configuration without > resorting to overbl

Re: Deprecation: Let's talk once more about removing $STUFF...

Thomas Adam writes: > On Tue, May 31, 2016 at 04:58:57PM -0400, Dan Espen wrote: >> Fvwm uses FvwmTaskBar, for example in file: >> >> sample.fvwmrc/system.fvwm2rc-sample-95 >> >> Those uses need to be eliminated before the module goes. > > Thanks. Removed the whole lot, in favour of out-of-tre

Re: Deprecation: Let's talk once more about removing $STUFF...

> > I still have FvwmWinList on a button in case I get some rogue window > > that FvwmProxy doesn't represent, but, honestly, it isn't a big deal. > I'd consider that a bug in FvwmProxy, in which case, please fix it. > FvwmWinList is going the way of the Dodo... I think "suppression" is a better

Re: Deprecation: Let's talk once more about removing $STUFF...

On Tue, May 31, 2016 at 2:30 PM, Thomas Funk wrote: > On 05/31/2016 09:30 PM, Thomas Adam wrote: > >> >> On 19 May 2016 4:18 p.m., "Thomas Adam" > tho...@fvwm.org>> wrote: >> > >> > Hey all, >> > >> > The last time this came up for conversation [0] things were far from >> ideal. I >> > want

Re: Deprecation: Let's talk once more about removing $STUFF...

On Tue, May 31, 2016 at 2:46 PM, Jason Weber wrote: > > I still have FvwmWinList on a button in case I get some rogue window > that FvwmProxy doesn't represent, but, honestly, it isn't a big deal. > > ​You can also use WindowList and get a list of all the windows (under certain conditions) in a m

Re: Deprecation: Let's talk once more about removing $STUFF...

On Tue, May 31, 2016 at 01:46:55PM -0700, Jason Weber wrote: > > I'll leave CPP and M4 for now as I'd like to try something with them. > > Is there something we're supposed to be using to replace FvwmM4? No. > Also, I am quietly watching to make sure you don't mention any module > I am criticall

Re: Deprecation: Let's talk once more about removing $STUFF...

On Tue, May 31, 2016 at 04:58:57PM -0400, Dan Espen wrote: > Fvwm uses FvwmTaskBar, for example in file: > > sample.fvwmrc/system.fvwm2rc-sample-95 > > Those uses need to be eliminated before the module goes. Thanks. Removed the whole lot, in favour of out-of-tree configurations via fvwm-{theme

Re: Deprecation: Let's talk once more about removing $STUFF...

> I'll leave CPP and M4 for now as I'd like to try something with them. Is there something we're supposed to be using to replace FvwmM4? I set it up in my .fvwm2rc 25 years ago and it seems to still be working fine. As far as I recall, it is just include(), define(), ifdef(), and ifelse(). Also,

Re: Deprecation: Let's talk once more about removing $STUFF...

Thomas Adam writes: > On 31 May 2016 9:31 p.m., "Thomas Funk" wrote: >> >> On 05/31/2016 09:30 PM, Thomas Adam wrote: >> >>> >>> On 19 May 2016 4:18 p.m., "Thomas Adam" > wrote: >>> > >>> > Hey all, >>> > >>> > The last time this came up for conversation [0] things were

Re: Deprecation: Let's talk once more about removing $STUFF...

On 31 May 2016 9:31 p.m., "Thomas Funk" wrote: > > On 05/31/2016 09:30 PM, Thomas Adam wrote: > >> >> On 19 May 2016 4:18 p.m., "Thomas Adam" > wrote: >> > >> > Hey all, >> > >> > The last time this came up for conversation [0] things were far from ideal. I >> > want to have another conversa

Re: Deprecation: Let's talk once more about removing $STUFF...

On 05/31/2016 09:30 PM, Thomas Adam wrote: On 19 May 2016 4:18 p.m., "Thomas Adam" mailto:tho...@fvwm.org>> wrote: > > Hey all, > > The last time this came up for conversation [0] things were far from ideal. I > want to have another conversation about this to see whether it's possible to

Re: Deprecation: Let's talk once more about removing $STUFF...

On 19 May 2016 4:18 p.m., "Thomas Adam" wrote: > > Hey all, > > The last time this came up for conversation [0] things were far from ideal. I > want to have another conversation about this to see whether it's possible to > state the case why some modules in FVWM should be removed. Anyone? Thoma

Re: Deprecation: Let's talk once more about removing $STUFF...

On Thu, May 19, 2016 at 01:07:26PM -0400, Dan Espen wrote: > Seemed like a valid use. Not sure if our condition testing > can do the same thing: > > #if PLANES > 8 > + TitleStyle LeftJustified\ > ActiveUp (\ > HGradient 128 2 rgb:FF/00/00 70 rgb:88/00/88 30 rgb:00/00/ff)\ > Inactive

Re: Deprecation: Let's talk once more about removing $STUFF...

On Thu, May 19, 2016 at 08:27:54PM +0200, Stefan Blachmann wrote: > Personally I'd rather prefer to keep FvwmWinList as I use it myself > and am not really eager spend time to modify my config, as I use it as > a sort of life saver rarely only when I lost track where a particular > window is. I'm

Re: Deprecation: Let's talk once more about removing $STUFF...

On Thu, May 19, 2016 at 11:57:17AM -0600, Jaimos Skriletz wrote: > ​I do agree that FvwmTaskBar should be deprecated and FvwmIconMan should be > used instead, but my experience is FvwmIconMan was not easy to create a > config that behaved like the simple FvwmTaskBar, and I still think many are > us

Re: Deprecation: Let's talk once more about removing $STUFF...

On Thu, May 19, 2016 at 01:07:26PM -0400, Dan Espen wrote: > I'm not using anything else you mentioned, so no problem. > But I'm unsure what problem some of them cause just hanging around. They're not used, and are bit-rotting. Almost all of the Fvwm modules I've listed here fall into the categor

Re: Deprecation: Let's talk once more about removing $STUFF...

In addition to what Jaimos said, at least in my impression FvwmWinList is still being used much. I saw it in quite a few out-of-the-box fvwm configs supplied by various linux and other unixoid OS distros. So I guess dropping it could cause some work for maintainers etc. Thus I think Jaimos' idea of

Re: Deprecation: Let's talk once more about removing $STUFF...

On Thu, May 19, 2016 at 11:07 AM, Dan Espen wrote: > Just had an opportunity to look at Fvwm.Org, it looks pretty nice. > I thought we were going to retain the themeing, but I don't see it. > Not a real problem. > ​ > ​Being a static site and only using html and javascript it makes being able to

Re: Deprecation: Let's talk once more about removing $STUFF...

On Thu, May 19, 2016 at 9:18 AM, Thomas Adam wrote: > > * FvwmTaskBar -- Use FvwmIconMan. > > ​I do agree that FvwmTaskBar should be deprecated and FvwmIconMan should be used instead, but my experience is FvwmIconMan was not easy to create a config that behaved like the simple FvwmTaskBar, and I

Re: Deprecation: Let's talk once more about removing $STUFF...

Thomas Adam writes: > Hey all, > > The last time this came up for conversation [0] things were far from ideal. I > want to have another conversation about this to see whether it's possible to > state the case why some modules in FVWM should be removed. > > As I understand it, FVWM was written wi

Deprecation: Let's talk once more about removing $STUFF...

Hey all, The last time this came up for conversation [0] things were far from ideal. I want to have another conversation about this to see whether it's possible to state the case why some modules in FVWM should be removed. As I understand it, FVWM was written with extensibility in mind, and henc