Re: Review Request: Add city and country resolution to GPS geolocation data using geonames.

[Petri Damstén]

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->requestUpdate(GeolocationProvider::ForcedUpdate, m_networkUp);
 
 bool changed = false;
 foreach (GeolocationProvider *plugin, m_plugins) {
@@ -139,6 +146,12 @@
 
 void Geolocation::actuallySetData()
 {
+if (m_latitude != m_data["latitude"].toString() ||
+m_longitude != m_data["longitude"].toString()) {
+m_latitude = m_data["latitude"]

Re: Imgur API key [was Fwd: KDE project API key]

[Sebastian Kügler]

Thanks for going this extra mile, Nikhil!

On Wednesday 27 January 2010 05:08:18 Nikhil Marathe wrote:
> Here is what Alan has to say. I am fine with having my email in, but
> we could change it to a more official KDE address if required. ( See
> http://reviewboard.kde.org/r/2324/ for context )

Best is probably to use the mailinglist address, so the right place gets to 
hear of 
issues (or API changes, so we can adapt quickly).

> 
> -- Forwarded message --
> From: Alan Schaaf 
> Date: Wed, Jan 27, 2010 at 1:00 AM
> Subject: Re: KDE project API key
> To: Nikhil Marathe 
> 
> 
> Hey Nikhil,
> 
> Thanks for asking about this. I've created a key for the Pastebin Applet:
> 
>d0757bc2e94a0d4652f28079a0be9379
> 
> However, I needed to include a contact email, so I used yours. You'd
> only ever get an email if something went terribly wrong or if a major
> version of the API has been released. Let me know if you'd like me to
> use another email instead.
> 
> Also, I'm a pretty big Linux guy, and I'm thrilled to see imgur
> integration within KDE :)

Cool :)
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: T4: Opening Day Presentations

[Sebastian Kügler]

On Wednesday 27 January 2010 00:51:12 Chani wrote:
> > 
> >
> > for everyone else, we can do an introductory round where we go around the
> > room and each person introduces themselves, what they have been working /
> > are currently working on and what they'd like to get out of the dev
> > sprint. even that will likely take over an hour with 25 people!
> >
> > 
> 
> okay, so 1-minute introductions. :)
> in theory that's 25 minutes, so we might be able to keep it to an hour in 
> reality.

I remember Zack, when he was asked to introduce himself during Akademy 2005 in 
Malaga:

"Not necessary, everybody knows me". Next. :-)

(Slightly weak anecdote, but I'm only starting as an oldtimer.)
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: T4: Opening Day Presentations

[Artur Souza (MoRpHeUz)]

Hey,

On Tue, Jan 26, 2010 at 3:09 PM, Alexis Ménard  wrote:
> i'd love to give a small state of the art for plasma-mobile (at least
> for the n900 point of view) : QML, C++, Packaging, and the main issues
> we have to face for now. I will also come with some nice technical
> proof and concept to consider during the sprint.

maybe we can do this together ? :)

Cheers,

-- 
---
Artur Duque de Souza
OpenBossa Research Labs
INdT - Instituto Nokia de Tecnologia
---
Blog: http://labs.morpheuz.eng.br/blog/
PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
---
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: T4: Opening Day Presentations

[Alexis Ménard]

On Wed, Jan 27, 2010 at 1:24 PM, Artur Souza (MoRpHeUz)
 wrote:
> Hey,
>
> On Tue, Jan 26, 2010 at 3:09 PM, Alexis Ménard  wrote:
>> i'd love to give a small state of the art for plasma-mobile (at least
>> for the n900 point of view) : QML, C++, Packaging, and the main issues
>> we have to face for now. I will also come with some nice technical
>> proof and concept to consider during the sprint.
>
> maybe we can do this together ? :)
>

+1

> Cheers,
>
> --
> ---
> Artur Duque de Souza
> OpenBossa Research Labs
> INdT - Instituto Nokia de Tecnologia
> ---
> Blog: http://labs.morpheuz.eng.br/blog/
> PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
> ---
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: T4: Opening Day Presentations

[Marco Martin]

On Wednesday 27 January 2010, Alexis Ménard wrote:
> On Wed, Jan 27, 2010 at 1:24 PM, Artur Souza (MoRpHeUz)
> 
>  wrote:
> > Hey,
> > 
> > On Tue, Jan 26, 2010 at 3:09 PM, Alexis Ménard  wrote:
> >> i'd love to give a small state of the art for plasma-mobile (at least
> >> for the n900 point of view) : QML, C++, Packaging, and the main issues
> >> we have to face for now. I will also come with some nice technical
> >> proof and concept to consider during the sprint.
> > 
> > maybe we can do this together ? :)
> 
> +1

looking forward to it,
/me will take care of saying "this is really bad" with the proper timing :p

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

Re: Review Request: Fix segmentation fault at plasma_applet_animation_example

[Adenilson Cavalcanti]

Loureiro

Did you make it sure that there will be not any leak (i.e. running
plasmoidviewer inside of valgrind)?

Regards


Adenilson

On Wed, Jan 27, 2010 at 10:35 AM,   wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2738/
> ---
>
> Review request for Plasma, Aaron Seigo, Marco Martin, igorto, and Adenilson 
> Cavalcanti.
>
>
> Summary
> ---
>
> This is a small patch that fix a segmentation fault at 
> plasma_applet_animation_example when we close the window.
> Basically I remove the delete sentence at the RotationStackedAnimation's 
> destruct, I made it because I think when we create a QGraphicsLinearLayout 
> passing a widget that widget will be the owner and responsible to delete it 
> as well its children elements and running the example under valgrind I don't 
> get leaks.
>
>
> Diffs
> -
>
>  trunk/KDE/kdelibs/plasma/animations/rotationstacked.cpp 1080090
>  trunk/KDE/kdelibs/plasma/animations/stackedlayout.h 1080090
>
> Diff: http://reviewboard.kde.org/r/2738/diff
>
>
> Testing
> ---
>
>
> Thanks,
>
> loureiro
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request: Fix segmentation fault at plasma_applet_animation_example

[loureiro . andrew]

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

Review request for Plasma, Aaron Seigo, Marco Martin, igorto, and Adenilson 
Cavalcanti.


Summary
---

This is a small patch that fix a segmentation fault at 
plasma_applet_animation_example when we close the window.
Basically I remove the delete sentence at the RotationStackedAnimation's 
destruct, I made it because I think when we create a QGraphicsLinearLayout 
passing a widget that widget will be the owner and responsible to delete it as 
well its children elements and running the example under valgrind I don't get 
leaks.


Diffs
-

  trunk/KDE/kdelibs/plasma/animations/rotationstacked.cpp 1080090 
  trunk/KDE/kdelibs/plasma/animations/stackedlayout.h 1080090 

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


Testing
---


Thanks,

loureiro

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

Review Request: Allow to know if the machine have batteries

[Nicolas Lécureuil]

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

Review request for Plasma.


Summary
---

When creating scripts for plasma first init there is for the moment no way to 
add the battery widget only if the machine have batteries. this patch try to 
work on this issue.

With this function , haveBattery() return true if the machine have some.


Diffs
-

  /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/scriptengine.h 
1081032 
  /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/scriptengine.cpp 
1081032 

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


Testing
---


Thanks,

Nicolas

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

Re: Review Request: Allow to know if the machine have batteries during plasma init ( scripting )

[Nicolas Lécureuil]

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

(Updated 2010-01-27 14:40:36.959854)


Review request for Plasma.


Summary (updated)
---

When creating scripts for plasma first init there is for the moment no way to 
add the battery widget only if the machine have batteries. this patch try to 
work on this issue.

With this function , haveBattery() return true if the machine have some.


Diffs
-

  /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/scriptengine.h 
1081032 
  /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/scriptengine.cpp 
1081032 

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


Testing
---


Thanks,

Nicolas

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

Re: Review Request: Fix segmentation fault at plasma_applet_animation_example

[Sebastian Kügler]

On Wednesday 27 January 2010 15:38:27 Adenilson Cavalcanti wrote:
> Did you make it sure that there will be not any leak (i.e. running
> plasmoidviewer inside of valgrind)?

That's what he writes, no? :)
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Allow to know if the machine have batteries during plasma init ( scripting )

[Sebastian Kügler]

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



/trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/scriptengine.cpp


Should probably is "hasBattery()"


- Sebastian


On 2010-01-27 14:40:36, Nicolas Lécureuil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2741/
> ---
> 
> (Updated 2010-01-27 14:40:36)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> When creating scripts for plasma first init there is for the moment no way to 
> add the battery widget only if the machine have batteries. this patch try to 
> work on this issue.
> 
> With this function , haveBattery() return true if the machine have some.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/scriptengine.h 
> 1081032 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/scriptengine.cpp 
> 1081032 
> 
> Diff: http://reviewboard.kde.org/r/2741/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nicolas
> 
>

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

Re: Review Request: Allow to know if the machine have batteries during plasma init ( scripting )

[Nicolas Lécureuil]

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

(Updated 2010-01-27 15:44:17.001925)


Review request for Plasma.


Changes
---

Sorry, my english need improvement, this new patch fix the name of the function 
to be hasBattery()


Summary
---

When creating scripts for plasma first init there is for the moment no way to 
add the battery widget only if the machine have batteries. this patch try to 
work on this issue.

With this function , haveBattery() return true if the machine have some.


Diffs (updated)
-

  /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/scriptengine.h 
1081032 
  /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/scriptengine.cpp 
1081032 

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


Testing
---


Thanks,

Nicolas

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

Re: notifications, again :D

[Marco Martin]

On Monday 25 January 2010, Aaron J. Seigo wrote:
> when clicking the (i) icon, i'd like to be able to see the last active
> notification of each application. e.g. if kopete and kontact have both sent
> out a notification to me, i should be able to see both if i purposefully
> click the (i). however, if kopete has sent 10 notifications, i should
> probably only see the most recent one, and be able to scroll through the
> older ones.
> 
the "browser" part is basically done-ish
it also augments separation by pulling stuff out of the applet so will be 
easier to split.

atm the browser is also the viewer of te automatic ones.
this will change and they will be displayed in a different popup.

there is still the problem for -running- jobs.
if a new one pops up, the whole notification browser will popup.
it could also be collpsed by default, but not sure if it will be obvious 
enough to "uncollapse"

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

Re: Review Request: Fix segmentation fault at plasma_applet_animation_example

[André Loureiro]

On Wed, Jan 27, 2010 at 10:38 AM, Adenilson Cavalcanti
 wrote:
> Loureiro
>
> Did you make it sure that there will be not any leak (i.e. running
> plasmoidviewer inside of valgrind)?
>
> Regards

Adenilson for sure, here go my heap summary, http://pastebin.com/m2b304044

>
> Adenilson
>
> On Wed, Jan 27, 2010 at 10:35 AM,   wrote:
>>
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> http://reviewboard.kde.org/r/2738/
>> ---
>>
>> Review request for Plasma, Aaron Seigo, Marco Martin, igorto, and Adenilson 
>> Cavalcanti.
>>
>>
>> Summary
>> ---
>>
>> This is a small patch that fix a segmentation fault at 
>> plasma_applet_animation_example when we close the window.
>> Basically I remove the delete sentence at the RotationStackedAnimation's 
>> destruct, I made it because I think when we create a QGraphicsLinearLayout 
>> passing a widget that widget will be the owner and responsible to delete it 
>> as well its children elements and running the example under valgrind I don't 
>> get leaks.
>>
>>
>> Diffs
>> -
>>
>>  trunk/KDE/kdelibs/plasma/animations/rotationstacked.cpp 1080090
>>  trunk/KDE/kdelibs/plasma/animations/stackedlayout.h 1080090
>>
>> Diff: http://reviewboard.kde.org/r/2738/diff
>>
>>
>> Testing
>> ---
>>
>>
>> Thanks,
>>
>> loureiro
>>
>>
>



-- 
--
André Luiz Viana Loureiro
Instituto Nokia de Tecnologia - INdT
OpenBossa Labs. - www.openbossa.org
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: notifications, again :D

[Marco Martin]

On Monday 25 January 2010, Aaron J. Seigo wrote:
> but when i want to see a specific notification, i would like to be able to
> quickly see what a specific application has said.
> 
> the use case is when kopete is busy spamming me and then something i
> actually DO care about appears. when i pop open the notifications area, i
> want to be able to prevent kopete from getting in my way of other
> notifications.

problem is that atm there is no concept of importance in the spec
and since all members are in the signarure of a single function call, no ways 
to add it in a compatible way.

what we can do now is an ugly whitelist: this is from the powermanager, so i 
care more to see it

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

Re: notifications, again :D

[Diego Moya]

I've prepared a storyboard with my concept for notification popups
(explained in my previous post):

http://megaswf.com/view/c72134c5318f9aee8cfe2b3a99c3fa0a.html

I've changed my original "group" idea to a "pile": several popups get
visibly piled at the same place. This doesn't take much space, and
still shows how many simultaneous alerts arrive.


2010/1/27 Aaron J. Seigo wrote:
> On January 26, 2010, Diego Moya wrote:
>> 2010/1/26 Aaron J. Seigo wrote:
> what i said is that showing all the previous notifications and jobs when a new
> notification is shown in the automatic popup is not desirable.

Yes, I agree with that. My idea was not to show all previous
notifications but just the new ones as soon as they arrive. Thus each
alert would create a popup exactly once, right when it's created, and
never again.


> when clicking the (i) icon, i'd like to be able to see the last active
> notification of each application. e.g. if kopete and kontact have both sent

I'd like to see the last active notification of each application even
if I don't click the (i) icon. This is the best way to know that
there's a Low Battery warning even if Kopete has sent a message one
milisecond later.

Showing only one message a time, if the two messages are together or
I'm not looking when the first one appears, I would never notice there
have been two alerts instead of one - so I wouldn't know to click the
(i) icon.


> out a notification to me, i should be able to see both if i purposefully click
> the (i). however, if kopete has sent 10 notifications, i should probably only
> see the most recent one, and be able to scroll through the older ones.

How long would you keep older warnings, and how would you layout them?
Say 20 applications have sent several messages each in the last hour.
Should the (i) icon show 20 boxes with 20 scrollbars?


>> recognizes already viewed notices (i.e. a familiar "blog" model).
> which seems backwards: if i explicitly ask for the notification to be shown,
> i'd like to be saved digging through all the kopete notifications just to find
> the last appointment notification from kontact.

Fair enough. I'm trying to prevent the user from missing any one
alert, which could happen if the same application sends two
notifications together. I think that putting together several fast
messages sent from the same application, should be handled by the
notification system, not left to individual applications like Kopete.


> this forces user interaction; notifications are often passive. simply showing
> a number and activating the (i) should be enough, as we currently do.

Ok, as long as the number is reset to 0 after the user clicks the (i).
I haven't looked if this is what happens now (and I'm now away from
home so I can't check).
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: notifications, again :D

[Marco Martin]

On Wednesday 27 January 2010, Diego Moya wrote:
> I've prepared a storyboard with my concept for notification popups
> (explained in my previous post):
> 
> http://megaswf.com/view/c72134c5318f9aee8cfe2b3a99c3fa0a.html
> 
> I've changed my original "group" idea to a "pile": several popups get
> visibly piled at the same place. This doesn't take much space, and
> still shows how many simultaneous alerts arrive.

the thing i did start to implement was funningly enough almost the same, only 
thing, i still think the new ones should be piled in front of old ones, not 
behind

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

Re: Review Request: save/restore containments

[Aaron Seigo]

> On 2010-01-24 15:13:41, Marco Martin wrote:
> > /trunk/KDE/kdelibs/plasma/corona.h, line 245
> > 
> >
> > listSavedContainments()?
> > otherwise would make the impression that would list also the deleted 
> > ones
> 
> Marco Martin wrote:
> thinking about it don't like curent method names that much, they seem 
> unrelated. what about
> importContainment(qstring)
> exportContainment(qstring)
> listExportedContainments()?
> 
> the catch would be that export does export -and- close...
> could be worth for clarity don't make it actually close the containment?
> 
> Chani Armitage wrote:
> yeah, I need to pick a metaphor and stick with it. open/close, 
> save/restore, import/export..?
> right now I'm leaning towards open/close with remove defaulting to true. 
> I think that normally, activities will be more like objects, unique, not 
> something you copy on a whim, but easily turned off for a while. "export" 
> sounds too much like something that takes effort and isn't done regularly, 
> like exporting your email archive.
> 99% of the time, the user should just be closing or opening one of their 
> regular activities and not caring about the details. only 1% of the time are 
> they likely to want to open an activity from elsewhere (say, one from their 
> other computer or that someone else sent them), or save one to something they 
> can send out.
> 
> However, there is a disadvantage to plasma's tendency to make things like 
> the real world... being able to copy things and make them appear in >1 place 
> can be useful at times. I'd like it to be possible to clone applets and/or 
> containments at some point, and it'd probably end up sharing code with this. 
> hmm.

save/restore is for runtime saving/restoring. this is more import/export, i 
think. open/close doesn't say too much about storage imo.

'"export" sounds too much like something that takes effort and isn't done 
regularly'

remember that this isn't what the user will see, but what the API tells the 
developer it will do.


- Aaron


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


On 2010-01-24 07:29:31, Chani Armitage wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2713/
> ---
> 
> (Updated 2010-01-24 07:29:31)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> as expected, the libplasma side of closing & opening containments is pretty 
> simple.
> getting hte right API and UI will be harder.
> there's no UI in this patch; I have a really ugly UI locally that basically 
> just adds buttons to the activity bar to call these functions. I'm reluctant 
> to commit bad UI; I'd rather someone take the API and make something pretty 
> with it.
> 
> the API, though... hrm. well, tbh I'll probably need to redo it at tokamak to 
> make it activity-centric instead of containment-centric. maybe have functions 
> like openActivity and closeActivity?
> 
> maybe I should make Containment::close() take an optional filename... not 
> something I personally would use, but the loading API leaves open hte option 
> to pass it an arbitrary filename instead of one from the area containments 
> are saved to.
> 
> I'd also like to add thumbnails to the saved containments in the future. I 
> guess I could store them in the same folder under a related filename..? right 
> now the containments are saved to $appdata/activities/$activityname but at 
> some point nepomuk will give us UIDs to use instead (and then we'll need to 
> extract the associated name to display in the UI, and deal with multi-monitor 
> systems having >1 containment, and so on..)
> ok, I'm rambling now. I just don't want this code hiding on my laptop until 
> tokamak :)
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdelibs/plasma/containment.h 1077904 
>   /trunk/KDE/kdelibs/plasma/containment.cpp 1077904 
>   /trunk/KDE/kdelibs/plasma/corona.h 1077904 
>   /trunk/KDE/kdelibs/plasma/corona.cpp 1077904 
> 
> Diff: http://reviewboard.kde.org/r/2713/diff
> 
> 
> Testing
> ---
> 
> works surprisingly well, haven't been able to cause anything bad to happen
> 
> 
> Thanks,
> 
> Chani
> 
>

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

Re: Review Request: save/restore containments

[Aaron Seigo]

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


"make it activity-centric instead of containment-centric"

Activity is a user interface word and a concept of plasma-desktop / 
plasma-netbook / etc. Containment is the libplasma API :)


/trunk/KDE/kdelibs/plasma/containment.h


export, with an optional a URL target?

then close() would become the equivalent of:

export();
destroy();



/trunk/KDE/kdelibs/plasma/containment.cpp


catching duplicates might be a good idea as well to avoid unintentional 
overwrites, not to mention if the containment isn't named or to catch the case 
where a containment is exported and then renamed.

iirc, Ivan has a system for mapping UUIDs to Containments for use with 
nepomuk; perhaps that same system can be used here.



/trunk/KDE/kdelibs/plasma/containment.cpp


this will end up not catching things that aren't saved out yet; the code 
should probably do:

save(newConf);



/trunk/KDE/kdelibs/plasma/corona.h


static?


- Aaron


On 2010-01-24 07:29:31, Chani Armitage wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2713/
> ---
> 
> (Updated 2010-01-24 07:29:31)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> as expected, the libplasma side of closing & opening containments is pretty 
> simple.
> getting hte right API and UI will be harder.
> there's no UI in this patch; I have a really ugly UI locally that basically 
> just adds buttons to the activity bar to call these functions. I'm reluctant 
> to commit bad UI; I'd rather someone take the API and make something pretty 
> with it.
> 
> the API, though... hrm. well, tbh I'll probably need to redo it at tokamak to 
> make it activity-centric instead of containment-centric. maybe have functions 
> like openActivity and closeActivity?
> 
> maybe I should make Containment::close() take an optional filename... not 
> something I personally would use, but the loading API leaves open hte option 
> to pass it an arbitrary filename instead of one from the area containments 
> are saved to.
> 
> I'd also like to add thumbnails to the saved containments in the future. I 
> guess I could store them in the same folder under a related filename..? right 
> now the containments are saved to $appdata/activities/$activityname but at 
> some point nepomuk will give us UIDs to use instead (and then we'll need to 
> extract the associated name to display in the UI, and deal with multi-monitor 
> systems having >1 containment, and so on..)
> ok, I'm rambling now. I just don't want this code hiding on my laptop until 
> tokamak :)
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdelibs/plasma/containment.h 1077904 
>   /trunk/KDE/kdelibs/plasma/containment.cpp 1077904 
>   /trunk/KDE/kdelibs/plasma/corona.h 1077904 
>   /trunk/KDE/kdelibs/plasma/corona.cpp 1077904 
> 
> Diff: http://reviewboard.kde.org/r/2713/diff
> 
> 
> Testing
> ---
> 
> works surprisingly well, haven't been able to cause anything bad to happen
> 
> 
> Thanks,
> 
> Chani
> 
>

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

Re: Review Request: Allow to know if the machine have batteries during plasma init ( scripting )

[Aaron Seigo]

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

Ship it!


i don't think the current patch compiles (a missing '}'), but it looks fine. 
for 4.5 i could (very easily) add full DataEngine support to the scripting if 
it becomes useful (i'm not sure it would be useful, but i'm open to use cases). 
in any case, please ensure it compiles and then commit (and backport). i'll 
take care of documenting the API in the design file.

- Aaron


On 2010-01-27 15:44:17, Nicolas Lécureuil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2741/
> ---
> 
> (Updated 2010-01-27 15:44:17)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> When creating scripts for plasma first init there is for the moment no way to 
> add the battery widget only if the machine have batteries. this patch try to 
> work on this issue.
> 
> With this function , haveBattery() return true if the machine have some.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/scriptengine.h 
> 1081032 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/scriptengine.cpp 
> 1081032 
> 
> Diff: http://reviewboard.kde.org/r/2741/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nicolas
> 
>

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

Re: notifications, again :D

[Aaron J. Seigo]

On January 27, 2010, Marco Martin wrote:
> On Wednesday 27 January 2010, Diego Moya wrote:
> > I've prepared a storyboard with my concept for notification popups
> > (explained in my previous post):
> > 
> > http://megaswf.com/view/c72134c5318f9aee8cfe2b3a99c3fa0a.html
> > 
> > I've changed my original "group" idea to a "pile": several popups get
> > visibly piled at the same place. This doesn't take much space, and
> > still shows how many simultaneous alerts arrive.
> 
> the thing i did start to implement was funningly enough almost the same,
> only thing, i still think the new ones should be piled in front of old
> ones, not behind

agreed; unless the user is 'actively' viewing them (mouse hover) or once we 
get the concept of priority into the notifications.

it's a neat idea, though :)

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

KDE core developer sponsored by Qt Development Frameworks
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: save/restore containments

[Marco Martin]

On Wednesday 27 January 2010, Aaron Seigo wrote:
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2713/#review3910
> ---
> 
> 
> "make it activity-centric instead of containment-centric"
> 
> Activity is a user interface word and a concept of plasma-desktop /
> plasma-netbook / etc. Containment is the libplasma API :)
 
well, talking about it at campkde the doubt really surfaced was:
is really a good thing to mantain the concept of one activity=one contaiment?

problem could be for instance with multi monitor. if an activity is what i'm 
doing now, i am doing it on both monitor (depends also what the workflow is 
could be the case or not)

perhaps the pervirtualdesktopviews madness could also be mapped to -one- 
activity

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

Re: notifications, again :D

[Diego Moya]

2010/1/27 Marco Martin wrote:
> the thing i did start to implement was funningly enough almost the same, only

Proof that local optima do exist for good designs, given the same
constraints! :-)


> thing, i still think the new ones should be piled in front of old ones, not
> behind

In what order do you remove them? Piling new ones at the back allows
for alerts to be seen in arrival order. Piling them on the top creates
a FIFO stack, which I'm not sure how to clear up - much less
automatically with timers.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: notifications, again :D

[Jamboarder]

> From: Marco Martin 

> problem is that atm there is no concept of importance in the spec
> and since all members are in the signarure of a single function call, no ways 
> to add it in a compatible way.
> 
> what we can do now is an ugly whitelist: this is from the powermanager, so i 
> care more to see it

If it helps any, might the following interaction model handle "noisy" apps:
- provide a mechanism that allows the user to suppress the popup of 
notifications from any specific app.  Suppressed notifications would still get 
stored in the "stack" and would be reflected by the increase in notification 
count number - they just wouldn't popup.
- when a notification is triggered by an app whose notifications are not 
suppressed, only show that specific notification and no other part of the 
notification stack/history.  The notification count is perhaps enough to 
communicate that there are additional notifications beyond the current one 
being shown.
- when the user clicks on the (i) show the all notifications in the 
stack/history using whatever grouping/scrolling/etc. strategy you come up with. 
(I like the app grouping idea myself...)

A singularly systemic determination of importance/priority will 
perhaps always run into a few grey areas that inevitably conflict with 
what the user holds is important.  No not all areas are grey, but the 
grey areas definitely exist.

I understand that chiming into an already long running thread from the peanut 
gallery is potentially not helpful.  This is meant to be purely constructive 
and not meant to be "you're all stupid, this is the only solution".

peace and much respect,
Andrew Lake
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Fix segmentation fault at plasma_applet_animation_example

[Aaron Seigo]

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


this will result in a leak when the layout isn't assigned. e.g.:

Animation* rotStackedAnim = 
Plasma::Animator::create(Plasma::Animator::RotationStackedAnimation);
delete rotStackedAnim;

and then we have a leak.

what the dtor probably should be is:

if (!m_sLayout->parentLayoutItem()) {
 delete m_sLayout;
}

m_sLayout should also be a QWeakPointer since it could be deleted behind our 
backs.

- Aaron


On 2010-01-27 14:35:00, loureiro wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2738/
> ---
> 
> (Updated 2010-01-27 14:35:00)
> 
> 
> Review request for Plasma, Aaron Seigo, Marco Martin, igorto, and Adenilson 
> Cavalcanti.
> 
> 
> Summary
> ---
> 
> This is a small patch that fix a segmentation fault at 
> plasma_applet_animation_example when we close the window.
> Basically I remove the delete sentence at the RotationStackedAnimation's 
> destruct, I made it because I think when we create a QGraphicsLinearLayout 
> passing a widget that widget will be the owner and responsible to delete it 
> as well its children elements and running the example under valgrind I don't 
> get leaks.
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdelibs/plasma/animations/rotationstacked.cpp 1080090 
>   trunk/KDE/kdelibs/plasma/animations/stackedlayout.h 1080090 
> 
> Diff: http://reviewboard.kde.org/r/2738/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> loureiro
> 
>

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

Re: notifications, again :D

[Marco Martin]

On Wednesday 27 January 2010, Diego Moya wrote:
> 2010/1/27 Marco Martin wrote:
> > the thing i did start to implement was funningly enough almost the same,
> > only
> 
> Proof that local optima do exist for good designs, given the same
> constraints! :-)

eheh :)

> > thing, i still think the new ones should be piled in front of old ones,
> > not behind
> 
> In what order do you remove them? Piling new ones at the back allows
> for alerts to be seen in arrival order. Piling them on the top creates
> a FIFO stack, which I'm not sure how to clear up - much less
> automatically with timers.

the policy should be this:
- if a new one arrives check if there is already a notification of the same 
app if it is remove that one
- else remove the oldest
-put the newest notification on top

old one wouldn't be "lost since the stack will be positioned to be enough to 
show the titles of old ones

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

Re: notifications, again :D

[Diego Moya]

2010/1/27 Marco Martin wrote:
> the policy should be this:
> - if a new one arrives check if there is already a notification of the same
> app if it is remove that one

What if I didn't have time to read that one, because it got instantly
covered by a newer one? Then I'm forced to open (i) to review what was
discarded.

> - else remove the oldest

Same thing. With "pile on top" I have no guarantee to have seen
previous messages, they could have been covered too fast or I might
have been looking elsewhere when they appeared.


> -put the newest notification on top
>
> old one wouldn't be "lost since the stack will be positioned to be enough to
> show the titles of old ones

So this policy is "see the whole of the last message in a burst, see
only the headers of previous ones".

I think this will work in a burst from the same app, but will favor
noisy applications over quiet ones. That important "Low battery" alert
would quickly be covered by Kopete messages. Are you sure you can put
up with this? At least, putting new messages behind gives all
applications equal chance.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: notifications, again :D

[Riccardo Iaconelli]

On Tuesday 26 January 2010 21:33:27 Marco Martin wrote:
> you need a 60 inh screen to see a full kopete notification :p
> (but could be quite controllable from our part tough)
> 
> luckily when there is a pending notification and a new message arrives now 
> updates the notification instead of adding a new one

can you give me a screenshot?

-Riccardo
-- 
Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平
Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch שלום
Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Bookmarks plasmoid moved to kdereview

[Friedrich W. H. Kossebau]

Mardi, le 26 janvier 2010, à 00:00, Aaron J. Seigo a écrit:
> On January 24, 2010, Friedrich W. H. Kossebau wrote:
> > Upcoming Tuesday two weeks have passed since the move into kdereview.
> > Thanks to Albert, Burkhard and Laurent some i18n problems have been
> > fixed. Did anyone else have the time to give this plasmoid a small test?
> 
> yes, i looked through the code today as well as used it. very nice :)

Thanks :)
 
> my only suggestions are:
> 
> * in the tooltip, if a subfolder is selected maybe add that it's a
>  bookmarks folder? right now that information gets "lost" when a subfolder
>  is selected

True. Perhaps the default icon for bookmark subfolders should not be the plain 
folder symbol, but the folder-favorites.
Will think about that.

> * in the configuration dialog, instead of having a button that opens a
>  dialog that lists the folders available it would be nice to have the tree
>  right there. right now there is only KBookmarksDialog, of course, which
>  makes this approach "necessary", at least without tons of duplicated code.
>  a
> KBookmarksTree (which KBookmarksDialog would use internally) would be a
>  nice addition to the kbookmarks library and would make the applet's config
>  dialog much nicer imho. it shouldn't be _too_ difficult since
>  KBookmarksDialog already has an implementation of such a tree internally.

Makes this page visually quite noisy, though. And this is the config page 
always shown first if opening the config editor, even if the user is just to 
change the key shortcut.
Otherwise nice idea, saves one click. Will keep in mind and roll around some 
more.

> neither are big issues, and i don't think the KBookmarksDialog is a blocker
>  at all (more of a "would be nice") to including this applet in
>  kdeplasma-addons.
> 
> please move it over at your leisure :)

Will happily do :) But where? 
kdebase/workspace/plasma/generic/applets? 
kdeplasma-addons/applets/?

Cheers
Friedrich
-- 
Okteta - KDE Hex Editor - http://utils.kde.org/projects/okteta
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: notifications, again :D

[Marco Martin]

On Wednesday 27 January 2010, Diego Moya wrote:
> 
> I think this will work in a burst from the same app, but will favor
> noisy applications over quiet ones. That important "Low battery" alert
> would quickly be covered by Kopete messages. Are you sure you can put
> up with this? At least, putting new messages behind gives all
> applications equal chance.

since given how i want to implement it one behaviour or the other would mean 
basically an one liner difference, we will be able to test both for a wile and 
see what seems better

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

Re: notifications, again :D

[Marco Martin]

On Wednesday 27 January 2010, you wrote:
> On Tuesday 26 January 2010 21:33:27 Marco Martin wrote:
> > you need a 60 inh screen to see a full kopete notification :p
> > (but could be quite controllable from our part tough)
> > 
> > luckily when there is a pending notification and a new message arrives
> > now updates the notification instead of adding a new one
> 
> can you give me a screenshot?
> 
> -Riccardo
already modified too much in trunk :D
but it seems that limiting the size of the avatar to a reasonable size pretty 
much solves the problem

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

Re: notifications, again :D

[Diego Moya]

2010/1/27 Marco Martin wrote:
> On Wednesday 27 January 2010, Diego Moya wrote:
> since given how i want to implement it one behaviour or the other would mean
> basically an one liner difference, we will be able to test both for a wile and
> see what seems better

Seems reasonable.

I'm sure someone in the future will ask to make it an option!
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Bookmarks plasmoid moved to kdereview

[Aaron J. Seigo]

On January 27, 2010, Friedrich W. H. Kossebau wrote:
> Mardi, le 26 janvier 2010, à 00:00, Aaron J. Seigo a écrit:
> > On January 24, 2010, Friedrich W. H. Kossebau wrote:
> > > Upcoming Tuesday two weeks have passed since the move into kdereview.
> > > Thanks to Albert, Burkhard and Laurent some i18n problems have been
> > > fixed. Did anyone else have the time to give this plasmoid a small
> > > test?
> > 
> > yes, i looked through the code today as well as used it. very nice :)
> 
> Thanks :)
> 
> > my only suggestions are:
> > 
> > * in the tooltip, if a subfolder is selected maybe add that it's a
> > 
> >  bookmarks folder? right now that information gets "lost" when a
> >  subfolder is selected
> 
> True. Perhaps the default icon for bookmark subfolders should not be the
> plain folder symbol, but the folder-favorites.

that sounds like a good idea too ...

> > * in the configuration dialog, instead of having a button that opens a
> > 
> >  dialog that lists the folders available it would be nice to have the
> >  tree right there. right now there is only KBookmarksDialog, of course,
> >  which makes this approach "necessary", at least without tons of
> >  duplicated code. a
> > 
> > KBookmarksTree (which KBookmarksDialog would use internally) would be a
> > 
> >  nice addition to the kbookmarks library and would make the applet's
> >  config dialog much nicer imho. it shouldn't be _too_ difficult since
> >  KBookmarksDialog already has an implementation of such a tree
> >  internally.
> 
> Makes this page visually quite noisy, though. And this is the config page
> always shown first if opening the config editor, even if the user is just
> to change the key shortcut.

it's the only thing on the page and dialogs-on-dialogs is something we really 
try to avoid as they are inconvenient :)

> > please move it over at your leisure :)
> 
> Will happily do :) But where?

> kdeplasma-addons/applets/?

yes, please :)

and thanks again for writing this one!

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

KDE core developer sponsored by Qt Development Frameworks
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: notifications, again :D

[Marco Martin]

On Wednesday 27 January 2010, Diego Moya wrote:
> 2010/1/27 Marco Martin wrote:
> > On Wednesday 27 January 2010, Diego Moya wrote:
> > since given how i want to implement it one behaviour or the other would
> > mean basically an one liner difference, we will be able to test both for
> > a wile and see what seems better
> 
> Seems reasonable.
> 
> I'm sure someone in the future will ask to make it an option!

/me doesn't want to fall in this trap again, however :p

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

On Plasmate's recent project list

[Diego Casella ([Po]lentino)]

>
> -- Messaggio inoltrato --
> From: Yuen Hoe Lim 
> To: plasma-devel@kde.org
> Date: Wed, 27 Jan 2010 12:45:58 +0800
> Subject: Re: On Plasmate's recent project list
>
> Correct, the project <---> folder naming convention is suggested, not
>> required ( even though I wouldn't break that :P ).
>>
>
> Hmm, okay so this brings up the greater question of whether we want to
> force project and folder names to be identical (They don't have to be
> technically, but we can force it programmatically). I'm personally not keen,
> (I have in fact already broken that rule in the implementation) and here
> again are my list of reasons :P
>
>- Forcing the names to be the same has the benefit of neatness, but I
>don't think this is always desireable since we are allowing users to import
>existing plasmoids as well as download them from GHNS (eventually), and the
>user really has no control over the names of these external projects. It'd
>be pretty troublesome, at least if it was me, if I was blocked from
>importing just because I have a project locally with the same name (note
>that if we force project and folder names to be identical, name conflicts
>will occur even if I have a plasmoid and a runner, for example, with the
>same name, and those are clearly different).
>- I think importing existing plasmoids and stuff will be a fairly
>common use-case, and the project name == folder name rule is not widely
>enforced in existing plasmoids (my own plasmoid doesn't keep this rule..)
>- For the above reasons I'm not convinced that there is a significant
>advantage of forcing project and folder names to be identical, and yet
>forcing them to be identical will make a lot of other sticky
>conflict-resolution dialogs necessary, not just in this 'import-all'
>feature. Examples: the regular project import, import from GHNS or even the
>desktop if we implement that, and when the user changes the project name in
>the metadata editor.
>
> In short, I think forcing the names to be identical will create a lot of
> extra work without really adding any significant benefit. It still can be
> done though if you guys really think it's better. What do you guys think? :)
>
> So,if we bump into a conflict situation, we rename one of the two folder,
>> good. Now, my question is: how the user will be able to distinguish the
>> "current" and "backup" version of his/her project ?
>> I mean, in the project list we can't show the directories name because
>> they must be hidden, so an appropriate way is to pick up the project name
>> from the "Name" field metadata.desktop file, and surprisingly this will be
>> 99% times the same, since previously there was a conflict, so most likely
>> the user will fill a bug report because he/she can't distingiush between the
>> two projects, and he/she is forced to look to the sources in order to find
>> the correct one.
>> So, what about showing the "Remove,overwrite,ignore" buttons, or adding
>> more informations in the project list (for example adding the date of last
>> modification could be enough to distinguish between and old backup and the
>> current project, at least when there are few projects). Any other ideas ?
>>
>
> I maintain that the former only makes sense if we force project names to be
> == folder names (in which case we'd need to add that kind of options/dialogs
> all over the place). If we keep the current status though (project names !=
> folder names), then I agree that we need distinguishers in the list. I was
> thinking adding the author name and version, because it should be relatively
> uncommon for the same guy to create two projects with the same name, so
> showing author should eliminate the larger class of duplicate names that
> result from external imports.
>

+1 for me :)

For people who actually want to maintain two projects of the same name and
> both by me, version number I think is a sensible way for me to distinguish
> between the two (so instead of doing the somewhat uncool thing of having to
> name my projects coolplasmoid_1 and coolplasmoid_2, I could have
> coolplasmoid v1 and coolplasmoid v2. Nicer IMO). Slipups that create same
> plasmoid name and same author and same version can STILL occur, but that
> would hopefully be rare, and again the fix is trivial - the user just needs
> to load either one and check his code, then flip to the metadata editor and
> key in an appropriate version number (or change the name if that's what he
> prefers).
>
> Any other ideas? :)
>
> Yours is good and, since its not a vital component in our app, we could
change its behaviour later, referring on users feedbacks :)


> 
> Jason "moofang" Lim Yuen Hoe
> http://yuenhoe.co.cc/
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Allow to know if the machine have batteries during plasma init ( scripting )

[Wayne Speir]

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



/trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/scriptengine.cpp


Do you want to check that 'engines' is not NULL?


- Wayne


On 2010-01-27 15:44:17, Nicolas Lécureuil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2741/
> ---
> 
> (Updated 2010-01-27 15:44:17)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> When creating scripts for plasma first init there is for the moment no way to 
> add the battery widget only if the machine have batteries. this patch try to 
> work on this issue.
> 
> With this function , haveBattery() return true if the machine have some.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/scriptengine.h 
> 1081032 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/scriptengine.cpp 
> 1081032 
> 
> Diff: http://reviewboard.kde.org/r/2741/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nicolas
> 
>

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

screensaver security - please help

[Chani]

ok, so I kinda dropped the ball here.
screensaver security depends on the c++ plasmoids telling the truth about what 
features they use. for 4.3 I went through kdebase and kdeplasma-addons and 
ensured that they were all up to date. I haven't done this for 4.4, and with 
less than a week to final tagging, I'm not going to get through them all on my 
own.

the process is pretty simple: play with an applet, skim through its source 
code, and find any dangerous things it does (like showing a filedialog). When 
such things are found, they can either be made optional or marked as required. 
when nothing is found, they can be marked as safe. I have a wiki page with 
more details, and the results from 4.3: 
http://techbase.kde.org/User:Chani/Plans/ConstraintsList

if you've got some spare time, please pick a few applets (I usually do them in 
batches of 5) and test them out. I expect most haven't changed, so 90% of the 
time it'll just be a matter of marking that on the wiki. :) if you find a 
confusing one, feel free to ask me about it.

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


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

Re: T4: Opening Day Presentations

[Dario Freddi]

On Tuesday 26 January 2010 18:40:44 Ivan Čukić wrote:
> > if you do have a topic you'd like to do a "full" presentation on, please
> > do add it to the wiki and we will work out a schedule for them.
> 
> Chani and I will cover the activities. We'll meet on IRC soon to discuss
>  how to divide the topic.
> 

I second this. A perfect balance over time/awesomeness shown would be having 
"group presentations". I can have one with Lukas, for example.

> 
> Cheerio
> 
> 
> --
> Money can't buy happiness, but neither can poverty.
>-- Leo Rosten
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
> 

-- 
---

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B


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: screensaver security - please help

[Ryan Rix]

On Wed 27 January 2010 1:17:41 pm Chani wrote:
> if you've got some spare time, please pick a few applets (I usually do them
> in batches of 5) and test them out. I expect most haven't changed, so 90%
> of the time it'll just be a matter of marking that on the wiki. :) if you
> find a confusing one, feel free to ask me about it.

I'll take a look at some tonight/this afternoon

-- 
Ryan Rix
== http://hackersramblings.wordpress.com | http://rix.si/ ==


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: T4: Opening Day Presentations

[Aaron J. Seigo]

On January 27, 2010, Dario Freddi wrote:
> On Tuesday 26 January 2010 18:40:44 Ivan Čukić wrote:
> > > if you do have a topic you'd like to do a "full" presentation on,
> > > please do add it to the wiki and we will work out a schedule for them.
> > 
> > Chani and I will cover the activities. We'll meet on IRC soon to discuss
> > 
> >  how to divide the topic.
> 
> I second this. A perfect balance over time/awesomeness shown would be
> having "group presentations". I can have one with Lukas, for example.

could you put this on the wiki, along with the topic? thanks! :)

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

KDE core developer sponsored by Qt Development Frameworks
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: screensaver security - please help

[Chani]

On January 27, 2010 15:08:18 Ryan Rix wrote:
> On Wed 27 January 2010 1:17:41 pm Chani wrote:
> > if you've got some spare time, please pick a few applets (I usually do
> > them in batches of 5) and test them out. I expect most haven't changed,
> > so 90% of the time it'll just be a matter of marking that on the wiki.
> > :) if you find a confusing one, feel free to ask me about it.
> 
> I'll take a look at some tonight/this afternoon

awesome, thank you :) :)

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


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

Re: Bookmarks plasmoid moved to kdereview

[Friedrich W. H. Kossebau]

Mercredi, le 27 janvier 2010, à 19:23, Aaron J. Seigo a écrit:
> On January 27, 2010, Friedrich W. H. Kossebau wrote:
> > Mardi, le 26 janvier 2010, à 00:00, Aaron J. Seigo a écrit:
> > > On January 24, 2010, Friedrich W. H. Kossebau wrote:
> > > > Upcoming Tuesday two weeks have passed since the move into kdereview.
> > > > Thanks to Albert, Burkhard and Laurent some i18n problems have been
> > > > fixed. Did anyone else have the time to give this plasmoid a small
> > > > test?
> > >
> > > yes, i looked through the code today as well as used it. very nice :)
> >
> > Thanks :)
> >
> > > my only suggestions are:
> > >
> > > * in the tooltip, if a subfolder is selected maybe add that it's a
> > >
> > >  bookmarks folder? right now that information gets "lost" when a
> > >  subfolder is selected
> >
> > True. Perhaps the default icon for bookmark subfolders should not be the
> > plain folder symbol, but the folder-favorites.
> 
> that sounds like a good idea too ...
> 
> > > * in the configuration dialog, instead of having a button that opens a
> > >
> > >  dialog that lists the folders available it would be nice to have the
> > >  tree right there. right now there is only KBookmarksDialog, of course,
> > >  which makes this approach "necessary", at least without tons of
> > >  duplicated code. a
> > >
> > > KBookmarksTree (which KBookmarksDialog would use internally) would be a
> > >
> > >  nice addition to the kbookmarks library and would make the applet's
> > >  config dialog much nicer imho. it shouldn't be _too_ difficult since
> > >  KBookmarksDialog already has an implementation of such a tree
> > >  internally.
> >
> > Makes this page visually quite noisy, though. And this is the config page
> > always shown first if opening the config editor, even if the user is just
> > to change the key shortcut.
> 
> it's the only thing on the page 

Currently ;)

> and dialogs-on-dialogs is something we
>  really try to avoid as they are inconvenient :)

Agreed.

Plan to work a little more on the KBookmark* classes of kdelibs in the future, 
so will then see how the KBookmarksTree/KBookmarksModel could become public 
also for this use case, so it's no more dialogs-on-dialogs. If noone else 
beats me to it, as they say ;)

> > > please move it over at your leisure :)
> >
> > Will happily do :) But where?
> >
> > kdeplasma-addons/applets/?
> 
> yes, please :)

Done, #1081252.

> and thanks again for writing this one!

Oh, wrote it just for myself, not for others ;)
But sharing it here gains maintenance and improvements from others, so that 
should be a good deal in this case :P

Cheers
Friedrich
-- 
Okteta - KDE Hex Editor - http://utils.kde.org/projects/okteta
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Allow to know if the machine have batteries during plasma init ( scripting )

[Sebastian Kügler]

On Wednesday 27 January 2010 21:32:17 Wayne Speir wrote:
> http://reviewboard.kde.org/r/2741/#review3920

> /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/scriptengine.cp
> p 
> 
> Do you want to check that 'engines' is not NULL?

Shouldn't be necessary:

"On failure, the fallback NullEngine (which does nothing and !isValid()) is 
returned."

http://api.kde.org/4.x-api/kdelibs-
apidocs/plasma/html/classPlasma_1_1DataEngineManager.html#a1e34f80e16f6171930320ff734ef014b
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 


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: Allow to know if the machine have batteries during plasma init ( scripting )

[Wayne Speir]

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



/trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/scriptengine.cpp


Per Sebastian:

Shouldn't be necessary:

"On failure, the fallback NullEngine (which does nothing and !isValid()) is
returned."


- Wayne


On 2010-01-27 15:44:17, Nicolas Lécureuil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2741/
> ---
> 
> (Updated 2010-01-27 15:44:17)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> When creating scripts for plasma first init there is for the moment no way to 
> add the battery widget only if the machine have batteries. this patch try to 
> work on this issue.
> 
> With this function , haveBattery() return true if the machine have some.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/scriptengine.h 
> 1081032 
>   
> /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/scriptengine.cpp 
> 1081032 
> 
> Diff: http://reviewboard.kde.org/r/2741/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nicolas
> 
>

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

Re: Review Request: Allow to know if the machine have batteries during plasma init ( scripting )

[Aaron J. Seigo]

On January 27, 2010, Sebastian Kügler wrote:
> On Wednesday 27 January 2010 21:32:17 Wayne Speir wrote:
> > http://reviewboard.kde.org/r/2741/#review3920
> > 
> > /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/scriptengine.
> > cp p 
> > 
> > Do you want to check that 'engines' is not NULL?
> 
> Shouldn't be necessary:

correct; it _always_ returns a valid pointer.

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

KDE core developer sponsored by Qt Development Frameworks
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel