Build failed in Jenkins: plasma-workspace_master_qt5 #990
See http://build.kde.org/job/plasma-workspace_master_qt5/990/changes Changes: [montel] Fix includes [montel] Remove kdelibs4support [montel] Remove not necessary include moc [montel] Remove not necessary include moc [montel] Remove deprecated function [montel] Fix includes [montel] Port to new connect api -- [...truncated 2720 lines...] Linking CXX shared module plasma_engine_packagekit.so [ 69%] Built target plasma_engine_packagekit [ 69%] Building CXX object dataengines/mpris2/CMakeFiles/plasma_engine_mpris2.dir/playercontrol.cpp.o [ 70%] Generating krunner_interface.cpp, krunner_interface.h Scanning dependencies of target plasma_engine_places [ 70%] Building CXX object dataengines/places/CMakeFiles/plasma_engine_places.dir/placesengine.cpp.o [ 70%] Generating krunner_interface.moc [ 70%] Building CXX object dataengines/places/CMakeFiles/plasma_engine_places.dir/placeservice.cpp.o Scanning dependencies of target plasma_engine_powermanagement [ 70%] Building CXX object dataengines/powermanagement/CMakeFiles/plasma_engine_powermanagement.dir/powermanagementengine.cpp.o [ 70%] Building CXX object dataengines/powermanagement/CMakeFiles/plasma_engine_powermanagement.dir/powermanagementjob.cpp.o [ 70%] Building CXX object dataengines/powermanagement/CMakeFiles/plasma_engine_powermanagement.dir/powermanagementservice.cpp.o [ 70%] Building CXX object dataengines/powermanagement/CMakeFiles/plasma_engine_powermanagement.dir/krunner_interface.cpp.o [ 70%] Building CXX object dataengines/powermanagement/CMakeFiles/plasma_engine_powermanagement.dir/plasma_engine_powermanagement_automoc.cpp.o Linking CXX shared module plasma_engine_notifications.so [ 70%] Built target plasma_engine_notifications [ 70%] Building CXX object dataengines/mpris2/CMakeFiles/plasma_engine_mpris2.dir/playeractionjob.cpp.o [ 70%] Building CXX object dataengines/mpris2/CMakeFiles/plasma_engine_mpris2.dir/playercontainer.cpp.o http://build.kde.org/job/plasma-workspace_master_qt5/ws/dataengines/powermanagement/powermanagementengine.cpp: In member function ‘virtual bool PowermanagementEngine::sourceRequestEvent(const QString)’: http://build.kde.org/job/plasma-workspace_master_qt5/ws/dataengines/powermanagement/powermanagementengine.cpp:174:41: warning: ‘Solid::PowerManagement::Notifier* Solid::PowerManagement::notifier()’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/solid/powermanagement.h:154) [-Wdeprecated-declarations] connect(Solid::PowerManagement::notifier(), SIGNAL(appShouldConserveResourcesChanged(bool)), ^ http://build.kde.org/job/plasma-workspace_master_qt5/ws/dataengines/powermanagement/powermanagementengine.cpp:174:50: warning: ‘Solid::PowerManagement::Notifier* Solid::PowerManagement::notifier()’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/solid/powermanagement.h:154) [-Wdeprecated-declarations] connect(Solid::PowerManagement::notifier(), SIGNAL(appShouldConserveResourcesChanged(bool)), ^ http://build.kde.org/job/plasma-workspace_master_qt5/ws/dataengines/powermanagement/powermanagementengine.cpp:176:51: warning: ‘bool Solid::PowerManagement::appShouldConserveResources()’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/solid/powermanagement.h:66) [-Wdeprecated-declarations] updateAcPlugState(Solid::PowerManagement::appShouldConserveResources()); ^ http://build.kde.org/job/plasma-workspace_master_qt5/ws/dataengines/powermanagement/powermanagementengine.cpp:176:78: warning: ‘bool Solid::PowerManagement::appShouldConserveResources()’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/solid/powermanagement.h:66) [-Wdeprecated-declarations] updateAcPlugState(Solid::PowerManagement::appShouldConserveResources()); ^ http://build.kde.org/job/plasma-workspace_master_qt5/ws/dataengines/powermanagement/powermanagementengine.cpp:178:94: warning: ‘QSetSolid::PowerManagement::SleepState Solid::PowerManagement::supportedSleepStates()’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/solid/powermanagement.h:74) [-Wdeprecated-declarations] const QSetSolid::PowerManagement::SleepState sleepstates = Solid::PowerManagement::supportedSleepStates(); ^
Do we have some SoK projects
Hello people! This year KDE is hosting Season of KDE. So I am wondering if we have some tasks in Plasma 5 area that can be considered as Season of KDE 2014 project? I joined Plasma/KDE through SoK 2013 and that I consider as a great opportunity for new comers. So my question is do we have some projects/ideas/tasks for SoK 2014? Also do we have some smaller tasks for Google code in 2014? That is also coming up.. Thanks! -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Do we have some SoK projects
Well you're going to be a Mentor, what would you feel best mentoring? I would look at https://todo.kde.org/?controller=boardaction=showproject_id=1 and https://todo.kde.org/?controller=boardaction=showproject_id=11 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Do we have some SoK projects
On Tuesday 21 October 2014 13:56:09 Bhushan Shah wrote: Hello people! This year KDE is hosting Season of KDE. So I am wondering if we have some tasks in Plasma 5 area that can be considered as Season of KDE 2014 project? I joined Plasma/KDE through SoK 2013 and that I consider as a great opportunity for new comers. So my question is do we have some projects/ideas/tasks for SoK 2014? Also do we have some smaller tasks for Google code in 2014? That is also coming up.. I added two ideas for a SOK project for KWin. I'm also interested in adding some CodeIn tasks but that depends on whether someone takes a SoK project. I won't be able to mentor on both ;-) Cheers Martin 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
5.2 Kickoff Meeting tomorrow (Tuesday) 13:00UTC
We'll have a Plasma 5.2 Kickoff meeting tomorrow (Wednesday) at 13:00UTC (15:00CEST) in #plasma IRC on freenode. We can have a supplementary meeting at 18:00 for those who can't make it at that time. Users of other application menus welcome too. Please review the 5.1 kanboard and ponder what you want moved to 5.2 https://todo.kde.org/?controller=boardaction=showproject_id=1 I've set up a kanboard for 5.2 https://todo.kde.org/?controller=boardaction=showproject_id=44 Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120624: add gtkbreeze, kconf_update tool to set gtk settings on first login
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120624/ --- (Updated Oct. 21, 2014, 9:06 a.m.) Review request for Plasma and Hugo Pereira Da Costa. Changes --- get rid of QCoreApplication Repository: breeze Description --- add gtkbreeze, kconf_update tool to set gtk settings on first login this checks if gtk settings are already set, if they are not or are set to oxygen they update them, else it quits it does this for both gtk 2 and 3 it sets gtk to the orion theme because it's available for both gtk 2 and 3 and it looks similar to breeze it sets the icons to oxygen because I could not get breeze icons to work with gtk 2 or 3 I also could not get icons to show on buttons or in menus in gtk 3 Diffs (updated) - misc/gtkbreeze/main.cpp PRE-CREATION misc/CMakeLists.txt ff891a9 misc/gtkbreeze/CMakeLists.txt PRE-CREATION misc/gtkbreeze/gtkbreeze.upd PRE-CREATION Diff: https://git.reviewboard.kde.org/r/120624/diff/ Testing --- run it and run gtk-demo and gtk3-demo Thanks, Jonathan Riddell ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The usage statistics [kactivities, baloo, ktp, plasma]
On Monday 20 October 2014 17:24:02 Vishesh Handa wrote:
On Mon, Oct 13, 2014 at 6:59 PM, Ivan Čukić ivan.cu...@kde.org wrote:
3. What will be needed
Integration with baloo. It will require patches on both sides if we are
to
support all the use-cases without cross-queries. We will need accessible
file
types via sqlite (on baloo side) and baloo identifiers or something on
kamd
side.
* The Baloo identifiers will only work for indexed files. Given that we're
not enforcing users to index everything (nor should we). We need a
different approach.
What could be an alternative approach is - since we already support
applications to set the mimetype in the api (used for SLC) we could save
that
as well. We could detect the mimetype for the files automatically, but not
for
other linkable things. I guess that this would also cover most of the use-
cases from the original mail that talked about the 'additional payload'.
One thing to ask here is if baloo skips indexing a file that is in an
indexable folder - does it store any info about the file (name, date etc.)
or
not?
Still, baloo is not off the hook - if we want to detect the file moving and
deletion (as suggested by the guy behind baloo :P), at least for the
indexed
files, we need baloo to somehow tell us what was moved/deleted.
This could be implemented in a few different ways that would all have some
drawbacks:
1 - baloo sending signals - big drawback would be that if the clients miss
out
an event, the database would become inconsistent;
2 - saving baloo ids along files in kamd - drawback is that baloo becomes
tied
to sqlite (as you mentioned);
3 - baloo saving information about what has moved/deleted so that a client
can
ask for all events that happened since some timestamp - drawbacks here are
that the clients need to regularly check for the updates meaning they will
most likely have at least a bit out of date information
4 - combination of 1 and 3 - it would be the most complex implementation,
but
it would work properly (distributed dbs are evil )
And, an additional problem is what to do about the files that are not
indexed
by baloo? Should it silently fail or what? For the statistics, it would be
(imo) ok to fail silently, but for activity linking, it might be nice to
show
a warning message to the user.
sum [
exp (-di) * exp ( ki * log li ) | i - [1..n]
]
I don't understand all of the math, but this sounds quite ideal. Currently
in KRunner we have a global run count which affects the score of all the
result, and that score doesn't degrade over time. This seems like
something
nice to replace it with, if we can make it super fast that is.
The scores are cached, so there is no problem with the speed - it is just a
query over a table. Something like
select resource, date, score * exp(now - date) as currentScore ...
which would be in the library, so the client would not need to think about
the
difference between the cached score and the current score (cached score was
current at the point of calculation, but needs to be degraded on query
because
the time has passed since the initial calculation).
If you are interested, I can go a bit more into math details - I think I
even
have it written somewhere.
Ch!
On 20 October 2014 17:24, Vishesh Handa m...@vhanda.in wrote:
On Mon, Oct 13, 2014 at 6:59 PM, Ivan Čukić ivan.cu...@kde.org wrote:
3. What will be needed
Integration with baloo. It will require patches on both sides if we are to
support all the use-cases without cross-queries. We will need accessible
file
types via sqlite (on baloo side) and baloo identifiers or something on
kamd
side.
* The Baloo identifiers will only work for indexed files. Given that we're
not enforcing users to index everything (nor should we). We need a
different approach.
* This would also require Baloo to stick with sqlite.
Appendix 1: Formula for the resource scoring:
===
LaTeX formatted:
S = \sum _{i = 1} ^ n
e^{-d_i} e^{k_i \log(l_i)}
Haskell-like formatted, whichever you find easier to read :)
sum [
exp (-di) * exp ( ki * log li ) | i - [1..n]
]
where d_i is the time that passed since the i-th event, k_i coefficient
depending on the type of the event, l_i length of the event (time distance
between open and close for example, or focus in and out)
It can be rewritten to look prettier (exp log = id and so on), but this
conveys the meaning in a nicer way by separating the terms according to
their
meaning.
The main ideas behind the formula are:
- score degrades with the time, so if a document was kept open in okular
for
an hour yesterday, it will have a significantly higher score than a
document
that was kept open for a whole day a year ago;
- different events have different meanings;
- event time interval is measured on a logarithmic scale, so that there
is a
greater
Re: Review Request 120624: add gtkbreeze, kconf_update tool to set gtk settings on first login
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120624/ --- (Updated Oct. 21, 2014, 10 a.m.) Review request for Plasma and Hugo Pereira Da Costa. Changes --- add gtk3 css file to remove window shadows to tidy up client side decorations Repository: breeze Description --- add gtkbreeze, kconf_update tool to set gtk settings on first login this checks if gtk settings are already set, if they are not or are set to oxygen they update them, else it quits it does this for both gtk 2 and 3 it sets gtk to the orion theme because it's available for both gtk 2 and 3 and it looks similar to breeze it sets the icons to oxygen because I could not get breeze icons to work with gtk 2 or 3 I also could not get icons to show on buttons or in menus in gtk 3 Diffs (updated) - misc/CMakeLists.txt ff891a9 misc/gtkbreeze/CMakeLists.txt PRE-CREATION misc/gtkbreeze/gtkbreeze.upd PRE-CREATION misc/gtkbreeze/main.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/120624/diff/ Testing --- run it and run gtk-demo and gtk3-demo Thanks, Jonathan Riddell ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120624: add gtkbreeze, kconf_update tool to set gtk settings on first login
On Oct. 19, 2014, 3:47 p.m., David Edmundson wrote: misc/gtkbreeze/main.cpp, line 96 https://git.reviewboard.kde.org/r/120624/diff/1/?file=320198#file320198line96 mid-long term we probably want to split this out into a file that we copy Otherwise this isn't really going to scale especially wrt GTK Config and changing themes later. I don't think it would make much difference to include it as a file, it wouldn't make it any easier to update later if we want to change the theme - Jonathan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120624/#review68708 --- On Oct. 21, 2014, 10 a.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120624/ --- (Updated Oct. 21, 2014, 10 a.m.) Review request for Plasma and Hugo Pereira Da Costa. Repository: breeze Description --- add gtkbreeze, kconf_update tool to set gtk settings on first login this checks if gtk settings are already set, if they are not or are set to oxygen they update them, else it quits it does this for both gtk 2 and 3 it sets gtk to the orion theme because it's available for both gtk 2 and 3 and it looks similar to breeze it sets the icons to oxygen because I could not get breeze icons to work with gtk 2 or 3 I also could not get icons to show on buttons or in menus in gtk 3 Diffs - misc/CMakeLists.txt ff891a9 misc/gtkbreeze/CMakeLists.txt PRE-CREATION misc/gtkbreeze/gtkbreeze.upd PRE-CREATION misc/gtkbreeze/main.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/120624/diff/ Testing --- run it and run gtk-demo and gtk3-demo Thanks, Jonathan Riddell ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Jenkins build is back to normal : plasma-workspace_master_qt5 #991
See http://build.kde.org/job/plasma-workspace_master_qt5/991/changes ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 5.2 Kickoff Meeting tomorrow (Tuesday) 13:00UTC
On Tuesday 21 October 2014, Jonathan Riddell wrote: We'll have a Plasma 5.2 Kickoff meeting tomorrow (Wednesday) at 13:00UTC (15:00CEST) in #plasma IRC on freenode. We can have a supplementary meeting at 18:00 for those who can't make it at that time. wednesday 13:00 utc is exactly the only time i really can't, sorry. if there will be another one at 18:00 would be awesome -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [plasma-devel] 5.2 Kickoff Meeting tomorrow (Wednesday) 13:00UTC
Original subject was wrong, it's on wednesday ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 5.2 Kickoff Meeting tomorrow (Tuesday) 13:00UTC
On Tuesday 21 October 2014, Marco Martin wrote: On Tuesday 21 October 2014, Jonathan Riddell wrote: We'll have a Plasma 5.2 Kickoff meeting tomorrow (Wednesday) at 13:00UTC (15:00CEST) in #plasma IRC on freenode. We can have a supplementary meeting at 18:00 for those who can't make it at that time. wednesday 13:00 utc is exactly the only time i really can't, sorry. if there will be another one at 18:00 would be awesome correction, i maybe can make it a least in part, but i'll probably just be a bit late -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 5.2 Kickoff Meeting tomorrow (Tuesday) 13:00UTC
On Tue, Oct 21, 2014 at 09:49:16AM +0100, Jonathan Riddell wrote: We can have a supplementary meeting at 18:00 for those who can't make it at that time. That's 18:00 CEST, 16:00UTC Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The usage statistics [kactivities, baloo, ktp, plasma]
On Tue, Oct 21, 2014 at 11:22 AM, Ivan Čukić ivan.cu...@kde.org wrote: One thing to ask here is if baloo skips indexing a file that is in an indexable folder - does it store any info about the file (name, date etc.) or not? No. It does store any info. Still, baloo is not off the hook - if we want to detect the file moving and deletion (as suggested by the guy behind baloo :P), at least for the indexed files, we need baloo to somehow tell us what was moved/deleted. This could be implemented in a few different ways that would all have some drawbacks: 1 - baloo sending signals - big drawback would be that if the clients miss out an event, the database would become inconsistent; 2 - saving baloo ids along files in kamd - drawback is that baloo becomes tied to sqlite (as you mentioned); 3 - baloo saving information about what has moved/deleted so that a client can ask for all events that happened since some timestamp - drawbacks here are that the clients need to regularly check for the updates meaning they will most likely have at least a bit out of date information The NTFS file system has something similar. It's called a USN Journal. It's their solution to applications being able to see what changed when they weren't running or if they missed some events. I'm not too keen on Baloo doing stuff like this, but we can make something new which does stuff like this, and (possibly) make Baloo use it. I looked into the BTRFS file system about a month ago, and we could hypothetically use its snapshot feature to know what has changed since a particular time interval. Currently btfs-send, sending both the data and the metadata, but that can be improved. I'm not saying that we make btrfs a dependency for Plasma, I'm just throwing ideas out there which was can use IF the user is on btrfs. 4 - combination of 1 and 3 - it would be the most complex implementation, but it would work properly (distributed dbs are evil ) And, an additional problem is what to do about the files that are not indexed by baloo? Should it silently fail or what? For the statistics, it would be (imo) ok to fail silently, but for activity linking, it might be nice to show a warning message to the user. Be careful here. * Silently failing is not always a good idea * Making file Indexing mandatory for statistics also seems a little bit risky. -- Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The usage statistics [kactivities, baloo, ktp, plasma]
On Monday 20 October 2014, Vishesh Handa wrote: On Mon, Oct 13, 2014 at 6:59 PM, Ivan Čukić ivan.cu...@kde.org wrote: 3. What will be needed Integration with baloo. It will require patches on both sides if we are to support all the use-cases without cross-queries. We will need accessible file types via sqlite (on baloo side) and baloo identifiers or something on kamd side. * The Baloo identifiers will only work for indexed files. Given that we're not enforcing users to index everything (nor should we). We need a different approach. could baloo implement some function to track a specific single file, giving it an id etc even if is not in an indexed folder? (i can imagine it not scaling well tough) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The usage statistics [kactivities, baloo, ktp, plasma]
Hey guys On Mon, Oct 13, 2014 at 6:59 PM, Ivan Čukić ivan.cu...@kde.org wrote: Hi all, As promised, starting a discussion on how we can use the usage statistics gathered by kactivitymanagerd (kamd in the rest of the text). And the design of the API to cover the use-cases. The point is to discuss all of this and put the summaries on the etherpad page at https://notes.kde.org/p/KActivities_Usage_Statistics I looked into the suggested use cases yesterday. I'm not sure where we would use some of the listed use-cases. Could someone help with the overall picture? Below is the list from notes.kde.org along with my comments. Recently used applications across the entire system. Potential Use case: I can only see this being used in KRunner when searching for applications. However, KRunner already has an inbuilt mechanism for that. Most frequently used (high usage score) applications across the entire system. Potential use case: Automatic favorite detection for Applications. Recently installed applications. Potential Use Case: Displaying it in Muon? But then the package manager has this information so would kactivities wrap around this? Recently used documents across the entire system. We already have KRecentDocuments which stores .desktop files in ~/.local/share/RecentDocuments. It's integrated in our file dialog as well. Though I do actually doubt the usefulness of this list. How do want to improve this? Most frequently used (high usage score) documents across the entire system. I'm not too sure where this would be used. Recently used documents by $application. Definitely useful. Each application currently stores this in their config file. What were you planning on adding? Most used (high usage score) documents by $application. I'm not too sure if anyone but the $application would use this list. Perhaps it's application's decision if they want such a feature and they can probably implement it quite easily. For example - I'm not too sure about a videos applications wanting the most recently viewed videos. Metadata for the recently/most used documents, so they can e.g. be grouped by type. * I'm not too sure what you mean. We already have a recently used documents list, and this can be grouped based on type * Where would this be used? Application Launching Interface (ALI) search history. * You mean like the krunner search history that was there in KDE4? Grouping things together by analysing the statistics (more advanced - API does not need to cover it). Recently used contacts Frequently used contacts Our contact list and person list can definitely use something like this. -- Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The usage statistics [kactivities, baloo, ktp, plasma]
On Tue, Oct 21, 2014 at 6:13 PM, Marco Martin notm...@gmail.com wrote: * The Baloo identifiers will only work for indexed files. Given that we're not enforcing users to index everything (nor should we). We need a different approach. could baloo implement some function to track a specific single file, giving it an id etc even if is not in an indexed folder? (i can imagine it not scaling well tough) I'm not too keen on doing this as we then need to track everything, and we all know how much inotify sucks. If we really want this, we can possibly create a new service just to do this. We can potentially start thinking of solutions based on inode number + disk id, though that has drawbacks as well. -- Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120623: LocationRunner: Convert case insensitive path to a proper one
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120623/ --- (Updated Oct. 21, 2014, 4:20 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Bugs: 95 https://bugs.kde.org/show_bug.cgi?id=95 Repository: plasma-workspace Description --- See bug report Diffs - runners/locations/locationrunner.cpp 13035a9 Diff: https://git.reviewboard.kde.org/r/120623/diff/ Testing --- Bug fixed. Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The usage statistics [kactivities, baloo, ktp, plasma]
On Tuesday 21 October 2014, Vishesh Handa wrote: an id etc even if is not in an indexed folder? (i can imagine it not scaling well tough) I'm not too keen on doing this as we then need to track everything, and we all know how much inotify sucks. If we really want this, we can possibly create a new service just to do this. We can potentially start thinking of solutions based on inode number + disk id, though that has drawbacks as well. that would definitely be less draining.. there the problem would be that it would lose it as soon it gets moved across partitions right? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The usage statistics [kactivities, baloo, ktp, plasma]
across partitions right? And that we would not know the file's name anymore. Anyhow, I think that this is more a question for kde-devel, not plasma-devel. Maybe a wider audience for brainstorming on files could be useful. -- KDE, ivan.cu...@kde.org, http://ivan.fomentgroup.org/ gpg key id: 850B6F76 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The usage statistics [kactivities, baloo, ktp, plasma]
No. It does store any info. Does this mean that baloo does not search file names at all? The NTFS file system has something similar. It's called a USN Journal. It's their solution to applications being able to see what changed when they weren't running or if they missed some events. I'm not too keen on Baloo doing stuff like this, but we can make something new which does stuff like this, and (possibly) make Baloo use it. +1 This would mean essentially moving baloo's file change detection outside, and improve its powers a bit? I looked into the BTRFS file system about a month ago, and we could hypothetically use its snapshot feature to know what has changed since a particular time interval. Currently btfs-send, sending both the data and The problem with this is that the snapshots should be *very* frequent then. I'm not sure this is a good idea. Or potentially reporting non-changed files to the client when the snapshot was not recent enough for the requested timestamp. Be careful here. * Silently failing is not always a good idea When statistics are concerned, it is always ok to fail Joking, but we can not do any better than that. * Making file Indexing mandatory for statistics also seems a little bit Indexing would be mandatory (or the separated service) just for the moving/deletion detection - the rest would work as before. Cheers, Ivan -- KDE, ivan.cu...@kde.org, http://ivan.fomentgroup.org/ gpg key id: 850B6F76 On 21 October 2014 17:18, Vishesh Handa m...@vhanda.in wrote: On Tue, Oct 21, 2014 at 11:22 AM, Ivan Čukić ivan.cu...@kde.org wrote: One thing to ask here is if baloo skips indexing a file that is in an indexable folder - does it store any info about the file (name, date etc.) or not? No. It does store any info. Still, baloo is not off the hook - if we want to detect the file moving and deletion (as suggested by the guy behind baloo :P), at least for the indexed files, we need baloo to somehow tell us what was moved/deleted. This could be implemented in a few different ways that would all have some drawbacks: 1 - baloo sending signals - big drawback would be that if the clients miss out an event, the database would become inconsistent; 2 - saving baloo ids along files in kamd - drawback is that baloo becomes tied to sqlite (as you mentioned); 3 - baloo saving information about what has moved/deleted so that a client can ask for all events that happened since some timestamp - drawbacks here are that the clients need to regularly check for the updates meaning they will most likely have at least a bit out of date information The NTFS file system has something similar. It's called a USN Journal. It's their solution to applications being able to see what changed when they weren't running or if they missed some events. I'm not too keen on Baloo doing stuff like this, but we can make something new which does stuff like this, and (possibly) make Baloo use it. I looked into the BTRFS file system about a month ago, and we could hypothetically use its snapshot feature to know what has changed since a particular time interval. Currently btfs-send, sending both the data and the metadata, but that can be improved. I'm not saying that we make btrfs a dependency for Plasma, I'm just throwing ideas out there which was can use IF the user is on btrfs. 4 - combination of 1 and 3 - it would be the most complex implementation, but it would work properly (distributed dbs are evil ) And, an additional problem is what to do about the files that are not indexed by baloo? Should it silently fail or what? For the statistics, it would be (imo) ok to fail silently, but for activity linking, it might be nice to show a warning message to the user. Be careful here. * Silently failing is not always a good idea * Making file Indexing mandatory for statistics also seems a little bit risky. -- Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- KDE, ivan.cu...@kde.org, http://ivan.fomentgroup.org/ gpg key id: 850B6F76 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119589: Allow KHelpCenter from Plasma 5 to work with KDE4 applications.
On Aug. 3, 2014, 10:05 a.m., Luigi Toscano wrote: Hello, I am trying to fix this exact issue in Kubuntu. I applied this patch and khelpcenter does indeed start now. However, documentation is not found for most apps. I think installing kdelibs4 to get kbuildsyscoca4 defeats the purpose of going to frameworks. IS there a better solution here? I am willing to fix the apps to have docs compatible to kf5 if someone points me in a direction. Thanks Scarlett - Scarlett --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119589/#review63706 --- On Aug. 3, 2014, 9:59 a.m., Matthew Dawson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119589/ --- (Updated Aug. 3, 2014, 9:59 a.m.) Review request for Documentation and Plasma. Repository: khelpcenter Description --- KHelpCenter 5.0.0 works with handbooks from KDE4 applications, but by default they cannot launch it. Fix that so KDE4 applications don't lose their help when someone upgrades to Plasma 5. Diffs - CMakeLists.txt 728b2583c052fd09e85ef66aa3e99d092948837d Diff: https://git.reviewboard.kde.org/r/119589/diff/ Testing --- Tested installing a manual patch against my system install. Hitting F1 in dolphin launches KHelpCenter as expected, with the dolphin help displayed (after running kbuildsyscoca4). Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The usage statistics [kactivities, baloo, ktp, plasma]
Recently used applications across the entire system. Potential Use case: I can only see this being used in KRunner when searching for applications. And Kickoff etc. (not only when searching apps) Recently installed applications. Potential Use Case: Displaying it in Muon? This one was requested by Eike. Recently used documents across the entire system. We already have KRecentDocuments which stores .desktop files in ~/.local/share/RecentDocuments. It's integrated in our file dialog as well. Though I do actually doubt the usefulness of this list. How do want to improve this? Again, Kickoff (and others) like to show a list of recent documents. One of the reasons I started working on usage tracking and scoring is because of the 'usefulness' of KRecentDocuments. I always found it irrelevant because it usually shows at most one useful item. If it took into the account the scores, it would become much more useful than it is now (IMO). Most frequently used (high usage score) documents across the entire system. I'm not too sure where this would be used. See above. Recently used documents by $application. Definitely useful. Each application currently stores this in their config file. What were you planning on adding? Most used (high usage score) documents by $application. I'm not too sure if anyone but the $application would use this list. Perhaps it's application's decision if they want such a feature and they can probably implement it quite easily. For example - I'm not too sure about a videos applications wanting the most recently viewed videos. The point is to have a generic thing that supports different variations on the same tune. That is, a few different things need to know what was opened and when, and then you get a lot of side things that could benefit from it as well. In this case, yes, every application does implement its recent documents mechanism and could implement the high scored ones etc. But, in that case,the workspace would have no idea about any of those - the tasks applet (or the launchers) would not be able to show the documents for applications etc. (p.s. One of the things I forgot to write before - the same mechanism could be used as a base for replacing the xsession protocol which I guess will go away along with the X11) Metadata for the recently/most used documents, so they can e.g. be grouped by type. * I'm not too sure what you mean. We already have a recently used documents list, and this can be grouped based on type * Where would this be used? This one was also requested by Eike. From my POV, one use-case would be applications that open different things like KDevelop having sessions and files. So a mimetype could be used to filter out what exactly they want to show etc. Application Launching Interface (ALI) search history. * You mean like the krunner search history that was there in KDE4? For example. -- KDE, ivan.cu...@kde.org, http://ivan.fomentgroup.org/ gpg key id: 850B6F76 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The usage statistics [kactivities, baloo, ktp, plasma]
On Tue, Oct 21, 2014 at 6:27 PM, Marco Martin notm...@gmail.com wrote: that would definitely be less draining.. there the problem would be that it would lose it as soon it gets moved across partitions right? Yup. And reverse lookups are very very hard. You you can only do (url - id) not the other way around. Unless we maintain our own mapping. But maybe I'm wrong. -- Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The usage statistics [kactivities, baloo, ktp, plasma]
On Tue, Oct 21, 2014 at 7:00 PM, Ivan Čukić ivan.cu...@gmail.com wrote: Recently used applications across the entire system. Potential Use case: I can only see this being used in KRunner when searching for applications. And Kickoff etc. (not only when searching apps) So Kickoff would be showing both the most frequently used and the automatic favorite applications? Recently used documents across the entire system. We already have KRecentDocuments which stores .desktop files in ~/.local/share/RecentDocuments. It's integrated in our file dialog as well. Though I do actually doubt the usefulness of this list. How do want to improve this? Again, Kickoff (and others) like to show a list of recent documents. Who else? One of the reasons I started working on usage tracking and scoring is because of the 'usefulness' of KRecentDocuments. I always found it irrelevant because it usually shows at most one useful item. If it took into the account the scores, it would become much more useful than it is now (IMO). Could you perhaps talk about possible workflows and how this would be displayed to the user? I'm still quite skeptical about how useful a global recently used files list actually is. I've always found the list of recent documents quite irrelevant as well. Most frequently used (high usage score) documents across the entire system. I'm not too sure where this would be used. See above. I would like workflow and use cases for this as well. Recently used documents by $application. Definitely useful. Each application currently stores this in their config file. What were you planning on adding? Most used (high usage score) documents by $application. I'm not too sure if anyone but the $application would use this list. Perhaps it's application's decision if they want such a feature and they can probably implement it quite easily. For example - I'm not too sure about a videos applications wanting the most recently viewed videos. The point is to have a generic thing that supports different variations on the same tune. That is, a few different things need to know what was opened and when, and then you get a lot of side things that could benefit from it as well. Such as? In this case, yes, every application does implement its recent documents mechanism and could implement the high scored ones etc. But, in that case,the workspace would have no idea about any of those - the tasks applet (or the launchers) would not be able to show the documents for applications etc. Questions that are coming to my mind - * Do we need the shell/kactivities to know about this information? * Does this need to be stored in a global database or applications continue using their config files and we just make a standard format? * How would this information be displayed to the user? You mentioned the launcher. Can you give me an example? (p.s. One of the things I forgot to write before - the same mechanism could be used as a base for replacing the xsession protocol which I guess will go away along with the X11) Metadata for the recently/most used documents, so they can e.g. be grouped by type. * I'm not too sure what you mean. We already have a recently used documents list, and this can be grouped based on type * Where would this be used? This one was also requested by Eike. From my POV, one use-case would be applications that open different things like KDevelop having sessions and files. So a mimetype could be used to filter out what exactly they want to show etc. So basically a filter on top of the global list of recently used documents? Application Launching Interface (ALI) search history. * You mean like the krunner search history that was there in KDE4? For example. Would this need to be a part of kactivities or can we just add this in krunner? -- Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Powerdevil] [Bug 340206] New: do not use Version from org.freedesktop.systemd1.Manager in checkSystemdVersion
https://bugs.kde.org/show_bug.cgi?id=340206 Bug ID: 340206 Summary: do not use Version from org.freedesktop.systemd1.Manager in checkSystemdVersion Product: Powerdevil Version: unspecified Platform: Debian unstable OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: plasma-devel@kde.org Reporter: edwin+...@etorok.net According to the documentation [0] Version is not part of the API and it should not be parsed, one may not assume the version to be formatted in any particular way.. However checkSystemdVersion() in ./powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp uses Version. The problem is that systemd-shim doesn't implement version, and this results in the loss of the Sleep/Hibernate buttons from the KDE menu (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747180). Although it is rather simple to implement 'Version' in systemd-shim, I don't know if that should be done given that the documentation says it should not be used in the first place. [0] http://www.freedesktop.org/wiki/Software/systemd/dbus/ Reproducible: Always -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The usage statistics [kactivities, baloo, ktp, plasma]
On Tuesday 21 October 2014 19:00:02 Ivan Čukić wrote: In this case, yes, every application does implement its recent documents mechanism and could implement the high scored ones etc. But, in that case,the workspace would have no idea about any of those - the tasks applet (or the launchers) would not be able to show the documents for applications etc. (p.s. One of the things I forgot to write before - the same mechanism could be used as a base for replacing the xsession protocol which I guess will go away along with the X11) yeah, would be possible to restore at least a bit, at least what applications were open with what documents, not a perfect state but better than nothing -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The usage statistics [kactivities, baloo, ktp, plasma]
On Tuesday 21 October 2014 18:17:09 Vishesh Handa wrote: Most used (high usage score) documents by $application. I'm not too sure if anyone but the $application would use this list. taskbar -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The usage statistics [kactivities, baloo, ktp, plasma]
On Tuesday 21 October 2014 19:27:10 Vishesh Handa wrote: The point is to have a generic thing that supports different variations on the same tune. That is, a few different things need to know what was opened and when, and then you get a lot of side things that could benefit from it as well. Such as? just some random ideas riffing on this (i'm sure smarter ones would come up after actually thinking on it) * file search, often opened documents could go up in the results * context menus of taskbar entries, often used documents for each entry * category in launcher * a kio accessible from dolphin sidebar * some kind of timeline to review the history of what you did this past week -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119589: Allow KHelpCenter from Plasma 5 to work with KDE4 applications.
On Aug. 3, 2014, 7:05 p.m., Luigi Toscano wrote: Scarlett Clark wrote: Hello, I am trying to fix this exact issue in Kubuntu. I applied this patch and khelpcenter does indeed start now. However, documentation is not found for most apps. I think installing kdelibs4 to get kbuildsyscoca4 defeats the purpose of going to frameworks. IS there a better solution here? I am willing to fix the apps to have docs compatible to kf5 if someone points me in a direction. Thanks Scarlett Afaik you just need kdelibs4support installed for that. (as a side note: if you have a kdelibs4-based application installed, you also have kdelibs4, no?) - Luigi --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119589/#review63706 --- On Aug. 3, 2014, 6:59 p.m., Matthew Dawson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119589/ --- (Updated Aug. 3, 2014, 6:59 p.m.) Review request for Documentation and Plasma. Repository: khelpcenter Description --- KHelpCenter 5.0.0 works with handbooks from KDE4 applications, but by default they cannot launch it. Fix that so KDE4 applications don't lose their help when someone upgrades to Plasma 5. Diffs - CMakeLists.txt 728b2583c052fd09e85ef66aa3e99d092948837d Diff: https://git.reviewboard.kde.org/r/119589/diff/ Testing --- Tested installing a manual patch against my system install. Hitting F1 in dolphin launches KHelpCenter as expected, with the dolphin help displayed (after running kbuildsyscoca4). Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The usage statistics [kactivities, baloo, ktp, plasma]
On 10/21/2014 07:27 PM, Vishesh Handa wrote: Who else? Kicker. Ivan also has his Lancelot launcher in develop- ment as I understand it. Could you perhaps talk about possible workflows and how this would be displayed to the user? I'm still quite skeptical about how useful a global recently used files list actually is. I've always found the list of recent documents quite irrelevant as well. Based on the amount of suggestions regarding it (e.g. grouping by type and per-app entry points) and the speedy reporting of bugs in it, it seems Recent Documents is quite popular among Kicker users. So basically a filter on top of the global list of recently used documents? Yes - it was suggested a few times to subdivide Recent Documents into content type groups like text documents and videos to get to the goal more quickly. Note that the purpose of this thread is to initially collect all the things we want to do, then figure out how the APIs to support that might look like (which includes finding out the right abstraction level and what should rather be done on the consumer side) and then draw up some concrete work items we can distribute over available hands. In that sense it's fine to poke and prod the use cases e.g. to find the similarities and pare things down and avoid overdesign, but I'd prefer it if we could do that in a friendly hmm, I wonder if ... manner rather than the please toil to receive my blessing tone of voice you're using here. In addition to strangely selective thread reading (I named both Kicker and the Task Mana- ger in my initial reply, which you could have replied to to poke for details) and a lack of awareness of what's shipping in Plasma Desktop it made reading your last couple of posts in this thread really frustrating. Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 106911: ksmserver should ignore non-executable files under ~/.kde4/Autostart
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/106911/#review68845 --- Ping - Arjun AK On Oct. 16, 2012, 7:12 p.m., Jekyll Wu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/106911/ --- (Updated Oct. 16, 2012, 7:12 p.m.) Review request for Plasma and Luboš Luňák. Bugs: 286658 http://bugs.kde.org/show_bug.cgi?id=286658 Repository: kde-workspace Description --- It does not make sense to feed non-executable files to krun, since that folder is named as Autostart, which expects executable files. Those .desktop files might be exception to the above rule, but I don't know whether the current situation of supporting .desktop under ~/.kde4/Autostart is an intentional or incidental feature. Diffs - ksmserver/startup.cpp d99ce4c Diff: https://git.reviewboard.kde.org/r/106911/diff/ Testing --- Thanks, Jekyll Wu ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119589: Allow KHelpCenter from Plasma 5 to work with KDE4 applications.
On Aug. 3, 2014, 10:05 a.m., Luigi Toscano wrote: Scarlett Clark wrote: Hello, I am trying to fix this exact issue in Kubuntu. I applied this patch and khelpcenter does indeed start now. However, documentation is not found for most apps. I think installing kdelibs4 to get kbuildsyscoca4 defeats the purpose of going to frameworks. IS there a better solution here? I am willing to fix the apps to have docs compatible to kf5 if someone points me in a direction. Thanks Scarlett Luigi Toscano wrote: Afaik you just need kdelibs4support installed for that. (as a side note: if you have a kdelibs4-based application installed, you also have kdelibs4, no?) Ahh yes silly me, they (we) put docs in a seperate package. Sorry for the noise. On the initial problem though, is this something we should just patch until apps are ported? - Scarlett --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119589/#review63706 --- On Aug. 3, 2014, 9:59 a.m., Matthew Dawson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119589/ --- (Updated Aug. 3, 2014, 9:59 a.m.) Review request for Documentation and Plasma. Repository: khelpcenter Description --- KHelpCenter 5.0.0 works with handbooks from KDE4 applications, but by default they cannot launch it. Fix that so KDE4 applications don't lose their help when someone upgrades to Plasma 5. Diffs - CMakeLists.txt 728b2583c052fd09e85ef66aa3e99d092948837d Diff: https://git.reviewboard.kde.org/r/119589/diff/ Testing --- Tested installing a manual patch against my system install. Hitting F1 in dolphin launches KHelpCenter as expected, with the dolphin help displayed (after running kbuildsyscoca4). Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120624: add gtkbreeze, kconf_update tool to set gtk settings on first login
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120624/#review68848 --- Ship it! Looking mostly good to my eyes. misc/gtkbreeze/CMakeLists.txt https://git.reviewboard.kde.org/r/120624/#comment48150 off-hand, I don't see why we need QWidgets here. Can you check? misc/gtkbreeze/main.cpp https://git.reviewboard.kde.org/r/120624/#comment48149 QDir::separator() here as well misc/gtkbreeze/main.cpp https://git.reviewboard.kde.org/r/120624/#comment48148 if setGtk2 fails and setGtk3 succeeds, it will return success. It should probably return success only if both failed. - Sebastian Kügler On Oct. 21, 2014, 10 a.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120624/ --- (Updated Oct. 21, 2014, 10 a.m.) Review request for Plasma and Hugo Pereira Da Costa. Repository: breeze Description --- add gtkbreeze, kconf_update tool to set gtk settings on first login this checks if gtk settings are already set, if they are not or are set to oxygen they update them, else it quits it does this for both gtk 2 and 3 it sets gtk to the orion theme because it's available for both gtk 2 and 3 and it looks similar to breeze it sets the icons to oxygen because I could not get breeze icons to work with gtk 2 or 3 I also could not get icons to show on buttons or in menus in gtk 3 Diffs - misc/CMakeLists.txt ff891a9 misc/gtkbreeze/CMakeLists.txt PRE-CREATION misc/gtkbreeze/gtkbreeze.upd PRE-CREATION misc/gtkbreeze/main.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/120624/diff/ Testing --- run it and run gtk-demo and gtk3-demo Thanks, Jonathan Riddell ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119589: Allow KHelpCenter from Plasma 5 to work with KDE4 applications.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119589/#review68851 --- Ship it! Uhm, I think the patch can go in. It's not breaking existing stuff and there are no conflicts with existing files. - Luigi Toscano On Aug. 3, 2014, 6:59 p.m., Matthew Dawson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119589/ --- (Updated Aug. 3, 2014, 6:59 p.m.) Review request for Documentation and Plasma. Repository: khelpcenter Description --- KHelpCenter 5.0.0 works with handbooks from KDE4 applications, but by default they cannot launch it. Fix that so KDE4 applications don't lose their help when someone upgrades to Plasma 5. Diffs - CMakeLists.txt 728b2583c052fd09e85ef66aa3e99d092948837d Diff: https://git.reviewboard.kde.org/r/119589/diff/ Testing --- Tested installing a manual patch against my system install. Hitting F1 in dolphin launches KHelpCenter as expected, with the dolphin help displayed (after running kbuildsyscoca4). Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The usage statistics [kactivities, baloo, ktp, plasma]
On Tue, Oct 21, 2014 at 9:58 PM, Eike Hein h...@kde.org wrote: On 10/21/2014 07:27 PM, Vishesh Handa wrote: Who else? Kicker. Ivan also has his Lancelot launcher in develop- ment as I understand it. Could you perhaps talk about possible workflows and how this would be displayed to the user? I'm still quite skeptical about how useful a global recently used files list actually is. I've always found the list of recent documents quite irrelevant as well. Based on the amount of suggestions regarding it (e.g. grouping by type and per-app entry points) and the speedy reporting of bugs in it, it seems Recent Documents is quite popular among Kicker users. Alright. I was not planning on condemning it just because I don't use it. My main motive was that if we plan to improve it, we then map down workflows and decide the different ways we want the users to use it. Right now, it is fairly hidden. So basically a filter on top of the global list of recently used documents? Yes - it was suggested a few times to subdivide Recent Documents into content type groups like text documents and videos to get to the goal more quickly. Note that the purpose of this thread is to initially collect all the things we want to do, then figure out how the APIs to support that might look like (which includes finding out the right abstraction level and what should rather be done on the consumer side) and then draw up some concrete work items we can distribute over available hands. The purpose, I assumed, from Ivan's initial email was to see how we can use the usage statistics gathered by kactivitymanagerd. Not to - in general collect ideas about usage tracking. The notes page also clearly mentions activities. In that sense it's fine to poke and prod the use cases e.g. to find the similarities and pare things down and avoid overdesign, but I'd prefer it if we could do that in a friendly hmm, I wonder if ... manner rather than the please toil to receive my blessing tone of voice you're using here. In addition to strangely selective thread reading (I named both Kicker and the Task Mana- ger in my initial reply, which you could have replied to to poke for details) and a lack of awareness of what's shipping in Plasma Desktop it made reading your last couple of posts in this thread really frustrating. I apologize. It wasn't my intention for this thread to become hostile. In fact, I even had another person go over all my emails (before sending them) because I feared my questions might not be taken well. The reason I'm prodding so much is I'm scared of activities becoming this big central thing. I have a little bit of experience on working on a project where we worked on stuff without clearly defined use-cases and workflows in mind. We rather focused on stuff which we thought could be used in cool ways in the future. However, I should have re-read your initial response instead of selectively skimming over the thread and only focusing on the notes pages. I assumed it would be a decent summary. -- Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 119589: Allow KHelpCenter from Plasma 5 to work with KDE4 applications.
On Aug. 3, 2014, 10:05 a.m., Luigi Toscano wrote: Scarlett Clark wrote: Hello, I am trying to fix this exact issue in Kubuntu. I applied this patch and khelpcenter does indeed start now. However, documentation is not found for most apps. I think installing kdelibs4 to get kbuildsyscoca4 defeats the purpose of going to frameworks. IS there a better solution here? I am willing to fix the apps to have docs compatible to kf5 if someone points me in a direction. Thanks Scarlett Luigi Toscano wrote: Afaik you just need kdelibs4support installed for that. (as a side note: if you have a kdelibs4-based application installed, you also have kdelibs4, no?) Scarlett Clark wrote: Ahh yes silly me, they (we) put docs in a seperate package. Sorry for the noise. On the initial problem though, is this something we should just patch until apps are ported? nevermind installing the docs package did not help. I noticed the only docs found by khelpcenter is in /usr/share/doc/HTML/en but kde4 apps install docs into /usr/share/doc/kde/HTML/en this very well could be a Kubuntu thing. - Scarlett --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119589/#review63706 --- On Aug. 3, 2014, 9:59 a.m., Matthew Dawson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119589/ --- (Updated Aug. 3, 2014, 9:59 a.m.) Review request for Documentation and Plasma. Repository: khelpcenter Description --- KHelpCenter 5.0.0 works with handbooks from KDE4 applications, but by default they cannot launch it. Fix that so KDE4 applications don't lose their help when someone upgrades to Plasma 5. Diffs - CMakeLists.txt 728b2583c052fd09e85ef66aa3e99d092948837d Diff: https://git.reviewboard.kde.org/r/119589/diff/ Testing --- Tested installing a manual patch against my system install. Hitting F1 in dolphin launches KHelpCenter as expected, with the dolphin help displayed (after running kbuildsyscoca4). Thanks, Matthew Dawson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The usage statistics [kactivities, baloo, ktp, plasma]
On Tue, Oct 21, 2014 at 10:48 PM, Vishesh Handa m...@vhanda.in wrote: So basically a filter on top of the global list of recently used documents? Yes - it was suggested a few times to subdivide Recent Documents into content type groups like text documents and videos to get to the goal more quickly. Makes sense. I guess. @Ivan: Is this the reason you wanted the Baloo sqlite database to have file type information? I'm afraid you may have mentioned it before, but I cannot find any log of it. Because it seems like it can be easily without needing Baloo. It is after all just some mimetype grouping. -- Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The usage statistics [kactivities, baloo, ktp, plasma]
On Tue, Oct 21, 2014 at 6:42 PM, Ivan Čukić ivan.cu...@gmail.com wrote: No. It does store any info. Does this mean that baloo does not search file names at all? I'm confused about your question. You'd initially asked if baloo skips indexing a file that is in an indexable folder - does it store any info about the file (name, date etc.) or not. It does not store any information about that file if it skips indexing it. The only reason it would skip the file would be if the mimetype was blacklisted or there were certain exclude filters. What do you mean by Baloo does not search file names at all? The NTFS file system has something similar. It's called a USN Journal. It's their solution to applications being able to see what changed when they weren't running or if they missed some events. I'm not too keen on Baloo doing stuff like this, but we can make something new which does stuff like this, and (possibly) make Baloo use it. +1 This would mean essentially moving baloo's file change detection outside, and improve its powers a bit? Yes. Though lets really make sure we absolutely need this before taking such a drastic step. inotify really is horrible, and until we have an alternative, it might be prudent to wait. I looked into the BTRFS file system about a month ago, and we could hypothetically use its snapshot feature to know what has changed since a particular time interval. Currently btfs-send, sending both the data and The problem with this is that the snapshots should be *very* frequent then. The cool thing about btfs snapshots is that even if they are frequent the don't consume any space, and are automatically deleted if the user starts using more space. Anyway, we probably should not discussing btrfs stuff. -- Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The usage statistics [kactivities, baloo, ktp, plasma]
On 21.10.2014 22:55, Vishesh Handa wrote: I'm not sure how this would work - How would kamd know about when an application has been created? Would it be getting notified by the package manager or monitoring all of /usr/ itself? Maybe Ivan can chime in since he probably had an implementation in mind when he suggested it. Actually, let me expand on context: This feature has a real precedent IIRC; Plasma 4's Kickoff gained the ability to highlight newly-installed apps at some point, which was probably lost in the Plasma 5 port. I'm actually not even sure if it was ever upstream or a Kubuntu- specific patch, but I think I saw it there once when I installed a live CD in a VM. It was probably fashioned after the similar feature in Windows, and has been re- quested for inclusion in Kicker by at least one down- stream, Netrunner Linux. As I recall, this was implemented inside Kickoff itself. I *think* it maintained a timestamped lists of new apps when discovering them as it build up the menu structure on startup or so ... I'm guessing something similar would be an avenue to getting it back - KAMD could diff ksycoca scans, or react to ksycoca change signals, and slam newly-dis- covered apps as CREATED into its db ...? Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
