User Details
- User Since
- Jul 30 2015, 8:46 PM (450 w, 4 d)
- Availability
- Available
Aug 25 2023
The problem is that package managers will not overwrite /etc stuff on install, that will lead very easily to issues.
As said, I see the point for the user local config, why not in .config, all fine for me.
But I would like to have the shipped ones as data, that allows to be sure updates will enforce the new state is used.
Aug 24 2023
I think having that in /etc is very wrong as most applications totally break or even crash on any non-trivial modification of this and /etc somehow implies this is config.
The files in the config dir in the home are only meant to be written by the shortcut config and Co. and not manually altered.
In Kate and Co., if you just remove some menus or toolbars in the worst case it will just crash.
Jul 9 2023
I miss what should be in that context object. If it is just something that should be passed around, I think the current code e.g. in KTextEditor is nicer the working on a void *.
We did remove the KTextEditor::DefaultStyles , I see no reason to move the enums beside creating porting work, there is no harm in having them in the theme.
Jul 3 2023
I think most stuff was already done.
May 15 2021
If I don't misunderstand the Qt docs:
May 7 2021
Actually, I am not sure to which code path I refer, I only know that I wasn't able to ever load my local kscreen kcm module even if QT_PLUGIN_PATH was set to the right path.
Apr 23 2021
For appimage: I would rather prefer if e.g. Craft would produce these (as it already does) and the stuff for that stays in the craft blueprints.
Apr 17 2021
I think given 2020 is over, yes.
One can still create a new task for new meetings.
Apr 14 2021
Ok, yeah, you are right that on Linux/BSD/... making DBus optional is a non-goal, I agree.
One can assume it will be usable there.
It is just a pain on other operating systems.
QtKeychain uses DBus to talk to KWallet etc, so that would merely move the problem
I don't think so.
Apr 13 2021
Was already done
Apr 9 2021
Yes, the binary factory already outputs them, for sure on should aim to improve that method.
Mar 29 2021
Given that is the default mode we use them on other platforms, I would love to see this more tested, thought I am not able to grasp the full impact of this.
Mar 28 2021
Add application plugin path to default search path
Mar 27 2021
One remaining thing not solved by moving the 2 classes to WidgetAddons and re-coloring upstreaming is the auto-loading of the RCC stuff.
Short dump of notes done during sprint:
Will create actionable sub tasks.
Mar 22 2021
Yeah, but that went nowhere, true, I somehow did forget about it ;=)
That would be cool to have, at the moment I still need to patch the icon themes engine "on" for Windows/macOS and in e.g. GNOME/.... Kate will just break (like any other KDE application that relies on Breeze icons for some actions).
I learned the hard way in https://invent.kde.org/frameworks/kiconthemes/-/merge_requests/26 that our current KIconEngine is no proper 1:1 replacement for the QSvgIconEngine.
Feb 25 2021
I think it at the moment is still alive in the Qt5Compat module:
Feb 4 2021
I can live with "KDE Gear", but I could even live with other generic names like "KDE Bundle" or such ;)
Feb 2 2021
That solution looks indeed nice, too.
I would have no issue to adopt that one. Merge requests welcome :P
In the Kate/KTextEditor config dialog we tried to provide a lot of "what's this" stuff.
But I guess it would make sense to move that there just to tooltips.
Jan 26 2021
I have now a working version that handles palette changes, too.
I need to finalize this, people start to complain more and more about this missing on Windows for Kate/etc... ;(
Jan 12 2021
kactivities & kactivities-stats => guess not that relevant, as not interesting for non-unices
Dec 27 2020
I think consistency trumps all things.
Nov 24 2020
Hmm, I don't think you need a theme chooser, we just need to watch for the palette change signal and then trigger again the theme name setting based on the background palette.
That would be enough to detect bright/dark mode.
Oct 31 2020
I think exporting some namespaced function or such that will do the setting of the theme and calling it would be ok for me.
This is anyways an "opt-in" approach people must decide to use.
Hannah, what do you think?
Oct 10 2020
I think the solution we have in current master is ok enough.
Sep 8 2020
Perhaps copying it there might be better than creating the impression that people should really use it for other stuff, if Okular is the only "big" last user of this.
Aug 17 2020
Thanks for taking care of all this!
;=)
Aug 11 2020
At the moment no idea how to fix that without regressions.
For my 2 wanted changes, I created a new merge request
https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/20
As said above, I think 100 is a bad idea. Can we close this?
I think we went with the solution in https://phabricator.kde.org/D29789, could we close this?
Jul 14 2020
Hi, just to avoid any wasted work:
Jul 11 2020
Ben activated the APPX stuff
Jun 21 2020
I think having 44x44 and 150x150 icons is just a matter of scaling the ones we have, they are a SVG anyways.
I think the hard part is that somebody needs to check if all things work ok for the binary factory builds and later care about the reported issues.
Jun 15 2020
Jun 8 2020
That depends.
If somebody else would test this and we can agree that this is a nicer way to hard-code breeze icons compared to having that code in kiconthemes it would make sense.
Jun 7 2020
May 29 2020
May 28 2020
May 22 2020
;=) Actually, I just missed this request, sorry.
May 20 2020
May 18 2020
I think it makes sense to have just "Raku", the world at large (like me) only recognizes Perl 5 as Perl .P
I think this is very good thing to have.
But perhaps we just should add that to the README.md that is prominently shown on e.g. https://invent.kde.org/frameworks/syntax-highlighting
The README anyways already contains a "Adding unit tests for a syntax definition" that could be replaced with this.
Hmm, looks better for me, too.
Let's go with this at the moment.
If it creates issues, we can still revert it again.
Thanks for taking care of this.
May 15 2020
Sure, thanks for the improvement!
Hmm, right, didn't think about that :(
Guess if we want to have this, we need to improve the read/writeConfig functions.
May 9 2020
see e.g. here for a start of using the right heights inside the renderer.
Same here ;=) Thanks a lot for the work on all this issues!
Looks fine for me, thanks for improvement!
Looking at the code, might it make more sense to just move away from the fixed height we have?
It isn't used that often and in most cases one could just query the height of the current line.
That would solve this issue without needing any hacks for the rendering I think.
Apr 27 2020
Apr 26 2020
I tried the current version.
For me this looks OK now.
Thought I would like to have more people trying this out before we merge.
Some volunteers?
Apr 25 2020
Ok, I see, there is an extra request for the new hl test file.
Then let's approve this one.
Apr 19 2020
Hmm, after applying this patch, for me, no text is visible at all.
By selecting a bit stuff, one at least sees an outline (CMakeLists.txt of ktexteditor toplevel dir).