Re: Review Request: Fix geolocation dataengine compilation for gpsd with (GPSD_API_MAJOR_VERSION >= 5)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101247/#review2937 --- Ship it! - Petri On April 28, 2011, 7:16 a.m., Rafael Fernández López wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101247/ > --- > > (Updated April 28, 2011, 7:16 a.m.) > > > Review request for Plasma and Petri Damstén. > > > Summary > --- > > This patch fixes compilation when GPSD_API_MAJOR_VERSION >= 5. The API has > changed and some calls are not compatible with the previous versions. GPSD > version here: 2.96. > > > Diffs > - > > plasma/generic/dataengines/geolocation/location_gps.h 506d1d1 > plasma/generic/dataengines/geolocation/location_gps.cpp c44cb30 > > Diff: http://git.reviewboard.kde.org/r/101247/diff > > > Testing > --- > > I wasn't able to compile the geolocation dataengine, while applying this > patch I can. I have only tested with my GPSD version (2.96), haven't tested > with previous versions, however it should work, since for previous versions > the calls made are exactly the same as before this patch. Not even unused > arguments are created. > > > Thanks, > > Rafael Fernández > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: bug fixes for the system-monitor applet
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/3950/#review7773 --- Ship it! Looks good to me. - Petri On 2010-05-14 08:21:03, Michel Lafon-Puyo wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/3950/ > --- > > (Updated 2010-05-14 08:21:03) > > > Review request for Plasma. > > > Summary > --- > > As my first work for KDE, I would like to add some power management > monitoring features to the system-monitor applet. Monitoring the cpu clock > frequency when using the on-demand or the conservative governor could be > useful (at least it is for me :)). > > Before going further in this development I tried to fix some little bugs with > the applet. Here is the list of the changes this patch introduces: > - the size of the applets when used in the panel and when no item is > monitored was (0,0) but an icon were displayed and it overlapped the other > applets (SM::Applet::CheckGeometry()) > - set the preferred height to MINIMUM when no item is monitored > (SM::Applet::displayNoAvailableSources()). When all the meters of an applet > were removed at once, the size were unchanged and a big icon could be > displayed. > - clear the content of the tooltip when nothing has to be displayed > (SM::Applet::toolTipAboutToShow()) > - when one or many items were set "unmonitored", the corresponding widgets > were not correctly deleted (SM::Applet::deleteMeters()) > - the removal of the layout and the meters were done on > SM::Applet::connectToEngine(), I moved that part in a new method > SM::Applet::removeLayout() that can be called more easily. This method is > called by the applets on configuration change to achieve a clean update. > - the header of the applets is now correctly deleted on form factor change > and should not be displayed when the applet is used in the panel > - when used in the panel, the webview containing the information given by the > hardware information applet was displayed under the icon because the webview > and the icon were not correctly deleted on form factor changes. > - to be consistent with the other applets, the HDD applet has been changed to > *not* populate the configuration with the list of the mounted volumes when > there is no more item to monitor. Nevertheless, on the first launch (no > configuration is present), the behaviour has not changed and the > configuration is still populated with the list of the mounted volumes. > > Additionnally, the HDD applet didn't use the SM::Applet to manage its meters. > So I replaced the list of SM::Plotter (m_plotters) by a list of > QGraphicsWidget (m_meters) and modified HDD to take advantage of the meters > management already implemented in the SM::Applet class (in particular the > removal of the meters/widgets on configuration change as mentioned above). > > Note: I was unable to find any bug reports corresponding to the fixes above. > Should I create them myself? > > > Diffs > - > > /trunk/KDE/kdebase/workspace/plasma/generic/applets/system-monitor/applet.h > 1126529 > > /trunk/KDE/kdebase/workspace/plasma/generic/applets/system-monitor/applet.cpp > 1126529 > /trunk/KDE/kdebase/workspace/plasma/generic/applets/system-monitor/cpu.h > 1126529 > /trunk/KDE/kdebase/workspace/plasma/generic/applets/system-monitor/cpu.cpp > 1126529 > /trunk/KDE/kdebase/workspace/plasma/generic/applets/system-monitor/hdd.h > 1126529 > /trunk/KDE/kdebase/workspace/plasma/generic/applets/system-monitor/hdd.cpp > 1126529 > /trunk/KDE/kdebase/workspace/plasma/generic/applets/system-monitor/hwinfo.h > 1126529 > > /trunk/KDE/kdebase/workspace/plasma/generic/applets/system-monitor/hwinfo.cpp > 1126529 > /trunk/KDE/kdebase/workspace/plasma/generic/applets/system-monitor/net.h > 1126529 > /trunk/KDE/kdebase/workspace/plasma/generic/applets/system-monitor/net.cpp > 1126529 > /trunk/KDE/kdebase/workspace/plasma/generic/applets/system-monitor/ram.h > 1126529 > /trunk/KDE/kdebase/workspace/plasma/generic/applets/system-monitor/ram.cpp > 1126529 > > /trunk/KDE/kdebase/workspace/plasma/generic/applets/system-monitor/temperature.h > 1126529 > > /trunk/KDE/kdebase/workspace/plasma/generic/applets/system-monitor/temperature.cpp > 1126529 > > Diff: http://svn.reviewboard.kde.org/r/3950/diff > > > Testing > --- > > Basic testing > > > Thanks, > > Michel > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [patch] Fix network monitor colors and stacking
On Fri, May 21, 2010 at 10:27 PM, Aaron J. Seigo wrote: > On May 21, 2010, Petri Damstén wrote: >> On Fri, May 21, 2010 at 7:27 PM, Aaron J. Seigo wrote: >> > On May 18, 2010, Petri Damstén wrote: >> >> On Mon, May 17, 2010 at 1:52 PM, Sergey wrote: >> >> > Problem: >> >> > It's very hard to understand on the network monitor plasmoid which >> >> > line is download and which is upload speed. They also stack and >> >> > this is not really usual for this kind of graphs. >> >> >> >> It was stacked before but there were complains that it's hard to read >> >> what is the value of the top graph, so it was changed to be not >> >> stacked. >> > >> > any update on this, Petri? let's either merge the bits that make sense or >> > discard this and close https://bugs.kde.org/show_bug.cgi?id=237922 >> >> Not sure if stacked or not is better. I can live with both. Is it > > well, make a decision one way or the other. :) in fact, just do whatever the > network management plasmoid is doing. there :) > >> possible to add graph colors to theme or is it better to just use hard >> coded colors (current text/background derived colors don't work >> nicely). Either way colors should be probably same as in Network >> Management plasmoid new plotter feature. > > agreed. It now has same colors (hard coded) and is stacked like Network Manager plasmoid. Stacked part of the patch is there so if it seems to be bad it can be changed by uncommenting one line. Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [patch] Fix network monitor colors and stacking
On Fri, May 21, 2010 at 7:27 PM, Aaron J. Seigo wrote: > On May 18, 2010, Petri Damstén wrote: >> On Mon, May 17, 2010 at 1:52 PM, Sergey wrote: >> > Problem: >> > It's very hard to understand on the network monitor plasmoid which >> > line is download and which is upload speed. They also stack and >> > this is not really usual for this kind of graphs. >> >> It was stacked before but there were complains that it's hard to read >> what is the value of the top graph, so it was changed to be not >> stacked. > > any update on this, Petri? let's either merge the bits that make sense or > discard this and close https://bugs.kde.org/show_bug.cgi?id=237922 Not sure if stacked or not is better. I can live with both. Is it possible to add graph colors to theme or is it better to just use hard coded colors (current text/background derived colors don't work nicely). Either way colors should be probably same as in Network Management plasmoid new plotter feature. Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [patch] Fix network monitor colors and stacking
On Mon, May 17, 2010 at 1:52 PM, Sergey wrote: > Problem: > It's very hard to understand on the network monitor plasmoid which > line is download and which is upload speed. They also stack and > this is not really usual for this kind of graphs. It was stacked before but there were complains that it's hard to read what is the value of the top graph, so it was changed to be not stacked. Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [patch] Fix network monitor colors and stacking
On Tue, May 18, 2010 at 9:45 AM, Michel Lafon-Puyo wrote: > Hi, > > I'm currently working on improvements for the system-monitor applet (see > http://reviewboard.kde.org/r/3950/) so I could help on this discussion. > > Le mardi 18 mai 2010 01:58:09, Aaron J. Seigo a écrit : >> * using hardcoded colors isn't going to work with all themes; this needs >> to use the Plasma::Theme colors in the some way, even if it means expsing >> more of the colors in the color scheme to do so > > I think the plotters should use the Plasma::Theme colors by default but could > it be a configuration option too? Currently they do. Text and background colors are used with some KColorUtils::tint. If Plasma theme could provide colors for this kind of use it would be great. > In fact, a lot of configuration stuff is duplicated among the various applets > (hdd, net, cpu...). This should be implemented as part as the base class > (SM::Applet). The color of the lines could be one of the configuration items. > > At the moment, I don't know if "by source" configuration could be useful. We > could choose the height of each plotters, their type (graphical, analogical > like the temperature applet, text...) and of course their color. Any thought > about that? Is it too much configuration options for an applet? I have also made a complex plotter for those who want tweak everything (http://kde-look.org/content/show.php/Complex+Plotter?content=111400). I would like to keep default plotter as clean as possible, but I really don't know anymore what it should have and what not? Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: bug fixes for the system-monitor applet
On Thu, May 13, 2010 at 1:07 AM, Aaron Seigo wrote: Can't find reviewboard password from my laptop so commenting here... > a few minor coments below. the biggest issue now is that with your patch, the > icon for the drives in the disk monitor appear _below_ the meters rather than > beside them. are you seeing this as well? Haven't actually tested the diff but appendVisualization already adds widget to main layout. hdd calls it with meter only. I guess it should call appendVisualization with layout (icon + meter) and remove mainLayout()->addItem(layout); line. Otherwise fixes seem good to me. Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Load webslice params from desktop file
On Friday 19 March 2010 17:51:04 Aaron J. Seigo wrote: > it doesn't address similar issues such as: > > * "how can i ship custom data with my c++ plasmoid in a way that's easy to > get at" (having a package would solve that) What makes a package? I see a desktop file in a zip a bare minimum package. I think that package() should return valid pointer in C++ if it's launched with desktop file under plasma/plasmoids/ so other files can be accessed too. > * "what does a package that customizes a plasmoid like this look like?" > (it's not really a plasma/applet, is it? imagine if we had 900 comic strip > plasmoids showing up ;) There are several plasmoids in kde-look.org to some web services written in scripting languages. These could be done just by writing a desktop file to webslice. From user point of view I think they are separate applets. For comic, weather, etc. those are separate data sources and so dataengine is better suited for those? Petri 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: Review Request: Load webslice params from desktop file
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3315/ --- (Updated 2010-03-18 12:21:54.524176) Review request for Plasma. Changes --- - config not hidden - Better fallback to defaults Summary --- Load webslice params from desktop file so webslices can be shared in kde-look.org as plasmoid packages (package containing only a custom desktop file). Diffs (updated) - /trunk/KDE/kdeplasma-addons/applets/webslice/kgraphicswebslice.cpp 1104337 /trunk/KDE/kdeplasma-addons/applets/webslice/plasma/plasma-applet-webslice.desktop 1104337 /trunk/KDE/kdeplasma-addons/applets/webslice/plasma/webslice.cpp 1104337 Diff: http://reviewboard.kde.org/r/3315/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Load webslice params from desktop file
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3315/ --- (Updated 2010-03-18 10:11:49.915987) Review request for Plasma. Changes --- Using X-Plasma-Args for arguments. Summary --- Load webslice params from desktop file so webslices can be shared in kde-look.org as plasmoid packages (package containing only a custom desktop file). Diffs (updated) - /trunk/KDE/kdeplasma-addons/applets/webslice/kgraphicswebslice.cpp 1104337 /trunk/KDE/kdeplasma-addons/applets/webslice/plasma/plasma-applet-webslice.desktop 1104337 /trunk/KDE/kdeplasma-addons/applets/webslice/plasma/webslice.cpp 1104337 Diff: http://reviewboard.kde.org/r/3315/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Load webslice params from desktop file
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3315/ --- Review request for Plasma. Summary --- Load webslice params from desktop file so webslices can be shared in kde-look.org as plasmoid packages (package containing only a custom desktop file). Diffs - /trunk/KDE/kdeplasma-addons/applets/webslice/kgraphicswebslice.cpp 1104337 /trunk/KDE/kdeplasma-addons/applets/webslice/plasma/CMakeLists.txt 1104337 /trunk/KDE/kdeplasma-addons/applets/webslice/plasma/plasma-applet-webslice.desktop 1104337 /trunk/KDE/kdeplasma-addons/applets/webslice/plasma/plasma-webslice.desktop PRE-CREATION /trunk/KDE/kdeplasma-addons/applets/webslice/plasma/webslice.h 1104337 /trunk/KDE/kdeplasma-addons/applets/webslice/plasma/webslice.cpp 1104337 Diff: http://reviewboard.kde.org/r/3315/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PATCH] Support for PopupApplets in Python
On Saturday 27 February 2010 14:59:11 Richard Dale wrote: > On Sat, Feb 27, 2010 at 11:33 AM, Luca Beltrame > > wrote: > > In data sabato 27 febbraio 2010 12:20:37, Simon Edwards ha scritto: > >> Luca, do you have a simple example of a PopupApplet that I can look at > >> and test with? > > > > You hit the nail on the head here. The fact is, I can't, as discussed > > with Richard Dale on IRC. I tried, looking at the code of the various > > applets (each seems to do things in a slightly different way) to make a > > popup, but it doesn't seem to work: however, since there is no simple > > example of a popupapplet around I'm unsure if it's the binding to have > > problems or if I'm doing something wrong. > > For Ruby I translated the C++ extender tutorial example, but the > problem is that it doesn't work in C++. > > http://techbase.kde.org/Development/Tutorials/Plasma/UsingExtenders > > I think the name of the data engine that the example uses has changed. > Also the instructions on the CMakeLists.txt content weren't present, > and they should be in a tutorial. > > I also don't understand if Plasma::PopupApplet always use extenders, > as in the above tutorial, or whether you normally do something else. > It isn't called a 'Plasma Popup Applet tutorial'. > > The ruby example code is in > kdeexamples/plasma/ruby/applets/extendertutorial > > If it worked it would be quite easy to translate to Python. Python popup applet with extenders: http://websvn.kde.org/trunk/KDE/kdeexamples/plasma/python/applets/pyhello/ Needs hello dataengine: http://websvn.kde.org/trunk/KDE/kdeexamples/plasma/python/dataengines/pyhello/ Petri 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: Review Request: Add city and country resolution to GPS geolocation data using geonames.
On Sunday 24 January 2010 17:18:49 Beat Wolf wrote:
> > On 2009-04-14 18:59:59, Aaron Seigo wrote:
> > > other than a couple of code style comments, and that i can't test it
> > > with a gps for you either :/, my only question/concern is that it's
> > > doing look ups on the internet without checking to see if we're
> > > connected. it could be in a local cache, but i'm going to guess that
> > > in a fairly typical "i'm using gps" scenario one won't have an
> > > internet connection as well. should we query solid for network status?
> > >
> > > rambling off-topic here: i also wonder if we aren't going to want some
> > > "can use the internet for ..." settings somewhere for the case where
> > > we have a system with gps, cheap wifi and expensive g3 connectivity ..
> > > somethings, like looking up the place name on the internet, may not be
> > > acceptible even if there is g3 service? not a use case we actually
> > > have to deal with now, but it's something that pops into my head every
> > > once in a while .. .. like when i see a patch like this :)
> >
> > Petri Damstén wrote:
> > Dataengine already checks network state but since it thinks gps does
> > not need one it uses gps plugin. I think location -> place should be
> > a separate plugin. It's not possible with current code though and I
> > would like to evaluate all the other possibilities before doing
> > rewrite (there were some wlan etc ideas as well). For 4.3 should it
> > go like this, I'm not sure?
> >
> > For 4.4 is geoclue out of the question? It seems that we are
> > implementing pretty much all the same things.
>
> any progress on this patch?
Attached is this patch converted to separate plugin. Tries to also fix plugins
marked as NetworkConnected only to not to update when there is no network.
Petri
Index: location_ip.cpp
===
--- location_ip.cpp (revision 1080874)
+++ location_ip.cpp (working copy)
@@ -61,7 +61,6 @@
// ordering of first three to preserve backwards compatibility
-outd["accuracy"] = 4;
outd["country"] = country;
outd["country code"] = countryCode;
outd["city"] = city;
@@ -75,7 +74,8 @@
Ip::Ip(QObject* parent, const QVariantList& args)
: GeolocationProvider(parent, args), d(new Private())
{
-setUpdateTriggers(SourceEvent | NetworkConnected);
+setUpdateTriggers(NetworkConnected);
+setAccuracy(4);
}
Ip::~Ip()
Index: geolocation.cpp
===
--- geolocation.cpp (revision 1080874)
+++ geolocation.cpp (working copy)
@@ -26,7 +26,7 @@
Geolocation::Geolocation(QObject* parent, const QVariantList& args)
: Plasma::DataEngine(parent, args),
- m_networkStatus(false)
+ m_networkUp(false)
{
Q_UNUSED(args)
setMinimumPollingInterval(500);
@@ -39,7 +39,12 @@
void Geolocation::init()
{
-m_networkStatus = Solid::Networking::status();
+int networkStatus = Solid::Networking::status();
+if (networkStatus == Solid::Networking::Connected || networkStatus == Solid::Networking::Unknown) {
+m_networkUp = true;
+} else {
+m_networkUp = false;
+}
//TODO: should this be delayed even further, e.g. when the source is requested?
const KService::List offers = KServiceTypeTrader::self()->query("Plasma/GeolocationProvider");
@@ -85,7 +90,7 @@
bool changed = false;
foreach (GeolocationProvider *plugin, m_plugins) {
-changed = plugin->requestUpdate(triggers) || changed;
+changed = plugin->requestUpdate(triggers, m_networkUp) || changed;
}
if (changed) {
@@ -97,7 +102,6 @@
bool Geolocation::sourceRequestEvent(const QString &name)
{
-kDebug() << name;
if (name == SOURCE) {
updatePlugins(GeolocationProvider::ForcedUpdate);
setData(SOURCE, m_data);
@@ -109,9 +113,12 @@
void Geolocation::networkStatusChanged()
{
-m_networkStatus = Solid::Networking::status();
-if (m_networkStatus == Solid::Networking::Connected || m_networkStatus == Solid::Networking::Unknown) {
+int networkStatus = Solid::Networking::status();
+if (networkStatus == Solid::Networking::Connected || networkStatus == Solid::Networking::Unknown) {
+m_networkUp = true;
updatePlugins(GeolocationProvider::NetworkConnected);
+} else {
+m_networkUp = false;
}
}
@@ -120,7 +127,7 @@
m_data.clear();
m_accuracy.clear();
-provider->requestUpdate(GeolocationProvider::ForcedUpdate);
+provider->req
Re: Installing plasmoid script howto
On Monday 11 January 2010 20:11:54 Aaron J. Seigo wrote: > On January 11, 2010, Petri Damstén wrote: > > On Monday 11 January 2010 19:01:49 Aaron J. Seigo wrote: > > > On January 11, 2010, Petri Damstén wrote: > > > > I got message for plasmoid script that said 'I have extracted package > > > > to ... and it does not work'. Is there a wiki page that would explain > > > > how to install plasmoid script using gui (and with plasmapkg) and if > > > > not, is > > > > > > er, what exactly did you do, and where did it try to install it and > > > what > > > > > > was the layout of the package, exactly? (e.g. can you provide a test > > > case for it?) > > > > Message was from user that tried to install plasmoid by manually > > unzipping > > ah! it was a message from a human, not one of our tools! haha. i was > wondering where that was in the code ;) > > ok, yes, please add it to user base if you could :) I was thinking something like this: http://userbase.kde.org/User:Pdamsten/Installing_Plasmoids Petri 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: Installing plasmoid script howto
On Monday 11 January 2010 19:01:49 Aaron J. Seigo wrote: > On January 11, 2010, Petri Damstén wrote: > > I got message for plasmoid script that said 'I have extracted package to > > ... and it does not work'. Is there a wiki page that would explain how to > > install plasmoid script using gui (and with plasmapkg) and if not, is > > er, what exactly did you do, and where did it try to install it and what > was the layout of the package, exactly? (e.g. can you provide a test case > for it?) Message was from user that tried to install plasmoid by manually unzipping it and I answerer that using GUI or plasmapkg is the correct way to install. I was just wondering if there already is a wiki page about installing which I could link from the kde-look.org page. And if I take some screenshots and write a howto, should I put it to userbase. Petri 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
Installing plasmoid script howto
Hi, I got message for plasmoid script that said 'I have extracted package to ... and it does not work'. Is there a wiki page that would explain how to install plasmoid script using gui (and with plasmapkg) and if not, is http://userbase.kde.org/Plasma right place for such a page? Petri 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: how can I access DataEngines from JavaScript in the Web Plasmoids?
On Saturday 02 January 2010 03:56:48 Aaron J. Seigo wrote: > On January 1, 2010, Patrick Aljord wrote: > > I just read a comment by Aaron saying that DataEngines can be accesed > > from JavaScript in the Web Plasmoids. I tried to figured how it can be > > done but couldn't so far. Any clue? :) > > kdeexamples/plasma/webkit/plasmoids/ > > requires today's trunk for everything to work perfectly I think dataengines in webkit plasmoids have worked since KDE 4.3. Webkit applet using dataengines, config dialog etc.: http://www.gitorious.org/pdamsten/plasmoids/blobs/master/scriptedimage/contents/code/main.html Petri 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: webkit scriptengine & multiple plasmoids
On Tuesday 22 December 2009 23:40:19 Aaron J. Seigo wrote: > On December 20, 2009, Petri Damstén wrote: > > On Friday 18 December 2009 00:17:19 Marco Martin wrote: > > > On Thursday 17 December 2009, Petri Damstén wrote: > > > > Hi, > > > > > > > > I'm trying to fix this bug: http://www.kde- > > > > look.org/content/show.php/Scripted+Image?content=91749 (Error having > > > > 2 of them). Seems that if there is two (or more) same webkit > > > > plasmoids on desktop only one of them loads properly on plasma start. > > > > When same plasmoid B load is started before A load is finished > > > > javascript functions don't get called. This happens only when > > > > plasmoids are same e.g. two scripted-image plasmoids. I made attached > > > > patch to load plasmoids with the same plugin name in queue and it > > > > seems to solve this but I'm not sure if this right way to do it? > > > > > > > > Petri > > > > > > seems an hacky workaround, but i can'r really think about a possible > > > real cause of this... > > > could be a bug in webkit itself, maybe has some internal sigleton class > > > that gets in an inconsistent state when two pages load the same url in > > > the same moment? seems terribly unlikely but... > > > > I can reproduce this bug with a small Qt only app > > (http://aryhma.oy.cx/damu/webkit-test.tar.gz). It seems that if the same > > javascript file is included in multiple html files that are loaded at the > > same time then loadFinished signal is emitted too early. Should this > > have a workaround in webkit script engine until this is fixed in > > Qt/webkit? > > if it has been reported against Qt/Webkit, then yes, we can have a > (documented) work around in the code that we can remove when Qt/Webkit is > fixed. Noticed that if javascript is embedded in html it works, so this could have a work around also on those rare webkit applets that are run in multiple instances. Qt bug tracker seems to recommend webkit bug tracker for webkit bugs but this bug is related to qt/webkit signals (of course it still might be a webkit bug) so I'm not sure what would be the right place for the report. Petri 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: webkit scriptengine & multiple plasmoids
On Friday 18 December 2009 00:17:19 Marco Martin wrote: > On Thursday 17 December 2009, Petri Damstén wrote: > > Hi, > > > > I'm trying to fix this bug: http://www.kde- > > look.org/content/show.php/Scripted+Image?content=91749 (Error having 2 of > > them). Seems that if there is two (or more) same webkit plasmoids on > > desktop only one of them loads properly on plasma start. When same > > plasmoid B load is started before A load is finished javascript > > functions don't get called. This happens only when plasmoids are same > > e.g. two scripted-image plasmoids. I made attached patch to load > > plasmoids with the same plugin name in queue and it seems to solve this > > but I'm not sure if this right way to do it? > > > > Petri > > seems an hacky workaround, but i can'r really think about a possible real > cause of this... > could be a bug in webkit itself, maybe has some internal sigleton class > that gets in an inconsistent state when two pages load the same url in the > same moment? seems terribly unlikely but... I can reproduce this bug with a small Qt only app (http://aryhma.oy.cx/damu/webkit-test.tar.gz). It seems that if the same javascript file is included in multiple html files that are loaded at the same time then loadFinished signal is emitted too early. Should this have a workaround in webkit script engine until this is fixed in Qt/webkit? Petri 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: webkit scriptengine & multiple plasmoids
On Friday 18 December 2009 00:17:19 Marco Martin wrote: > On Thursday 17 December 2009, Petri Damstén wrote: > > Hi, > > > > I'm trying to fix this bug: http://www.kde- > > look.org/content/show.php/Scripted+Image?content=91749 (Error having 2 of > > them). Seems that if there is two (or more) same webkit plasmoids on > > desktop only one of them loads properly on plasma start. When same > > plasmoid B load is started before A load is finished javascript > > functions don't get called. This happens only when plasmoids are same > > e.g. two scripted-image plasmoids. I made attached patch to load > > plasmoids with the same plugin name in queue and it seems to solve this > > but I'm not sure if this right way to do it? > > > > Petri > > seems an hacky workaround, but i can'r really think about a possible real > cause of this... > could be a bug in webkit itself, maybe has some internal sigleton class > that gets in an inconsistent state when two pages load the same url in the > same moment? seems terribly unlikely but... Yes it's hacky and I don't like it either. Debugged a little more and noticed that if webkit is already loading the same page it emits loadFinished right away for the next pages. I would guess that loadFinished is emitted too early and calling init fails because javascript is not yet ready. Petri koe(5356)/plasma WebApplet::init: Loading frame: QWebFrame(0x1ba51d0) "webkit-test" koe(5356)/plasma WebApplet::init: Loading frame: QWebFrame(0x1bcbe60) "webkit-test" koe(5356)/plasma WebApplet::loadFinished: Load finished for frame: QWebFrame(0x1bcbe60) "webkit-test" koe(5356)/plasma WebApplet::init: Loading frame: QWebFrame(0x1bd31d0) "webkit-test" koe(5356)/plasma WebApplet::loadFinished: Load finished for frame: QWebFrame(0x1bd31d0) "webkit-test" koe(5356)/plasma WebApplet::init: Loading frame: QWebFrame(0x1bdf020) "webkit-test" koe(5356)/plasma WebApplet::loadFinished: Load finished for frame: QWebFrame(0x1bdf020) "webkit-test" koe(5356)/plasma WebApplet::init: Loading frame: QWebFrame(0x1bedd10) "scriptedimage" koe(5356)/plasma WebApplet::init: Loading frame: QWebFrame(0x1bda090) "scriptedimage" koe(5356)/plasma WebApplet::loadFinished: Load finished for frame: QWebFrame(0x1bda090) "scriptedimage" koe(5356)/plasma WebApplet::loadFinished: Load finished for frame: QWebFrame(0x1ba51d0) "webkit-test" koe(5356)/plasma WebApplet::loadFinished: Load finished for frame: QWebFrame(0x1bedd10) "scriptedimage" 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
webkit scriptengine & multiple plasmoids
Hi,
I'm trying to fix this bug: http://www.kde-
look.org/content/show.php/Scripted+Image?content=91749 (Error having 2 of
them). Seems that if there is two (or more) same webkit plasmoids on desktop
only one of them loads properly on plasma start. When same plasmoid B load is
started before A load is finished javascript functions don't get called. This
happens only when plasmoids are same e.g. two scripted-image plasmoids. I made
attached patch to load plasmoids with the same plugin name in queue and it
seems to solve this but I'm not sure if this right way to do it?
Petri
Index: webapplet.cpp
===
--- webapplet.cpp (revision 1063166)
+++ webapplet.cpp (working copy)
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -67,8 +68,13 @@
Plasma::WebView *page;
bool loaded;
+KUrl url;
+QString webpage;
+static QMap loading;
};
+QMap WebApplet::Private::loading;
+
WebApplet::WebApplet(QObject *parent, const QVariantList &args)
: AppletScript(parent),
d(new Private)
@@ -86,20 +92,31 @@
d->init(this);
QString webpage;
-webpage = package()->filePath("mainscript");
+d->webpage = package()->filePath("mainscript");
-if (webpage.isEmpty()) {
+if (d->webpage.isEmpty()) {
kDebug() << "fail! no page";
delete d->page;
d->page = 0;
return false;
}
-KUrl url(package()->filePath("html"));
-kDebug() << webpage << package()->path() << url;
-d->page->mainFrame()->setHtml(dataFor(webpage), url);
+d->url = KUrl(package()->filePath("html"));
+kDebug() << d->webpage << package()->path() << d->url;
+load();
return true;
}
+void WebApplet::load()
+{
+if (!d->loading.contains(package()->metadata().pluginName()) ||
+!d->loading[package()->metadata().pluginName()]) {
+d->loading[package()->metadata().pluginName()] = true;
+d->page->mainFrame()->setHtml(dataFor(d->webpage), d->url);
+} else {
+QTimer::singleShot(50, this, SLOT(load()));
+}
+}
+
void WebApplet::paintInterface(QPainter *painter,
const QStyleOptionGraphicsItem *option,
const QRect &contentsRect)
@@ -116,6 +133,7 @@
void WebApplet::loadFinished(bool success)
{
+d->loading[package()->metadata().pluginName()] = false;
d->loaded = success;
}
Index: webapplet.h
===
--- webapplet.h (revision 1063166)
+++ webapplet.h (working copy)
@@ -56,6 +56,7 @@
void connectFrame(QWebFrame *);
virtual void loadFinished(bool);
virtual void initJsObjects();
+void load();
private:
class Private;
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: Time dataengine invalid sunrise and sunset results
On Thursday 26 November 2009 06:56:09 Amos Kariuki wrote:
> I have some test code to obtain the sunrise and sunset time given a
> longitude and latitude for a location:
>
> QString Latitude = "40";
> QString Longitude = "-75";
> Plasma::DataEngine* timeEngine =
> Plasma::DataEngineManager::self()->loadEngine("time"); const
> Plasma::DataEngine::Data timeData=
> timeEngine->query(QString("Local|Solar|Latitude=%1|Longitude=%2").arg(Lati
> tude).arg(Longitude)); qDebug() << "Sunrise: " << timeData["Sunrise"] <<
> "Sunset: " << timeData["Sunset"];
>
> The result I get is:
> Sunrise: QVariant(QDateTime, QDateTime("Tue Nov 24 20:01:02 2009") )
> Sunset: QVariant(QDateTime, QDateTime("Wed Nov 25 05:32:35 2009") )
>
>
> However, the results for that location (40, -75) based on NOAA's solar
> calculator at
Re: Review Request: Draft: Widgets Explorer "Add Widgets"
On Wednesday 25 November 2009 07:30:03 Anselmo Melo wrote:
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2191/
> ---
>
> (Updated 2009-11-25 05:30:03.553432)
>
>
> Review request for Plasma.
>
>
> Changes
> ---
>
> Diff updated. Includes:
> * "Get New Widgets" button+submenu
> * Changes by Petri Damstén ("get new widgets" button between the input
> field and tabbar + close button) * close button working
Message freeze is today, so is this ready to be committed?
Petri
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: Review Request: Draft: Widgets Explorer "Add Widgets"
On Friday 20 November 2009 22:15:45 Anselmo Melo wrote: > > On 2009-11-20 19:46:47, Marco Martin wrote: > > > i still think the button should be between the input field and the > > > tabbar, to not take even more vertical space > > > > Anselmo Melo wrote: > > Nica. I'll change that and update the screenshot. > > Hm... well, the input field and the tabbar are part of the same widget > (filteringwidget). Maybe it's better place it on the left of input field > to not mix "filters" with "new widget" stuff. I'm going to the airport > right now, I'll try to work on it during the flight =) Modified the diff so it puts the Get New Widgets to the filter row: http://kotisivu.lumonetti.fi/damu0/misc/we.diff It also adds close button but It's not working yet: http://kotisivu.lumonetti.fi/damu0/images/add-widgets1.png Petri 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: Review Request: About, stop and uninstall buttons in widget explorer
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2213/ --- (Updated 2009-11-20 13:51:32.753648) Review request for Plasma. Changes --- * About data in tooltip. If this http://teom.wordpress.com/2009/08/23/social-desktop-integration-in-kaboutdialog/ goes to kdelibs it could be nice for plasmoids too. * No stop button. I kind a liked it in previous add dialog, but it's true that it's not needed for general use. There is code for handling ksycoca database changes in model but the icon is not removed on uninstall. I'll investigate it further next week or if someone more familiar with this code can take a look it would be great. Summary --- Mostly copy/paste code. TODO: * How to hide widget explorer when about pressed? * Buttons seem to take space in layout even when hidden, so removing/adding now * Some layout issues on first show * list must be updated on uninstall/stop * recycle about dialog (todo from old add widgets dialog) Diffs (updated) - /trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsExplorer/appletslist.cpp 1051785 /trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsExplorer/applettooltip.h 1051785 /trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsExplorer/applettooltip.cpp 1051785 /trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsExplorer/widgetexplorer.h 1051785 /trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsExplorer/widgetexplorer.cpp 1051785 Diff: http://reviewboard.kde.org/r/2213/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: About, stop and uninstall buttons in widget explorer
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2213/ --- Review request for Plasma. Summary --- Mostly copy/paste code. TODO: * How to hide widget explorer when about pressed? * Buttons seem to take space in layout even when hidden, so removing/adding now * Some layout issues on first show * list must be updated on uninstall/stop * recycle about dialog (todo from old add widgets dialog) Diffs - /trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsExplorer/appletslist.h 1051459 /trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsExplorer/appletslist.cpp 1051459 /trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsExplorer/applettooltip.h 1051459 /trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsExplorer/applettooltip.cpp 1051459 /trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsExplorer/widgetexplorer.h 1051459 /trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsExplorer/widgetexplorer.cpp 1051459 Diff: http://reviewboard.kde.org/r/2213/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Draft: Widgets Explorer "Add Widgets"
On Thursday 19 November 2009 13:28:01 Marco Martin wrote: > > Another issues: > > * I'm missing remove and about buttons. At least about dialog would be > > important for kde-look.org plasmoids. Is the Applet info popup right > > place for those? > > in the tooltip yes. > scripted plasmoids should already have a remove button by the way? Yes, but it seems to be doing nothing. I'll take a look on this today/tomorrow. Petri 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: Review Request: Draft: Widgets Explorer "Add Widgets"
On Tuesday 17 November 2009 11:01:40 Marco Martin wrote: > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/2191/#review3141 > --- > > > ths is absolutely needed, to not face a dig regression in 4.4... can't > really try the patch right now, can you provide a screenshot of it? Applied the patch, screenshot here: http://kotisivu.lumonetti.fi/damu0/images/add-widgets.jpg Could the button be on the same line with the search and category boxes? Another issues: * I'm missing remove and about buttons. At least about dialog would be important for kde-look.org plasmoids. Is the Applet info popup right place for those? * Could the icons have two rows of text? * Sometimes search box won't accept focus and clicking desktop does not hide widgets explorer (Previous add widgets dialog also had focus on search at start which was good imho). Petri 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: Add missing actionsForMatch
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2180/ --- Review request for Plasma. Summary --- Would this be a correct way to add missing actionsForMatch? Diffs - /trunk/KDE/kdelibs/plasma/abstractrunner.cpp 1048280 /trunk/KDE/kdelibs/plasma/scripting/runnerscript.h 1048280 Diff: http://reviewboard.kde.org/r/2180/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Support translations in Runner and DataEngine packages
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2134/ --- Review request for Plasma. Summary --- * Are translations needed in DataEngine packages? * Can Runner use PlasmoidPackage? Translations and ui files are possible. Diffs - /trunk/KDE/kdelibs/plasma/scripting/scriptengine.cpp 1047395 /trunk/KDE/kdelibs/plasma/dataengine.cpp 1047395 /trunk/KDE/kdelibs/plasma/private/abstractrunner_p.h 1047395 /trunk/KDE/kdelibs/plasma/private/dataengine_p.h 1047395 /trunk/KDE/kdelibs/plasma/abstractrunner.cpp 1047395 Diff: http://reviewboard.kde.org/r/2134/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Network Management Plasmoid TODOs
On Tuesday 10 November 2009 17:49:04 Will Stephenson wrote: > This will only work for WPA-PSK wireless connections though, for EAP, > cellular and VPN connections there are just too many mandatory settings to > show even a simplified view in the popup. Do you want to introduce a > second interaction path just for a different type of wifi connection? I think for cellular Country + Provider would be enough in most cases. For VPN simple config could be just 'import settings file'. Petri 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: QWebFrame and baseUrl
On Tuesday 10 November 2009 15:42:18 Kenneth Christiansen wrote:
> Hi again.
>
> I talked to Thiago Macieira and he told me that QUrl in 4.6 is more
> strict than in 4.5, but there isn't any behaviour change.
>
> Can you please give me examples that stopped working?
d->page->mainFrame()->setHtml(dataFor(webpage), QUrl(package()-
>filePath("html"))); used to work. Now urls have to have scheme to work. Fixed
by using KUrl that adds file:// for local paths.
Petri
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: Network Management Plasmoid TODOs
On Monday 09 November 2009 15:06:40 Sebastian Kügler wrote: > Note that I can't test VPN or mobile broadband stuff. If nobody can do > that, we should disable it before the release. It would be nice if there could be a simpler configuration dialog shown first on add like: Add wireless: Network: [ Strongest net v] Password: [ ] [Advanced...] Add mobile: Country: [ From geolocation? v] Operator: [v] [Advanced...] nm-applet has country/operator selection for mobile and it's pretty useful. Petri 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: Review Request: Add missing functions to RunnerScript
On Wednesday 04 November 2009 10:02:34 Petri Damstén wrote: > Changes > --- > > emit RunnerScript signals from AbstractRunner directly. > > > Summary > --- > > Add missing functions to RunnerScript. Initial python support ready. Committed other Script classes. Was there something else for this RunnerScript class? Petri 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
QWebFrame and baseUrl
Hi,
Seems that after update to 4.6 webkit scriptengine stopped working. Problem is
that now baseUrl has to have scheme in it to work. Is this intentional feature
in 4.6?
Petri
Index: webapplet.cpp
===
--- webapplet.cpp (revision 1044595)
+++ webapplet.cpp (working copy)
@@ -94,9 +94,10 @@
d->page = 0;
return false;
}
-
-kDebug() << webpage << package()->path() << package()->filePath("html");
-d->page->mainFrame()->setHtml(dataFor(webpage), QUrl(package()-
>filePath("html")));
+QUrl url(package()->filePath("html"));
+url.setScheme("file");
+kDebug() << webpage << package()->path() << url;
+d->page->mainFrame()->setHtml(dataFor(webpage), url);
return true;
}
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: Review Request: Add missing functions to RunnerScript
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2054/ --- (Updated 2009-11-04 08:02:34.755273) Review request for Plasma. Changes --- emit RunnerScript signals from AbstractRunner directly. Summary --- Add missing functions to RunnerScript. Initial python support ready. Diffs (updated) - /trunk/KDE/kdelibs/plasma/abstractrunner.h 1044136 /trunk/KDE/kdelibs/plasma/abstractrunner.cpp 1044136 /trunk/KDE/kdelibs/plasma/scripting/runnerscript.h 1044136 /trunk/KDE/kdelibs/plasma/scripting/runnerscript.cpp 1044136 Diff: http://reviewboard.kde.org/r/2054/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add missing functions to RunnerScript
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2054/ --- (Updated 2009-11-03 18:41:40.896958) Review request for Plasma. Changes --- Use signals instead of virtual functions. Summary --- Add missing functions to RunnerScript. Initial python support ready. Diffs (updated) - /trunk/KDE/kdelibs/plasma/abstractrunner.h 1044136 /trunk/KDE/kdelibs/plasma/abstractrunner.cpp 1044136 /trunk/KDE/kdelibs/plasma/scripting/runnerscript.h 1044136 /trunk/KDE/kdelibs/plasma/scripting/runnerscript.cpp 1044136 Diff: http://reviewboard.kde.org/r/2054/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add missing functions to RunnerScript
> On 2009-11-03 17:06:58, Aaron Seigo wrote: > > /trunk/KDE/kdelibs/plasma/scripting/runnerscript.h, lines 87-98 > > <http://reviewboard.kde.org/r/2054/diff/1/?file=13668#file13668line87> > > > > can't add new virtual members; it's BIC. the prepare and teardown slots > > are unecessary as the signals can be connected to. Should I just remove those for now or? - Petri --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2054/#review2902 ------- On 2009-11-03 08:36:35, Petri Damstén wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/2054/ > --- > > (Updated 2009-11-03 08:36:35) > > > Review request for Plasma. > > > Summary > --- > > Add missing functions to RunnerScript. Initial python support ready. > > > Diffs > - > > /trunk/KDE/kdelibs/plasma/abstractrunner.h 1044136 > /trunk/KDE/kdelibs/plasma/abstractrunner.cpp 1044136 > /trunk/KDE/kdelibs/plasma/scripting/runnerscript.h 1044136 > /trunk/KDE/kdelibs/plasma/scripting/runnerscript.cpp 1044136 > > Diff: http://reviewboard.kde.org/r/2054/diff > > > Testing > --- > > > Thanks, > > Petri > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: plasmapkg & wallpaper
> On 2009-11-03 17:07:50, Aaron Seigo wrote: > > /trunk/KDE/kdebase/runtime/plasma/tools/plasmapkg/main.cpp, lines 137-138 > > <http://reviewboard.kde.org/r/2006/diff/2/?file=13546#file13546line137> > > > > does this work for zip'd up packages as well? Plasma::PackageStructure reads metadata from zip files and it's used like this later in the code. I tested it with wallpaper plugin, runner and dataengine packages and it correctly identified those. It does not identify wallpaper image package automatically (it would have to read zip file directly?). - Petri --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2006/#review2903 ----------- On 2009-10-30 08:07:28, Petri Damstén wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/2006/ > --- > > (Updated 2009-10-30 08:07:28) > > > Review request for Plasma. > > > Summary > --- > > * install wallpaper plasma packages > * auto detect (plasmoids,) dataengines, runners and wallpapers (install them > without --type) > * Remove previous package also with --install > > > Diffs > - > > /trunk/KDE/kdebase/runtime/plasma/tools/plasmapkg/main.cpp 1042090 > > Diff: http://reviewboard.kde.org/r/2006/diff > > > Testing > --- > > > Thanks, > > Petri > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Add missing functions to RunnerScript
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2054/ --- Review request for Plasma. Summary --- Add missing functions to RunnerScript. Initial python support ready. Diffs - /trunk/KDE/kdelibs/plasma/abstractrunner.h 1044136 /trunk/KDE/kdelibs/plasma/abstractrunner.cpp 1044136 /trunk/KDE/kdelibs/plasma/scripting/runnerscript.h 1044136 /trunk/KDE/kdelibs/plasma/scripting/runnerscript.cpp 1044136 Diff: http://reviewboard.kde.org/r/2054/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: plasmapkg & wallpaper
On Friday 30 October 2009 10:07:28 Petri Damstén wrote: > (Updated 2009-10-30 08:07:28.008673) > > > Review request for Plasma. > > > Changes > --- > > * --type wallpaper works for both wallpaper plugin and wallpaper image > packages. * install / upgrade reverted to original Is there something else that should be added to this (so should I put this to feature plan to get more time)? Petri 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: setData & QVariant
On Monday 02 November 2009 22:38:53 Aaron J. Seigo wrote:
> On October 31, 2009, Petri Damstén wrote:
> > On Friday 30 October 2009 19:53:29 Aaron J. Seigo wrote:
> > > On October 30, 2009, Petri Damstén wrote:
> > > > I'm trying to fix BUG 212342. It seems like if variable is put to
> > > > QVariant and then as a parameter to setData it does not work. If same
> > > > variable is
> > >
> > > odd ...
> > >
> > > what does a simple app like this give you:
> > >
> > > #include
> > > #include
> > > using namespace std;
> > >
> > > int main()
> > > {
> > > QVariant v;
> > > cout << v.isNull() << " " << v.isValid() << endl;
> > > return 0;
> > > }
> >
> > test$ ./mytest
> > 1 0
>
> so it isn't in QVariant (which would have surprised me), and the code in
> DataEngine hasn't changed recently. the check in setData is for (v.isNull()
> || !v.isValid()), perhaps you can put some debug in there to see what is
> happening?
Seems that v is null for Free Space. Modified test:
#include
#include
using namespace std;
int main()
{
QVariant v;
qlonglong ll = 1024;
v.setValue(ll);
cout << v.toLongLong() << " " << v.isNull() << " " << v.isValid() << endl;
return 0;
}
gives:
test$ ./mytest
1024 1 1
Petri
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: setData & QVariant
On Friday 30 October 2009 19:53:29 Aaron J. Seigo wrote:
> On October 30, 2009, Petri Damstén wrote:
> > I'm trying to fix BUG 212342. It seems like if variable is put to
> > QVariant and then as a parameter to setData it does not work. If same
> > variable is
>
> odd ...
>
> what does a simple app like this give you:
>
> #include
> #include
> using namespace std;
>
> int main()
> {
> QVariant v;
> cout << v.isNull() << " " << v.isValid() << endl;
> return 0;
> }
>
test$ ./mytest
1 0
Petri
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
setData & QVariant
Hi,
I'm trying to fix BUG 212342. It seems like if variable is put to QVariant and
then as a parameter to setData it does not work. If same variable is put as a
parameter to setData directly it works? see attached patch. I think this
happened after updating to Qt 4.6.
Petri
Index: soliddeviceengine.cpp
===
--- soliddeviceengine.cpp (revision 1042590)
+++ soliddeviceengine.cpp (working copy)
@@ -157,13 +157,13 @@
setData(name, I18N_NOOP("File Path"), storageaccess->filePath());
if (storageaccess->isAccessible()) {
-QVariant freeDiskVar;
-qlonglong freeDisk = freeDiskSpace(storageaccess->filePath());
-if ( freeDisk != -1 ) {
-freeDiskVar.setValue( freeDisk );
-}
if (!device.is()) {
-setData(name, I18N_NOOP("Free Space"), freeDiskVar );
+qlonglong freeDisk = freeDiskSpace(storageaccess->filePath());
+if (freeDisk != -1) {
+setData(name, I18N_NOOP("Free Space"), freeDisk);
+} else {
+setData(name, I18N_NOOP("Free Space"), QVariant());
+}
}
}
@@ -550,14 +550,16 @@
}
Solid::StorageAccess *storageaccess = device.as();
-if (storageaccess == 0) return false;
+if (storageaccess == 0) {
+return false;
+}
-QVariant freeSpaceVar;
qlonglong freeSpace = freeDiskSpace(storageaccess->filePath());
-if ( freeSpace != -1 ) {
-freeSpaceVar.setValue( freeSpace );
+if (freeSpace != -1) {
+setData(udi, I18N_NOOP("Free Space"), freeSpace);
+} else {
+setData(udi, I18N_NOOP("Free Space"), QVariant());
}
-setData(udi, I18N_NOOP("Free Space"), freeSpaceVar );
return true;
}
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: Review Request: return minimum size for Plasma::Frame
> On 2009-10-30 09:58:36, Marco Martin wrote: > > /trunk/KDE/kdelibs/plasma/widgets/frame.cpp, line 272 > > <http://reviewboard.kde.org/r/2018/diff/1/?file=13547#file13547line272> > > > > perhaps it should be the preferred too Added it to preferred too. - Petri --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2018/#review2867 --- On 2009-10-30 09:48:52, Petri Damstén wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/2018/ > --- > > (Updated 2009-10-30 09:48:52) > > > Review request for Plasma. > > > Summary > --- > > return minimum size for Plasma::Frame (BUG: 212341) > > > Diffs > - > > /trunk/KDE/kdelibs/plasma/widgets/frame.cpp 1042084 > > Diff: http://reviewboard.kde.org/r/2018/diff > > > Testing > --- > > > Thanks, > > Petri > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: return minimum size for Plasma::Frame
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2018/ --- Review request for Plasma. Summary --- return minimum size for Plasma::Frame (BUG: 212341) Diffs - /trunk/KDE/kdelibs/plasma/widgets/frame.cpp 1042084 Diff: http://reviewboard.kde.org/r/2018/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: plasmapkg & wallpaper
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2006/ --- (Updated 2009-10-30 08:07:28.008673) Review request for Plasma. Changes --- * --type wallpaper works for both wallpaper plugin and wallpaper image packages. * install / upgrade reverted to original Summary --- * install wallpaper plasma packages * auto detect (plasmoids,) dataengines, runners and wallpapers (install them without --type) * Remove previous package also with --install Diffs (updated) - /trunk/KDE/kdebase/runtime/plasma/tools/plasmapkg/main.cpp 1042090 Diff: http://reviewboard.kde.org/r/2006/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: plasmapkg & wallpaper
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2006/ --- Review request for Plasma. Summary --- * install wallpaper plasma packages * auto detect (plasmoids,) dataengines, runners and wallpapers (install them without --type) * Remove previous package also with --install Diffs - /trunk/KDE/kdebase/runtime/plasma/tools/plasmapkg/main.cpp 1042090 Diff: http://reviewboard.kde.org/r/2006/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: WallpaperScript
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1984/ --- (Updated 2009-10-28 08:49:03.341028) Review request for Plasma. Changes --- * ScriptEngine and Wallpaper are both QObjects so WallpaperScript cannot inherit both. Added a small helper class for this (not a best name perhaps). Or should WallpaperScript not inherit ScriptEngine? * I have done some work with python but currently it just paints wallpaper with single color. * plasmapkg modifications are on the way too. Summary --- Adds WallpaperScript for scripted wallpaper plugins. Diffs (updated) - /trunk/KDE/kdelibs/plasma/wallpaper.h 1041546 /trunk/KDE/kdelibs/plasma/scripting/wallpaperscript.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1041546 /trunk/KDE/kdelibs/plasma/packagestructure.cpp 1041546 /trunk/KDE/kdelibs/plasma/plasma.h 1041546 /trunk/KDE/kdelibs/plasma/private/wallpaper_p.h 1041546 /trunk/KDE/kdelibs/plasma/scripting/scriptengine.h 1041546 /trunk/KDE/kdelibs/plasma/scripting/scriptengine.cpp 1041546 /trunk/KDE/kdelibs/plasma/scripting/wallpaperscript.h PRE-CREATION /trunk/KDE/kdelibs/plasma/wallpaper.cpp 1041546 Diff: http://reviewboard.kde.org/r/1984/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: WallpaperScript
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1984/ --- Review request for Plasma. Summary --- Adds WallpaperScript for scripted wallpaper plugins. Diffs - /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1040341 /trunk/KDE/kdelibs/plasma/packagestructure.cpp 1040341 /trunk/KDE/kdelibs/plasma/plasma.h 1040341 /trunk/KDE/kdelibs/plasma/private/wallpaper_p.h 1040341 /trunk/KDE/kdelibs/plasma/scripting/scriptengine.h 1040341 /trunk/KDE/kdelibs/plasma/scripting/scriptengine.cpp 1040341 /trunk/KDE/kdelibs/plasma/scripting/wallpaperscript.h PRE-CREATION /trunk/KDE/kdelibs/plasma/scripting/wallpaperscript.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/wallpaper.h 1040341 /trunk/KDE/kdelibs/plasma/wallpaper.cpp 1040341 Diff: http://reviewboard.kde.org/r/1984/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Small fixes
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1939/ --- Review request for Plasma. Summary --- * Add support to load PopupApplet and Containment from path * AppletScript::addStandardConfigurationPages adds also publish page * AppletScript::standardConfigurationDialog does not add standard pages (or what is addStandardConfigurationPages for?) Diffs - /trunk/KDE/kdelibs/plasma/applet.cpp 1039407 /trunk/KDE/kdelibs/plasma/containment.h 1039407 /trunk/KDE/kdelibs/plasma/containment.cpp 1039407 /trunk/KDE/kdelibs/plasma/popupapplet.h 1039407 /trunk/KDE/kdelibs/plasma/popupapplet.cpp 1039407 /trunk/KDE/kdelibs/plasma/private/applet_p.h 1039407 /trunk/KDE/kdelibs/plasma/scripting/appletscript.cpp 1039407 Diff: http://reviewboard.kde.org/r/1939/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Dataengines, libs and default config
On Friday 18 September 2009 21:43:20 Aaron J. Seigo wrote: > On September 18, 2009, Petri Damstén wrote: > > > > Currently making a weather applet is much harder in scripting > > > > languages because you don't have access to the library. > > > > > > can't you build some QScript bindings for it? then the applet can > > > request that add-on? > > > > Yes of course but I was thinking some common way that would not require > > generating bindings for all available scritpengines. > > there are a few ways to go about this: > > a) go around making bindings for multiple languages over and over. not > realistic, imo > > b) create a generic interface to specific kinds of things that then each > script engine maintainer can look after > > c) concentrate on the JS bindings and make those top tier and not worry too > much about whether there are equal features in every single script engine. > > (c) is what i'd like to see us do. there are already differences between > the script engines (obvious ones like google gadgets vs pythonoids; less > obvious ones like python libs that aren't available in ruby). > > we really ought to be promoting JS as the preferred way to write plasmoids > anyways and given that we have limited resources and no suitable CLR type > thing realistically at our disposal, let's just concentrate on QSCript > here. > > so.. what would it look like? > > i think most sensible would be a way to register families of widget types > (weather, clock, etc). perhaps we can call them "widget foundations", since > you build on top of them? each foundation would provide a factory for > creating instances of an applet with some QScript hooks that can be > exported into the runtime, perhaps as part of an object named > "foundation"? I think most of the kde-look.org plasmoids are made with python (quick check from 20 highest rated is about 90%). I personally don't like the idea of letting those to be second class citizens. Petri 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: Now Playing & Urls
On Friday 18 September 2009 20:04:22 Aaron J. Seigo wrote: > On September 17, 2009, Alex Merry wrote: > > On Thursday 17 September 2009 18:05:59 you wrote: > > > Hi, > > > > > > Not all script engines (e.g. webkit) can use QPixmap from the data and > > > sometimes file path is useful (if artwork is not set I would like to > > > show jpg from the same dir). This patch adds Url & ArtUrl fields to > > > data. Ok to commit or should I find another solution? > > > > Well, the only thing that concerns me is that if the widget and engine > > are on different machines (which is entirely possible, since one of the > > GSoC projects was to allow just that), the URLs will not be valid for the > > widget. > > that's correct; paths that are not reachable over the network are not ok if > the widget is expected to be able to work over the network at all. > > one way to work around this would be to implement a system that lets one > open files using KIO via either the DataEngine or AccessManager which > would handle where to open the file from. > > but if this really is just to work around webkit not being able to access > pixmap data, that's really something certainly can be worked around in the > webkit script engine. I can live without arturl but url would be handy even if it is not valid. If there is no metadata I would like to use file name so there is something to show to the user. Other option would be to set pattern in dataengine so it could parse the directory and file name but I'm not sure if that belongs there. Petri 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: Dataengines, libs and default config
On Friday 18 September 2009 20:26:20 Aaron J. Seigo wrote: > On September 18, 2009, Petri Damstén wrote: > > Would it be possible to put default config pages that are currently in > > libs (libplasmaweather, libplasmaclock, ...) to dataengine (or > > somewhere)? > > DataEngines can not do any UI. Not necessarily in dataengine but associated somehow in plugin/library. > > Currently making a weather applet is much harder in scripting languages > > because you don't have access to the library. > > can't you build some QScript bindings for it? then the applet can request > that add-on? Yes of course but I was thinking some common way that would not require generating bindings for all available scritpengines. Well that was just an idea maybe not forth implementing... Petri 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
Dataengines, libs and default config
Hi, Would it be possible to put default config pages that are currently in libs (libplasmaweather, libplasmaclock, ...) to dataengine (or somewhere)? Currently making a weather applet is much harder in scripting languages because you don't have access to the library. e.g. Put 'config.page' file to contents/ui which has something like: [Page] dataengine=weather page=defaultConfig [Params] Pressure=false Temperature=true Is this a big no no or something that could be done? Ideas how to do this 'plasma way'? Petri 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: Now playing dataengine
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1634/ --- Review request for Plasma. Summary --- This patch: * Adds ArtUrl field (e.g. webkit scriptengine cannot handle QPixmap) * Adds Url field (sometimes it's useful to know file name e.g. when there is no metadata) * Updates metadata if CAN_PROVIDE_METADATA goes up and metadata is empty. There was a concern that if it's used in a remove widget, urls are not valid. Is documentation enough for this (Not included yet)? Diffs - /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/nowplaying/nowplayingengine.cpp 1024661 /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/nowplaying/playercontainer.cpp 1024661 /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/nowplaying/playerinterface/juk.cpp 1024661 /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/nowplaying/playerinterface/juk_p.h 1024661 /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/nowplaying/playerinterface/mpris/mpris.cpp 1024661 /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/nowplaying/playerinterface/mpris/mpris_p.h 1024661 /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/nowplaying/playerinterface/player.h 1024661 /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/nowplaying/playerinterface/player.cpp 1024661 Diff: http://reviewboard.kde.org/r/1634/diff Testing --- Basic testing with 'Now Rocking' plasmoid Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Convert weather code to use KUnitConversion (kdeplasma-addons)
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1530/ --- Review request for Plasma. Summary --- Convert weather code to use KUnitConversion. Diffs - /trunk/KDE/kdeplasma-addons/applets/weather/CMakeLists.txt 1020435 /trunk/KDE/kdeplasma-addons/applets/weather/weatherapplet.h 1020435 /trunk/KDE/kdeplasma-addons/applets/weather/weatherapplet.cpp 1020435 /trunk/KDE/kdeplasma-addons/applets/weatherstation/weatherstation.h 1020435 /trunk/KDE/kdeplasma-addons/applets/weatherstation/weatherstation.cpp 1020435 /trunk/KDE/kdeplasma-addons/libs/plasmaweather/weatherconfig.h 1020435 /trunk/KDE/kdeplasma-addons/libs/plasmaweather/weatherconfig.cpp 1020435 /trunk/KDE/kdeplasma-addons/libs/plasmaweather/weatherpopupapplet.h 1020435 /trunk/KDE/kdeplasma-addons/libs/plasmaweather/weatherpopupapplet.cpp 1020435 Diff: http://reviewboard.kde.org/r/1530/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Convert weather code to use KUnitConversion (kdebase)
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1529/ --- Review request for Plasma. Summary --- Convert weather code to use KUnitConversion. Diffs - /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_bbcukmet.cpp 1020445 /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_envcan.cpp 1020445 /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_noaa.cpp 1020445 /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/weatherutils.h 1020445 /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/weatherutils.cpp 1020445 Diff: http://reviewboard.kde.org/r/1529/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Moonrise/set for time dataengine
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/680/ --- (Updated 2009-08-24 07:56:57.427556) Review request for Plasma. Changes --- Forgot this. Updated diff to latest svn. Summary --- Moonrise/set patch using new TimeSource in time dataengine. This also changes all sun and moon phase calculation code so same code can be used for all the calculations. This is too late for 4.3, but I'll post it here so it won't get lost. Diffs (updated) - /trunk/KDE/kdebase/workspace/plasma/dataengines/time/solarposition.cpp 1014903 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/solarposition.h 1014903 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/phases.cpp 1014903 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/CMakeLists.txt 1014903 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/solarsystem.h PRE-CREATION /trunk/KDE/kdebase/workspace/plasma/dataengines/time/solarsystem.cpp PRE-CREATION /trunk/KDE/kdebase/workspace/plasma/dataengines/time/time_solar_export.h 1014903 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/timesource.h 1014903 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/timesource.cpp 1014903 /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/CMakeLists.txt 1014903 /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/dataengineconsumer.h PRE-CREATION /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_bbcukmet.h 1014903 /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_bbcukmet.cpp 1014903 /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_envcan.h 1014903 /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_envcan.cpp 1014903 Diff: http://reviewboard.kde.org/r/680/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma webkit and proxy
On Thursday 06 August 2009 22:22:25 Marco Martin wrote: > On Thursday 06 August 2009, Petri Damstén wrote: > > Hi, > > > > Some time a go I converted Scripted Image plasmoid (http://www.kde- > > look.org/content/show.php/Scripted+Image?content=91749) to webkit > > scriptengine. I got this question: > > > > This plasmoid is not working if behind a proxy. Is it possible to make > > the plasmoid use the KDE proxy settings? > > > > Does Plasma::WebView handle proxy someway? > > > > Petri > > hmm, webview should use kio now so it should use the system settings as > proxy? Checked the svn log (Should have done that in the first place :-) and it seems to be new in 4.3, so probably he/she is still using < 4.3. Petri 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
plasma webkit and proxy
Hi, Some time a go I converted Scripted Image plasmoid (http://www.kde- look.org/content/show.php/Scripted+Image?content=91749) to webkit scriptengine. I got this question: This plasmoid is not working if behind a proxy. Is it possible to make the plasmoid use the KDE proxy settings? Does Plasma::WebView handle proxy someway? Petri 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: shared lib: conversion-lib in Plasma
On Monday 20 July 2009 20:44:32 Aaron J. Seigo wrote: > On Sunday 19 July 2009, Carsten Niehaus wrote: > > Moin moin > > > > > > > I don't think having such a library in kdelibs is such a bad idea, > > > > > actually. > > > > > > > > > > By policy, we usually require at least 2 users of the library > > > > > before it can be added into kdelibs. But this seems like something > > > > > worth having around in kdelibs to me. > > > > > > > > > > -Allen > > > > > > > > Besides, if it is used in some plasmoids and kalzium, then it > > > > technically meets the two user rule. > > > > > > Right. > > > So I propose putting this library through the kdereview process, with > > > the eye on moving it into kdelibs for 4.4. > > > > Ok, I am fine with that, so is Kashyap R Puranik. As this code > > originates from Plasma I would like them to move the code or give me a > > thumbs up before I move it. > > > > @Plasma-dev: Would that be ok for you? > > fine with me :) Fine with me too and if someone more experienced with module moves than me can do the move it's even better :-) Petri 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: Review Request: Moonrise/set for time dataengine
On Thursday 16 July 2009 20:25:53 Aaron Seigo wrote: > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/680/#review1627 > --- > > > has this been committed yet? No, I have been waiting comments for the time engine part of the patch. Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Unit conversion library
On Wednesday 15 July 2009 16:53:03 Carsten Niehaus wrote: > As a sideissue, kashthealien created this request six weeks ago: > > http://reviewboard.kde.org/r/779/ > > Aaron mentioned i18n()-problems, but those are not patch specific but > lib-specific. I did i18n rewrite for the lib and added density with that commit (http://websvn.kde.org/?view=rev&revision=994221) so this is shipped. Petri 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: Plasma Unit conversion library
On Tuesday 07 July 2009 20:35:18 Aaron J. Seigo wrote:
> btw ... some things that would be great to get done as well:
>
> * currency conversions using the short names, e.g. cad, usd, nko, etc ..
> typing "canadian dollar" is a little annoying ;)
Yes they are upper case now (10 CAD > € works) but lower case would be
probably better.
> * this line needs to be replaced with a KIO call:
> i(KProcess::execute(QStringList() << "kioclient" << "copy" << "--
> noninteractive" << URL << m_cache) == 0) {
kio calls crashed when library was used in runner (threading issues?) so I
have to test if it now works (code is already there it's just commented).
Petri
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: Plasma Unit conversion library
On Tuesday 07 July 2009 17:40:53 kashyap puranik wrote: > Hi, > > I have used the unit conversion library in the kde-plasma addons/libs > directory. > > I have modified the library to add an density unit conversion. > > Right now I am using it for Kalzium for unit conversion, I have it in a > separate directory under kdeedu/kalzium . > > Is there any way, this library can be shared between Plasma and Kalzium? I'm going to do a major modifications to unit conversion library because currently it cannot be properly translated to all the languages. I'll add the density after that. I'm not sure how to proceed when multiple projects in KDE start to use the same lib so I let others to answer to that. Petri 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: Review Request: Moonrise/set for time dataengine
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/680/ --- (Updated 2009-07-06 06:02:10.326719) Review request for Plasma. Changes --- Update patch to current trunk. Updates also bbc ion to use dataengine directly (if lib is better I can update the patch). Summary --- Moonrise/set patch using new TimeSource in time dataengine. This also changes all sun and moon phase calculation code so same code can be used for all the calculations. This is too late for 4.3, but I'll post it here so it won't get lost. Diffs (updated) - /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/CMakeLists.txt 992178 /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/dataengineconsumer.h PRE-CREATION /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_bbcukmet.h 992178 /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_bbcukmet.cpp 992178 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/solarsystem.h PRE-CREATION /trunk/KDE/kdebase/workspace/plasma/dataengines/time/solarsystem.cpp PRE-CREATION /trunk/KDE/kdebase/workspace/plasma/dataengines/time/time_solar_export.h 992178 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/timesource.h 992178 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/timesource.cpp 992178 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/solarposition.h 992178 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/solarposition.cpp 992178 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/CMakeLists.txt 992178 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/phases.cpp 992178 Diff: http://reviewboard.kde.org/r/680/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Cannot remove scripted plasmoid
On Thursday 18 June 2009 22:23:58 Chani wrote: > On June 18, 2009 09:15:27 Petri Damstén wrote: > > On Saturday 13 June 2009 10:10:44 Petri Damstén wrote: > > > > doh! that was in the wrong init() method (the private vs the public > > > > one) .. it's fixed now :) > > > > > > I think that X-Plasma-DefaultSize code should be still called from > > > private init, since public init is too late for that? > > yes. > > > I was a way for a while but now I had finally time to test this. Seems > > that now plasma always resizes scripted applets to default size. Could > > X-Plasma- DefaultSize code work for C++ (like in attached patch) or > > should it be in the script specific section of the code in the > > AppletPrivate::init? > > > > Petri > > c++ plasmoids have been setting default size in their constructors, so it's > probably best not to override that :) AppletPrivate::init is called from Plasma::Applet constructor so it gets run before actual Applet constructor where resize usually is? I was thinking that it could be used for C++ too for consistency but would not break existing applets. Petri 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: Cannot remove scripted plasmoid
On Saturday 13 June 2009 10:10:44 Petri Damstén wrote:
> > doh! that was in the wrong init() method (the private vs the public one)
> > .. it's fixed now :)
>
> I think that X-Plasma-DefaultSize code should be still called from private
> init, since public init is too late for that?
I was a way for a while but now I had finally time to test this. Seems that
now plasma always resizes scripted applets to default size. Could X-Plasma-
DefaultSize code work for C++ (like in attached patch) or should it be in the
script specific section of the code in the AppletPrivate::init?
Petri
Index: applet.cpp
===
--- applet.cpp (revision 983609)
+++ applet.cpp (working copy)
@@ -2278,6 +2278,14 @@
}
}
+//set a default size before any saved settings are read
+QSize size = appletDescription.property("X-Plasma-DefaultSize").toSize();
+if (size.isEmpty()) {
+size = QSize(200, 200);
+}
+//kDebug() << "size" << size;
+q->resize(size);
+
q->setBackgroundHints(Applet::DefaultBackground);
q->setHasConfigurationInterface(true); //FIXME why not default it to true in the constructor?
@@ -2318,15 +2326,6 @@
if (!package->filePath("mainconfigui").isEmpty()) {
q->setHasConfigurationInterface(true);
}
-
-//set a default size before any saved settings are read
-QSize size = appletDescription.property("X-Plasma-DefaultSize").toSize();
-if (size.isEmpty()) {
-size = QSize(200,200);
-}
-
-//kDebug() << "size" << size;
-q->resize(size);
}
QString AppletPrivate::globalName() const
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: Cannot remove scripted plasmoid
On Friday 12 June 2009 18:21:30 Aaron J. Seigo wrote: > On Friday 12 June 2009, Petri Damstén wrote: > > On Thursday 11 June 2009 18:43:39 Aaron J. Seigo wrote: > > > great; we still need to fix the plasmoid (or the python scriptengine, > > > which is broken) but it's good to know we can handle these situations > > > with some robustness at least. > > > > Seems that the problem is in Plasma::AppletPrivate::setupScriptSupport > > which calls config. > > doh! that was in the wrong init() method (the private vs the public one) .. > it's fixed now :) I think that X-Plasma-DefaultSize code should be still called from private init, since public init is too late for that? Petri 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: Cannot remove scripted plasmoid
On Thursday 11 June 2009 18:43:39 Aaron J. Seigo wrote: > great; we still need to fix the plasmoid (or the python scriptengine, which > is broken) but it's good to know we can handle these situations with some > robustness at least. Seems that the problem is in Plasma::AppletPrivate::setupScriptSupport which calls config. plasmoidviewer backtrace with breakpoint at kDebug() << "requesting config for" << q->name() << "without a containment!"; #0 Plasma::AppletPrivate::mainConfigGroup (this=0xb0d000) at /home/damu/Development/src/kdelibs/plasma/applet.cpp:2396 #1 0x7fde2b547d39 in Plasma::Applet::config (this=0x7fde28d69528) at /home/damu/Development/src/kdelibs/plasma/applet.cpp:392 #2 0x7fde2b54b3e1 in Plasma::AppletPrivate::setupScriptSupport (this=0xb0d000) at /home/damu/Development/src/kdelibs/plasma/applet.cpp:2306 #3 0x7fde2b54e0af in Plasma::AppletPrivate::init (this=0xb0d000, packagePath=) at /home/damu/Development/src/kdelibs/plasma/applet.cpp:2269 #4 0x7fde2b54ee19 in Applet (this=0xa76020, parentObject=0x0, ar...@0x7fff340fd340) at /home/damu/Development/src/kdelibs/plasma/applet.cpp:156 #5 0x7fde2b54f65c in Plasma::Applet::load (appletna...@0x7fff340fdc10, appletId=, args=) at /home/damu/Development/src/kdelibs/plasma/applet.cpp:1924 #6 0x7fde2b55e216 in Plasma::ContainmentPrivate::addApplet (this=0xb2bc90, na...@0x7fff340fdc10, ar...@0x7fff340fda30, appletgeomet...@0x7fff340fd5c0, id=0, delayInit=false) at /home/damu/Development/src/kdelibs/plasma/containment.cpp:1821 #7 0x0040645a in FullView::addApplet (this=0x7fff340fd890, na...@0x7fff340fdc10, containme...@0xa78bf0, wallpaper=, ar...@0x7fff340fda30) at /home/damu/Development/src/kdebase/workspace/plasma/shells/plasmoidviewer/fullview.cpp:114 #8 0x00408af1 in main (argc=2, argv=0x7fff340fe358) at /home/damu/Development/src/kdebase/workspace/plasma/shells/plasmoidviewer/main.cpp:158 Petri 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: Fix flexible size of panel spacer
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/825/ --- Review request for Plasma. Summary --- Do setSizePolicy in constraintEvent so flexible size works (tasks applet does this similar way). Diffs - /trunk/KDE/kdebase/workspace/plasma/applets/panelspacer/panelspacer.cpp 980183 Diff: http://reviewboard.kde.org/r/825/diff Testing --- Screenshots --- Current http://reviewboard.kde.org/r/825/s/128/ After patch http://reviewboard.kde.org/r/825/s/129/ Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Initial size of scripted plasmoids
On Wednesday 10 June 2009 19:03:35 Aaron J. Seigo wrote:
> On Wednesday 10 June 2009, Petri Damstén wrote:
> > But isn't this too late because plasma sets size before init and it
> > resets the user set size? Is there a proper way to set initial size for
> > scripted applets or should applet just accept the initial size plasma
> > sets.
>
> put X-Plasma-DefaultSize= in your metadata.desktop file.
Patch to use X-Plasma-DefaultSize in ruby and python examples. ok to commit?
Petri
Index: python/examples/applets/pyclock/metadata.desktop
===
--- python/examples/applets/pyclock/metadata.desktop (revision 980109)
+++ python/examples/applets/pyclock/metadata.desktop (working copy)
@@ -63,6 +63,7 @@
Icon=chronometer
X-Plasma-API=python
X-Plasma-MainScript=code/main.py
+X-Plasma-DefaultSize=125,125
X-KDE-PluginInfo-Author=Simon Edwards
x-kde-plugininfo-email=si...@simonzone.com
Index: python/examples/applets/pyclock/contents/code/main.py
===
--- python/examples/applets/pyclock/contents/code/main.py (revision 980109)
+++ python/examples/applets/pyclock/contents/code/main.py (working copy)
@@ -50,7 +50,6 @@
KGlobal.locale().insertCatalog("libplasmaclock")
self.setHasConfigurationInterface(True)
-self.resize(125, 125)
self.setAspectRatioMode(Plasma.Square)
self.timezone = ""
Index: ruby/examples/applets/webapplet/metadata.desktop
===
--- ruby/examples/applets/webapplet/metadata.desktop (revision 980109)
+++ ruby/examples/applets/webapplet/metadata.desktop (working copy)
@@ -72,3 +72,4 @@
X-KDE-PluginInfo-EnabledByDefault=true
X-Plasma-API=ruby-script
X-Plasma-MainScript=code/main.rb
+X-Plasma-DefaultSize=600,400
Index: ruby/examples/applets/webapplet/contents/code/main.rb
===
--- ruby/examples/applets/webapplet/contents/code/main.rb (revision 980109)
+++ ruby/examples/applets/webapplet/contents/code/main.rb (working copy)
@@ -41,8 +41,6 @@
end
def init
-resize(600, 400)
-
@page = Plasma::WebView.new(self)
@page.page = Qt::WebPage.new(@page)
@page.page.linkDelegationPolicy = Qt::WebPage::DelegateAllLinks
Index: ruby/examples/applets/clock/metadata.desktop
===
--- ruby/examples/applets/clock/metadata.desktop (revision 980109)
+++ ruby/examples/applets/clock/metadata.desktop (working copy)
@@ -124,6 +124,7 @@
ServiceTypes=Plasma/Applet
X-Plasma-API=ruby-script
X-Plasma-MainScript=code/main.rb
+X-Plasma-DefaultSize=125,125
X-KDE-PluginInfo-Author=Richard Dale
x-kde-plugininfo-email=richard.j.d...@gmail.com
Index: ruby/examples/applets/clock/contents/code/main.rb
===
--- ruby/examples/applets/clock/contents/code/main.rb (revision 980109)
+++ ruby/examples/applets/clock/contents/code/main.rb (working copy)
@@ -40,7 +40,6 @@
KDE::Global.locale.insertCatalog("libplasmaclock")
setHasConfigurationInterface(true)
-resize(125, 125)
setAspectRatioMode(Plasma::Square)
@theme = Plasma::Svg.new(self)
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: Cannot remove scripted plasmoid
On Wednesday 10 June 2009 20:30:36 Aaron J. Seigo wrote: > On Wednesday 10 June 2009, Aaron J. Seigo wrote: > > we should still catch such mistakes gracefully, however. does the > > attached patch help? > > that patch could be hazardous to your health. try the attached one instead > as it actually works. Yes, this works. Petri 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
Initial size of scripted plasmoids
Hi, C++ applets do resize on constructor which work ok. Scripted plasmoids cannot do that and examples do that in init: def init(self): self.resize(200, 200) But isn't this too late because plasma sets size before init and it resets the user set size? Is there a proper way to set initial size for scripted applets or should applet just accept the initial size plasma sets. Petri 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: Cannot remove scripted plasmoid
On Friday 05 June 2009 09:05:58 Petri Damstén wrote: > On Thursday 04 June 2009 22:17:54 Aaron J. Seigo wrote: > > define "removing": removing from plasma by click on the "x" in the handle > > (or "Remove this..." in the context menu)? removing from disk with > > plasmapkg? removing via the add widgets gui? . inquiring minds want > > to know! ;) > > > > (if it's the 'x' or "Remove this" from in plasma, then attach a plasma- > > desktop-applets rc file after doing a kquitapp plasma-desktop) > > I'll try to be more precise. Steps used to produce attached plasma-desktop- > appletsrc: > - Removed ~/.kde from test user > - Start new session > - Install now-rocking widget > - Add it to desktop > - restart plasma -> everything ok > - remove desktop folder and now-rocking from desktop using 'x' > - restart plasma > - now-rocking applet is back on desktop, desktop folder isn't > > Seems that now-rocking is still in plasma-desktop-appletsrc. Seems that this is because mainConfig is created without containment: plasma-desktop(1574)/libplasma Plasma::AppletPrivate::mainConfigGroup: requesting config for "Now Rocking" without a containment! Because of this KConfig::deleteGroupImpl tries to delete [Applets][10] and not [Containments][1][Applets][10] as it should. Petri 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: Cannot remove scripted plasmoid
On Thursday 04 June 2009 22:17:54 Aaron J. Seigo wrote: > define "removing": removing from plasma by click on the "x" in the handle > (or "Remove this..." in the context menu)? removing from disk with > plasmapkg? removing via the add widgets gui? . inquiring minds want to > know! ;) > > (if it's the 'x' or "Remove this" from in plasma, then attach a plasma- > desktop-applets rc file after doing a kquitapp plasma-desktop) I'll try to be more precise. Steps used to produce attached plasma-desktop- appletsrc: - Removed ~/.kde from test user - Start new session - Install now-rocking widget - Add it to desktop - restart plasma -> everything ok - remove desktop folder and now-rocking from desktop using 'x' - restart plasma - now-rocking applet is back on desktop, desktop folder isn't Seems that now-rocking is still in plasma-desktop-appletsrc. Testing was done with latest kubuntu beta packages 4.2.90 but it seems to happen in my desktop with latest svn too. Petri [Containments][1] activity= desktop=-1 formfactor=0 geometry=0,0,1024,768 immutability=1 location=0 plugin=desktop screen=0 wallpaperplugin=image wallpaperpluginmode=SingleImage zvalue=0 [Containments][1][Applets][10] geometry=624,20,300,350 immutability=1 plugin=now-rocking zvalue=0 [Containments][1][Wallpaper][image] slideTimer=10 slidepaths=/opt/kde-svn/share/wallpapers/ userswallpapers= wallpaper=/opt/kde-svn/share/wallpapers/Air wallpapercolor=56,111,150 wallpaperposition=0 [Containments][3] activity= desktop=-1 formfactor=2 geometry=0,-41,1024,35 immutability=1 location=4 plugin=panel screen=0 zvalue=150 [Containments][3][Applets][4] geometry=0,3,32,32 immutability=1 plugin=launcher zvalue=0 [Containments][3][Applets][4][Shortcuts] global=Alt+F1 [Containments][3][Applets][5] geometry=36,3,32,32 immutability=1 plugin=notifier zvalue=0 [Containments][3][Applets][6] geometry=72,3,22,32 immutability=1 plugin=pager zvalue=0 [Containments][3][Applets][7] geometry=98,3,772,32 immutability=1 plugin=tasks zvalue=0 [Containments][3][Applets][8] geometry=874,3,60,32 immutability=1 plugin=systemtray zvalue=0 [Containments][3][Applets][8][Configuration][ExtenderItems][1] extenderIconName= extenderItemName=jobGroup extenderItemPosition=0 extenderTitle= isCollapsed=false isGroup=true sourceAppletId=8 sourceAppletPluginName=systemtray [Containments][3][Applets][8][Configuration][ExtenderItems][2] extenderIconName= extenderItemName=completedJobsGroup extenderItemPosition=0 extenderTitle=0 Recently Completed Jobs: groupCollapsed=false isCollapsed=false isGroup=true sourceAppletId=8 sourceAppletPluginName=systemtray [Containments][3][Applets][8][PopupApplet] DialogHeight=8 DialogWidth=0 [Containments][3][Applets][9] geometry=938,3,64,32 immutability=1 plugin=digital-clock zvalue=0 [Containments][3][Applets][9][Configuration][ExtenderItems][3] extenderIconName=view-pim-calendar extenderItemName=calendar extenderItemPosition=0 extenderTitle=Calendar isCollapsed=false sourceAppletId=9 sourceAppletPluginName=digital-clock [Containments][3][Configuration] maximumSize=1024,35 minimumSize=1024,35 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
Cannot remove scripted plasmoid
Hi, Played with python plasmoids again. When removed they seem to be getting back at plasma restart. Then I tested with javascript plasmoid which also comes back (At the same restart C++ plasmoid was removed correctly). Any ideas what might be wrong here? Plasmoids used in testing: http://kotisivu.lumonetti.fi/damu0/misc/now-rocking.plasmoid (this is work in progress...) http://www.kde-look.org/content/show.php/Label?content=99881 Petri 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: Review Request: Density unit conversion
On Tuesday 02 June 2009 20:34:01 Aaron J. Seigo wrote: > On Tuesday 02 June 2009, Petri Damstén wrote: > > I have plans to make translation better in 4.4. I guess singular, plural > > strings should be a one KLocalizedString but I'm not sure if it can be > > used that way? > > afaik, yes. and it's in fact necessary to do translations correctly at all > since some languages have different plurals for 2, 3, 10, etc.. > > > Singular, plural are also needed as QStrings in a list so they > > can be matched against user given string in conversion runner. > > hm... this will run into the same problem; we should ask the i18n people > how we could get this information out of the system (unique plural strings > for the current language) ok, this is on my todo list I'll get back to this later. Petri 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: Review Request: Density unit conversion
On Tuesday 02 June 2009 18:44:31 Aaron Seigo wrote:
> in the meantime, the i18n here looks very wrong. shouldn't it be:
>
> i18np("density unit", "ounce per cubic foot", "ounces per cubit foot", ..)?
No, currently unit takes arguments as (singular, plural, symbol, ...
> i seem to recall the translators being very unhappy with the conversion
> lib, and this is likely why ;) since there's a good amount of time to work
> on this between now and 4.4, how about creating a branch in svn to do this
> work, commit your patch (with the fixed yard -> foot thing) to that branch
> and then work on fixing the i18n? when 4.4 opens you can then merge the
> entire set of changes over into trunk/.
I have plans to make translation better in 4.4. I guess singular, plural
strings should be a one KLocalizedString but I'm not sure if it can be used
that way? Singular, plural are also needed as QStrings in a list so they can
be matched against user given string in conversion runner.
Petri
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
Translating scripted applets
Hi,
Continuing testing python applets and trying to get translations working. I
tried contents/locale/fi/LC_MESSAGES/pluginname.mo but it didn't work before I
added following code. Is this correct fix or should I use something else for
po file names?
Petri
Index: applet.cpp
@@ -2271,6 +2275,7 @@
//FIXME: we should _probably_ use a KComponentData to segregate the
applets
// from each other; but I want to get the basics working first
:)
KGlobal::dirs()->addResourceDir("locale", translationsPath);
+KGlobal::locale()->insertCatalog(package->metadata().pluginName());
}
QString xmlPath = package->filePath("mainconfigxml");
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: Python Applet and configChanged
On Wednesday 27 May 2009 18:39:14 Richard Dale wrote: > As well as your patch don't we need a 'do nothing' default > implemtation of configChanged()? Yes, that's true. Committed patch with this addition. Petri 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: Python Applet and configChanged
On Tuesday 26 May 2009 21:05:02 Aaron J. Seigo wrote: > On Tuesday 26 May 2009, Petri Damstén wrote: > > Yes, seems to be called only once now. I think it still gets called when > > Cancel is pressed if configLoader == 0? > > this should be better in trunk now. testing with the javascript > Plasma::ScriptEngine i'm only getting configChanged calls when the config > actually changes now. huzzah for that. Works with python applet too. Is it ok to commmit configChanged() patch to pyappletscript.py? Petri 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: Python Applet and configChanged
On Tuesday 26 May 2009 16:19:39 Aaron J. Seigo wrote:
> right, we probably don't need the applet to also say the config has changed
> if (but only if!) we have a config loader, so something like this in
> AppletPrivate::configDialogFinished():
>
> if (!configLoader) {
> // manually call configChanged, otherwise let the loader do that for us
> q->configChanged();
> }
>
> does that fix it for you properly?
Yes, seems to be called only once now. I think it still gets called when
Cancel is pressed if configLoader == 0?
Petri
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
Python Applet and configChanged
Hi,
Testing python applet and noticed that configChanged is not forwarded to
python applets (attached diff).
Currently configChanged is called multiple times at start and at config dialog
close. Should Plasma take care of calling configChanged just once in these
situations?
plasmoidviewer with python applet start (configChanged called 4 times):
main.py __init__
main.py init
main.py constraintsEvent
main.py constraintsEvent
main.py constraintsEvent
plasmoidviewer(18498) KCoreConfigSkeleton::writeConfig:
plasmoidviewer(18498)/libplasma Plasma::Applet::configChanged: KConfigSkeleton
main.py configChanged
plasmoidviewer(18498) KCoreConfigSkeleton::writeConfig:
plasmoidviewer(18498)/libplasma Plasma::Applet::configChanged: KConfigSkeleton
main.py configChanged
main.py constraintsEvent
plasmoidviewer(18498) KCoreConfigSkeleton::writeConfig:
plasmoidviewer(18498)/libplasma Plasma::Applet::configChanged: KConfigSkeleton
main.py configChanged
plasmoidviewer(18498) KCoreConfigSkeleton::writeConfig:
plasmoidviewer(18498)/libplasma Plasma::Applet::configChanged: KConfigSkeleton
main.py configChanged
config dialog ok pressed after changing data (configChanged called 3 times):
plasmoidviewer(18498) KCoreConfigSkeleton::writeConfig:
plasmoidviewer(18498)/libplasma Plasma::Applet::configChanged: KConfigSkeleton
main.py configChanged
plasmoidviewer(18498)/libplasma Plasma::AppletPrivate::configDialogFinished:
plasmoidviewer(18498)/libplasma Plasma::Applet::configChanged: KConfigDialog
main.py configChanged
plasmoidviewer(18498)/libplasma Plasma::AppletPrivate::configDialogFinished:
plasmoidviewer(18498)/libplasma Plasma::Applet::configChanged: KConfigDialog
main.py configChanged
Petri
Index: python/pyappletscript.py
===
--- python/pyappletscript.py (revision 972647)
+++ python/pyappletscript.py (working copy)
@@ -40,7 +40,7 @@
# on either; it might have been changed in the module itself)
self.m_moduleName = str(self.applet().pluginName())
#print("pluginname: " + str(self.applet().pluginName()))
-
+
self.plugin_name = str(self.applet().pluginName()).replace('-','_')
PythonAppletScript.importer.register_top_level(self.plugin_name, str(self.applet().package().path()))
@@ -74,6 +74,11 @@
#print("Script: showConfigurationInterface")
self.pyapplet.showConfigurationInterface()
+def configChanged(self):
+if not self.initialized:
+return
+self.pyapplet.configChanged()
+
def paintInterface(self, painter, option, contentsRect):
if not self.initialized:
return
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: Review Request: Fix the 0600GMT=sunrise, 1800GMT=sunset bug in the BBC Weather Ion
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/684/#review1147
---
Would it have been easier to just use time datengine? There is code in
libplasmaweather that determines if it's day and it's just two lines:
Plasma::DataEngine::Data data = timeEngine->query(
QString("Local|Solar|Latitude=%1|Longitude=%2").arg(latitude).arg(longitude));
bool day = (data["Corrected Elevation"].toDouble() > 0.0);
Dataengines don't support calling other dataengines like wallpapers and applets
do, but a copy of dataengineconsumer_p.h should take care of that (Could this
be a public header?). Also if moon rise/set (http://reviewboard.kde.org/r/680/)
gets in at some point it would not need any changes in weather ions if time
dataengine is used.
- Petri
On 2009-05-15 15:59:05, Andrew Coles wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/684/
> ---
>
> (Updated 2009-05-15 15:59:05)
>
>
> Review request for Plasma.
>
>
> Summary
> ---
>
> To give an icon depicting the current weather, the BBC UK Met. Office backend
> decides whether or not it is day or night using a simple rule: if it's after
> 0600GMT but before 1800GMT, it is daytime; otherwise, it's night time. This
> causes two known issues:
>
> i) For people in the UK, the weather icons indicate night even though sunset
> is not until well after 2000GMT at this time of year
> ii) For people outside the UK, day and night are set to an approximation of
> what they are in the UK. So, for instance, for people in New York, the
> weather icon goes to night at lunchtime.
>
> The attached diff fixes this bug by calculating the actual sunrise/sunset
> times for the weather location, and using /these/ to decide whether it's day
> or night. How is this done? Whilst the BBC don't provide sunrise/sunset
> time in the current observations, they do provide latitude and longitude
> information. Given we know:
>
> i) The date
> ii) The latitude/longitude
>
> ...we can then calculate sunrise and sunset times using a bit of maths. If
> you look, the diffs for the ion itself are very small: just enough to handle
> the lat/long information, and then calls to sunrise/sunset calculation to
> decide whether it's day or night. This code has been reused from the time
> DataEngine - so we're not importing lots of new code at this point.
>
>
> Diffs
> -
>
> /trunk/KDE/kdebase/workspace/plasma/dataengines/time/CMakeLists.txt 968518
> /trunk/KDE/kdebase/workspace/plasma/dataengines/time/solarposition.h 968518
> /trunk/KDE/kdebase/workspace/plasma/dataengines/time/time_solar_export.h
> PRE-CREATION
> /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/CMakeLists.txt
> 968518
> /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_bbcukmet.h
> 968518
>
> /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_bbcukmet.cpp
> 968518
>
> Diff: http://reviewboard.kde.org/r/684/diff
>
>
> Testing
> ---
>
> I use the BBC weather ion for my weather data, so I tested it for my current
> location (fine) and a few others from around the world (also fine). Has been
> fine for well over a week, becoming increasingly more useful as sunset pushes
> towards 10pm.
>
>
> Thanks,
>
> Andrew
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: battery plasmoid and remaining time..
On Thursday 14 May 2009 12:13:22 Aaron J. Seigo wrote: > let me close with an example from the world of automobiles: ever notice how > fuel gages show "how much is left in your tank" versus "how many kilometers > you have left to go"? think about it. this is the exact same issue. now, > either car manufacturers are simply overlooking an obviously great feature > that would be trivial to implement in today's cars or we're doing something > really stupid here. > > i'm guessing car manufacturers realize that it's safer to let the user > guess based on the readout of the fuel level, their expected use of the car > and their experience with that vehicle than leave people stranded and > surprised because the car said it had 10 more kliks right before hitting an > uphill incline. I think I have seen several cars that estimate kilometers left with the current tank, like Volvo: http://www.c30world.com/forums/showthread.php?t=6390 but pictures show that not without problems... Petri 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: Review Request: Fix the 0600GMT=sunrise, 1800GMT=sunset bug in the BBC Weather Ion
> On 2009-05-09 18:03:39, Aaron Seigo wrote: > > what version of the GPL is it licensed under? the source code you got this > > from doesn't say... that would need to be clarified. also, is there overlap > > here with the sun/moon calcs in the time engine? Yes, it does the same calculations that time engine does. weatherlib/lcd weather uses time engine to do day/night for sources that don't have condition icon at all, but I guess this could be done also in dataengine. Can dataengines use other dataengines? - Petri --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/684/#review1100 --- On 2009-05-09 16:41:15, Andrew Coles wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/684/ > --- > > (Updated 2009-05-09 16:41:15) > > > Review request for Plasma. > > > Summary > --- > > To give an icon depicting the current weather, the BBC UK Met. Office backend > decides whether or not it is day or night using a simple rule: if it's after > 0600GMT but before 1800GMT, it is daytime; otherwise, it's night time. This > causes two known issues: > > i) For people in the UK, the weather icons indicate night even though sunset > is not until well after 2000GMT at this time of year > ii) For people outside the UK, day and night are set to an approximation of > what they are in the UK. So, for instance, for people in New York, the > weather icon goes to night at lunchtime. > > The attached diff fixes this bug by calculating the actual sunrise/sunset > times for the weather location, and using /these/ to decide whether it's day > or night. How is this done? Whilst the BBC don't provide sunrise/sunset > time in the current observations, they do provide latitude and longitude > information. Given we know: > > i) The date > ii) The latitude/longitude > > ...we can then calculate sunrise and sunset times using a bit of maths. If > you look, the diffs for the ion itself are very small: just enough to handle > the lat/long information, and then calls to sunrise/sunset calculation to > decide whether it's day or night. The sunrise/sunset calculation - existing > mature GPLed code - has been put into weatherutils.h/.cpp, as other ions may > need this information too. > > > Diffs > - > > /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_bbcukmet.h > 965571 > > /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_bbcukmet.cpp > 965571 > /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/weatherutils.h > 965571 > > /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/weatherutils.cpp > 965571 > > Diff: http://reviewboard.kde.org/r/684/diff > > > Testing > --- > > I use the BBC weather ion for my weather data, so I tested it for my current > location (fine) and a few others from around the world (also fine). > > > Thanks, > > Andrew > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Moonrise/set for time dataengine
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/680/ --- (Updated 2009-05-10 03:41:26.842682) Review request for Plasma. Changes --- Updated diff with on demand allocation of sun and moon. Summary --- Moonrise/set patch using new TimeSource in time dataengine. This also changes all sun and moon phase calculation code so same code can be used for all the calculations. This is too late for 4.3, but I'll post it here so it won't get lost. Diffs (updated) - /trunk/KDE/kdebase/workspace/plasma/dataengines/time/CMakeLists.txt 965999 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/phases.cpp 965999 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/solarposition.h 965999 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/solarposition.cpp 965999 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/solarsystem.h PRE-CREATION /trunk/KDE/kdebase/workspace/plasma/dataengines/time/solarsystem.cpp PRE-CREATION /trunk/KDE/kdebase/workspace/plasma/dataengines/time/timeengine.cpp 965999 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/timesource.h 965999 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/timesource.cpp 965999 Diff: http://reviewboard.kde.org/r/680/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Moonrise/set for time dataengine
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/680/ --- Review request for Plasma. Summary --- Moonrise/set patch using new TimeSource in time dataengine. This also changes all sun and moon phase calculation code so same code can be used for all the calculations. This is too late for 4.3, but I'll post it here so it won't get lost. Diffs - /trunk/KDE/kdebase/workspace/plasma/dataengines/time/CMakeLists.txt 965523 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/phases.cpp 965523 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/solarposition.h 965523 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/solarposition.cpp 965523 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/solarsystem.h PRE-CREATION /trunk/KDE/kdebase/workspace/plasma/dataengines/time/solarsystem.cpp PRE-CREATION /trunk/KDE/kdebase/workspace/plasma/dataengines/time/timeengine.cpp 965523 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/timesource.h 965523 /trunk/KDE/kdebase/workspace/plasma/dataengines/time/timesource.cpp 965523 Diff: http://reviewboard.kde.org/r/680/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: moved moonphase code to time dataengine.
On Monday 27 April 2009 11:09:45 Petri Damstén wrote: > I have made moonrise / moonset calculation to the code. There is also moon > phase there (phase calculation seems simple after sun and moon values for > rise / set are calculated). Currently phase is 0.0 - 1.0 (0.5 meaning full > moon). How should we continue from here? So is it ok to commit moon rise / set / phase? My plan was to make rise /set calculation but if I understood it correctly phase is just one line of code after that so I added it too. Petri 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: Review Request: moved moonphase code to time dataengine.
On Monday 27 April 2009 02:31:48 Davide Bettio wrote:
> moved moonphase code to time dataengine from luna plasmoid/moonphase kicker
> applet (as requested by petri). phases.cpp is missing but it comes from the
> plasmoid.
I have made moonrise / moonset calculation to the code. There is also moon
phase there (phase calculation seems simple after sun and moon values for rise
/ set are calculated). Currently phase is 0.0 - 1.0 (0.5 meaning full moon).
How should we continue from here?
Petri
Index: timeengine.cpp
===
--- timeengine.cpp (revision 959786)
+++ timeengine.cpp (working copy)
@@ -106,7 +106,7 @@
// this is relatively cheap - KSTZ::local() is cached
timezone = KSystemTimeZones::local().name();
} else {
-KTimeZone newTz = KSystemTimeZones::zone(tz);
+KTimeZone newTz = KSystemTimeZones::zone(timezone);
if (!newTz.isValid()) {
return false;
}
@@ -118,7 +118,7 @@
QString trTimezone = i18n(timezone.toUtf8());
data[I18N_NOOP("Timezone")] = trTimezone;
-
+
QStringList tzParts = trTimezone.split("/");
data[I18N_NOOP("Timezone Continent")] = tzParts.value(0);
data[I18N_NOOP("Timezone City")] = tzParts.value(1);
@@ -126,7 +126,8 @@
if (args.count() > 0) {
static const QString latitude = I18N_NOOP("Latitude");
static const QString longitude = I18N_NOOP("Longitude");
-
+bool sun = false, moon = false;
+
data[latitude] = args[latitude].toDouble();
data[longitude] = args[longitude].toDouble();
QDateTime dt = QDateTime::fromString(args[I18N_NOOP("DateTime")], Qt::ISODate);
@@ -137,10 +138,16 @@
data[I18N_NOOP("Time")] = dt.time();
}
if (args.contains(I18N_NOOP("Solar"))) {
+sun = true;
+}
+if (args.contains(I18N_NOOP("Lunar"))) {
+moon = true;
+}
+if (sun || moon) {
if (!solarPosition) {
solarPosition = new SolarPosition;
}
-solarPosition->appendData(data);
+solarPosition->appendData(data, sun, moon);
}
if (args.contains(I18N_NOOP("Moon"))) {
appendMoonphase(data);
Index: solarposition.cpp
===
--- solarposition.cpp (revision 959786)
+++ solarposition.cpp (working copy)
@@ -20,48 +20,106 @@
#include
/*
- * This class is ported from public domain javascript code:
+ * Mathematics, ideas, public domain code used for these classes from:
+ * http://www.stjarnhimlen.se/comp/tutorial.html
+ * http://www.stjarnhimlen.se/comp/riset.html
* http://www.srrb.noaa.gov/highlights/solarrise/azel.html
* http://www.srrb.noaa.gov/highlights/sunrise/sunrise.html
- * Calculation details:
- * http://www.srrb.noaa.gov/highlights/sunrise/calcdetails.html
+ * http://bodmas.org/astronomy/riset.html
+ * moontool.c by John Walker
+ * Wikipedia
*/
-class NOAASolarCalc
+class SolarSystemObject
{
public:
-static void calc(const QDateTime &dt, double longitude, double latitude,
- double zone, double *jd, double *century, double *eqTime,
- double *solarDec, double *azimuth, double *zenith);
-static double radToDeg(double angleRad);
-static double degToRad(double angleDeg);
-static double calcJD(double year, double month, double day);
-static QDateTime calcDateFromJD(double jd, double minutes, double zone);
-static double calcTimeJulianCent(double jd);
-static double calcJDFromJulianCent(double t);
-static double calcGeomMeanLongSun(double t);
-static double calcGeomMeanAnomalySun(double t);
-static double calcEccentricityEarthOrbit(double t);
-static double calcSunEqOfCenter(double t);
-static double calcSunTrueLong(double t);
-static double calcSunTrueAnomaly(double t);
-static double calcSunRadVector(double t);
-static double calcSunApparentLong(double t);
-static double calcMeanObliquityOfEcliptic(double t);
-static double calcObliquityCorrection(double t);
-static double calcSunRtAscension(double t);
-static double calcSunDeclination(double t);
-static double calcEquationOfTime(double t);
-static void calcAzimuthAndZenith(QDateTime now, double eqTime, double zone,
- double solarDec, double latitude, double longitude,
- double *zenith, double *azimuth);
-static double calcElevation(double zenith);
-static double calcHourAngle(double zenith, double solarDec, double latitude);
-static void calcTimeUTC(double zenith, bool rise, double *jd, double *minutes,
- double latit
Re: [PATCH] Don't create multiple busy widgets
On Wednesday 15 April 2009 12:40:38 Marco Martin wrote: > On Wednesday 15 April 2009, Petri Damstén wrote: > > Hi, > > > > Patch to check if widget is already busy. > > > > Petri > > this was really a wooops :) And I forgot to update my kdelibs. Aaron already fixed this in #954122 :-) Petri 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
[PATCH] Don't create multiple busy widgets
Hi,
Patch to check if widget is already busy.
Petri
Index: applet.cpp
===
--- applet.cpp (revision 953617)
+++ applet.cpp (working copy)
@@ -670,6 +670,9 @@
void Applet::setBusy(bool busy)
{
if (busy) {
+if (isBusy()) {
+return;
+}
d->createMessageOverlay(false);
d->messageOverlay->opacity = 0;
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: Review Request: Add city and country resolution to GPS geolocation data using geonames.
> On 2009-04-14 18:59:59, Aaron Seigo wrote: > > other than a couple of code style comments, and that i can't test it with a > > gps for you either :/, my only question/concern is that it's doing look ups > > on the internet without checking to see if we're connected. it could be in > > a local cache, but i'm going to guess that in a fairly typical "i'm using > > gps" scenario one won't have an internet connection as well. should we > > query solid for network status? > > > > rambling off-topic here: i also wonder if we aren't going to want some "can > > use the internet for ..." settings somewhere for the case where we have a > > system with gps, cheap wifi and expensive g3 connectivity .. somethings, > > like looking up the place name on the internet, may not be acceptible even > > if there is g3 service? not a use case we actually have to deal with now, > > but it's something that pops into my head every once in a while .. .. like > > when i see a patch like this :) Dataengine already checks network state but since it thinks gps does not need one it uses gps plugin. I think location -> place should be a separate plugin. It's not possible with current code though and I would like to evaluate all the other possibilities before doing rewrite (there were some wlan etc ideas as well). For 4.3 should it go like this, I'm not sure? For 4.4 is geoclue out of the question? It seems that we are implementing pretty much all the same things. - Petri --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/592/#review923 --- On 2009-04-14 16:46:26, Andrew Coles wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/592/ > --- > > (Updated 2009-04-14 16:46:26) > > > Review request for Plasma. > > > Summary > --- > > Yesterday, I proposed a patch for using an IP geolocation service that > returns longitude and latitude, as the GPS backend would give that data but > the IP one would not. Today, it's the other way around: a patch to add place > name and country information to the GPS geolocation data, as the IP > geolocation gives this but GPS geolocation does not. > > The only caveat is that I'm programming blind - I don't have a GPS receiver, > and 'it compiles' is far from good enough. Hence, I need a volunteer to test > it - anyone? > > Assuming it works, the geolocation data engine will then have reached the > point where the fields returned are identical, /irregardless of whether IP or > GPS data is used/. Specifically, the user gets: > > - Latitude > - Longitude > - Accuracy > - Country Name > - Country Code > - City Name > > > Diffs > - > > /trunk/kdereview/plasma/dataengines/geolocation/location_gps.h 954031 > /trunk/kdereview/plasma/dataengines/geolocation/location_gps.cpp 954031 > > Diff: http://reviewboard.kde.org/r/592/diff > > > Testing > --- > > It compiles, and it looks alright. How pitiful is that? Given it's based on > the IP geolocation XML code, but using a reverse geocoding rather than IP > geolocation service, it should in theory work, but it really does need > testing by someone with a GPS unit. > > > Thanks, > > Andrew > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Use libplasmaweather in Weather Wallpaper
> On 2009-04-14 16:22:53, Jonathan Thomas wrote: > > Ooh, looks great! This port is greatly appreciated. Before, setting a new > > location after you set the first one didn't work at all. Now it works, > > unless you set a different location, then try to go back to your old > > location. (E.G. Set to manchester, new hampshire -> Hit OK (everything > > works), set it to a different location (say, San Francisco, California) -> > > hit OK (everything still works). But then, trying to go back to manchester, > > the wallpaper still stays at the one for San Francisco. This is, however, > > better than it used to be by far. :) > > > > Also, I assume later that I can manually add a button to WeatherConfig's > > layout so that I can reach the advanced setting for the wallpaper, correct? > > > > Thanks again! Yes, layout of the widget is accessible with QWidget::layout(). - Petri --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/589/#review922 --- On 2009-04-14 14:28:46, Petri Damstén wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/589/ > --- > > (Updated 2009-04-14 14:28:46) > > > Review request for Plasma. > > > Summary > --- > > Use libplasmaweather WeatherConfig widget in Weather Wallpaper. > > > Diffs > - > > /trunk/KDE/kdeplasma-addons/wallpapers/weather/CMakeLists.txt 953924 > /trunk/KDE/kdeplasma-addons/wallpapers/weather/weatherAddPlace.ui 953924 > /trunk/KDE/kdeplasma-addons/wallpapers/weather/weatherLocations.ui 953924 > /trunk/KDE/kdeplasma-addons/wallpapers/weather/weatherwallpaper.h 953924 > /trunk/KDE/kdeplasma-addons/wallpapers/weather/weatherwallpaper.cpp 953924 > > Diff: http://reviewboard.kde.org/r/589/diff > > > Testing > --- > > > Thanks, > > Petri > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Use libplasmaweather in Weather Wallpaper
On Wednesday 15 April 2009 01:02:53 Andrew Coles wrote: > i) Geolocation is compulsary, so if it uses IP localisation I'll get the > weather for 200 miles away. A manual override would be useful (i.e. the > old behaviour). It only tries gets the location if source is not configured. User can configure it manually like before. > ii) The GPS geolocation backend doesn't return a city name, only lat/long > data. Can libplasmaweather still get a weather report in this case? I > know the geonames service will do it*, but is this configured as a weather > source? I think this should be added to geolocation dataengine and libplasmaweather would use it without any modifications. Petri 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: Review Request: Use libplasmaweather in Weather Wallpaper
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/589/ --- (Updated 2009-04-14 14:28:46.261240) Review request for Plasma. Changes --- Get initial place using geolocation dataengine. Summary --- Use libplasmaweather WeatherConfig widget in Weather Wallpaper. Diffs (updated) - /trunk/KDE/kdeplasma-addons/wallpapers/weather/CMakeLists.txt 953924 /trunk/KDE/kdeplasma-addons/wallpapers/weather/weatherAddPlace.ui 953924 /trunk/KDE/kdeplasma-addons/wallpapers/weather/weatherLocations.ui 953924 /trunk/KDE/kdeplasma-addons/wallpapers/weather/weatherwallpaper.h 953924 /trunk/KDE/kdeplasma-addons/wallpapers/weather/weatherwallpaper.cpp 953924 Diff: http://reviewboard.kde.org/r/589/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Use libplasmaweather in Weather Wallpaper
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/589/ --- Review request for Plasma. Summary --- Use libplasmaweather WeatherConfig widget in Weather Wallpaper. Diffs - /trunk/KDE/kdeplasma-addons/wallpapers/weather/CMakeLists.txt 953924 /trunk/KDE/kdeplasma-addons/wallpapers/weather/weatherAddPlace.ui 953924 /trunk/KDE/kdeplasma-addons/wallpapers/weather/weatherLocations.ui 953924 /trunk/KDE/kdeplasma-addons/wallpapers/weather/weatherwallpaper.h 953924 /trunk/KDE/kdeplasma-addons/wallpapers/weather/weatherwallpaper.cpp 953924 Diff: http://reviewboard.kde.org/r/589/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Solar position calculation to time dataengine
On Tuesday 07 April 2009 19:44:08 Aaron Seigo wrote: > as for the I18N_NOOPs, the idea was that users of DataEngines > could then just show the key/value pairs directly in a user interface and > get them translated without having to know the keys ahead of time. i expect > this to become an issue when we have more scripted plasmoids; others don't > seem to think it matters. *shrug* What about the case where dataengine is translated and untranslated (scripted) plasmoid wants to get a specific field. How does it know the field name? Petri 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
