- Queries
- All Stories
- Search
- Advanced Search
All Stories
Nov 15 2019
Sorry this has gotten stuck in limbo, @steffenh. I discussed this with @hein and @mart and we agreed that it can go in now so that it doesn't get blocked forever, but we will need to refactor how we handle touch throughout Plasma, including here in Kickoff. To track that, we have opened T12041: KDeclarative: kill own drag and drop handling. Please feel free to comment and help coordinate there, since I know you're quite interested in proper touch support.
In D24706#562797, @ndavis wrote:How is it for you compared to the git master focus decorations? I know it's not what you're asking, but I'd like to know.
(we should make a tag for all things that require Qt changes so we can prioritise them)
Ok, thank you!
In D25324#562909, @broulik wrote:I think you would want to make that a RUNTIME dependency.
This is starting to look really good. All functions will need documenting in the header of that file so they show up on api.kde.org, see other modules for examples.
In D25244#562817, @cullmann wrote:Some feedback?
Else I would just try that.
For me it worked fine (obviously).
some style complaints. Looks great other than that 👍
+1: i found myself many times wanting to use this but not being able because of plasma dep.
the code is used a lot in plasmoids and seems quite robust
- remove all color mapping tech, it's pointless since the code now uses the system palette
- remove garbage foobar class
- remove unnecessary main.moc include
- create two global SystemPalettes instead of in individual items
Also am I wonfering how this relates to the bug report you referred to? Can you tell what effect your code change has on the symptoms reported in https://bugs.kde.org/show_bug.cgi?id=409380#c0 ?
I think you would want to make that a RUNTIME dependency. This stuff is mostly for packagers, telling them to install something isn't what we want.
Thanks for looking at the issue. No time to look closer the next days, but curious about this partial change (which has been discussed before and discarded):
changing QColor ( 245, 245, 245 ); // light-grey background to highlightingTheme.editorColor(KSyntaxHighlighting::Theme::EditorColorRole::BackgroundColor) implies, one cannot use KSyntaxHighlighting to render text highlighted e.g. for a print-out on a paper (or only for a PDF). Compare e.g. the example https://phabricator.kde.org/source/syntax-highlighting/browse/master/examples/codepdfprinter/.
Is this change for background needed to make that rehighlight approach working?
Add enum declaration to make boolean settings in qml a bit more readable.
I have opened https://phabricator.kde.org/D25323 to fix the missing highlighting in kio-extras.