lcd4linux-devel — lcd4linux development team

Re: [Lcd4linux-devel] this and that

[Xavier V. <xav...@fr...>]

Hello list

> >>I don't think a seperation in 'hard' and 'soft' does make sense...
> What do you mean by 'hard' and 'soft' (Depends, Recommends and Suggests?)?

#debian-devel-fr folks suggested to have a lcd4linux-drivers-hard (for
 real displays, with no external dep) and lcd4linux-drivers-soft (for
 X11,ncurses, ... so extern dep), but I don't think mayself it's good.

> >>Plugins with external dependencies: one .deb for every plugin ?
> >>Drivers with external dependencies: one .deb for each driver ?
> Definitely not, unless you only ever want a few plugins/drivers.
Markus suggested to have theme-based plugins :
lcd4linux-plugins-multimedia (xmms, others)
lcd4linux-plugins-system (i2c, cpu, mem, ...)
lcd4linux-drivers (hardware drivers)
lcd4linux-ncurses
lcd4linux-X11 (maybe both in the same deb ?)
lcd4linux-gnome-applet 
...

> > I really don't know what to do about this :/
> > Packaging non-dep plugins into lcd4linux package is a good idea. If
> > extern-deps plugins are not numerous we may think about making
> > one-plugin debs.
> Possible, another solution would be to Recommend the 'extern-deps' and 
> document the use of the dependencies in the extended description (so 
> everything is in one package).
I think it may be the better choice.

> How compares lcd4linux with lcdproc 
> (http://packages.debian.org/unstable/utils/lcdproc)?
I fact, lcdproc works with a networked server-client model : there's  
 LCDd, the server which cares of display and manages a network port,
  and multiple client (like lcdproc) which retrieve information, but I
 don't think lcdproc uses extern libraries.
OTOH, LCDd uses libncurses and I think it's a dep.

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

Re: [Lcd4linux-devel] manpage for lcd4linux

[Xavier V. <xav...@fr...>]

Hello Jerry !

> I would be willing to go with docbook if it suits our needs.  I have never
> used docbook before, but then I had never written a manpage before last
> week. :)  Is docbook used in other open source projects?
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)

> > BTW: I SCPed the lcd4linux site, maybe it would be a good thing to
> > rewrite it a bit to avoid frames and friends. If you don't forbid me, I
> > would greatly like to give a try and rewrite it in PHP.
> I won't stop you from writing it in PHP, but...
> 
> 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 ;)

> 2. Right now the webpage is hosted on Sourceforge, I believe.  Does Sourceforge
> provide PHP?  If it doesn't, this would be a show-stopper.
Yes, SF provides PHP (hopefully)

> 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

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

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

Re: [Lcd4linux-devel] this and that

[Luk C. <in...@us...>]

Hi list

>>Debian packaging: a core package including the core and only plugins and 
>>drivers without any dependencies should be ok (no need to put all 
>>drivers in extra packages: the core should make sense 'alone')

Indeed.

>>I don't think a seperation in 'hard' and 'soft' does make sense...

What do you mean by 'hard' and 'soft' (Depends, Recommends and Suggests?)?

>>Plugins with external dependencies: one .deb for every plugin ?
>>Drivers with external dependencies: one .deb for each driver ?

Definitely not, unless you only ever want a few plugins/drivers.

> I really don't know what to do about this :/
> Packaging non-dep plugins into lcd4linux package is a good idea. If
> extern-deps plugins are not numerous we may think about making
> one-plugin debs.

Possible, another solution would be to Recommend the 'extern-deps' and 
document the use of the dependencies in the extended description (so 
everything is in one package).

How compares lcd4linux with lcdproc 
(http://packages.debian.org/unstable/utils/lcdproc)?

Cheers

Luk

Re: [Lcd4linux-devel] this and that

[Michael R. <re...@eu...>]

Hi Xavier,

> BTW: would it be possible to build a gnome-applet on top of X11 or
> pixmap plugin rapidly without rewriting all the code ? I really dislike
> gnome-multiload-applet :/

I can't say, because I don't either know Gnope nor the multiload applet. 
But I think we have a volunteer who will find out :-)

>>PHP is ok for me, too. But, Xavier, with your bad internet connection, 
>>how would you keep things up to date regularly? I can't be of much help, 
>>  because I don't even know how BHB is spelled :-)
> 
> I fact, I can code the site, and then Jerry can manage it. The zwe  
>  engine works with predefined functions in an include and writing
>   pages is _really_ easy (just calling functions for titles, special
>  div, ...)

Ok. It's your and Jerry's decision.

> I really don't know what to do about this :/
> Packaging non-dep plugins into lcd4linux package is a good idea. If
> extern-deps plugins are not numerous we may think about making
> one-plugin debs.
or grouping plugins and drivers by dependencies?

>>Is there anything really missing for 0.10.0?
>>- isdn (completely missing)
>>- GPO's (completely missing)
>>- Key/Event handling (completely undone)
> 
> What about driving multiple displays (one layout per display) from a
> single lcd4linux instance ? I don't know if it's technically possible,
> but it may be a good thing (think about a toshiba graphic display to
> show graphs and a MO to drive PWM fans + a gnome applet)

I don't know wether it's possible to code, shurely not implemented at 
the moment. And I don't think it's necessary. If you have two displays, 
use two instances.

bye, Michael

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

Re: [Lcd4linux-devel] this and that

[Xavier V. <xav...@fr...>]

Hi list !

> heavy traffic here!
Right !

> First, an announcement: The new X11 driver is finished! Much easier than 
> the old one, becuase of no second updater thread necessary.
Cool ! I'll test it heavilly.
BTW: would it be possible to build a gnome-applet on top of X11 or
pixmap plugin rapidly without rewriting all the code ? I really dislike
gnome-multiload-applet :/

> Task list from Xavier: checked as "Status" into CVS. Great work! But I 
> didn't update it by now...
Thanks.

> PHP is ok for me, too. But, Xavier, with your bad internet connection, 
> how would you keep things up to date regularly? I can't be of much help, 
>   because I don't even know how BHB is spelled :-)
I fact, I can code the site, and then Jerry can manage it. The zwe  
 engine works with predefined functions in an include and writing
  pages is _really_ easy (just calling functions for titles, special
 div, ...)

> Debian packaging: a core package including the core and only plugins and 
> drivers without any dependencies should be ok (no need to put all 
> drivers in extra packages: the core should make sense 'alone')
> I don't think a seperation in 'hard' and 'soft' does make sense...
> 
> Plugins with external dependencies: one .deb for every plugin ?
> Drivers with external dependencies: one .deb for each driver ?
I really don't know what to do about this :/
Packaging non-dep plugins into lcd4linux package is a good idea. If
extern-deps plugins are not numerous we may think about making
one-plugin debs.

> Is there anything really missing for 0.10.0?
> - isdn (completely missing)
> - GPO's (completely missing)
> - Key/Event handling (completely undone)
What about driving multiple displays (one layout per display) from a
single lcd4linux instance ? I don't know if it's technically possible,
but it may be a good thing (think about a toshiba graphic display to
show graphs and a MO to drive PWM fans + a gnome applet)

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

[Lcd4linux-devel] this and that

[Michael R. <re...@eu...>]

Hi there,

heavy traffic here!

First, an announcement: The new X11 driver is finished! Much easier than 
the old one, becuase of no second updater thread necessary.

To save some time, I'm commenting on several mails at once:

Task list from Xavier: checked as "Status" into CVS. Great work! But I 
didn't update it by now...

Man Page: DocBook is ok for me, and seems to be commmon sense. But our 
new "DocMgr" didn't response by now... (Jerry?)

PHP is ok for me, too. But, Xavier, with your bad internet connection, 
how would you keep things up to date regularly? I can't be of much help, 
  because I don't even know how BHB is spelled :-)

Again, Jerry? your opinion?

Debian packaging: a core package including the core and only plugins and 
drivers without any dependencies should be ok (no need to put all 
drivers in extra packages: the core should make sense 'alone')

I don't think a seperation in 'hard' and 'soft' does make sense...

Plugins with external dependencies: one .deb for every plugin ?
Drivers with external dependencies: one .deb for each driver ?


again, this is stuff for 0.10.1

Is there anything really missing for 0.10.0?

- isdn (completely missing)
- GPO's (completely missing)
- Key/Event handling (completely undone)

I want all (important) features of 0.9.11 to be in the 0.10.0. Key/Event 
handling would be a new feature, but GPO's will be built upon that (you 
will have "Timer" events and "user timers" and "handlers" specified in 
the config file)


bye, Michael

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

Re: [Lcd4linux-devel] manpage for lcd4linux

[Samuel M. <sam...@en...>]

Hello,

I had started a docbook version of the help webpage which I joined to
this mail. It is far from being complete but it shows that it is quite
easy to make an sgml document from which you'll be able to generate the
man page as well as a webpage.

Cheers,

Sam.

On Mon, 23 Feb 2004 23:46:28 +0100
Martin Hejl <ma...@he...> wrote:

> Hi Xavier,
> 
> >>There are plans to generate both the manpage and the web page out of
> >
> >>something like "docbook". I don't know it, so I can't tell you if
> >its a >good or bad idea. But having a common source is a good thing
> >in any case...
> > 
> > In fact, DTML is as easy as writing HTML, but then it can be
> > processed to create manpages and HTML pages. This would help keeping
> > it all in sync.
> > Read doc in docbook-doc package to find out.
> I actually got started writing up a users manual for the 
> "next-generation lcd4linux" in docbook - but unfortunately, other
> (more urgent) things to do got in the way, so there's not much to show
> (and it's a _lot_ to document, especially when one is still in the
> process finding out all the implications and possibilities of the new
> config system).
> 
> I guess documenting the drivers should be fairly easy (since most of
> it is the same as with the old version, it's just expressed in a
> different format in the config file) - but the plugin and layout
> definition surely is a different story.
> 
> Besides, I was struggling a bit with where to start, and what to
> explain where - I mean, looking at it from a new user's perspective,
> this can all be pretty overwhelming.
> 
> In short, I'm all for docbook (we use it at LEAF with great success), 
> and I'm surely willing to help out with documentation (especially if 
> it's in docbook-XML format)
> 
> Martin
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Lcd4linux-devel mailing list
> Lcd...@li...
> https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel


-- 
Samuel Mimram

sam...@en...

BOFH excuse #141:

disks spinning backwards - toggle the hemisphere jumper.

Re: [Lcd4linux-devel] manpage for lcd4linux

[Martin H. <ma...@he...>]

Hi Xavier,

>>There are plans to generate both the manpage and the web page out of 
>>something like "docbook". I don't know it, so I can't tell you if its a 
>>good or bad idea. But having a common source is a good thing in any case...
> 
> In fact, DTML is as easy as writing HTML, but then it can be processed
> to create manpages and HTML pages. This would help keeping it all in
> sync.
> Read doc in docbook-doc package to find out.
I actually got started writing up a users manual for the 
"next-generation lcd4linux" in docbook - but unfortunately, other (more 
urgent) things to do got in the way, so there's not much to show (and 
it's a _lot_ to document, especially when one is still in the process 
finding out all the implications and possibilities of the new config 
system).

I guess documenting the drivers should be fairly easy (since most of it 
is the same as with the old version, it's just expressed in a different 
format in the config file) - but the plugin and layout definition surely 
is a different story.

Besides, I was struggling a bit with where to start, and what to explain 
where - I mean, looking at it from a new user's perspective, this can 
all be pretty overwhelming.

In short, I'm all for docbook (we use it at LEAF with great success), 
and I'm surely willing to help out with documentation (especially if 
it's in docbook-XML format)

Martin

Re: [Lcd4linux-devel] Re: lcd4linux 0.9.12

[Xavier V. <xav...@fr...>]

Hello list.

> >>(Xavier, 
> >>you had this great planning sheet, is it up to date?)
> > 
> > Err... I dropped it to write one in plain text, but it's not up to date
> >  (in fact, there are just displays). Do you want me to actualize it ?
> 
> Yes, that would be great. As my real-life job takes a lot of time at the 
> moment, I can never remember what I've been working on yesterday :-)
It's in a separate post.

> >>I think we should release something like a "pre" or "beta" or whatever 
> >>you want to call it. What do you think?
> > 
> > maybe lcd4linux-0.9.12-RC1, then lcd4linux-0.9.12.RC2, ... 
> good ideas.
Thanks.

> > BTW: it's a total rewrite of lcd4linux, I don't think a minor version
> > reflects it ! Maybe 0.10.0 ? I don't vote for 1.0.0, as there are still
> > bugs and ToDo.
> Even better idea. So NextGeneration will be 0.10.0
I won \o/ :D

Bye ;)
-- 
Xavier VELLO <xav...@fr...>

Re: [Lcd4linux-devel] manpage for lcd4linux

[Xavier V. <xav...@fr...>]

Hi all !

> There are plans to generate both the manpage and the web page out of 
> something like "docbook". I don't know it, so I can't tell you if its a 
> good or bad idea. But having a common source is a good thing in any case...
In fact, DTML is as easy as writing HTML, but then it can be processed
to create manpages and HTML pages. This would help keeping it all in
sync.
Read doc in docbook-doc package to find out.

> There are plans to do a rewrite of the webpage as a whole (avoid frames, 
> use PHP).
> I want all this stuff to be decided by the guy who's job is to manage 
> it. So this would be you...
Michael, php coding and doc writing may be done by different persons
too. I talk PHP quite well and contributed to a light php engine called
ZWE. But most of sites using zwe were hosted at tuxfamily.org but their
services are closed for the moment : the only site up using zwe is
www.bulix.org (in fact it's zwe-lite, a blog engine, but zwe is really
good).

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

Re: [Lcd4linux-devel] Re: lcd4linux 0.9.12

[Xavier V. <xav...@fr...>]

> I thinks it will take some time until NextGeneration is ready for 
> release. There are some Todo's which are not finished by now (Xavier, 
> you had this great planning sheet, is it up to date?)
Here is the plain text one, mostly up to date.
In fact I didn't check if new features were added to displays (CZ, MO,
...), so read it and correct it before putting it on CVS.

BTW: here's the ToDo section, so everyone can discuss it :
 
 TODO : task {assigned to}
--------
* namespace support for plugins (with ::) {Michael}
- support visible attribute for widgets other than icons
- time-based bars for graphic displays
- dynamic loading of plugins/displays/input
>> after next release it seems ?
- add support for input (display keypads, gamepads, socket, ...)
>> gamepad and socket were suggested to me by french debian stuff ;)
* finish debian package {Xavier, Luk, Samuel}
>> see another thread on the ML

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

Re: [Lcd4linux-devel] lcd4linux4debian

[Michael R. <re...@eu...>]

Hi Xavier,

> Now, let's talk about what to do for debian, he're the claim :
> A lot of lcd4linux plugins (and soon drivers) do (or will) rely on
> external libraries, system calls, ... how to handle it ?

Good question! An another point that votes for dynamic loading!

> - make one big lcd4linx package which depends on libx11, libncurses, ...
> and don't please to embedded systems.
Not so good.

> - make separate package for each plugin and driver, but I talked to
> debian devs and they won't accept 50 different packages for one program.

Hmm... who writes the 44 plugins left? :-)

> - put libx11, libncurses and others in "suggested" or "recommended", but
> this isn't clean.

No, it isn't. Definitely not.


You should ask debian guys again, how they prefer things handled in such 
a case.

Luk, are you listening? Your opinion?

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

Re: [Lcd4linux-devel] manpage for lcd4linux

[Michael R. <re...@eu...>]

Hi Jerry,

>>Unfortunately, we are in a process of reorganizing lcd4linux rather 
>>completely. Therefore writing a man page especially for the .conf is 
>>impossible or useless, because it will look very different for 0.9.12 
>>(we call it the "NextGeneration" internally.
> 
> Okay.  Ideally it would be nice to have the docs ready to go when 0.9.12
> is ready.  Can you give me a couple of weeks notice when you think it
> is close to being ready?

Of course, no problem.

>>Are you willing to become a "Documentation Manager" for lcd4linux? We 
>>would really need someone who takes care of that...

> If no one else wants to, sure, I'll do it.  I'll need some hand-holding
> in the form of "document this" and "that needs to be done".

I'd really appreciate it!

As a documentation manager, you should not only keep the man page up to 
date, but also some README's (maybe), and, most important, the web page, 
at least the "documentation" part of it.

There are plans to generate both the manpage and the web page out of 
something like "docbook". I don't know it, so I can't tell you if its a 
good or bad idea. But having a common source is a good thing in any case...

There are plans to do a rewrite of the webpage as a whole (avoid frames, 
use PHP).

I want all this stuff to be decided by the guy who's job is to manage 
it. So this would be you...


bye, Michael

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

Re: [Lcd4linux-devel] manpage for lcd4linux

[Michael R. <re...@eu...>]

Hi Xavier,

> Maybe it would be good to look at docbook and other stuff to have html
> and manpage in sync without duplicating the work.

Well, a 'documentation manager' should be in charge for deciding...

> BTW: I SCPed the lcd4linux site, maybe it would be a good thing to
> rewrite it a bit to avoid frames and friends. If you don't forbid me, I
> would greatly like to give a try and rewrite it in PHP.

This, too, should be planned with a DocMgr. If I'd be in charge for 
keeping the web page up to date, I would keep it as it is (it's quite 
clean handwritten HTML code), and I ton't talk PHP.

bye, Michael

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

Re: [Lcd4linux-devel] Re: lcd4linux 0.9.12

[Michael R. <re...@eu...>]

Hi Xavier,

> I quote you : 
> 
>>Here's my plan: prepare the parser, rewrite all plugins so that ne 
>>namespace is used, but DO NOT IMPLEMENT DYNAMIC LOADING!
>>Why? I want to release 0.9.12 as soon as possible...
> 
> I thinked 0.9.12 would be released soon. Moreover, there are big
> problems to solve for debian, so I prefer beginning this talk now.

I want to release it as soon as possible, and implement the dynamic 
loading stuff later. But 'as soon as possible' does not mean 'soon', but 
  'when all problems are solved'

>>(Xavier, 
>>you had this great planning sheet, is it up to date?)
> 
> Err... I dropped it to write one in plain text, but it's not up to date
>  (in fact, there are just displays). Do you want me to actualize it ?

Yes, that would be great. As my real-life job takes a lot of time at the 
moment, I can never remember what I've been working on yesterday :-)

>>I think we should release something like a "pre" or "beta" or whatever 
>>you want to call it. What do you think?
> 
> maybe lcd4linux-0.9.12-RC1, then lcd4linux-0.9.12.RC2, ... 
good ideas.

> BTW: it's a total rewrite of lcd4linux, I don't think a minor version
> reflects it ! Maybe 0.10.0 ? I don't vote for 1.0.0, as there are still
> bugs and ToDo.
Even better idea. So NextGeneration will be 0.10.0

bye, Michael

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

Re: [Lcd4linux-devel] manpage for lcd4linux

[Jerry S. <ye...@th...>]

Hi Michael,

> >Saw a posting on sourceforge that said you wanted a manpage
> >for lcd4linux.  Threw one together, it should be attached
> >to this email.
> 
> Looks great!

Thanks :)

> Unfortunately, we are in a process of reorganizing lcd4linux rather 
> completely. Therefore writing a man page especially for the .conf is 
> impossible or useless, because it will look very different for 0.9.12 
> (we call it the "NextGeneration" internally.

Okay.  Ideally it would be nice to have the docs ready to go when 0.9.12
is ready.  Can you give me a couple of weeks notice when you think it
is close to being ready?

> Are you willing to become a "Documentation Manager" for lcd4linux? We 
> would really need someone who takes care of that...

If no one else wants to, sure, I'll do it.  I'll need some hand-holding
in the form of "document this" and "that needs to be done".

Jerry

Re: [Lcd4linux-devel] lcd4linux4debian

[<Mar...@t-...>]

Am 23.02.2004 19:32:03 schrieb(en) Xavier VELLO:
> Hi all !
> 
> Now, let's talk about what to do for debian, he're the claim :
> A lot of lcd4linux plugins (and soon drivers) do (or will) rely on
> external libraries, system calls, ... how to handle it ?
> 
> - make one big lcd4linx package which depends on libx11, libncurses,
> ...
> and don't please to embedded systems.
> - make separate package for each plugin and driver, but I talked to
> debian devs and they won't accept 50 different packages for one
> program.
> - put libx11, libncurses and others in "suggested" or "recommended",
> but
> this isn't clean.
> 
> What about it ?
> 
> Bye !
> --
> Xavier VELLO <xav...@fr...>
>
Hi Xavier!

I am also a Debian user. I think it's a good idea to put similar  
Plugins together. e.g. all plugins who connects to the Internet, or all  
Multimedia-Plugins like XMMS in one Package.

Markus

[Lcd4linux-devel] lcd4linux4debian

[Xavier V. <xav...@fr...>]

Hi all !

Now, let's talk about what to do for debian, he're the claim :
A lot of lcd4linux plugins (and soon drivers) do (or will) rely on
external libraries, system calls, ... how to handle it ?

- make one big lcd4linx package which depends on libx11, libncurses, ...
and don't please to embedded systems.
- make separate package for each plugin and driver, but I talked to
debian devs and they won't accept 50 different packages for one program.
- put libx11, libncurses and others in "suggested" or "recommended", but
this isn't clean.

What about it ?

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

Re: [Lcd4linux-devel] Re: lcd4linux 0.9.12

[Xavier V. <xav...@fr...>]

Hi Michael, Luk, Sam and others !

> again, please use the list for such discussions!
Luk, Sam, are you really reading the ML ?

> > lcd4linux 0.9.12 will be released soon, when Michael will have finished
> > namespace rewrite.
> Huh? How did you know...

I quote you : 
> Here's my plan: prepare the parser, rewrite all plugins so that ne 
> namespace is used, but DO NOT IMPLEMENT DYNAMIC LOADING!
> Why? I want to release 0.9.12 as soon as possible...
I thinked 0.9.12 would be released soon. Moreover, there are big
problems to solve for debian, so I prefer beginning this talk now.

> I thinks it will take some time until NextGeneration is ready for 
> release. There are some Todo's which are not finished by now (Xavier, 
> you had this great planning sheet, is it up to date?)
Err... I dropped it to write one in plain text, but it's not up to date
 (in fact, there are just displays). Do you want me to actualize it ?

> I think we should release something like a "pre" or "beta" or whatever 
> you want to call it. What do you think?
maybe lcd4linux-0.9.12-RC1, then lcd4linux-0.9.12.RC2, ... 

BTW: it's a total rewrite of lcd4linux, I don't think a minor version
reflects it ! Maybe 0.10.0 ? I don't vote for 1.0.0, as there are still
bugs and ToDo.

> In the meantime we could take care of another point: Update all the 
> documentation on SourceForge. This will be lots of work....But I don't 
> want to "officially" release lcd4linux without proper documentation.
See my post "Re: [Lcd4linux-devel] manpage for lcd4linux" about docbook.

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

[Lcd4linux-devel] Re: Icon visible attribute (and little cleanup)

[Xavier V. <xav...@fr...>]

Hi all !

> > * You let documentation about old generation on the CVS : files
> > README.Drivers README.Rows and README.Tokens should be removed.
> Right. README.Rows and README.Tokens can be removed. The README.Drivers 
> should be rewritten to fit the NextGeneration scheme.
Okay.

> > * Maybe it would be cleaner to remove build files from CVS, which are
> > generated with ./bootstrap and are generally not commited by many other
> > projects, but this is not critical at all to let them. Here they are :
> 
> Oh, I don't think so. It may be cleaner to remove this files, but this 
> would also mean that everybody who wants to try the CVS version must 
> have all the autotools stuff installed.
> I had some discussions about this in the past, and I decided to keep 
> this files in CVS, too.
Do as you want, this was just a suggestion ;)

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

Re: [Lcd4linux-devel] manpage for lcd4linux

[Xavier V. <xav...@fr...>]

Hi Michael, hi Jerry, hi list !

> Are you willing to become a "Documentation Manager" for lcd4linux? We 
> would really need someone who takes care of that...
Maybe it would be good to look at docbook and other stuff to have html
and manpage in sync without duplicating the work.

BTW: I SCPed the lcd4linux site, maybe it would be a good thing to
rewrite it a bit to avoid frames and friends. If you don't forbid me, I
would greatly like to give a try and rewrite it in PHP.

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

[Lcd4linux-devel] Re: lcd4linux 0.9.12

[Michael R. <re...@eu...>]

Hi Xavier, Hi Sam and Luk, Hi List,

again, please use the list for such discussions!

Xavier VELLO wrote:

> lcd4linux 0.9.12 will be released soon, when Michael will have finished
> namespace rewrite.

Huh? How did you know...
I thinks it will take some time until NextGeneration is ready for 
release. There are some Todo's which are not finished by now (Xavier, 
you had this great planning sheet, is it up to date?)

Furter, I'm afraid the current code will contain very lots of bugs. 
Especially the Evaluator does lots of dynamic allocations, I'm really 
shure there are tons of memory leaks. I already added a "--with-dmalloc" 
option, we should do lots of debugging and testing here...

I think we should release something like a "pre" or "beta" or whatever 
you want to call it. What do you think?

In the meantime we could take care of another point: Update all the 
documentation on SourceForge. This will be lots of work....But I don't 
want to "officially" release lcd4linux without proper documentation.


bye, Michael

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

[Lcd4linux-devel] Re: Icon visible attribute (and little cleanup)

[Michael R. <re...@eu...>]

Hi Xavier,

as always, try to post to the list...

> * There's no example for visible attribute for icons in
> lcd4linux.conf.sample, so I send you one, it shows up when the cpu usage
> goes above 50% :
> 
> widget lightning {
>     class 'icon'
>     speed 100
>     visible cpu('busy', 500)-50
>     bitmap {
>         row1 '...***'
>         row2 '..***.'
>         row3 '.***..'
>         row4 '.****.'
>         row5 '..**..'
>         row6 '.**...'
>         row7 '**....'
>         row8 '*.....'
>     }
> }

Cool!

> * You let documentation about old generation on the CVS : files
> README.Drivers README.Rows and README.Tokens should be removed.

Right. README.Rows and README.Tokens can be removed. The README.Drivers 
should be rewritten to fit the NextGeneration scheme.

There are several files in CVS which will be removed. I'm removing them 
if they are either useless/obsolete with NextGeneration, or if they have 
been ported. So if you find an "old" file, this means it has not been 
ported, and you're welcome to do so :-)

> * Maybe it would be cleaner to remove build files from CVS, which are
> generated with ./bootstrap and are generally not commited by many other
> projects, but this is not critical at all to let them. Here they are :

Oh, I don't think so. It may be cleaner to remove this files, but this 
would also mean that everybody who wants to try the CVS version must 
have all the autotools stuff installed.

I had some discussions about this in the past, and I decided to keep 
this files in CVS, too.


bye, Michael

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

Re: [Lcd4linux-devel] manpage for lcd4linux

[Michael R. <re...@eu...>]

Hi Jerry,

> Saw a posting on sourceforge that said you wanted a manpage
> for lcd4linux.  Threw one together, it should be attached
> to this email.

Looks great!


> There should probably also be a page for lcd4linux.conf.
> It would help people trying to get lcd4linux up and running
> on their system and wouldn't be that hard since its already
> documented up on the website.
Of course, youz are right!

Unfortunately, we are in a process of reorganizing lcd4linux rather 
completely. Therefore writing a man page especially for the .conf is 
impossible or useless, because it will look very different for 0.9.12 
(we call it the "NextGeneration" internally.

The lcd4linux.1 will differ a bit, too, but not too much. The docs on 
SourceForge isn't up to date, too.

Are you willing to become a "Documentation Manager" for lcd4linux? We 
would really need someone who takes care of that...


bye, Michael

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

[Lcd4linux-devel] manpage for lcd4linux

[Jerry S. <ye...@th...>]

Hello,

Saw a posting on sourceforge that said you wanted a manpage
for lcd4linux.  Threw one together, it should be attached
to this email.  You can have a look at it with:

groff -man -Tascii lcd4linux.1 | more

There should probably also be a page for lcd4linux.conf.
It would help people trying to get lcd4linux up and running
on their system and wouldn't be that hard since its already
documented up on the website.

Let me know what you think..

Jerry Seutter