On Fri, Apr 1, 2016 at 5:43 PM, Thomas Adam <tho...@fvwm.org> wrote:
> On Fri, Apr 01, 2016 at 02:47:24PM -0600, Jaimos Skriletz wrote:
> >
>
> Thanks! It looks really good. We can remove the Changelog section; people
> can look at the release descriptions and/or Git history from now on.
> Maintaining this is a doubling of effort for absolutely no reason.
>
>
The ChangeLog page is just links to the files on GitHub so there is no
maintenance on the page. Could be removed, I just thought it would be nice
to have links easily found on fvwm.org for them.
> In terms of the FAQ, have you (for now) just copied that from
> $FVWM.GIT/docs/
> ? If so, I can remove that file from the FVWM repo and make the one in
> fvwmorg.gh.io the authoritative version (as it should be). Same goes for
> removing other files from the FVWM repo too, but that's a different
> concern.
>
>
No, the FAQ is a html dump (save as) from the old fvwm.org page as it was a
copy of that file with linked anchors in it. The FAQ needs to be converted
into a markdown file (complete with anchored links). Then I will create a
simple wrapper to wrap the markdown file into the webpage. I would keep the
FAQ around in $FVWM.GIT/docs/ until then.
Also I am unsure if these various markdown files, FAQ.md, AUTHORS.md,
DEVELOPERS.md, etc should be located and maintained on the webpage or
in $FVWM.GIT source. I think either can work with git.io so it is probably
a matter of preference. But agreed, these markdown files should all be
collected and maintained in a single place.
> > I am working on a 'Config' section for the site to include examples of
> > decors, icons, sounds and vector buttons (many adapted from fvwm-themes).
> > But this is gonna take a while as I play with the different decors.
>
> Maybe. It might be easier to just direct people towards things like
> Fvwm-{Crystal,Nightshade}. The icons/sounds/etc., can just be forgotten
> about. They're so old, it's not even funny, and if someone *really* wants
> those, shove them on the wiki.
Agreed on the age of the resources. It may be that fvwm.org doesn't
provide any actual resources for configs and just points to other sites and
what I have been collecting can be put elsewhere. My vision wasn't to be a
full
configuration like Crystal or Nightshade, but provide configuration
examples complete with any resources needed (images, etc). My rough idea
was to include
- A simple/minimal "default" config.
- Examples of various config snippets for things such as Vector
Buttons, Window Decors, Menus, Modules, etc. (This was kinda attempted on
the current fvwm.org page).
I think the actual question is should fvwm.org provide any resources for
configurations like above, or should it only link to other sites? This is
also not something I was planning on including in the initial transition of
moving the site to git.io, but was something I was thinking of developing
and adding if there was interest to have a collection of config snippets on
fvwm.org. If not I will look into updating the wiki (though I am liking
jekyll over ikiwiki for building static pages).
> > I also think adding some feature to the buttons on the page would be
> nice,
> > but not sure what sort of silly feature (maybe some js/css magic) would
> be
> > good to add to the site.
>
> Maximizing of the div, perhaps?
>
> > Anyways, those are some ideas but as of now the above links give a
> > recreation of fvwm.org using a static site (with some redesigning). Any
> > input is appreciated.
>
> Thanks for this, Jaimos. One question: how would we handle adding new
> screenshots? There's a script which runs to generate some HTML. I presume
> this is manual at the moment?
>
>
Currently it is a script which needs to be run manually (same for the man
pages, and that script is in worse shape, has hard links to files in my
$HOME). Once the site is on git.io I was thinking of looking into what sort
of hooks there are to generate stuff during the generation. Its current
state is just to be static for the move.
My hope is I got the site to a place that it can be transferred over to
git.io as a static page. Most of the above are things that can be resolved
after the transfer. This also includes adding any new content/features to
the site.
jaimos
