Re: plasma workspace integration for akonadi
On Saturday 08 February 2014, Heena Mahour wrote: Re implementation of lion mail is required in any case . It is currently using data engine which is not the required tool as it should use models throughout and all is based on QGraphicsView . just for completeless, dataengines don't have anything to do with qgraphicsview. also, in plasma2 dataengines can export normal qabstractitemmodels. the difference with model imports is that are shared between multiple applets, that with a potentially ubiquitous (and big footprint) as akonadi, can make the difference -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115605: Rename plasmapkg
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115605/#review49429 --- I'd rather have it names plasmapkg2, the 5 prefix sounds weird in the Plasma context. (Most of the other visible Plasma bits carry version 2.0). - Sebastian Kügler On Feb. 9, 2014, 7:45 p.m., Hrvoje Senjan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115605/ --- (Updated Feb. 9, 2014, 7:45 p.m.) Review request for KDE Frameworks, Plasma and Sebastian Kügler. Repository: plasma-framework Description --- ...so it can be co-installed in the same prefix as kde-runtime(4) Diffs - src/plasmapkg/CMakeLists.txt a9e186f Diff: https://git.reviewboard.kde.org/r/115605/diff/ Testing --- Builds Thanks, Hrvoje Senjan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115605: Rename plasmapkg
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115605/#review49433 --- Ship it! Ship It! - Sebastian Kügler On Feb. 10, 2014, 11:45 a.m., Hrvoje Senjan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115605/ --- (Updated Feb. 10, 2014, 11:45 a.m.) Review request for KDE Frameworks, Plasma and Sebastian Kügler. Repository: plasma-framework Description --- ...so it can be co-installed in the same prefix as kde-runtime(4) Diffs - src/plasmapkg/CMakeLists.txt a9e186f Diff: https://git.reviewboard.kde.org/r/115605/diff/ Testing --- Builds Thanks, Hrvoje Senjan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115605: Rename plasmapkg
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115605/#review49435 --- This review has been submitted with commit cc34d2c17ef44f4aabb10986d27b5a4dc088baf2 by Hrvoje Senjan to branch master. - Commit Hook On Feb. 10, 2014, 11:45 a.m., Hrvoje Senjan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115605/ --- (Updated Feb. 10, 2014, 11:45 a.m.) Review request for KDE Frameworks, Plasma and Sebastian Kügler. Repository: plasma-framework Description --- ...so it can be co-installed in the same prefix as kde-runtime(4) Diffs - src/plasmapkg/CMakeLists.txt a9e186f Diff: https://git.reviewboard.kde.org/r/115605/diff/ Testing --- Builds Thanks, Hrvoje Senjan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115605: Rename plasmapkg
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115605/ --- (Updated Feb. 10, 2014, 11:53 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, Plasma and Sebastian Kügler. Repository: plasma-framework Description --- ...so it can be co-installed in the same prefix as kde-runtime(4) Diffs - src/plasmapkg/CMakeLists.txt a9e186f Diff: https://git.reviewboard.kde.org/r/115605/diff/ Testing --- Builds Thanks, Hrvoje Senjan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115605: Rename plasmapkg
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115605/#review49438 --- Ehh, the 2 doesn't make sense anymore since the plasma library is now following the kde frameworks version numbering. Right now it's version is 4.96.0 and is going to be 5.0 once all of frameworks is released in it's final state. For reference: http://quickgit.kde.org/?p=plasma-framework.gita=blobdiffh=f873539cd0814e3d512ae37278feb57738f5fdc9hp=8fb14bba0ca3983cb3503ea780c66b932816a1a1hb=f9e5cc949ff3719ec553955fba09f4efbc189c07f=CMakeLists.txt - Mark Gaiser On Feb. 10, 2014, 11:53 a.m., Hrvoje Senjan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115605/ --- (Updated Feb. 10, 2014, 11:53 a.m.) Review request for KDE Frameworks, Plasma and Sebastian Kügler. Repository: plasma-framework Description --- ...so it can be co-installed in the same prefix as kde-runtime(4) Diffs - src/plasmapkg/CMakeLists.txt a9e186f Diff: https://git.reviewboard.kde.org/r/115605/diff/ Testing --- Builds Thanks, Hrvoje Senjan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Minutes Monday Plasma hangout
Present: Alex Fiestas, David Edmundson, Jens Reuterberg, Marco Martin, Martin Gräßlin, Sebastian Kügler, Vishesh Handa 10th February, 2014, 12:00 CET sebas - plasmoids can now be dbus-activated (will blog) - positive feedback to highdpi - wants to merge themeswitch branch - did some sketching for a wallpaper dialog, will implement Vishesh - Baloo is merged in master, almost done for 4.x - Will start work on krunner w/ Aleix Martin - got KWindowSystem to build without X11 (means: two builds) - Can run Kate and Konsole on Wayland now (even with KDE integration plugin) (!) - is now looking into drkonqi - is dog-fooding now to get as many issues as possible shaken out - tries fixing oxygen windeco on WL - submitted new hint for undecorated windows to EWMH (to get rid of Motif) Marco - Merged branch with attached properties (see http://notmart.org/blog/2014/02/making-plasmoids-qml-api-better/ ) - systemtray needs some more work for having multiple systrays work - Fixes in tooltips - Improvements to popup-slide effect in progress Jens - Setting up group of designers - Talking to journalists - Get work out that already exist - Work on logos (Baloo, e.g.) - Planning porting icon themes David - Bugfixing all over the place - will fix more bugs listed for plasma-shell product - wants to move notes plasmoid into kde-workspace (into generic) - Fix tooltips atop panel popups Alex - PAM module for kwallet works in Plasma 1 now - Talks with Teo and Valentin about KSecretService in KF5 General Remarks: - it would be nice if we could somehow streamline the different things that install things and have backends (ghns, bodega, muon, packagekit, ...) - testing Baloo / Milou is important now - need to file bug in ghns about downloading data - need to add artwork freeze to schedule -- 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: plasma workspace integration for akonadi
On Monday, February 10, 2014 11:25:41 Marco Martin wrote: On Saturday 08 February 2014, Heena Mahour wrote: Re implementation of lion mail is required in any case . It is currently using data engine which is not the required tool as it should use models throughout and all is based on QGraphicsView . just for completeless, dataengines don't have anything to do with qgraphicsview. also, in plasma2 dataengines can export normal qabstractitemmodels. the difference with model imports is that are shared between multiple applets, that with a potentially ubiquitous (and big footprint) as akonadi, can make the difference Yes, with the new dataengines, this would be just fine. BUT ... we don't have those models in KF5, which means we'd need kdepimlibs ported, which ... well, rewind to the start of this thread. The UI needs a complete rewrite as well, which means that basically everything will have to be done from scratch, minus the UI and interaction concepts, which I think are pretty sound. -- 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: plasma workspace integration for akonadi
On Friday, February 07, 2014 19:25:55 Kevin Krammer wrote: On Friday, 2014-02-07, 18:26:20, Marco Martin wrote: On Friday 07 February 2014 16:28:20 Kevin Krammer wrote: The GSOC idea referenced below is not about data at all, it is about state. Akonadi state information and control works via D-Bus, so it would be possible to do a client for that without linking to libakonadi-kde. This was just brought up as an option, since Plasma/workspace development and KDEPIM libs development are currently not using the same Qt version and potentially will not during the GSOC period. my concern is: * is this worth, as opposed to waiting for kdepimlibs? I mostly brought this up as an options, it might or might not be worthwhile. Using D-Bus directly might allow to only transfer information that is needed, on the other hand making a QML adaptor for things like Akonadi::AgentInstanceModel will be faster and easier to code. Obviously also a difference in dependencies if that matters. * is accessing those dbus functions something that kdepimlibs doesn't provide? No. But kdepimlibs obviously involves more C++ classes. * *if* a Qt5 kdepimlibs was available, would this way be preferrable anyways? My understanding is that there is a frameworks branch in kdepimlibs which at some point was fully build-able. No idea what the current status is. That's my status as well. I hope the upcoming PIM sprint will shed some light on this. I'm pretty sure though that we're looking at at least another two workspace releases until PIM has been ported to KF5. (Note, that still doesn't mean that Akonadi has to have been ported, if I understand the architecture well, it should be entirely possible to have Akonadi(Qt4) used by kdepimlibs/5 (and even KMail4) at the same time. (Please correct me if I'm wrong.) That leads me to a migration path which involves kdepimlibs as the first step, so we can actually get at the data in akonadi. Which also means that a custom pim-status-lib will be replaced very quickly, making it quite a waste to implement it at high-enough quality. Otherwise, basic status information is something that should be done using Statusnotifier items. I've repeated that specific GSOC idea for a couple of years now, either there were no takers or they didn't convince us that they could successfully do it. I didn't re-add the idea again, mostly because of the lack of interest but also because of the bad timing for this year (focus on different Qt versions). Since it is a old idea it might also have to be reevaluated, e.g. whether it fits into the current or future concepts of our workspace offerings, etc. The only reason this was listed as KDEPIM idea was that Plasma was consistently filling all the GSOC slots it could get while KDE PIM usually had some to spare. This is almost 100% user interface and user interaction work. Hoping that the stuff in kdepimlibs is now up to the job (searchfolders working well enough, for example), yes. -- 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: Review Request 115605: Rename plasmapkg
On Feb. 10, 2014, 12:03 p.m., Mark Gaiser wrote: Ehh, the 2 doesn't make sense anymore since the plasma library is now following the kde frameworks version numbering. Right now it's version is 4.96.0 and is going to be 5.0 once all of frameworks is released in it's final state. For reference: http://quickgit.kde.org/?p=plasma-framework.gita=blobdiffh=f873539cd0814e3d512ae37278feb57738f5fdc9hp=8fb14bba0ca3983cb3503ea780c66b932816a1a1hb=f9e5cc949ff3719ec553955fba09f4efbc189c07f=CMakeLists.txt That's invisible. What is visible in version numbering are numbers of imports, versions of binaries, etc. Those are all aligned to 2. - Sebastian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115605/#review49438 --- On Feb. 10, 2014, 11:53 a.m., Hrvoje Senjan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115605/ --- (Updated Feb. 10, 2014, 11:53 a.m.) Review request for KDE Frameworks, Plasma and Sebastian Kügler. Repository: plasma-framework Description --- ...so it can be co-installed in the same prefix as kde-runtime(4) Diffs - src/plasmapkg/CMakeLists.txt a9e186f Diff: https://git.reviewboard.kde.org/r/115605/diff/ Testing --- Builds Thanks, Hrvoje Senjan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 115623: Add a property to tooltip to enable/disable tooltips
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115623/ --- Review request for Plasma. Repository: plasma-framework Description --- Add a property to tooltip to enable/disable tooltips This is useful to be able to disable tooltips when a dialog exists. We don't use the QQuickItem::enabled property as this propagates onto children which would have adverse side effects. See https://git.reviewboard.kde.org/r/115626/ Diffs - src/declarativeimports/core/tooltip.h a51c287 src/declarativeimports/core/tooltip.cpp afcbdef Diff: https://git.reviewboard.kde.org/r/115623/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma workspace integration for akonadi
apart from re-implementation of lion mail , what about the other tasks I mentioned , these are fine? these will also require akonadi client library of kdepimlibs . On Mon, Feb 10, 2014 at 6:17 PM, Sebastian Kügler se...@kde.org wrote: On Friday, February 07, 2014 19:25:55 Kevin Krammer wrote: On Friday, 2014-02-07, 18:26:20, Marco Martin wrote: On Friday 07 February 2014 16:28:20 Kevin Krammer wrote: The GSOC idea referenced below is not about data at all, it is about state. Akonadi state information and control works via D-Bus, so it would be possible to do a client for that without linking to libakonadi-kde. This was just brought up as an option, since Plasma/workspace development and KDEPIM libs development are currently not using the same Qt version and potentially will not during the GSOC period. my concern is: * is this worth, as opposed to waiting for kdepimlibs? I mostly brought this up as an options, it might or might not be worthwhile. Using D-Bus directly might allow to only transfer information that is needed, on the other hand making a QML adaptor for things like Akonadi::AgentInstanceModel will be faster and easier to code. Obviously also a difference in dependencies if that matters. * is accessing those dbus functions something that kdepimlibs doesn't provide? No. But kdepimlibs obviously involves more C++ classes. * *if* a Qt5 kdepimlibs was available, would this way be preferrable anyways? My understanding is that there is a frameworks branch in kdepimlibs which at some point was fully build-able. No idea what the current status is. That's my status as well. I hope the upcoming PIM sprint will shed some light on this. I'm pretty sure though that we're looking at at least another two workspace releases until PIM has been ported to KF5. (Note, that still doesn't mean that Akonadi has to have been ported, if I understand the architecture well, it should be entirely possible to have Akonadi(Qt4) used by kdepimlibs/5 (and even KMail4) at the same time. (Please correct me if I'm wrong.) That leads me to a migration path which involves kdepimlibs as the first step, so we can actually get at the data in akonadi. Which also means that a custom pim-status-lib will be replaced very quickly, making it quite a waste to implement it at high-enough quality. Otherwise, basic status information is something that should be done using Statusnotifier items. I've repeated that specific GSOC idea for a couple of years now, either there were no takers or they didn't convince us that they could successfully do it. I didn't re-add the idea again, mostly because of the lack of interest but also because of the bad timing for this year (focus on different Qt versions). Since it is a old idea it might also have to be reevaluated, e.g. whether it fits into the current or future concepts of our workspace offerings, etc. The only reason this was listed as KDEPIM idea was that Plasma was consistently filling all the GSOC slots it could get while KDE PIM usually had some to spare. This is almost 100% user interface and user interaction work. Hoping that the stuff in kdepimlibs is now up to the job (searchfolders working well enough, for example), yes. -- 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 -- -Heena Season of kde'12 participant Google Summer of Code 2013 Delhi College of Engineering(COE),India http://about.me/heena.mahour http://heenamahour.blogspot.in ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kf5 alpha 1 : modules, versions
On Saturday 08 February 2014, David Faure wrote: * OK if I run astyle-kdelibs in both, to harmonize coding style? (drawback: it makes forward-porting changes from 4.x harder) +1 if you can do it. + Can you add both to http://community.kde.org/Frameworks/List? This includes figuring out who to write down as maintainer :) + plasma-framework/README.md should be completed with a description + according to http://community.kde.org/Frameworks/Policies, the autotests and tests in plasma-framework should move to the toplevel. + In kactivities, the actual autotests like ./tests/core should move to an autotests subdir. the above points should be done.. only thing, in kactivities frameworks should still be merged in master (Ivan, would this be ok?) + kactivites needs a README.md, a kactivities.yaml and a .reviewboardrc Both frameworks need to be ported to ecm_generate_headers and ecm_generate_pri_file. Do you want to look at that too? sure.. but what I need to do for that exactly? ;) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kf5 alpha 1 : modules, versions
the above points should be done.. only thing, in kactivities frameworks should still be merged in master (Ivan, would this be ok?) Fine by me :) (even more than 'fine') ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kf5 alpha 1 : modules, versions
On Monday 10 February 2014, Ivan Čukić wrote: the above points should be done.. only thing, in kactivities frameworks should still be merged in master (Ivan, would this be ok?) Fine by me :) (even more than 'fine') ok. i suppose kdesrc-build has to be updated beforehand tough to pick up the correct ones? (how?) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
You need things done? We fix! You see!
With that eloquent start I wanted to say that some of you may now we now have our project page up and running (thanks to the webteam, Alex Fiestas and the Sysadmins) vdesign.kde.org We also have one open group at the KDE forums http://forum.kde.org/viewforum.php?f=285 where anyone of you can jump in and ask for design help on any subject. Anything at all. But in talking with some of the Plasma Devs one point became clear - some things that we work on is not... well its not news ready and in those situation perhaps getting help from the wider community may not be the best thing. But don't worry there are 13 designers all sworn to secrecy who also have their secret club house in the KDE forums where we talk about the projects we work on in house You can either contact me here via the list, the artist list or the promo list (depending on what you need help with) or safer and quicker - tell me via mail at jens at ohyran dot se. As for open design issues, no matter how trivial tell me here and I'll repost them in the forums - or post them yourself! The more information and work we have the more people see stuff is going on and more will join in! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
New framework: KRunner
Hi, During the last sprint, it was decided to split KRunner out of the plasma framework, since it seems like we want to use it but then there are a couple of alternatives. To that end, I created a new repository (kde:krunner) that contains the relevant code and I'll remove it from plasma and add a dependency on krunner from kde-workspace. I'll do it by tomorrow, so it doesn't come up as a surprise. For the moment, I marked it as a tier3, arguably it should be tier4 since there's the possibility of ending up deprecating it, but we're still not there. Cheers! Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 115641: Ensure to not call X11 specific calls if we are not on platform X11
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115641/ --- Review request for Plasma. Repository: plasma-framework Description --- Ensure to not call X11 specific calls if we are not on platform X11 This fixes a bunch of possible crashy code when trying to run applications linking plasma-framework on platform Wayland. Diffs - src/declarativeimports/core/dialogshadows.cpp 5a0ee82576e61430a1e7a330a5ad973ef75067c9 src/plasma/private/effectwatcher.cpp 495fa5986817fe325a3aea349980fb9e627a6fa7 src/plasma/private/effectwatcher_p.h 386a839bc3c31ae53a2bae5c382ec00f0dad3ef6 src/shell/panelshadows.cpp d2fa85bb8644d0d610e69c26c0fad7828868d277 Diff: https://git.reviewboard.kde.org/r/115641/diff/ Testing --- kwin-compositing-kcm no longer crashes when started on Wayland Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
