Subject: Re: Fvwm CVS login

From: Uwe Pross <[email-masked]>
Date: Wed, 26 Mar 2003 07:45:40 +0100

Hi Jason,

On Tue, 25 Mar 2003, Jason L Tibbitts III wrote:

> UP> Could you please create an cvs account for me with the following
> UP> username and password?
> 
> You should be set up.  Remember that you will need to check out a
> completely fresh tree in order to be able to commit.

Thank you.

> UP> We may also need a new cvs tree which does not belong to the
> UP> fvwm-package.
> 
> Could you elaborate on what you might need?  I can give you another
> module or a completely separate repository if you need it.

Bob and me (and maybe others) will work on the new fvwm-web
site. During the development the new site should not be
shown when requesting for www.fvwm.org. 

I am not an expert for cvs. In my cvs repository I would
create a new tree for the new page - but maybe the is
another better solution.

Some thoughts to the cvs control for the new web page: 

I think it would be good if the new page tree is separated
from the old one in the cvs. This makes it possible to
discard the old page when the new has been set up. It would
be also good if the new page would be accessable via
fvwm.org (www.fvwm.org/new_page or something like this) to
get other developers an idea how the development of the web
pages goes on. For this it would be good if changes to the
cvs tree of the new page effect directly the subdirectory
on the web server like it is now when commiting changes to
the fvwm-web tree. If this is not possible I will keep a
online version at my homepage like it is now.

Maybe Bob or other developers can make a comment what is a
good way to put the new page under cvs control.

BTW: I realized that fvwm.org is mirrored by
     fvwm.sourceforge.net and maybe by others as well. If
     we use php for the new page and support the usage of
     different page styles we might need to make sure that
     the mirrors support this as well. 

Regards, Uwe
-- 
+-----------------------------------------------------------
| Uwe Pross                              
| 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: Bob Woodside <[email-masked]>
Date: Wed, 26 Mar 2003 13:27:45 -0500

On Wed, 26 Mar 2003 07:45:40 +0100

> create a new tree for the new page - but maybe the is

	I had originally thought of just using CVS as a source repository where
we could both (all?) work on it together, but kept separate from the
regular Web stuff and not viewable on the live site. However, Uwe's and
Mikhael's comments lead me to think that a separate directory that got
propagated to the Web site might be easiest for all concerned, so that
neither of us needed to keep a separate Web server in sync with CVS to
let the other developers see the work in progress.

> fvwm.org (www.fvwm.org/new_page or something like this) 

	...or even www.fvwm.org/TestWeb

> to get other developers an idea how the development of the web
> the fvwm-web tree. 

	Yes. Jason, what would be most practical for this purpose, a
subdirectory under fvwm-web, or a separate directory at the same level
as fvwm-web? (I'm guessing the former.) I think our main concern is to
keep the test stuff from getting included in any release or snapshot
tarballs, but making it easy to feed to the Web site.

	Does anyone have any objections to having the new test pages viewable
from the regular Web site, given the special test URL? Are there
negative implications we haven't thought of?

>      the mirrors support this as well. 

	I believe Mikhael indicated that the SourceForge site is PHP-enabled. I
don't know of any other mirrors...are there any? I don't know how the
mirror(s) are fed, but I guess the same considerations apply here
vis-á-vis the directory structure.

Cheers,
Bob

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 27 Mar 2003 00:06:12 +0000

Please remember, these new pages are going to become official in a month
or two. Unless you want to add and remove files in cvs a lot, I would
immediatelly work on the final (or almost final) names.

I would neither add a new tree nor a new repository, just create .php (or
.phtml) file for every existing .html file, in the same directory if
appropriate. Then, when the new pages are ready, just remove .html files.

I see no problem for test files to be accessible from the web.

Any other solution (a new subtree or a new cvs repository) will
unnecessarily complicate things. There will never be a conflict between
old pages and new pages, so we can keep 2 versions simultaneously in the
same directory structure.

Regards,
Mikhael.

---

From: Uwe Pross <[email-masked]>
Date: Thu, 27 Mar 2003 08:46:16 +0100

Good morning fvwm-workers,

On 27 Mar 2003 at 00:06:12 +0000, Mikhael Goikhman wrote:

> I would neither add a new tree nor a new repository, just
> create .php (or .phtml) file for every existing .html
> file, in the same directory if appropriate. Then, when
> the new pages are ready, just remove .html files.
> 

I agree. I have pulled the fvwm-web tree from cvs and put
it at

http://www-user.tu-chemnitz.de/~uwp/fvwm-web/

The new php-files have been added to this directory. Since
our web server serves php before html I have moved the file
index.php to home.php. So the new version is accessable via

http://www-user.tu-chemnitz.de/~uwp/fvwm-web/home.php

Since I don't know what the web server at fvwm.org serves
first I will keep home.php until the site is published
officially.

I have added a "Latest news" entry for the development of
the new site to home.php to show what's going on. Entries
are made to the file latest_news.txt which is included in
home.php. The entry on the web site will be removed before
the site is officially.

Before I add the files to the cvs and put them online at
fvwm.org it would be good if somebody looks in the php
sources for potentially security lacks. Bob could you
do that please? - Four eyes see more than two.

To the actual layout: Does anyone have objections on the
actual layout? Is the navigation through the site via the
pager understandable? I think the pager navigation is
different than the navigation on other web sites - but it
should be comprehensible. 
How about the actual colors and window decoration? Bob
meant the colors should be changed a little bit. Any other
suggestions?

If there are no objections on the actual design. I will go
on and fill the sub sites with contents, create icons for
each sub page, etc.

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, 27 Mar 2003 08:49:21 +0100

> do that please? - Four eyes see more than two.

I forgot to say the php-files can be downloaded at:

http://www-user.tu-chemnitz.de/~uwp/fvwm-web/fvwm_php_27032003.tgz

Regards, Uwe

---

From: Dan Espen <[email-masked]>
Date: Thu, 27 Mar 2003 06:38:07 -0500

> http://www-user.tu-chemnitz.de/~uwp/fvwm-web/

I like the pager better than the menu.

When it shows the window for the first page, I don't like the
squashed appearance of the first window.
Is there a way to add a minumum height to the window so it doesn't
look squashed.  Perhaps always extend it to the bottom of the
browser?

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

---

From: Uwe Pross <[email-masked]>
Date: Thu, 27 Mar 2003 13:24:24 +0100

Hi there,

> I like the pager better than the menu.

So do I.
 
> When it shows the window for the first page, I don't like
> the squashed appearance of the first window. Is there a
> way to add a minumum height to the window so it doesn't
> look squashed.  Perhaps always extend it to the bottom of
> the browser?

I am not sure what you mean. Do you mean the height of the
window on home.php? I have added a minimum height and moved
the web site news into the window.

Actually the height and the width depend on the size of
your browser window. If have got a big screen resolution
say 1600x1200 the window might have looked squashed. I
have got a 880x660 resolution at home and a 1152x900 at
work. On this resoultion the window does not look that
squashed.

For now a minimum height of 800 pixels has been added. If
this in not sufficient I could add more which might look
strange at lower screen resolutions. 

Another possibility would be put more text in the
windows so that it's height is more than the browser's
height.

Regards, Uwe

---

From: Dan Espen <[email-masked]>
Date: Thu, 27 Mar 2003 07:35:08 -0500

Uwe Pross <[email-masked]> writes:
> window on home.php?

Yes.

> I have added a minimum height and moved

It looks better now, but by adding text you made the window taller
anyway.

> say 1600x1200 the window might have looked squashed. I

Yes, I'm using 1600x1200.
In this case, I guess it was squashed because you had another
window under it, but I think an earlier version was squashed
with empty space under it.

> strange at lower screen resolutions. 

I think a minumum height of 800 will do it.

> windows so that it's height is more than the browser's

Is it possible to attach alt tags to the images in the pager?
For example, there are 4 screenshot pages, but you can't tell
where they lead until you click on them.

---

From: Uwe Pross <[email-masked]>
Date: Thu, 27 Mar 2003 13:55:58 +0100

Hi there,

> where they lead until you click on them.

Done. I added "title" as well to get it shown in mozilla
and opera.

Uwe

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 27 Mar 2003 14:08:16 +0100

> > http://www-user.tu-chemnitz.de/~uwp/fvwm-web/

That link gives me only the old site.

> I like the pager better than the menu.

Cool.  Looks much better than I would have imagined.  BUt instead
of the icons in the pager I would try to cram the name of the
contents into a single window in ech page like this:

  +----------------------------+
  | Download                   |
  +--------------+-------------+
  |+------------+|+-----------+|
  ||            |||           ||
  || Sources    ||| Icons     ||
  ||            |||           ||
  |+------------+|+-----------+|
  +--------------+-------------+
  |              |             |
  |              |             |
  |              |             |
  |              |             |
  |              |             |
  +--------------+-------------+

And to improve readability, I would use pale colours for the pages
and strong colours for the desk titles.

Left aligned Desk titles would be nice.

> look squashed.  Perhaps always extend it to the bottom of the

Bye

Dominik ^_^  ^_^

---

From: Uwe Pross <[email-masked]>
Date: Thu, 27 Mar 2003 15:03:26 +0100

Hi there,

On 27 Mar 2003 at 14:08:16 +0100, Dominik Vogt wrote:

> Cool.  Looks much better than I would have imagined.  BUt
> instead of the icons in the pager I would try to cram the
> name of the contents into a single window in ech page
> like this:
> 

That's not that easy.

Deskname left align:
http://www-user.tu-chemnitz.de/~uwp/fvwm-web/home.php?layout=text_pager

Text instead of icons:
http://www-user.tu-chemnitz.de/~uwp/fvwm-web/home.php?layout=text_pager&text_on_pager=1

The problem is that the font size depends on your browser
settings. If you use big fonts the pager looks quite
different than with small fonts. I used images since they
have the same size independent from the browser settings.
I could generate images for the pager with text instead of
mini icons. I will have a try tonight.

BTW: The links in the pager pages were thought to be an
 additional fancy feature to jump to certain sub links
 directly. One can get to the sub pages of the third tier
 over the links in the desk labels as well. The links in
 the pages are just additional.

Regards, Uwe

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 27 Mar 2003 15:12:58 +0100

> contents into a single window in ech page like this:

I've attached a screen shot of what I had in mind.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 27 Mar 2003 15:22:31 +0100

> http://www-user.tu-chemnitz.de/~uwp/fvwm-web/home.php?layout=text_pager

Looks good, but when I click on one of the sub links, the mozilla
tab it is displayed in freezed.  I can not even close it.  The
problem with text in the pages is that it occupies too much space
(see the screenshot I posted).

>  the pages are just additional.

Actually, I like the additional fancy feature much more than the
main feature with nested pagers which I find immensly confusing
because it works much unlike the pager layout suggests.  :-)  

Bye

Dominik ^_^  ^_^

---

From: Uwe Pross <[email-masked]>
Date: Thu, 27 Mar 2003 15:24:10 +0100

Hi there,

> I've attached a screen shot of what I had in mind.

The best way to achieve this is to have pictures for the
windows on the pages. Using convert this should not be a
problem.

Is it wanted that the pages look stretched
horizontally? 

Regards, Uwe

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 27 Mar 2003 15:29:35 +0100

> > name of the contents into a single window in ech page

[snip]

Ah, maybe we should just drop the multi-desk multi-page pager and
have a multi-desk one-page pager with windows on the shown page
for the subsections.  The active desk and the active window is
hilighted:

  +----------------+
  | Download       |
  +----------------+
  | +---------+    |
  | | sources |    |
  | +---------+    |
  | +-------+      |
  | | icons |      |
  | +-------+      |
  +----------------+
  |.Features.......| <-- selected desk (section)
  +----------------+
  |................|
  |.+----------+...|
  |.|.features.|...| <-- selected window (subsection)
  |.+----------+...|
  |................|
  |................|
  +----------------+

However - regardless of the pager layout - if we have more than
two or three sub sections per section, it becomes confusing.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 27 Mar 2003 15:32:42 +0100

> windows on the pages. Using convert this should not be a

But that removes the possibility to navigate the page in a text
based browser.

> Is it wanted that the pages look stretched

That was a feeble attempt to have mor space for the labels.  Looks
very ugly, I know.

Anyway, take a look at my new proposal in another mail first.

Bye

Dominik ^_^  ^_^

---

From: Uwe Pross <[email-masked]>
Date: Thu, 27 Mar 2003 15:37:50 +0100

Hi there,

> But that removes the possibility to navigate the page in a text

Console browsers like lynx use the description of the alt
attribute in the image tag. If this is properly set one can
use this browsers. Have a try with lynx - looks not that
good but it works.

Regards, Uwe

---

From: Dan Espen <[email-masked]>
Date: Thu, 27 Mar 2003 11:21:54 -0500

> I've attached a screen shot of what I had in mind.

Aggh...no, not those colors!

:)

I think shades of blue are always good.
The current gray is safe.

---

From: Jason L Tibbitts III <[email-masked]>
Date: 27 Mar 2003 10:27:28 -0600

>>>>> "UP" == Uwe Pross <[email-masked]> writes:

UP> Since I don't know what the web server at fvwm.org serves first I
UP> will keep home.php until the site is published officially.

I believe I have it set to serve html before php:

DirectoryIndex index.html index.htm index.shtml index.php index.php4 index.php3 index.cgi

 - J<

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 27 Mar 2003 17:31:14 +0100

> The current gray is safe.

Forget about the colours, it's just the palette I was using today.
If large areas of the screen were painted with these gradients I
had to visit the eye specialist soon %-\  We can talk about the
actual theme later.  Anything that resembles Windoze even remotely
has to vanish :-)

Bye

Dominik ^_^  ^_^

---

From: Bob Woodside <[email-masked]>
Date: Thu, 27 Mar 2003 12:14:22 -0500

On Thu, 27 Mar 2003 08:46:16 +0100

> http://www-user.tu-chemnitz.de/~uwp/fvwm-web/home.php

	Actually, your server's order wouldn't be a problem. I'd call the home
page index.php. Then when we go to 

http://www-user.tu-chemnitz.de/~uwp/fvwm-web

we'll see the new stuff, which is what we really want to see. If anyone
wants to look at the old version, he can explicitly ask for index.html.

> first I will keep home.php until the site is published

	I would guess it gives precedence to index.html, but I don't know for
sure. Does anyone have an answer? 

	*Never mind*  - I just saw Jason's answer come in as I was typing
below. So, since index.html has precedence on the live FVWM site, I'd go
ahead and call it index.php.

> do that please? - Four eyes see more than two.

	And 6 or 8 would be even better.  :-)

	I just grabbed your latest tarball, and will take a look at it shortly.
The first security issue, as I've mentioned before, is that we need to
modify the code to work with PHP 4 with register_globals set to off
(which I'm sure is what Jason installed). But we want to modify it so
it'll be backward compatible with your PHP 3 system. I'll hack up a test
page and send it to you a little later; try it out and let me know
whether it works OK on your system.

	As for merging the new files with the existing fvwm-web, we want to be
sure there aren't any subdirectory clashes. For example, there is a
"screenshots" directory in both your new set and in the old fvwm-web,
and they're different things. In the tarball I pulled down, there is
only your new stuff. Is it your intent that I should be able to merge
this with my existing (copy of) fvwm-web?

	Ah, that reminds me...what are the implications for running navgen in a
merged directory? (That one also appears to have some PHP 3/4
incompatibilities that I haven't had time to research thoroughly yet.)

> meant the colors should be changed a little bit. Any other

	Mainly for the pager background. I think something a bit lighter than
that grey would give some needed contrast - possibly a light cream
color. 

Cheers,
Bob

---

From: Uwe Pross <[email-masked]>
Date: Thu, 27 Mar 2003 20:36:14 +0100

Hi Bob,

On Thu, 27 Mar 2003, Bob Woodside wrote:

> 	Actually, your server's order wouldn't be a
> problem. I'd call the home page index.php.

Should be done by this mail has been sent.

> 	I just grabbed your latest tarball, and will take a
> look at it shortly. The first security issue, as I've
> mentioned before, is that we need to modify the code to
> work with PHP 4 with register_globals set to off (which
> I'm sure is what Jason installed). But we want to modify
> it so it'll be backward compatible with your PHP 3
> system. 

I think we should develop for the target system not for my
system at home. I figured out that at the university's
server php 4 is running. 

http://www-user.tu-chemnitz.de/~uwp/fvwm-web/php_info.php

I will switch to php 4 at home as well.

> I'll hack up a test page and send it to you a little
> later; try it out and let me know whether it works OK on
> your system.

So you need not to do that.

> 	As for merging the new files with the existing
> fvwm-web, we want to be sure there aren't any
> subdirectory clashes.

Yes, you are right.

> For example, there is a "screenshots" directory in both
> your new set and in the old fvwm-web, and they're
> different things. In the tarball I pulled down, there is
> only your new stuff. Is it your intent that I should be
> able to merge this with my existing (copy of) fvwm-web?

Yes the screenshot subdirectory was an accident :-) We might
switch to screen_shot.

> 	Ah, that reminds me...what are the implications for
> running navgen in a merged directory? (That one also
> appears to have some PHP 3/4 incompatibilities that I
> haven't had time to research thoroughly yet.)

nagven.php looks recursively for files having a .php
extension and includes them. It extracts the variable
settings in the header of the php-files, does some
consistency checks and stores the contents of the variables
in the file navgen_write/navigation.inc. On my server at
home the apacher server has the permission to write into
this directory. I would suggest to do not allow this on
fvwm.org since a writeable directoy is potentially a
security issue.

> 	Mainly for the pager background. I think something
> a bit lighter than that grey would give some needed
> contrast - possibly a light cream color.

You can try different colors on your own by specifying them
in the url like:

http://localhost/uwe/fvwm_web_site/?pager_bg=%23ffff66

Please note that this variable is not passed through links
to other pages. Other possible changes to the actual layout
and their default value are:

if(!isset($decoration_path))  $decoration_path=$rel_path."/decorations/window_deco_simple_blue";
if(!isset($window_border_bg)) $window_border_bg="#c5cecd";
if(!isset($window_border_fg)) $window_border_fg="#ffffff";
if(!isset($window_bg))        $window_bg="#000000";
if(!isset($window_fg))        $window_fg="#ffffff";
if(!isset($body_bg))          $body_bg="#000000";
if(!isset($body_fg))          $body_fg="#ffffff";
if(!isset($body_bg_image))    $body_bg_image=$rel_path."/pictures/Totally-New-Product-1.jpg";
if(!isset($menu_bg))          $menu_bg="#c5cecd";
if(!isset($menu_fg))          $menu_fg="#000000";
if(!isset($windowlist_bg))    $windowlist_bg="#c5cecd";
if(!isset($windowlist_fg))    $windowlist_fg="#000000";
if(!isset($pager_bg))         $pager_bg="#b5bebd";
if(!isset($pager_fg))         $pager_fg="#000000";
if(!isset($hilight_bg))       $hilight_bg="#1a6e99";
if(!isset($hilight_fg))       $hilight_fg="#ffffff";

For example to change the background image using a file on
the local machine one could use:

http://localhost/uwe/fvwm_web_site/?body_bg_image=file:/home/uwe/pictures/azure.jpg

Uwe
-- 
+----------------------------------------------
| Uwe Pross
|    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: Dan Espen <[email-masked]>
Date: Thu, 27 Mar 2003 14:52:58 -0500

> Yes the screenshot subdirectory was an accident :-) We might

I don't think you should rename that directory.
Just add screenshots/index.php (if you have it).

There are some scripts in that directory that need to be reworked.
After your stuff is checked in, I plan to take a look.

Same for some of the other subdirectories.

---

From: Bob Woodside <[email-masked]>
Date: Thu, 27 Mar 2003 16:18:23 -0500

On Thu, 27 Mar 2003 20:36:14 +0100

> Should be done by this mail has been sent.

	Yes, I'd already noticed it before I got your message.

> > look at it shortly.

	Help! I don't know what's wrong, but after making my standard
register_globals patches, this version acts really strange. It won't put
any titlebar decorations on the windows. I can see that you've made a
lot of changes to the live site today. Is there possibly a newer tarball
I can grab this evening or tomorrow?

> ...

	When you set it up, set register_globals = Off in your php.ini. You'll
start to see the problem. Obviously, you can't control how the
university's server is set up (they have it on).

> fvwm.org since a writeable directoy is potentially a

	So a developer making changes that required running navgen would run it
on his local system to regenerate navigation.inc, then commit the
resulting changes to CVS, fight? (By the way, did you know there's an
option to build a command-line version of PHP, so you can run something
like navgen just like you would a Perl or shell script?)

> in the url....

> to other pages. 

	I think it would be nice if they were, but we can worry about that
later.

> Other possible changes to the actual layout
> if(!isset($decoration_path)) 
> $decoration_path=$rel_path."/decorations/window_deco_simple_blue";
	[snip]

	These are a bunch that have to change for the new register_globals
setting, by the way.

Cheers,
Bob

---

From: Uwe Pross <[email-masked]>
Date: Fri, 28 Mar 2003 08:40:12 +0100

Hi Bob,

On Thu, 27 Mar 2003, Bob Woodside wrote:

> 	I'll grab the new tarball first thing in the
> morning...or whenever I find out the URL for it.

I created a subdirectory for the tarballs: 
 
   http://www-user.tu-chemnitz.de/~uwp/fvwm-web/packed/

I have checked fvwm_php_28032003_0809.tgz twice and untared
it in a test directory.

> 	In PHP4 all the Environment, GET, PUT, Cookie, and
> Server variables that were implicitly global before are
> contained in global arrays, like $HTTP_SERVER_VARS (4.0,
> now deprecated) or $_SERVER (4.1 and later). In addition,
> since 4.1 these "Superglobal" arrays are implicitly
> global; the old $HTTP_xxx_VARS had to be declared global.
> Finally, there is a Superglobal array called $_REQUEST
> that contains all the variables "provided to the script
> via any user input mechanism, and which therefore cannot
> be trusted" - e.g., the POST and GET variables, etc.

Sounds resonable. 

> 	The register_globals = On setting makes all these
> variables automatically appear in the global space. So if
> someone requests http://my.host.com/mypage.php?decor=xp
> you automatically have a variable called $decor in your
> global space, just like in PHP3. With register_globals =
> Off, you don't have all these variables in your global
> space. If you want a $decor variable input via the URL,
> you have to do something like $decor = $_REQUEST['decor']
> or $decor = $_GET['decor']; and if you want it to be a
> global, you have to declare it as such.
>
> 	Basically, turning it off forces you to think about
> where a variable is coming from, and whether it's global.
> The idea is to minimize "variable poisoning". For
> example, suppose someone requests the URL
> http://my.host.com/mypage.php?PHP_SELF=someboguspagename,
> then where did the value of $PHP_SELF come from? $_SERVER
> is guaranteed to contain only the Server variables.
> 
> 	It's off by default, and the documentation strongly
> recommends leaving it that way unless you really need it
> on (probably because you're running a lot of older code
> that depends on the old behavior).

I like that concept since it forces me to think about what
I am doing. It reminds me on the type concept of java.
Thanks very much for this explanation. I think it is not
that much effort to convert the actual php-files that they
work with php4 and this settings.

> 	I'm not sure when the CLI version was introduced -
> somewhere in PHP 4. Ah, the manual says 4.2.0.

I am going to grab 4.3.1 today. I have not compiled a
php-module yet - hope there will be not that much problems
to get this work with my actual apache installation ;-) 
Maybe I need to upgrade my apache server to version 2 as well. 

> if (isset($_GET['decoration_path']))  {
>   //  Do any sanity checks on the value here...is it ridiculously
>   //  long, does the directory exist, etc.
>   $decoration_path = $_GET['decoration_path'];
>   }  else  {
>   }
> Or, you could use $_REQUEST instead of $_GET if you don't
> care whether it came from GET or POST. In our case, of
> course, it's always a GET variable.

I could do that changes when php4 is running on my machine.
Or if you like you could do that as well - let's see who is
first :-)

Regards, Uwe

---

From: Uwe Pross <[email-masked]>
Date: Fri, 28 Mar 2003 08:47:41 +0100

Hi there,

> I've attached a screen shot of what I had in mind.

http://www-user.tu-chemnitz.de/~uwp/fvwm-web/?layout=text_pager

I could make the images smaller. With the actual size the pager is
to big for my taste.

Regards, Uwe

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 28 Mar 2003 11:18:28 +0100

> I could make the images smaller. With the actual size the pager is

Yeah, it doesn't work with more than one page per desk.  Here is
another example that looks much better, including the complete
config file to generate it (1280x960 pixels on screen).  Warning:
the config kills all xterm windows.

Bye

Dominik ^_^  ^_^

---

From: Uwe Pross <[email-masked]>
Date: Fri, 28 Mar 2003 11:28:16 +0100

Hi there,

On 28 Mar 2003 at 11:18:28 +0100, Dominik Vogt wrote:

> config file to generate it (1280x960 pixels on screen).  

Yes, this one looks nice. I think one can do that but it
will be a _really_ big effort, since the overlapping
windows cannot be display in a table like it is now. One
needs either assemble the images in sub tables or uses
complete images in conjunction with image maps.
 
I would suggest to keep that in mind and have a try when
the first version of the new pages has been finished. I
think otherwise it takes to much time and we might get
problem to have the page ready in time.

> Warning: the config kills all xterm windows.

;-)

Regards, Uwe