Re: mvwm - things I'd like to see
On Thu, Sep 04, 2014 at 12:04:09AM +0200, Thomas Funk wrote: > The most part I am missing is dynamic parts like growing FvwmButtons > => add a button on the fly without restart the module. I second this. FvmwButtons configuration is a *pain*. Eventually the new "*vwmGui" module should provide easy configuration as well as a rich feature set. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: "GetNextSimpleOption" "is broken"
On Wed, Sep 03, 2014 at 10:39:39PM +0100, Thomas Adam wrote: > On Tue, Sep 02, 2014 at 11:14:11PM +0100, Dominik Vogt wrote: > > On Tue, Sep 02, 2014 at 11:09:49PM +0100, Thomas Adam wrote: > > > On 2 September 2014 23:04, Dominik Vogt wrote: > > > > Can you write the missing sub-rule for the Test command > > > > (the one that has to do with infostore)? > > > > > > Will do in the next half-hour or so. > > > > Great. This is the last missing piece of the conditional commands. > > I'm eager to get over with the basic parsing description draft so > > I can try some practical things. :-) > > Are we OK to lay a steak in the ground, and for me to merge > document-parsing to master? I don't really care whether it's in the master or elsewhere. > Then we can consider what to do next, etc? I'd like to gather some experience with splitting functions into interface and implementation before tackling the real parser. > We can always continue fleshing this out over time, etc. Yes. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: mvwm - things I'd like to see
Michael Treibton wrote: > On 3 September 2014 22:27, Dominik Vogt wrote: >> On Wed, Sep 03, 2014 at 10:01:37PM +0100, Michael Treibton wrote: >>> Here's some of the things I'd like: >>> >>> - no more motif borders (horrible) >> >> With fvwm you can more or less configure every border style you >> want. Have you tried the themes package? Theming could be better >> integrated into the distribution, though. > > fvwm-themes? Seems old and didn't work well for me last time. is it > still developed? No, since years. but you can try Fvwm-Nightshade. Have a look on the development branch: https://github.com/Fvwm-Nightshade/Fvwm-Nightshade/tree/develop >>> - fluxbox style window borders >> >> Borders in fluxbox are also very configurable. Do you have a >> screenshot of what you mean? > > Here is one: http://files.samhart.net/img/misc/flux-tab-example.png - > look at the bottom border. > >>> - diff. border colors for each side >> >> Can already be done with pixmap borders. > > but why must i make pixmaps for each color that i want? i have > colorsets for this, don't i? > >> Could you please elaborate on what you think fvwm is missing in >> terms of scripting flexibility? (Other than fvwm's scripting >> language can be awkward - we're working on that.) > > That, and i don't like perl? Everything is using dedicating embedded > things like lua from the outset, so why can't this wm? you can use every scripting language in FVWM via PipeRead but Perl is best integrated. There's exist a lua module but haven't tested it: http://box-look.org/content/show.php/FvwmLua+0.4?content=127229 Also a Python library: http://barry.warsaw.us/software/fvwm.html >> Note that mvwm is not going to be a brand new window manager that >> does everything from scratch. It will be a very much improved fvwm >> with maybe a few antique things removed. Regarding window >> handling and window decorations it won't change much for now. > > i think i understand that, yes. But i don't always see if this > approach is good or not - why not write it from scratch? wasn't that > the original intent? The most part I am missing is dynamic parts like growing FvwmButtons => add a button on the fly without restart the module. But most things can be made with FVWM. -- Thomas -- -- -- "Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe." -- Albert Einstein
Re: mvwm - things I'd like to see
On Wed, Sep 03, 2014 at 10:42:38PM +0100, Michael Treibton wrote:
> On 3 September 2014 22:27, Dominik Vogt wrote:
> > On Wed, Sep 03, 2014 at 10:01:37PM +0100, Michael Treibton wrote:
> >> Here's some of the things I'd like:
> >>
> >> - no more motif borders (horrible)
> >
> > With fvwm you can more or less configure every border style you
> > want. Have you tried the themes package? Theming could be better
> > integrated into the distribution, though.
>
> fvwm-themes? Seems old and didn't work well for me last time. is it
> still developed?
It isn't developed in earnest anymore. AFAIK, I was the last one to
touch the CVS repository on Sourceforge, but those efforts weren't
released. I updated some of the configuration syntax to bring it inline
with changes to the stable releases, etc.
But really, there's not a lot else to do to it. It's stable in its
approach to how it sets out themes, etc., and since that point there's
been other projects to mimick that, notably fvwm-crystal and
fvwm-nightshade.
> >> - fluxbox style window borders
> >
> > Borders in fluxbox are also very configurable. Do you have a
> > screenshot of what you mean?
>
> Here is one: http://files.samhart.net/img/misc/flux-tab-example.png -
> look at the bottom border.
Not possible without a patch. I think I recall one from years ago, but
I wasn't going to apply it as I seem to recall it was invasive in its
approach, and hard-coded a number of assumptions.
> >> - diff. border colors for each side
> >
> > Can already be done with pixmap borders.
>
> but why must i make pixmaps for each color that i want? i have
> colorsets for this, don't i?
You do have colorsets. The problem there is that the graphics context
and pixmap used to render the window frame is one rectangle; fvwm
doesn't draw individual pixmaps for each side of the border, nor for its
handles, either. I patched this years ago to support this, but it was
just a toy, and the patch likely wouldn't apply now anyway. Note that
decors in general is targetted for lots of change anyway, eventually.
Maybe this will be possible as a side-effect, who knows?
> > Could you please elaborate on what you think fvwm is missing in
> > terms of scripting flexibility? (Other than fvwm's scripting
> > language can be awkward - we're working on that.)
>
> That, and i don't like perl? Everything is using dedicating embedded
> things like lua from the outset, so why can't this wm?
Sure. $LANGUAGE_DU_JOUR notwithstanding, right? I don't like fvwm's
emulation either, but some parts of fvwm's approach are so specific to
itself that you couldn't represent that flexibility through lua or some
other language anyway (c.f. All/Next/Prev, etc.)
This isn't a new topic you're being up here. My first look at fvwm
recalls my reading of a possible merger between fvwm and scwm from
way back (amusingly even then in circa 1998 this was referred to as
'fvwm3'). But you have to be __really__ careful. You can't just "slap"
a scripting language in and expect it to cure all problems---because
having an interpreter suddenly becomes integral to how the window
manager performs. By that point, I no longer recognise fvwm as
extensible by that language, I consider the language to interact with
fvwm, and those two concepts are very different.
What we need to do is consider more closely how a module interface
exposes itself, and for it to be easier for people to use some language
of their choice to achieve their aims. This is already on the TODO
list.
> > Note that mvwm is not going to be a brand new window manager that
> > does everything from scratch. It will be a very much improved fvwm
> > with maybe a few antique things removed. Regarding window
> > handling and window decorations it won't change much for now.
>
> i think i understand that, yes. But i don't always see if this
> approach is good or not - why not write it from scratch? wasn't that
> the original intent?
No, absolutely not. I wasn't about to suggest throwing away fvwm when I
kicked this clean-up project off. Not ever. There's too much
specialist knowledge and code in fvwm in terms of window management
that you won't find anywhere else. You can't start something from
scratch and hope to get that right.
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Re: mvwm - things I'd like to see
On 3 September 2014 22:27, Dominik Vogt wrote: > On Wed, Sep 03, 2014 at 10:01:37PM +0100, Michael Treibton wrote: >> Here's some of the things I'd like: >> >> - no more motif borders (horrible) > > With fvwm you can more or less configure every border style you > want. Have you tried the themes package? Theming could be better > integrated into the distribution, though. fvwm-themes? Seems old and didn't work well for me last time. is it still developed? >> - fluxbox style window borders > > Borders in fluxbox are also very configurable. Do you have a > screenshot of what you mean? Here is one: http://files.samhart.net/img/misc/flux-tab-example.png - look at the bottom border. >> - diff. border colors for each side > > Can already be done with pixmap borders. but why must i make pixmaps for each color that i want? i have colorsets for this, don't i? > Could you please elaborate on what you think fvwm is missing in > terms of scripting flexibility? (Other than fvwm's scripting > language can be awkward - we're working on that.) That, and i don't like perl? Everything is using dedicating embedded things like lua from the outset, so why can't this wm? > Note that mvwm is not going to be a brand new window manager that > does everything from scratch. It will be a very much improved fvwm > with maybe a few antique things removed. Regarding window > handling and window decorations it won't change much for now. i think i understand that, yes. But i don't always see if this approach is good or not - why not write it from scratch? wasn't that the original intent? Michael
Re: "GetNextSimpleOption" "is broken"
On Tue, Sep 02, 2014 at 11:14:11PM +0100, Dominik Vogt wrote:
> On Tue, Sep 02, 2014 at 11:09:49PM +0100, Thomas Adam wrote:
> > On 2 September 2014 23:04, Dominik Vogt wrote:
> > > Can you write the missing sub-rule for the Test command
> > > (the one that has to do with infostore)?
> >
> > Will do in the next half-hour or so.
>
> Great. This is the last missing piece of the conditional commands.
> I'm eager to get over with the basic parsing description draft so
> I can try some practical things. :-)
Dominik,
Are we OK to lay a steak in the ground, and for me to merge
document-parsing to master? Then we can consider what to do next, etc?
We can always continue fleshing this out over time, etc.
Kindly,
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Re: mvwm - things I'd like to see
On Wed, Sep 03, 2014 at 10:01:37PM +0100, Michael Treibton wrote: > Here's some of the things I'd like: > > - no more motif borders (horrible) With fvwm you can more or less configure every border style you want. Have you tried the themes package? Theming could be better integrated into the distribution, though. > - fluxbox style window borders Borders in fluxbox are also very configurable. Do you have a screenshot of what you mean? > - xdg menus by default Isn't that more a themes issue? Fvwm's window manager core just offers the functionality. To tune it the way one wants to have it one can either write a config file or resort to the themes project. > - diff. border colors for each side Can already be done with pixmap borders. > - lua scripting interface > > i think lua is important because it lets people extend mvwm in ways > not possible right now. Have you tried fvwm's perllib? You can also already let any external program generate fvwm input with the PipeRead command, and feed it with environment variables as input. Could you please elaborate on what you think fvwm is missing in terms of scripting flexibility? (Other than fvwm's scripting language can be awkward - we're working on that.) Note that mvwm is not going to be a brand new window manager that does everything from scratch. It will be a very much improved fvwm with maybe a few antique things removed. Regarding window handling and window decorations it won't change much for now. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
mvwm - things I'd like to see
Hi, Here's some of the things I'd like: - no more motif borders (horrible) - fluxbox style window borders - xdg menus by default - diff. border colors for each side - lua scripting interface i think lua is important because it lets people extend mvwm in ways not possible right now. I've also seen weirdness with mvwm and xrandr - the multiple monitor feature just about hangs in there with functionality but i think it needs fixing. Michael
