[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: [Panel-devel] Design of Sensor and meters
From: Vinay Khaitan <vkhaitan () gmail ! com>
Date: 2005-09-14 3:36:16
Message-ID: 56c534770509132036684dd264 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
>
> if you need a key->value mapping, that's what a Map is for. e.g.
> QMap<QString,
> QVariant>
hmm, yes! QMap<QString.QVariant> looks sufficient. Actually I wanted that we
should be able to use the format like network.interface.eth0 . So in
QMap<QString,QVariant>, if a key needs more than one dot, the QVariant
itself can be QMap<QString,QVariant>. So actually, we have the option of
using %alpha.beta.gamma.delta .
So we can have single return value. Nice! it is more efficient.
and again i really don't like the concept of meters constantly making calls
> to
> sensors to grab bits of data. just send the current state of the sensor in
> a
> signal to a slot in the sensor (it's cheap if we pass it by const
> reference)
> and it's done.
> MULTIMETER meter=bar number=2 orientation=horizontal, separationX=50
> > separationY=50 value.1=cpu0.system bar.x=0 bar.y=etc
> > value.2=cpu1.systemSENSOR=cpusensor
>
> oi vey. we need to have a discussion about what plasmoids are going to
> look
> like.
>
> to boil it down to essentials: are they going to be scripts, or are they
> going
> to be "theme files". the latter will certainly not encompasse the needs of
> plasma applets in the least, though theme files could be a specialized
> kind
> of plasmoid (and loaded via a theme container.. all transparent to the
> user,
> so no concerns there).
>
so if we say that plasmoids will be actual code at the most base level, with
> a
> simplistic theme engine added on top of that, then we ought to start
> phrasing
> our use cases in those terms.
>
> > The separation stuff would set the separation of multiple meters.
> > orientation is separation orientation.
>
> how about:
>
> MULTIMETER meter
> meter.setType bar
> meter.setNumberOfMeters 2
> meter.setOrientation horizontal
> meter.setMeterKey 1 cpu0.system
> meter.setMeterKey 2 cpu1.system
> SENSOR sensor = cpusensor
> meter.connectTo sensor
>
> looks almost identical, but is done more like a real script.
The format of theme file was not my intention in first mail, but inteface of
sensors and meters only.
But, I must say, I like the idea of script type theme file much more that
current theme file structure. It looks a lot readable for any programmer
that the current theme file.
what does concern
> me is the layout / geometry stuff:
>
meter.setSpacing 50
> bar.x=0 bar.y=etc
Well, using the layout for geometry also looks very nice idea. I am for it.
this stuff tends to get really messy if you work with translated strings,
> themed widgets (e.g. not just pixmaps) and what not.
I cant forsee the mess in those two things.
So after discussion with pedro,ryan and you, it looks the structure of
meters and sensor seems agreed by all of us. is it? Should we go for it?
And pedro, the idea of Q_PROPERTY was introduced for things like MOUNTPOINT
which can sometimes arise in specific types of sensors.
Vinay Khaitan
[Attachment #5 (text/html)]
<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, \
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">if you need a key->value \
mapping, that's what a Map is for. e.g. QMap<QString,<br> \
QVariant></blockquote><div><br> hmm, yes! QMap<QString.QVariant> looks \
sufficient. Actually I wanted that we should be able to use the format like
network.interface.eth0 . So in QMap<QString,QVariant>, if a key
needs more than one dot, the QVariant itself can be
QMap<QString,QVariant>. So actually, we have the option of using
%alpha.beta.gamma.delta .<br>
<br>
So we can have single return value. Nice! it is more efficient.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid \
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">and again i really \
don't like the concept of meters constantly making calls to<br> sensors to grab bits \
of data. just send the current state of the sensor in a<br>signal to a slot in the \
sensor (it's cheap if we pass it by const reference)<br>and it's \
done.</blockquote><div><br> <br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid \
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> MULTIMETER \
meter=bar number=2 orientation=horizontal, separationX=50<br>> separationY=50 \
value.1=cpu0.system bar.x=0 bar.y=etc<br>> \
value.2=cpu1.systemSENSOR=cpusensor<br><br>oi vey. we need to have a discussion about \
what plasmoids are going to look<br>like.<br><br>to boil it down to essentials: are \
they going to be scripts, or are they going <br>to be "theme files". the \
latter will certainly not encompasse the needs of<br>plasma applets in the least, \
though theme files could be a specialized kind<br>of plasmoid (and loaded via a theme \
container.. all transparent to the user, <br>so no concerns there). <br>
</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">so if we say that plasmoids \
will be actual code at the most base level, with a <br>simplistic theme engine added \
on top of that, then we ought to start phrasing<br>our use cases in those \
terms.<br><br>> The separation stuff would set the separation of multiple \
meters.<br>> orientation is separation orientation. <br><br>how \
about:<br><br>MULTIMETER meter<br>meter.setType bar<br>meter.setNumberOfMeters \
2<br>meter.setOrientation horizontal<br>meter.setMeterKey 1 \
cpu0.system<br>meter.setMeterKey 2 cpu1.system<br>SENSOR sensor = cpusensor \
<br>meter.connectTo sensor<br><br>looks almost identical, but is done more like a \
real script.</blockquote><div>The format of theme file was not my intention in first \
mail, but inteface of sensors and meters only. <br> But, I must say, I like the idea \
of script type theme file much more that current theme file structure. It looks a lot \
readable for any programmer that the current theme file.<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, \
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> what does concern<br>me is the \
layout / geometry stuff: <br> </blockquote><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; \
padding-left: 1ex;">meter.setSpacing 50<br>bar.x=0 bar.y=etc</blockquote><div>Well, \
using the layout for geometry also looks very nice idea. I am for it. <br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid \
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">this stuff tends \
to get really messy if you work with translated strings,<br>themed widgets ( e.g. not \
just pixmaps) and what not.</blockquote><div><br> I cant forsee the mess in those two \
things.<br> </div><br>
</div>So after discussion with pedro,ryan and you, it looks the
structure of meters and sensor seems agreed by all of us. is it? Should
we go for it?<br>
<br>
And pedro, the idea of Q_PROPERTY was introduced for things like
MOUNTPOINT which can sometimes arise in specific types of sensors.<br>
<br>
Vinay Khaitan<br>
_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic