On Thu, 16 Feb 2012 09:57:28 -0500 Dan Espen <des...@verizon.net> wrote: > Thomas Adam <tho...@fvwm.org> writes: > > 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. > > Like all open source work, > the project should meet some need of the coder. > So, whoever does the work should have some input on what gets done.
The possibility of an applicant submitting their own proposal should be definitely be left open. However, since this is also paid work, I don't think there is anything wrong with saying, "this is what the project leadership *needs* doing most". Speaking for myself, I would say that "my needs as a coder" in this regard are about finding clear and well-defined ideas set out for me, because: a) While I am personally interested in the project, I am not familiar with the source, and having a proposal set out suggests a doorway into the source. b) I'm more interested in helping the involved senior people with the tasks that they perceive to be important, or tasks that the user base has expressed interest in, than in performing my own analysis. As a long term fvwm user tho, I do naturally have some opinions... > What do you think? > > I'd like to see the initial appearance issue get some attention. I don't remember the last time I saw the default config, but if this has to do with enticing new users, to my mind working on that would first involve: - deciding who potential "new users" might be, without saying "well anybody" which leads to trying to be all things to all people and/or aiming at a lowest common denominator. - identifying fvwm's strengths and weaknesses vis. what people think about when they think about a graphical desktop, and focus on presenting the strengths, not on shoring up the weaknesses. IMO fwvm's biggest strength is its configurability, which is a challenging thing to emphasis in a default configuration. Eg: it seems to me that the "fvwm95" concept dates back to a time when gnome was still in it's infancy, and it made more sense to think in terms of an appeal to general users who did not, and might never, want or need much in the way of configurability -- instead, the appeal was about providing a familiar out of the box functionality. But if in contemporary terms configurability is fvwm's strength, there is no point in trying to appeal to people who will never make much use of it, by using it to mimic something familiar and comfortable. I'm looking back at the "New default configuration wanted" thread that started last April and was continued a bit in January. It seems that appearance is a big issue. Perhaps we could have a sort of competition around that, within the limitations that Thomas suggested (no dependency on xpm/png/svg support). Something that would emphasis configurability would be to use multiple, complementary styles. Also: - being heavy on the comments - incorporating optional commented out sections. - tieing-in something on the web I also know there is a rounded corners patch available for fvwm. I haven't tried it myself, but having a bit of web-dev in my background, I know that rounded corners are something that people associate with a "more modern" look. I don't know if this is a great GSOC item however, as it does not really involve programming. > I'm working close to that area: > > Right now, I'm trying to understand xdg menus. > We make an entry in the FvwmMenu marked: > > D: Desktop > > It's pretty clear that should be "A: Applications". > I'm pretty sure there should be a "Preferences" and > "Settings" menu. Right now, am I correct to say that xdg menu compatibility is provided by a script for converting the xml files? Presuming that application installs often use those, it might be good to include the possibility to have that automatically (or prompt to) run at start-up if the files have changed. OTOH, again taking (manual) configurability as the key strength, it might be better to just leave it up to the user to update things his/her self. > If we had a volunteer to do "drudge" work it would be nice > to move off docbook to something easier to use. Here's an irritating thing: I'm using 2.6.2 provided by gentoo, and the links from index.html down in /usr/share/doc/fvwm... are relative to subdirectories that don't exist. The files do, just they are all in the top level. I'd suggest having those pre-generated in the source tarball, btw, instead of the xml. 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. MK -- "Enthusiasm is not the enemy of the intellect." (said of Irving Howe) "The angel of history[...]is turned toward the past." (Walter Benjamin)
