- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Jun 15 2020
May 15 2020
I think for the default(!) settings, familiarity trumps everything else. That's why I think, a vertical panel is a bad idea. There is a reason why Mate, Cinnamon, Xfce, LXDE etc exist, why Mint is such a popular distribution and why I even see a lot of screenshots of people moving the panel to the bottom on GNOME. People coming from Windows want a familiar environment and they make up still the vast majority of potential future users. KDE should not make the same mistake as GNOME by ignoring this simple fact, and corner itself in some "obsessed with design details" bubble.
May 10 2020
Strange. It worked with gmake locally, but failed on the Flathub buildbot again (https://flathub.org/builds/#/builders/32/builds/19809, only x86_64 failed, not arm or aarch64).
Indeed. It failed with cmake 3.15.2 + ninja 1.9.0 and worked with make (4.2.1).
Apr 13 2020
OK, found it:
They wouldn't even need to enable the Flathub repo like Neon did. Just having the backend installed by default would improve the out of box experience enormously. (You could then just go to flathub.org and click-to-install, no restart needed)
In T11994#226574, @heikobecker wrote:It will (parts of it already have). "to Opt In" is the important part of the sentence. Soon everything will be moved to gitlab, see the thread on kde-devel for more details.
In T11994#226350, @bcooksley wrote:Probably one of the final ones to Opt In:
- amarok
OK, found it.
fixed:
How can I close this? (phabricator UI really sucks, I hope the move to Gitlab is completed soon)
Mar 28 2020
In D28360#636448, @gikari wrote:Again, why not just make XSettingsd required? It's simpler.
Mar 27 2020
In D28360#636418, @gikari wrote:But the option is enabled by default and needs to be explicitly disabled. This seems to be an overengineered solution. It basically says, that XSettingsd is an optional dependency, which already is.
In D28360#636406, @gikari wrote:In D28360#636404, @eszlari wrote:I would like to have this in 5.18
We cannot add mandatory dependencies to the stable branches/releases. Currently it's an optional dependency. If you want to make it mandatory, only 5.19 and later are possible options.
In D28360#636403, @gikari wrote:Why just not make xsettingsd required?
Mar 14 2020
Mar 13 2020
Mar 9 2020
Mar 8 2020
In D25324#624299, @gikari wrote:In D25324#624229, @eszlari wrote:This bug is not fixed by this patch. xsettingsd needs to be started in plasma-workspace/startkde/startplasma.cpp (or by systemd in the future).
xsettingsd is started by the daemon itself, if it's not instantiated already. The daemon itself launches at startup, because it is a kded module.
This bug is not fixed by this patch. xsettingsd needs to be started in plasma-workspace/startkde/startplasma.cpp (or by systemd in the future).
Mar 5 2020
Feb 27 2020
See also: https://phabricator.kde.org/D25324
In D25324#563373, @gikari wrote:In D25324#563347, @eszlari wrote:But seems, this only applies to dependencies checked by find_package().
I'm confused.
Does it mean, I should create custom FindXsettingsd.cmake module for xsettingsd, then write something like this:
find_package(Xsettingsd) set_package_properties(Xsettingsd PROPERTIES TYPE RUNTIME DESCRIPTION "Provides settings to X11 applications via the XSETTINGS specification" URL "https://github.com/derat/xsettingsd" )?
Feb 19 2020
Feb 14 2020
Nov 29 2019
Nov 16 2019
I guess he refers to:
Nov 15 2019
In D24743#562745, @gikari wrote:I'm not very proficient in CMake, so how can I do that?
Nov 14 2019
Maybe a warning about the runtime dependency on xsettingsd should be added to cmake, so distro packagers know about it.
Aug 20 2019
Aug 11 2019
Jun 14 2019
Apr 20 2019
I think, for my small contributions, this would be overkill, but thanks for your trust! :-)
Apr 19 2019
@apol Have forgotten to commit?
Apr 4 2019
Mar 22 2019
I guess you guys would consider this to be too risky for 5.15? (Although a lot of Nvidia owners - me included - are dying to get this fix).
Oct 18 2018
peter.eszlari@gmail.com
Oct 9 2018
Aug 8 2018
May 30 2018
In D13102#268116, @apol wrote:I don't really see how to put it without reading convoluted. Also as is, the documentation isn't wrong, we are just changing the logic to use one or another.
May 29 2018
May 28 2018
Do you have a commit access ?
May 27 2018
May 11 2018
Jan 16 2018
change CMAKE_BUILD_TYPE to RelWithDebInfo and remove CMAKE_INSTALL_LIBDIR=lib
When the KDE nightly build is switched to this manifest, it would be good, if a hint was added to krita's download page, with a link to the repo file:
I changed the manifest to be usable for nightly builds and removed openjpeg.
Jan 15 2018
In D9882#191275, @rempt wrote:I have no opinion in the appstream file question, but I'm fine with having these definitions in our repo, on the same basis as the snap definitions: I cannot maintain them.
In D9882#191052, @ngraham wrote:Would you consider adding <release> information to your AppStream metadata file here, so you don't need to patch it in on Flathub?
It's already there on master and will be dropped when 4.0 is released.
Jan 14 2018
And in case you are not familiar with the current state of flatpak: when the user has a recent version of Plasma Discover or GNOME Software installed, it's of course enough to click the the bundle to install it.
fixed name of manifest in instructions
By the way: The resulting bundle includes python scripting support and should contain support for audio in animations (I had no idea how to test that).