Subject: The new web pages

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 23 Apr 2003 15:10:17 +0000

I am starting the new thread, because the thread depth of 25 is getting
ridiculous. Problems:

The ALT property of mini icons in the pager should be "", otherwise some
browsers (at least Opera) use this name initially before the icons are
loaded making the pager too wide initially.

Konqueror first loads the main css and then immediatelly switches to
the alternative css. This is most probably a bug/feature in Konqueror,
but probably there is a work around, like switching the order of the main
and alternative css.

In the alternative css the visited links are not different from the
non-visited one, they should be clearly distinguishable.
In the alternative css the active pager page is not marked.

I think the empty title is less interesting than the title with text.
At least with old logos, the title text (empty now) carries the meaning.
In the pages where the window decoration title should better be void we
may just define it empty. What do you think? 

Other than this I like the current design.

Regards,
Mikhael.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Bob Woodside <[email-masked]>
Date: Wed, 23 Apr 2003 22:40:04 -0400

On Wed, 23 Apr 2003 15:10:17 +0000
Mikhael Goikhman <[email-masked]> wrote:

> I am starting the new thread, because the thread depth of 25 is
> getting ridiculous. Problems:
> 
> The ALT property of mini icons in the pager should be "", otherwise
> some browsers (at least Opera) use this name initially before the
> icons are loaded making the pager too wide initially.

	The standard way to prevent this is to specify the exact width &
height of each icon image, so the browser knows how much space to layout
for it before loading it. I think most of the current browsers will pick
up the title attribute for the balloon help if alt is missing, but older
ones don't, and I've no idea what Lynx does; so I think we should keep
the alt attribute.

	I'll commit a change to do this in a few minutes. See if this looks
better.

Cheers,
Bob

---

From: Bob Woodside <[email-masked]>
Date: Wed, 23 Apr 2003 23:20:33 -0400

On Wed, 23 Apr 2003 22:40:04 -0400
Bob Woodside <[email-masked]> wrote:

> height of each icon image...
> 
> 	I'll commit a change to do this in a few minutes. See if this
> 	looks better.

	Of course, I didn't realize you'd already tweaked this line, so I got a
CVS confilict. I commented out your 2 lines and added mine for now.

	Let's see how this looks to you in the morning. If it looks OK, I'll
remove the commented lines. If not, we can restore them.

Chers,
Bob

---

From: Bob Woodside <[email-masked]>
Date: Thu, 24 Apr 2003 00:08:31 -0400

I was going to send Matt Chapman a message about the WM comparison
chart on his "Window Managers for X" site and remove the dumb
"Developers' note" I left on our Links page, but a couple of questions
occurred to me.

	1) He has a link to an "FVWM2 THEMES" page
(http://www.geocities.com/bluesmani/). The page is still alive, but
doesn't seem to be active (it refers to 2.2.2 as the latest FVWM
release). Mikhael, was this a precursor to the Official FVWM Themes
page, and now obsolete? Or was it a completely independent effort that
never had any connection to the official one? In any case, I think Matt
should be told about the officlal one.

	2) My original intent was to tell him that in the comparison chart he
should check FVWM as having pinnable (or tear-off) menus (which, ahem,
would make FVWM the only WM with *all* the columns checked). But I can't
recall whether tear-off menus are in 2.4. Are they?

Cheers,
Bob

---

From: Uwe Pross <[email-masked]>
Date: Thu, 24 Apr 2003 08:21:27 +0200

Hi there,

> ones don't, and I've no idea what Lynx does; so I think we should keep

Opera renders good now - even if the pager pictures do not
exist ;-) 

Lynx uses the alt attribute to display the picture's name
since it does not display the picture itself. So at least
for this browser the alt attribute which describes the link
is really neccessary. Netscape uses the alt attribute to pop
up a little ballon which shows the image description.  
Other browsers as mozilla use the title attribute for the
ballon.

I think it is a good way to have both attributes meaningful
since the pager icons only says not that much.

Regards, Uwe
-- 
  ,_,  Uwe Pross
 (O,O) mailto:[email-masked]
 (   ) http://www.tu-chemnitz.de/~uwp
=-"-"-================================
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Uwe Pross <[email-masked]>
Date: Thu, 24 Apr 2003 08:46:59 +0200

Hi there,

On 23 Apr 2003 at 15:10:17 +0000, Mikhael Goikhman wrote:

> In the alternative css the visited links are not different
> from the non-visited one, they should be clearly
> distinguishable.  In the alternative css the active pager
> page is not marked.

The existence of an alternate style will not  be  discovered
by  most  users.  It is really a fancy feature, but if there
are problems with some browsers I think it is reasonable  to
live without it. 

> I think the empty title is less interesting than the title
> with text.  At least with old logos, the title text (empty
> now) carries the meaning.  In the pages where the window
> decoration title should better be void we may just define
> it empty. What do you think?

You are right, the title looks that empty ;-) I think we may
choose  a  window  title  which  it quite different from the
header. On the start page it could be "Welcome to  the  fvwm
homepage" or on the screenshot page it may say "Click on the
image for the full sized version." ... 

Some thoughts:
It would be good if the pages stable and unstable belong  to
the navgation structure and would be displayed in the pager.
The link at bottom of the man pages return  to  index  would
not  be  needed  in  that  case.  The  same is with the perl
library page and the logo sub pages. These pages are  hidden
from the navigation structure. 

I think it is not good to hide that much from the navigation
structure.  Hiding should be done by the layout-file so that
further layouts may be designed as flexible as possible. 

For that case we may introduce a new header  variable  which
tells  the  layout  algorithm to do not step further down in
the navigation tree. Layout files may  descide  of  the  use
this variable of not. For example a layout could display all
available man pages on the left side of the  page.  If  they
are  not in the navigation structure is will be not possible
to set up such a layout. 

Regards, Uwe

---

From: Dan Espen <[email-masked]>
Date: Thu, 24 Apr 2003 07:28:27 -0400

> recall whether tear-off menus are in 2.4. Are they?

They are not in 2.4.
There are problems with the way they work and they
will probably be disabled in 2.6.  There was some discussion of
the problems a few months ago.

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Bob Woodside <[email-masked]>
Date: Thu, 24 Apr 2003 09:03:42 -0400

On Thu, 24 Apr 2003 07:28:27 -0400
Dan Espen <[email-masked]> wrote:

> >   2) My original intent was to tell him that in the comparison
> >   chart he should check FVWM as having pinnable
> >   (or tear-off) menus (which, ahem, would make
> >   FVWM the only WM with *all* the columns checked).
> >   But I can't recall whether tear-off menus are in 2.4. Are they?
> 
> They are not in 2.4.

	That's what I thought.

> the problems a few months ago.

	Bummer! It's a nice feature that I like to use occasionally, and
haven't seen a problem (but maybe I haven't triggered it, or it just
doesn't bother me). Guess I'll have to search the archives to see what
the problem(s) might be.

Cheers,
Bob

---

From: Grzegorz Nieweglowski <[email-masked]>
Date: Thu, 24 Apr 2003 08:35:29 +0200

> ones don't, and I've no idea what Lynx does; so I think we should keep

The W3C standards are:

* "alt" is used by text-mode browsers to display a description of "what
  you would see if your browser could display images"

* "alt" is also displayed by graphical browsers if image loading is
  turned off (just like text-mode browsers), or the image hasn't been
  downloaded yet

* "title" is _the_ property to use for popup-info

Actually using "alt" for pop-up info is a bug/bad implementation of
standards (according to W3C), but some (most) browsers allow it.

Anyway, both "title" and "alt" should be provided with every image you
wish to have descriptions/popups.

-- 
\hoppke
(Grzegorz Nieweglowski)
http://lubuska.zapto.org/~hoppke/

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 24 Apr 2003 17:02:58 +0000

> > ones don't, and I've no idea what Lynx does; so I think we should keep

Thanks, but I don't think that anyone involved here (Uwe, Bob, me) does
not know the theory. The W3C standards is pretty irrelevant to the
original problem.

Bob, I will remove my fix (limiting ALT length), since it is redundant
with your fix (specifying explicit image sizes).

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 24 Apr 2003 17:16:27 +0000

> should be told about the officlal one.

I think I already tried to contact Mutt in the past, but it seems that he
does not update his web pages (at least some of them) in the last 4 years.

bluesmani themes is not connected to fvwm-themes in any way (except that
there is a link to it together with dozen of others at the bottom of
fvwm-themes.sf.net).

Regards,
Mikhael.

---

From: Bob Woodside <[email-masked]>
Date: Thu, 24 Apr 2003 13:28:17 -0400

On Thu, 24 Apr 2003 08:35:29 +0200

> standards (according to W3C), but some (most) browsers allow it.

	Here's the behavior I see:

Netscape 6 & 7 & Mozilla:  follow this standard, only use title for
popups (presumably other Mozilla derivatives behave likewise)

Opera 6 (Linux):  folllows the standard, uses only title

Opera 7 (Win):  uses title, falls back to displaying link url in popup

IE6:  gives precedence to title, then falls back to alt for popups

Netscape 4:  ignores title, only uses alt, period

> wish to have descriptions/popups.

	Agreed.

Cheers,
Bob

---

From: Uwe Pross <[email-masked]>
Date: Fri, 25 Apr 2003 23:11:00 +0200

Hi there,

I have finished the layout description using php classes. The current
two layouts have been ported to php class descriptions.
Currently the new layout files are not used since I have not tested
them very carefully :-|

The new layouts are accessable via

  www.fvwm.org/?layout=plain_class
and
  www.fvwm.org/?layout=default_class

Don't be disappointed. They hardly look different to the current
layouts. (On the plain layout the navigation is different. On the
default layout the pager color is changed a bit to show that a
different layout descriptions is used.)

The difference is that classes are used for the layout description
which makes it quite easy to derive new layouts from a existing ones.

Currently the following files are used:

class_layout_base.inc: description of base layout class
interface_definitions.inc: mapping of object functions to global functions.

layout_default_class.inc: default layout using classes (might be splitted)
layout_plain_class.inc: plain layout using classes (might be splitted)

navgen.cli produces currently a array for the class _and_ the current
concept. 

Comments are welcome.

Regards, Uwe

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 26 Apr 2003 00:37:55 +0000

> which makes it quite easy to derive new layouts from a existing ones.

This is good. Can I suggest to move all layout classes to the separate
directory? I.e. layout/default.inc instead of layout_default.inc.

> layout_plain_class.inc: plain layout using classes (might be splitted)

I think the navigation methods may be (if possible of course) moved to
separate elements. Like:

  layout/navigation/pager.inc
  layout/navigation/parent_list.inc
  layout/navigation/void.inc  # does not exist in the new version
  layout/navigation/menus.inc  # does not exist yet

How about to separate the decoration methods too:

  layout/decor/window.inc  # there is also the actual image/color theme
  layout/decor/border.inc  # there is also the actual image/color theme
  layout/decor/void.inc

This way, the current layout=default consists of navigation=pager and
decor=window, layout=plain consists of navigation=parent_list (or void)
and decor=void.

This is just a working suggestion without all details.

BTW, I think "layout" is not the best term for what it does. Maybe
"skin", "view" or "look" (other names: "theme", "design", "looknfeel").

On the other subjects.

Why do you set decoration windows to be 800 pixels tall - to always force
a side scrollbar? An empty window taller than the page looks very bad.

I think we are not going to return to the old pages, so I will remove all
.html files soon.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Fri, 25 Apr 2003 20:56:23 -0400

I notice that for the screenshots, the ability to move from full size
image to full size image has been removed.

Is there a plan to bring that back?

---

From: parv <[email-masked]>
Date: Fri, 25 Apr 2003 21:14:29 -0400

in message <[email-masked]>,
wrote Dan Espen thusly...
>
> I notice that for the screenshots, the ability to move from full
                                         ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
> size image to full size image has been removed.
  ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^

Say what?

--

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 26 Apr 2003 01:35:17 +0000

> Is there a plan to bring that back?

I may enhance the script to automatically add "Next/Prev" links, but I
think Uwe wants to redesign the whole thing later.

Hopefully this feature is not very urgent.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Fri, 25 Apr 2003 21:49:52 -0400

> > I notice that for the screenshots, the ability to move from full

Go to http://www.fvwm.org/screenshots/index.html,
click on a thumbnail to go to one full size image.

Notice the links that lte you can navigate
from image to image?

> Hopefully this feature is not very urgent.

Its not urgent.

I was just wondering if there was some magic php
trick that would accomplish this some other way.

---

From: parv <[email-masked]>
Date: Sat, 26 Apr 2003 01:30:46 -0400

in message <[email-masked]>,
wrote Dan Espen thusly...
> > > I notice that for the screenshots, the ability to move from
> > > full size image to full size image has been removed.
> > 
> > Say what?
> 
> Go to http://www.fvwm.org/screenshots/index.html, click on
> a thumbnail to go to one full size image.
> 
> Notice the links that lte you can navigate from image to image?

Forgot about that!  Sorry to bother everybody (I misunderstood
you)...

  - parv

--

---

From: Uwe Pross <[email-masked]>
Date: Sat, 26 Apr 2003 15:30:13 +0200

Hi there,

On 26 Apr 2003 at 01:35:17 +0000, Mikhael Goikhman wrote:

> I may enhance the script to automatically add "Next/Prev" links, but
> I think Uwe wants to redesign the whole thing later.

For the moment this might be a  workaround.  I  thought  this  feature
might  be  not  that important since I always go from thumbnail to the
full sized shot. But if this feature is requested we may put it back. 

To the screenshot site:

Actually I wanted to wait before discussing the screenshot pages until
the php concept has been finished. 

The  screenshot  pages  as  they  are  now  very  good.  Some  desktop
screenshots  are quite out of date. The information about some shots is
quite poor and there are no .fvwmrcs for the shots. 

For the desktop shot I think it would be good if a  short  description
were  given  what  is  seen  on  _each_  shot - like FvwmButtons (with
config), gkrellm (with theme), asmail, Taskbar (with config),  and  so
on. If somebody uses special icons we might also say where they can be
obtained from. The desktop  shot  page  should  not  contain  too  may
pictures  to  keep  the page clearer. We may separate the shot page to
pages contain 5 or 7 shots and provide prev and next buttons  on  each
page.  We  should  also  provide  "simple"  screenshots  like the fvwm
default look. 

For the window decoration and menu screenshot pages we might need some
more shots with configs to attract people. 

Maybe a separate FvwmButtons screenshot page would be nice.

Rating for the shots would be also a fancy feature ;-)

Regards, Uwe

---

From: Bob Woodside <[email-masked]>
Date: Sat, 26 Apr 2003 12:09:24 -0400

On Sat, 26 Apr 2003 00:37:55 +0000
Mikhael Goikhman <[email-masked]> wrote:

> Why do you set decoration windows to be 800 pixels tall - to always
> force a side scrollbar? An empty window taller than the page looks
> very bad.

	This was a quick 'n dirty hack several weeks ago when the few test
pages we had hadn't much content yet and looked squashed and silly when
viewed on a very wide screen. I suspect that all the pages have enough
content now that this isn't needed anymore.

Cheers,
Bob

---

From: Uwe Pross <[email-masked]>
Date: Sat, 26 Apr 2003 14:43:35 +0200

Hi there,

On 26 Apr 2003 at 00:37:55 +0000, Mikhael Goikhman wrote:

> This is good. Can I suggest to move all layout classes to the
> separate directory? I.e. layout/default.inc instead of
> layout_default.inc.

Yes, it is good to have the files more structured. 

> This is just a working suggestion without all details.

The idea is good - but the current class concept needs to be changed a
little  bit.  As  far  as I know php does not support deriving a class
from more than one base class. So the concept you suggest is more like
a  construction kid where one collects all items one needs in a layout
(theme) description. 
If I am thinking about it this make the class  concept  not  necessary
anymore.  We  could  place function descriptions in separate files and
include them in the  layout  files.  So  we  don't  need  to  descripe
function  more  than one time and changing a function would affect all
layouts. 

A layout file would look than just like this:

include(theme_desc("navigation/parent_path.inc"));
include(theme_desc("navigation/pager.inc"));
include(theme_desc("decor/window.inc"));
...
<html>
...
</html>

This seems to me much more flexible than the  class  concept.  Damn  I
should have discussed the class idea before implementing it ;-) 
BTW, having such function description files makes  it  quite  easy  to
reuse the themes for further web designs - e.g. fvwm-theme. 

> "skin", "view" or "look" (other names: "theme", "design",

Okay, I am not a native english speaker so some terms I  have  choosen
might  be not selected by other people. However, from your suggestions
I would like "theme" at most since relates to fvwm-theme. From  a  web
"design"  view  the  term  "design" might be most appropriate. I would
like to leave it up to you. 
 
> force a side scrollbar? An empty window taller than the page looks

This was not on purpose - more by accident. I had some difficulties to
keep  the  class  description up to date, since the other layout files
were changed a lot last week. 

> I think we are not going to return to the old pages, so I will
> remove all .html files soon.

Yes, good idea. I think we need to clean up the file tree a bit ;-)

Another thing  is  that  the  web  files  currently  have  no  license
statement in it. With the modular function file concept the frame work
becomes quite usable. 
I would like to put them under GPL like fvwm.  Any  disagrees?  To  do
this  is  it  necessary  to  put the GNU statement in each php and inc
file? 

Regards, Uwe

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 26 Apr 2003 23:48:54 +0000

> like to leave it up to you.

Do you mean I am a native English speaker? :)

Ok, if I should choose, I think the term "web theme" is good.
Or "theme" for short.

> function  more  than one time and changing a function would affect all

I didn't mean the class concept is bad. I just don't have a time to think
about the exact code design right now. I hope you have more time to think
about this, i.e. how to make creation of new web themes easy. It may be
good (or bad) to have subclassed themes or subclassed navigations/pagers.

> this  is  it  necessary  to  put the GNU statement in each php and inc

I think placing the statement in one/two central .inc files that are
included by all .php is more than enough. Having .php files themselves
small (only html, no static text) would be nice.

Regards,
Mikhael.

---

From: Uwe Pross <[email-masked]>
Date: Mon, 28 Apr 2003 08:23:32 +0200

Hi there,

> Ok, if I should choose, I think the term "web theme" is good.

All the new stuff will be placed at /web-theme/{...}

> I didn't mean the class concept is bad. 

I got that. But the class concept might be not necessary. On
my computer at home I had the impression that using
classes/objects produces more cpu load at the web servers
side. I don't like to overkill the web server at fvwm.org.

> I just don't have a time to think about the exact code
> design right now. I hope you have more time to think about
> this, i.e. how to make creation of new web themes easy. It
> may be good (or bad) to have subclassed themes or
> subclassed navigations/pagers.

I have not made a decision yet. My current concept (in mind)
is partinioning the functions as the are now in
layout_default.inc in files and add some dependencies to
this functions files like:

/web-theme/navigation/window_decoration/default.inc:

------------------------------------------------------------
// don't load this files if functions described here do
// already exist 
if(function_exists("window_decoration_start")) return;

// declare functions which are needed by the function
// declations in this file
require("decoration_title_line");

// or maybe just
include(theme_description("navigation/window_decoration/window_decoration_title_line.inc"));

function window_decoration_start("") {...}
------------------------------------------------------------

This would allow to include the functions needed for a
theme in the theme file. I have to think about it more
detailed regarding to simplicity, extentability, safety and
cpu usage. 

> I think placing the statement in one/two central .inc
> files that are included by all .php is more than enough.

I am going to do that.

> Having .php files themselves small (only html, no static
> text) would be nice.

The header in the php files is necessary to get urls like

www.fvwm.org/features.php. 

and use navgen to obtain the navigation structure.  If the
php-files would contain html (and php-function calls) only
the url would look like

www.fvwm.org/theme_default.php?file=features

This would allow to separate contents and layout as the
current concept. But I don't like such urls ;-)

Cheers, Uwe