How to launch .desktop files properly?
Hello, specifically in this case, how should ksmserver properly launch autostart apps, when they are specified by their .desktop files? When the autostart launching code was moved from klauncher to ksmserver by [1], it replaced the launching by simply using QProcess, which caused a number of problems such as not parsing the Exec line properly (fixed by [2]), ksmserver discarded all stderr of launched apps instead of them going to ~/.xsession-errors, and launched apps getting killed by SIGPIPE under specific circumstances. I got bitten by these and simply fixed it with [3] by using KRun::runApplication(), as AFAIK that is the proper way to launch something using a .desktop file. Seeing that others had these problems as well (the bugreports mentioned in the commit message for [3]), I backported it after some time. And, after 5.9.5 got out, bug #379254 ([4]) has been reported, about desktop startup taking too long. It turns out that some distros ship broken autostart .desktop files, KRun shows a blocking error dialog (under ksplash) and that blocks the whole startup. To make this even worse, it's not very obvious why the error shows up, and even if it were, kcm_autostart actually completely ignores global autostart files. Now, does somebody know how this should be done properly? QProcess has poor defaults for fire-and-forget launching of apps (bye-bye stderr, hello SIGPIPE). KProcess is better, but there's still a lot of what KRun/klauncher do that would need to be copy: All the .desktop file parsing and KProcess setting up, kdeinit, KAuthorized, X-KDE-RunOnDiscreteGpu. Not that I know if all of this matters much nowadays, but if it wasn't needed, then why KRun still does it, and one way or another all the manual setup would be lame. I've also looked at KToolInvocation::startServiceByDesktopPath(), which talks to klauncher directly, but there I'm not sure what the status with klauncher is (I mean, if the autostart code hadn't been moved, there wouldn't be any of this), and also while the function is technically not deprecated, its documentation has @deprecated suggesting to use QProcess (ugh) or KRun. So I guess that leaves KRun and just making sure it optionally doesn't show the blocking dialog, such as adding "QString* error = nullptr"? Or does somebody have a better idea? And if not, is it ok to just commit this change to kio repository, or are there nowadays any special rules for library commits now that there are zillion git repos? [1] https://cgit.kde.org/plasma-workspace.git/commit/ksmserver?id=d9883511c92e448b3441d994170fa1d43eea4ff2 [2] https://cgit.kde.org/plasma-workspace.git/commit/ksmserver?id=889be45e893425273d545a73edc42c4bbead446d [3] https://cgit.kde.org/plasma-workspace.git/commit/ksmserver?id=0377d6a992725e0b0b469b87d17343fa3730b829 [4] https://bugs.kde.org/show_bug.cgi?id=379254 -- Lubos Lunak
Re: KDE Review: Kor - a minimalistic desktop shell
On Tuesday 05 of February 2013, Tomaz Canabrava wrote: 'Big Forehead' in portuguese. ROTFL. I should make up an odd story based on this (BTW, 'cor' also apparently means 'odd' in Irish). So, as you might have noticed, it has almost become a tradition that SUSE people use odd names whenever they create any KDE-related: Meinproc, unsermake, icecream, and I'm sure I'm missing a few more. And since KHotKeys, as much as it was an odd misnomer, didn't quite have a ring to it, I tried harder this time. But if that's not a good story, an odd tortoise that simply wanted its good ole desktop back is fine with me too. 2013/2/5 Albert Astals Cid aa...@kde.org El Dilluns, 4 de febrer de 2013, a les 10:24:53, Martin Sandsmark va escriure: Kor is a simple and minimalistic desktop shell with support for plasmoids, plasma wallpapers, etc., but also its own minimalistic plugins/widgets. It is an option for those with low-end hardware or who don't need a full Plasma desktop. It has no configuration UI, and relies on hand-edited configuration files. Kor Testudo Shell does Testudo mean something? It's a name, I had to name it something. As long as there's nothing actually wrong with the name, I just use it and don't care what the name is. PS: Although, thinking about it, you had me wondering for a moment why you hadn't asked about 'Kor'. -- Lubos Lunak l.lu...@suse.cz
Re: KDE Review: Kor - a minimalistic desktop shell
Hello, On Monday 04 of February 2013, Martin Sandsmark wrote: Dear esteemed ladies and gentlemen (and everyone in between), Kor is a simple and minimalistic desktop shell with support for plasmoids, plasma wallpapers, etc., but also its own minimalistic plugins/widgets. It is an option for those with low-end hardware or who don't need a full Plasma desktop. It has no configuration UI, and relies on hand-edited configuration files. I'd like to clarify this a bit. Simple yes, and definitely simpler than Plasma Desktop, but minimalistic no, at least not by design. The current state is simply what 'just works' for me (I haven't had to touch the codebase for the last year), and I couldn't be bothered to add e.g. the configuration UI, but I won't stop anybody from doing so. I rather see Kor as a classic desktop that is a bit like the KDE3 desktop (because of being used to it, reusing some code, and not bothering with touch interfaces) that is built on current KDE platform (which is what differentiates it from Razor-Qt or Trinity). For all practical purposes, it is a KDE desktop. And although it should be somewhat lighter on resources than Plasma Desktop, I have no idea how much (especially after it loads anything Plasma-based). -- Lubos Lunak l.lu...@suse.cz
Re: KNotify-considerations for frameworks
On Friday 23 of September 2011, George Kiagiadakis wrote: I agree with parts of this plan, but not all of them. I think we need to study more the use cases. Let's consider a few examples. ... 2) Your music player informs you of the next song that is going to be played. You most likely want a popup here. Anything else would be annoying. Plus, there is no good reason for having this configurable from the knotify settings dialog, since it can just be a checkbox in the music player (which it already is in amarok for example). So I cannot have e.g. a custom command that shows the song name in an OSD or whatever form I'd want 3) Your voip software informs you of an incoming call. You definitely want a persistent popup with accept/reject buttons and you may also want a persistent ringing sound. Disabling the popup should not be allowed, or else users will not be able to handle the call, so the only thing that you can have configurable is the sound. or to disable the popup, leave just the sound and accept the call simply in the app itself 4) Your window manager wants to play sounds for window events like minimize, maximize, close, etc... There is absolutely no reason to allow the user configuring popups for these notifications, as well as anything else. Just sounds are enough. or have a popup saying 'window XYZ demands attention' or have a KWin compositing effect, or whatever else that I haven't come up with but that doesn't mean nobody else can? So, what I think that should happen is this: Create something in tier1 (or tier2 if needed) that allows people to just show popups, Such a thing has been there since ages, KPassivePopup, and I've always hated it when somebody used it directly instead of KNotification. a lot of the options on the KNotification object are also not needed (they are read from the config file) That's right, but I'd expect they were added mostly for people with this I want only this exact event to happen line of thinking that you show. This will simplify things, both for developers and users. The current solution of having one system that can do everything and people using it for completely different use cases creates this feel of complexity that we have. Which part exactly would be simplified? Creating several specialized solutions instead of one, having developers to think about what they should use instead of notify(eventname), or the user interface where the apps will need their own GUI and will not let users change half of the things? If there are perceived problems with KNotification, Aaron's mail has a much better approach to handling them. -- Lubos Lunak l.lu...@suse.cz
Re: Klipper
On Tuesday 31 of May 2011, Esben Mose Hansen wrote: On 2011-05-16 18:35, todd rme wrote: Would that make klipper a potential target for the upcoming modularization efforts, then? As a pseudo-sometime maintainer of Klipper, I have thought about this extensively. So this is my take on it. Klipper should be modularized like this: 1. The core bit: 1.a. This bit should listen to clipboard changes, and notify interested clients about changes as they occur. Why would they need it instead of QClipboard::changed() ? 1.b. It should also handle at least basic clipboard retention (that is, plain text, html, and QT-supported image formats). Note that it doesn't really depend on whether Qt supports the format or not, QClipboard::mimeData() can provide the complete clipboard contents in all formats, whether known or not. The problem is rather the question what formats to store (more than one usually means duplication of the underlying data and there's no generic way to tell which format is the best, additionally actually creating the data in any format may possibly take some time). 2. The history bit. This should be a client. It should be able to store the history. It would be best if the selection is only recorded if it is plain text, with the option of being completely ignored. This could be - a race condition (depending on how the retrieving of content for history saving is done) - slow (keep in mind that people occassionally put huge data into clipboard) It could also handle the edit clipboard feature. I can see the reason why this could be outside of the core, or why the history showing could be, but the saving itself IMO fits much better in core. 3. The action bit. This feature is surprisingly popular, but I still find it a bit bells-and-whistles sort of thing. For those who don't know what it is, it is a listener that looks at the clipboard contents and if it matches certain patterns (e.g., looks like an URL, matches a file on disk etc), pops up a passive popup with some options for handling it, say opening the file in okular or whatever). Now, since we are discussing this, I can put my question to the crowd: Does this sound like a dataengine with two plasmoids to you? It sounds a bit like over-engineering to me. Or should it be a service that communicates over dbus? Or is it just a bad idea. Given what's said above, I myself would try to keep all the data handling to the core, as much as possible. The UI, if separate, could just forward commands to the core or ask only for contents it actually needs to show. That said, history has shown that having clipboard polling in an important process can occassionally break things in ugly ways, so trying to move the core to KDED (or Plasma, if somebody really thinks that's a good idea) should be something to think about twice. And if it already needs a separate process, what is the gain of the UI separation (this is not a rhetoric question)? Note that if it is converted to a dataengine/plasmoid, the Gnome users we have will hate us. The only UI from Klipper I care to see are the history and action popups, so if this meant I'd need to have a plasmoid somewhere just to remind me that a a functionality I consider core exists, then count me in. -- Lubos Lunak l.lu...@suse.cz
Review Request: Make KFileDialog update saved file type based on extension also for non-mimetype based filters
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6325/ --- Review request for kdelibs, Rafael Fernández López and David Faure. Summary --- Run e.g. Kolourpaint, do 'Save as', type 'a.xpm' , KFileDialog will automatically select 'XPM' as the saved type. This however doesn't work with all applications, namely those that use KFileDialog::setFilter() (i.e. only setMimeFilter() works this way). This patch implements this feature also for this case. Diffs - trunk/KDE/kdelibs/kfile/kfilefiltercombo.h 1208060 trunk/KDE/kdelibs/kfile/kfilefiltercombo.cpp 1208060 trunk/KDE/kdelibs/kfile/kfilewidget.cpp 1208060 Diff: http://svn.reviewboard.kde.org/r/6325/diff Testing --- Tried with LibreOffice with KDE4 integration, where this feature works only with this patch. Thanks, Lubos
