Applet::init()

[David Baron]

Apparently, plasma will wait until all of these are done before displaying 
anything (correct me if I am wrong). So any applet that checks 
unmounted/unmountable media, unconnected network connections, loads large data 
sets, etc., will make plasma wait and wait unless ...

Do ALL of it in background threads.
Just start, set busy if need be, and exit init().
When threads needed for applet functionality are done, reset busy and let it 
play.

Let's check our init code :-)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Ayatana notifications for Plasma

[Aurélien Gâteau]

Aaron J. Seigo wrote:
> On September 29, 2009, Aurélien Gâteau wrote:
 Keep in mind that the
 binary is started on demand, so it does not take any memory if you are
 not using it (assuming it would automatically stop itself after a
 while).
>>> Same goes for applets, dataengines...
>> Can an applet unload itself from memory? What I meant with "stop itself
>> after a while", was the notify-osd executable calling exit(). I believe
>> your desktop would be a bit too clean if an applet called exit() :).
> 
> the overhead of a running applet should be negligable unless it's doing 
> something rather wrong. 
> 
> so while you can certainly have an applet remove itself you'd also need a way 
> to re-create it, position it properly, make sure any user adjustments 
> previously made to it remain, etc. then there'd be the overhead of any re-
> layouts this triggers in the containment, etc. for the memory savings that 
> would result, this probably isn't worth it.

I agree. My point was that the perceived bloat of having a separate 
executable running in the background could be compensated by having said 
executable stop itself after some time, since DBus would restart it when 
needed.

>> True, but in both cases it would have needed a patch.
>> Offtopic: it's too bad Plasma does not have a DBus call to reload its
>> config. 
> 
> you really don't want to do that; this implies something other than plasma-
> desktop has touched the config file(s) but plasma-desktop may have written 
> over it since then. due to limitations in kconfig this whole "change the 
> config file on disk behind the app's back" is a non-starter.

OK.

>> Could be handy when going from one distro release to another
>> (/me thinks about the switch between knetworkmanager the executable and
>> knetworkmanager the plasmoid). I'll try to implement this if I find time.
> 
> this is why i wrote the QScript based system for controlling plasma-desktop. 
> it supports update scripts. there's a file in workspace/plasma/design/ about 
> it and i've blogged about it as well.

Oh! I'll forward this to Jonathan. I was thinking about adding a way for 
kconf_update to run commands before and after updates (so that a script 
could stop plasma-desktop, edit its configuration and restart it), but 
this sounds better.

Aurelien
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: taskmanager library: Manual Sorting Fix

[Christian Mollekopf]

On Wednesday 30 September 2009 01:35:41 j...@progsoc.org wrote:
> > On 2009-09-04 20:16:52, Aaron Seigo wrote:
> > > this results in a "leak" in that every window ever created will have an
> > > item that stays forever, no? shouldn't it only keep track of winIds
> > > that still exist, and do so in the manual grouping strategy?
> >
> > Christian Mollekopf wrote:
> > Yes this would result in a "leak" (as long the groupmanager instance
> > exists). I just noticed that also manual grouping is broken since it also
> > relies on the pointers to remain.
> >
> > I will work on a new patch where manual grouping and sorting keep
> > track of the windows/groups by winIds.
> >
> > Aaron Seigo wrote:
> > any progress on this?
> >
> > Christian Mollekopf wrote:
> > yes, but since i'm rather busy atm. it takes some more time.
> > I'll try to finish it until next week.
> >
> > Cheers
> 
> Out of curiosity, will this change affect how new applications are
>  displayed/handled in the taskbar?  Ideally they'd just appear (and stay
>  unless moved) to the right of any extant tasks.  If not, can I ask a big
>  favour ... ? ;)

This will not change the behaviour of the taskbar, new tasks are appended on 
the right if no or manual sorting is used, otherwise according to the sorting 
strategy.

Regards
> 
> 
> - jedd
> 
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1526/#review2247
> ---
> 
> On 2009-09-28 20:26:09, Christian Mollekopf wrote:
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > http://reviewboard.kde.org/r/1526/
> > ---
> >
> > (Updated 2009-09-28 20:26:09)
> >
> >
> > Review request for Plasma, Aaron Seigo and Marco Martin.
> >
> >
> > Summary
> > ---
> >
> > this fixes the manual sorting strategy, which is broken atm if the
> > desktop is changed.
> >
> > Since the manual sorting strategy relies on AbstractGroupableItem pointer
> > not to change, we cannot remove it from the bookkeeping in case it
> > returns (after a desktop change for instance). I don't know if this is
> > acceptable because this results in the item never being removed from the
> > itemList until the groupmanager instance is deleted (lifetime of the
> > applet which created the instance).
> >
> > Another option would be to identify tasks and groups by WId, which is a
> > bit more complicated, but if you think it would be better/cleaner, i
> > could supply a patch.
> >
> >
> > This addresses bug 200255.
> > https://bugs.kde.org/show_bug.cgi?id=200255
> >
> >
> > Diffs
> > -
> >
> >   /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1018615
> >
> > Diff: http://reviewboard.kde.org/r/1526/diff
> >
> >
> > Testing
> > ---
> >
> > Tried it, works.
> >
> >
> > Thanks,
> >
> > Christian
> 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Qalculate plasmoid in kdeplasma-addons

[Matteo Agostinelli]

On Friday 25 September 2009 11:09:44 Matteo Agostinelli wrote:
> On Friday 25 September 2009 11:04:25 John Tapsell wrote:
> > 2009/9/25 Matteo Agostinelli :
> > > Hi all,
> > >
> > > the qalculate plasmoid (advanced calculator that uses libqalculate) has
> > > spent quite some time on kdereview and has also been relatively popular
> > > in kde- look.org. I think the applet is quite mature now and has been
> > > tested sufficiently. What do you think about moving it to
> > > kdeplasma-addons? Is it ok?
> >
> > Don't suppose you could pick a better name? :-)
> >
> > If it's supposed to replace the current calculator, then the user
> > visible name should just be "Calculator" or "KDE Calculator", imho.
> >
> > John
> 
> Sure. I chose this name for two reasons basically:
> - to clearly distinguish it from the original calculator plasmoid
> - I mantained name and artwork of the original project
> (http://qalculate.sourceforge.net)
> 
> But certainly both name and icon could be changed
> 
> Matteo
> 
Also, I would like to add that this is not meant to be a replacement of the 
existing calculator but an optional "enhanced" calculator, since it requires 
an additional external dependency (libqalculate). So IMO the current choice of 
branding (name and icon) could be acceptable. If there are no objections, I 
would like to move it to kdeplasma-addons next weekend. I am willing to 
mantain it in the future.

Regards,
Matteo
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

No signals from Plasma.ComboBox?

[Thomas Olsen]

Hi 

Firstly, it has been *AGES* since I've coded Qt/KDE and this is my first 
endeavor into Plasma so I'll probably be sending a lot of newbie questions, 
but I'll promise that I'll do my best to google for the answers first.

I'm trying to connect the activated or textChanged from a Plasma.ComboBox 
signal to a Python function but nothing seems to happen. This is  what I've 
tried inside my init() function (most is snipped out):

self.currency_to = Plasma.ComboBox(self.applet)

QObject.connect(self.currency_from,SIGNAL("activated(PyQt_PyObject)"),self.do_convert_from)

def do_convert_from(currency_from):
print "Convert from:" + currency_from

But when I select an item in the combo nothing happens; no errors or anything.

I've also tried:


QObject.connect(self.currency_from,SIGNAL("activated(string)"),self.do_convert_from)

but to no avail.

If anyone can point me to a Python Plasmoid I can study I would appreciate it.

-- 
Best Regards / Med venlig hilsen

  Thomas Olsen

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: No signals from Plasma.ComboBox?

[Marco Martin]

On Wednesday 30 September 2009, Thomas Olsen wrote:
> Hi
>
> Firstly, it has been *AGES* since I've coded Qt/KDE and this is my first
> endeavor into Plasma so I'll probably be sending a lot of newbie questions,
> but I'll promise that I'll do my best to google for the answers first.
>
> I'm trying to connect the activated or textChanged from a Plasma.ComboBox
> signal to a Python function but nothing seems to happen. This is  what I've
> tried inside my init() function (most is snipped out):
>
> self.currency_to = Plasma.ComboBox(self.applet)
>
> QObject.connect(self.currency_from,SIGNAL("activated(PyQt_PyObject)"),self.
>do_convert_from)
>
> def do_convert_from(currency_from):
> print "Convert from:" + currency_from
>
> But when I select an item in the combo nothing happens; no errors or
> anything.
>
> I've also tried:
>
>
> QObject.connect(self.currency_from,SIGNAL("activated(string)"),self.do_conv
>ert_from)
>
> but to no avail.
>
> If anyone can point me to a Python Plasmoid I can study I would appreciate
> it.
looking in the combobox code seems the signals are correctly wired up.
try doing the same thing by accessing the nativeWidget() signals, but it 
should make no difference

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: No signals from Plasma.ComboBox?

[Thomas Olsen]

On 30/9-2009 14:43 Marco Martin  wrote:
> On Wednesday 30 September 2009, Thomas Olsen wrote:
> > I'm trying to connect the activated or textChanged from a Plasma.ComboBox
> > signal to a Python function but nothing seems to happen. This is  what
> > I've tried inside my init() function (most is snipped out):
> >
> > self.currency_to = Plasma.ComboBox(self.applet)
> >
> > QObject.connect(self.currency_from,SIGNAL("activated(PyQt_PyObject)"),sel
> >f. do_convert_from)
> >
> > def do_convert_from(currency_from):
> > print "Convert from:" + currency_from
> >
> > But when I select an item in the combo nothing happens; no errors or
> > anything.
> >
> > I've also tried:
> >
> >
> > QObject.connect(self.currency_from,SIGNAL("activated(string)"),self.do_co
> >nv ert_from)
> >
> > but to no avail.
> >
> > If anyone can point me to a Python Plasmoid I can study I would
> > appreciate it.
> 
> looking in the combobox code seems the signals are correctly wired up.
> try doing the same thing by accessing the nativeWidget() signals, but it
> should make no difference
> 

I tried:


QObject.connect(self.currency_from.nativeWidget(),SIGNAL("activated(PyQt_PyObject)"),self.do_convert_from)

That was what you meant? Anyways it didn't make any difference but thanks for 
the suggestion.

-- 
Best Regards / Med venlig hilsen

  Thomas Olsen

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Remote widgets, the next steps

[Rob Scheepmaker]

On Tuesday 29 September 2009 18:04:07 Fabrizio Montesi wrote:
> On Tue, Sep 29, 2009 at 4:30 PM, Rob Scheepmaker <
> 
> r.scheepma...@student.utwente.nl> wrote:
> > I never really considered the case of implementing a native
> > Plasma::Services
> > in jolie script since that could get a bit complicated anyway,
> > considering the
> > access control/message signing, plus additional overhead like the fact
> > that we
> > should send over valid kconfigxml describing the parameters.
> 
> Message signing and access control shouldn't be too hard to code: I'd like
> to write some sort of standard Jolie library for handling Plasma services
> and to distribute it with Jolie. Could you provide the workflow specs?
> (describing them here is fine)

Cool, I'll append some more information to the remote widgets design doc when 
I've got the time.

> We had some work on generating kconfigxml automatically from Jolie
>  interface files, see
> http://jolie.svn.sourceforge.net/viewvc/jolie/trunk/tools/jolie2plasma/
> Only problems are w.r.t. certain data types (which I see you already know
>  by your explanation in the following).

Nice, thanks for the pointer... I'll give it a spin soon.

> Also, publishing
> 
> > a Plasma::Service using a different technology (like as a SOAP service)
> > would
> > be tricky since the access/control and message singing would make this
> > SOAP service quite complicated to use
> 
> Well, a lot of SOAP services in the industry there have very complicated
> specifications on how to access them. I don't think anybody would kick us
> for some security parameters that need to be added to messages. :-)

Ok, it'll require me to change the implementation to no longer stream 
Credentials to a bytearray, but append the different fields as child nodes in 
the message to be somewhat usable, but that's a relatively minor change. And I 
suppose we could always write some libs for php/ruby/whatnot to make accessing 
these plasma soap services easier.

> > I mostly considered the case of accessing something like a SOAP service
> > from
> > plasma as something seperate, where we could leverage jolie, but need to
> > use a
> > different approach. In that case we would want some wsdl to jolie
> > converter for example, since it would be a pain if a developer that just
> > wants to use a
> > web service needs to do that by hand. And a wsdl to configxml convertor,
> > since
> > Plasma::Service need to provide valid configxml. And a seperate Service
> > implementation that doesn't do any access control stuff and just calls
> > operations on the service, but this would be a relatively small and
> > trivial class to make. I could at some point add a function to access
> > manager to access any non native plasma service through a
> > Plasma::Service. If/when (?) there are converters to help us with the
> > wsdl, it should be very easy ... both
> > to implement, and to use.
> 
> This is true, but if we provide a way to use the loadEmbeddedJolieService
>  in MetaService so to load custom Jolie scripts and see them as a
> Plasma::Service I can at least access SOAP services by making a Jolie
> script. In a lot of cases making a Jolie script for accessing a SOAP
>  service is easy, and there are hard cases in which I would like to use a
>  Jolie script even if I had all the automatic converters because there
>  could be a necessity for some additional orchestration (security
>  protocols, handshaking etc...) which Plasma doesn't support.

true.

> 
> For the future tools, we would just need a WSDL2Jolie converter, since we
> already have Jolie2Plasma (which converts a Jolie interface to a kconfigxml
> service descriptor).

That would be lovely... such a converter could make a lot of common cases 
extremely easy to use. Think of something like:

Plasma::Service *service = 
  AccessManager::self()-
>accessService("http://soap.amazon.com/schemas2/AmazonWebServices.wsdl";);

and then just being able to use service just like any Plasma::Service.

> 
> > The problem of streaming the parameters is not entirely solvable. The
> > parameters passed to any Plasma::Service are a QVariantMap. I could
> > obviously
> > put every element of the map as seperate child node, but they're still
> > QVariants, and those will need to be serialized/deserialized.
> > I could use the 3 native sodep types: string integer and double directly,
> > but
> > this doesn't solve the issue for all the types out there, just for some
> > of the
> > most common ones.
> 
> I suggest we go this way:
> - if a parameter can be cast to a sodep data type, convert it;
> - otherwise, serialize it.
> 
> Nevertheless, maintain the separate child node structure. This way we
> already have a mostly working implementation (I imagine most parameters in
> Plasma are integers, strings, doubles and booleans?) and I can start adding
> sodep data types appropriately as we see necessary.

Ok, sounds sensible.

> What I'd like to get working first is to, at least, be able to 

Re: No signals from Plasma.ComboBox?

[Thomas Olsen]

On 30/9-2009 14:43 Marco Martin  wrote:
> On Wednesday 30 September 2009, Thomas Olsen wrote:
> > def do_convert_from(currency_from):
> > print "Convert from:" + currency_from
> >

BTW: I forgot a basic Python rule and add "self" as an argument to class 
methods :-/ It should naturally be:

 def do_convert_from(self, currency_from):
 print "Convert from:" + currency_from

But it didn't change the result.
Now I've added a PushButton and connected it to a slot where I can get the 
value from the combo, but it's not optimal so I'm still open for suggestions.

-- 
Best Regards / Med venlig hilsen

  Thomas Olsen

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Remote widgets, the next steps

[Fabrizio Montesi]

On Wed, Sep 30, 2009 at 3:45 PM, Rob Scheepmaker <
r.scheepma...@student.utwente.nl> wrote:

> Cool, I'll append some more information to the remote widgets design doc
> when
> I've got the time.
>
Great, thanks.


>
>  > Also, publishing
> >
> > > a Plasma::Service using a different technology (like as a SOAP service)
> > > would
> > > be tricky since the access/control and message singing would make this
> > > SOAP service quite complicated to use
> >
> > Well, a lot of SOAP services in the industry there have very complicated
> > specifications on how to access them. I don't think anybody would kick us
> > for some security parameters that need to be added to messages. :-)
>
> Ok, it'll require me to change the implementation to no longer stream
> Credentials to a bytearray, but append the different fields as child nodes
> in
> the message to be somewhat usable, but that's a relatively minor change.
> And I
> suppose we could always write some libs for php/ruby/whatnot to make
> accessing
> these plasma soap services easier.
>
Definitely. Moreover, they already have some very nice APIs for accessing
Web Services so if we make a little document with the specs it would already
be pretty easy I think.


> >
> > For the future tools, we would just need a WSDL2Jolie converter, since we
> > already have Jolie2Plasma (which converts a Jolie interface to a
> kconfigxml
> > service descriptor).
>
>
> That would be lovely... such a converter could make a lot of common cases
> extremely easy to use. Think of something like:
>
> Plasma::Service *service =
>  AccessManager::self()-
> >accessService("http://soap.amazon.com/schemas2/AmazonWebServices.wsdl";);
>
> and then just being able to use service just like any Plasma::Service.
>
Yes we should aim to something like that. A first step would be at least to
have a semi-automatic tool that takes the WSDL as input and outputs a Jolie
script that can then be used with loadEmbeddedJolieService and let it handle
the dirty work.


> > What I'd like to get working first is to, at least, be able to implement
> > local (yes, local) services in Jolie. By doing so I would already gain a
> >  lot of power, for example a plasmoid could load this Jolie service using
> >  loadEmbeddedJolieService in MetaService and I could use this Jolie
> service
> >  to orchestrate whatever distributed application in a network, hiding the
> >  complexity from Plasma.
> > Orchestrating a distributed application could be something complicated
> > (multiparty p2p session) or simply accessing your GoogleMail. ;)
>
> Cool stuff :p
>
> Thanks for your feedback. You've given me some useful stuff to make the
> implementation more flexible. I'll be improving the implementation, and
> will
> keep you informed of the progress.
>

Ok, thanks a lot. :-)

Cheers,
Fabrizio.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: adding default colors format for kolourpicker and support for latex colors.

[Pino Toscano]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1669/#review2508
---


As said also on IRC (after being asked), I'm NOT ok with the all patch as it is:
- it mixes a new good feature (the latex formatting) with a really questionable 
one (the removal of the color popup)
- it goes A LOT of code messup (unwanted spaces around, coding style changes in 
existing code, inconsistent spacing, etc)
also on IRC I asked you to provide first a clean (code-wise) patch (== new 
review) for ONLY adding the latex formatting, then (after discussion) the other 
change.
I see nothing of that, hence the revert of the commit of this "patch".
Also, would be nice to know what is the rationale for the removal of the popup 
menu, given it is basically part of the workflow of the applet.

Now, some few comments on the rest.


/trunk/KDE/kdeplasma-addons/applets/kolourpicker/kolourpicker.cpp


Missing i18n.



/trunk/KDE/kdeplasma-addons/applets/kolourpicker/kolourpicker.cpp


redF(), greenF() and blueF()



/trunk/KDE/kdeplasma-addons/applets/kolourpicker/kolourpicker.cpp


There's a KLocale function to remove the & mark.


- Pino


On 2009-09-21 13:11:09, Tomaz Canabrava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1669/
> ---
> 
> (Updated 2009-09-21 13:11:09)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> remvoes the default menu that appears whenever we want to pick a color, not 
> it uses a default colorstring format to do that, the color string format 
> should be choosen before picking colors ( click on the round color button, go 
> to Default Color Format and choose your favorite one), then just pick colors 
> without the annoying menu popping everytime.
> 
> Also, added support for latex colors.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdeplasma-addons/applets/kolourpicker/kolourpicker.h 1026319 
>   /trunk/KDE/kdeplasma-addons/applets/kolourpicker/kolourpicker.cpp 1026319 
> 
> Diff: http://reviewboard.kde.org/r/1669/diff
> 
> 
> Testing
> ---
> 
> everything working, no regressions found, no new bugs introduced ( from my 
> tests )
> 
> 
> Thanks,
> 
> Tomaz
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Ayatana notifications for Plasma

[Aaron J. Seigo]

On September 30, 2009, Aurélien Gâteau wrote:
> Aaron J. Seigo wrote:
> > On September 29, 2009, Aurélien Gâteau wrote:
>  Keep in mind that the
>  binary is started on demand, so it does not take any memory if you are
>  not using it (assuming it would automatically stop itself after a
>  while).
> >>>
> >>> Same goes for applets, dataengines...
> >>
> >> Can an applet unload itself from memory? What I meant with "stop itself
> >> after a while", was the notify-osd executable calling exit(). I believe
> >> your desktop would be a bit too clean if an applet called exit() :).
> >
> > the overhead of a running applet should be negligable unless it's doing
> > something rather wrong.
> >
> > so while you can certainly have an applet remove itself you'd also need a
> > way to re-create it, position it properly, make sure any user adjustments
> > previously made to it remain, etc. then there'd be the overhead of any
> > re- layouts this triggers in the containment, etc. for the memory savings
> > that would result, this probably isn't worth it.
> 
> I agree. My point was that the perceived bloat of having a separate
> executable running in the background could be compensated by having said
> executable stop itself after some time, since DBus would restart it when
> needed.

for a separate process this makes sense; for a widget inside of plasma itself 
it's probably better not to bother destroying it and recreating it constantly. 

for clarity, there are three approaches to this:

* extensively modify existing upstream widgets, like the system tray

* minimal modifications to upstream widgets, provide a new widget that also 
runs in plasma (as you did with the message thing)

* minimal modifications to upstream widgets, run all the new stuff in a 
separate process

i think this conversation may be toggling between the first and last 
approaches, when there is the middle approach available.

> > this is why i wrote the QScript based system for controlling
> > plasma-desktop. it supports update scripts. there's a file in
> > workspace/plasma/design/ about it and i've blogged about it as well.
> 
> Oh! I'll forward this to Jonathan. I was thinking about adding a way for
> kconf_update to run commands before and after updates (so that a script
> could stop plasma-desktop, edit its configuration and restart it), but
> this sounds better.

at the very least it actually works ;)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Extenders

[Thomas Olsen]

Having read 
http://techbase.kde.org/Development/Tutorials/Plasma/UsingExtenders I'm still 
a bit baffled as to what Extenders are.
Am I right to believe that they are what you use when you eg. want to have an 
icon in the panel that pops up the plasmoid when clicked upon?
-- 
Best Regards / Med venlig hilsen

  Thomas Olsen

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Extenders

[Marco Martin]

On Wednesday 30 September 2009, Thomas Olsen wrote:
> Having read
> http://techbase.kde.org/Development/Tutorials/Plasma/UsingExtenders I'm
> still a bit baffled as to what Extenders are.
> Am I right to believe that they are what you use when you eg. want to have
> an icon in the panel that pops up the plasmoid when clicked upon?
yes and no.
an icon in the panel that pops up the plasmoid when clicked upon is the 
PopupApplet class, that pops up everything that is contained in the 
qgraphicswidget returned by graphicsWidget() (or setted by setGraphicsWidget)

extenderitems are widgets with their own titlebar that can be stacked and are 
contained in an Extender and can be dragged around between applet or be put 
standalone.
some PopupApplets just use Extender as graphicsWidget()


-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Forecast-only weather ion

[Shawn Starr]

On September 29, 2009 09:14:42 pm Thilo-Alexander Ginkel wrote:
> Hello everyone,
> 
> I am currently developing a Weather Ion for the German wetter.com weather
>  data provider to improve the station coverage for Germany, Austria and
>  Switzerland.
> 
> Unfortunately, wetter.com only provides forecast data through its free web
> service API, so the Ion actually has no access to current observation data
>  to provide to the Weather Plasmoid. AFAICS this results in some ugly
>  rendering glitches in the Plasmoid such as a large question mark document
>  being displayed instead of the current weather condition.

If you omit the keys for current conditions, it should not display any current 
condition tab at all.

> Is building a Ion that does not supply observation data, but only forecast
> data, supported? Is there a way to convince the Weather Plasmoid to skip
> displaying the observation data (instead of displaying "N/A" indicators and
> icons)?
> 
If you use "N/A"  the applet should ignore displaying those fields if they 
aren't even set, they shouldn't appear at all.

Let me know where it is not doing this and I'll fix applet.

Thanks, 
Shawn.

> Thanks,
> Thilo
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
> 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Qalculate plasmoid in kdeplasma-addons

[Aaron J. Seigo]

On September 30, 2009, Matteo Agostinelli wrote:
> Also, I would like to add that this is not meant to be a replacement of the
> existing calculator but an optional "enhanced" calculator, since it
>  requires an additional external dependency (libqalculate). So IMO the
>  current choice of branding (name and icon) could be acceptable. If there

so i finally got it built and found some time to test it. some input:

* it uses QHttp; it must use KIO instead

* the network access in QalculateEngine::updateExchangeRates() is blocking 
rather than async

* there's nothing that defines the widget as being a calculator when it's just 
sitting there. perhaps when there are no results the qalculate icon could be 
painted in the results area? or even the icon and the name? probably don't 
want to do anything with the line edit as it should have as much space as 
possible

* minor issue: there's a tooltip even when the widget is shown fully on the 
desktop that probably isn't overly useful

>  are no objections, I would like to move it to kdeplasma-addons next
>  weekend. I am willing to mantain it in the future.

i'm cool with this; the code looks good and if you are willing / able to 
maintain it -> win! :) i look forward to seeing this in plasma-addons for 4.4. 
do you have a checkout of kdebase around? if you do, could you put an entry in 
workspace/plasma/design/CHANGELOG-4.4 for this? (if not, i can do it for you)

btw, is libqalculate thread safe? if so, would you be interested in hooking up 
qalculate to the calculator runner? if qalculate doesn't exist, it could fall 
back to the current "evaluate it using qscript" method, but if qalculate does 
exist it could get us a much nicer calculator runner.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request: support for latex colours in kolorpicker.

[Tomaz Canabrava]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1747/
---

Review request for Plasma and Pino Toscano.


Summary
---

adds support for latex color on kolourpicker menu.


Diffs
-

  /trunk/KDE/kdeplasma-addons/applets/kolourpicker/kolourpicker.cpp 1029750 

Diff: http://reviewboard.kde.org/r/1747/diff


Testing
---

works, no drawbacks or regressions found.


Thanks,

Tomaz

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Applet::init()

[Aaron J. Seigo]

On September 30, 2009, David Baron wrote:
> Do ALL of it in background threads.
> Just start, set busy if need be, and exit init().
> When threads needed for applet functionality are done, reset busy and let
>  it play.

threaded is one possibility; another is to use async methods which many of our 
libraries already provide.

> Let's check our init code :-)

agreed...

if there are a number of offending applets already, let's get a list of them 
on techbase. otherwise, this should probably be mentioned in a plasma tutorial 
on techbase.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: No signals from Plasma.ComboBox?

[Aaron J. Seigo]

On September 30, 2009, Thomas Olsen wrote:
>  QObject.connect(self.currency_from,SIGNAL("activated(PyQt_PyObject)"),self

have you tried SIGNAL("activated(QString)")? (says the guy who doesn't know 
anything about pyqt ;)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: No signals from Plasma.ComboBox?

[Luca Beltrame]

In data mercoledì 30 settembre 2009 14:09:52, Thomas Olsen ha scritto:

>  QObject.connect(self.currency_from,SIGNAL("activated(PyQt_PyObject)"),self
> .do_convert_from)

In addition to what Aaron said (the signature in quote is not correct), you 
could also use the new PyQt signal API, which is more Pythonic and prevents 
connections not working if you make a typing error.

Basically:

self.currency_form.activated.connect(self.do_convert_form)

so it's object.SIGNAL.connect(SLOT).

Notice that this works only for newer PyQt and SIP versions. In PyKDE4 it 
works most of the time, but not always.

A little OT, but I hope it helps.


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Extenders

[Thomas Olsen]

On 30/9-2009 19:20 Marco Martin  wrote:
> On Wednesday 30 September 2009, Thomas Olsen wrote:
> > Having read
> > http://techbase.kde.org/Development/Tutorials/Plasma/UsingExtenders I'm
> > still a bit baffled as to what Extenders are.
> > Am I right to believe that they are what you use when you eg. want to
> > have an icon in the panel that pops up the plasmoid when clicked upon?
> 
> yes and no.
> an icon in the panel that pops up the plasmoid when clicked upon is the
> PopupApplet class, that pops up everything that is contained in the
> qgraphicswidget returned by graphicsWidget() (or setted by
>  setGraphicsWidget)
> 
> extenderitems are widgets with their own titlebar that can be stacked and
>  are contained in an Extender and can be dragged around between applet or
>  be put standalone.
> some PopupApplets just use Extender as graphicsWidget()
> 

Thanks for the explanation. Even though I have been using KDE4.X since April I 
still don't grasp a lot of the inner workings and I guess I still have to read 
a lot of code and experiment on my own before I'm half way there ;-)
I understood in principle what you wrote but cannot think of an example where 
I have seen it in use. If I where given an example I hope my response would be 
"Ahhh - now I understand" :-D

-- 
Best Regards / Med venlig hilsen

  Thomas Olsen (who is still living in the old Desktop way of thinking)

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Forecast-only weather ion

[Thilo-Alexander Ginkel]

On Wednesday 30 September 2009 19:20:55 Shawn Starr wrote:
> > Unfortunately, wetter.com only provides forecast data through its free
> > web service API, so the Ion actually has no access to current observation
> > data to provide to the Weather Plasmoid. AFAICS this results in some ugly
> > rendering glitches in the Plasmoid such as a large question mark document
> > being displayed instead of the current weather condition.
> 
> If you omit the keys for current conditions, it should not display any
>  current condition tab at all.

That's correct.

> > Is building a Ion that does not supply observation data, but only
> > forecast data, supported? Is there a way to convince the Weather Plasmoid
> > to skip displaying the observation data (instead of displaying "N/A"
> > indicators and icons)?
> 
> If you use "N/A"  the applet should ignore displaying those fields if they
> aren't even set, they shouldn't appear at all.
> 
> Let me know where it is not doing this and I'll fix applet.

Currently I am sending the following data back for a weather forecast request:

QHash(("Place", QVariant(QString, "Heidelberg") ) ( "Credit Url" ,  
QVariant(QString, "http://www.wetter.com";) ) ( "Condition Icon" ,  
QVariant(QString, "N/A") ) ( "Temperature Unit" ,  QVariant(QString, "6001") ) 
( "Total Weather Days" ,  QVariant(int, 4) ) ( "Credit" ,  QVariant(QString, 
"Powered by wetter.com") ) ( "Short Forecast Day 0" ,  QVariant(QString, "day|
weather-clouds|cloudy|22|14|20") ) ( "Short Forecast Day 1" ,  
QVariant(QString, "nite|weather-clouds-night|cloudy|13|12|20") ) ( "Short 
Forecast Day 2" ,  QVariant(QString, "Thu|weather-clouds|cloudy|20|9|20") ) ( 
"Short Forecast Day 3" ,  QVariant(QString, "Fri|weather-clouds|cloudy|17|9|
20") ) ( "Station" ,  QVariant(QString, "Heidelberg") ) )

This results in the following display (under KDE built from trunk): 

http://blog.ginkel.com/wp-content/uploads/2009/09/snapshot-weatherplasmoid.png

IMHO, the condition icon should be left out in this case and probably nothing 
should be displayed instead of "N/A" for the current temperature (I also tried 
leaving out the condition icon completely, which did not make any difference).

Alternatively, I could of course also display the weather icon that is 
associated with the current time in the forecast results, but that kind of 
feels like cheating. ;-)

Now that my Weather Ion is mostly feature-complete, how does the further 
process look like? Should I submit a review request? Should it first go to the 
playground? (Feel free to point me to a Wiki page if there is any explaining 
the process.)

Thanks,
Thilo
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: No signals from Plasma.ComboBox?

[Thomas Olsen]

On 30/9-2009 19:42 "Aaron J. Seigo"  wrote:
> On September 30, 2009, Thomas Olsen wrote:
> > 
> > QObject.connect(self.currency_from,SIGNAL("activated(PyQt_PyObject)"),sel
> >f
> 
> have you tried SIGNAL("activated(QString)")? (says the guy who doesn't know
> anything about pyqt ;)
> 

I'll try your suggestion and also what Luca suggested. I wasn't aware that the 
signal API had changed. Somehow I had gotten unsubscribed from the PyQt 
mailinglist -  I thought it had just died a silent death, but it's alive and 
kicking, so I guess it can save this list from some of my noob questions ;-)

-- 
Best Regards / Med venlig hilsen

  Thomas Olsen

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Fwd: Re: [kde-promo] Communication of the upcoming Kubuntu Netbook Edition release

[Chani]

it seems people like plasma-netbook already :)

--  Forwarded Message  --

Subject: Re: [kde-promo] Communication of the upcoming Kubuntu Netbook Edition 
release
Date: September 29, 2009, 18:30:17
From: Carl Symons 
To: kde-pr...@kde.org

> Date: Tue, 29 Sep 2009 15:18:05 -0400
> From: Scott Kitterman 
> Subject: [kde-promo] Communication of the upcoming Kubuntu Netbook
>Edition release
> To: KDE Promo 

> As some of you will be aware, Kubuntu and the plamsa netbook developers
> have been working together on a special technology preview "Kubuntu Netbook
> Edition" as part of the *buntu "Karmic Koala"/9.10 release next month.

First of all...I downloaded the OS today. It is
delightful...appearance and function.

>
> I'm the Kubuntu developer who has been leading this effort from the Kubuntu
> end of things.  I'm writing here because I want to make sure that how we
> describe the release is in sync with KDE.
>
> The situation, from my perspective is that we have taken a very early
> snapshot of plasma netbook and integrated it into KDE 4.3 (plasma netbook
> will ship from KDE first in 4.4).  It provides a somewhat bare austere, but
> usable environment.

I ran Moblin a bit over the past few days after getting a USB "LiveCD"
at LinuxCon. It is austere. In comparison, Kubuntu Netbook is fancy,
fancy. Nuno Pinheiro's work shines. And the interface philosophy is
already superior to Moblin, in my view. I agree with something I saw
mentioned--perhaps at your site--KNetbook resembles Kubuntu but has
its own personality.

>
> It is stable and usable, but it does not fully reflect KDE's vision for
> netbook.

Yes, but it does reflect a significant departure from netbook business as usual.

>
> I do not want people to look at this and see its incompleteness and say
> KDE's vision falls short.  I want people to see what's there, like it, and
> look forward to seeing the full vision in KDE 4.4 (and of course our "Lucid
> Lynx"/10.04 release).
>
> We are already attracting users from other sources who have never been
> willing to try KDE before.
>
> I'm interested in feedback on how to communicate these messages in a way
> that communicates both what it is and what it isn't.
>
> Scott K
>
>
I've been poking around at Ubuntu Netbook Remix and Moblin. Neither
really work for me, as I'm a KDE Koolaid drinker by now, and Moblin is
not Linuxy enough. I was sold by the video and descriptions.

As Jos says, it works to tell the truth. In my view, the KDE 4 release
philosopy has proven out (yeah I know not everyone agrees.)

There are a couple of technical issues that got in the way of a 100%
no problem install. The ISO is too big to fit on a CD and for some
reason, I couldn't get K3B to stick it on a DVD. So I used unetbootin
and a USB drive. The process was a bit rough. (Although that's one of
the attractions of Linux for me.)

The "newspaper"/"application" selector is a bit hinky. Maybe I haven't
figured it out yet, but it seems to work capriciously.

It feels like what it's billed as--"alpha", although so far it behaves
well. Perhaps something could be done by your team, even possibly with
cooperation from the KDE-promo bunch, to craft an install/user guide.

On my Aspire 1, KNtbk installed wireless & wired networking better
than Kubuntu 9.04. There were no device function issues.

You may want to discount my strong inclination to KDE in the
following...I think that the Kubuntu Netbook Edition-Karmic even now
is superior to straight Kubuntu 9.04 and Moblin. I haven't used Ubuntu
Netbook Remix enough to feel comfortable offering an opinion. In other
words, I think that you've built a winner.

I'd welcome the opportunity to contribute to the introduction effort.

Carl Symons
 
___
This message is from the kde-promo mailing list.

Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set 
digest on or temporarily stop your subscription.

-
-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Extenders

[Hans Chen]

Hi,

The Plasma notifications are extenders. They're stacked, and if you widgets
are unlocked you can drag them to desktop[1] or stack them with other
extenders[2]. (As you can see in the second screencast, the calender is also
an extender).

With best regards,
Hans Chen

[1]
http://userbase.kde.org/images.userbase/e/ed/Plasma_howto-extender-todesktop.gif
[2]
http://userbase.kde.org/images.userbase/6/66/Plasma_howto-extender-stack.gif

On Wed, Sep 30, 2009 at 21:11, Thomas Olsen  wrote:

> On 30/9-2009 19:20 Marco Martin  wrote:
> > On Wednesday 30 September 2009, Thomas Olsen wrote:
> > > Having read
> > > http://techbase.kde.org/Development/Tutorials/Plasma/UsingExtendersI'm
> > > still a bit baffled as to what Extenders are.
> > > Am I right to believe that they are what you use when you eg. want to
> > > have an icon in the panel that pops up the plasmoid when clicked upon?
> >
> > yes and no.
> > an icon in the panel that pops up the plasmoid when clicked upon is the
> > PopupApplet class, that pops up everything that is contained in the
> > qgraphicswidget returned by graphicsWidget() (or setted by
> >  setGraphicsWidget)
> >
> > extenderitems are widgets with their own titlebar that can be stacked and
> >  are contained in an Extender and can be dragged around between applet or
> >  be put standalone.
> > some PopupApplets just use Extender as graphicsWidget()
> >
>
> Thanks for the explanation. Even though I have been using KDE4.X since
> April I
> still don't grasp a lot of the inner workings and I guess I still have to
> read
> a lot of code and experiment on my own before I'm half way there ;-)
> I understood in principle what you wrote but cannot think of an example
> where
> I have seen it in use. If I where given an example I hope my response would
> be
> "Ahhh - now I understand" :-D
>
> --
> Best Regards / Med venlig hilsen
>
>   Thomas Olsen (who is still living in the old Desktop way of thinking)
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Extenders

[Thomas Olsen]

On 30/9-2009 23:24 Hans Chen  wrote:
> Hi,
> 
> The Plasma notifications are extenders. They're stacked, and if you widgets
> are unlocked you can drag them to desktop[1] or stack them with other
> extenders[2]. (As you can see in the second screencast, the calender is
>  also an extender).
> 
> With best regards,
> Hans Chen
> 
> [1]
> http://userbase.kde.org/images.userbase/e/ed/Plasma_howto-extender-todeskto
> p.gif [2]
> http://userbase.kde.org/images.userbase/6/66/Plasma_howto-extender-stack.gi
> f
> 
> > If I where given an example I hope my response
> > would be
> > "Ahhh - now I understand" :-D
> >

Aha - now I understand :-)

Thanks

-- 
Best Regards / Med venlig hilsen

  Thomas Olsen

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Different activities for each desktop KCM

[Marco Martin]

Hi all,
i noticed in the kwin multiple desktops config there is a checkbox for 
enabling the  different activities for each desktop thing in plasma, but it 
was a but uuh, fake.
this patch enables it, using a new plasma dbus call done for that.

Cheers,
Marco Martin
Index: main.ui
===
--- main.ui	(revision 1027345)
+++ main.ui	(working copy)
@@ -84,9 +84,6 @@
   
   

-
- false
-
 
  Different activity for each desktop
 
Index: main.cpp
===
--- main.cpp	(revision 1027345)
+++ main.cpp	(working copy)
@@ -22,6 +22,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -286,6 +287,10 @@
 slotEffectSelectionChanged( m_ui->effectComboBox->currentIndex() );
 // TODO: plasma stuff
 
+QDBusInterface interface("org.kde.plasma-desktop", "/App");
+bool perVirtualDesktopViews = interface.call("perVirtualDesktopViews").arguments().first().toBool();
+m_ui->activityCheckBox->setChecked(perVirtualDesktopViews);
+
 emit changed(false);
 }
 
@@ -353,6 +358,9 @@
 QDBusMessage message = QDBusMessage::createSignal("/KWin", "org.kde.KWin", "reloadConfig");
 QDBusConnection::sessionBus().send(message);
 
+QDBusInterface interface("org.kde.plasma-desktop", "/App");
+interface.call("setPerVirtualDesktopViews", (m_ui->activityCheckBox->isChecked()));
+
 emit changed(false);
 }
 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Applet::init()

[David Baron]

On Wednesday 30 September 2009 19:36:28 Aaron J. Seigo wrote:
> On September 30, 2009, David Baron wrote:
> > Do ALL of it in background threads.
> > Just start, set busy if need be, and exit init().
> > When threads needed for applet functionality are done, reset busy and let
> >  it play.
> 
> threaded is one possibility; another is to use async methods which many of
>  our libraries already provide.
> 
> > Let's check our init code :-)
> 
> agreed...
> 
> if there are a number of offending applets already, let's get a list of
>  them on techbase. otherwise, this should probably be mentioned in a plasma
>  tutorial on techbase.
> 

Recent post cited the qalculate--I really like this one. Poster said the code 
uses a blocking internet access for currency exchange rates. So if the network 
connection is not good, plasma-desktop simply waits. Great plasmoid--please 
change this. I am sure there are others.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Forecast-only weather ion

[Shawn Starr]

On September 30, 2009 03:14:01 pm Thilo-Alexander Ginkel wrote:
> On Wednesday 30 September 2009 19:20:55 Shawn Starr wrote:
> > > Unfortunately, wetter.com only provides forecast data through its free
> > > web service API, so the Ion actually has no access to current
> > > observation data to provide to the Weather Plasmoid. AFAICS this
> > > results in some ugly rendering glitches in the Plasmoid such as a large
> > > question mark document being displayed instead of the current weather
> > > condition.
> >
> > If you omit the keys for current conditions, it should not display any
> >  current condition tab at all.
> 
> That's correct.
> 
> > > Is building a Ion that does not supply observation data, but only
> > > forecast data, supported? Is there a way to convince the Weather
> > > Plasmoid to skip displaying the observation data (instead of displaying
> > > "N/A" indicators and icons)?
> >
> > If you use "N/A"  the applet should ignore displaying those fields if
> > they aren't even set, they shouldn't appear at all.
> >
> > Let me know where it is not doing this and I'll fix applet.
> 
> Currently I am sending the following data back for a weather forecast
>  request:
> 
> QHash(("Place", QVariant(QString, "Heidelberg") ) ( "Credit Url" ,
> QVariant(QString, "http://www.wetter.com";) ) ( "Condition Icon" ,
> QVariant(QString, "N/A") ) ( "Temperature Unit" ,  QVariant(QString,
>  "6001") ) ( "Total Weather Days" ,  QVariant(int, 4) ) ( "Credit" , 
>  QVariant(QString, "Powered by wetter.com") ) ( "Short Forecast Day 0" , 
>  QVariant(QString, "day| weather-clouds|cloudy|22|14|20") ) ( "Short
>  Forecast Day 1" ,
> QVariant(QString, "nite|weather-clouds-night|cloudy|13|12|20") ) ( "Short
> Forecast Day 2" ,  QVariant(QString, "Thu|weather-clouds|cloudy|20|9|20") )
>  ( "Short Forecast Day 3" ,  QVariant(QString,
>  "Fri|weather-clouds|cloudy|17|9| 20") ) ( "Station" ,  QVariant(QString,
>  "Heidelberg") ) )
> 
> This results in the following display (under KDE built from trunk):
> 
> http://blog.ginkel.com/wp-content/uploads/2009/09/snapshot-weatherplasmoid.
> png
> 
> IMHO, the condition icon should be left out in this case and probably
>  nothing should be displayed instead of "N/A" for the current temperature
>  (I also tried leaving out the condition icon completely, which did not
>  make any difference).
> 
> Alternatively, I could of course also display the weather icon that is
> associated with the current time in the forecast results, but that kind of
> feels like cheating. ;-)
> 
> Now that my Weather Ion is mostly feature-complete, how does the further
> process look like? Should I submit a review request? Should it first go to
>  the playground? (Feel free to point me to a Wiki page if there is any
>  explaining the process.)
> 
There is another option,  but since you don't  have any pressure info you 
can't "guess" the condition. So, it seems the applet should ignore displaying 
the icon if there's nothing set at all.

I will fix that on applet side, so you won't see the icon.

The ion should go into the playground there's an ion directory for other 
plugins being developed. From there, we'll let the code settle and test it.

If you don't have an account, you might want to get a SVN account for 
committing it. the Wiki techbase explains where to do this.

Thanks for your contribution and help! :-)

I've been away right now, since i'm currently looking for a job, the market is 
tough right now :-(

Shawn.

> Thanks,
> Thilo
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
> 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Declarative UI integration v0.2

[Alan Alpert]

Hi Plasma Devs,

The feedback on this list was of great help in rethinking the design of the Qt 
Declarative plasma integration. I thought I might spend more time thinking 
about the design and soliciting feedback before I rush off and implement 
something this time :).

The way we get a QML file loaded into an applet is with a PlasmaQmlView, a 
QGraphicsWidget that you can give a QML file and then deal with like any other 
QGraphicsWidget. One reason we need the redesign is that you should be able to 
have multiple ones in an Applet and the 'Plasmoid' item was supposed to only 
be used once. The PlasmaQmlView automatically loads the Plasma items library 
from the C++ side, so that you can import it in QML. There would also still be 
the script engine for QML only applets.

Once the file is loaded we need to provide ways for it to access plasma 
specific 
functionality. The plasma functionality which I believe needs to be exposed 
is:
-Plasma Widgets
-Plasma Theme (SVGs/colors)
-Plasma data sources (through data engines)
-Centrally managed configuration data storage
-Config dialog requested
Please correct me if anything is missing from this list or is incorrect.

Plasma Widgets are exposed directly - you can just go Plasma.PushButton for 
example and it's there. For the moment this works fine, but because they 
weren't designed for QML use their property interfaces are not always that 
great. To fix this I think we'd either write wrappers (which can be done now) 
or add more properties to the Plasma Widgets (which would be done when/if this 
leaves the playground).

My current thought for the remaining points (Theme, Data sources, Config stuff) 
is to have a new QML item created for each, providing a QML interface to that 
functionality. These would be
-a Theme global object in the Plasma QML namespace, with functions to get 
colors or find images/resources
-the DataSource object, as it is in v0.1
-A Config global object, with a configRequested signal and a 'persistent' 
object 
you can set properties on (e.g. Plasma.Config.persistent.weatherLocation = 
"Berlin" would store weatherLocation=Berlin in the right place in the 
appletsrc file)

We currently expose the Plasma::Applet* directly though, as the 'applet' 
global variable, and I'm not sure if this is good design (exposing too much 
internals). So currently I don't actually mention that and advise that it not 
be used, but if it were to be used then maybe you could access the theming 
functions directly. That would remove the need for the QML Theme object but 
I'm currently leaning away from making the applet variable 'public'. 

The 'Plasmoid' item from v0.1 would disappear completely. If your root item is 
a QGraphicsLayoutItem subclass you'll be installed in a QGraphicsLayout 
automatically, otherwise you can watch the size property of the 'applet' 
global variable if you want (which IS the whole applet, not just the QML 
part).  I'm unsure as to whether this is the best idea(but I haven't thought 
of anything better), as in the script engine you might want the additional 
structure of having a Plasmoid item as the root, and in that case it is the 
single item representing the Plasmoid.

So far I have just implemented removing the Plasmoid item, to make sure that 
they can still work like that. Note that QML tries to solve version 
compatibility problems by having the version in the import statement, so while 
Plasma 0.2 has no Plasmoid item, Plasma 0.1 has it (and all the other items) 
just as it was and so all the examples still work as is.

I would appreciate any feedback you have on this design, remembering that Qt 
Declarative itself is still in development and so feedback on how it works can 
still be acted upon.

-- 
Alan Alpert (aalpert on irc)
Software Engineer
Nokia, Qt Development Frameworks
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel