Review Request 119813: Show activity-linked files in folder view option
Eike Hein
hein at kde.org
Mon Aug 18 18:21:39 UTC 2014
> 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?
>
> Marco Martin wrote:
> 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
>
> Eike Hein wrote:
> I guess C++ would be OK for me; Folder already has a "SystemSettings" class in the plugin for things like double click vs. single click and double click interval that I could add a prop to. So this may be a way forward.
>
> Ivan Čukić wrote:
> It would be nice if this was accessible directly from qml - so that all applets can access it in the same way.
>
> Marco Martin wrote:
> "It would be nice if this was accessible directly from qml - so that all applets can access it in the same way."
> there may be several apis for that.
> maybe having just initializations of the settings?
> like: there is a file in the package, "plasmoiddefaults", is a config file:
> [org.kde.plasma.folder]
> showActivitiesOption=false
> [whateverotherplasmoid]
> ...
>
> the initial plasmoid.configuration object will be initialized with the value there instead of the actual default in its xml...
>
> how does that sound?
>
> Eike Hein wrote:
> ^ Hmm, doesn't that defeat the purpose of centralizing the option by explicitly enumerating plasmoids again? What if there's a new plasmoid, or a third-party one? You end up having to reissue the LNF.
>
> Marco Martin wrote:
> that was the idea of defaulting options for plasmoids in particular.
>
> in alternative, if one wants default options valid for everybody hmm,
> what about a singlethon qml object LookAndFeelHints with some properties as hints for plasmoids (not blindly everything in defaults, but only a small subset that makes sense plasmoids know about)
^ That seems better to me. I mean it still means having a known list somewhere (the hints) but the process for extending/maintaining that list seems reasonable (-> community discourse). I imagine if we had something like Python's PEP process, that's what we'd use to propose and deploy hints in there.
- Eike
-----------------------------------------------------------
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/4dfcc780/attachment.html>
More information about the Plasma-devel
mailing list