From zjhnzyf at 163.com  Sat Apr  9 17:22:52 2011
From: zjhnzyf at 163.com (zjhnzyf)
Date: Sat, 9 Apr 2011 23:22:52 +0800 (CST)
Subject: [luci] hello everyone
Message-ID: <e346c7.7b16.12f3adbc695.Coremail.zjhnzyf@163.com>

hello everyone test mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.subsignal.org/pipermail/luci/attachments/20110409/41245a47/attachment.htm 

From hakais at gmail.com  Sat Apr  9 17:40:51 2011
From: hakais at gmail.com (Pau)
Date: Sat, 9 Apr 2011 17:40:51 +0200
Subject: [luci] hello everyone
In-Reply-To: <e346c7.7b16.12f3adbc695.Coremail.zjhnzyf@163.com>
References: <e346c7.7b16.12f3adbc695.Coremail.zjhnzyf@163.com>
Message-ID: <BANLkTimc3RHMC0MjaOiO-agbKCzuOvcumA@mail.gmail.com>

hi

2011/4/9 zjhnzyf <zjhnzyf at 163.com>

> hello everyone test mail
>
>
>
> _______________________________________________
> luci mailing list
> luci at lists.subsignal.org
> https://lists.subsignal.org/mailman/listinfo/luci
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.subsignal.org/pipermail/luci/attachments/20110409/f83dd7e9/attachment.htm 

From hakais at gmail.com  Sat Apr  9 18:11:51 2011
From: hakais at gmail.com (Pau)
Date: Sat, 9 Apr 2011 18:11:51 +0200
Subject: [luci] LuCI view controller, and bmx6 luci moule
Message-ID: <BANLkTikgg5TsR7SvmwmuymER69mP3tMV+A@mail.gmail.com>

Hi people.
This is my first mail to this mailing list. I'm Pau from Barcelona (
guifi.net), last week I was in sublab, maybe some of you can remind me.
Well,we are developing an OpenWrt based firmware for quick mesh deployments.
The main freature is going to be the "out of the box" system. Where the user
does not need knowlatges about networking.

I'm working with the LuCI interface, trying to adapt it to our requirements.
We need one thing that seems not suporrted by LuCI system. We need control
over the existing modules and where are them showed in the web interface.
For instance, the OLSR module in placed here:
luci -> admin -> status -> olsr

And we need to put it here:
luci -> qmp -> olsr

The only way I found is editing the olsr.lua code, and modify the entry()
function. But with a system upgrade or something like this the changes will
be lost.
Also we need to control if a installed module must be shown or not.

However, I am also developing a bmx6 luci module (I know jow is also working
on it, maybe we should work togheter). And for this  module I have
implemented the following freature:

/etc/config/bmx6
......
config bmx6 luci
    option ignore 0
    option level1 admin
    option level2 status
    option level3 bmx6
    option json http://127.0.0.1:8086/
......

You can find the bmx6.lua code here: http://pastebin.com/cYy2bYXN

From bogus@does.not.exist.com  Mon Apr  4 21:35:10 2011
From: bogus@does.not.exist.com ()
Date: Mon, 04 Apr 2011 19:35:10 -0000
Subject: No subject
Message-ID: <mailman.0.1302365545.2549.luci@lists.subsignal.org>

with uci interface.
Then, the position in the luci web site is allways dinamic, you can change
the bmx6.luci options from uci to disable/move it.

My first concert was to thing about "every index call is asking for UCI
options, and then accessing to the flash memory". But as far I know, there
is an index cache, then this code is only called one time.

What do you think about this freature? Is extensible to other luci modules?

Thanks for your incredible work guys!!

/p4u

--0016e64fcc5ae975a504a07e9a4d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi people.<br>This is my first mail to this mailing list. I&#39;m Pau from =
Barcelona (<a href=3D"http://guifi.net">guifi.net</a>), last week I was in =
sublab, maybe some of you can remind me.<br>Well,we are developing an OpenW=
rt based firmware for quick mesh deployments. The main freature is going to=
 be the &quot;out of the box&quot; system. Where the user does not need kno=
wlatges about networking.<br>

<br>I&#39;m working with the LuCI interface, trying to adapt it to our requ=
irements. We need one thing that seems not suporrted by LuCI system. We nee=
d control over the existing modules and where are them showed in the web in=
terface.<br>

For instance, the OLSR module in placed here:<br>luci -&gt; admin -&gt; sta=
tus -&gt; olsr<br><br>And we need to put it here:<br>luci -&gt; qmp -&gt; o=
lsr<br><br>The only way I found is editing the olsr.lua code, and modify th=
e entry() function. But with a system upgrade or something like this the ch=
anges will be lost.<br>

Also we need to control if a installed module must be shown or not.<br><br>=
However, I am also developing a bmx6 luci module (I know jow is also workin=
g on it, maybe we should work togheter). And for this=A0 module I have impl=
emented the following freature:<br>

<br>/etc/config/bmx6<br>......<br>config bmx6 luci<br>=A0=A0=A0 option igno=
re 0<br>=A0=A0=A0 option level1 admin<br>=A0=A0=A0 option level2 status<br>=
=A0=A0=A0 option level3 bmx6<br>=A0=A0=A0 option json <a href=3D"http://127=
.0.0.1:8086/">http://127.0.0.1:8086/</a><br>

...... <br><br>You can find the bmx6.lua code here: <a href=3D"http://paste=
bin.com/cYy2bYXN">http://pastebin.com/cYy2bYXN</a><br>From line 6 to 26, yo=
u can see the code that read the parameters from bmx6 with uci interface. <=
br>

Then, the position in the luci web site is allways dinamic, you can change =
the bmx6.luci options from uci to disable/move it.<br><br>My first concert =
was to thing about &quot;every index call is asking for UCI options, and th=
en accessing to the flash memory&quot;. But as far I know, there is an inde=
x cache, then this code is only called one time.<br>

<br>What do you think about this freature? Is extensible to other luci modu=
les?<br><br>Thanks for your incredible work guys!!<br><br>/p4u<br>

--0016e64fcc5ae975a504a07e9a4d--

From freifunk at somakoma.de  Sat Apr  9 18:48:46 2011
From: freifunk at somakoma.de (Manuel Munz)
Date: Sat, 09 Apr 2011 18:48:46 +0200
Subject: [luci] LuCI view controller, and bmx6 luci moule
In-Reply-To: <BANLkTikgg5TsR7SvmwmuymER69mP3tMV+A@mail.gmail.com>
References: <BANLkTikgg5TsR7SvmwmuymER69mP3tMV+A@mail.gmail.com>
Message-ID: <4DA08DEE.2080802@somakoma.de>

Hi Pau

On 09.04.2011 18:11, Pau wrote:
> Hi people.
> This is my first mail to this mailing list. I'm Pau from Barcelona (
> guifi.net), last week I was in sublab, maybe some of you can remind me.
> Well,we are developing an OpenWrt based firmware for quick mesh deployments.
> The main freature is going to be the "out of the box" system. Where the user
> does not need knowlatges about networking.

this is a thing many communities need/want and therefore it may be a
good idea to join forces. I'm currently on some kind of mission, because
i think it may be a good thing to work together on one firmware to avoid
work being done twice (or more often). If you like contact me via jabber
(soma at jabber.ccc.de) or write a private mail, i'd like to hear more
about your plans.

> 
> I'm working with the LuCI interface, trying to adapt it to our requirements.
> We need one thing that seems not suporrted by LuCI system. We need control
> over the existing modules and where are them showed in the web interface.
> For instance, the OLSR module in placed here:
> luci -> admin -> status -> olsr
> 
> And we need to put it here:
> luci -> qmp -> olsr

Just out of curiosity: what does qmp mean and why do you need olsr to be
shown there?

> 
> The only way I found is editing the olsr.lua code, and modify the entry()
> function. But with a system upgrade or something like this the changes will
> be lost.
> Also we need to control if a installed module must be shown or not.
> 
> However, I am also developing a bmx6 luci module (I know jow is also working
> on it, maybe we should work togheter). And for this  module I have
> implemented the following freature:
> 
> /etc/config/bmx6
> ......
> config bmx6 luci
>     option ignore 0
>     option level1 admin
>     option level2 status
>     option level3 bmx6
>     option json http://127.0.0.1:8086/
> ......
> 
> You can find the bmx6.lua code here: http://pastebin.com/cYy2bYXN
> From line 6 to 26, you can see the code that read the parameters from bmx6
> with uci interface.
> Then, the position in the luci web site is allways dinamic, you can change
> the bmx6.luci options from uci to disable/move it.

That feels a bit too static for me, i.e. you assume there are 3
levels.If a feature to place modules at custom places should be
implemented i think this should be more flexible. But I'm not so sure
this is a good idea at all because it can make it hard to write
documentation or help users if everything can be everywhere in the menu.

[...]

Regards, soma

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://lists.subsignal.org/pipermail/luci/attachments/20110409/1719f55d/attachment.pgp 

From hakais at gmail.com  Sat Apr  9 22:07:04 2011
From: hakais at gmail.com (Pau)
Date: Sat, 9 Apr 2011 22:07:04 +0200
Subject: [luci] LuCI view controller, and bmx6 luci moule
In-Reply-To: <4DA08DEE.2080802@somakoma.de>
References: <BANLkTikgg5TsR7SvmwmuymER69mP3tMV+A@mail.gmail.com>
	<4DA08DEE.2080802@somakoma.de>
Message-ID: <BANLkTimtiaiFuGTZ3n00_UzpThD2n6o4pQ@mail.gmail.com>

>
> this is a thing many communities need/want and therefore it may be a
> good idea to join forces. I'm currently on some kind of mission, because
> i think it may be a good thing to work together on one firmware to avoid
> work being done twice (or more often). If you like contact me via jabber
> (soma at jabber.ccc.de) or write a private mail, i'd like to hear more
> about your plans.
>

You are right, maybe we can work together. I'll explain you more details
about our project by private.

Just out of curiosity: what does qmp mean and why do you need olsr to be
> shown there?
>
qmp = Quick Mesh Project

Our idea is to have a very simple web interface, with only one or two tabs.
The main tab will be "qmp", where you are be able to define the main options
of the system.

We are using three protocols: bmx6 (main), olsr6 and babel at the same time.
But the OLSR example was only an example.
But for instance, the Interface and Wireless section from
luci-mod-admin-core is usefull for us. But not the rest.
Then, we will have something like this:

qmp -> interfaces
qmp -> status (bmx6 & olsr6)
qmp -> wireless links

We are "redesigning" LuCi interface to adapt it to our requirements, this is
the idea.

That feels a bit too static for me, i.e. you assume there are 3
> levels.If a feature to place modules at custom places should be
> implemented i think this should be more flexible. But I'm not so sure
> this is a good idea at all because it can make it hard to write
> documentation or help users if everything can be everywhere in the menu.
>

You are right also.
Meybe the best way to do this is with only one option:

option 'section' 'admin status bmx6'

But I don't know how to implement it.  Because to define a section I have to
do:

page = node("admin","status", "bmx6")
or
entry( {"admin", "services", "olsrd", "plugins"})

Then, I cannot iterate between the section elements because I cannot add the
elements one-to-one.

Do you know if something like this is possible?:

page = node.add("admin")
page = node.add("status")
page = node.add("bmx6")

Thank you!!

/p4u

2011/4/9 Manuel Munz <freifunk at somakoma.de>

> Hi Pau
>
> On 09.04.2011 18:11, Pau wrote:
> > Hi people.
> > This is my first mail to this mailing list. I'm Pau from Barcelona (
> > guifi.net), last week I was in sublab, maybe some of you can remind me.
> > Well,we are developing an OpenWrt based firmware for quick mesh
> deployments.
> > The main freature is going to be the "out of the box" system. Where the
> user
> > does not need knowlatges about networking.
>
> this is a thing many communities need/want and therefore it may be a
> good idea to join forces. I'm currently on some kind of mission, because
> i think it may be a good thing to work together on one firmware to avoid
> work being done twice (or more often). If you like contact me via jabber
> (soma at jabber.ccc.de) or write a private mail, i'd like to hear more
> about your plans.
>
> >
> > I'm working with the LuCI interface, trying to adapt it to our
> requirements.
> > We need one thing that seems not suporrted by LuCI system. We need
> control
> > over the existing modules and where are them showed in the web interface.
> > For instance, the OLSR module in placed here:
> > luci -> admin -> status -> olsr
> >
> > And we need to put it here:
> > luci -> qmp -> olsr
>
> Just out of curiosity: what does qmp mean and why do you need olsr to be
> shown there?
>
> >
> > The only way I found is editing the olsr.lua code, and modify the entry()
> > function. But with a system upgrade or something like this the changes
> will
> > be lost.
> > Also we need to control if a installed module must be shown or not.
> >
> > However, I am also developing a bmx6 luci module (I know jow is also
> working
> > on it, maybe we should work togheter). And for this  module I have
> > implemented the following freature:
> >
> > /etc/config/bmx6
> > ......
> > config bmx6 luci
> >     option ignore 0
> >     option level1 admin
> >     option level2 status
> >     option level3 bmx6
> >     option json http://127.0.0.1:8086/
> > ......
> >
> > You can find the bmx6.lua code here: http://pastebin.com/cYy2bYXN
> > From line 6 to 26, you can see the code that read the parameters from
> bmx6
> > with uci interface.
> > Then, the position in the luci web site is allways dinamic, you can
> change
> > the bmx6.luci options from uci to disable/move it.
>
> That feels a bit too static for me, i.e. you assume there are 3
> levels.If a feature to place modules at custom places should be
> implemented i think this should be more flexible. But I'm not so sure
> this is a good idea at all because it can make it hard to write
> documentation or help users if everything can be everywhere in the menu.
>
> [...]
>
> Regards, soma
>
>
> _______________________________________________
> luci mailing list
> luci at lists.subsignal.org
> https://lists.subsignal.org/mailman/listinfo/luci
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.subsignal.org/pipermail/luci/attachments/20110409/9d1667a5/attachment-0001.htm 

From bart.vandermeerssche at flukso.net  Fri Apr 22 10:10:13 2011
From: bart.vandermeerssche at flukso.net (Bart Van Der Meerssche)
Date: Fri, 22 Apr 2011 10:10:13 +0200
Subject: [luci] cbi .default option
Message-ID: <4DB137E5.9040804@flukso.net>

Hi list,

I'm coding a new cbi-modeled web page with LuCI 0.9. I would expect the 
below code to behave as follows:
1/ only show the voltage form field when the 'enable' checkbox is flagged
2/ pre-fill the voltage field with the value 230 when the field is displayed

voltage = s:option(Value, "voltage", translate("voltage"))
voltage.default = "230"
voltage:depends("enable", "1")

However, it seems only when using a form field of type ListValue that 
the .default setting has any effect. When using the Value type, nothing 
is pre-filled. The .default is listed as a Value option in the CBI 
documentation: http://luci.subsignal.org/trac/wiki/Documentation/CBI.

Is this the intended behaviour? Am I doing something wrong here?


Best regards,
Bart Van Der Meerssche.