> 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?
^ 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. - 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ć > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
