Review Request 119813: Show activity-linked files in folder view option

[Marco Martin]

> On Aug. 17, 2014, 2:36 p.m., Eike Hein wrote:
> > Looks good, but: I'm aware of at least one downstream that would like to hide activities support from plasmashell for complexity reasons. Is there a way to disable activities support, and does it have an API we could use to conditionally hide the option in Folder?
> 
> Ivan Čukić wrote:
>     There is no way to disable activities. At least, not a supported way.
>     
>     I *do* sometimes test a few things without the activity manager running, but it was decided at one point (a long time ago) that we will not be supporting that setup in any manner.
>     
>     The only component that is always guaranteed to work without activities is kwin, because it needs to work with other environments beside Plasma.
>     
>     From my point of view, if a distribution wants something like that, they need to be prepared to maintain their own patches which I don't think is very manageable in the long-run.
>     
>     
>     * interestingly enough, there still is a hidden checkbox in the activities kcm for disabling the system, but it was voted out as soon as I created it. It has absolutely no effect now.
> 
> Eike Hein wrote:
>     > From my point of view, if a distribution wants something like that, they need to be prepared to maintain their own patches which I don't think is very manageable in the long-run.
>     
>     I agree, having them fork the code downstream all over the place is pretty ugly. So the only recourse is to leave this patch out for now then.
> 
> Ivan Čukić wrote:
>     The problem with leaving the patch out is that it is a regression compared to 4.1x (pre-baloo).
>     
>     And if we do it like this, no new feature (at least, activity-related) will ever get in.
> 
> Eike Hein wrote:
>     I actually feel really, really uncomfortable taking a firm stance here, because I can see both sides.
>     
>     - Making Activities optional can inhibit its uptake, preventing the implementation of functionality that relies on them being there, and so possibly functionality that justifies their existence. This is slightly similar to the old "Nepomuk on by default" debate.
>     
>     - OTOH Plasma does claim to care about being a framework for downstreams to customize or implement new interfaces, and requiring forking+patching isn't supporting that cleanly. That some downstreams may want to offer interfaces that don't use Activities is legitimate. There's also value in the "if downstreams are going to do it anyway, we might as well maintain it upstream" stance that's popular through much FOSS. We've also intentionally modularized and decoupled a lot of things before as good engineering practice.
>     
>     The only compromise I can come up with is not to make the "Disable activities" knob visible in the UI, but make it a ISV-level config option somewhere, or even a build-time option. A precedent: Some downstreams don't like the Desktop Toolbox. In Plasma 5 we provide a clean way to hide it, you can just put the .desktop file for the package in your distro profile overlay and add Hidden=true. Something like this for Activities might be a good idea - perhaps as simple as not autostarting the daemon and having the UI adapt to it.
>     
>     Of course we could also put an ISV-level option into Folder, i.e. have a UseActivities config key distros can set to false via desktop scripting and hide the option. But this has the downside of reimplementing it in every widget instead of having something central.
> 
> Marco Martin wrote:
>     note that not using activities is different to not having the daemon running or having the linking database active.
>     not offering an activity switcher is one thing not having the daemon running will break things, no ways around it.
>     If is really needed to not have it, the config ui can check if the daemon is not running not show the option, that may be a solution.
>     "expect bug" is a constant tough
> 
> Marco Martin wrote:
>     Another option is to put an option in defaults of the shell package (or look&feel?) on wether those options should be visible or not
> 
> Eike Hein wrote:
>     Marco: Hmm, that sounds cool. How would that look like from a code POV, i.e. how exactly would Folder adapt to the LNF option?

would have to be accessed by the c++ part..
that may mean also that i'll finally be forced to make the lookandfeelaccess class finally available in a library somewhere (what that class does is exposing a filePath() method to take files from the l&f package performing a fallback to the default one when the configured l&f package doesn't provide a certain file).
As first thing there may be just an hidden option.. could also be cool having a set of default configs for applets (as soon as created) either in the shell or l&f package, I'm not too sure how i would do that tough


- Marco


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119813/#review64674
-----------------------------------------------------------


On Aug. 17, 2014, 2:32 p.m., Ivan Čukić wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119813/
> -----------------------------------------------------------
> 
> (Updated Aug. 17, 2014, 2:32 p.m.)
> 
> 
> Review request for Plasma, Eike Hein, Marco Martin, and Sebastian Kügler.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> -------
> 
> This is port of the feature that the folder view had before baloo replaced nepomuk - the configuration option to show the files that are linked to the current activity (activities:/current/).
> 
> It requires the latest master of kactivities which ship with the new kio implementation.
> 
> 
> Diffs
> -----
> 
>   containments/folder/package/contents/ui/ConfigLocation.qml dc97e81 
> 
> Diff: https://git.reviewboard.kde.org/r/119813/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Ivan Čukić
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140818/3cb3976f/attachment-0001.html>