> On Oct. 9, 2016, 5:46 p.m., Andreas Hartmetz wrote: > > Why not add logic to the runner to disable it automatically in the > > appropriate conditions? It doesn't have to be as simplistic as "there is no > > Baloo database at all". The other Andreas sort of suggested that and > > dismissed it right away but I think it's a good idea. > > For example, it could be tri-state: Disabled by default if Baloo file > > search is disabled, enabled if file search is enabled, or explicitly > > enabled / disabled. While it's ugly, it also covers the case that somebody > > uses only E-mail indexing. E-mail indexing is super useful IME, and > > somebody might want to use it from krunner. I just use it from KMail, > > though... > > One could also add an option to the Baloo KCM to clear the file index, > > which would automatically disable the runner (not sure if this is doable > > with a small amount of work / code). > > I don't think it is a good idea to effectively make distributions choose > > Baloo support or not in krunner. If they still really want to, they can > > probably use the cascading feature of KConfig and supply a global config > > file that disables the Baloo runner by default.
Oh, it totally makes sense to interact with the KCM setting, it's just outside the scope of this RR. To a user it is not at all obvious that they need to disable it in two places. They will just start to type in krunner or K menu with a big chance of a segfault. The KCM itself should additionally stop the indexing when being disabled. The default would always be _with_ Baloo, but giving choice to disable build for certain systems is just a nice thing to do. To kind of enforce that default, one could also add a default-on option to cmake so that it continued to fail to configure with missing Baloo instead of silently build without it. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128956/#review99882 ----------------------------------------------------------- On Sept. 20, 2016, 12:06 p.m., Andreas Sturmlechner wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128956/ > ----------------------------------------------------------- > > (Updated Sept. 20, 2016, 12:06 p.m.) > > > Review request for Plasma. > > > Repository: plasma-workspace > > > Description > ------- > > https://mail.kde.org/pipermail/kde-frameworks-devel/2016-September/037734.html > > Regardless of the current state of Baloo, it is not very deeply tied into > Plasma. Usage in plasma-workspace comes down to providing the baloo runner. > > > Diffs > ----- > > CMakeLists.txt 9da918358bd797b8fe00de646b6576ba22976d0e > runners/CMakeLists.txt 48cc3799f834a57031ae387a35f41859178fe317 > > Diff: https://git.reviewboard.kde.org/r/128956/diff/ > > > Testing > ------- > > Several days of Plasma-5 without any issues. Usage of krunner without any > segfaults. > > > Thanks, > > Andreas Sturmlechner > >
