Re: Review Request: Use sunrise and sunset times from the Environment Canada weather service to set weather icon to day/night, accordingly.
On 2009-05-03 16:42:23, Shawn Starr wrote: It seems to be working so far, it's already committed. Beat Wolf wrote: i can't find this code in svn, is it really commited? can somebody mark this as submitted? Shawn Starr wrote: Its been redone. But we still dont have proper sunrise/sunset. so can somebody please close this report? (since this patch is out of date) - Beat --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/665/#review1045 --- On 2009-05-03 16:05:40, Andrew Coles wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/665/ --- (Updated 2009-05-03 16:05:40) Review request for Plasma. Summary --- Previously, day began at 6am, and night began at 6pm. However, as summer approaches, this is increasingly far from the truth. Hence, the real sunrise/sunset times are now used to determine whether it is day or night, and the weather icon set appropriately. This also fixes issues with the weather wallpaper picking night-time images during the day. Diffs - /trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_envcan.cpp 963098 Diff: http://reviewboard.kde.org/r/665/diff Testing --- I need someone who uses this weather service to test it for me. Thanks, Andrew ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Quicklaunch: Fix bugs related to having unlimited visible icons
On Monday 14 September 2009 05:35:21 Shafqat Bhuiyan wrote: Beat Wolf wrote: is there any news on the svn account or the patch? I got my svn account sorted and it seems to work fine now :) I still have the patch on my machine and I'll commit it once I figure it how to backport patches. Any hints are welcome... ;) There's a script kdesvnbackport in kdesdk/ which makes this really easy. :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: MediaCenterComponents - Picasa Engine
On Saturday 12 September 2009 16:49:01 Alessandro Diaferia wrote: I've had a look at the code and I feel it can be merged into MediaCenterComponents since I plan to provide models to navigate through webservices like picasa, youtube and so on. As from what i've achieved with mediacenter there's already a good api to start writing a model for both the youtube engine and this one. Any objection? Suggestions from the kde-silk team? It would be a good idea to make the API (names of sources, returned data) generic for image webservices, so it's easier to just exchange the dataengine in the background to use a different image webservice. Otherwise, great, I'd say :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: MediaCenterComponents - Picasa Engine
2009/9/14 Sebastian Kügler se...@kde.org On Saturday 12 September 2009 16:49:01 Alessandro Diaferia wrote: I've had a look at the code and I feel it can be merged into MediaCenterComponents since I plan to provide models to navigate through webservices like picasa, youtube and so on. As from what i've achieved with mediacenter there's already a good api to start writing a model for both the youtube engine and this one. Any objection? Suggestions from the kde-silk team? It would be a good idea to make the API (names of sources, returned data) generic for image webservices, so it's easier to just exchange the dataengine in the background to use a different image webservice. +1 What do you think about a generic API for media sources in general, and then defining something more specific for each type (e.g. music, video, pictures..). Otherwise, great, I'd say :) -- 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 -- Alessandro Diaferia KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: big revamp of Device Notifier
On 2009-09-11 19:44:22, Aaron Seigo wrote: /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.cpp, line 366 http://reviewboard.kde.org/r/1370/diff/5/?file=10962#file10962line366 this is only needed if m_showOnlyRemovable changes, correct? wrote: it is used also to hide or show the devices when you (un)check the option show all the items in the context menu. wrote: yes, that's what i said :) wrote: no, i mean when you right click the dialog, and you set the option to show or not even devices that normally would be hidden too. like when you right click on the Places panel in dolphin. In fact resetDevices() is called in configAccepted() (if m_showOnlyRemovable changes) and in setAllItemsShown(bool shown) (if m_showAll changes). wrote: ok, let's back up a bit here. that call to resetDevices is in DeviceNotifier::configAccepted. so i'm talking about when the configuration is changed. that means that in configAccepted, which is what line 365 here is, resetDevices _does not need to be called_ unless m_showOnlyRemovable changes. make sense? now forward again :) looking a m_showAll in NotifierView, Show All devices is always in the context menu and always enabled, even when there is nothing to show. probably, if there are no items to show there doesn't need to be a context menu in the view at all. i'm still not really sure what the real world use cases for hiding/showing individual items in the notifier are other than it's neat that i can; i'm trying to imagine someone who has so many items listed there that it's unmanagable otherwise. or someone who keeps two items in one notifier widget and has a second notifier widget with some others? hm. on the other hand, i can see this resulting in confusion when when someone plugs a device in, marks it to not be shown, then later plugs it in (and hopefully it's impossible to have different devices with the same name?) and it doesn't show up. particularly is days or weeks have passed between those two events. and why would i NOT want my camera to show up when i plug it in? what's the use case for that? this is why i'm still really unsure that turning the device *notifier* into a device *listing manager* in this way is the best of ideas. there's really two similar ideas here it seems: managing devices that are plugged and unplugged (which may or may not be storage devices) and listing storage devices. we actually have a widget for both of those tasks, but the storage device lister doesn't provide access to actions related to the device, which the device notifier does. this really comes back to use cases. can you provide use cases to go with the hide/show individual items feature? oh, and the widget should emit configNeedsSaving() after calls to writeEntry :) wrote: ok, i misunderstood a bit what you wanted to say. so, yes. in configAccepted() the call to resetDevices() is needed only if m_showOnlyRemovable changes, so we could actually check if the variable changed value and only in the case call resetDevices() and better yet add or remove the not removable devices without reset all the devices. as regards the show/hide system: saying that Show all devices is always enabled you mean it's always checked? if it is it is definitely a bug in the patch. i don't think the fact that the context menu is shown even when there are no devices is a big deal, but anyway it would be simple to make a check. anyway it uses the uuid provided by solid and not the names to identify the devices, so if you have two devices with the same name and you hide one, the other will remain visible (unless the uuid are equals, but i think this is a really rare case, if it is possible). Actually i decided to develop this feature only because a user on kde-look said to me that the applet was of no use for him because he had lots of devices and, unless he was able to hide some of them, the plasmoid was unusable. (comment #7 on http://kde-look.org/content/show.php?content=106051forumpage=2). wrote: i still think a better answer is to extend the disk monitor. however, as the places view does indeed have this behaviour, for consistency i suppose the device notifier can/should too. please make it consistent with the places view (e.g. in dolphin), however, so that the show all entry isn't shown unless there are hidden items to show. after that, this patch can go in afaic. do you have an svn account? if not, would you like to continue working on this (and/or other items) in KDE's svn? ok, i'll do this change and i think this evening i'll send the new revision. no, i don't have an svn account, and yes, i'd like to continue to work on KDE (preferably
Re: MediaCenterComponents - Picasa Engine
On Monday 14 September 2009 12:40:36 Alessandro Diaferia wrote: 2009/9/14 Sebastian Kügler se...@kde.org On Saturday 12 September 2009 16:49:01 Alessandro Diaferia wrote: I've had a look at the code and I feel it can be merged into MediaCenterComponents since I plan to provide models to navigate through webservices like picasa, youtube and so on. As from what i've achieved with mediacenter there's already a good api to start writing a model for both the youtube engine and this one. Any objection? Suggestions from the kde-silk team? It would be a good idea to make the API (names of sources, returned data) generic for image webservices, so it's easier to just exchange the dataengine in the background to use a different image webservice. +1 What do you think about a generic API for media sources in general, and then defining something more specific for each type (e.g. music, video, pictures..). Yes, as you've been working on that, maybe you can come up with a draft for the dataengine that applies to other, similar services as well? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: MediaCenterComponents - Picasa Engine
2009/9/14 Sebastian Kügler se...@kde.org On Monday 14 September 2009 12:40:36 Alessandro Diaferia wrote: 2009/9/14 Sebastian Kügler se...@kde.org On Saturday 12 September 2009 16:49:01 Alessandro Diaferia wrote: I've had a look at the code and I feel it can be merged into MediaCenterComponents since I plan to provide models to navigate through webservices like picasa, youtube and so on. As from what i've achieved with mediacenter there's already a good api to start writing a model for both the youtube engine and this one. Any objection? Suggestions from the kde-silk team? It would be a good idea to make the API (names of sources, returned data) generic for image webservices, so it's easier to just exchange the dataengine in the background to use a different image webservice. +1 What do you think about a generic API for media sources in general, and then defining something more specific for each type (e.g. music, video, pictures..). Yes, as you've been working on that, maybe you can come up with a draft for the dataengine that applies to other, similar services as well? -- 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 I can propose a draft. I think I'll discuss about it today live together with Francesco.. I'll post the draft here as soon as i get something convincing :) -- Alessandro Diaferia KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: MediaCenterComponents - Picasa Engine
On Monday 14 September 2009 14:21:38 Alessandro Diaferia wrote: I can propose a draft. I think I'll discuss about it today live together with Francesco.. I'll post the draft here as soon as i get something convincing :) Cool, looking forward to seeing it. Keep in mind that we'll want to do the same for other content sources as well. In the end, we might write applets for a type of dataengine and make the dataengine implementation that is used configurable. That way, we get content provider plugins for specific services. And we could even write tests for it :D -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Nepomuk Virtual Folders as Background
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1605/ --- Review request for Plasma. Summary --- This patch enables the use of Nepomuk's virtual folders in slide show mode for image wallpaper. The use case is something like creating a tag Wallpaper for some photos on digikam for example, make it sync with Nepomuk and configuring the slideshow to use nepomuksearch:/hasTag:Wallpaper as a folder. Problems: after rebooting, plasma comes up before Nepomuk and then we get an error and the wallpapers are not displayed. Ideas ? It was the first time I played with KIO too, so I may be doing something wrong ;) reviews really appreciated. Diffs - trunk/KDE/kdebase/workspace/plasma/wallpapers/image/backgroundlistmodel.h 1021511 trunk/KDE/kdebase/workspace/plasma/wallpapers/image/backgroundlistmodel.cpp 1021511 trunk/KDE/kdebase/workspace/plasma/wallpapers/image/image.cpp 1021511 Diff: http://reviewboard.kde.org/r/1605/diff Testing --- Using the virtual folder with my slide show as background. After reboot I saw the bug above mentioned. Thanks, Artur ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[PATCH] Fix annoying wallpaper list update behavior.
As from what happens with the current approach the view that lists available wallpapers is connected to the modified() SLOT through the activated() SIGNAL. But when the global preferences are set to use Double Click you have to double click each item in the view in order to see the preview before applying the wallpaper. This is a little annoying since there's apparently no need for the view to wait for a double click before previewing the wallpaper. In addition to this the behavior is not so intuitive. This patch comes then: Index: image/image.cpp === --- image/image.cpp (revisione 1022077) +++ image/image.cpp (copia locale) @@ -127,7 +127,7 @@ QWidget* Image::createConfigurationInter fillMetaInfo(b); } } -connect(m_uiImage.m_view, SIGNAL(activated(const QModelIndex )), this, SLOT(pictureChanged(const QModelIndex ))); +connect(m_uiImage.m_view, SIGNAL(clicked(const QModelIndex )), this, SLOT(pictureChanged(const QModelIndex ))); m_uiImage.m_pictureUrlButton-setIcon(KIcon(document-open)); connect(m_uiImage.m_pictureUrlButton, SIGNAL(clicked()), this, SLOT(showFileDialog())); Is it ok for you to commit it? -- Alessandro Diaferia KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: MediaCenterComponents - Picasa Engine
2009/9/14 Sebastian Kügler se...@kde.org On Monday 14 September 2009 14:21:38 Alessandro Diaferia wrote: I can propose a draft. I think I'll discuss about it today live together with Francesco.. I'll post the draft here as soon as i get something convincing :) Cool, looking forward to seeing it. Keep in mind that we'll want to do the same for other content sources as well. In the end, we might write applets for a type of dataengine and make the dataengine implementation that is used configurable. That way, we get content provider plugins for specific services. And we could even write tests for it :D -- 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 That's great! Do we want to keep the API on the DataEngine's query side or do we want to provide a set of inherited DataEngines such as for example Plasma::MediaContentsDataEngine ? But probably that's too much. -- Alessandro Diaferia KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: MediaCenterComponents - Picasa Engine
On Monday 14 September 2009 15:06:35 Alessandro Diaferia wrote: That's great! Do we want to keep the API on the DataEngine's query side or do we want to provide a set of inherited DataEngines such as for example Plasma::MediaContentsDataEngine ? But probably that's too much. On the one hand, it would make sense to share some common code, on the other hand, having an abstract mediacontent engine might not be what we want (since DataEngine is already abstract enough and should work fine). I suspect that this is something we'll find out as we have code for more than one or two engines. That should give us a better feeling for how much abstraction makes sense here. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Nepomuk Virtual Folders as Background
On Monday 14 September 2009, 10:28 Sebastian Kügler wrote: This is something that would also be really cool for the picture frame applet. :) That's true! It would be awesome to have picture frame applets to show different nepomuk virtual folders! :) Cheers! -- Artur Duque de Souza openBossa INdT - Instituto Nokia de Tecnologia -- Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net -- signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PATCH] BUG 167388 inconsistency in ~/.kde4/share/config/trashrc
[Too much cross-posting, removing kde-devel from the CC list]
On Wednesday 02 September 2009, 潘卫平(Peter Pan) wrote:
===
--- trashimpl.cpp (revision 1018673)
+++ trashimpl.cpp (working copy)
@@ -771,6 +771,7 @@
void TrashImpl::fileAdded()
{
+m_config.reparseConfiguration();
KConfigGroup group = m_config.group( Status );
if ( group.readEntry( Empty, true) == true ) {
group.writeEntry( Empty, false );
This one makes sense indeed. Before reading we have to re-read from
disk. Well, ideally only if it changed, so another fix would be to use
KDirWatch on ktrashrc.
@@ -784,6 +785,7 @@
void TrashImpl::fileRemoved()
{
if ( isEmpty() ) {
+m_config.reparseConfiguration();
KConfigGroup group = m_config.group( Status );
group.writeEntry( Empty, true );
m_config.sync();
This one is not necessary. There's no point in reparsing if we're only writing
and not reading, is there? We'll overwrite any changes anyway.
But if more than one kio_trash are created, inconsistency may occur,
This is indeed true, and Tobias' answer is valid for that part.
I don't think KInterProcessLock removes the need for the reparseConfiguration
before reading, though, if that's what Tobias implied -- but I don't think it
was what he implied ;).
reparseConfiguration is expensive,
Yes, because of kdeglobals. We should turn m_config into a SimpleConfig, in
fact, so that it only reads the local trashrc and not any kdeglobals or global
trashrc. I'll do that, you commit the reparseConfiguration and close the bug?
Thanks!
Tobias: hmm I just noticed that you used ktrashrc for the user settings,
while the empty/not-empty flag is in trashrc, for a reason I cannot remember.
On one hand we should probably merge that so that it's less confusing, on the
other hand it would make reparseConfiguration more expensive again ;-)
--
David Faure, fa...@kde.org, sponsored by Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add tooltips to the SystemTray show/icon hidden icons button
2009/9/13 Darío Andrés andresbajotie...@gmail.com: On 2009-05-05 15:57:15, Aaron Seigo wrote: this will have to wait for 4.4 now due to the string freeze, but that will also give us time to track down the tooltip issue? :) Beat Wolf wrote: did anybody commit this? so the bugreport can be closed OK, I just retested it and it works properly now. I can't reproduce the issue I described before. I'm going to commit when SVN is up again. Mh, I got a new issue, can anyone check it ? (I have the Korgac icon (new SystrayProtocol) hidden) 1) Hover the Show Hidden Icons arrow, and wait until the popup appears 2) Click it and do not move the mouse The show hidden icons popup dissapear, but the Korgac icon popup appears (as it is the first hidden icon that re-appeared) The mouse cursor is still in the same place (now pointing to a different system tray icon). If you click, you will activate the systemtray icon that is behind the mouse cursor, so the Korgac icon is not involved at all.. Darío --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/630/#review1069 --- On 2009-04-25 15:31:01, Darío Andrés wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/630/ --- (Updated 2009-04-25 15:31:01) Review request for Plasma. Summary --- This adds a tooltip to the SystemTray icon which hides or shows the hidden icons. It may need better texts. Addresses bug 183953 This addresses bug 183953. https://bugs.kde.org/show_bug.cgi?id=183953 Diffs - svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebase/workspace/plasma/applets/systemtray/ui/taskarea.cpp 958965 Diff: http://reviewboard.kde.org/r/630/diff Testing --- Thanks, Darío ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: associate an external tool to an applet
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1606/ --- Review request for Plasma. Summary --- first implementation of an idea discussed @tokamak: add api to assign the execution of something to an applet. the rationale is to launch an app that is the full version of that applet, where the applet serves as little preview. it is possible to assign a kservice (usually used with kservice::servicefromdesktopfile(app name)) and an optional argument. if the service is missing and the argument url is present the url will be opened based on its mimetype. an applethandle icon and a context menu entry will be added to launch that external tool now there are roe rough edges: -api: pass kservice and url or just strings to make bindings easier? -urls: right now there is only one parameter: maybe having support for a list? -naming: now all the names are talking about an external tool, the applet handle uses the maximize icon, calling it maximize everywhere? i would leave external tool in the api and call maximize the action and the action text, that is what is presented to the user.. Diffs - /trunk/KDE/kdelibs/plasma/applet.h 1023331 /trunk/KDE/kdelibs/plasma/applet.cpp 1023331 /trunk/KDE/kdelibs/plasma/containment.cpp 1023331 /trunk/KDE/kdelibs/plasma/private/applet_p.h 1023331 /trunk/KDE/kdelibs/plasma/private/applethandle.cpp 1023331 /trunk/KDE/kdelibs/plasma/private/applethandle_p.h 1023331 Diff: http://reviewboard.kde.org/r/1606/diff Testing --- Thanks, Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: workspace/plasma filesystem reorganization
On Sunday 13 September 2009, Marco Martin wrote: Hi all, at tokamak we talked about moving stuff around in workspace/plsma, to better distinguish between the desktop shell, the netbook shell and possibly other future things. as i mentioned in an old message, i think a hyerarchy like that would make sense: |-desktop | | |-applets | |-containments | | `-shells |-netbook | `-the whole hierarchy again there |-common | |-wallpapers |-scriptengines |-applets, the ones not shell-specific `-libplasma-workspace libplasma-workspace would be a dynamic lib, private without headers installed and would contain what shells/common has today uh, and another thing: maybe the widget explorer to be another separate library, so in workspace/libs we would have libplasmagenericshell (or libplasmageneric) and libplasmawidgetexplorer comments? improvements? as soon as we agree on one i can start making damages :) Cheers Marco Martin -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: big revamp of Device Notifier
On 2009-09-11 19:44:22, Aaron Seigo wrote: /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.cpp, line 366 http://reviewboard.kde.org/r/1370/diff/5/?file=10962#file10962line366 this is only needed if m_showOnlyRemovable changes, correct? wrote: it is used also to hide or show the devices when you (un)check the option show all the items in the context menu. wrote: yes, that's what i said :) wrote: no, i mean when you right click the dialog, and you set the option to show or not even devices that normally would be hidden too. like when you right click on the Places panel in dolphin. In fact resetDevices() is called in configAccepted() (if m_showOnlyRemovable changes) and in setAllItemsShown(bool shown) (if m_showAll changes). wrote: ok, let's back up a bit here. that call to resetDevices is in DeviceNotifier::configAccepted. so i'm talking about when the configuration is changed. that means that in configAccepted, which is what line 365 here is, resetDevices _does not need to be called_ unless m_showOnlyRemovable changes. make sense? now forward again :) looking a m_showAll in NotifierView, Show All devices is always in the context menu and always enabled, even when there is nothing to show. probably, if there are no items to show there doesn't need to be a context menu in the view at all. i'm still not really sure what the real world use cases for hiding/showing individual items in the notifier are other than it's neat that i can; i'm trying to imagine someone who has so many items listed there that it's unmanagable otherwise. or someone who keeps two items in one notifier widget and has a second notifier widget with some others? hm. on the other hand, i can see this resulting in confusion when when someone plugs a device in, marks it to not be shown, then later plugs it in (and hopefully it's impossible to have different devices with the same name?) and it doesn't show up. particularly is days or weeks have passed between those two events. and why would i NOT want my camera to show up when i plug it in? what's the use case for that? this is why i'm still really unsure that turning the device *notifier* into a device *listing manager* in this way is the best of ideas. there's really two similar ideas here it seems: managing devices that are plugged and unplugged (which may or may not be storage devices) and listing storage devices. we actually have a widget for both of those tasks, but the storage device lister doesn't provide access to actions related to the device, which the device notifier does. this really comes back to use cases. can you provide use cases to go with the hide/show individual items feature? oh, and the widget should emit configNeedsSaving() after calls to writeEntry :) wrote: ok, i misunderstood a bit what you wanted to say. so, yes. in configAccepted() the call to resetDevices() is needed only if m_showOnlyRemovable changes, so we could actually check if the variable changed value and only in the case call resetDevices() and better yet add or remove the not removable devices without reset all the devices. as regards the show/hide system: saying that Show all devices is always enabled you mean it's always checked? if it is it is definitely a bug in the patch. i don't think the fact that the context menu is shown even when there are no devices is a big deal, but anyway it would be simple to make a check. anyway it uses the uuid provided by solid and not the names to identify the devices, so if you have two devices with the same name and you hide one, the other will remain visible (unless the uuid are equals, but i think this is a really rare case, if it is possible). Actually i decided to develop this feature only because a user on kde-look said to me that the applet was of no use for him because he had lots of devices and, unless he was able to hide some of them, the plasmoid was unusable. (comment #7 on http://kde-look.org/content/show.php?content=106051forumpage=2). wrote: i still think a better answer is to extend the disk monitor. however, as the places view does indeed have this behaviour, for consistency i suppose the device notifier can/should too. please make it consistent with the places view (e.g. in dolphin), however, so that the show all entry isn't shown unless there are hidden items to show. after that, this patch can go in afaic. do you have an svn account? if not, would you like to continue working on this (and/or other items) in KDE's svn? wrote: ok, i'll do this change and i think this evening i'll send the new revision. no, i don't have an svn account, and yes, i'd like to continue to
Re: MediaCenterComponents - Picasa Engine
On September 14, 2009, Sebastian Kügler wrote: It would be a good idea to make the API (names of sources, returned data) generic for image webservices, so it's easier to just exchange the dataengine in the background to use a different image webservice. instead of writing N different DataEngines and trying to keep them all in sync with each other, what about writing one DataEngine for, e.g. fetching images, and then allow different backends to feed that one DataEngine? this is how weather and comics work, and it keeps the interface to the visualizations consistent because as far as they are concerned there only is one interface. -- 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: workspace/plasma filesystem reorganization
On September 14, 2009, Marco Martin wrote: uh, and another thing: maybe the widget explorer to be another separate library, so in workspace/libs we would have libplasmagenericshell (or libplasmageneric) and libplasmawidgetexplorer why? -- 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
QtScript bindings
Mark said you were interested in QtScript bindings. Do you want bindings of the chunks of the Qt api + Plamsa API? Or just a simplified subset of the Plasma API? If its the former, we should talk. :) I've started the very beginnings of a Smoke-based binding. If its the latter, then you really don't need Smoke or binding generators, QtScript is pretty easy to make bindings with. Ian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma wallpaper changing via D-Bus
Hi, I am trying to implement D-Bus to plasma. I'm only interested in changing the wallpaper. I've downloaded the kdebase-workspace files and kdelibs. But I don't know where to go after here. I have intermediate knowledge of d-bus and intermediate knowledge of C++. Can you point me to the right direction. Thank you. -- Renan Cakirerk ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: fix a Plasma crash with a 16-bit screen depth and Qt 4.6
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1608/ --- Review request for Plasma. Summary --- Meke sure that Plasma only tries to apply its software Gaussian blur to 32-bit QImages, since it will corrupt memory if applied to ones with lower bit depths. Add a Q_ASSERT to the effect to make testing easier. This addresses bug 207290. https://bugs.kde.org/show_bug.cgi?id=207290 Diffs - /trunk/KDE/kdebase/workspace/plasma/applets/tasks/abstracttaskitem.cpp 1023128 /trunk/KDE/kdelibs/plasma/private/effects/blur.cpp 1023128 Diff: http://reviewboard.kde.org/r/1608/diff Testing --- Thanks, Benjamin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: workspace/plasma filesystem reorganization
On 14-09-2009 at 17:38:51 Marco Martin notm...@gmail.com wrote: uh, and another thing: maybe the widget explorer to be another separate library, so in workspace/libs we would have libplasmagenericshell (or libplasmageneric) and libplasmawidgetexplorer Maybe simply libplasmashell? I think that generic or common doesn't fit there. ;-) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma wallpaper changing via D-Bus
On September 14, 2009, Renan Cakirerk wrote: Hi, I am trying to implement D-Bus to plasma. I'm only interested in cool; I believe Ivan has started on d-bus introspection into plasma. what are your use case(s) for this? (that can impact how this is implemented) the short story for how d-bus exposure should look like is that the d-bus interfaces would need to follow the structure in plasma itself: access to the Corona, which can enumerate the Containments, and each Containment can enumerate its widgets and background. however, depending on the use case, it may make more sense to use the javascript based interactive console for things like setting the wallpaper. but that really depends on your use case(s). p.s. if you want to work on this, i'd highly recommend joining the mailing list so you can keep up with our efforts in this area. -- 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: [PATCH] Fix annoying wallpaper list update behavior.
On September 14, 2009, Alessandro Diaferia wrote: Is it ok for you to commit it? +1 -- 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: Review Request: fix a Plasma crash with a 16-bit screen depth and Qt 4.6
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1608/#review2360 --- /trunk/KDE/kdebase/workspace/plasma/applets/tasks/abstracttaskitem.cpp http://reviewboard.kde.org/r/1608/#comment1655 this conversion should happen in explur so all users of it get this fix automatically. this also removes the need for the assert in expblur. otherwise, the patch looks good. - Aaron On 2009-09-14 15:00:05, Benjamin Stuhl wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1608/ --- (Updated 2009-09-14 15:00:05) Review request for Plasma. Summary --- Meke sure that Plasma only tries to apply its software Gaussian blur to 32-bit QImages, since it will corrupt memory if applied to ones with lower bit depths. Add a Q_ASSERT to the effect to make testing easier. This addresses bug 207290. https://bugs.kde.org/show_bug.cgi?id=207290 Diffs - /trunk/KDE/kdebase/workspace/plasma/applets/tasks/abstracttaskitem.cpp 1023128 /trunk/KDE/kdelibs/plasma/private/effects/blur.cpp 1023128 Diff: http://reviewboard.kde.org/r/1608/diff Testing --- Thanks, Benjamin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QtScript bindings
Hi Guys, What I'd personally like to do is to create the same stuff downloadable at lively.cs.tut.fi/qt inside a plasmoid using plain JavaScript. In essence everything that runs in a separate window could be a plasmoid, to the extend that I could create a debugging plasmoid for some other plasmoid. In the present implementation, we have generated full bindings to Qt APIs using qtscriptgenerator, and then we use the APIs for composing mashups etc. This means a considerable extension to Plasmoid JavaScript interfaces, including stuff like xml processing, networking etc. tjm Ian Monroe wrote: Mark said you were interested in QtScript bindings. Do you want bindings of the chunks of the Qt api + Plamsa API? Or just a simplified subset of the Plasma API? If its the former, we should talk. :) I've started the very beginnings of a Smoke-based binding. If its the latter, then you really don't need Smoke or binding generators, QtScript is pretty easy to make bindings with. Ian ___ 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: MediaCenterComponents - Picasa Engine
2009/9/14 Aaron J. Seigo ase...@kde.org On September 14, 2009, Sebastian Kügler wrote: It would be a good idea to make the API (names of sources, returned data) generic for image webservices, so it's easier to just exchange the dataengine in the background to use a different image webservice. instead of writing N different DataEngines and trying to keep them all in sync with each other, what about writing one DataEngine for, e.g. fetching images, and then allow different backends to feed that one DataEngine? this is how weather and comics work, and it keeps the interface to the visualizations consistent because as far as they are concerned there only is one interface. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel That was in my plans as discussed with Marco times ago during the GSoC period.. I'll try to see from comics and weather :) -- Alessandro Diaferia KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QtScript bindings
We already talked about this on IRC, so just recording for everyone else. On Mon, Sep 14, 2009 at 12:14 PM, Aaron J. Seigo ase...@kde.org wrote: On September 14, 2009, Ian Monroe wrote: Do you want bindings of the chunks of the Qt api + Plamsa API? Or just a simplified subset of the Plasma API? both, as separate entities; and we already have the latter in fairly decent shape at this point. If its the former, we should talk. :) I've started the very beginnings of a Smoke-based binding. smoke based? have you looked into the qscript generator that Kent @ Qt has been working on (for a long time now ... i wonder why there isn't more news about it by now...) This is what Amarok already uses. We have a long torrid history together (I ported it to cmake, and then later pissed off all the distros by requiring it as a separate dependency). The problem is that uses massive amounts of memory. in any case, yes, we are -quite- interested in full qt+kdelibs QScript bindings Cool. I'll be emailing later today or tomorrow and we can get started in Gitorious. I'm also going to email Kent to make sure I'm not pulling a Brisbane. Ian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QtScript bindings
On September 14, 2009, Tommi Mikkonen wrote: What I'd personally like to do is to create the same stuff downloadable at lively.cs.tut.fi/qt inside a plasmoid using plain JavaScript. In once we have full qt/kdelibs bindings available to us, this should be trivial. it would be really interesting to see what can be done at that point as Lively seems very interesting. In the present implementation, we have generated full bindings to Qt APIs using qtscriptgenerator, and then we use the APIs for composing mashups etc. This means a considerable extension to Plasmoid JavaScript interfaces, including stuff like xml processing, networking etc. which is great for trusted content; for untrusted content (or for people who don't want to get neck deep into the full APIs), the simplified JS interface will continue to exist. -- 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: QtScript bindings
Aaron J. Seigo wrote: On September 14, 2009, Tommi Mikkonen wrote: What I'd personally like to do is to create the same stuff downloadable at lively.cs.tut.fi/qt inside a plasmoid using plain JavaScript. In once we have full qt/kdelibs bindings available to us, this should be trivial. it would be really interesting to see what can be done at that point as Lively seems very interesting. Based on experiences from the students and other folks, developing cool widgets and little apps takes only few hours. Moreover, the system has proven to be surprisingly robust against small errors in the content downloaded from the net. In the present implementation, we have generated full bindings to Qt APIs using qtscriptgenerator, and then we use the APIs for composing mashups etc. This means a considerable extension to Plasmoid JavaScript interfaces, including stuff like xml processing, networking etc. which is great for trusted content; for untrusted content (or for people who don't want to get neck deep into the full APIs), the simplified JS interface will continue to exist. Agreed, and my thoughts exactly. Having said that, what I would also like is a harmonized API; having finally spend some hours tonight (after traveling in conferences for some weeks!) on JS Plasmoid development with Lively content, I constantly seem to have problems on the names of widget types etc. Only a subset would be available for unreliable stuff, and the full set for reliable plasmoids. tjm ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QtScript bindings
On September 14, 2009, Tommi Mikkonen wrote: Having said that, what I would also like is a harmonized API; having finally spend some hours tonight (after traveling in conferences for some weeks!) on JS Plasmoid development with Lively content, I constantly seem to have problems on the names of widget types etc. can you provide some concrete examples? -- 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: QtScript bindings
Aaron J. Seigo wrote: On September 14, 2009, Tommi Mikkonen wrote: Having said that, what I would also like is a harmonized API; having finally spend some hours tonight (after traveling in conferences for some weeks!) on JS Plasmoid development with Lively content, I constantly seem to have problems on the names of widget types etc. can you provide some concrete examples? QFrame vs. Frame and QWebView vs. Webview is QtScriptGenerator and Plasmoids, and at the same time QtVertical in native Qt, QtScriptGenerator and Plasmoids. Another issue is with types when adding a Qt widget that has been instantiated in C++. At least http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/CheatSheet documents that at times a QPainter etc is expected as parameter whereas Plasma uses name Painter etc. As the error message I get is 'script could not be initialized' or something similar when misspelling a class name, it is very frustrating to debug API usage. This is not a major issue, and any convention will be ok for me. However, if we have two scripting systems --- one wirh privileges and another without --- it will be confusing if type names etc. are different. An additional issue is that if we have these two sets, the restricted one should not fail without error messages if someone tests privileged APIs but give an error message etc. Personally, I can live with either API; both are probably fine for most developers but there should only be one. In a perfect world, we could have two, one for privileged apps and the other for regular ones. I am however worried that this will complicate the view a casual developer will get to Plasma widget development. tjm ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
KDE/kdebase/workspace/plasma
SVN commit 1023511 by mart: move stuff around: all containments,applets etc are in the subdirectory of their topic: that is generic: stuff that is condivided among different shells desktop: desktop shell specific netbook: shell, containments, applets and dataengines used for the netbook shell screensaver: the shell and containment of the screensaver overlay CCMAIL:plasma-devel@kde.org M +4 -9 CMakeLists.txt D animators (directory) D applets (directory) D containmentactions (directory) D containments (directory) D dataengines (directory) A desktop (directory) A desktop/CMakeLists.txt AMdesktop/containments (directory) containments#1023065 M +0 -1 desktop/containments/CMakeLists.txt D desktop/containments/screensaver (directory) A desktop/shells (directory) A desktop/shells/CMakeLists.txt A desktop/shells/desktop (directory) shells/desktop#1023065 A desktop/shells/desktop/CMakeLists.txt shells/desktop/CMakeLists.txt#1023440 M +1 -1 desktop/shells/desktop/interactiveconsole.cpp A desktop/shells/desktop/plasmaapp.cpp shells/desktop/plasmaapp.cpp#1023450 [License: LGPL (v2+)] A generic (directory) A generic/CMakeLists.txt AMgeneric/animators (directory) animators#1023065 AMgeneric/applets (directory) applets#1023065 AMgeneric/containmentactions (directory) containmentactions#1023065 AMgeneric/dataengines (directory) dataengines#1023065 AMgeneric/runners (directory) runners#1023065 AMgeneric/scriptengines (directory) scriptengines#1023065 A generic/shells (directory) A generic/shells/CMakeLists.txt A generic/shells/plasmoidviewer (directory) shells/plasmoidviewer#1023065 AMgeneric/wallpapers (directory) wallpapers#1023065 D runners (directory) A screensaver (directory) A screensaver/CMakeLists.txt A screensaver/containments (directory) A screensaver/containments/CMakeLists.txt A screensaver/containments/screensaver (directory) containments/screensaver#1023065 A screensaver/shells (directory) A screensaver/shells/CMakeLists.txt A screensaver/shells/screensaver (directory) shells/screensaver#1023065 M +10 -20screensaver/shells/screensaver/CMakeLists.txt M +1 -1 screensaver/shells/screensaver/backgrounddialog.cpp M +13 -8 screensaver/shells/screensaver/saverview.cpp M +1 -2 screensaver/shells/screensaver/saverview.h D scriptengines (directory) D shells/desktop (directory) D shells/plasmoidviewer (directory) D shells/screensaver (directory) D wallpapers (directory) --- trunk/KDE/kdebase/workspace/plasma/CMakeLists.txt #1023510:1023511 @@ -1,13 +1,8 @@ add_definitions(-DKDE_DEFAULT_DEBUG_AREA=1204) -add_subdirectory(animators) -add_subdirectory(applets) -add_subdirectory(containments) -add_subdirectory(containmentactions) -add_subdirectory(dataengines) +add_subdirectory(desktop) +add_subdirectory(generic) add_subdirectory(netbook) -add_subdirectory(runners) -add_subdirectory(scriptengines) -add_subdirectory(shells) +add_subdirectory(screensaver) add_subdirectory(tools) -add_subdirectory(wallpapers) + ** trunk/KDE/kdebase/workspace/plasma/desktop/containments #property svn:mergeinfo + --- trunk/KDE/kdebase/workspace/plasma/desktop/containments/CMakeLists.txt #1023065:1023511 @@ -1,3 +1,2 @@ add_subdirectory(desktop) add_subdirectory(panel) -add_subdirectory(screensaver) --- trunk/KDE/kdebase/workspace/plasma/desktop/shells/desktop/interactiveconsole.cpp #1023065:1023511 @@ -41,7 +41,7 @@ #include Plasma/Corona -#include scriptengine.h +#include scripting/scriptengine.h //TODO: // use text editor KPart for syntax highlighting? ** trunk/KDE/kdebase/workspace/plasma/generic/animators #property svn:mergeinfo + ** trunk/KDE/kdebase/workspace/plasma/generic/applets #property svn:mergeinfo + ** trunk/KDE/kdebase/workspace/plasma/generic/containmentactions #property svn:mergeinfo + ** trunk/KDE/kdebase/workspace/plasma/generic/dataengines #property svn:mergeinfo + **
Re: KDE/kdebase/workspace/plasma
On Monday 14 September 2009, Marco Martin wrote: SVN commit 1023511 by mart: move stuff around: all containments,applets etc are in the subdirectory of their topic: that is generic: stuff that is condivided among different shells desktop: desktop shell specific netbook: shell, containments, applets and dataengines used for the netbook shell screensaver: the shell and containment of the screensaver overlay CCMAIL:plasma-devel@kde.org let me know if there are problems, here builds i hope having done svn add to everything is needed :) move of stuff was pretty arbitrary, individual components can still be moved around, esp individual applets (atm kickoff,pager,tasks and trash are in desktop, all others in generic) also, in moving i noticed the screensaver shell still tried to include and use appletbrowser.h, i really wonder why it was still building. now those parts are just commented out but a port is badly needed. M +4 -9 CMakeLists.txt D animators (directory) D applets (directory) D containmentactions (directory) D containments (directory) D dataengines (directory) A desktop (directory) A desktop/CMakeLists.txt AMdesktop/containments (directory) containments#1023065 M +0 -1 desktop/containments/CMakeLists.txt D desktop/containments/screensaver (directory) A desktop/shells (directory) A desktop/shells/CMakeLists.txt A desktop/shells/desktop (directory) shells/desktop#1023065 A desktop/shells/desktop/CMakeLists.txt shells/desktop/CMakeLists.txt#1023440 M +1 -1 desktop/shells/desktop/interactiveconsole.cpp A desktop/shells/desktop/plasmaapp.cpp shells/desktop/plasmaapp.cpp#1023450 [License: LGPL (v2+)] A generic (directory) A generic/CMakeLists.txt AMgeneric/animators (directory) animators#1023065 AMgeneric/applets (directory) applets#1023065 AMgeneric/containmentactions (directory) containmentactions#1023065 AMgeneric/dataengines (directory) dataengines#1023065 AMgeneric/runners (directory) runners#1023065 AMgeneric/scriptengines (directory) scriptengines#1023065 A generic/shells (directory) A generic/shells/CMakeLists.txt A generic/shells/plasmoidviewer (directory) shells/plasmoidviewer#1023065 AMgeneric/wallpapers (directory) wallpapers#1023065 D runners (directory) A screensaver (directory) A screensaver/CMakeLists.txt A screensaver/containments (directory) A screensaver/containments/CMakeLists.txt A screensaver/containments/screensaver (directory) containments/screensaver#1023065 A screensaver/shells (directory) A screensaver/shells/CMakeLists.txt A screensaver/shells/screensaver (directory) shells/screensaver#1023065 M +10 -20 screensaver/shells/screensaver/CMakeLists.txt M +1 -1 screensaver/shells/screensaver/backgrounddialog.cpp M +13 -8 screensaver/shells/screensaver/saverview.cpp M +1 -2 screensaver/shells/screensaver/saverview.h D scriptengines (directory) D shells/desktop (directory) D shells/plasmoidviewer (directory) D shells/screensaver (directory) D wallpapers (directory) --- trunk/KDE/kdebase/workspace/plasma/CMakeLists.txt #1023510:1023511 @@ -1,13 +1,8 @@ add_definitions(-DKDE_DEFAULT_DEBUG_AREA=1204) -add_subdirectory(animators) -add_subdirectory(applets) -add_subdirectory(containments) -add_subdirectory(containmentactions) -add_subdirectory(dataengines) +add_subdirectory(desktop) +add_subdirectory(generic) add_subdirectory(netbook) -add_subdirectory(runners) -add_subdirectory(scriptengines) -add_subdirectory(shells) +add_subdirectory(screensaver) add_subdirectory(tools) -add_subdirectory(wallpapers) + ** trunk/KDE/kdebase/workspace/plasma/desktop/containments #property svn:mergeinfo + --- trunk/KDE/kdebase/workspace/plasma/desktop/containments/CMakeLists.txt #1023065:1023511 @@ -1,3 +1,2 @@ add_subdirectory(desktop) add_subdirectory(panel) -add_subdirectory(screensaver) --- trunk/KDE/kdebase/workspace/plasma/desktop/shells/desktop/interactiveconsol e.cpp #1023065:1023511 @@ -41,7 +41,7 @@ #include Plasma/Corona -#include scriptengine.h +#include scripting/scriptengine.h //TODO: // use text editor KPart for syntax highlighting? ** trunk/KDE/kdebase/workspace/plasma/generic/animators #property svn:mergeinfo + ** trunk/KDE/kdebase/workspace/plasma/generic/applets #property svn:mergeinfo + ** trunk/KDE/kdebase/workspace/plasma/generic/containmentactions #property svn:mergeinfo + **
Re: [PATCH] Fix annoying wallpaper list update behavior.
On Mon, Sep 14, 2009 at 4:57 PM, Aaron J. Seigo ase...@kde.org wrote: On September 14, 2009, Alessandro Diaferia wrote: Is it ok for you to commit it? +1 -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Yeah I agree with the functionality, I hated this double clicking, and it isn't clear at all.. it took me a second to figure it out too (I first clicked my wallpaper, then clicked OK and wondered why it didn't work..).. Also, the problem(imho) , is that with the Open File Dialog, last time I checked, did not select(click), the item that you have just chosen in that dialog... this is not related, right? Because I'd really like that problem fixed... it's kind of annoying, and I believe that it is quite obvious that you are opening the image with the intent to set the current background as the image you have selected ..not doing it for your good health ;-) -- KDE Developer, Shaun Reich ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: big revamp of Device Notifier
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1370/ --- (Updated 2009-09-14 21:26:48.596052) Review request for Plasma. Changes --- -doesn't draw anymore the Show all items actions in the context menu if there aren't hidden items. -removed the useSvg in freespacedelegate.cpp Now i'll go and get an SVN account, and after that i'll commit it, ok? Summary --- This is a patch that modifies quite heavily the behaviour of the Device Notifier. It comes from here: http://kde-look.org/content/show.php/Device+Manager?content=106051 It can show the not removable devices too, it can mount them automatically or with a click, since the eject button is a mount button when the volume is umounted. So that guy on the dot will be ok. It can hide some items in the same way as Dolphin's places (hide item/ show all). Finally, it shows the various opening actions under the device instead of calling that xp-ish window. Diffs (updated) - /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/CMakeLists.txt 1022457 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/configurationpage.ui PRE-CREATION /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.h 1022457 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.cpp 1022457 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicespaceinfodelegate.h 1022457 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicespaceinfodelegate.cpp 1022457 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/notifierdialog.h 1022457 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/notifierdialog.cpp 1022457 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/notifierview.h 1022457 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/notifierview.cpp 1022457 Diff: http://reviewboard.kde.org/r/1370/diff Testing --- I'm using it every day since I released 0.1 on Kde-look. I tried all the options on my pc and they work. Some people on kde-look posted some comments about some problems, but it seems to me they are very particular cases, so in my opinion it is quite stable to go in trunk, but anyway review it! :) Screenshots --- screen http://reviewboard.kde.org/r/1370/s/183/ Thanks, Giulio ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PATCH] Fix annoying wallpaper list update behavior.
2009/9/14 Shaun Reich predator...@gmail.com Also, the problem(imho) , is that with the Open File Dialog, last time I checked, did not select(click), the item that you have just chosen in that dialog... this is not related, right? Because I'd really like that problem fixed... it's kind of annoying, and I believe that it is quite obvious that you are opening the image with the intent to set the current background as the image you have selected ..not doing it for your good health ;-) https://mail.kde.org/mailman/listinfo/plasma-devel Oh, didn't notice that, i'll take a look then. In the while i've committed the fix for the view. Cheers -- Alessandro Diaferia KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PATCH] Fix annoying wallpaper list update behavior.
2009/9/14 Alessandro Diaferia alediafe...@gmail.com 2009/9/14 Shaun Reich predator...@gmail.com Also, the problem(imho) , is that with the Open File Dialog, last time I checked, did not select(click), the item that you have just chosen in that dialog... this is not related, right? Because I'd really like that problem fixed... it's kind of annoying, and I believe that it is quite obvious that you are opening the image with the intent to set the current background as the image you have selected ..not doing it for your good health ;-) https://mail.kde.org/mailman/listinfo/plasma-devel Oh, didn't notice that, i'll take a look then. In the while i've committed the fix for the view. Cheers -- Alessandro Diaferia KDE Developer Ok, checked it out and now it works properly after the commit :) -- Alessandro Diaferia KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Patch to add a 7-day (up-to) forecast to the NOAA weather Ion
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1584/ --- (Updated 2009-09-14 23:24:56.419041) Review request for Plasma and Shawn Starr. Changes --- - Added forecast condition keywords as defined at http://www.weather.gov/mdl/XML/Design/MDL_XML_Design.htm#_Toc141760783 (some don't seem to fit in any existing category) - i18n'zd the forecast-summary and added available definitions to the dat file. Summary --- The patch uses the REST API provided by NOAA at http://www.weather.gov/forecasts/xml/rest.php to obtain the forecast for the location coordinates returned by the observation data. It requests the 7-day forecast but only displays the days for which data is available (usually 5-7 days). The weather icon descriptions unfortunately don't match those used by the normal observation feed, and are defined at http://www.weather.gov/forecasts/xml/DWMLgen/schema/parameters.xsd ; we however use a similar heuristic algorithm (keyword search)) to find the best match for the returned weather conditions. This patch also enables the normal condition icon which was being mistakenly being unset. Diffs (updated) - trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/data/noaa_i18n.dat 1016572 trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_noaa.h 1016575 trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_noaa.cpp 1021754 Diff: http://reviewboard.kde.org/r/1584/diff Testing --- Verified the NOAA forecast was displayed in the Weather Forecast applet for a few locations. Thanks, Amos ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Patch to add a 7-day (up-to) forecast to the NOAA weather Ion
On 2009-09-13 22:28:30, Shawn Starr wrote: It looks fine, but please make sure any new strings are wrapped in proper i18n(). I cannot approve this commit until that's please. spstarr: I think the only think that needed to be internationalized was the weather summary so correct me if I'm wrong or need to add something else; thanks. - Amos --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1584/#review2338 --- On 2009-09-14 23:24:56, Amos Kariuki wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1584/ --- (Updated 2009-09-14 23:24:56) Review request for Plasma and Shawn Starr. Summary --- The patch uses the REST API provided by NOAA at http://www.weather.gov/forecasts/xml/rest.php to obtain the forecast for the location coordinates returned by the observation data. It requests the 7-day forecast but only displays the days for which data is available (usually 5-7 days). The weather icon descriptions unfortunately don't match those used by the normal observation feed, and are defined at http://www.weather.gov/forecasts/xml/DWMLgen/schema/parameters.xsd ; we however use a similar heuristic algorithm (keyword search)) to find the best match for the returned weather conditions. This patch also enables the normal condition icon which was being mistakenly being unset. Diffs - trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/data/noaa_i18n.dat 1016572 trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_noaa.h 1016575 trunk/KDE/kdebase/workspace/plasma/dataengines/weather/ions/ion_noaa.cpp 1021754 Diff: http://reviewboard.kde.org/r/1584/diff Testing --- Verified the NOAA forecast was displayed in the Weather Forecast applet for a few locations. Thanks, Amos ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: big revamp of Device Notifier
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1370/#review2366 --- Ship it! this can go in as a draft of what will be there for 4.4 final; changes that will still need to be made including clearing up the config dialog (i'll do that) and making it so that items with only one action associated/available will launch that action immediately on click. only items with multiple actions should expand a listing of possible actions. - Aaron On 2009-09-14 21:26:48, Giulio Camuffo wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1370/ --- (Updated 2009-09-14 21:26:48) Review request for Plasma. Summary --- This is a patch that modifies quite heavily the behaviour of the Device Notifier. It comes from here: http://kde-look.org/content/show.php/Device+Manager?content=106051 It can show the not removable devices too, it can mount them automatically or with a click, since the eject button is a mount button when the volume is umounted. So that guy on the dot will be ok. It can hide some items in the same way as Dolphin's places (hide item/ show all). Finally, it shows the various opening actions under the device instead of calling that xp-ish window. Diffs - /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/CMakeLists.txt 1022457 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/configurationpage.ui PRE-CREATION /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.h 1022457 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicenotifier.cpp 1022457 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicespaceinfodelegate.h 1022457 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/devicespaceinfodelegate.cpp 1022457 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/notifierdialog.h 1022457 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/notifierdialog.cpp 1022457 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/notifierview.h 1022457 /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/notifierview.cpp 1022457 Diff: http://reviewboard.kde.org/r/1370/diff Testing --- I'm using it every day since I released 0.1 on Kde-look. I tried all the options on my pc and they work. Some people on kde-look posted some comments about some problems, but it seems to me they are very particular cases, so in my opinion it is quite stable to go in trunk, but anyway review it! :) Screenshots --- screen http://reviewboard.kde.org/r/1370/s/183/ Thanks, Giulio ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QtScript bindings
On September 14, 2009, Tommi Mikkonen wrote: can you provide some concrete examples? QFrame vs. Frame and QWebView vs. Webview is QtScriptGenerator and Plasmoids, Frame is not a QFrame, it's a Plasma::Frame. WebView is not a QWebView, it's a Plasma::WebView. and at the same time QtVertical in native Qt, QtScriptGenerator and Plasmoids any suggestions for getting enums into the JS namsepace? . Another issue is with types when adding a Qt widget that has been instantiated in C++. At least http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/CheatSheet documents that at times a QPainter etc is expected as parameter whereas Plasma uses name Painter etc. mm.. afiacs it's always QPainter? As the error message I get is 'script could not be initialized' or something similar when misspelling a class name, it is very frustrating to debug API usage. yes, there isn't a nice debugging system yet.. This is not a major issue, and any convention will be ok for me. However, if we have two scripting systems --- one wirh privileges and another without --- it will be confusing if type names etc. are different. i'm not so sure. learning the difference between Plasma::WebView and WebView, depending on the script bindings used, is probably pretty nominal compared to becoming acquainted with the entire Qt API. also note that the simple applet JS bindings do not bind the entire API of all the classes offered, either. An additional issue is that if we have these two sets, the restricted one should not fail without error messages if someone tests privileged APIs but give an error message etc. well, yes. this is currently unimplemented. -- 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
On September 14, 2009, Chani wrote: also, in moving i noticed the screensaver shell still tried to include and use appletbrowser.h, i really wonder why it was still building. now those parts are just commented out but a port is badly needed. ah crud. :/ I don't know if I'll have time for that. it could be easy, or it could run into issues with the lack of windowmanagement and other strange things lockprocess does. the new widget browser is a QGraphicsWidget, so you should be able to place it right on the canvas. this should actually be easier than what you have there right now as there would be no window management at all needed. -- 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
On September 14, 2009, Marco Martin wrote: SVN commit 1023511 by mart: move stuff around: i really don't like the shells/ directories. plasma/netbook/shells/netbook/ plasma/desktop/shells/desktop/ plasma/screensaver/shells/screensaver that's all very redundant. there are no other entries in the shells/, nor do i think there ever will be.. the entire point of plasma/netbook/, plasma/desktop/ and plasma/screensaver/ is to separate out the shells specific to those use cases. containments/, applets/ (perhaps that should be plasmoids/?), etc. make sense because there will be (and already are) multiple instances of those for the various shells. -- 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: [PATCH] BUG 167388 inconsistency in ~/.kde4/share/config/trashrc
David Faure 写道:
[Too much cross-posting, removing kde-devel from the CC list]
On Wednesday 02 September 2009, 潘卫平(Peter Pan) wrote:
===
--- trashimpl.cpp (revision 1018673)
+++ trashimpl.cpp (working copy)
@@ -771,6 +771,7 @@
void TrashImpl::fileAdded()
{
+m_config.reparseConfiguration();
KConfigGroup group = m_config.group( Status );
if ( group.readEntry( Empty, true) == true ) {
group.writeEntry( Empty, false );
This one makes sense indeed. Before reading we have to re-read from
disk. Well, ideally only if it changed, so another fix would be to use
KDirWatch on ktrashrc.
r1023611 | peterpan | 2009-09-15 09:38:35 +0800 (二, 2009-09-15) | 3 行
call m_config.reparseConfiguration() when adding a file.
BUG:167388
Looking forward to your code using KDirWatch on ktrashrc.
Regards
--
潘卫平(Peter Pan)
Red Flag Software Co., Ltd
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Any easy way to add picture frame programmatically?
Hi, I want to add picture frame programmatically and set it content to user selected image. For example my program (not a plasmoid) has a list view which contains image thumbnails, right click on an image, then invoke add picture frame function. Can somebody give clues? Regards, Reza ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PATCH] BUG 202473 no sound on emptying trash widget although sound is configured in systemsettings
潘卫平(Peter Pan) 写道: Aaron J. Seigo 写道: On September 1, 2009, 潘卫平(Peter Pan) wrote: How about the patch followed? the applet would need to follow the contents of trash:/ then, so when a file is trashed in dolphin, konqueror or some other app it would become enabled. That has been already done in trash applet using KDirLister. Regards r1023617 | peterpan | 2009-09-15 10:41:17 +0800 (二, 2009-09-15) | 3 行 send a KNotification event when emptying trash. BUG:202473 Regards -- 潘卫平(Peter Pan) Red Flag Software Co., Ltd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Any easy way to add picture frame programmatically?
On September 14, 2009, Reza Shah wrote: Can somebody give clues? short answer: plasma is not ready for this. longer answer: letting external applications place content and/or widgets into the running desktop is really asking for problems and general abuse. we already support extensive drag and drop operations as well a (user controlled) javascripting console. but for automatic additions from external apps, there really needs to be some sort of security framework in place; at a minimum plasma-desktop should check with the user that this is what they really want. we're getting closer to that with various things we're working on (e.g. remote widgets, signing of packages, etc) but we're not there yet. -- 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: Review Request: associate an external tool to an applet
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1606/#review2367 --- /trunk/KDE/kdelibs/plasma/applet.h http://reviewboard.kde.org/r/1606/#comment1666 external - associated? tool - application? we will need to have a non-KService version of the tool definer method since not all apps will be registered in that manner. i think we could probably just take a string and figure out ourselves internally if it's a service or an executable. as for arguments ... hm. use cases could be: * command line arguments (e.g. konsole -e ls -lR) * URLs * ...? probably needs more use case thinking. if it does remain limited to URLs (and i think an API that makes launching apps with urls would be a good idea), then that might be a more generic sort of thing: associatedUrls()? it will need to support url lists. a does this applet have a valid associated app? convenience method would be nice /trunk/KDE/kdelibs/plasma/applet.cpp http://reviewboard.kde.org/r/1606/#comment1667 you should stop the job here, no? or perhaps put it on hold and publish it so that the app can then use it? /trunk/KDE/kdelibs/plasma/applet.cpp http://reviewboard.kde.org/r/1606/#comment1668 is this synchronous? i think it is; probably should create a KRun object and connect to its signals (or just ignore the result, even?) so that it isn't synchronous and holding up the application. /trunk/KDE/kdelibs/plasma/applet.cpp http://reviewboard.kde.org/r/1606/#comment1670 you know what would be dreadfully cool? if there was an external tool manager that, when an app was triggered, it would see if that resulted in a window popping up. if so, then it could track that window and as long as that window existed, it could become associated with the widget? might not work so hot, i suppose, if you open an image in a viewer, navigate to another image in the viewer, and then click the widget's run icon again. hmm... another benefit of having a manager for these would be that instead of having an extra set of members in the applet's dptr regardless of whether or not it uses this feature, there would only be one manager and only as many objects in memory as there are widgets using this feature. /trunk/KDE/kdelibs/plasma/applet.cpp http://reviewboard.kde.org/r/1606/#comment1669 this is actually unecessary; KRun does all of this for you, including re-using the mimetype fetching job. - Aaron On 2009-09-14 15:04:43, Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1606/ --- (Updated 2009-09-14 15:04:43) Review request for Plasma. Summary --- first implementation of an idea discussed @tokamak: add api to assign the execution of something to an applet. the rationale is to launch an app that is the full version of that applet, where the applet serves as little preview. it is possible to assign a kservice (usually used with kservice::servicefromdesktopfile(app name)) and an optional argument. if the service is missing and the argument url is present the url will be opened based on its mimetype. an applethandle icon and a context menu entry will be added to launch that external tool now there are roe rough edges: -api: pass kservice and url or just strings to make bindings easier? -urls: right now there is only one parameter: maybe having support for a list? -naming: now all the names are talking about an external tool, the applet handle uses the maximize icon, calling it maximize everywhere? i would leave external tool in the api and call maximize the action and the action text, that is what is presented to the user.. Diffs - /trunk/KDE/kdelibs/plasma/applet.h 1023331 /trunk/KDE/kdelibs/plasma/applet.cpp 1023331 /trunk/KDE/kdelibs/plasma/containment.cpp 1023331 /trunk/KDE/kdelibs/plasma/private/applet_p.h 1023331 /trunk/KDE/kdelibs/plasma/private/applethandle.cpp 1023331 /trunk/KDE/kdelibs/plasma/private/applethandle_p.h 1023331 Diff: http://reviewboard.kde.org/r/1606/diff Testing --- Thanks, Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
