Re: [PATCH] BUG 189643 Taskbar should be animated while program is starting

[潘卫平(Peter Pan)]

Aaron J. Seigo 写道:
> On Wednesday 29 July 2009, 潘卫平 wrote:
>> Third, I set the BusyWidgest's geometry in AbstractTaskItem::drawTask(),
>> so it can get the proper geometry.
> 
> patch looks good; i only wonder if there's a better place to put the 
> setGeometry for the busy widget than in a paintEvent, but this seems like it 
> should be alright and probably as good as any other.
> 
> thanks for the patch, please commit :)
> 
> 
> 
> 
> 
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel

SVN commit 1004385 by peterpan:

Thank you very much.

-- 
潘卫平(Peter Pan)
Red Flag Software Co., Ltd
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Issues with setupMatchSession/matchSessionComplete in RunnerManager

[Aaron J. Seigo]

On Wednesday 29 July 2009, Ryan P. Bitanga wrote:
> On Thu, Jul 30, 2009 at 2:04 AM, Aaron J. Seigo wrote:
> > On Wednesday 29 July 2009, Ryan P. Bitanga wrote:
> >> On Thu, Jul 30, 2009 at 12:43 AM, Aaron J. Seigo wrote:
> >> > On Wednesday 29 July 2009, Ryan P. Bitanga wrote:
> >>
> >> so I think the best place to do this would be in
> >> the destructor of FindMatchesJob. We'd check if the queue is empty,
> >> and if it is then we can emit the teardown signal.
> >
> > there'd be some corner cases there, such as if there are no
> > FindMatchesJobs when teardown is requested ... how about in
> > RunnerManagerPrivate::jobDone()? see attached patch...
>
> I like the fact that this keeps everything in RunnerManager instead of
> having the logic separated between files. Doesn't this suffer from the
> same problem though? If there are no jobs to begin with, the slot
> won't be called.

that's why there's a call to checkTearDown() in 
RunnerManager::matchSessionComplete(). if there are no jobs running, 
checkTearDown() will run immediately. otherwise, it will wait until the jobs 
are all done.

> >> Agreed, but the use case that came to mind while I was writing this
> >> e-mail is that of the window runner. It caches the data once a query
> >> is launched but the data may become invalid while the dialog is open
> >> (e.g. an application is launched/closed while the dialog is open). But
> >> this is an issue addressable in the runner implementation.
> >
> > yes; in this case the setup/teardown lets the runner know that it should
> > start watching for those changes as well. if the data can't be trusted
> > between runs (meaning that there is no way to detect changes and the data
> > may change) then the runner will have to re-load the data in match no
> > matter what we do :)
>
> Just for clarity I think we should put that in the apidocs. :)

sure :)

-- 
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 Software


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: Issues with setupMatchSession/matchSessionComplete in RunnerManager

[Ryan P. Bitanga]

On Thu, Jul 30, 2009 at 2:04 AM, Aaron J. Seigo wrote:
> On Wednesday 29 July 2009, Ryan P. Bitanga wrote:
>> On Thu, Jul 30, 2009 at 12:43 AM, Aaron J. Seigo wrote:
>> > On Wednesday 29 July 2009, Ryan P. Bitanga wrote:
>> so I think the best place to do this would be in
>> the destructor of FindMatchesJob. We'd check if the queue is empty,
>> and if it is then we can emit the teardown signal.
>
> there'd be some corner cases there, such as if there are no FindMatchesJobs
> when teardown is requested ... how about in RunnerManagerPrivate::jobDone()?
> see attached patch...

I like the fact that this keeps everything in RunnerManager instead of
having the logic separated between files. Doesn't this suffer from the
same problem though? If there are no jobs to begin with, the slot
won't be called. :( I initially thought the checkTeardown call in
RunnerManager::reset would fix this, but reset is called _before_ the
dialog is hidden so no signal will be emitted in that particular
corner case.

I think an easy way around this would be to enqueue a dummy
FindMatchesJob (with an invalid context to skip the run method?) when
requesting a teardown.

I also think RunnerManager::reset should only deal with having a blank
search context (but necessarily ending the match session) since the
interfaces also call reset when the query changes to an empty string.
In the other times RunnerManager::reset() is called, the dialog is
about to be closed anyway so matchSessionComplete will be called.

> the only downside to this approach in general is that one long-running runner
> (or never returning, even) could indefinitely delay teardown happening for
> other runners. it would be possible to do per-runner bookkeeping if this every
> becomes a real issue.
>
True. I suppose this would be the best solution since there still is
no way to gracefully terminate a thread that's executing a job.

>> > there'd be no point to these signals at all then and runners would just
>> > do all their data gathering in (or just before) match(). that would be
>> > too slow. the point of these signals is to do the setup and teardown as
>> > rarely as possible, but also only when the data will be used.
>>
>> Agreed, but the use case that came to mind while I was writing this
>> e-mail is that of the window runner. It caches the data once a query
>> is launched but the data may become invalid while the dialog is open
>> (e.g. an application is launched/closed while the dialog is open). But
>> this is an issue addressable in the runner implementation.
>
> yes; in this case the setup/teardown lets the runner know that it should start
> watching for those changes as well. if the data can't be trusted between runs
> (meaning that there is no way to detect changes and the data may change) then
> the runner will have to re-load the data in match no matter what we do :)
>
Just for clarity I think we should put that in the apidocs. :)

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

Re: Picture Frame Widget

[Aaron J. Seigo]

(cc'ing Aron as he's not subscribed (yet? ;) to plasma-devel)

On Wednesday 29 July 2009, Aron Hoekstra wrote:
> Offer the ability to right-click on a presently displayed image and
> "exclude" it from the slideshow.

i think this has been requested before, too. would be nice to see it 
implemented.

> Of course, Transition Effects would be a nice feature.

i believe this one is already being working on as part of a SoC project on 
animations.

> I'm a developer, but don't know much about panel/widget development.
> Where could I find the source for the picture frame so that I might try
> to implement these options myself?

the frame is in kdeplasma-addons/applets/frame/ 

you can test your changes easily (as in "without restarting plasma-desktop") 
with: plasmoidviewer frame

if you need/want some pointers on getting the sources from kde's svn and 
working on those, just let us know... i look forward to seeing your patches :)

-- 
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 Software


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 clear() method to Plasma::TabBar widget

[Aaron Seigo]

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


i assume the reason there is no QTabWidget::clear() is that it isn't something 
that gets used very often and is easy to do outside the API, so for API 
simplicity hasn't ever been added. personally i'm Ok with this patch as long as 
there is more than one user of it.


svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs/plasma/widgets/tabbar.cpp


should the preferred size of the tabProxy be updated at this point? e.g.:

d->tabProxy->setPreferredSize(d->tabProxy->native->sizeHint());

insert/remove tab are doing this, so i assume it should be done here as 
well.


- Aaron


On 2009-07-28 06:22:04, Shawn Starr wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1146/
> ---
> 
> (Updated 2009-07-28 06:22:04)
> 
> 
> Review request for Plasma, Aaron Seigo and Marco Martin.
> 
> 
> Summary
> ---
> 
> Add a clear() method to the Plasma::TabBar widget, It seems odd to require 
> the user to have to iterate though all the tabs to delete them when this 
> really should be done internally. It's seems strange QTabBar also has no 
> clear() to deal with this. Maybe someone can explain why this is the case?
> 
> 
> Diffs
> -
> 
>   svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs/plasma/widgets/tabbar.h 
> 1003358 
>   svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs/plasma/widgets/tabbar.cpp 
> 1003358 
> 
> Diff: http://reviewboard.kde.org/r/1146/diff
> 
> 
> Testing
> ---
> 
> 1) call clear() with no tabs added to a Plasma::TabBar instance, result 
> function exits and nothing happens.
> 2) call clear() with tabs added, add and remove them with different sizes, 
> tabs are destroyed properly. We are assuming that if there are N pages there 
> are N tabs. As I didn't see any method to return the total number of tabs 
> only pages.
> 
> 
> Thanks,
> 
> Shawn
> 
>

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

Picture Frame Widget

[Aron Hoekstra]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I think the Picture Frame/Slideshow Widget is great, thanks for
developing it. I'd like to offer a few suggestions:

Offer the ability to right-click on a presently displayed image and
"exclude" it from the slideshow.

Of course, Transition Effects would be a nice feature.

I'm a developer, but don't know much about panel/widget development.
Where could I find the source for the picture frame so that I might try
to implement these options myself?

Thanks,

Aron Hoekstra
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkpwgskACgkQi+/GM3KZPFn/NgCaAzLtcV8YVcC7OLUS//ntNohj
7v4An3+RhimhZUw13H+aDBdDPvPoL0+i
=w0Df
-END PGP SIGNATURE-
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Issues with setupMatchSession/matchSessionComplete in RunnerManager

[Aaron J. Seigo]

On Wednesday 29 July 2009, Ryan P. Bitanga wrote:
> On Thu, Jul 30, 2009 at 12:43 AM, Aaron J. Seigo wrote:
> > On Wednesday 29 July 2009, Ryan P. Bitanga wrote:
> >> Because we can launch a new query while jobs for an existing query are
> >> still executing, any slots that are connected to prepare and teardown
> >> have to be threadsafe.
> >
> > setup and teadrown should be called and executed from the main thread.
> > queries should not be started until those signals (and slots connected to
> > them) have been executed. there should be no threading involved at all at
> > this point.
>
> This means that while a query is executing, we can't emit the signals.

that's correct...

> Calling matchSessionComplete in the hide event of KRunnerDialog isn't
> safe in this case,

true...

> so I think the best place to do this would be in
> the destructor of FindMatchesJob. We'd check if the queue is empty,
> and if it is then we can emit the teardown signal.

there'd be some corner cases there, such as if there are no FindMatchesJobs 
when teardown is requested ... how about in RunnerManagerPrivate::jobDone()? 
see attached patch... 

the only downside to this approach in general is that one long-running runner 
(or never returning, even) could indefinitely delay teardown happening for 
other runners. it would be possible to do per-runner bookkeeping if this every 
becomes a real issue.

> > there'd be no point to these signals at all then and runners would just
> > do all their data gathering in (or just before) match(). that would be
> > too slow. the point of these signals is to do the setup and teardown as
> > rarely as possible, but also only when the data will be used.
>
> Agreed, but the use case that came to mind while I was writing this
> e-mail is that of the window runner. It caches the data once a query
> is launched but the data may become invalid while the dialog is open
> (e.g. an application is launched/closed while the dialog is open). But
> this is an issue addressable in the runner implementation.

yes; in this case the setup/teardown lets the runner know that it should start 
watching for those changes as well. if the data can't be trusted between runs 
(meaning that there is no way to detect changes and the data may change) then 
the runner will have to re-load the data in match no matter what we do :)

-- 
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 Software
Index: runnermanager.cpp
===
--- runnermanager.cpp	(revision 1003540)
+++ runnermanager.cpp	(working copy)
@@ -57,7 +57,8 @@
 RunnerManagerPrivate(RunnerManager *parent)
   : q(parent),
 deferredRun(0),
-prepped(false)
+prepped(false),
+teardownRequested(false)
 {
 matchChangeTimer.setSingleShot(true);
 delayTimer.setSingleShot(true);
@@ -197,8 +198,28 @@
 // ourselves here
 emit q->matchesChanged(context.matches());
 }
+
+checkTearDown();
 }
 
+void checkTearDown()
+{
+//kDebug() << prepped << teardownRequested << searchJobs.count() << oldSearchJobs.count();
+
+if (!prepped || !teardownRequested) {
+return;
+}
+
+if (searchJobs.isEmpty() && oldSearchJobs.isEmpty()) {
+foreach (AbstractRunner *runner, runners) {
+emit runner->teardown();
+}
+
+prepped = false;
+teardownRequested = false;
+}
+}
+
 void unblockJobs()
 {
 // WORKAROUND: Queue an empty job to force ThreadWeaver to awaken threads
@@ -222,6 +243,7 @@
 KConfigGroup config;
 bool loadAll : 1;
 bool prepped : 1;
+bool teardownRequested : 1;
 };
 
 /*
@@ -329,6 +351,8 @@
 
 void RunnerManager::setupMatchSession()
 {
+d->teardownRequested = false;
+
 if (d->prepped) {
 return;
 }
@@ -345,11 +369,9 @@
 return;
 }
 
-foreach (AbstractRunner *runner, d->runners) {
-emit runner->teardown();
-}
-
-d->prepped = false;
+kDebug() << "tearing down";
+d->teardownRequested = true;
+d->checkTearDown();
 }
 
 void RunnerManager::launchQuery(const QString &term)
@@ -480,6 +502,7 @@
 }
 
 d->context.reset();
+d->checkTearDown();
 }
 
 } // Plasma namespace


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: [PATCH] BUG 189643 Taskbar should be animated while program is starting

[Aaron J. Seigo]

On Wednesday 29 July 2009, 潘卫平 wrote:
> Third, I set the BusyWidgest's geometry in AbstractTaskItem::drawTask(),
> so it can get the proper geometry.

patch looks good; i only wonder if there's a better place to put the 
setGeometry for the busy widget than in a paintEvent, but this seems like it 
should be alright and probably as good as any other.

thanks for the patch, please commit :)

-- 
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 Software


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: Issues with setupMatchSession/matchSessionComplete in RunnerManager

[Ryan P. Bitanga]

On Thu, Jul 30, 2009 at 12:43 AM, Aaron J. Seigo wrote:
> On Wednesday 29 July 2009, Ryan P. Bitanga wrote:
>> Because we can launch a new query while jobs for an existing query are
>> still executing, any slots that are connected to prepare and teardown
>> have to be threadsafe.
>
> setup and teadrown should be called and executed from the main thread. queries
> should not be started until those signals (and slots connected to them) have
> been executed. there should be no threading involved at all at this point.
>

This means that while a query is executing, we can't emit the signals.
Calling matchSessionComplete in the hide event of KRunnerDialog isn't
safe in this case, so I think the best place to do this would be in
the destructor of FindMatchesJob. We'd check if the queue is empty,
and if it is then we can emit the teardown signal.

>> Another issue is that teardown is currently only emitted when the
>> dialog is hidden. I think the assumption was that there would be a one
>> to one correspondence between emissions of prepare and teardown.
>> However, with the current implementation, prepare will most likely be
>> emitted several more times than teardown.
>
> no, they are paired.
Yep, as noted in a previous e-mail, my bad.

>> or we could emit teardown prior to launching a new query. Say in
>
> there'd be no point to these signals at all then and runners would just do all
> their data gathering in (or just before) match(). that would be too slow. the
> point of these signals is to do the setup and teardown as rarely as possible,
> but also only when the data will be used.
>
Agreed, but the use case that came to mind while I was writing this
e-mail is that of the window runner. It caches the data once a query
is launched but the data may become invalid while the dialog is open
(e.g. an application is launched/closed while the dialog is open). But
this is an issue addressable in the runner implementation.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [PATCH] BUG 189643 Taskbar should be animated while program is starting

[潘卫平]

Aaron J. Seigo 写道:
> On Thursday 23 July 2009, 潘卫平(Peter Pan) wrote:
>> Taht will cover the icon and looks mussy.
>> I prefer to let it over the text.
>
> hm.. ok, how about on the right side of the button then, where the # of
> windows usually appears when there are several windows grouped?
>
> also as for this:
>
> +QRectF rect = parentGroup()->tasksLayout()->contentsRect();
> +int rowCount = parentGroup()->tasksLayout()->rowCount();
> +qreal height = rect.height() / rowCount;
> +QSizeF size(height, height);
>
> it should be able to just position it relative to the task button itself,
> something like this which would make it consistent with the group number
> drawing as well:
>
> Plasma::FrameSvg *itemBackground = m_applet->itemBackground();
> QSizeF busySize(itemBackground->elementSize(expanderElement()));
> QRectF animationRect(QPointF(size().width() - busySize.width(),
(size.height()
> - busySize.height())  / 2), busySize);
>
> even with this code, however, if the size of the button changes while the
app
> is launching the busy widget will no longer be in the right place.
>
> so ... either the positioning code should be put into a separate method
and be
> called from both startStartupAnimation and resizeEvent or a layout should
be
> used to manage that for us. a layout is probably overkill in this
situation,
> though.
>
>
>
> 
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel

Fisrt, I prefer to use Plasma::BusyWidget, consistent with others.

Second, I prefer to replace icon when the app is starting up, like
firefox when it is opening a new website.

Third, I set the BusyWidgest's geometry in AbstractTaskItem::drawTask(),
so it can get the proper geometry.

Best regards!


-- 
潘卫平(Peter Pan)
Index: abstracttaskitem.cpp
===
--- abstracttaskitem.cpp	（版本 1004126）
+++ abstracttaskitem.cpp	（工作副本）
@@ -586,26 +586,34 @@
 
 QRectF bounds = boundingRect().adjusted(m_applet->itemLeftMargin(), m_applet->itemTopMargin(), -m_applet->itemRightMargin(), -m_applet->itemBottomMargin());
 
-if ((!m_animId && ~option->state & QStyle::State_MouseOver) ||
- (m_oldBackgroundPrefix != "hover" && m_backgroundPrefix != "hover")) {
-m_icon.paint(painter, iconRect(bounds).toRect());
+WindowTaskItem *window = qobject_cast(this);
+QGraphicsWidget *busyWidget;
+busyWidget = window ? window->busyWidget() : 0;
+
+if (busyWidget) {
+busyWidget->setGeometry(iconRect(bounds));
+busyWidget->show();
 } else {
-KIconEffect *effect = KIconLoader::global()->iconEffect();
-QPixmap result = m_icon.pixmap(iconRect(bounds).toRect().size());
+if ((!m_animId && ~option->state & QStyle::State_MouseOver) 
+||(m_oldBackgroundPrefix != "hover" && m_backgroundPrefix != "hover")) {
+m_icon.paint(painter, iconRect(bounds).toRect());
+} else {
+KIconEffect *effect = KIconLoader::global()->iconEffect();
+QPixmap result = m_icon.pixmap(iconRect(bounds).toRect().size());
 
-if (effect->hasEffect(KIconLoader::Desktop, KIconLoader::ActiveState)) {
-if (qFuzzyCompare(qreal(1.0), m_alpha)) {
-result = effect->apply(result, KIconLoader::Desktop, KIconLoader::ActiveState);
-} else {
-result = Plasma::PaintUtils::transition(
-result,
-effect->apply(result, KIconLoader::Desktop,
-  KIconLoader::ActiveState), m_fadeIn?m_alpha:1-m_alpha);
+if (effect->hasEffect(KIconLoader::Desktop, KIconLoader::ActiveState)) {
+if (qFuzzyCompare(qreal(1.0), m_alpha)) {
+result = effect->apply(result, KIconLoader::Desktop, KIconLoader::ActiveState);
+} else {
+result = Plasma::PaintUtils::transition(result,
+effect->apply(result, KIconLoader::Desktop,
+KIconLoader::ActiveState), m_fadeIn?m_alpha:1-m_alpha);
+}
 }
+painter->drawPixmap(iconRect(bounds).topLeft(), result);
 }
-painter->drawPixmap(iconRect(bounds).topLeft(), result);
 }
-
+
 painter->setPen(QPen(textColor(), 1.0));
 
 QRect rect = textRect(bounds).toRect();
Index: windowtaskitem.cpp
===
--- windowtaskitem.cpp	（版本 1004126）
+++ windowtaskitem.cpp	（工作副本）
@@ -60,7 +60,8 @@
 
 WindowTaskItem::WindowTaskItem(QGraphicsWidget *parent, Tasks *applet)
 : AbstractTaskItem(parent, applet),
-  m_task(0)
+  m_task(0),
+  m_busyWidget(0)
 {
 }
 
@@ -239,6 +240,11 @@
 connect(task, SIGNAL(gotT

Re: Issues with setupMatchSession/matchSessionComplete in RunnerManager

[Aaron J. Seigo]

On Wednesday 29 July 2009, Ryan P. Bitanga wrote:
> Because we can launch a new query while jobs for an existing query are
> still executing, any slots that are connected to prepare and teardown
> have to be threadsafe.

setup and teadrown should be called and executed from the main thread. queries 
should not be started until those signals (and slots connected to them) have 
been executed. there should be no threading involved at all at this point.

> Another issue is that teardown is currently only emitted when the
> dialog is hidden. I think the assumption was that there would be a one
> to one correspondence between emissions of prepare and teardown.
> However, with the current implementation, prepare will most likely be
> emitted several more times than teardown.

no, they are paired.

> or we could emit teardown prior to launching a new query. Say in

there'd be no point to these signals at all then and runners would just do all 
their data gathering in (or just before) match(). that would be too slow. the 
point of these signals is to do the setup and teardown as rarely as possible, 
but also only when the data will be used.

-- 
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 Software


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: KDE MicroBlog (Twitter) update doesn't work

[Ryan P. Bitanga]

It had nothing to do with the dataengine or anywhere in the service
framework. Someone accidentally commented out a line in the applet. I
committed the fix. checkout r1004151 of the applet.

On Wed, Jul 29, 2009 at 8:01 PM, Ryan P. Bitanga wrote:
> On Wed, Jul 29, 2009 at 6:41 PM, Gerhard
> Gappmeier wrote:
>>
>>
>> No, I'm directly connected to the Internet, no proxy. Receiving messages
>> works.
>>
>> Have you tested with Twitter, or with identica?
>
> I tested both before but I svn up'd to 1003809 and compiled everything
> just now and I'm getting the same problem. Since the dataengine hasn't
> changed since I last successfully tested it, you could be right that
> it's a problem elsewhere.
>
>>
>> May there be any other side effects with changes in the service framework,
>> twitter API, or just configuration files for twitter, that may corrupt
>> things?
>>
>> If you tell me where the configuration is stored, I could delete this files,
>> and recreate my µBlog configuration.

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

Re: KDE MicroBlog (Twitter) update doesn't work

[Ryan P. Bitanga]

On Wed, Jul 29, 2009 at 6:41 PM, Gerhard
Gappmeier wrote:
>
>
> No, I'm directly connected to the Internet, no proxy. Receiving messages
> works.
>
> Have you tested with Twitter, or with identica?

I tested both before but I svn up'd to 1003809 and compiled everything
just now and I'm getting the same problem. Since the dataengine hasn't
changed since I last successfully tested it, you could be right that
it's a problem elsewhere.

>
> May there be any other side effects with changes in the service framework,
> twitter API, or just configuration files for twitter, that may corrupt
> things?
>
> If you tell me where the configuration is stored, I could delete this files,
> and recreate my µBlog configuration.
I ran on fresh config and encountered the same problem but the
password should be in kwallet and the config is in
plasma-desktop-appletsrc. :-/

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

Re: Issues with setupMatchSession/matchSessionComplete in RunnerManager

[Ryan P. Bitanga]

On Wed, Jul 29, 2009 at 7:17 PM, Martin Gräßlin 
wrote:
> Am Mittwoch 29 Juli 2009 12:53:56 schrieb Ryan P. Bitanga:
>> Another issue is that teardown is currently only emitted when the
>> dialog is hidden. I think the assumption was that there would be a one
>> to one correspondence between emissions of prepare and teardown.
>> However, with the current implementation, prepare will most likely be
>> emitted several more times than teardown. This poses problems for the
>> new window runner which only clears the data after the teardown signal
>> is emitted. It ends up with too much obsolete data.
> As I commented on Aaron's review request: currently teardown signal is never
> fired. And with the prepped bool it should be ensurable that prepare is only
> fired when there has been a teardown before (which is also currently not
> working ;-)). If those two points are fixed there is no problem.
>>
Hmm... The signal is supposed to be fired after the dialog is closed.
If you left the dialog open while testing the signal won't be fired.

And yep, you're right, prepare is only fired once and won't be fired
again until after someone calls matchSessionComplete. I was coming
from the assumption prepare should be launched everytime a query
changes so i missed that initially... Oops. :) So I think the question
now is should there really be a one to one correspondence between the
two? I think it'd be better if there were multiple prepare signals
instead since the slots are supposed to be thread safe and mutex locks
take time, plus things would be slightly faster by avoiding a call to
a slot.

>> We could leave it up to the runner author to make sure that methods
>> connected to the prepare signal clear obsolete data when the query
>> changes.
>>
>> e.g. assuming setupMatch() is connected to prepare and matchComplete()
>> is connected to teardown
>> void Foo::setupMatch()
>> {
>>     QMutexLocker l(&m_mutex);
>>     // If the query changed before teardown was emitted get rid of the old
>> stuff if (data.count()) {
>>         matchComplete();
>>     }
>>     ...
>> }
>>
>> or we could emit teardown prior to launching a new query. Say in
>> RunnerManager::setupMatchSession() add
>> if (d->prepped) {
>>     matchSessionComplete();
>> }
> I think that is not a good idea. For example the windows runner: it caches all
> icons and window information. That cache should be cleared as soon as the
> query session ended.

The question here is _when_ is the query session over? For some
instances (since we're running in multiple threads), the match()
method won't even be executed because a newer query arrived. Ideally,
we should fire teardown once all the jobs for that particular query
are done. But given we can launch a new query anytime, do we fire the
teardown signal immediately before we launch a new query (the second
option) or do we expect runners to realize they can get multiple
prepare signals and work around it (the first option)?

And oh, since my net conked out before I could post my reply in
reviewboard and I was too lazy to type everything all over again, I
know you are a kwin dev and thanks for coverswitch XD

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

Re: Issues with setupMatchSession/matchSessionComplete in RunnerManager

[Martin Gräßlin]

Am Mittwoch 29 Juli 2009 12:53:56 schrieb Ryan P. Bitanga:
> Hi all,
>
> I should have thought of this sooner, but upon taking a closer look at
> the code, I just realized that we have a few issues with the whole
> setup/teardown scenario.
>
> Because we can launch a new query while jobs for an existing query are
> still executing, any slots that are connected to prepare and teardown
> have to be threadsafe. If a runner deletes something because the
> teardown signal was emitted while a job is still being executed, it's
> possible that the runner may misbehave. In practice that shouldn't be
> much of an issue because we could care less what the old instance
> returns but we need to make this clear in the documentation to avoid
> things like dereferencing null pointers.
>
> Another issue is that teardown is currently only emitted when the
> dialog is hidden. I think the assumption was that there would be a one
> to one correspondence between emissions of prepare and teardown.
> However, with the current implementation, prepare will most likely be
> emitted several more times than teardown. This poses problems for the
> new window runner which only clears the data after the teardown signal
> is emitted. It ends up with too much obsolete data.
As I commented on Aaron's review request: currently teardown signal is never 
fired. And with the prepped bool it should be ensurable that prepare is only 
fired when there has been a teardown before (which is also currently not 
working ;-)). If those two points are fixed there is no problem.
>
> We could leave it up to the runner author to make sure that methods
> connected to the prepare signal clear obsolete data when the query
> changes.
>
> e.g. assuming setupMatch() is connected to prepare and matchComplete()
> is connected to teardown
> void Foo::setupMatch()
> {
> QMutexLocker l(&m_mutex);
> // If the query changed before teardown was emitted get rid of the old
> stuff if (data.count()) {
> matchComplete();
> }
> ...
> }
>
> or we could emit teardown prior to launching a new query. Say in
> RunnerManager::setupMatchSession() add
> if (d->prepped) {
> matchSessionComplete();
> }
I think that is not a good idea. For example the windows runner: it caches all 
icons and window information. That cache should be cleared as soon as the 
query session ended.


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

Issues with setupMatchSession/matchSessionComplete in RunnerManager

[Ryan P. Bitanga]

Hi all,

I should have thought of this sooner, but upon taking a closer look at
the code, I just realized that we have a few issues with the whole
setup/teardown scenario.

Because we can launch a new query while jobs for an existing query are
still executing, any slots that are connected to prepare and teardown
have to be threadsafe. If a runner deletes something because the
teardown signal was emitted while a job is still being executed, it's
possible that the runner may misbehave. In practice that shouldn't be
much of an issue because we could care less what the old instance
returns but we need to make this clear in the documentation to avoid
things like dereferencing null pointers.

Another issue is that teardown is currently only emitted when the
dialog is hidden. I think the assumption was that there would be a one
to one correspondence between emissions of prepare and teardown.
However, with the current implementation, prepare will most likely be
emitted several more times than teardown. This poses problems for the
new window runner which only clears the data after the teardown signal
is emitted. It ends up with too much obsolete data.

We could leave it up to the runner author to make sure that methods
connected to the prepare signal clear obsolete data when the query
changes.

e.g. assuming setupMatch() is connected to prepare and matchComplete()
is connected to teardown
void Foo::setupMatch()
{
QMutexLocker l(&m_mutex);
// If the query changed before teardown was emitted get rid of the old stuff
if (data.count()) {
matchComplete();
}
...
}

or we could emit teardown prior to launching a new query. Say in
RunnerManager::setupMatchSession() add
if (d->prepped) {
matchSessionComplete();
}

Thoughts?

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

Re: KDE MicroBlog (Twitter) update doesn't work

[Gerhard Gappmeier]

Ryan P. Bitanga schrieb:
> On Wed, Jul 29, 2009 at 5:49 PM, Ryan P. Bitanga 
> wrote:
>   
>> On Wed, Jul 29, 2009 at 4:11 PM, Gerhard
>> Gappmeier wrote:
>> 
>>> I reverted back to 974104 (2009-05-28), before a bigger change was done, but
>>> this also didn't work.
>>>
>>> So I took a look at the code to see how updates are sent.
>>> Unfortunetly this doesn't happen in the dataengine itself.
>>> It uses Plasma Services, a more general service framework.
>>>
>>> I've no clue about how to investigate this further, but I think it's very
>>> likely that it has nothing to do with dataengine itself, but maybe with this
>>> service framework, or at least with how this framework is used.
>>>
>>> I also sniffed the network traffic using Wireshark.
>>> I can see the traffic when the plasmoid receives messages.
>>> But when I send an "update" not even a TCP connection gets established. So
>>> nothing happens at all.
>>>
>>> I hope this information helps you to further investigate the problem.
>>>
>>>   
> Come to think of it, I know aseigo tested it after he commited some
> changes just before the replies support was added to the dataengine.
> I've been able to successfully test it as well. Any special
> configuration with your network?
>   
No, I'm directly connected to the Internet, no proxy. Receiving messages
works.

Have you tested with Twitter, or with identica?

May there be any other side effects with changes in the service framework,
twitter API, or just configuration files for twitter, that may corrupt
things?

If you tell me where the configuration is stored, I could delete this files,
and recreate my µBlog configuration.
> - Ryan
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>   


-- 
mit freundlichen Grüßen / best regards

*Gerhard Gappmeier*
ascolab GmbH - automation systems communication laboratory
Tel.: +49 9131 691 123
Fax: +49 9131 691 128
Web: http://www.ascolab.com
GPG-Key: http://www.ascolab.com/gpg/gg.asc

--
*ascolab GmbH*
Geschäftsführer: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrauß
Sitz der Gesellschaft: Am Weichselgarten 7 • 91058 Erlangen • Germany
Registernummer: HRB 9360
Registergericht: Amtsgericht Fürth



signature.asc
Description: OpenPGP digital signature
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE MicroBlog (Twitter) update doesn't work

[Ryan P. Bitanga]

On Wed, Jul 29, 2009 at 5:49 PM, Ryan P. Bitanga wrote:
> On Wed, Jul 29, 2009 at 4:11 PM, Gerhard
> Gappmeier wrote:
>>
>> I reverted back to 974104 (2009-05-28), before a bigger change was done, but
>> this also didn't work.
>>
>> So I took a look at the code to see how updates are sent.
>> Unfortunetly this doesn't happen in the dataengine itself.
>> It uses Plasma Services, a more general service framework.
>>
>> I've no clue about how to investigate this further, but I think it's very
>> likely that it has nothing to do with dataengine itself, but maybe with this
>> service framework, or at least with how this framework is used.
>>
>> I also sniffed the network traffic using Wireshark.
>> I can see the traffic when the plasmoid receives messages.
>> But when I send an "update" not even a TCP connection gets established. So
>> nothing happens at all.
>>
>> I hope this information helps you to further investigate the problem.
>>
Come to think of it, I know aseigo tested it after he commited some
changes just before the replies support was added to the dataengine.
I've been able to successfully test it as well. Any special
configuration with your network?

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

Re: KDE MicroBlog (Twitter) update doesn't work

[Ryan P. Bitanga]

On Wed, Jul 29, 2009 at 4:11 PM, Gerhard
Gappmeier wrote:
> Hi
>
> for while now I'm not able to send updates to Twitter using the MicroBlog
> plasmoid, whereas receiving messages works.
>
> Yesterday I reverted the microblog dataengine to older versions to see when it
> was broken.
>
> @aseigo, thx for your hint, but rev 995814 has not broken it. Also a previous
> version didn't work.

Not surprised there, 995814 had nothing to do with sending messages.
It simply added the capability to receive replies and direct messages.
:)

>
> I reverted back to 974104 (2009-05-28), before a bigger change was done, but
> this also didn't work.
>
> So I took a look at the code to see how updates are sent.
> Unfortunetly this doesn't happen in the dataengine itself.
> It uses Plasma Services, a more general service framework.
>
> I've no clue about how to investigate this further, but I think it's very
> likely that it has nothing to do with dataengine itself, but maybe with this
> service framework, or at least with how this framework is used.
>
> I also sniffed the network traffic using Wireshark.
> I can see the traffic when the plasmoid receives messages.
> But when I send an "update" not even a TCP connection gets established. So
> nothing happens at all.
>
> I hope this information helps you to further investigate the problem.
>
> --

I'll look into it shortly since I'm working on something else for the
microblog dataengine right now :)

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

Re: Review Request: Add next and previous buttons to Frame applet

[Sebastian Kügler]

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

Ship it!


Patch looks fine, other than some minor coding style things, it's good to go IMO


trunk/KDE/kdeplasma-addons/applets/frame/slideshow.cpp


we use braces also for single indented lines



trunk/KDE/kdeplasma-addons/applets/frame/slideshow.cpp


braces please also for single lines


- Sebastian


On 2009-07-28 20:22:17, Arthur Mello wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1028/
> ---
> 
> (Updated 2009-07-28 20:22:17)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> As mentioned on Frame TODO this patch adds buttons to navigate through slide 
> show.
> Buttons appear when mouse is over applet and only when applet is doing a 
> slideshow.
> Example code at TODO put the buttons above the pictue, I placed them on left 
> and right borders, but I can change this if necessary.   
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdeplasma-addons/applets/frame/frame.h 1003781 
>   trunk/KDE/kdeplasma-addons/applets/frame/frame.cpp 1003781 
>   trunk/KDE/kdeplasma-addons/applets/frame/slideshow.h 1003781 
>   trunk/KDE/kdeplasma-addons/applets/frame/slideshow.cpp 1003781 
> 
> Diff: http://reviewboard.kde.org/r/1028/diff
> 
> 
> Testing
> ---
> 
> 
> Screenshots
> ---
> 
> Slide show buttons
>   http://reviewboard.kde.org/r/1028/s/155/
> 
> 
> Thanks,
> 
> Arthur
> 
>

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

Re: Conky

[David Baron]

On Wednesday 29 July 2009 00:08:45 Aaron J. Seigo wrote:
> On Tuesday 28 July 2009, David Baron wrote:
> > This is a very versatile, configurable system/email/xmms2/you-name-it
>
> i've read reviews about it and it seems very un-user-friendly in it's
> configuration. what does it have that our plasmoids don't currently have,
> exactly?

Just a thought. Once one gets over the manual configuration part, one applet 
can take the place of several different monitors. Of, course, a UI for the 
configuration could be provided.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

KDE MicroBlog (Twitter) update doesn't work

[Gerhard Gappmeier]

Hi

for while now I'm not able to send updates to Twitter using the MicroBlog 
plasmoid, whereas receiving messages works.

Yesterday I reverted the microblog dataengine to older versions to see when it 
was broken.

@aseigo, thx for your hint, but rev 995814 has not broken it. Also a previous 
version didn't work.

I reverted back to 974104 (2009-05-28), before a bigger change was done, but 
this also didn't work.

So I took a look at the code to see how updates are sent.
Unfortunetly this doesn't happen in the dataengine itself.
It uses Plasma Services, a more general service framework.

I've no clue about how to investigate this further, but I think it's very 
likely that it has nothing to do with dataengine itself, but maybe with this 
service framework, or at least with how this framework is used.

I also sniffed the network traffic using Wireshark.
I can see the traffic when the plasmoid receives messages.
But when I send an "update" not even a TCP connection gets established. So 
nothing happens at all.

I hope this information helps you to further investigate the problem.

-- 

mit freundlichen Grüßen / best regards

Gerhard Gappmeier
ascolab GmbH - automation system communication laboratory
Tel.: +49 9131 691 123
Fax: +49 9131 691 128
Web: http://www.ascolab.com
GPG Fingerprint: 967A 15F1 2788 164D CCA3 6C46 07CD 6F82 5AAC 50C4



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