Re: FVWM: GSoC 2012: Project ideas
On Fri, Feb 17, 2012 at 02:22:41AM -0500, MK wrote: > WRT asciidoc, Thomas mentions stuff "within the Documentation/ > directory", but I don't know what this refers to (there is no such > directory in the 2.6.4 source). In any case, I would think that it > should not be hard to parse/scrape/whatever the existing docs into a > NAME, SYNOPSIS, DESCRIPTION pattern, rather than do it all manually. Umm, I mentioned this in a previous reply to this thread. Please read that. -- Thomas Adam
Re: FVWM: GSoC 2012: Project ideas
On Fri, Feb 17, 2012 at 02:23:03AM -0500, MK wrote: > On Thu, 16 Feb 2012 11:06:46 + > Thomas Adam wrote: > > > Now that 2.6.0 is out, I'm proposing the following project (some of > > which are a continuation from previous GSoC proposals) -- none of > > which are listed in any order. > > > > * Style clean-up (Difficulty: Easy): > > > > This would involve thinking about the internal state of styles. At > > the moment, we've a complete bomb-site in fvwm/styles.c in the form > > of a huge case statement which is responsible for dishing out random > > code to act on windows. I'd like to see this mechanism replaced with > > something more like a dispatch-state, involving stucts and > > callbacks. I've very tentatively started this here: > > > > https://github.com/ThomasAdam/fvwm/commits/ta/style-cmd-tweaks > > I think I get the gist of what you want to do there. Have you thought of > using a hash table or tree in place of the a,b,c,d thing? Yes. The point isn't to care about the structure but to show how it works at the moment. There is no grouping per-se of style options other than to say which letter that option begins with, which is only done that way to satisfy a switch statement. But a tree is overkill for this because all you're really doing is a linear search -- so having: struct style_opt_struct *all_style_ops[] Would be fine for this. > > * Finer-grained style matching (Difficulty: Medium): > > > > Currently there is no direct way to match specific components of > > windows when putting styles to them -- the only way you can do this > > at the moment is through clever ordering of style lines. This > > project would therefore flesh out ideas to allow for specifiers for > > which window to match based on a windows's name, class, resource, or > > icon name. Perhaps in the form: > > > > Style (Name=xteddy,Class=XTeddy) Sticky > > Would "class" here be a new (optional) aspect of the fvwm syntax? No more so than Name, or Resource would be, yes. > > * Unification of window commands/states to provide a consistent > > interface (Difficulty: Hard) > > > > This change is huge though, and would need more discussion. > > It implies to me a lot of drastic changes to the way the way the > configuration is currently. Are you sure that is a good idea? Absolutely it is a good idea. You can't keep using that as an excuse to disallow changes, and managing the migration wouldn't be too difficult. -- Thomas Adam
Re: FVWM: GSoC 2012: Project ideas
On Fri, 17 Feb 2012 09:45:07 + Thomas Adam wrote: > On Fri, Feb 17, 2012 at 02:23:03AM -0500, MK wrote: > > On Thu, 16 Feb 2012 11:06:46 + > > Thomas Adam wrote: > > > * Style clean-up (Difficulty: Easy): > > > > > > This would involve thinking about the internal state of styles. > > > At the moment, we've a complete bomb-site in fvwm/styles.c in the > > > form of a huge case statement which is responsible for dishing > > > out random code to act on windows. I'd like to see this > > > mechanism replaced with something more like a dispatch-state, > > > involving stucts and callbacks. I've very tentatively started > > > this here: > > > > > > https://github.com/ThomasAdam/fvwm/commits/ta/style-cmd-tweaks > > > > I think I get the gist of what you want to do there. Have you > > thought of using a hash table or tree in place of the a,b,c,d thing? > > Yes. The point isn't to care about the structure but to show how it > works at the moment. There is no grouping per-se of style options > other than to say which letter that option begins with, which is only > done that way to satisfy a switch statement. But a tree is overkill > for this because all you're really doing is a linear search -- so > having: > > struct style_opt_struct *all_style_ops[] > > Would be fine for this. Fair enough. There are only a hundred or so of them anyway, and I presume that happens (mostly) at start-up. > > > * Finer-grained style matching (Difficulty: Medium): > > > > > > Currently there is no direct way to match specific components of > > > windows when putting styles to them -- the only way you can do > > > this at the moment is through clever ordering of style lines. > > > This project would therefore flesh out ideas to allow for > > > specifiers for which window to match based on a windows's name, > > > class, resource, or icon name. Perhaps in the form: > > > > > > Style (Name=xteddy,Class=XTeddy) Sticky > > > > Would "class" here be a new (optional) aspect of the fvwm syntax? > > No more so than Name, or Resource would be, yes. Those are passed thru from xlib, correct? I did not realize fvwm used all that, I've only ever just used the name, but looking at the manpage I notice it does. So the idea here would be to allow combinations of properties rather than a single one? Something I've thought a few times -- it may already be possible, but I don't think so -- would be the ability to label windows in the fvwm Exec command and use those labels with Style. That would allow you to have two different possible styles set up for applications (eg, terminal emulators) that otherwise have identical X properties. > > > * Unification of window commands/states to provide a consistent > > > interface (Difficulty: Hard) > > > > > > This change is huge though, and would need more discussion. > > > > It implies to me a lot of drastic changes to the way the way the > > configuration is currently. Are you sure that is a good idea? > > Absolutely it is a good idea. You can't keep using that as an excuse > to disallow changes, and managing the migration wouldn't be too > difficult. Fair enough again. It would not upset me particularly, and I suppose the rest of the user base could be more excited than ticked off. If you did get two people from GSOC, to what extent do you think these various tasks could be done concurrently? MK -- "Enthusiasm is not the enemy of the intellect." (said of Irving Howe) "The angel of history[...]is turned toward the past." (Walter Benjamin)
Re: FVWM: GSoC 2012: Project ideas
On Fri, 17 Feb 2012 09:46:34 + Thomas Adam wrote: > On Fri, Feb 17, 2012 at 02:22:41AM -0500, MK wrote: > > WRT asciidoc, Thomas mentions stuff "within the Documentation/ > > directory", but I don't know what this refers to (there is no such > > directory in the 2.6.4 source). In any case, I would think that it > > should not be hard to parse/scrape/whatever the existing docs into a > > NAME, SYNOPSIS, DESCRIPTION pattern, rather than do it all manually. > > Umm, I mentioned this in a previous reply to this thread. Please > read that. Okay, I found that directory on github. -- "Enthusiasm is not the enemy of the intellect." (said of Irving Howe) "The angel of history[...]is turned toward the past." (Walter Benjamin)
Re: FVWM: GSoC 2012: Project ideas
On Fri, Feb 17, 2012 at 10:33:51AM -0500, MK wrote: > On Fri, 17 Feb 2012 09:45:07 + > Thomas Adam wrote: > > No more so than Name, or Resource would be, yes. > > Those are passed thru from xlib, correct? I did not realize fvwm used > all that, I've only ever just used the name, but looking at the manpage > I notice it does. Well, yes. It's tied to Xlib. That's how all of this works. > So the idea here would be to allow combinations of properties rather > than a single one? Correct. At the moment we match class or resource or name or visible name. See fvwm/style.c:fw_match_style_id(). These values come out of xlib in so much that all windows have to set those properties. If I need to explain all of this, I'm happy to, but you'll need to contact me off-list for that. So yes, we'd want to basically allow the user to specify those individually and instead combine them: Style (Class=,Name=Resource=) ... > Something I've thought a few times -- it may already be possible, but I > don't think so -- would be the ability to label windows in the fvwm Exec > command and use those labels with Style. That would allow you to have > two different possible styles set up for applications (eg, terminal > emulators) that otherwise have identical X properties. Umm, I don't follow you here. But see the WindowStyle command which instead uses the window's ID internally to make out the individual windows. > > > > * Unification of window commands/states to provide a consistent > > > > interface (Difficulty: Hard) > > > > > > > > This change is huge though, and would need more discussion. > > > > > > It implies to me a lot of drastic changes to the way the way the > > > configuration is currently. Are you sure that is a good idea? > > > > Absolutely it is a good idea. You can't keep using that as an excuse > > to disallow changes, and managing the migration wouldn't be too > > difficult. > > Fair enough again. It would not upset me particularly, and I suppose > the rest of the user base could be more excited than ticked off. Well that's not my intention with this either. I am saying that whilst the changes I'm tentatively proposing are quite wide-ranging, taking a typical FVWM config file and updating its syntax to suit wouldn't be too hard. > If you did get two people from GSOC, to what extent do you think these > various tasks could be done concurrently? To some extent, yes. There might be some correlation needed though. -- Thomas Adam
Re: FVWM: GSoC 2012: Project ideas
"Thomas Adam" wrote: >> 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 -- What is the exact difference between a 'terminal', a 'shell', a 'tty' and a 'console'? A terminal is at the end of an electric wire, a shell is the home of a turtle, tty is a strange abbreviation and a console is a kind of cabinet. -- Gilles
Re: FVWM: GSoC 2012: Project ideas
On Fri, Feb 17, 2012 at 08:38:06PM +0100, Thomas Funk wrote:
> "Thomas Adam" wrote:
> >> 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.
> - 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.
> 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.
> - 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
--
"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: FVWM: GSoC 2012: Project ideas
On Fri, Feb 17, 2012 at 08:06:46PM +, Thomas Adam wrote: > On Fri, Feb 17, 2012 at 08:38:06PM +0100, Thomas Funk wrote: > > "Thomas Adam" wrote: > > >> 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
Re: FVWM: GSoC 2012: Project ideas
On Fri, Feb 17, 2012 at 01:44:12PM -0700, Jaimos Skriletz wrote:
> 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.
> 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.)
Re: FVWM: GSoC 2012: Project ideas
> > 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-workers@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
Re: FVWM: GSoC 2012: Project ideas
On Fri, Feb 17, 2012 at 02:10:54PM -0700, Jaimos Skriletz wrote:
> > > 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-workers@lists.math.uh.edu/msg07167.html
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
--
"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: FVWM: GSoC 2012: Project ideas
Thomas Adam writes: > On Fri, Feb 17, 2012 at 02:10:54PM -0700, Jaimos Skriletz wrote: >> > > 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-workers@lists.math.uh.edu/msg07167.html > > 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. -- Dan Espen
Re: FVWM: GSoC 2012: Project ideas
On Fri, Feb 17, 2012 at 05:49:00PM -0500, Dan Espen wrote:
> Thomas Adam writes:
>
> > On Fri, Feb 17, 2012 at 02:10:54PM -0700, Jaimos Skriletz wrote:
> >> > > 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-workers@lists.math.uh.edu/msg07167.html
> >
> > 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.
> 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
--
"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: FVWM: GSoC 2012: Project ideas
Thomas Adam writes: > On Fri, Feb 17, 2012 at 05:49:00PM -0500, Dan Espen wrote: >> Thomas Adam writes: >> >> > On Fri, Feb 17, 2012 at 02:10:54PM -0700, Jaimos Skriletz wrote: >> >> > > 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-workers@lists.math.uh.edu/msg07167.html >> > >> > 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. > >> 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. -- Dan Espen
