On July 13, 2010 22:46:52 Nate C wrote:
Is there any equivelent to QGraphicsWidget::closeEvent for a plasma
applet. I need to shutdown a QThread on the close event, but can not
figure anything out. Plasma::Applet subclasses QGraphicsWidget, so
should I not get it for free? (I am using the
On July 13, 2010, Aaron J. Seigo wrote:
On July 11, 2010, Thomas Fjellstrom wrote:
I kind-of agree, I still can't figure out how to remove widgets once
they've been lost. There's no remove button in the new selector like
there used to be.
not relevant. widgets shouldn't get lost in the
On July 13, 2010, Aaron J. Seigo wrote:
On July 12, 2010, Markus Slopianka wrote:
I had absolutely no problems with the 4.3 one.
i'm glad. but we had problems with it elsewhere. we need a consistent UI
that works everywhere:
* with panels (with a high degree of visual affinity)
* with
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4623/#review6553
---
Ship it!
go for it
- Marco
On 2010-07-13 19:09:06, Manuel
On Wednesday 14 July 2010, Nate C wrote:
Is there any equivelent to QGraphicsWidget::closeEvent for a plasma
applet. I need to shutdown a QThread on the close event, but can not
figure anything out. Plasma::Applet subclasses QGraphicsWidget, so
should I not get it for free? (I am using the
Hi Ivan,
On 07/13/2010 03:13 PM, Ivan Čukić wrote:
1. The ActivityManager (KDED module) now accepts application name/id
when the application notifies it that it has opened a document (or any
other type of resource that has an url)
If the name is not specified, KWindowInfo is used to try and
On 2010-07-14 08:01:02, Marco Martin wrote:
go for it
commited and backported to 4.5
- Manuel
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4623/#review6553
On Wednesday 14 July 2010, Fathi Boudra wrote:
On Tue, Jul 13, 2010 at 11:09 PM, Marco Martin notm...@gmail.com wrote:
i fear the time is really tight and we should have stuff ready for
yesterday something that we really need is a set of meego packages of
4.5, or the current trunk, or
Hi Sebastian,
First of all, I hope you are on plasma-devel since a lot of people
didn't take me seriously concerning the cross-posting...
So applications need to notify it about opening a doc manually? I am
asking because I started implementing the exact same thing and we should
Yes, the apps
On 07/14/2010 11:53 AM, Ivan Čukić wrote:
First of all, I hope you are on plasma-devel since a lot of people
didn't take me seriously concerning the cross-posting...
did not find the thread in stupid thunderbird (if only kmail would work
again here)
So applications need to notify it about
On 07/13/2010 04:04 PM, Marco Martin wrote:
On Tue, Jul 13, 2010 at 3:55 PM, Ivan Čukić ivan.cu...@kde.org wrote:
On 13 July 2010 15:45, Marco Martin notm...@gmail.com wrote:
it must be done indeed.
but is it possible to automatically unlink it as well when the window
is detached from the
On 07/13/2010 09:57 PM, Aaron J. Seigo wrote:
On July 13, 2010, Ivan Čukić wrote:
a.s. This is a cross-post
Hi,
A few notifications and questions.
1. The ActivityManager (KDED module) now accepts application name/id
when the application notifies it that it has opened a document (or any
On Wednesday 14 July 2010 07:46:52 Nate C wrote:
Is there any equivelent to QGraphicsWidget::closeEvent for a plasma
applet. I need to shutdown a QThread on the close event, but can not
figure anything out. Plasma::Applet subclasses QGraphicsWidget, so
should I not get it for free? (I am using
would be a list of the tarball sources ok?
yeah.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
On Wednesday 14 July 2010, Ivan Čukić wrote:
Hi Sebastian,
First of all, I hope you are on plasma-devel since a lot of people
didn't take me seriously concerning the cross-posting...
So applications need to notify it about opening a doc manually? I am
asking because I started
2010/7/14 Bjoern Ricks bjoern.ri...@intevation.de:
Imho we should unify the package layout for all mobile platforms. I am not
sure if that is possible with different packaging system but we should give
it a try. Our packages for maemo are already installable and usable on the
N900. But nobody
Sebastian:
once more just so this is not forgotten: there is no need for ranking -
at least not on the data level - when linking the activity to the event
rather than to the file.
Agreed. The only problem I see is that we'll need much more complex
queries when sorting the results by usage.
On Wed, Jul 14, 2010 at 3:34 AM, Thomas Fjellstrom tfjellst...@shaw.ca wrote:
I see your point. But it seems like a bug that will pop up now and again,
and it would be nice to have a list of all the plasmoids/widgets that are
currently created so they can be removed, or re positioned if they
On Wednesday 14 July 2010, Ivan Čukić wrote:
Sebastian:
once more just so this is not forgotten: there is no need for ranking -
at least not on the data level - when linking the activity to the event
rather than to the file.
Agreed. The only problem I see is that we'll need much more
i think windows outside of the current activity should be hidden from the
taskbar, at least by default.
and this must be done in 4.5, otherwise will cause another ser revolt.
I agree. The current plan is to have it in 4.5.1 - Chani thinks it
would be risky to do it for .0 - not enough testing.
On Wednesday 14 July 2010 14:57:21 Marco Martin wrote:
i think windows outside of the current activity should be hidden from the
taskbar, at least by default.
and this must be done in 4.5, otherwise will cause another ser revolt.
From what I'm reading on the forums these days, it may happen,
On Wednesday 14 July 2010 15:00:40 Ivan Čukić wrote:
I agree. The current plan is to have it in 4.5.1 - Chani thinks it
would be risky to do it for .0 - not enough testing.
Can this be considered a somewhat official stance? If so I'll ping the
appropriate people so that this gets known in
On July 14, 2010, Artur Souza (MoRpHeUz) wrote:
On Wed, Jul 14, 2010 at 3:34 AM, Thomas Fjellstrom tfjellst...@shaw.ca
wrote:
I see your point. But it seems like a bug that will pop up now and
again, and it would be nice to have a list of all the
plasmoids/widgets that are currently
On 07/14/2010 02:32 PM, Ivan Čukić wrote:
Sebastian:
once more just so this is not forgotten: there is no need for ranking -
at least not on the data level - when linking the activity to the event
rather than to the file.
Agreed. The only problem I see is that we'll need much more complex
the problem is:
i think windows outside of the current activity should be hidden from the
taskbar, at least by default.
and this must be done in 4.5, otherwise will cause another ser revolt.
I agree that they should be hidden.
I'm not against doing it in 4.5, if someone can do it without
On July 14, 2010 05:32:18 Ivan Čukić wrote:
Sebastian:
once more just so this is not forgotten: there is no need for ranking -
at least not on the data level - when linking the activity to the event
rather than to the file.
Agreed. The only problem I see is that we'll need much more
On July 14, 2010 03:16:15 Sebastian Trüg wrote:
On 07/14/2010 11:53 AM, Ivan Čukić wrote:
First of all, I hope you are on plasma-devel since a lot of people
didn't take me seriously concerning the cross-posting...
did not find the thread in stupid thunderbird (if only kmail would work
I'm not against doing it in 4.5, if someone can do it without introducing bugs
I'm willing, but I'll need a hint - how to expose the things you did
to libtaskmanager?
--
While you were hanging yourself on someone else's words
Dying to believe in what you heard
I was staring straight into the
?event nuao:involves ?r . ?r relatedTo activity
(just a rough example)
The sorting is the complicated one - it should be done according to
some formula like this:
sort rating = number-of-times-used / log (days-from-last-usage)
(this formula was for when had only those two fields remembered,
On July 14, 2010, Thomas Fjellstrom wrote:
Normally I would agree. Do you volunteer to make sure the bug never appears
again?
yes, we do. now that we're at the point of such questions, though, it's safe
to say that this thread has reached the end of its ability to produce useful
input. let's
On July 13, 2010, Thomas Fjellstrom wrote:
You have to agree that a one size fit all solution /never/ fits all
scenarios.
we're not trying to. we're trying to fit the use cases that should be able to
be consolidated.
notably, mobile and app dashboard use are not included.
--
Aaron J. Seigo
On July 13, 2010, Thomas Fjellstrom wrote:
To explain, the data engine will do a DNS lookup, arp lookup, and a shell
out to ping (that runs for about 5 seconds per host), when an update is
requested. The data engine can not wait for them to finish, otherwise it'd
block for possibly (if DNS is
On July 14, 2010, Luca Beltrame wrote:
From what I'm reading on the forums these days, it may happen, as there is
already a lot of discussion on activities (sometimes heated).
this is not a good reason to make these kinds of decisions. being directed by
the popular topic of the day amongst a
On July 14, 2010, Luca Beltrame wrote:
From what I'm reading on the forums these days, it may happen, as there is
already a lot of discussion on activities (sometimes heated).
this is not a good reason to make these kinds of decisions. being directed by
the popular topic of the day amongst a
On July 14, 2010, Marco Martin wrote:
i think windows outside of the current activity should be hidden from the
taskbar, at least by default.
yes, that makes sense.
and this must be done in 4.5,
only if it can be done in a way that is sensible. it won't be able to be an
optional thing
On July 14, 2010, Marco Martin wrote:
just possible to retrieve uris of resources (and from the taskbar i can't
know what documents are open by a particular task...)
which is a bit of a design flaw imho. being able to know what URI(s) a window
is interacting with could be useful in so many
On July 14, 2010, Sebastian Trüg wrote:
The idea on my end is to create nuao:DesktopEvent instances which link
to the opened file and the application opening it. For the latter the
that sounds very sensible, and would get rid of the false positives due to
automatically associating files issue.
On July 14, 2010, Aaron J. Seigo wrote:
On July 13, 2010, Thomas Fjellstrom wrote:
To explain, the data engine will do a DNS lookup, arp lookup, and a
shell out to ping (that runs for about 5 seconds per host), when an
update is requested. The data engine can not wait for them to finish,
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4623/#review6561
---
On July 14, 2010, Artur Souza (MoRpHeUz) wrote:
The infrastructure that Bjoern already provides is awesome. You just
keep doing your job on trunk and the snapshots repository give you
updated packages every day or so! :D
where is this?
--
Aaron J. Seigo
humru othro a kohnu se
GPG
On July 14, 2010, Thomas Fjellstrom wrote:
I'm wondering if the Storage or newer Caching stuff would be a good fit for
my DataEngine.
For my DNS-SD discovery mechanism, I would like sources for hosts that go
off line to stick around after. I can fairly easily build some internal
caching
On July 14, 2010, Thomas Fjellstrom wrote:
one way around that is to not use the setData API in DataEngine, but to
instead create subclasses of DataContainer for each sourc. when all the
data is retreived, then the DataContainer can call checkForUpdate().
that should work better for your
On July 14, 2010, Aaron J. Seigo wrote:
On July 14, 2010, Thomas Fjellstrom wrote:
Normally I would agree. Do you volunteer to make sure the bug never
appears again?
yes, we do. now that we're at the point of such questions, though, it's
safe to say that this thread has reached the end of
On July 14, 2010, Ivan Čukić wrote:
On July 14, 2010, Luca Beltrame wrote:
From what I'm reading on the forums these days, it may happen, as there
is already a lot of discussion on activities (sometimes heated).
this is not a good reason to make these kinds of decisions. being
On July 14, 2010, Aaron J. Seigo wrote:
On July 14, 2010, Thomas Fjellstrom wrote:
I'm wondering if the Storage or newer Caching stuff would be a good fit
for my DataEngine.
For my DNS-SD discovery mechanism, I would like sources for hosts that
go off line to stick around after. I can
which is a bit of a design flaw imho. being able to know what URI(s) a window
It is not a design flaw, it is about the design not being used at the moment :)
Naturally, once the apps start using our new protocol, we'll have the
wid-uri association.
(this is the most awesome side effect of
SVN commit 1149977 by jacopods:
First attempt to get rid of the capacity bar in the device notifier: use a
Plasma::Meter with tooltips.
Screenshot: http://imagebin.ca/view/ccJ3dD.html
Feedback is more than welcome
CCMAIL:plasma-devel@kde.org
M +17 -17deviceitem.cpp
M +3 -2
Just for completeness: I already have a scoring algorithm that takes the
desktop events and a bunch of other criteria into account to score all
files and thus, guess which files are most important to the user.
Cheers,
Sebastian
On 07/14/2010 07:34 PM, Aaron J. Seigo wrote:
On July 14, 2010,
On 07/14/2010 07:03 PM, Ivan Čukić wrote:
?event nuao:involves ?r . ?r relatedTo activity
(just a rough example)
The sorting is the complicated one - it should be done according to
some formula like this:
sort rating = number-of-times-used / log (days-from-last-usage)
already done in
Just for completeness: I already have a scoring algorithm that takes the
desktop events and a bunch of other criteria into account to score all
files and thus, guess which files are most important to the user.
Ok then, no complaints from me :)
Cheerio
On 07/14/2010 06:09 PM, Chani wrote:
The suggestion thing was just an idea. You can also use the links to
show related documents for the activity. However, as the documents would
not be linked directly but via the event the link would automatically be
marked as being added automatically and
On July 14, 2010, Thomas Fjellstrom wrote:
On July 14, 2010, Aaron J. Seigo wrote:
On July 14, 2010, Thomas Fjellstrom wrote:
Normally I would agree. Do you volunteer to make sure the bug never
appears again?
yes, we do. now that we're at the point of such questions, though, it's
On Wed, Jul 14, 2010 at 2:42 PM, Aaron J. Seigo ase...@kde.org wrote:
where is this?
http://files.kolab.org/local/maemo/
Cheers,
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
On July 14, 2010, Aaron J. Seigo wrote:
On July 14, 2010, Thomas Fjellstrom wrote:
On July 14, 2010, Aaron J. Seigo wrote:
On July 14, 2010, Thomas Fjellstrom wrote:
Normally I would agree. Do you volunteer to make sure the bug never
appears again?
yes, we do. now that we're
On July 14, 2010, Jacopo De Simoi wrote:
SVN commit 1149977 by jacopods:
First attempt to get rid of the capacity bar in the device notifier: use a
Plasma::Meter with tooltips. Screenshot:
http://imagebin.ca/view/ccJ3dD.html
the screenshot looks nice; but i'm curious: what were the issues
On July 14, 2010, Jacopo De Simoi wrote:
SVN commit 1149977 by jacopods:
First attempt to get rid of the capacity bar in the device notifier: use a
Plasma::Meter with tooltips. Screenshot:
http://imagebin.ca/view/ccJ3dD.html
the screenshot looks nice; but i'm curious: what were the
On July 14, 2010, Jacopo De Simoi wrote:
On July 14, 2010, Jacopo De Simoi wrote:
SVN commit 1149977 by jacopods:
First attempt to get rid of the capacity bar in the device notifier:
use a Plasma::Meter with tooltips. Screenshot:
http://imagebin.ca/view/ccJ3dD.html
the
On Wed, Jul 14, 2010 at 1:26 PM, Aaron J. Seigo ase...@kde.org wrote:
and this must be done in 4.5,
only if it can be done in a way that is sensible. it won't be able to be an
optional thing because we can't introduce new strings in the 4.5 branch, so no
configuration UI is possible. so if it
On July 14, 2010, todd rme wrote:
On Wed, Jul 14, 2010 at 1:26 PM, Aaron J. Seigo ase...@kde.org wrote:
and this must be done in 4.5,
only if it can be done in a way that is sensible. it won't be able to be
an optional thing because we can't introduce new strings in the 4.5
branch, so
On Wednesday 14 July 2010, Ivan Čukić wrote:
which is a bit of a design flaw imho. being able to know what URI(s) a
window
It is not a design flaw, it is about the design not being used at the
moment :)
Naturally, once the apps start using our new protocol, we'll have the
wid-uri
FYI ...
but please take any discussion over to kde-edu :)
-- Forwarded Message --
Subject: [kde-edu]: plasma edu
Date: July 14, 2010
From: Aaron J. Seigo ase...@kde.org
To: kde-...@kde.org
hi everyone :)
at Akademy we had a very good meeting of people involved with various
On Wednesday 14 July 2010 07:39:10 Nate C wrote:
I went through the same thing a few days ago. I found this first block
on web somewhere. If the form factor is not planar then you know you
are in a panel. I did not have much luck with the popup extenders.
But, this will allow it to at least
On Wednesday 14 July 2010 20:10:42 Jacopo De Simoi wrote:
SVN commit 1149977 by jacopods:
First attempt to get rid of the capacity bar in the device notifier: use a
Plasma::Meter with tooltips. Screenshot:
http://imagebin.ca/view/ccJ3dD.html
No longer displays amount of free space --
On Tuesday 13 July 2010 22:35:50 Aaron J. Seigo wrote:
sorry, but it's not coming back.
Oh, then offloading all useful info into tooltips is good?
Is this how you definition of elegance?
___
Plasma-devel mailing list
Plasma-devel@kde.org
On Wednesday 14 July 2010 23:46:41 Jacopo De Simoi wrote:
No longer displays amount of free space -- regression.
Avoidable tooltips - Usability problem.
I agree, suggestions?
How about extending Plasma::Meter to show text/numbers in the progress bar?
Maybe it could look like the
On Wed, Jul 14, 2010 at 6:51 PM, Markus Slopianka marku...@kdemail.net wrote:
Oh, then offloading all useful info into tooltips is good?
Is this how you definition of elegance?
Constructive feedback is great, isn't it? It's awesome when every
developer out there has the right(tm) solution in
did you try __del__(this), so the destructor?
--
sebas
Thanks, __del__ gives me the chance to do tear down stuff.
Subclassing closeEvent(self) never gets called
Nate Carson
___
Plasma-devel mailing list
Plasma-devel@kde.org
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4554/
---
(Updated 2010-07-14 22:43:15.191097)
Review request for Plasma, Aaron Seigo,
On Thursday 15 July 2010 00:04:45 Artur Souza (MoRpHeUz) wrote:
Yep, it's way more elegant than having an icon with an i that when
clicked shows all the useful information.
In the old window as well as Aurelien's mockup the applet description is
visible right away, without the need to click i,
only thing that concernes me a bit is that this kind of association in kwin,
and in the kded seems a bit uhm separate
This is only temporary
--
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
Oh, and btw: It's impossible to click on URLs in those Plasma tooltips, while
it's perfectly possible in all other About windows.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
p.p.s. If you hadn't done anything related to Nepomuk Queries and ||,
, ! (and what else we had), I can start making a patch for it.
Already in trunk. :)
Fantastic :)
Exactly. My approach was rather similar to Ivan's I think: I have a dbus
service that handles all the events. Apps simply
On July 14, 2010, Markus Slopianka wrote:
Oh, and btw: It's impossible to click on URLs in those Plasma tooltips,
while it's perfectly possible in all other About windows.
Hmm, maybe a regression? It works here on 4.4.4.
___
Plasma-devel mailing
- Original message -
I take this as a proposal to remove the i from the systray.
Yes, thats exactly what I want: to prpose that. *Sigh*.
And the problem with the mockup isnt that it doesnt solve the issue of showing
the information but that it brings back all the problems we had with
On Wed 14 July 2010 4:09:08 pm Thomas Fjellstrom wrote:
On July 14, 2010, Markus Slopianka wrote:
Oh, and btw: It's impossible to click on URLs in those Plasma tooltips,
while it's perfectly possible in all other About windows.
Hmm, maybe a regression? It works here on 4.4.4.
As well as
On Wed 14 July 2010 8:41:57 am Marco Martin wrote:
just a reminder for everybody
meeting at 9:00 am UTC
tomorrow 15th
So..
I'm a ... how can I put this nicely? A dork. I'm a dork. Right before sending
my hey, yeah 9UTC WORKSFORME I sent a mail to another list who also had a
meeting at
On July 14, 2010 10:26:49 Aaron J. Seigo wrote:
On July 14, 2010, Marco Martin wrote:
i think windows outside of the current activity should be hidden from the
taskbar, at least by default.
yes, that makes sense.
and this must be done in 4.5,
only if it can be done in a way that is
what's all this event stuff? are you doing.. something like zeitgeist or
something?
indeed. Only integrated with Nepomuk and the semantic desktop. Allows
for some cool things.
oh? :)
point me to a blog post where I can read more! :)
___
On 07/14/2010 07:34 PM, Aaron J. Seigo wrote:
On July 14, 2010, Sebastian Trüg wrote:
The idea on my end is to create nuao:DesktopEvent instances which link
to the opened file and the application opening it. For the latter the
that sounds very sensible, and would get rid of the false
On July 14, 2010 21:15:23 Ryan Rix wrote:
On Wed 14 July 2010 8:41:57 am Marco Martin wrote:
just a reminder for everybody
meeting at 9:00 am UTC
tomorrow 15th
So..
I'm a ... how can I put this nicely? A dork. I'm a dork. Right before
sending my hey, yeah 9UTC WORKSFORME I sent a
80 matches
Mail list logo
