Re: Placement of config files for Plasma 5 and KF5-based applications
Am Mittwoch, 28. Januar 2015, 08:43:41 schrieb Martin Gräßlin: > On Tuesday 27 January 2015 01:01:27 Thomas Pfeiffer wrote: > > Hi everyone, > > first of all, I think it's a great step in the right direction that > > we're now putting our config files in ~/.config instead of ~/.kde(4), > > we're now finally "standard-compliant". > > > > However, where we still could - and imho should - do better is with > > where exactly we put them. If I look at my .config folder, I see > > mostly folders there, and then a lot of KDE files directly on the top > > level. If everyone would do that, .config would be a huge mess of > > files and it would be difficult to find the one you're looking for. > > We should not be the "bad boy" here. > > > > The question is: Where should we put the files? Putting them all in a > > .config/kde folder again would be possible and would clear up the > > top-level clutter, but I think we could go further. > > In fact, I don't see a reason why config files from otherwise > > completely unrelated applications that only have in common that they > > were made by KDE should all reside in the same folder, whereas other > > applications each have their own folder. > > > > What could make sense is having e.g. everything from Calligra in one > > folder, or everything from KDE Edu or KDE Games. > > And I'd put all Plasma stuff into one folder. Actually, there already > > is a plasma-workspace folder on my system, which contains an "env" > > and a "shutdown" folder. Why not put Plasma-related config files in > > there? > > > > I also have a "KDE" folder with Marble Virtual Globe.conf and > > Sonnet.conf in there, and a kde.org folder with libphonon.conf and > > marble.conf. This doesn't make us look very professional, as it shows > > that there is currently no guideline for where to put our config > > files. > > I think we should change that! > > > > So, for me there are three questions: > > 1. Should we come up with guidelines for config file placement? > > 2. Does my suggestion above make sense or if now how should it be done > > instead? > > 3. If we want guidelines, how do we make them known and maybe even > > "enforce" them via code checking or some such? > > There was a change to put config files into org.kde.foo, but that had to > be reverted as it broke for setups like KWin where the configuration is > not done in the same process. > > Given that at least for KWin I do not want to do any changes as > a) the risk of breakage is too high > b) it's too much work (all code needs to be hunted down for usage of > "kwinrc" (git grep shows 46 usages just in kwin, no idea how spread out > it is in other places to configure kwin) or KSharedConfig::openConfig > and similar) Wow. I thought there would be one define that the config file is there and there and it would be used in all places. > c) I simply don't care whether users have a "problem" with > ~/.config containing many files, it's a directory for applications, not > for the user I think having all KDE related configs together in one place has an advantage: One can recover the KDE configuration with a simple rsync command from backup, without affecting any non KDE stuff. I did so in the past. It has been quite a while since I last did it, as KDE / Plasma configuration does not seem to be easy to break, but I still think its a valuable feature to have all KDE related things in one place. "its not for the user" is no reasoning I agree with. Most config files are plain text, there are even special options that may only be available in the config file and in case of any breakage that cannot be fixed within the GUI its nice to be able to fix things on the config file level. But well, there has been discussion about config file format on kde-pim mailing list as well, and whether to store them as binary data or not. And granted KMail / Akonadi and others store things in there that seems to me to be application *state* not *user configuration* and it may make sense to separate those. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: Plasma Applet for Audio Volume for kdereview
Hi. Am Mittwoch, 5. August 2015, 12:45:01 schrieb Jonathan Riddell: > plasma-pa is a new volume manager and is intended to be a replacement for > KMix in Plasma. Will that make PulseAudio mandatory? It is still not working for me in all cases (stuttering sound with PlaneShift OpenAL sound output as one of the last issues) and am I happy that Plasma 5 and KMix still work without it. > We plan to ship it as a beta in Plasma 5.4 and it's currently in kdereview > for your reviewing attention. > > https://projects.kde.org/projects/kdereview/plasma-pa > > Please check over it and consider if it passes review. Thanks, -- Martin
Re: Plasma Applet for Audio Volume for kdereview
Am Donnerstag, 6. August 2015, 12:43:28 schrieb Martin Klapetek: > On Wed, Aug 5, 2015 at 4:24 PM, Martin Steigerwald > > wrote: > > Hi. > > > > Am Mittwoch, 5. August 2015, 12:45:01 schrieb Jonathan Riddell: > > > plasma-pa is a new volume manager and is intended to be a replacement > > > for KMix in Plasma. > > > > Will that make PulseAudio mandatory? > > > > It is still not working for me in all cases (stuttering sound with > > PlaneShift > > OpenAL sound output as one of the last issues) and am I happy that Plasma > > 5 > > and KMix still work without it. > > You can still use kmix with Plasma, there is even a port to kf5 though I'm > not sure what's its state. I referred to the "and [plasma-pa] is intended to be a replacement for KMix in Plasma" from Jonathan. If kmix will still be there, I do not care much. But for as long as PulseAudio does not work for my usecases, I just prefer if I can run Plasma still without it. Thanks, -- Martin
Re: State of Audio CD support in KDE
Am Freitag, 2. Oktober 2015, 04:46:08 CEST schrieb Boudhayan Gupta: > On 2 October 2015 at 01:19, Albert Astals Cid wrote: > > I'd miss the ripping habilities of kio-audiocd personally, maybe we can > > merge it with kaudiocreator and make them share code? > > Yeah, let's make KAudioCreator do the conversion. If people want an > easy/seamless solution, maybe we can add a context-menu to Dolphin? > > I've got ripping to WAV running in my branch of KCompactDisc, I'm just > chasing a double-free bug before I upload the code. It's barely 300 > lines of code; I have no clue why audiocd-kio's main cpp file is more > than 1000 lines, never mind the converters. I really love the audiocd:/ thing. Cause it was so easy to use while wit worked. Open Dolphin, insert CD, click CD, drag and drop the files you want and it does all the stuff. I really do think that this is really a nice interface and would prefer this over an external applicaiton any time. -- Martin
Re: [Kde-pim] Qt 4 Builds
On Sonntag, 27. März 2016 10:01:09 CEST Thiago Macieira wrote: > On domingo, 27 de março de 2016 15:31:47 PDT Martin Koller wrote: > > The latest openSuse (Leap 42.1) ships the Qt4 based kdepim, although it > > uses plasma5 desktop. > > > > Speaking of it: given that openSuse decided against shipping KF5-based > > PIM, > > how stable is KF5-based PIM considered these days ? > > Is it ready for productive daily professional use ? > > Tumbleweed has already switched to the KF5-based PIM and it's working mostly > fine. There are some minor issues like requiring the shortcut to go to the > next unread message in any folder to be pressed multiple times before it > decides to do its job, but nothing major. Shortcuts are still completely broken with self-compiled kdepim from git master. They have been broken for months already. I can´t use arrow right in threaded mail list to switch to a mail of the next thread for example. I think if not already done I will file a bug about it. I didn´t yet, cause I thought it was just a temporary development hic-up initially. -- Martin
Distro integration for Plasma Browser Integration (was: Re: Plasma Browser Integration is in kdereview
Hello David. Thanks for your effort on plasma browser integration. I am unsure whether to keep CC to kde-core-devel and plasma-devel, please drop as you deem appropriate. Keeping all text for reference for those that only read distributions mailing list. David Edmundson - 05.06.17, 15:42: > Hey all, > > We'd like to add project plasma-browser-integration into KDE[0]. > > The goal is to make chrome and firefox integrate better into a Plasma > desktop environment through browser extensions. > > How?: > Firefox and chrome (and potentially others) allow plugins to talk to a > native binary host [1]. This binary host is launched by the the browser and > has a socket to a conventional browser extension. This project consists of > both parts allowing a chrome extension to make normal DBus calls to > services just like other apps. > > Integrating what?: > This gives us the following features: > - Finding open tabs via krunner > - Download progress in the task bar > - Showing now playing information with shortcuts (if the website supports > it) > - "Send to KDE Connect" context menu on links > - Loading windows on the correct activity (WIP) > - An SNI if incognito windows are open with action to close them. > > And potentially more in the future. There is a config to enable/disable > parts as appropriate. > > Deployment: > This repo consists of two parts. The binary host which should be > distributed by normal distro means, and the browser extension which is > going to be different. > > The browser extension can be deployed in one of 3 ways. > - manually by the user from the code (useful for devs) > > - through the webstore [2][3] > - chrome also has a feature where we can ship a text file on the distro > side that will make the browser automatically fetch an extension from their > store. > > Ideally we want the extension available on the store from an official KDE > channel. > > - potentially it could also be done by the distro, but it seems like FF > might be removing that possibility and the digital signing is an issue. What options are possible to distribute extensions via distro packaging? I ask cause I think at least for chrome / chromium you need a Google account to use the plugin / extension store. Also it would put the extension outside of distro security support. Therefore I mostly use xul-ext packages in Debian as extensions for Firefox and also a new uBlock origin extension package for chromium. Eventually this would need to be brought up with browser developers. I am willing to help there by creating wishlist item / bug report. > [0] https://cgit.kde.org/plasma-browser-integration.git/ > [1] https://developer.chrome.com/extensions/nativeMessaging > [2] > https://chrome.google.com/webstore/detail/plasma-integration/cimiefiiaegbelh > efglklhhakcgmhkai [3] > https://addons.mozilla.org/en-US/android/addon/plasma-integration/?src=cb-dl > -updated > > Regards > > David and Kai Thanks, -- Martin
Re: Moving Baloo forward
Am Dienstag, 21. Januar 2014, 02:10:21 schrieb Vishesh Handa: > On Saturday 18 January 2014 12:53:38 Jonathan Marten wrote: > > Vishesh Handa writes: > > > http://community.kde.org/Baloo > > > > Thanks for producing that useful page, and of course for all your past > > and current work on Nepomuk and Baloo. There is one statement there > > that makes me a little concerned: > > > > "This metadata is now stored with the extended attributes of the file > > instead of storing it in a separate database." > > > > Am I right in assuming that this means xattr? If so, would there be > > implications for cases where those extended attributes may not get > > preserved or are not supported: > > > > - simple copy/move of a file using cp/mv (with the default options) > > - copy/move of a file using KIO > > - network file systems (NFS or SMB) > > - backup/restore > > - FAT filesystems > > - platforms other then Linux > > > > Hoping that none of those will make normal use impossible, but if > > there would be problems or workarounds needed with any of these then > > they ought to be addressed early. […] > The idea is that in systems which do not support xattr a secondary database > will be used to store the information. So, it will be very similar to the > situation we had with Nepomuk. > > I still have to implement this. As a user feedback: I like the idea of using xattrs a lot. And also your effort with Baloo. I was a bit surprised by it as of now finally the Nepomuk stuff basically works on my system. I think that secondary database as backup if xattrs are not available is important. E.g. I wonder whether xattrs are available with - NFS mounted homes (especially when those are backed by non-linux NFS implementations like from NetApp) or through - ecryptfs and other stacked filesystem approaches. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Re: Moving Baloo forward
Am Dienstag, 28. Januar 2014, 08:03:54 schrieb Rolf Eike Beer: > Am Freitag, 24. Januar 2014, 15:59:12 schrieb Vadim Zhukov: > > 2014/1/24 Sebastian Kügler : > > > On Friday, January 24, 2014 01:24:54 Vadim Zhukov wrote: > > >> in the best case you'll have two totally different codepaths > > >> that you'll have to manage. > > > > > > This should be "worst case", I think. In the best case, there's xattr > > > support, meaning another code path isn't needed. > > > > It's doubtful at least whether xattr support is a good thing, because > > it's too easily gets misused: for example, there were viruses on > > Windows which effectively hidden themselves in NTFS streams. And there > > are personal data leaking issues I've pointed out earlier. But the > > question "xarttrs: to be or not to be everywhere" is totally offtopic, > > because it's what OS developers should decide. > > I am against storing metadata in xattrs, but more for personal opinion than > for anything I can express in technical terms. What could be done and which > uses xattrs for what I seem them for is to just store a unique identifier in > the xattrs (e.g. a GUID) which makes it easier to map the file to its > metadata in the database, maybe together with some sort of checksum to > detect modifications. That way no accidential information leak will happen > if that thing is copied elsewhere. Storing metadata in xattrs makes a really nice feature possible: To move a file to another machine and have the metadata be copied and re- indexed on that new machine as well. The copy process just needs to take care of transfering the xattr. This can even work when using a USB stick or so as interim medium. A database ID would not be sufficient for that. Actually I very much like that as a feature. With current Nepomuk I expect to loose any key words and other metadata when I transfer some files to another machine. Of course, if its just my user data I can also transfer my complete home directory when migrating to a new box. But any exchange of data between users will use any and all metadata that is not directly stored in the file unless they are transferred somehow like via xattr. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: Moving Baloo forward
Am Dienstag, 28. Januar 2014, 22:06:45 schrieb Rolf Eike Beer: > Am Dienstag, 28. Januar 2014, 20:10:13 schrieb Ivan Čukić: > > > To move a file to another machine and have the metadata be copied and > > > re- > > > indexed on that new machine as well. The copy process just needs to take > > > care of transfering the xattr. This can even work when using a USB stick > > > or so as interim medium. > > > > I'm all for xattrs, but this thread really raises a nice question of which > > annotations/tags/whatever should be public and which should not. > > IMHO the default should be "privacy first". Probably everyone of us has > laughed about someone who accidentially published either metadata or > deleted text (remember MS Word document history or something)? I'm > absolutely fine if you want this that you do this. But most people will not > be aware of it, even less of the implications. So it should be deactivated > by default and only activated explicitely. Hmmm, right, didn´t actually think of the privacy implications. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: KCGroups in KDEreview
>From a user's point of view (who helps with triaging bugs and some other stuff from time to time), so feel free to consider it or not. David Edmundson - 03.12.20, 12:15:52 CET: > Ultimately this isn't really dealing with cgroups directly but with > the manager to control them, systemd. > > That's correct usage, kernel docs of cgroups say to go via a > controller for write operations. However that at point is it worth > naming the library ksystemd? I'd say that depends on whether it at some point could be extended to support another cgroups controller daemon or not. I don't see any popular one at this point in time, however this might change. > It might cause some contention due to people who get angsty at a name, > but it's a lot more fitting. It would then give us a place to dump a > lot of other wrappers (especially logind) that we're seeing > duplicated in a bunch of places throughout KDE. Of course if you like to extend it more towards systemd, a name change would make sense. While I know and teach what control groups can do, I do not really care about the functionality they offer at the moment on my desktop machines. I use elogind with Plasma both on Debian Sid and on Devuan Ceres which sets up a CGroup V2 structure by default, but does not do any of the resource control stuff that Systemd offers. Control groups, logind and things like that sounds like integration with services and functionalities of the host operating system. So I wondered whether it would make sense to generalize that. However, that might just be too much abstraction. There is Phonon, which does that for audio, but basically I just used whatever backend was recommended at a time. And AFAIR there has been times where one of the backends did not even work correctly for some reason. Ciao, -- Martin
Re: ACTION REQUIRED - Gitlab and Subversion server migration
Ben Cooksley - 23.07.23, 12:01:04 CEST: > Please ensure you run the following two commands to clear out any > existing host keys: > - ssh-keygen -R invent.kde.org -f ~/.ssh/known_hosts > - ssh-keygen -R svn.kde.org ~/.ssh/known_hosts The second command misses a "-f": ssh-keygen -R svn.kde.org -f ~/.ssh/known_hosts Thanks for all your work, Ben! Best, -- Martin
Re: Crow Translate
Albert Astals Cid - 08.07.24, 23:53:18 CEST: > I would appreciate a big warning when using non-free software engines > that there's no expectation of privacy on what is being translated (and > same on the Free Software ones if they don't promise that level of > privacy). Would it be possible to by default use whatever Mozilla uses for Firefox Translations? As far as I read this is local? -- Martin
