lcd4linux-devel Mailing List for lcd4linux (Page 47)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Thanks!

Jerry

Woops, forgot to use the list reply and I don't have a copy of my
email.  Xavier, feel free to post it if you still have it.

Jerry

-----Message suivi-----
From: Jerry Seutter <ye...@th...>
To: Xavier VELLO <xav...@fr...>
Subject: Re: [Lcd4linux-devel] manpage for lcd4linux
Date: 02 Mar 2004 13:29:15 -0700

On Tue, Mar 02, 2004 at 04:57:12PM +0100, Xavier VELLO wrote:
> Hi Jerry, hi list !

<snip>

> > 3. Integration with autogenerated HTML, such as DocBook files that 
> > are rendered in HTML.  Can we still throw the DocBook output up on
> > the website?
> Yes ! It's the main reason ! In fact, we'll have to write a modified dtd
> stylesheet to call engine functions instead of using html tags. This may
> be done with a script too without modifying the stylesheet, but a new
> sheet would be proper.
> /me has to learn more about docbook to know how to write customized
> stylesheets.

Cool, I like the sound of that.

> > How is writing the webpages in PHP different from writing lcd4linux
> > in Java?  PHP has a lot of really cool features that I don't see a 
> > need for here.
> You're rude here. 

My apologies, Xavier.  It was not my intent to be rude, and reading my
email now, it is too harsh.

> In fact, I see a bunch of advantages to write the site
> in PHP:
> - keep documentations clean (without frames, fixed styles, ...)
> - help the maintainers (new versions, new docs)
> - be more attractive (in fact it'll be the role of CSS)
> - add interactivity ?
> - ...
> Once more, I think I should write a test engine before continuing this
> thread.

I worked through some PHP tutorials last week and was pleasantly surprised
at how well it fits in with HTML code.  I'm used to writing web pages in
Python and it isn't as nice as working with PHP.

It sounds like you have thought this through pretty well.  You do have a
good point that PHP has more headroom to grow.  I look forward to seeing
the test engine.

Thanks again for your input, Xavier!

Jerry
-- 
Xavier VELLO <xav...@fr...>

Hi

> > Once more, I think I should write a test engine before continuing this
> > thread.
> I agree.
> 
> BUT! Your test engine must be really great. I've some (minor) troubles 
> to accept PHP. But I have even a lot of more troubles to accept the need 
> of MySQL! And I have even bigger problems accepting both!
In fact, PHP is quite always used in conjunction with mysql. Instead of
 storing information (menus, users, variables) in files, it's easier
 (and more efficient) to  store them in a mysql table.

So, if I understand you, I it should be perfect and great, even if it's
just a "technology preview" ? (I like this term :)
These are the features I propose to you :
- dynamic content creation (to avoir frames and add some little things)
- a web-based administration interface (to manage news, menus ...)
- pools
- fully featured documentation area (zwe was originally writen for a
documentation e-zine)
- fully CSS and XHTML compliance (maybe with some 'proprietary' mozilla
CSS attributes).
- helper-functions to ease page writing

Features in zwe, but maybe not useful (I think) :
- forums (we have good MLs)
- user accounts (maybe for manage rights for admins ?)
- parsing of fixed-format text files (NEWS files, AUTHORS, ...) <- not
in the original engine, I added it later.

> (Hey! This ist just a little cute website about a little cute project!)
I know, but a cute project can also have a great nuclear-powered
 website ;) Are there some Greepeace folks here ? :)

> [Here in Austria, there's a lot of talks about our "Minister of Finace" 
> K.H. Grasser. He's got his private Hompage, which cost 285.000 EUR (in 
> words: two hundred eightyfive thousands euro)]
I just have one thing to say : I work for free ;)
But 285.000 EUR are 3560 Cwlinux displays :)

> Again, your test site must be really cool... Otherwise I'm afraid I will 
> follow Jerry's argumentation :-(
I think you'll have to wait for it a bit, but I promise you'll love it
(or at least I love it ;)

I'll first try to desing a fixed page with CSS/XHTML so you won't reject
the website because you don't like the desing. I'll mail when it's done.

Michael : In send you a tgz of 3 examples of zwe sites (just to see the
different styles that can be implemented). Put them in
test/zwe-examples if you want.

Bye !
-- 
Xavier VELLO <xav...@fr...>

Hi Xavier, Hi List,

> Once more, I think I should write a test engine before continuing this
> thread.

I agree.

BUT! Your test engine must be really great. I've some (minor) troubles 
to accept PHP. But I have even a lot of more troubles to accept the need 
of MySQL! And I have even bigger problems accepting both!

(Hey! This ist just a little cute website about a little cute project!)

[Here in Austria, there's a lot of talks about our "Minister of Finace" 
K.H. Grasser. He's got his private Hompage, which cost 285.000 EUR (in 
words: two hundred eightyfive thousands euro)]

Again, your test site must be really cool... Otherwise I'm afraid I will 
follow Jerry's argumentation :-(

bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Hi Jerry, hi list !

> 1. Exactly what on the lcd4linux website needs PHP?  We have a bunch
> of mostly static files up and it doesn't seem like we have many plans
> for dynamic content.  HTML and CSS are tailored to static content. 
> Why use PHP?  Xavier, you mentioned before that the News and Changelog
> sections could be automatically handled by PHP, but in reality, how
> often do these change?  Once a month?  When they are changed, how long
> does it take, maybe 30 minutes?  With PHP and your solution, how long
> will it take?  20 minutes?  Is the time-saving worth the extra time
> spent writing and maintaining the PHP pages?
In fact, then the site admin can add news with a web-based interface in
a bunch of minutes, modify last release (verion and date) information.
Adding a new documentation would just consist on SCPing the file and
adding a link in the mysql database.
It's right, maybe all this may not be suficient to justify the use of
PHP, but believe me, there are other reasons comming through my mind.
I'll code a test engine on my spare time, you'll be able to see it, and
then we'll discut more about it.

> 2. What happens when the PHP breaks and you aren't around to maintain
> it?  Michael then gets stuck with it because he wants to release the
> next version of lcd4linux and he has to update the webpage.  Myself,
> I would rather have Michael working on adding new features to lcd4linux
> than maintaining PHP code he knows nothing about. (I don't mean to 
> say that you aren't reliable or anything like that, just that we can't
> be around all the time.)
The purpose of such an engine is to code it once, and then not touch it.
The engine will consist of some include files, and then the interface
just has to include("../php-includes/include.inc"); and call the
predefined functions.
When releasing a new version, Michael would have to add a new, change
release variables, and upload an updated "what's new page".
Changing documentation would be : compiling docbook sources, passing it
through a script and SCPing it, that's all. I don't think the engine may
break without reasons.

> 3. Integration with autogenerated HTML, such as DocBook files that 
> are rendered in HTML.  Can we still throw the DocBook output up on
> the website?
Yes ! It's the main reason ! In fact, we'll have to write a modified dtd
stylesheet to call engine functions instead of using html tags. This may
be done with a script too without modifying the stylesheet, but a new
sheet would be proper.
/me has to learn more about docbook to know how to write customized
stylesheets.

> How is writing the webpages in PHP different from writing lcd4linux
> in Java?  PHP has a lot of really cool features that I don't see a 
> need for here.
You're rude here. In fact, I see a bunch of advantages to write the site
in PHP:
- keep documentations clean (without frames, fixed styles, ...)
- help the maintainers (new versions, new docs)
- be more attractive (in fact it'll be the role of CSS)
- add interactivity ?
- ...
Once more, I think I should write a test engine before continuing this
thread.

Bye !
-- 
Xavier VELLO <xav...@fr...>

Hello all,

Thanks Xavier and Martin for your input.

I do have a few concerns about using PHP.  It almost seems like PHP
is a solution in search of a problem.

1. Exactly what on the lcd4linux website needs PHP?  We have a bunch
of mostly static files up and it doesn't seem like we have many plans
for dynamic content.  HTML and CSS are tailored to static content. 
Why use PHP?  Xavier, you mentioned before that the News and Changelog
sections could be automatically handled by PHP, but in reality, how
often do these change?  Once a month?  When they are changed, how long
does it take, maybe 30 minutes?  With PHP and your solution, how long
will it take?  20 minutes?  Is the time-saving worth the extra time
spent writing and maintaining the PHP pages?

2. What happens when the PHP breaks and you aren't around to maintain
it?  Michael then gets stuck with it because he wants to release the
next version of lcd4linux and he has to update the webpage.  Myself,
I would rather have Michael working on adding new features to lcd4linux
than maintaining PHP code he knows nothing about. (I don't mean to 
say that you aren't reliable or anything like that, just that we can't
be around all the time.)

3. Integration with autogenerated HTML, such as DocBook files that 
are rendered in HTML.  Can we still throw the DocBook output up on
the website?

How is writing the webpages in PHP different from writing lcd4linux
in Java?  PHP has a lot of really cool features that I don't see a 
need for here.

Jerry

Hi Michael, hi list !

First, I decided to cut the thread because it grew too big, and finally
changed of topic.

> > But the better would be that I code a preliminary version, and we
may
> > > decide then. The claim is that I don't have any webspace with mysql. Can
> > > anyone help me for this ? Michael, can I host this test in
> > > http://lcd4linux.sf.net/test ?
> > Of course you can!
> > I hope you won't face any permission problems. If so, let me know.
- I created a test directory, it works ! I uploaded PhpMyAdmin in
test/pma to manage the database then, SF doesn't provide it.

- One of things I would like to do was coding a little GUI to manage
menus, news and others with a Gtk2-perl interface, but the mysql server
doesn't accept external requests :/ You'll have to deal with a
web-based administration interface

- Michael : Please ask for a DB, I tried but I don't have the right,
only project admins can. It's in the admin page, near to web space
requesting.

Bye !
-- 
Xavier VELLO <xav...@fr...>

Hi list !

> > But the better would be that I code a preliminary version, and we may
> > decide then. The claim is that I don't have any webspace with mysql. Can
> > anyone help me for this ? Michael, can I host this test in
> > http://lcd4linux.sf.net/test ?
> Of course you can!
> I hope you won't face any permission problems. If so, let me know.
Err... Please, can you ask for a mysql database ? I'll need one.
I don't know where to ask for it, and moreover, I don't have the right
to ask it ;)

> btw, as for the "PHP or not PHP" discussion, on epoint camt to my mind: 
> What I definitely do NOT want is a "What's new" made out of the 
> "Changelog" as, for ecample, the Samba team does). A Changelog is for 
> programmers, a "what's new" is for users.
> I really hate having to read over hundreds of lines about implementing 
> this function in that way and stuff, just to find the one interesting 
> line about a new config entry.
I know. The project I was talking about didn't auto-generate changelogs
 and have clean changelog, by release. I know, this file should be
 called NEWS ;)

> Another point: I've been trying to follow the KISS principle with the 
> current web site. I want you to follow this principle, too.
Keep it Simple, Stupid ? I don't really know what to keep simple ? The
code ? The navigation ? Both ?

> and a very other point: There's a discussion going on on the lcdproc 
> list about documentation licensing: They think about lidensing the docs 
> as GFDL (or something that sounds like that).
> Anybody knows about issues with GPL'ed docs?
At my side, I don't mind about documentation licensing. I don't think
 it's necessary for applications doc.
Moreover, FDL is not considered free by Debian, so there may be one more
problem.

I think GPL or non-licensed is sufficient.

Bye !
-- 
Xavier VELLO <xav...@fr...>

PS: This is the 20th mail of this thead !! Please don't reply directly
and create a new thread "Doc licensing" (or other) !

Hi Xavier,

> But the better would be that I code a preliminary version, and we may
> decide then. The claim is that I don't have any webspace with mysql. Can
> anyone help me for this ? Michael, can I host this test in
> http://lcd4linux.sf.net/test ?

Of course you can!
I hope you won't face any permission problems. If so, let me know.

btw, as for the "PHP or not PHP" discussion, on epoint camt to my mind: 
What I definitely do NOT want is a "What's new" made out of the 
"Changelog" as, for ecample, the Samba team does). A Changelog is for 
programmers, a "what's new" is for users.

I really hate having to read over hundreds of lines about implementing 
this function in that way and stuff, just to find the one interesting 
line about a new config entry.

Another point: I've been trying to follow the KISS principle with the 
current web site. I want you to follow this principle, too.

and a very other point: There's a discussion going on on the lcdproc 
list about documentation licensing: They think about lidensing the docs 
as GFDL (or something that sounds like that).

Anybody knows about issues with GPL'ed docs?

bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Hi Xavier,

>>>ASP is a ***** with VB inside. I would better code my own web server
>>> than using it.
>>
>>LOL. I guess I disagree with your view on VB (since I make a living 
>>writing code in VB, at least when the job calls for something written in 
>>VB - just try to write some simple DTS scripts for SQL server with 
>>anything else, and you'll know what I mean).
> 
> But SQL server is a ***** ;) 
Well, that's your opinion, and you're entitled to it ;-)

> In fact, I don't know really what DTS
>   means, but PHP and Perl handle very well SQL request (maybe sql
>  server doesn't use standard sql request).
DTS is "Data Transformation Services" - basically, scripts that run on 
the server to import/export/convert data. Very convenient for example if 
you get "data-dumps" from SAP (or some other system that doesn't have 
direct access to the database) or if you want to create data extracts 
from the data in SQL server (for example to create those Excel sheets 
that management loves so much).

This obviously has nothing to do at all with web-pages (ASP, PHP or 
whatever) - I was just taking issue with your statement that "ASP is a 
***** with VB inside") - VB has it's places, especially in corporate 
environments where you can't just go and tell them to dump the thousands 
of dollars/euros they've invested in their (Microsoft-centric) 
infrastructure and switch to linux/mysql/PHP/you name it because it's 
much more "kewl". Besides, ASP can use JScript too (and I recall seeing 
a Perl-version too, at some point).

>>I don't know how easy to deploy PHP is (since I've never used it), but I 
>>can't say that CGI scripts in perl are very hard to deploy (or even 
>>write) - that's another thing I do for my day-job, and I find writing 
>>and deploying perl CGI stuff rather straight forward. I also don't think 
>>that CGI is "outdated" - it surely isn't as "hip" as JSP or PHP, but 
>>then, I don't care much for hipness, when it comes to getting a job done 
>>(as you may have guessed, I don't work in marketing...).
> 
> To deploy a PHP script, you copy it on the server as a HTML page, and
> that's all ! Moreover, hosters prefer PHP and CGI for security and
> quotas reasons. HOsters can decide how much cpu and memory a script can
> use.
Yes, that's right. But this assumes that the Webserver in question 
already supports PHP already (which SF does, and which I acknowledged as 
a benefit for our scenario).
To deploy a CGI-script, you copy the files somewhere on the server, and 
add an entry in the Web-server's config to accept that location as a 
script directory (if one doesn't want to copy everything into the 
default cgi-bin directory). Just as simple, I guess

>>>I'm not really sure to understand you. Is PHP-Website an online-editing
>>>CMS ?
>>
>>I'm not sure what "online-editing CMS" would imply. With php-website, 
>>one can change the content by filling out HTML forms (which in turn get 
>>saved in a MySQL database, from which the actual pages are created) - if 
>>that's "online-editing", then yes, it is.
> 
> Yes, hat what I meant, like zwe-lite is. But I really dislike thit
>   solution because mysql request are slower than opening a file. 
Correct - especially when the SF staff is messing with the DB servers 
(which they have been doing a lot lately - or so it seems).

> I fact, it sounds more like a WiKi than like a CMS.
Well, to a certain extent, yes. But then, if that's the case, the 
professional CMS systems I've seen (vignette, for example) would qualify 
as a WiKi too. But I'm sure the guys from phpWebsite 
(http://phpwebsite.appstate.edu/) would have issues with phpWebsite 
being called a WiKi :-)

> But the better would be that I code a preliminary version, and we may
> decide then. The claim is that I don't have any webspace with mysql. Can
> anyone help me for this ? Michael, can I host this test in
> http://lcd4linux.sf.net/test ?
Indeed - that sounds like a very good idea. It's probably much more 
efficient to discuss a specific sample, rather than talk about PHP 
versus whatever in abstract.

Martin

Helli Martin, hello list !

> > ASP is a ***** with VB inside. I would better code my own web server
> >  than using it.
> LOL. I guess I disagree with your view on VB (since I make a living 
> writing code in VB, at least when the job calls for something written in 
> VB - just try to write some simple DTS scripts for SQL server with 
> anything else, and you'll know what I mean).
But SQL server is a ***** ;) In fact, I don't know really what DTS
  means, but PHP and Perl handle very well SQL request (maybe sql
 server doesn't use standard sql request).

> I don't know how easy to deploy PHP is (since I've never used it), but I 
> can't say that CGI scripts in perl are very hard to deploy (or even 
> write) - that's another thing I do for my day-job, and I find writing 
> and deploying perl CGI stuff rather straight forward. I also don't think 
> that CGI is "outdated" - it surely isn't as "hip" as JSP or PHP, but 
> then, I don't care much for hipness, when it comes to getting a job done 
> (as you may have guessed, I don't work in marketing...).
To deploy a PHP script, you copy it on the server as a HTML page, and
that's all ! Moreover, hosters prefer PHP and CGI for security and
quotas reasons. HOsters can decide how much cpu and memory a script can
use.

> > I'm not really sure to understand you. Is PHP-Website an online-editing
> > CMS ?
> I'm not sure what "online-editing CMS" would imply. With php-website, 
> one can change the content by filling out HTML forms (which in turn get 
> saved in a MySQL database, from which the actual pages are created) - if 
> that's "online-editing", then yes, it is.
Yes, hat what I meant, like zwe-lite is. But I really dislike thit
  solution because mysql request are slower than opening a file. I
 fact, it sounds more like a WiKi than like a CMS.

> > You're not clear at this. But My vision is to use PHP to 'assist' page
> >  writing : for 'normal' pages (not news or things like this), php is to
> >  insert headers, menu and things like this, and provide link(), img(),
> >  title() functions to avoid caring about which CSS class title use.
> Ok - in that case, I misunderstood your previous statement. But wouldn't 
> that mean that a change in the way a page looks would require a change 
> in the PHP code (since it hides the details about CSS classes and so 
> on)? Not that I hope we'd change the way the page looks like too often, 
> but having to change code to change the appearance somewhat contradicts 
> your point that "PHP generates HTML code, so it isn't heavier than pure 
> HTML".
Yes, but PHP code will be in a reduced set of files, with simple
 functions like this :
/* make a link to $to, in frame $window, printing $text */
function lien ($to, $where, $text)
{
  echo "\n<a href=\"$to\"";
  if ($where)
    echo " target=\"$where\"";
  echo ">$text</a>\n\n";
}

or this :
/* open a new paragraph */
function parag ($title = "")
{
  if ($title != "")
    {
      global $title_color;
      echo "<div class=\"ptitle\">\n";
      echo "$title\n";
      echo "</div>\n";
    }
  echo "<div class=\"pcontent\">\n";
}

The HTML code with class and folks show immediatly. And more cosmetical
changes will be done via CSS.

> Ok, that I surely can agree with. But that surely sounds like a CMS. I 
> guess the main thing we need to decide then is wether adding the 
> (relative) complexity is actually needed - I mean, how many people will 
> be updating the page? If Michael will be the only one (long term), it 
> would be hard to justify the extra work. If there are several people who 
> are willing to pick up the work, it sounds like the way to go.
Even it Michael is the only long-term maintainer, I think this engine
will be able to help him. Moreover, this would be the better way to
discard frames and include docbook-made documentation while looking
good.

But the better would be that I code a preliminary version, and we may
decide then. The claim is that I don't have any webspace with mysql. Can
anyone help me for this ? Michael, can I host this test in
http://lcd4linux.sf.net/test ?

Bye !
-- 
Xavier VELLO <xav...@fr...>

Hi Xavier,

I'm glad you didn't misunderstand my previous email.

>>>>- what are the benefits? (besides from being 'hip', which doesn't count 
>>>>for me)
>>>
>>>There are a lot :
>>>- using databases (for example to keep a table of porting status without
>>>rewriting HTML page, just modifying the sql table) (another example :
>>>news on front page).
>>
>>The same is true for for ASP and plain CGI
> 
> ASP is a ***** with VB inside. I would better code my own web server
>  than using it.
LOL. I guess I disagree with your view on VB (since I make a living 
writing code in VB, at least when the job calls for something written in 
VB - just try to write some simple DTS scripts for SQL server with 
anything else, and you'll know what I mean).

> plain CGI is becoming outdated and harder than PHP. PHP is embedded
> within html, so it's easy to deploy.
I don't know how easy to deploy PHP is (since I've never used it), but I 
can't say that CGI scripts in perl are very hard to deploy (or even 
write) - that's another thing I do for my day-job, and I find writing 
and deploying perl CGI stuff rather straight forward. I also don't think 
that CGI is "outdated" - it surely isn't as "hip" as JSP or PHP, but 
then, I don't care much for hipness, when it comes to getting a job done 
(as you may have guessed, I don't work in marketing...).

But I guess that's pretty much beside the point of the discussion at 
hand here.

>>All of the above is also true for ASP, and I avoid it like the plague 
>>(for various reasons). So why should we go for PHP, instead of plain 
>>HTML, or docbook (and pages generated on demand) or m4 (I run one site 
>>that's mainly static, which is generated using m4)?
> 
> In fact, I propose to code a sort of 'content managing system', and then
> integrate docbook-generated docs. The advantage is for the maintainance
> (news, new pages, ...).
In that case, I fully agree with you.

>>And while we're at it - when it comes to easily editing the pages (by 
>>several people), why not go with a content management system like 
>>PHP-Website (which is what leaf.sourceforge.net runs, for example)? It 
>>has a learning curve, but probably less so than coding directly in PHP. 
>>And the project leader at LEAF has pretty good connections to the PHP- 
>>Website crew, so getting help should not be a problem.
> 
> I'm not really sure to understand you. Is PHP-Website an online-editing
> CMS ?
I'm not sure what "online-editing CMS" would imply. With php-website, 
one can change the content by filling out HTML forms (which in turn get 
saved in a MySQL database, from which the actual pages are created) - if 
that's "online-editing", then yes, it is.

As I said, PHP-Website has some learning curve, but it's a nice tool to 
enable a large group of people to keep a page up to date.

> I don't think PHP produces a lot of lag. Maybe SF servers are
>   overloaded sometimes by bad-coded php pages ;) But this aspect can't
>  be a stopper.
Surely not.

>>>Believe me, PHP generates HTML code, so it isn't heavier than pure
>>>  HTML. I really dislike flash and JS. The only 'overload' is on the
>>> server, but don't worry.
>>
>>Well, but nobody would ever edit the HTML code generated by PHP, so 
>>what's your point? I mean, to me, PHP is a means to generate HTML - 
>>which is fundamentally different from HTML itself. I'm surely not 
>>proficient in PHP (and I don't plan to be any time soon), and I know 
>>that one can use inline HTML in PHP (or at least, I recall that being a 
>>possibiliy), but that surely doesn't equate to HTML itself. Again, I 
>>don't mean to put PHP down, I'd just like to keep the facts straight.
> 
> You're not clear at this. But My vision is to use PHP to 'assist' page
>  writing : for 'normal' pages (not news or things like this), php is to
>  insert headers, menu and things like this, and provide link(), img(),
>  title() functions to avoid caring about which CSS class title use.
Ok - in that case, I misunderstood your previous statement. But wouldn't 
that mean that a change in the way a page looks would require a change 
in the PHP code (since it hides the details about CSS classes and so 
on)? Not that I hope we'd change the way the page looks like too often, 
but having to change code to change the appearance somewhat contradicts 
your point that "PHP generates HTML code, so it isn't heavier than pure 
HTML".

>>I just wanted to put give a second opinion (and granted, a very negative 
>>one), based on my experience with other projects, where people have 
>>promised to take over maintenance of a web-page (the technology itself 
>>is rather irrelevant, actually) - in all those projects, this concept 
>>didn't go well in the long term. It's usually a good idea to use the 
>>skills of several people in the team, rather than rely on one single 
>>person to do everything that's needed for a certain task.
> 
> I propose to code the engine (in fact, I'll start from zero instead of
>  re-using the bloated zwe), which will be easy to understand, and then
>  enverybody will be able to upload pages, maintain different sections  
>  ... Menu, pools, some variables will be on mysql tables. I don't want
>  to (and can't) take over the maintainance of the site, just the coding
>  part, and help Jerry and Michael to write the pages.
Ok, that I surely can agree with. But that surely sounds like a CMS. I 
guess the main thing we need to decide then is wether adding the 
(relative) complexity is actually needed - I mean, how many people will 
be updating the page? If Michael will be the only one (long term), it 
would be hard to justify the extra work. If there are several people who 
are willing to pick up the work, it sounds like the way to go.

Martin

Hi all !

> >>- what are the benefits? (besides from being 'hip', which doesn't count 
> >>for me)
> > 
> > There are a lot :
> > - using databases (for example to keep a table of porting status without
> > rewriting HTML page, just modifying the sql table) (another example :
> > news on front page).
> The same is true for for ASP and plain CGI
ASP is a ***** with VB inside. I would better code my own web server
 than using it.
plain CGI is becoming outdated and harder than PHP. PHP is embedded
within html, so it's easy to deploy.

> > - cool things : display a little box with last version, web-interface
> > news system, ...
> If you implement those things, I guess you're already implementing some 
> kind of "content management system". Nothing bad at all, but probably 
> not a feature of PHP itself, but rather one you added with your coding 
> (and may I say, content management systems existe with plain CGI too).
You're right

> All of the above is also true for ASP, and I avoid it like the plague 
> (for various reasons). So why should we go for PHP, instead of plain 
> HTML, or docbook (and pages generated on demand) or m4 (I run one site 
> that's mainly static, which is generated using m4)?
In fact, I propose to code a sort of 'content managing system', and then
integrate docbook-generated docs. The advantage is for the maintainance
(news, new pages, ...).

> And while we're at it - when it comes to easily editing the pages (by 
> several people), why not go with a content management system like 
> PHP-Website (which is what leaf.sourceforge.net runs, for example)? It 
> has a learning curve, but probably less so than coding directly in PHP. 
> And the project leader at LEAF has pretty good connections to the PHP- 
> Website crew, so getting help should not be a problem.
I'm not really sure to understand you. Is PHP-Website an online-editing
CMS ?

> >>- what are the drawbacks?
> > Just one, it's one more language to learn ! But it's the same base
> > syntax as C and Perl, so no high learning price.
> > Another drawback was that at the beginning php wasn't supported by all
> > hosters, but now it's supported everywhere :)
> Well, I would like to add to that the fact that it's somewhat slow (not 
> PHP itself, but it surely is slow on most sourceforge servers I've seen)
I don't think PHP produces a lot of lag. Maybe SF servers are
  overloaded sometimes by bad-coded php pages ;) But this aspect can't
 be a stopper.

> > Believe me, PHP generates HTML code, so it isn't heavier than pure
> >   HTML. I really dislike flash and JS. The only 'overload' is on the
> >  server, but don't worry.
> Well, but nobody would ever edit the HTML code generated by PHP, so 
> what's your point? I mean, to me, PHP is a means to generate HTML - 
> which is fundamentally different from HTML itself. I'm surely not 
> proficient in PHP (and I don't plan to be any time soon), and I know 
> that one can use inline HTML in PHP (or at least, I recall that being a 
> possibiliy), but that surely doesn't equate to HTML itself. Again, I 
> don't mean to put PHP down, I'd just like to keep the facts straight.
You're not clear at this. But My vision is to use PHP to 'assist' page
 writing : for 'normal' pages (not news or things like this), php is to
 insert headers, menu and things like this, and provide link(), img(),
 title() functions to avoid caring about which CSS class title use.

> I just wanted to put give a second opinion (and granted, a very negative 
> one), based on my experience with other projects, where people have 
> promised to take over maintenance of a web-page (the technology itself 
> is rather irrelevant, actually) - in all those projects, this concept 
> didn't go well in the long term. It's usually a good idea to use the 
> skills of several people in the team, rather than rely on one single 
> person to do everything that's needed for a certain task.
I propose to code the engine (in fact, I'll start from zero instead of
 re-using the bloated zwe), which will be easy to understand, and then
 enverybody will be able to upload pages, maintain different sections  
 ... Menu, pools, some variables will be on mysql tables. I don't want
 to (and can't) take over the maintainance of the site, just the coding
 part, and help Jerry and Michael to write the pages.

Bye !
-- 
Xavier VELLO <xav...@fr...>

Hi Xavier, hi Michael,

Ok, I'll play devel's advocate here. Don't take this personally, I just 
want to offer a second opinion.

>>- what are the benefits? (besides from being 'hip', which doesn't count 
>>for me)
> 
> There are a lot :
> - using databases (for example to keep a table of porting status without
> rewriting HTML page, just modifying the sql table) (another example :
> news on front page).
The same is true for for ASP and plain CGI

> - dynamic generation of pages
The same is true for ASP and CGI

> - easy include system : for zwe, the concept is simple : the new page
the same is true for ASP, CGI and SSI

> includes a php include, has the article in XHTML and call function to
> insert headers, menus, images, code frames, links, ...
Again, plain ASP and CGI can do that as well

> The advantage of this, it for example that you can modify you menu or
> add 'general' links easilly without rewriting all the pages of using
> "deprecated" frames.
That's the nature of dynamically generated content, I guess - m4 can do 
that very well too (for static pages)

> - cool things : display a little box with last version, web-interface
> news system, ...
If you implement those things, I guess you're already implementing some 
kind of "content management system". Nothing bad at all, but probably 
not a feature of PHP itself, but rather one you added with your coding 
(and may I say, content management systems existe with plain CGI too).

All of the above is also true for ASP, and I avoid it like the plague 
(for various reasons). So why should we go for PHP, instead of plain 
HTML, or docbook (and pages generated on demand) or m4 (I run one site 
that's mainly static, which is generated using m4)?

I'd say the one strong point for PHP is that SF offers it on their 
servers (which isn't true for ASP and also SSI, at least I think so).

Don't get me wrong, I don't have anything against PHP per se - but I'm 
always wary if things are mainly done for reasons that sound like they 
came from some feature list written up by some marketing department.

And while we're at it - when it comes to easily editing the pages (by 
several people), why not go with a content management system like 
PHP-Website (which is what leaf.sourceforge.net runs, for example)? It 
has a learning curve, but probably less so than coding directly in PHP. 
And the project leader at LEAF has pretty good connections to the PHP- 
Website crew, so getting help should not be a problem.

>>- what are the drawbacks?
> 
> Just one, it's one more language to learn ! But it's the same base
> syntax as C and Perl, so no high learning price.
> Another drawback was that at the beginning php wasn't supported by all
> hosters, but now it's supported everywhere :)
Well, I would like to add to that the fact that it's somewhat slow (not 
PHP itself, but it surely is slow on most sourceforge servers I've seen)

>> From my side, I have two opinions: basically I don't care wheter the 
>>website is made of HTML, Flash, Java, PHP, Perl, VisualBasic (ok, remove 
>>that one) as long as it looks cool, renders correct, isn't full-bloated, 
>>and is up to date.
> 
> Believe me, PHP generates HTML code, so it isn't heavier than pure
>   HTML. I really dislike flash and JS. The only 'overload' is on the
>  server, but don't worry.
Well, but nobody would ever edit the HTML code generated by PHP, so 
what's your point? I mean, to me, PHP is a means to generate HTML - 
which is fundamentally different from HTML itself. I'm surely not 
proficient in PHP (and I don't plan to be any time soon), and I know 
that one can use inline HTML in PHP (or at least, I recall that being a 
possibiliy), but that surely doesn't equate to HTML itself. Again, I 
don't mean to put PHP down, I'd just like to keep the facts straight.

>>OTOH, if I am to keep it up to date or if I should assist in maintaining 
>>it, it should be bare HTML, 'cause it's the only web language I'm able 
>>to read and write. I don't even know CSS (I've seen it, and I disliked 
>>it, because I did not understand it :-)
> 
> In fact, you write your pages in HTML, but you include a file and call
> PHP functions to help to format (and insert common tags). CSS looks
> strange at first sight, but it can really produce good looking sites.
Well, being a big fan of CSS myself, I'd agree, even though that's 
probably not one of the main reasons to use CSS - to me, the main reason 
is that it enables the developer to separate content and appearance, 
which is always a nice thing. In short, you code your webpage specifying 
what kind of data the tags represent, and the CSS is in charge of 
specifying how that data looks like. Separating data from appearance can 
make maintenance of a web-page much easier (you specify _once_ how 
things should look like, as opposed to with every change).

One nice side-effect of CSS is that (if properly used) the page renders 
well on all standards compliant browsers, without too much experimenting.

>>So, change it to PHP or CSS or both if you think it's good, but PLEASE 
>>do not handover the maintenance to me after a couple of weeks...
> 
> In the better dreams, once I have finished the coding, we could write
> the help pages in docbook and then modify them a bit to include them in
> the site. I've already designed 4 sites with zwe and derivated works,
> but they are all in tuxfamily servers, which are down :/
Which of course would mean that you'd be the sole person in charge of 
keeping the page up to date (at least the "infrastructure" behind it - 
I'm not talking about some "what's new" item that's parsed by PHP 
scripts) - are you aware of that, and willing to commit to that? I mean 
even during holiday seasons, finals season or whatever other time it you 
might have other things on your hands (as we all do from time to time), 
if Michael decides to push out a new release? To me, it's always been a 
bad idea to put the burden of keeping a web-page up to date on the 
shoulders of one single person.

Again, don't get me wrong - I don't have a problem with PHP per se (even 
though I will surely not read up to get up to speed with how it works),

I just wanted to put give a second opinion (and granted, a very negative 
one), based on my experience with other projects, where people have 
promised to take over maintenance of a web-page (the technology itself 
is rather irrelevant, actually) - in all those projects, this concept 
didn't go well in the long term. It's usually a good idea to use the 
skills of several people in the team, rather than rely on one single 
person to do everything that's needed for a certain task.

Hopefully, this won't trigger a flamewar (I guess things like "PHP is 
better/worse than..." tend to do so).

Martin

Hello all !
> >>- it lags a lot ! Dunno if there's an option to configure refresh rate,
> >>if so, default value is too high. 
> > Sory, the lag is from xmms(), I don't know why (maybe marquee text). It
> > works great with half a dozen of icons, good job !
> Fine. I love it when problems solve themselves alone....
But now I'll have to guess why xmms lags :/

> >>- visible attribute for icons is inverted ! It shows if visible<0, and
> >>hides if visible>0 :/ I think the problem is in drv_generic_graphic.c
> > I checked, the problem is in drv_generic_graphic. Here's a patch to
> > correct it.
> erm... where? (the patch)
Sorry :/ Here it is

> > Last but not least, will you implement a 'zoom' configuration ? By now,
> > a 'logical' pixel is displayed with a 'dot' of multiple pixels. This
> > 'resolution' should be configurable, for example for gnome applet (which
> > I would use to display graphs only).
> Isn't  "pixel" and "gap" config entries what you're asking for? Take a 
> look at the (old) Display/X11 section on http://lcd4linux.sf.net
Yes, sorry

> > For posterity, I would dream about using multiple colors on X11 (example
> > one graph in blue, one in red, ...), but we may implement it later.
> That's why the generic graphic framebuffer takes already a byte for a 
> pixel (and not a single bit). Someday I want to support colors...
Very good !!

Bye !
-- 
Xavier VELLO <xav...@fr...>

Hi Michael, hi list !
> 
> >>My personal opinion is to leave it in html for the time being.  How would
> >>you feel about modifying the web page to not use frames, and perhaps use
> >>CSS?
> > I became quite good with CSS and folks. A first step would be to use
> > CSS. But I think php may be a good thing. It's up to the team to decide
> 
> Ok, as a decision basis, could someone please explain PHP to me?
I'll try :

> - what does PHP mean? (as you can see from this question, I really dont 
> know anything about it :-)
For the PHP manual (php-doc package if I remember well) :
PHP (recursive acronym for "PHP: Hypertext Preprocessor") is a
widely-used Open Source general-purpose scripting language that is
especially suited for Web development and can be embedded into HTML. 

> - what is it for?
In short, it can process pages dynamically, to make the site maintainer
 work less and the server make the work ;) You include code within HTML
 code, just between <? and ?> marks.

> - what are the benefits? (besides from being 'hip', which doesn't count 
> for me)
There are a lot :
- using databases (for example to keep a table of porting status without
rewriting HTML page, just modifying the sql table) (another example :
news on front page).
- dynamic generation of pages
- easy include system : for zwe, the concept is simple : the new page
includes a php include, has the article in XHTML and call function to
insert headers, menus, images, code frames, links, ...
The advantage of this, it for example that you can modify you menu or
add 'general' links easilly without rewriting all the pages of using
"deprecated" frames.
- cool things : display a little box with last version, web-interface
news system, ...

> - what are the drawbacks?
Just one, it's one more language to learn ! But it's the same base
syntax as C and Perl, so no high learning price.
Another drawback was that at the beginning php wasn't supported by all
hosters, but now it's supported everywhere :)

>  From my side, I have two opinions: basically I don't care wheter the 
> website is made of HTML, Flash, Java, PHP, Perl, VisualBasic (ok, remove 
> that one) as long as it looks cool, renders correct, isn't full-bloated, 
> and is up to date.
Believe me, PHP generates HTML code, so it isn't heavier than pure
  HTML. I really dislike flash and JS. The only 'overload' is on the
 server, but don't worry.

> OTOH, if I am to keep it up to date or if I should assist in maintaining 
> it, it should be bare HTML, 'cause it's the only web language I'm able 
> to read and write. I don't even know CSS (I've seen it, and I disliked 
> it, because I did not understand it :-)
In fact, you write your pages in HTML, but you include a file and call
PHP functions to help to format (and insert common tags). CSS looks
strange at first sight, but it can really produce good looking sites.

> So, change it to PHP or CSS or both if you think it's good, but PLEASE 
> do not handover the maintenance to me after a couple of weeks...
In the better dreams, once I have finished the coding, we could write
the help pages in docbook and then modify them a bit to include them in
the site. I've already designed 4 sites with zwe and derivated works,
but they are all in tuxfamily servers, which are down :/

Bye !
-- 
Xavier VELLO <xav...@fr...>

Hi Xavier, Jerry,

>>My personal opinion is to leave it in html for the time being.  How would
>>you feel about modifying the web page to not use frames, and perhaps use
>>CSS?
> 
> I became quite good with CSS and folks. A first step would be to use
> CSS. But I think php may be a good thing. It's up to the team to decide

Ok, as a decision basis, could someone please explain PHP to me?

- what does PHP mean? (as you can see from this question, I really dont 
know anything about it :-)

- what is it for?

- what are the benefits? (besides from being 'hip', which doesn't count 
for me)

- what are the drawbacks?

 From my side, I have two opinions: basically I don't care wheter the 
website is made of HTML, Flash, Java, PHP, Perl, VisualBasic (ok, remove 
that one) as long as it looks cool, renders correct, isn't full-bloated, 
and is up to date.

OTOH, if I am to keep it up to date or if I should assist in maintaining 
it, it should be bare HTML, 'cause it's the only web language I'm able 
to read and write. I don't even know CSS (I've seen it, and I disliked 
it, because I did not understand it :-)

So, change it to PHP or CSS or both if you think it's good, but PLEASE 
do not handover the maintenance to me after a couple of weeks...

bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Hi Xavier #1 :-)

>>- it lags a lot ! Dunno if there's an option to configure refresh rate,
>>if so, default value is too high.
> 
> Sory, the lag is from xmms(), I don't know why (maybe marquee text). It
> works great with half a dozen of icons, good job !

Fine. I love it when problems solve themselves alone....

>>- visible attribute for icons is inverted ! It shows if visible<0, and
>>hides if visible>0 :/ I think the problem is in drv_generic_graphic.c
> 
> I checked, the problem is in drv_generic_graphic. Here's a patch to
> correct it.

erm... where? (the patch)

> In fact, the problem was in the :? statement. I dislike this syntax, if
> statements are cleaner, and less prone to errors.
Me too, but sometimes a ?: is much more elegant and short.

> Last but not least, will you implement a 'zoom' configuration ? By now,
> a 'logical' pixel is displayed with a 'dot' of multiple pixels. This
> 'resolution' should be configurable, for example for gnome applet (which
> I would use to display graphs only).

Isn't  "pixel" and "gap" config entries what you're asking for? Take a 
look at the (old) Display/X11 section on http://lcd4linux.sf.net

> For posterity, I would dream about using multiple colors on X11 (example
> one graph in blue, one in red, ...), but we may implement it later.

That's why the generic graphic framebuffer takes already a byte for a 
pixel (and not a single bit). Someday I want to support colors...

bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Little fixes :

> - it lags a lot ! Dunno if there's an option to configure refresh rate,
> if so, default value is too high.
Sory, the lag is from xmms(), I don't know why (maybe marquee text). It
works great with half a dozen of icons, good job !

> - visible attribute for icons is inverted ! It shows if visible<0, and
> hides if visible>0 :/ I think the problem is in drv_generic_graphic.c
I checked, the problem is in drv_generic_graphic. Here's a patch to
correct it.
In fact, the problem was in the :? statement. I dislike this syntax, if
statements are cleaner, and less prone to errors.

> - some icons don't display : karo works, but squirell doesn't show !! I
> really don't know where the bug is, but I didn't look at the code, I'll
> do it this WE.
Just a consequence of the above ! Squirell had visible=1, so it didn't
 show ;)

Last but not least, will you implement a 'zoom' configuration ? By now,
a 'logical' pixel is displayed with a 'dot' of multiple pixels. This
'resolution' should be configurable, for example for gnome applet (which
I would use to display graphs only).

For posterity, I would dream about using multiple colors on X11 (example
one graph in blue, one in red, ...), but we may implement it later.

Bye !
-- 
Xavier VELLO <xav...@fr...>

Hello list, hello Michael !

As promised, I tested X11 driver, and there are some caveats :
- it lags a lot ! Dunno if there's an option to configure refresh rate,
if so, default value is too high.
- visible attribute for icons is inverted ! It shows if visible<0, and
hides if visible>0 :/ I think the problem is in drv_generic_graphic.c
- some icons don't display : karo works, but squirell doesn't show !! I
really don't know where the bug is, but I didn't look at the code, I'll
do it this WE.

Bye !
-- 
Xavier VELLO <xav...@fr...>

Hello Luk, hello all !

> > - postinst script crashes. I think it'd be better to remove the dialog I
> > put, it's not worth the price.
> Yes, we should avoid user interaction at the install stage if possible. 
> We should however document the configuration file (README?, pointer in 
> manpage?).
I think too we should remove the dialog.

> > - there is still a permission problem with /etc/lcd4linux.conf. It must
> > be owned by root.root and be 0600, we must modify debian/rules for this.
> Shouldn't be hard to take care of.
Yes, a chmod in debian/rules would be enough.

> > - who will be the maintainer ? I definitively can't as I'll go in a
> > boarding school, with certainly no regular net access.
> If we find nobody to maintain the package we can start by a 'Request To 
> Package' (see http://www.debian.org/devel/wnpp).
Okay. Can't you be the maintainer ? I'll try to ask other friends from
debian "french connection" it someone would like to maintain it. Then,
we'll send a request.

-- 
Xavier VELLO <xav...@fr...>

Hello Xavier, I'm Xavier ;)

First, you must care to "reply to list" when writing to lists on SF, or
you'll reply to the last who posted. It's a common error.

> I've found a memory leak (( I didn't try to find it out in the source t=
ough ))
> So Here it goes :
> If you set more than the screen height in the Layout,
> it leak at FULL Trotle =3D)) ( like filling up like 60 mb in few min =3D=
))
I tried to define 3 rows on my HD44780 2 rows display, I don't find any
 leak. In fact, we had problems with it some time ago, as the layout FB
 is dynamically resized (at lcd4linux segfaulted). We thought it was
 fixed.
Please send us your configuration, maybe there's something wrong.

At my side, I get with top this :
  485 root      15   0  3472 1100  3344 S     1.7  0.4   0:02 lcd4linux
And the size doesn't grow.

In fact, lcd4linux went through a total rewrite, and it's not totally
bugfree=C2=A9. There's a compile option to use dmalloc to search the memo=
ry
leaks, maybe Michael can help you with it.

> BTW, what is the option to enable Virtual Screen ( probably a option
> I did'nt set.. )
Virtual screens haven't been ported yet. This feature will be made =20
 with the future event interface. The event interface will handle
  input from multiple sources (display keypads, gamempad, socket, ...)
 and handle internal timers, to then call functions.
I'm sorry you'll have to wait for this to be implemented (I think it'll
be for 0.10.1).

> Thank you all for your Good works =3D)
All the Team thanks you for the regards, and for using this masterpiece
 of software ;)

Bye !
--=20
Xavier VELLO <xav...@fr...>

PS: Are you registered on the ML ? I put your own email in CC just in
case. Don't forget to reply _only_ to lcd...@li...

Hi there all, 

I've found a memory leak (( I didn't try to find it out in the source tough ))
So Here it goes :

If you set more than the screen height in the Layout,
it leak at FULL Trotle =)) ( like filling up like 60 mb in few min =))

BTW, what is the option to enable Virtual Screen ( probably a option
I did'nt set.. )

Thank you all for your Good works =)

Xavier LaRue

On Wed, Feb 25, 2004 at 12:53:01PM +0100, Xavier VELLO wrote:
> In fact docbook is very used for documentation, for example
>   documentation of gnome projects is done with, Linux Documentation
>  Projet too, ...
> It's one more markup language to learn, but it isn't harder than HTML
> (and vim has syntax coloring support for it)

Oh cool.  If vim has syntax coloring for it, then it must be good! :)
Seriously though, it does sound like the way to go. 

> > 1. Do we really need PHP?  PHP really becomes useful when you want to have
> > dynamic content on the web.  Unless we have plans to generate dynamic content
> > (do we?), I'd rather leave the webpage in html or something similar that
> > almost everybody can easily edit.
> In fact, PHP isn't an absolute necessity, but it can be useful for
>  news, release info, processing of Changelog, ...
> I've written a changelog/todo parser for another project which retrieves
> the changelog from CVS and parse it with bold, underline and things like
> this, very eye-candy ;)

Okay, I can see it being useful for updating the news and changelog sections.
Michael, what would you like to use?

Would we do the whole site using PHP, or just those two sections?

> PS: Jerry, always use Reply to List to reply to mails at
> lcd4linux-devel as SF doesn't support reply-to tag.

Thanks!  Before today I didn't even know such a thing existed. :)

2004	Jan (57)	Feb (71)	Mar (80)	Apr (40)	May (49)	Jun (20)	Jul (3)	Aug (9)	Sep (8)	Oct (2)	Nov	Dec (11)
2005	Jan (10)	Feb (25)	Mar (24)	Apr (26)	May (71)	Jun (35)	Jul (5)	Aug (3)	Sep (18)	Oct (4)	Nov (5)	Dec (2)
2006	Jan (50)	Feb (12)	Mar (7)	Apr (24)	May (1)	Jun (17)	Jul (51)	Aug (38)	Sep (38)	Oct (33)	Nov (8)	Dec (13)
2007	Jan (44)	Feb (25)	Mar (21)	Apr (68)	May (52)	Jun (24)	Jul (17)	Aug (12)	Sep (4)	Oct (14)	Nov (1)	Dec (3)
2008	Jan (9)	Feb (1)	Mar	Apr (5)	May	Jun	Jul (1)	Aug (1)	Sep (5)	Oct (5)	Nov (1)	Dec
2009	Jan (4)	Feb	Mar (2)	Apr (1)	May (21)	Jun (5)	Jul	Aug	Sep (4)	Oct (1)	Nov	Dec
2010	Jan (15)	Feb (36)	Mar (1)	Apr	May	Jun (2)	Jul (3)	Aug	Sep (2)	Oct	Nov (1)	Dec (3)
2011	Jan (22)	Feb (2)	Mar (2)	Apr (1)	May (2)	Jun	Jul (25)	Aug	Sep	Oct	Nov	Dec (4)
2012	Jan (14)	Feb (6)	Mar (20)	Apr (12)	May	Jun (1)	Jul	Aug	Sep (1)	Oct (2)	Nov (2)	Dec
2013	Jan	Feb (3)	Mar (2)	Apr (1)	May (9)	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec (1)
2014	Jan (1)	Feb (1)	Mar (3)	Apr (2)	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2015	Jan	Feb	Mar (5)	Apr	May	Jun (11)	Jul (1)	Aug (3)	Sep	Oct	Nov (1)	Dec
2016	Jan (2)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2018	Jan	Feb (1)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

lcd4linux-devel Mailing List for lcd4linux (Page 47)

lcd4linux-devel — lcd4linux development team