Re: Equivalent for closeEvent?
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 python bindings.) you mean when the applet is removed? well, it's destroyed then, so I assume making it the parent of the qthread would ensure the qthread is also destroyed... ohhh, but Note that deleting a QThread object will not stop the execution of the thread it represents - so... in C++ I would have the applet's destructor stop the qthread (except, I can't remember if the qthread's destructor will have been called before or after that)... alternatively, there's the destroyed() signal. not sure which'd be easier in python. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
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 first place (that would be a bug), and remove is pretty ambiguous in a world where we can pause activities. it was a stop gap feature, not a clear one to everyone, didn't have enough fine grained control. it was time to move on. 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 ever get lost. -- Thomas Fjellstrom tfjellst...@shaw.ca ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
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 the desktop * with the screen saver * with the dashboard * with netbook / tablet etc ... sorry, but it's not coming back. You have to agree that a one size fit all solution /never/ fits all scenarios. -- Thomas Fjellstrom tfjellst...@shaw.ca ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fixing painting of systemtray
--- 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 Mommertz wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4623/ --- (Updated 2010-07-13 19:09:06) Review request for Plasma. Summary --- Correct drawing code in systemtray. don't use rect() anymore as this rect doesn't contain borders in planar more and leads to drawing errors there. setting to same size as contentsRect. Right easment is currently not used and therefore removed from calculation. Qt::IntersectClip doesn't make sense here as this clips away the background for firstelements. For 4.6 I would completly rewrite the drawing code for better reading. But to not introduce new bugs in 4.5 in this late phase I want to get this patch for now. Diffs - /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/ui/applet.cpp 1148491 Diff: http://reviewboard.kde.org/r/4623/diff Testing --- Screenshots --- systray in floating layout. bottom with patch applied http://reviewboard.kde.org/r/4623/s/458/ Thanks, Manuel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Equivalent for closeEvent?
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 python bindings.) not sure about python, but yes, you should get it -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activities protocol
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 get it. 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 really not duplicate code. 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 ontology is not stable yet. This is something we should fix as soon as possible so that we can encode applications properly. The reason for this is to make it possible to keep track of recently opened resources (and all the stats/rating stuff Lukas is working on) on a per-application basis. KActivityConsumer uses QCoreApplication::applicationName() for this, so it is done 'behind a curtain'. 2. Does anyone have objections in automatically linking a resource (that the application reports is opened) with the current activity? From my point of view, it is something that should be done. This is how I think it should be done: rather than linking the file directly to the activity you should link the desktop event to the activity. That way the information is exact and can later be used to suggest the link between file and activity to the user. Cheers, Sebastian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fixing painting of systemtray
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 2010-07-13 19:09:06, Manuel Mommertz wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4623/ --- (Updated 2010-07-13 19:09:06) Review request for Plasma. Summary --- Correct drawing code in systemtray. don't use rect() anymore as this rect doesn't contain borders in planar more and leads to drawing errors there. setting to same size as contentsRect. Right easment is currently not used and therefore removed from calculation. Qt::IntersectClip doesn't make sense here as this clips away the background for firstelements. For 4.6 I would completly rewrite the drawing code for better reading. But to not introduce new bugs in 4.5 in this late phase I want to get this patch for now. Diffs - /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/ui/applet.cpp 1148491 Diff: http://reviewboard.kde.org/r/4623/diff Testing --- Screenshots --- systray in floating layout. bottom with patch applied http://reviewboard.kde.org/r/4623/s/458/ Thanks, Manuel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: definitions and package for plasma on meego
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 whatever. i don't have any knowledge whatsoever about packaging, but is the biggest thing -everyone- interested in it is asking I could do the packaging quickly if you point where are the source I should take. dude, that would be awesome! would be a list of the tarball sources ok? and, question for everybody, d we start with the regular full build or directly with a slimmed down version of kdelibs? (not everything builds yet?) It's part of my daily work (I maintain packages for MeeGo). what would be needed to use the obs would be either the own meego one to be opened (is it already?) or the suse obs to have meego as an available platform to build to MeeGo community OBS is in testing phase. The MeeGo target isn't ready yet. OpenSUSE OBS doesn't have MeeGo target. In the meantime, I could use MeeGo OBS (the closed one) to build the packages. that would speed up a lot when the community one will be open. all the building blocks would be already there. Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activities protocol
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 report the name, window id and the uri of the resource opened (be it a document, folder or some internal uri) really not duplicate code. This is in the ActivityManager kded module. 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 ontology is not stable yet. This is something we should fix as soon as possible so that we can encode applications properly. I wasn't going for anything this pedantic (was trying to limit the data and not remember every event) but it is fine with me to go that extra mile. This is how I think it should be done: rather than linking the file directly to the activity you should link the desktop event to the activity. That way the information is exact and can later be used to suggest the link between file and activity to the user. The problem I see here is /suggesting/. The user usually opens a lot of documents, and I wouldn't really like to have to ask him/her do you want to add this to the activity for every one. That is, if you have an idea about the UI that would make this job non-irritating, I'm more than happy to hear it. From my POV, I'd rather have a system that has 90% precision which doesn't ask the user anything than to have it 100% and annoys the user constantly. (something like the best package manager - Slackware's - aka the user :) ) (mind that this doesn't affect the usage of DesktopEvent) Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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 opening a doc manually? I am asking because I started implementing the exact same thing and we should Yes, the apps report the name, window id and the uri of the resource opened (be it a document, folder or some internal uri) really not duplicate code. This is in the ActivityManager kded module. I will have a look. 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 ontology is not stable yet. This is something we should fix as soon as possible so that we can encode applications properly. I wasn't going for anything this pedantic (was trying to limit the data and not remember every event) but it is fine with me to go that extra mile. It is worth it since then we have a lot more information to do cool things with. This is how I think it should be done: rather than linking the file directly to the activity you should link the desktop event to the activity. That way the information is exact and can later be used to suggest the link between file and activity to the user. The problem I see here is /suggesting/. The user usually opens a lot of documents, and I wouldn't really like to have to ask him/her do you want to add this to the activity for every one. That is, if you have an idea about the UI that would make this job non-irritating, I'm more than happy to hear it. From my POV, I'd rather have a system that has 90% precision which doesn't ask the user anything than to have it 100% and annoys the user constantly. (something like the best package manager - Slackware's - aka the user :) ) 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 thus, less important than a manually added one. When I say suggestion I do not necessarily mean to suggest the link between file and activity but any kind of suggestion. This includes suggesting the file when showing related stuff for an activity. Cheers, Sebastian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activities protocol
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 activity? Yes, but that would be undesired - if you open a file from an activity, it belongs to it. (and possibly other activities as well) The window containing the document, on the other side, gets unassociated when it doesn't hold the doc in question anymore. ok, but there should really be a mechanism to change the activities associated with an already opened document somehow. coupling it with the activities associated with the window that holds the document could be a good way As mentioned already on nepo...@kde.org, I think the activity relation needs to go into the event itself, not the file. That way we have an indirect relation between file and activity without forcing anything on the user. We can later use that relation in whatever way we want while keeping the file itself clean of any automatically added data. Cheers, Sebastian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activities protocol
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 other type of resource that has an url) If the name is not specified, KWindowInfo is used to try and get it. The reason for this is to make it possible to keep track of recently opened resources (and all the stats/rating stuff Lukas is working on) on a per-application basis. sounds good. 2. Does anyone have objections in automatically linking a resource (that the application reports is opened) with the current activity? this will lead to lots of false positives. a file i open from an email that gets sent to me stands a high likeliehood of having nothing to do with the activity i'm in. other examples abound. if automatic linking is implemented, then i think we'll end up needing a simple ranking system with documents that were automatically (passively?) linked by the system just due to being open with a low ranking, information that is accessed as a result of another item associated with an activity (e.g. if i have an app or window associated with an activity, then things opened with that app / window stand a high chance of being relevant) having a higher ranking and items actively marked as having the highest. 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. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Equivalent for closeEvent?
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 the python bindings.) did you try __del__(this), so the destructor? -- 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: definitions and package for plasma on meego
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
Re: Activities protocol
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 implementing the exact same thing and we should Yes, the apps report the name, window id and the uri of the resource opened (be it a document, folder or some internal uri) by the way, since this information is saved, is there a way given a window id to know if it's associated on a given activity (in particulr the current one) i was trying to hide from the taskbar the windows that don't belong to the current activity (there will be probably an option just like show only windows from current desktop) but there doesn't seem ways to retrieve this information api wise, seems just possible to retrieve uris of resources (and from the taskbar i can't know what documents are open by a particular task...) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: definitions and package for plasma on meego
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 did provide packages for plasma mobile yet. I am not familiar with rpm packaging yet but I would like to contribute for KDE PIM. +10 on this one. Let's try to use the same packages as most as possible (I know that different projects have different needs and this reflects in the way that kdelibs are compiled - platform profiles). But if we could use almost the same stuff, it would be *wonderful*. 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 Cheers! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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. Marco: by the way, since this information is saved, is there a way given a window id to know if it's associated on a given activity (in particulr the current one) No, currently the kwin activities part is totally separate from this system. Chani could probably tell you more. -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
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 ever get lost. If the bug pops up now and again, then there is something really wrong that should get fixed and not work arounded. I understand the I don't like it argument (besides not agreeing), but a bug that should never happen is not a pro argument for changing the add widgets dialog. Cheers, ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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 complex queries when sorting the results by usage. Marco: by the way, since this information is saved, is there a way given a window id to know if it's associated on a given activity (in particulr the current one) No, currently the kwin activities part is totally separate from this system. Chani could probably tell you more. 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. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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, as there is already a lot of discussion on activities (sometimes heated). Notice that again, I don't want to push anything: just that, if a decision on this is made, I'll make sure to propagate it to the interested parties so we know what to answer. 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: [Nepomuk] Activities protocol
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 time for PR and user communication purposes. 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: Scrollbars in add widget ui
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 created so they can be removed, or re positioned if they ever get lost. If the bug pops up now and again, then there is something really wrong that should get fixed and not work arounded. I understand the I don't like it argument (besides not agreeing), but a bug that should never happen is not a pro argument for changing the add widgets dialog. Normally I would agree. Do you volunteer to make sure the bug never appears again? Cheers, ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Thomas Fjellstrom tfjellst...@shaw.ca ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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 queries when sorting the results by usage. do the queries really have to be that more complicated. In the end it is one additional edge in the graph. Instead of checking for something like ?r relatedTo activity you do something like ?event nuao:involves ?r . ?r relatedTo activity (just a rough example) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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 introducing bugs :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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 complex queries when sorting the results by usage. Marco: by the way, since this information is saved, is there a way given a window id to know if it's associated on a given activity (in particulr the current one) No, currently the kwin activities part is totally separate from this system. Chani could probably tell you more. the kwin thing isn't saved at all right now. it's just stored in kwin, and lost when it restarts. I had hoped to make it persistent before 4.5 came out... but... on the other hand, I want more time to consider *how* it should be done, properly, and not rush in something that might turn out to be the wrong approach and need supporting forever. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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 again here) 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 report the name, window id and the uri of the resource opened (be it a document, folder or some internal uri) really not duplicate code. This is in the ActivityManager kded module. I will have a look. 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 ontology is not stable yet. This is something we should fix as soon as possible so that we can encode applications properly. I wasn't going for anything this pedantic (was trying to limit the data and not remember every event) but it is fine with me to go that extra mile. It is worth it since then we have a lot more information to do cool things with. This is how I think it should be done: rather than linking the file directly to the activity you should link the desktop event to the activity. That way the information is exact and can later be used to suggest the link between file and activity to the user. The problem I see here is /suggesting/. The user usually opens a lot of documents, and I wouldn't really like to have to ask him/her do you want to add this to the activity for every one. That is, if you have an idea about the UI that would make this job non-irritating, I'm more than happy to hear it. From my POV, I'd rather have a system that has 90% precision which doesn't ask the user anything than to have it 100% and annoys the user constantly. (something like the best package manager - Slackware's - aka the user :) ) 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 thus, less important than a manually added one. When I say suggestion I do not necessarily mean to suggest the link between file and activity but any kind of suggestion. This includes suggesting the file when showing related stuff for an activity. what's all this event stuff? are you doing.. something like zeitgeist or something? this is still something the application will have to support, I assume, so we probably want just one simple way for it to report the docuements it has open. in kwin, what I need is which activities are associated with this wid?, so that I can filter out windows that aren't on the current activity. there can be no levels here, no suggestion; either a window is shown or it is not. I mean, I have absolutely nothing against you guys using levels yourselves, it's just that kwin needs a simple yes/no when it asks. :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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 shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
?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, if we remember all events we'll be able to do something even more evil :) ) p.s. The kded module should stay clean from nepomuk, for the time being, and just delegate the things to nepomukactivitiesservice 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. -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
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 stop here. p.s. the javascript console lets you get to any plasmoid using scripting. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
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 humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: DataEngine and regular polling.
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 having issues) tens of seconds at a time, per host. So what should I do here? if a timeout is requested, but no data can be filled immediately, then once setData is called on the source, at that point the visualization should be notified. in your case, it sounds like there are multiple setData calls, however. so the first one probably triggers an update, and the subsequent ones (e.g. the ping) waits for the next timeout. 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 use case. 2. DataEngine::setPollingInterval seems to poll only once. yes, that's an engine-wide polling interval. I mean once period. I expected it to actually setup a regular poll, not a one shot timer. that was a bug; i've just fixed it. it now does set up a regular poll as it is supposed to :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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 subset of our user base doesn't work. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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 subset of our user base doesn't work. Well, this *is* something we already wanted, just didn't make it yet :) Cheerio -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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 because we can't introduce new strings in the 4.5 branch, so no configuration UI is possible. so if it is added, it needs to absolutely work because it will not only be the default ... it won't be able to be turned off. that said, i think it may make work well since it's an active user selection to associate the window with the activity, and the window won't be shown when a different activity is shown. what will likely end up becoming a requirement, however, is a way to show windows in other activities so that a person may find that krita window i had open ... without switching to every activity manually. that sounds a bit more like something for 4.6, though. otherwise will cause another ser revolt. a user revolt because the windows are shown in the taskbar? seriously? will some people complain? sure. will some throw tomatos at us because of it? sure, but those people will do that no matter what we do: they are just looking for an excuse. (and for that reason i have ~zero interest in and respect for them.) let's make decisions that make sense on their own merit, not because the peasants are revolting!. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activities protocol
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 ways. would be nice to see that information available from a wid. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activities protocol
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. files the user tags explicitly would be easily discernable from those that have a DesktopEvent. assuming that DesktopEvent allows for things such as counting the number of times that same event happens, it should even be possible to decrease the importance of files accessed just once or a long tme ago. +1 from me to our ontology overlords. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: DataEngine and regular polling.
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, otherwise it'd block for possibly (if DNS is having issues) tens of seconds at a time, per host. So what should I do here? if a timeout is requested, but no data can be filled immediately, then once setData is called on the source, at that point the visualization should be notified. in your case, it sounds like there are multiple setData calls, however. so the first one probably triggers an update, and the subsequent ones (e.g. the ping) waits for the next timeout. Yeah, the regular update will set off the dns check, and the much longer running ping call. each will be spaced several seconds apart. 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 use case. Hmm, so after I receive the updates from QHostInfo/QProcess, I should call checkForUpdate in my new custom DataContainer? 2. DataEngine::setPollingInterval seems to poll only once. yes, that's an engine-wide polling interval. I mean once period. I expected it to actually setup a regular poll, not a one shot timer. that was a bug; i've just fixed it. it now does set up a regular poll as it is supposed to :) Will the fix make it into 4.5? Temporarily I've added a regular timer to my data engine that calls a function that just loops over my internal list of found hosts, and calls their update method, which sets off the long running DNS/ping checks. -- Thomas Fjellstrom tfjellst...@shaw.ca ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fixing painting of systemtray
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4623/#review6561 --- /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/ui/applet.cpp http://reviewboard.kde.org/r/4623/#comment6318 these kinds of changes are really annoying. yes, rightEasement isn't used right now. but what if we do use it in the future? then we'll have to add this code back in. is the code that was removed a performance problem? no. was it unreadable? no. so why was it removed? just because. at one point, it ONLY supported rightEasement. when we had need for leftEasement, and switched over to that, both left and right easement calculation was kept so that we could easily change the right/left layout decisions later on down the road. now we're back to having an assumption in the code that we only have some special space on the left. please put the rightEasement code back in ASAP. - Aaron On 2010-07-13 19:09:06, Manuel Mommertz wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4623/ --- (Updated 2010-07-13 19:09:06) Review request for Plasma. Summary --- Correct drawing code in systemtray. don't use rect() anymore as this rect doesn't contain borders in planar more and leads to drawing errors there. setting to same size as contentsRect. Right easment is currently not used and therefore removed from calculation. Qt::IntersectClip doesn't make sense here as this clips away the background for firstelements. For 4.6 I would completly rewrite the drawing code for better reading. But to not introduce new bugs in 4.5 in this late phase I want to get this patch for now. Diffs - /trunk/KDE/kdebase/workspace/plasma/generic/applets/systemtray/ui/applet.cpp 1148491 Diff: http://reviewboard.kde.org/r/4623/diff Testing --- Screenshots --- systray in floating layout. bottom with patch applied http://reviewboard.kde.org/r/4623/s/458/ Thanks, Manuel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: definitions and package for plasma on meego
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 Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: DataEngine cache/storage
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 myself, but if plasma can provide a way to do it, that would probably be a better solution. while the DataEngine is alive, if a host goes off-line, then it's up to the DataEngine to not get rid of the source. between instances of the DataEngine being created (e.g. the DataEngine is created in response to a request by your applet, then the applet is removed, then it is added again; or between starts of plasma-desktop, etc.), the new DataEngine caching should indeed do the trick for you by keeping the last known data around. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: DataEngine and regular polling.
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 use case. Hmm, so after I receive the updates from QHostInfo/QProcess, I should call checkForUpdate in my new custom DataContainer? right. 2. DataEngine::setPollingInterval seems to poll only once. yes, that's an engine-wide polling interval. I mean once period. I expected it to actually setup a regular poll, not a one shot timer. that was a bug; i've just fixed it. it now does set up a regular poll as it is supposed to :) Will the fix make it into 4.5? yes, i backported it. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
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 its ability to produce useful input. let's stop here. I happen to think its a perfectly valid point. If you can't guarantee the bug won't reappear, an easily discoverable work around is going to have to be made for it. Just a little bit of brain storming, but some place, an interface showing a list of the current running plasmoids (one item per plasmoid instance), which when hovered over with the mouse cause them to be highlighted by plasma itself. It would make the most sense if it were to hide all normal windows, or bring plasma forward. Possibly tie it into the ZUI to show all current containments. That said, a much simpler and easier to implement idea would be to add back that minus button and just force people to add back instances they wanted (if theres more than one running). Maybe as an option. p.s. the javascript console lets you get to any plasmoid using scripting. And I'm sure its fully documented, easily discoverable, and understandable by mere users. -- Thomas Fjellstrom tfjellst...@shaw.ca ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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 directed by the popular topic of the day amongst a subset of our user base doesn't work. Well, this *is* something we already wanted, just didn't make it yet :) agreed; i just want to keep our motivations and reasons on the right track in the meantime :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: DataEngine cache/storage
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 fairly easily build some internal caching myself, but if plasma can provide a way to do it, that would probably be a better solution. while the DataEngine is alive, if a host goes off-line, then it's up to the DataEngine to not get rid of the source. between instances of the DataEngine being created (e.g. the DataEngine is created in response to a request by your applet, then the applet is removed, then it is added again; or between starts of plasma-desktop, etc.), the new DataEngine caching should indeed do the trick for you by keeping the last known data around. Ah. Ok. So I will have to add in some caching of my own. Thats too bad. Though I can see why it would be /hard/ for plasma to manage cached data while the data engine is still running. Thanks. -- Thomas Fjellstrom tfjellst...@shaw.ca ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activities protocol
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 activities for me - taskbar knowing the open documents) -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
KDE/kdebase/workspace/plasma/generic/applets/devicenotifier
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 deviceitem.h
---
trunk/KDE/kdebase/workspace/plasma/generic/applets/devicenotifier/deviceitem.cpp
#1149976:1149977
@@ -33,7 +33,6 @@
#include KStandardDirs
#include KDesktopFile
#include KGlobalSettings
-#include kcapacitybar.h
#include kdesktopfileactions.h
//Plasma
@@ -42,6 +41,7 @@
#include Plasma/BusyWidget
#include Plasma/ItemBackground
#include Plasma/Label
+#include Plasma/Meter
#include Plasma/Animator
#include Plasma/Animation
@@ -107,16 +107,16 @@
m_descriptionLabel-setOpacity(0);
updateColors();
-KCapacityBar *capacityBarWidget = new
KCapacityBar(KCapacityBar::DrawTextInline);
-m_capacityBar = new QGraphicsProxyWidget(this);
-m_capacityBar-setWidget(capacityBarWidget);
-capacityBarWidget-setAttribute(Qt::WA_TranslucentBackground);
-capacityBarWidget-setContinuous(true);
-m_capacityBar-setAcceptHoverEvents(false);
-m_capacityBar-setOpacity(0);
+
+m_freeSpaceBar = new Plasma::Meter();
+m_freeSpaceBar-setMeterType(Plasma::Meter::BarMeterHorizontal);
+m_freeSpaceBar-setLabelAlignment(0, Qt::AlignCenter);
+m_freeSpaceBar-setOpacity(0);
+m_freeSpaceBar-setMaximumHeight(12);
+
info_layout-addItem(m_nameLabel);
info_layout-addItem(m_descriptionLabel);
-info_layout-addItem(m_capacityBar);
+info_layout-addItem(m_freeSpaceBar);
m_leftActionIcon = new Plasma::IconWidget(this);
m_leftActionIcon-setMaximumSize(m_leftActionIcon-sizeFromIconSize(LEFTACTION_SIZE));
@@ -317,9 +317,9 @@
}
}
-const bool barVisible = m_capacityBar-isVisible();
-m_capacityBar-setVisible(m_mounted allowsCapacityBar());
-if (!barVisible m_capacityBar-isVisible()) {
+const bool barVisible = m_freeSpaceBar-isVisible();
+m_freeSpaceBar-setVisible(m_mounted allowsCapacityBar());
+if (!barVisible m_freeSpaceBar-isVisible()) {
// work around for a QGraphicsLayout bug when used with proxy widgets
m_mainLayout-invalidate();
}
@@ -360,7 +360,7 @@
m_barFade =
Plasma::Animator::create(Plasma::Animator::FadeAnimation, this);
m_labelFade-setTargetWidget(m_descriptionLabel);
-m_barFade-setTargetWidget(m_capacityBar);
+m_barFade-setTargetWidget(m_freeSpaceBar);
m_labelFade-setProperty(targetOpacity, 0);
m_barFade-setProperty(targetOpacity, 0);
@@ -378,15 +378,15 @@
void DeviceItem::setHoverDisplayOpacity(qreal opacity)
{
m_descriptionLabel-setOpacity(opacity);
-m_capacityBar-setOpacity(opacity);
+m_freeSpaceBar-setOpacity(opacity);
}
void DeviceItem::setFreeSpace(qulonglong freeSpace, qulonglong size)
{
qulonglong usedSpace = size - freeSpace;
-KCapacityBar *capacityBarWidget =
static_castKCapacityBar*(m_capacityBar-widget());
-capacityBarWidget-setText(i18nc(@info:status Free disk space, %1
free, KGlobal::locale()-formatByteSize(freeSpace)));
-capacityBarWidget-setValue(size 0 ? (usedSpace * 100) / size : 0);
+
+m_freeSpaceBar-setToolTip(i18nc(@info:status Free disk space, %1
free, KGlobal::locale()-formatByteSize(freeSpace)));
+m_freeSpaceBar-setValue(size 0 ? (usedSpace * 100) / size : 0);
}
void DeviceItem::leftActionClicked()
---
trunk/KDE/kdebase/workspace/plasma/generic/applets/devicenotifier/deviceitem.h
#1149976:1149977
@@ -33,6 +33,7 @@
class IconWidget;
class BusyWidget;
class Label;
+class Meter;
}
namespace Notifier
@@ -332,8 +333,8 @@
///The label that draws the description of the device
Plasma::Label *m_descriptionLabel;
-///The proxy hosting the capacity bar
-QGraphicsProxyWidget *m_capacityBar;
+///The meter that draws free space for the device
+Plasma::Meter *m_freeSpaceBar;
///The busy widget
Plasma::BusyWidget *m_busyWidget;
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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, 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. files the user tags explicitly would be easily discernable from those that have a DesktopEvent. assuming that DesktopEvent allows for things such as counting the number of times that same event happens, it should even be possible to decrease the importance of files accessed just once or a long tme ago. +1 from me to our ontology overlords. ___ Nepomuk mailing list nepo...@kde.org https://mail.kde.org/mailman/listinfo/nepomuk ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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 playground. :) This is targetted for 4.6 though. (this formula was for when had only those two fields remembered, if we remember all events we'll be able to do something even more evil :) ) and I do. :P p.s. The kded module should stay clean from nepomuk, for the time being, and just delegate the things to nepomukactivitiesservice maybe we could drop that for 4.6 since optional nepomuk makes everything so much more complicated. 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. :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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 thus, less important than a manually added one. When I say suggestion I do not necessarily mean to suggest the link between file and activity but any kind of suggestion. This includes suggesting the file when showing related stuff for an activity. 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. this is still something the application will have to support, I assume, so we probably want just one simple way for it to report the docuements it has open. Exactly. My approach was rather similar to Ivan's I think: I have a dbus service that handles all the events. Apps simply call a set of methods on that interface. In case of non-KDE apps this can be done by KRun or even Konsole. I think here is where Ivan and I should merge our work. in kwin, what I need is which activities are associated with this wid?, so that I can filter out windows that aren't on the current activity. there can be no levels here, no suggestion; either a window is shown or it is not. I mean, I have absolutely nothing against you guys using levels yourselves, it's just that kwin needs a simple yes/no when it asks. :) it is up to you (or the service you ask) where you draw the line - whether automatically annotated files are included or not. Cheers, Sebastian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
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 safe to say that this thread has reached the end of its ability to produce useful input. let's stop here. I happen to think its a perfectly valid point. If you can't guarantee the bug won't reappear, an easily discoverable work around is going to have to be made for it. if the bug has a very low possibility of reappearing and if it does the consequences are nominal, then hobbling the default interface for everyone all the time is a really bad idea. so no, it isn't a valid point at all. Just a little bit of brain storming, but some place, an interface showing a list of the current running plasmoids (one item per plasmoid instance), which when hovered over with the mouse cause them to be highlighted by plasma itself. It would make the most sense if it were to hide all normal windows, or bring plasma forward. last time we discussed this (on this list even, iirc), the possibility of having a listing of running plasmoids in the tasks (ctrl+escape) window from krunner sounded pretty nice. and it could be without all the other problems of adding removal to the add widgets interface. Possibly tie it into the ZUI to show all current containments. there is no ZUI anymore. That said, a much simpler and easier to implement idea would be to add back that minus button and just force people to add back instances they wanted (if theres more than one running). which was exactly the problem: it doesn't say what is being removed, leading to loss of desired items. this made the minus sign less than useful. adding finer granularity to it just makes it harder to use. simpler does not always mean better. so, no, this feature will not be re-appearing. that is final. Maybe as an option. that isn't how we work here. if there is a solution to a problem that isn't workable, we don't simply say well, just throw it in there and make it an option, even if it does suck. that's just a way to make the software suck twice as hard: now it has a poor solution -and- a configuration option for people to deal with. lose. p.s. the javascript console lets you get to any plasmoid using scripting. And I'm sure its fully documented, it is. easily discoverable, and understandable by mere users. it isn't. and i don't think it's a solution for mere users (a phrase that's a bit ... un-nice to the people who use kde software, imho). it's an option for those of us who run into such situations during development. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: definitions and package for plasma on meego
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
Re: Scrollbars in add widget ui
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 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 stop here. I happen to think its a perfectly valid point. If you can't guarantee the bug won't reappear, an easily discoverable work around is going to have to be made for it. if the bug has a very low possibility of reappearing and if it does the consequences are nominal, then hobbling the default interface for everyone all the time is a really bad idea. so no, it isn't a valid point at all. I sure wouldn't call it hobbling the interface. Just a little bit of brain storming, but some place, an interface showing a list of the current running plasmoids (one item per plasmoid instance), which when hovered over with the mouse cause them to be highlighted by plasma itself. It would make the most sense if it were to hide all normal windows, or bring plasma forward. last time we discussed this (on this list even, iirc), the possibility of having a listing of running plasmoids in the tasks (ctrl+escape) window from krunner sounded pretty nice. and it could be without all the other problems of adding removal to the add widgets interface. That might indeed be nice. Possibly tie it into the ZUI to show all current containments. there is no ZUI anymore. As of 4.4.4 it still zooms. That said, a much simpler and easier to implement idea would be to add back that minus button and just force people to add back instances they wanted (if theres more than one running). which was exactly the problem: it doesn't say what is being removed, leading to loss of desired items. this made the minus sign less than useful. adding finer granularity to it just makes it harder to use. simpler does not always mean better. I fully understand the reasoning. But now I have no way to remove lost widgets. I'd call that a hobbled interface. so, no, this feature will not be re-appearing. that is final. Maybe as an option. that isn't how we work here. if there is a solution to a problem that isn't workable, we don't simply say well, just throw it in there and make it an option, even if it does suck. that's just a way to make the software suck twice as hard: now it has a poor solution -and- a configuration option for people to deal with. lose. It sucks more now than it did before. p.s. the javascript console lets you get to any plasmoid using scripting. And I'm sure its fully documented, it is. easily discoverable, and understandable by mere users. it isn't. and i don't think it's a solution for mere users (a phrase that's a bit ... un-nice to the people who use kde software, imho). it's an option for those of us who run into such situations during development. Most of the time I'm a /mere/ user. I don't think its un-nice. Most people doing day to day regular tasks really don't want nor need to worry about some script console. Heck, most of the time I can't remember the various key shortcuts to various things. Took me an age to fully memorize ALT+F2, and just recently I may have fully memorized the Disable compositing short cut, but I tend to forget it over and over, so I have to go at it the long way. -- Thomas Fjellstrom tfjellst...@shaw.ca ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KDE/kdebase/workspace/plasma/generic/applets/devicenotifier
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 with KCapacityBar in this case? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KDE/kdebase/workspace/plasma/generic/applets/devicenotifier
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 with KCapacityBar in this case? I had in mind issues such as the following br: https://bugs.kde.org/show_bug.cgi?id=231609 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KDE/kdebase/workspace/plasma/generic/applets/devicenotifier
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 screenshot looks nice; but i'm curious: what were the issues with KCapacityBar in this case? I had in mind issues such as the following br: https://bugs.kde.org/show_bug.cgi?id=231609 ok, thanks for the added info :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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 is added, it needs to absolutely work because it will not only be the default ... it won't be able to be turned off. that said, i think it may make work well since it's an active user selection to associate the window with the activity, and the window won't be shown when a different activity is shown. what will likely end up becoming a requirement, however, is a way to show windows in other activities so that a person may find that krita window i had open ... without switching to every activity manually. that sounds a bit more like something for 4.6, though. I know that hidden options are highly frowned upon, and rightly so, but this seems like one of the very rare situations where it might be considered appropriate. It would basically be an experimental option that will be in a configuration dialog in the next KDE release. The people who would likely be setting windows to activities at this point would also probably be the same people who could handle a (temporarily) hidden option. Anyone not able to deal with hidden options probably wouldn't be messing with the per-window settings. And it would just be a temporary measure, providing some testing for an option that will be more visible in KDE 4.6. If you went this route I don't know whether it would better to have it enabled or disabled by default, though. -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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 no configuration UI is possible. so if it is added, it needs to absolutely work because it will not only be the default ... it won't be able to be turned off. that said, i think it may make work well since it's an active user selection to associate the window with the activity, and the window won't be shown when a different activity is shown. what will likely end up becoming a requirement, however, is a way to show windows in other activities so that a person may find that krita window i had open ... without switching to every activity manually. that sounds a bit more like something for 4.6, though. I know that hidden options are highly frowned upon, and rightly so, but this seems like one of the very rare situations where it might be considered appropriate. It would basically be an experimental option that will be in a configuration dialog in the next KDE release. The or, it might not be configurable if it works well enough ... but i agree that this could be a worthwhile exception to the rule for the reasons you provided. route I don't know whether it would better to have it enabled or disabled by default, though. my gut says enabled by default for the reasons i outlined in my previous email. we could provide a javascript snippet that turns it off though. thought: providing a list of javascript templates would be really cool in the desktop console. *ponders* -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activities protocol
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 association. (this is the most awesome side effect of activities for me - taskbar knowing the open documents) only thing that concernes me a bit is that this kind of association in kwin, and in the kded seems a bit uhm separate -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Fwd: [kde-edu]: plasma edu
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 school deployments of the KDE Desktop v3 and/or KDE Plasma Desktop. we decided to try and do two things: a) bring some of the unique efforts that are currently going on downstream in these projects upstream, allowing them to use the KDE community's resources as a point of collaboration for them. this will hopefully allow our large (and small!) edu deployments to share their efforts as well as get their work into more downstream-agnostic forms (allowing them to more easily shift OS if needed) b) provide a unique Plasma Workspace offering that educational deployments may choose to take advantage of. this means upstream work on the Plasma Desktop that has a specific aim for the educational desktop needs, bringing us closer to our downstreams and giving our downstreams new tools they can't get elsewhere. at the meeting we decided on a few things: * the best place to run this project is from the KDE Edu community. this is why i am sending this email to kde-edu@ and not plasma-de...@. it's more relevant for educational deployments (plasma-devel is fairly high traffic, techical and not overly useful for edu focused work :), and hopefully will bring all of our edu resources closer together. we hope that by providing a good edu experience on top of Plasma Desktop and Plasma Netbook, we can also find new opportunities for KDE Edu software (and vice versa) * we need to write documentation of what we want to achieve and where we are right now, this will go here for now: http://techbase.kde.org/Projects/Plasma/Classroom we did this with netbook (http://techbase.kde.org/Projects/Plasma/Plasma- Netbook) and it was a very successful approach, even as our initial design evolved over time. * we want to keep our sources together, but not bound to the KDE SC release cycle for now. therefore, we are proposing to put our code into trunk/extragear/edu/. no such directory currently exists. we will make it. * in addition to gather work down for existing edu deployments, we intend to deliver a set of components (plasmoids, containments, javascript layout templates) that will run inside a standard Plasma Desktop shell. we want to have a first release around the same time as SC 4.6. the central idea is to have a set of simplified, lockable panel layouts paired with a desktop widget layout that can be customized by the teacher that leverages the Activities as debuting in Plasma Desktop 4.5. each class session will get an Actvity, which the classroom lead (e.g. teacher) can populate with applications, files, etc. when a student logs in, it will fetch the Activities for the class sessions they are in. * we require input from teachers using KDE software to provide feedback and consultation on the above idea and as it progresses as a software product current action items: * get the Plasmoid from the Portugal deployment in svn * get the javascript layout that mimics the java bar used in Brazil in svn * flesh out the design document so we can begin getting teacher feedback and start working on it ok, that's probably enough for one email. :) i hope that the KDE Edu team is ok with us joining/invading your space to run this project. your input is not only welcome, it is desired. i'd say it's even critical to this becoming a success. open the floodgates! :) -- 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 --- -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Python Plasma.PopupApplet revisited
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 dock sensibly to a panel. def init if (self.formFactor() == Plasma.Planar): self.planar = True self.horizontal = False elif (self.formFactor() == Plasma.Horizontal): self.planar = False self.horizontal = True elif (self.formFactor() == Plasma.Vertical): self.planar = False self.horizontal = False # panel icon if not self.planar: self.icon = MbPanelIcon() layout = QGraphicsLinearLayout(Qt.Vertical) self.setLayout(layout) layout.addItem(self.icon) self.icon.updateIcon(self.geometry()) return Thanks. It might not help with the popup but it will come in handy elsewhere :-) Anyways - now I have filed a bug report [*] on the bindings module with a test case attached as it seems like no one has been able to get it to work - or wont share the secret ;-) [*] https://bugs.kde.org/show_bug.cgi?id=244667 Please vote -- Best Regards / Med venlig hilsen Thomas Olsen 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/kdebase/workspace/plasma/generic/applets/devicenotifier
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 -- regression. Avoidable tooltips - Usability problem. Bug you mentioned - Qt bug (fixed in 4.7). What are the actual improvements then? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
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 https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KDE/kdebase/workspace/plasma/generic/applets/devicenotifier
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 percentage display on the battery Plasma applet. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
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 mind but are never here when things needs to get done. I would love to change positions and be the one to ignore all the work and research that was done before some work and just complain about it and say why I have the best idea ever. *sigh*. Back to technical: Yep, it's way more elegant than having an icon with an i that when clicked shows all the useful information. Specially that my mother doesn't need to figure out what the hell the i icon means (it could be something related to uninstall on my native language) and just hovers the mouse over what she wants to figure out what that plasmoid is without yet another mouse interaction. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Equivalent for closeEvent?
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 https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add external loader support to Plasma::Applet, Plasma::DataEngine, Plasma::Service
--- 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, Robert Marmorstein, and Shaun Reich. Changes --- This one should work. I've added support to it in plasma-kpart, and that builds and afaict works, yay. Summary --- Adds ability for applications which embed plasma to specify a class which plasma will query for Applet, DataEngine, and Service creation, giving them the chance to create these objects internally. The foremost use of this is to give Plasma the chance to ask applications when restoring layouts from disk, for applets which were based on QWidgets, such as the case in various Plasma dashboards which may embed QWidgets as plasma::applets Diffs (updated) - trunk/KDE/kdelibs/plasma/CMakeLists.txt 1146180 trunk/KDE/kdelibs/plasma/applet.cpp 1146180 trunk/KDE/kdelibs/plasma/dataenginemanager.cpp 1146180 trunk/KDE/kdelibs/plasma/externalpluginloader.h PRE-CREATION trunk/KDE/kdelibs/plasma/externalpluginloader.cpp PRE-CREATION trunk/KDE/kdelibs/plasma/service.cpp 1146180 Diff: http://reviewboard.kde.org/r/4554/diff Testing --- Well, this thing is about 90% there right now, everything works, etc, afaict, but I can't get the instance of the PluginManager outside of the Plasma namespace, if someone could help that would be great. :) I can commit some support into trunk/playground/base/shells/kpart Thanks, Ryan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
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, so your argument simply isn't valid. Specially that my mother doesn't need to figure out what the hell the i icon means (it could be something related to uninstall on my native language) I take this as a proposal to remove the i from the systray. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activities protocol
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 https://mail.kde.org/mailman/listinfo/plasma-devel -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
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
Re: [Nepomuk] Activities protocol
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 call a set of methods I'm not very fond of having apps call dbus directly. By creating the KActivity* classes, we can keep the dbus interface as minimal as possible, while the classes could handle some logic and provide convenience methods. (and we don't need to keep the dbus api back-compatible) maybe we could drop that for 4.6 since optional nepomuk makes everything so much more complicated. I agree. We'll just need to communicate this to KWin guys - they didn't really want to depend on nepomuk. Although, (from my pov) the kded daemon could access nepomuk directly instead of doing it via the service... (it doesn't really matter whether it is a kded module or a nepomuk service...) Cheerio -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
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 list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Thomas Fjellstrom tfjellst...@shaw.ca ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
- 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 the old widgets explorer. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
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 in a trunk build from somewhere between RC1 and today. Ryan -- Ryan Rix == http://hackersramblings.wordpress.com | http://rix.si/ == == http://rix.si/page/contact/ if you need a word == 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: IRC meeting: point of what was done at akademy
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 9UTC telling them that it was madness for me to stay up to 2am for a meeting... well, yeah, ehm :) It's 9pm, I'm still Finlag'd from waking up with the sun today (far worse than being jetlag'd), and even with a heavy serving of the coffee I put on downstairs, I don't see myself being sane for this meeting. I'll, like, catch logs, and send mails, and harass people afterwards. :) Cheers, Marco Martin Best best, Ryan I don't date -d before replying Rix -- Ryan Rix == http://hackersramblings.wordpress.com | http://rix.si/ == == http://rix.si/page/contact/ if you need a word == ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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 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 is added, it needs to absolutely work because it will not only be the default ... it won't be able to be turned off. honestly, I hadn't planned to make it an option ever. :) that said, i think it may make work well since it's an active user selection to associate the window with the activity, and the window won't be shown when a different activity is shown. what will likely end up becoming a requirement, however, is a way to show windows in other activities so that a person may find that krita window i had open ... without switching to every activity manually. that sounds a bit more like something for 4.6, though. true; I tend to lose windows even just with vdesktops :) logging out properly has become far more tedious now that I need to remember to check all desktops *and* all activities for unsaved work and session-unfriendly apps. otherwise will cause another ser revolt. a user revolt because the windows are shown in the taskbar? seriously? will some people complain? sure. will some throw tomatos at us because of it? sure, but those people will do that no matter what we do: they are just looking for an excuse. (and for that reason i have ~zero interest in and respect for them.) let's make decisions that make sense on their own merit, not because the peasants are revolting!. +1 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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! :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
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 positives due to automatically associating files issue. files the user tags explicitly would be easily discernable from those that have a DesktopEvent. assuming that DesktopEvent allows for things such as counting the number of times that same event happens, it should even be possible to decrease the importance of files accessed just once or a long tme ago. +1 from me to our ontology overlords. [un-top-posting] 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. neat. :) I was doing some thinking on the bus... and I like this scoring idea. think of it this way: I have a bunch of plasma source folders (kdelibs/plasma, workspace/plasma, ...) that are loosely associated with plasma and kde. I have kwin source folders (workspace/kwin, ..) that are loosely associated with kwin and kde. plasma and kwin are loosely associated with kde. Now, when I open a kwin file in kwin, it's a safe bet that it applies only to kwin, and the window opening it should be associated with that activity and not bleed into others. When I open a plasma file in kwin... well, it *could* be that I forgot what activity I was in and got sidetracked, but since there's that loose association from kwin to kde to the source, then it seems more likely that I needed to read that file to help with whatever kwin thing I'm doing. So, the best assumption is to put it on that activity (and not on the plasma activity). On the other hand, if someone sends me a link to some youtube vid, that has no association with anything, so that window ought not to be put on the activity... although you could argue that it could be given a weak association, so that if it was opened from that activity a second time it'd get put there. :) and of course there's all sorts of opportunity for experimenting there :) and the more apps are activity-aware, the less often things will accidentally bleed over to the wrong activities, because the stuff (irc channels, mail folders) that's not in that activity won't be shown in the first place. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: IRC meeting: point of what was done at akademy
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 mail to another list who also had a meeting at 9UTC telling them that it was madness for me to stay up to 2am for a meeting... well, yeah, ehm :) It's 9pm, I'm still Finlag'd from waking up with the sun today (far worse than being jetlag'd), and even with a heavy serving of the coffee I put on downstairs, I don't see myself being sane for this meeting. I'll, like, catch logs, and send mails, and harass people afterwards. :) Cheers, Marco Martin Best best, Ryan I don't date -d before replying Rix yeah... metoo :/ I may or may not be awake then. if I find myself losing hte battle I'll try and send email with my thoughts. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
