Re: Plasma, ARGB and 4.5
I you change the graphicssystem and you have already opened the application that will be embedded, then you will have garbage...You shoud restart those applications to reembed them... On Mon, Feb 16, 2009 at 10:51 PM, Marco Martin notm...@gmail.com wrote: On Monday 16 February 2009, Aaron J. Seigo wrote: On Friday 13 February 2009, Marco Martin wrote: Hi all, right now plasma enables argb visuals with that magin X11 code pasted in many places... since 4.5 now can handle it by setting Qt::WA_TranslucentBackground on the top level window we want transparent we can make it in a prettier way that would be nice. done, seems to work quite good, except for two things: the tooltips seems to insist that they don't want to be transparent the systemtray has garbage again with the raster graphicssystem (so i didn't dream it up) i'm not sure if that's the case also with the old method btw i really hope those two aren't insolvable issues, otherwise it would be necessary to return back.. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma, ARGB and 4.5
The one pixel thingy was commited 10 minutes ago, so we reach the snapshots tomorrow :D Nice to hear that all issues are fixed one by one :D On Tue, Feb 17, 2009 at 11:29 AM, Marco Martin notm...@gmail.com wrote: On Monday 16 February 2009, Marco Martin wrote: On Monday 16 February 2009, Aaron J. Seigo wrote: On Friday 13 February 2009, Marco Martin wrote: Hi all, right now plasma enables argb visuals with that magin X11 code pasted in many places... since 4.5 now can handle it by setting Qt::WA_TranslucentBackground on the top level window we want transparent we can make it in a prettier way that would be nice. done, seems to work quite good, except for two things: the tooltips seems to insist that they don't want to be transparent the systemtray has garbage again with the raster graphicssystem (so i didn't dream it up) i'm not sure if that's the case also with the old method btw update: tred with the latest qt snapshot and tooltips opacity is automagigally fixed there, so we just have to be a bit patient :D also some other little annoyances are fixed: on autohide panels the cashew was disappearing also the weather icon was disappearing when the tab were switched from 5 days view to details those 2 issues are fixed as well :D ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma, ARGB and 4.5
On Monday 16 February 2009, Marco Martin wrote: On Monday 16 February 2009, Aaron J. Seigo wrote: On Friday 13 February 2009, Marco Martin wrote: Hi all, right now plasma enables argb visuals with that magin X11 code pasted in many places... since 4.5 now can handle it by setting Qt::WA_TranslucentBackground on the top level window we want transparent we can make it in a prettier way that would be nice. done, seems to work quite good, except for two things: the tooltips seems to insist that they don't want to be transparent the systemtray has garbage again with the raster graphicssystem (so i didn't dream it up) i'm not sure if that's the case also with the old method btw update: tred with the latest qt snapshot and tooltips opacity is automagigally fixed there, so we just have to be a bit patient :D also some other little annoyances are fixed: on autohide panels the cashew was disappearing also the weather icon was disappearing when the tab were switched from 5 days view to details those 2 issues are fixed as well :D ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Display correct week number in the calendar widget
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/76/#review147 --- Any opinion about this? - Andras On 2009-02-14 06:30:08, Andras Mantia wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/76/ --- (Updated 2009-02-14 06:30:08) Review request for Plasma. Summary --- The calendar widget currently display incorrect and misleading week numbers if according to the regional setting the week doesn't start with Monday (like in the US). The widget uses KCalendarSystem::weekNumber to find the week number for the first date in the row. This date can be any day of the week, not only Monday, as the calendar widget takes into the account the regional settings. But KCalendarSystem::weekNumber determines the ISO week number as it is stated in its documentation and that one starts with Mondays. This results in a wrong week number shown. Examples: in 2009 the week1 is 1-4, week 2 is 5-11th of January. If the regional is US, the second row starts from 4-10. For 4th the week number is 1, so 1 is shown for that week. This is wrong, that week contains days both from the first and second week. The solution is either to calculate the week number according to the regional settings or display the week number correctly in ISO numbering. The patch does the second one, displays the week number(s) where the days in that row belong. So in US regional, row 2 (weeks 4-5) would be assigned to weeks 1/2 (4 is in 1, 5-10 is in 2). Diffs - trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.cpp 925810 Diff: http://reviewboard.kde.org/r/76/diff Testing --- Tested with all possible weekday starts. The calendar default size needs to be bigger to fit week numbers like 52/53, sincerely don't know where to do it, that change probably needs to be done in the applet itself. Thanks, Andras ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine
On Tuesday 17 February 2009 08:01:31 David Baron wrote: 2. At 1st timeout, I do the a query(ContactCollections) then if I find a suitable key, connectSource, i.e to ContentCollection-6. You can just do that in or from init(). Why use a timer here? The panel on which the applet is nested delays coming up when I do it directly in init(). Have you tried connecting to ContactCollections, and then checking for data of this one in dataUpdated()? This would be non-blocking. (Fetching the collections is pretty fast here, so I wouldn't have thought it's necessary.) -- 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
Open source user experience
Hello everyone, I just wanted to let you know, that recently there was a thread on the IxDA mailing list about open source user experience. http://www.ixda.org/discuss.php?post=38371 I'm not sure you can read it without being subscribed; and I'm not sure it is all that interesting anyway :-) Someone mentioned an online wire-framing tool he is creating, others complimented the work going on at mozilla labs and even more people raised concerns over cultural differences between designers and developers. Nothing new really; we at least scratched the surface of everything they mentioned here already. But the reason I'm telling you this is that it seemed like there are quite a few people out there who are really interested in getting involved with this movement. So we could just be happy that everybody likes us (well, besides ourselves, designers seem to like us :-), but we could also think about some kind of outreach program, with which we try to bring both cultures closer together. Basically what the user council does for users and developers. Let me know if you approve of such an idea and if you have any thoughts about it. Now seems to be a good opportunity to get started. michael ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine
On Tuesday 17 February 2009 14:13:10 David Baron wrote: On Tuesday 17 February 2009 14:37:11 you wrote: On Tuesday 17 February 2009 08:01:31 David Baron wrote: 2. At 1st timeout, I do the a query(ContactCollections) then if I find a suitable key, connectSource, i.e to ContentCollection-6. You can just do that in or from init(). Why use a timer here? The panel on which the applet is nested delays coming up when I do it directly in init(). Have you tried connecting to ContactCollections, and then checking for data of this one in dataUpdated()? This would be non-blocking. (Fetching the collections is pretty fast here, so I wouldn't have thought it's necessary.) This is what I am doing. This gives me one (more?) ContactConnection-#. It is connecting to this, oro mre accurately, its contents that needs the QTimer. Doing the initial connect was put in the timer because otherwize, it delayed the panel from coming up. Some more: - if you run 'plasmaengineexplorer --engine akonadi', how long does it take to start up? (instantly or a couple of seconds?) - if you request the source 'ContactCollections', how long does it take until it returns results? - I've just made the fetching of the collectionlist async as well, can you svn up and recompile the akonadi dataengine to see if that helps? -- 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: Fun with Akonadi Dataengine
On Tuesday 17 February 2009 17:41:38 Sebastian Kügler wrote: On Tuesday 17 February 2009 14:13:10 David Baron wrote: On Tuesday 17 February 2009 14:37:11 you wrote: On Tuesday 17 February 2009 08:01:31 David Baron wrote: 2. At 1st timeout, I do the a query(ContactCollections) then if I find a suitable key, connectSource, i.e to ContentCollection-6. You can just do that in or from init(). Why use a timer here? The panel on which the applet is nested delays coming up when I do it directly in init(). Have you tried connecting to ContactCollections, and then checking for data of this one in dataUpdated()? This would be non-blocking. (Fetching the collections is pretty fast here, so I wouldn't have thought it's necessary.) This is what I am doing. This gives me one (more?) ContactConnection-#. It is connecting to this, oro mre accurately, its contents that needs the QTimer. Doing the initial connect was put in the timer because otherwize, it delayed the panel from coming up. Some more: - if you run 'plasmaengineexplorer --engine akonadi', how long does it take to start up? (instantly or a couple of seconds?) Program comes up quickly - if you request the source 'ContactCollections', how long does it take until it returns results? And I get this quickly These two connections are quick enough. However, when plasma is first starting up, everything has slowed down. Maybe this is why my 1 second delay simply lets everything start up nicely. It is all the contacts that might take several-10 seconds to come up in the explorer and in the program. The explorer is blocked during this wait. I seem to need to see them all listed in the console before any dataUpdate's are called. This is most probably the change you cite below. Maybe I do not really (or always) need to repeat my connectAllSources but the .h file says doing so is harmless . - I've just made the fetching of the collectionlist async as well, can you svn up and recompile the akonadi dataengine to see if that helps? Most probably will. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine
Latest from playground SVN. After hand entering stuff like akonadi/monitor.h since I do not have the Akonadi/Monitor files available, it build OK. My applet's sequence no longer gets to 1st base. I do not get the query() that gives me the ContactCollection-#. In the explorer, I do get it. Possibly connectSource works and Query is broken! When I request it, I see in the console contact data items rather than sources and then the explorer crashes. I most likely do not want ALL the hash items all at once like that. What I had been getting in dataUpdated was the source (Contact-) and the data-hash. Will I still get this (and the console output has changed) or is this all changed as well. If so, I think the former sequences made more sense. Since I had contacts one-at-a-time to work with rather than having to parse when I have a new one. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[PATCH] ftp support in locations runner
The attached patch adds ftp support to the locations runner. I find it very
annoying that I cannot run ftp connections my simply typing ftp.kde.org like
I could in KDE 3.
Ok to commit to 4.2 and trunk?
Cheers,
Sebastian
Index: locationrunner.cpp
===
--- locationrunner.cpp (revision 927493)
+++ locationrunner.cpp (working copy)
@@ -57,7 +57,10 @@
if (idx != -1) {
url.setPath(term.mid(idx));
}
-url.setProtocol(http);
+if (term.startsWith(ftp))
+url.setProtocol(ftp);
+else
+url.setProtocol(http);
}
}
@@ -108,7 +111,7 @@
match.setData(url.url());
if (KProtocolInfo::isHelperProtocol(url.protocol())) {
-//kDebug() helper protocol url.protocol() call external application ;
+//kDebug() helper protocol url.protocol() call external application ;
match.setText(i18n(Launch with %1, KProtocolInfo::exec(url.protocol(;
} else {
//kDebug() protocol managed by browser url.protocol();
@@ -145,7 +148,7 @@
KUrl urlToRun(location);
if ((type == Plasma::RunnerContext::NetworkLocation || type == Plasma::RunnerContext::UnknownType)
-data.startsWith(http://;)) {
+(data.startsWith(http://;) || data.startsWith(ftp://;))) {
// the text may have changed while we were running, so we have to refresh
// our content
processUrl(urlToRun, location);
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine
Latest from playground SVN. I re-downloaded and compared with the older code. The only real difference besides the volume of diagnostic printout is that the ContactCollection-# list is made at a completion event rather than immediately on connectSource(ContactCollections). Such could alleviate some of the panel delay I encountered when doing this directly in init(). However, this is a small amount of data at this point. The delay was more from the log-jam on kde/plasma startup. For example, with the older dataengine, it took almost 90 seconds before I got the contacts to start dataUpdate-ing. Later on, run from the plasmoidviewer, this same thing completes in several seconds. With the new code, I will not have any useful return from query until I have the equivalent in dataUpdate. This is why it did not work. I should recode it so it would work either way. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine
On Tuesday 17 February 2009 22:01:18 David Baron wrote: Latest from playground SVN. I re-downloaded and compared with the older code. The only real difference besides the volume of diagnostic printout is that the ContactCollection-# list is made at a completion event rather than immediately on connectSource(ContactCollections). Such could alleviate some of the panel delay I encountered when doing this directly in init(). However, this is a small amount of data at this point. The delay was more from the log-jam on kde/plasma startup. For example, with the older dataengine, it took almost 90 seconds before I got the contacts to start dataUpdate-ing. Later on, run from the plasmoidviewer, this same thing completes in several seconds. With the new code, I will not have any useful return from query until I have the equivalent in dataUpdate. This is why it did not work. I should recode it so it would work either way. To get it to work either way, I still use the QTimer. I MUST repeat the connectSource( ContactCollections ) or a least wait the second before the 1st call since the console shows no further such calls. When I get dataUpdated from this call, I connect the ContactCollection-#,, and then have the QTimer call connectAllSources and I get my contacts. HOWEVER, the new code will crash the applet in plasmoidviewer just as it crashed the explorer. This may be due to the increased volume of printed contacts information or it may be something else. The applet in the panel apparently did not crash (the desktop and panel came up) even though the plasma command certainly showed all that stuff. In any event, I am going back to the older code until the problem is resolved since I cannot test the applet or dataengine with the new code. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma, ARGB and 4.5
On Monday 16 February 2009, Marco Martin wrote: On Monday 16 February 2009, Aaron J. Seigo wrote: On Friday 13 February 2009, Marco Martin wrote: Hi all, right now plasma enables argb visuals with that magin X11 code pasted in many places... since 4.5 now can handle it by setting Qt::WA_TranslucentBackground on the top level window we want transparent we can make it in a prettier way that would be nice. done, seems to work quite good, except for two things: the tooltips seems to insist that they don't want to be transparent the systemtray has garbage again with the raster graphicssystem (so i didn't dream it up) i'm not sure if that's the case also with the old method btw Reverting r907753 should fix the systray icons. You'll have to read my reply on kde-commits for the details, but the short version is that the move to using Qt::WA_TranslucentBackground combined with that patch means that Plasma is now explicitly telling Qt (and Gtk) to not use real transparency for the systray icons. Regards, Fredrik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
OpenBrain
Hello plasma-devel, my name is Drake Justice (hallowname) and this is my first post. My plasmoid is OpenBrain the desktop assistant. It's basically an AIML bot (think chat bot, alice bot, artificial intelligence) that parses XML (.aiml) files, and can then respond to english input. It now has a dependency called libopenbrain, which is a shortened, rewrite of librebecca, which hasn't been coded on in years (and was written in vc++ and didn't compile properly under linux). My question is: where should libopenbrain go? inside base/plasma/applets/openbrain ? other apps can utilize libopenbrain to have their program instantly speak english, with little to no knowledge of aiml parsing. i want to distribute the 'brain' itself with the 'openbrain' plasmoid regardless of the location of libopenbrain. so libopenbrain alone would require the implementing app to provide it's own 'brain data'. so openbrain would respond to 'who is lancelot?' with (if online) a wikipedia article on lancelot, meanwhile the lancelot app runner (which will get openbrain features) would answer something like 'lancelot is this plasmoid, it runs programs, and has easy to locate links to your computer.' but basically, where should libopenbrain go? also libopenbrain still has std, boost, and xerces includes, they will be converted to qt when i get time. it uses berkdb43 now to instantly load all the brain data (no more waiting 30-60 seconds for it to load). i didn't really see a better way to do this w qt. tips? sorry for the long post. and that openbrain is broken on playground. but i dont know where to put libopenbrain u see. compiling the tarballs from kde-apps.org should work though if you want to see it in action. thanks in advance, Drake Justice ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: OpenBrain
I dont know how many rules you added to the brain now but to have a decent coverage you would need _lots_ of them, else the brain would give funny answers most of the times. What can be really cool would be extracting rules with simple facts from KDE docs. Else I really doubt apps maintainers will spend time writing trivial AIML rules for dubious user cases. And of course we have the problem of the 50+ languages you should be targeting ... So I dont think you need to rush, looks like it will be in playground for a lng time. 2009/2/18 Drake Justice hallown...@gmail.com Hello plasma-devel, my name is Drake Justice (hallowname) and this is my first post. My plasmoid is OpenBrain the desktop assistant. It's basically an AIML bot (think chat bot, alice bot, artificial intelligence) that parses XML (.aiml) files, and can then respond to english input. It now has a dependency called libopenbrain, which is a shortened, rewrite of librebecca, which hasn't been coded on in years (and was written in vc++ and didn't compile properly under linux). My question is: where should libopenbrain go? inside base/plasma/applets/openbrain ? other apps can utilize libopenbrain to have their program instantly speak english, with little to no knowledge of aiml parsing. i want to distribute the 'brain' itself with the 'openbrain' plasmoid regardless of the location of libopenbrain. so libopenbrain alone would require the implementing app to provide it's own 'brain data'. so openbrain would respond to 'who is lancelot?' with (if online) a wikipedia article on lancelot, meanwhile the lancelot app runner (which will get openbrain features) would answer something like 'lancelot is this plasmoid, it runs programs, and has easy to locate links to your computer.' but basically, where should libopenbrain go? also libopenbrain still has std, boost, and xerces includes, they will be converted to qt when i get time. it uses berkdb43 now to instantly load all the brain data (no more waiting 30-60 seconds for it to load). i didn't really see a better way to do this w qt. tips? sorry for the long post. and that openbrain is broken on playground. but i dont know where to put libopenbrain u see. compiling the tarballs from kde-apps.org should work though if you want to see it in action. thanks in advance, Drake Justice ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Jordi Polo Carres NLP laboratory - NAIST http://www.bahasara.org ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
OpenBrain
I dont know how many rules you added to the brain now but to have a decent coverage you would need _lots_ of them indeed, it loads over 1.6 million at the moment in around 1 second. however after i get the code base complete, im going to set up a webui for users of openbrain to contribute back to openbrain (via interactive reprogramming of what it should say and do). the brain would give funny answers most of the times it does at the moment 1.6 milion is nowhere near enough nodes. im still gettting it's c++ straightened out. I really doubt apps maintainers will spend time writing trivial AIML rules for dubious user cases 99.9% wouldn't :P, but some will. lvan from the lancelot project wants to. why have two aiml parsers tightly integrated with kde? So I dont think you need to rush, looks like it will be in playground for a lng time. I dont want it out of playground, its only in playground so more people within the kde community can easily access and modify it. there are jaunty and opensuse packages of openbrain i never wanted to be made. openbrain is nowhere near usable yet i dont think. but it's close. people like it. it can respond to people in their own language. 'how do i send email?' 'how do i get online?' 'how do i click?' 'run firefox' 'echo 9*9 | bc' 'calculate pi' 'start konsole please' 'who is richard stallman?' 'google science fair' 'wikipedia kde' etc... it's useful. it's also interwoven with kde, being a plasmoid/widget/runner and answering to 'give me a calculator' with the execution of 'kcalc' or 'browse the web' with konqueror (only if xdg returns no set preferred browser) mixing c++ with aiml can be powerful i think. I dont know how many rules you added to the brain now but to have a decent coverage you would need _lots_ of them, else the brain would give funny answers most of the times. What can be really cool would be extracting rules with simple facts from KDE docs. Else I really doubt apps maintainers will spend time writing trivial AIML rules for dubious user cases. And of course we have the problem of the 50+ languages you should be targeting ... So I dont think you need to rush, looks like it will be in playground for a lng time. 2009/2/18 Drake Justice hallowname at gmail.comhttps://mail.kde.org/mailman/listinfo/plasma-devel * Hello plasma-devel, my name is Drake Justice (hallowname) and this is my* * first post. My plasmoid is OpenBrain the desktop assistant. It's basically* * an AIML bot (think chat bot, alice bot, artificial intelligence) that parses* * XML (.aiml) files, and can then respond to english input. It now has a* * dependency called libopenbrain, which is a shortened, rewrite of librebecca,* * which hasn't been coded on in years (and was written in vc++ and didn't * * compile properly under linux). My question is: where should libopenbrain go?* * inside base/plasma/applets/openbrain ? other apps can utilize libopenbrain* * to have their program instantly speak english, with little to no knowledge* * of aiml parsing. i want to distribute the 'brain' itself with the* * 'openbrain' plasmoid regardless of the location of libopenbrain. so* * libopenbrain alone would require the implementing app to provide it's own* * 'brain data'. so openbrain would respond to 'who is lancelot?' with (if * * online) a wikipedia article on lancelot, meanwhile the lancelot app runner* * (which will get openbrain features) would answer something like 'lancelot is* * this plasmoid, it runs programs, and has easy to locate links to your* * computer.'* *** but basically, where should libopenbrain go?* *** also libopenbrain still has std, boost, and xerces includes, they will be* * converted to qt when i get time.* * it uses berkdb43 now to instantly load all the brain data (no more waiting* * 30-60 seconds for it to load). i didn't really see a better way to do this w* * qt. tips?* *** sorry for the long post. and that openbrain is broken on playground. but i* * dont know where to put libopenbrain u see. compiling the tarballs from* * kde-apps.org should work though if you want to see it in action.* *** thanks in advance,* * Drake Justice* *** ___* * Plasma-devel mailing list* * Plasma-devel at kde.orghttps://mail.kde.org/mailman/listinfo/plasma-devel * *** https://mail.kde.org/mailman/listinfo/plasma-devel* ** ** ** ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine
Hi David, On Tuesday 17 February 2009 21:47:46 David Baron wrote: On Tuesday 17 February 2009 22:01:18 David Baron wrote: Latest from playground SVN. I re-downloaded and compared with the older code. The only real difference besides the volume of diagnostic printout is that the ContactCollection-# list is made at a completion event rather than immediately on connectSource(ContactCollections). That should work as expected now. Such could alleviate some of the panel delay I encountered when doing this directly in init(). However, this is a small amount of data at this point. The delay was more from the log-jam on kde/plasma startup. For example, with the older dataengine, it took almost 90 seconds before I got the contacts to start dataUpdate-ing. Later on, run from the plasmoidviewer, this same thing completes in several seconds. Just comment out the kDebug() lines that generate this. I've commented out and removed most of it. With the new code, I will not have any useful return from query until I have the equivalent in dataUpdate. This is why it did not work. I should recode it so it would work either way. To get it to work either way, I still use the QTimer. I MUST repeat the connectSource( ContactCollections ) or a least wait the second before the 1st call since the console shows no further such calls. When I get dataUpdated from this call, I connect the ContactCollection-#,, and then have the QTimer call connectAllSources and I get my contacts. I've re-read the API docs and found a note that setData() needs to be initialized with empty data when we return true there. I've committed that change, it makes it work as expected now. I've also added sources() to the engine which makes it easier to find out what to do with it. I've also found a weirdness (expectedness?) in the dataengine. Apparently, I cannot connect to sources from different classes, somehow everything ends up calling the dataUpdated() in MailExtender, while I connect to the source EmailCollection from the applet itself (LionMail). For now, I'm just relaying the data in that case and call dataUpdated() in the applet using it. Still, something to keep in mind. HOWEVER, the new code will crash the applet in plasmoidviewer just as it crashed the explorer. This may be due to the increased volume of printed contacts information or it may be something else. The applet in the panel apparently did not crash (the desktop and panel came up) even though the plasma command certainly showed all that stuff. In any event, I am going back to the older code until the problem is resolved since I cannot test the applet or dataengine with the new code. Do you have a backtrace for this crash? BTW, thanks for your patience in getting it sorted how we want the akonadi engine to behave. As Aaron said, we should design it for actual usecases, you happen to be the first (well, second ;)) one to come across this, hence the immaturity of the akonadi engine. I had a chat with some of the Akonadi people tonight, giving me some more perspective of where we can go. Something I'd like to have is give me the contact for this email address (or telephone number, in your case), but Akonadi doesn't support this yet. Something that could be considered together with more Nepomuk integration in Akonadi, as I was told. -- 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: 4.3 feature plan
The one thing I would like to see more than anything else, finished floating panel applet and containment that can be embedded into any plasmoid with a 1 liner. layout-addItem(Plasma::Applet::Load(floatpanel)); // for example -- So far I got it working, with a couple major issues (aside from layout issues with spacings) 1) popupPosition always gives a very bad spot (It could be 0,0 I'm not sure, which would make sense if the view or corona isn't set on the containment) 2) it needs a new way to save/restore - currently it creates a new containment entry inside plasma-desktop-appletsrc which on next plasma boot loads the containment outside of the applet that spawned it. Other than that, they do expand into the fully popped out applet when the panel has enough space for them, and shrink to icons when appropriate. =) Other notes when throwing a system tray applet inside it it wouldn't grab systray icons - even if it was the only one loaded. tested working: taskbar, kickoff, lancelot, incoming messages, rss feed, comics, Quicklaunch, digital clock, system monitor, conways game of life, 15 puzzle, Picture frame, blue marble runs but is white - could be my broken install, network manager, Dictionary, Battery monitor, Login/Logout Not working at all as far as I can tell: bouncy ball Tested Bad breakage: xeyes clone when I throw this in, no applets render. Note: I have a broken 4.3 install so certain things wont work for me Tested bad: Now playing (Can't right click on it, no way to remove it, won't let me remove from add widgets either) (playground - plasma/welcome/welcome/cpp/containment - contains floatpanel applet and welcomepanel containment(Should be renamed?)) On Tue, 2009-02-17 at 22:14 -0300, Artur Souza(MoRpHeUz) wrote: Hey! We were chatting on IRC and we thought that it would be a good idea to start the 4.3 feature plan so we can start hacking on stuff! So, what do you think about ? Let's have a meeting on IRC or even start this conversation using the ML ? (the good about ML is that people that can't attend to the meeting can follow the discussion easily..) After this we can put all this information on the wiki and then it's just hacking and fun! =P Cheers! -- Artur Duque de Souza OpenBossa Research Labs INdT - Instituto Nokia de Tecnologia -- Blog: http://labs.morpheuz.eng.br/blog/ GPG: 0xDBEEAAC3 @ wwwkeys.pgp.net -- ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Windows go below panel visibility mode
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/119/ --- Review request for Plasma. Summary --- Adds Windows go below panel visibility mode. Identical in all ways to the default mode except doesn't set a strut. Example usage: User wants to place an always visible 80% width panel at the top of the screen and wants maximized windows to go behind it. The user can still access the decoration buttons so why not? Known problems: KWin doesn't prevent the window decoration titlebar from going completely under the panel preventing the user from moving the window out again unless they know about alt+dragging. Diffs - trunk/KDE/kdebase/workspace/plasma/shells/desktop/panelcontroller.cpp 927475 trunk/KDE/kdebase/workspace/plasma/shells/desktop/panelview.h 927475 trunk/KDE/kdebase/workspace/plasma/shells/desktop/panelview.cpp 927475 Diff: http://reviewboard.kde.org/r/119/diff Testing --- Thanks, Lucas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
