FVWM: GSoC 2012: Project ideas

[Thomas Funk]

Comments welcome, or even ideas.

What about

- RANDR support? Switching resolutions without restart Fvwm would be nice.

- extend FvwmForm? I used it in my config, but it lacks in some places.
I think, it's a nice tool to create GUI based parts.
It could replace FvwmGtk which is a little bit outdated (as I know it
supports only Gtk1. There was an attempt to port it to Gtk2 but Gtk3 is
the future...) in some ways.

- add support for Wayland ... ok, probably too much for a GSoc project
... but as an idea?

Regards,
Thomas

[Thomas Adam]

Post by Thomas Funk

Comments welcome, or even ideas.

What about
- RANDR support? Switching resolutions without restart Fvwm would be nice.

This one is fine. I've already a head-start in this.

Post by Thomas Funk
- extend FvwmForm? I used it in my config, but it lacks in some
places. I think, it's a nice tool to create GUI based parts.

Extend how? As far as I see it, we need one or the other in terms of
FvwmForm or FvwmScript. Currently they both do subtle things when comparinf
one to the other. But if a project was born to somehow unify them (and to
keep the name FvwmForm) I would not object.

Post by Thomas Funk
It could replace FvwmGtk which is a little bit outdated (as I know
it supports only Gtk1. There was an attempt to port it to Gtk2 but
Gtk3 is the future...) in some ways.

The comparison here ends, as far as I am concerned. No further mention of
GTK is needed.

Post by Thomas Funk
- add support for Wayland ... ok, probably too much for a GSoc
project ... but as an idea?

Considering Wayland is as experimental as XCB, consider this an outright
"No".

-- Thomas Adam

[Jaimos Skriletz]

Comments welcome, or even ideas.

Another suggestion for possible projects (seems this list is getting big so any presepctive programer will have plenty to choose from) is a better Menu system. The main thing I am intersted in seeing is more control over what a single menu entry can do.

There are basically two basic ways to go about this, and I think the first is probabaly the better fit but the second could be nice if someone has the time desire.

1) Modify/extend the current menu system to offer more configurability, the main thing I am looking for here is say allow for multiple mouse bindings per menu entry (a right click and left click could do different things). I think FvwmButtons as an example is good for this, each menu item is given a list of options/commands. This would allow people to design menus to have say submenus on a right click while a default action on a left click which is a common feature in lots of wm/de.

2) Rewrite the menu syntax and redsign the object, there was some talk about this on the mailing list years ago now and some good ideas for improving menus. I don't think this is needed for adding just a few features to the current menu and it would break a lot of scripts (fvwm-menu-desktop, fvwm-menu-directory, and even distro specific menu generation scripts).

jaimos

[Thomas Adam]

Post by Jaimos Skriletz
1) Modify/extend the current menu system to offer more configurability,
the main thing I am looking for here is say allow for multiple mouse
bindings per menu entry (a right click and left click could do different
things). I think FvwmButtons as an example is good for this, each menu
item is given a list of options/commands. This would allow people to
design menus to have say submenus on a right click while a default action
on a left click which is a common feature in lots of wm/de.

I've asked for this in the past, but as a project per-se leaves very little
jobs to do. I don't think this is appropriate for a student of GSoC. It
would be over within a few days. Besides which, it's already in the TODO
file.

Post by Jaimos Skriletz
2) Rewrite the menu syntax and redsign the object, there was some talk
about this on the mailing list years ago now and some good ideas for

And the link to that thread is?

-- 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.)

[Jaimos Skriletz]

Post by Thomas Adam

Post by Jaimos Skriletz
2) Rewrite the menu syntax and redsign the object, there was some talk
about this on the mailing list years ago now and some good ideas for

And the link to that thread is?

http://www.mail-archive.com/fvwm-***@lists.math.uh.edu/msg07167.html

Seems like the idea was liked at the time, but mostly just died. Though as I said it would be possible to get everything done in the current menu syntax, I do like some of the ideas in the newer menu syntax suggestions in the thread.

Also I'm sure we can imporve/change some of the ideas since that post was form 2002.

jaimos

[Thomas Adam]

Post by Thomas Adam

Post by Jaimos Skriletz
2) Rewrite the menu syntax and redsign the object, there was some talk
about this on the mailing list years ago now and some good ideas for

And the link to that thread is?

Hmm. This is terrible. If only because menus are treated here as some kind
of alien-citizen and if this suggestion was to ever go through they should
be treated the same way in FVWM like any other entity.

-- Thomas Adam

[Dan Espen]

Post by Thomas Adam

Post by Thomas Adam

Post by Jaimos Skriletz
2) Rewrite the menu syntax and redsign the object, there was some talk
about this on the mailing list years ago now and some good ideas for

And the link to that thread is?

Hmm. This is terrible. If only because menus are treated here as some kind
of alien-citizen and if this suggestion was to ever go through they should
be treated the same way in FVWM like any other entity.

Seems to be a lot of change with no new function.

As I understand it, Fvwm can be accepting commands from many sources at
the same time. Various modules can send commands to Fvwm, each is
sent one at a time. I don't believe "+" is handled as it should be
to account for this.

This new design would make that worse.

[Thomas Adam]

Post by Dan Espen

Post by Thomas Adam

Post by Thomas Adam

Post by Jaimos Skriletz
2) Rewrite the menu syntax and redsign the object, there was some talk
about this on the mailing list years ago now and some good ideas for

And the link to that thread is?

Hmm. This is terrible. If only because menus are treated here as some kind
of alien-citizen and if this suggestion was to ever go through they should
be treated the same way in FVWM like any other entity.

Seems to be a lot of change with no new function.

It's not that so much that. Menus are treated separately from functions --
and in some respect they need to be, yet their syntax and operation can also
be similar. Moreso in that the way they're styled is separate from normal
windows (for technical reasons only).

I don't deny that the feature-request for this is a good thing, but I do not
think gleaming anything from that thread in terms of its implementation
merits anything, especially not when comparing it to how menus are handled
now.

Post by Dan Espen
As I understand it, Fvwm can be accepting commands from many sources at
the same time. Various modules can send commands to Fvwm, each is
sent one at a time. I don't believe "+" is handled as it should be
to account for this.

Well there's no real way to send a "+" command from a module and its use
outside of a configuration file is going to be ambiguous and at best
completely undefined. And to be honest, that behaviour away from where "+"
is used *should* be that way.

If there's a good enough case to demonstrate where the "+" command
falls-short, I'd entertain a bug-fix to this, but I would want to see some
test-cases to show how it's been fixed so as not to interrupt or break its
current behaviour, which works just fine.

-- Thomas Adam

[Dan Espen]

Post by Thomas Adam

Post by Dan Espen

Post by Thomas Adam

Post by Thomas Adam

Post by Jaimos Skriletz
2) Rewrite the menu syntax and redsign the object, there was some talk
about this on the mailing list years ago now and some good ideas for

And the link to that thread is?

Hmm. This is terrible. If only because menus are treated here as some kind
of alien-citizen and if this suggestion was to ever go through they should
be treated the same way in FVWM like any other entity.

Seems to be a lot of change with no new function.

It's not that so much that. Menus are treated separately from functions --
and in some respect they need to be, yet their syntax and operation can also
be similar. Moreso in that the way they're styled is separate from normal
windows (for technical reasons only).
I don't deny that the feature-request for this is a good thing, but I do not
think gleaming anything from that thread in terms of its implementation
merits anything, especially not when comparing it to how menus are handled
now.

Post by Dan Espen
As I understand it, Fvwm can be accepting commands from many sources at
the same time. Various modules can send commands to Fvwm, each is
sent one at a time. I don't believe "+" is handled as it should be
to account for this.

Well there's no real way to send a "+" command from a module and its use
outside of a configuration file is going to be ambiguous and at best
completely undefined. And to be honest, that behaviour away from where "+"
is used *should* be that way.
If there's a good enough case to demonstrate where the "+" command
falls-short, I'd entertain a bug-fix to this, but I would want to see some
test-cases to show how it's been fixed so as not to interrupt or break its
current behaviour, which works just fine.

A module (like FvwmCpp) could be reading user written config files and
transforming them some way which would end up with Fvwm potentially
getting "+" commands intermixed from multiple sources. I admit this
is a stretch, no one has ever seen it but it remains possible.

The solution would be to have the command stream's state stored for each
input command stream. I'm not saying it's necessary to do that. It
never occurs. Along similar lines, backslashes aren't accepted in most
fvwm command streams like FvwmTalk.

I think we want a design where Fvwm can perform a complete action each
time it sees a command. It mostly does.

Getting back to menus, Right now it's impossible to change or remove items
in an existing menu, you can only destroy or add to the end.
Tied in with this would be the ability to gray out menu entries.
I think you can see how this would be useful.

[Jaimos F Skriletz]

Post by Dan Espen

Post by Thomas Adam

Post by Thomas Adam

Post by Jaimos Skriletz
2) Rewrite the menu syntax and redsign the object, there was some talk
about this on the mailing list years ago now and some good ideas for

And the link to that thread is?

Hmm. This is terrible. If only because menus are treated here as some kind
of alien-citizen and if this suggestion was to ever go through they should
be treated the same way in FVWM like any other entity.

Seems to be a lot of change with no new function.
As I understand it, Fvwm can be accepting commands from many sources at
the same time. Various modules can send commands to Fvwm, each is
sent one at a time. I don't believe "+" is handled as it should be
to account for this.
This new design would make that worse.

That was something I ran across years ago and saw it as thinking about a
slightly more versatile syntax, though it is the functionality in the
long run that is desired. I like how the idea was to give each menu item
a more detailed list of properties, to allow for a larger variety in
menu design. Such as being able to apply the different MenuStyles,
Actions, etc to an individual item as opposed to the whole menu. And I
think the current menu syntax is slightly limited in the ability to
allow the above in a nice way.

Though a slight modification of the current syntax to be more like
FvwmButtons (item1, item2, item3) as another option. Something like

AddToMenu MenuName (Item="xTerm",Hotkey="t",Action (Mouse 1) Exec xterm,
Action (Mouse 3) Exec xterm -g 80x60,Colorset=,Icon=,Frame=,etc)

The change of syntax was more along the thoughts of in order to improve
functionality an improved config syntax could go hand in hand. It was
just a suggestion, but after thomas mentioned that adding most (if not
all) the functionality is on the TODO list and not a large project,
there are plenty of other ideas to work with for GSoC.

jaimos