Re: Notifications plasmoid, leak?
On Sunday 06 June 2010, Alex Fiestas wrote: Hi fellows Seems that the notifications plasmoid is leaking X11 memory for each notification How to reproduce: 1-Execute system activity (Ctrl+Esc), and show the X11 memory column 2-Remove your notifications plasmoid inside plasma. 3-Execute plasmoidviewer notifications 4-Execute kdialog --passivepopup foo to add a notification. when adding notifications take a look at the X11 Memory column, you'll see how it increases 400K per each notification but only decrease 100 when the notification is closed. I thought it would be because the notification is saved in the Notifications browser but: 1-Click on the plasmoid so the notification browser is shown 2-Close one notification when looking at the X11 Memory You should see how the X11 memory INCREASE each time you close a notification. Additionally when you close the entire browser, the memory is not released. trunk? when is updted? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notifications plasmoid, leak?
I can reproduce it in trunk updated and compiled a couple of hours ago. Also, the issue is not reproducible in trunk compiled the 24th of may, so the cause should be a commit in this period of time. Hope this helps. Dave. On Sunday 06 June 2010 12:30:34 Marco Martin wrote: On Sunday 06 June 2010, Alex Fiestas wrote: Hi fellows Seems that the notifications plasmoid is leaking X11 memory for each notification How to reproduce: 1-Execute system activity (Ctrl+Esc), and show the X11 memory column 2-Remove your notifications plasmoid inside plasma. 3-Execute plasmoidviewer notifications 4-Execute kdialog --passivepopup foo to add a notification. when adding notifications take a look at the X11 Memory column, you'll see how it increases 400K per each notification but only decrease 100 when the notification is closed. I thought it would be because the notification is saved in the Notifications browser but: 1-Click on the plasmoid so the notification browser is shown 2-Close one notification when looking at the X11 Memory You should see how the X11 memory INCREASE each time you close a notification. Additionally when you close the entire browser, the memory is not released. trunk? when is updted? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: use portable KDiskFreeSpaceInfo for free space calculation
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4241/ --- Review request for Plasma and Christopher Blauvelt. Summary --- Currently, the soliddevice data engine use either statvfs() or statfs() for determine the free space on a mount point. This, other than requiring per-OS code which does not cover all the OS KDE supports (for example Windows), is already wrapped in a nice API in kio, the class KDiskFreeSpaceInfo. The proposed patch applies this class to the soliddevice data engine, although making it depend on kio. Diffs - /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/soliddevice/CMakeLists.txt 1135061 /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/soliddevice/soliddeviceengine.cpp 1135061 Diff: http://reviewboard.kde.org/r/4241/diff Testing --- Looks reporting the correct value for mounted mount points, when queried via plasmaengineexplorer. Thanks, Pino ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: use portable KDiskFreeSpaceInfo for free space calculation
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4241/ --- (Updated 2010-06-06 13:15:14.345121) Review request for Plasma and Christopher Blauvelt. Summary --- Currently, the soliddevice data engine use either statvfs() or statfs() for determine the free space on a mount point. This, other than requiring per-OS code which does not cover all the OS KDE supports (for example Windows), is already wrapped in a nice API in kio, the class KDiskFreeSpaceInfo. The proposed patch applies this class to the soliddevice data engine, although making it depend on kio. Diffs - /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/soliddevice/CMakeLists.txt 1135061 /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/soliddevice/soliddeviceengine.cpp 1135061 Diff: http://reviewboard.kde.org/r/4241/diff Testing --- Looks reporting the correct value for mounted mount points, when queried via plasmaengineexplorer. Thanks, Pino ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: use portable KDiskFreeSpaceInfo for free space calculation
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4241/#review6000 --- Ship it! Can't imagine anything saner than this. Of course last word to Christopher. - Alessandro On 2010-06-06 13:15:14, Pino Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4241/ --- (Updated 2010-06-06 13:15:14) Review request for Plasma and Christopher Blauvelt. Summary --- Currently, the soliddevice data engine use either statvfs() or statfs() for determine the free space on a mount point. This, other than requiring per-OS code which does not cover all the OS KDE supports (for example Windows), is already wrapped in a nice API in kio, the class KDiskFreeSpaceInfo. The proposed patch applies this class to the soliddevice data engine, although making it depend on kio. Diffs - /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/soliddevice/CMakeLists.txt 1135061 /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/soliddevice/soliddeviceengine.cpp 1135061 Diff: http://reviewboard.kde.org/r/4241/diff Testing --- Looks reporting the correct value for mounted mount points, when queried via plasmaengineexplorer. Thanks, Pino ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Plasma Media Center] some advice request
Am Freitag 04 Juni 2010, 23:47:07 schrieb Aaron J. Seigo: another approach might be to make it a kwin plugin, and have the video window rendered beneath the PMC window using a compositing plugin. this plugin would need to know what the video window is and what the PMC window is (can be done using XAtoms specific to the plugin) and then render the video window under the PMC window and not using the normal rendering. one of the KWin people might be able to help guide us here in how best to make that happen, and the plugin could probably ship with PMC itself. this would tie PMC to kwin, but it would also mean that it would work just great non-fullscreen and without any window management hacks in PMC itself. I think that this could work, but I want to point out two things: 1. Texture from pixmap is quite heavy with some drivers. CPU usage for kwin increases to approx. 20 % when watching a video on my system. I often turn compositing off when watching fullscreen movies and don't need effects. Depending on the hardware PMC is targeting this could become a problem. On the other hand it's likely that we need compositing as we might want to have nice alpha-blended overlay controls in own windows, etc. etc. Also we have to tweak kwin so that the effect enforces that the fullscreen video window is not unredirected. Something I wanted to add for a long time... 2. The effect should live in kwin source directory because the KWin Effects API does not provide a stable ABI. If the PMC effects live in another source tree and PMC is released together with PMC I don't see a problem - except that the effect is not magically updated by kwin devs. If it's released seperately we have to find a solution. Maybe that would be an excuse to start to think about providing a stable ABI ;-) (Although I already have ideas how to break ABI as soon as 4.6 development starts) 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: use portable KDiskFreeSpaceInfo for free space calculation
Seems fine to me. I think the reason we used unix specific libraries originally was we did not plan on supporting plasma on other OSs. Clearly that's no longer the case so this makes sense. On Sun, Jun 6, 2010 at 2:08 PM, Alessandro Diaferia alediafe...@gmail.comwrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4241/#review6000 --- Ship it! Can't imagine anything saner than this. Of course last word to Christopher. - Alessandro On 2010-06-06 13:15:14, Pino Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4241/ --- (Updated 2010-06-06 13:15:14) Review request for Plasma and Christopher Blauvelt. Summary --- Currently, the soliddevice data engine use either statvfs() or statfs() for determine the free space on a mount point. This, other than requiring per-OS code which does not cover all the OS KDE supports (for example Windows), is already wrapped in a nice API in kio, the class KDiskFreeSpaceInfo. The proposed patch applies this class to the soliddevice data engine, although making it depend on kio. Diffs - /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/soliddevice/CMakeLists.txt 1135061 /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/soliddevice/soliddeviceengine.cpp 1135061 Diff: http://reviewboard.kde.org/r/4241/diff Testing --- Looks reporting the correct value for mounted mount points, when queried via plasmaengineexplorer. Thanks, Pino ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
