Where are Kate syntax files stored?
Syntax highlighting XML files used to come with katepart, but that's gone now in KDE5. I did a brute-force grep on my filesystem, but still can't find the syntax XML files :-/ Where are they?
Re: Where are Kate syntax files stored?
On Saturday, 2017-08-05, 17:39:49, Nikos Chantziaras wrote: > Syntax highlighting XML files used to come with katepart, but that's > gone now in KDE5. I did a brute-force grep on my filesystem, but still > can't find the syntax XML files :-/ > > Where are they? I think they are part of the KTextEditor Framework now, Kate and friends depend on. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Where are Kate syntax files stored?
On Saturday August 05 2017 17:24:13 Kevin Krammer wrote: >I think they are part of the KTextEditor Framework now, Kate and friends >depend on. The SyntaxHighlighting framework, nowadays. AFAIK the system location for the highlighthing files is $prefix/share/org.kde.syntax-highlighting/syntax . User-specific copies (also those downloaded with Kate's built-in updater) are stored in ~/.local/share/org.kde.syntax-highlighting/syntax . R.
Task manager window grouping failures and KWin window-action slowness
I have LOTS of windows, and while task manager window grouping in KDE4 started off pretty bad early on, it got better for me. In Debian Jessie, i would have issues running 3 different firefox profiles with differing Class Instance names, where it would still *usually* correctly separately group them, but sometimes draw the incorrect icon for them. Now, in Debian Stretch, the icon managers are *TERRIBLE* at grouping my firefox windows. I have *hundreds* of firefox windows, and i'm lucky if task manager manages to make 1 or 2 groups of a few tens or dozens, and then ALL of the rest become individual task manager icons. (race condition?) I prefer using Icon-only Task Manager with "Show Launcher when not running" (though, interestingly, in Icon-only mode, there's not "Group Windows" setting button) I have tried switching "Alternatives" hoping that doing so would issue a "regroup" operation, but it seems that the grouping algorithm is done one-time at window creation in some common code? Is there any way to FORCE the code to re-evaluate grouping? Or, is this bug fixed in subsequent Plasma or KDE Frameworks (or whatever component) releases? Additionally, i like to set window-action for double-click title bar to "lower". with many windows, it can sometimes take 30 seconds for the action to complete. it sits there doing nothing, and i don't know for sure if it's that i keep hammering at it, or i move the mouse and click in different windows, then hammer on it some more, but it eventually will do a lower. (it's not ALWAYS that slow). Sounds to me like some code branch goes off to evaluate something and gets all caught up in some operations that don't scale very well to hundreds/thousands of windows). These are regressions from behaviors that USED to be fine (mostly in KDE3 where on a much less substantial machine than what i have now, i never had any issues of unresponsiveness. yes, Firefox has had a role in creating unresponsiveness), but in jumping from Debian Jessie to Stretch, i'm finding a lot of little issues in Plasma5 that i do NOT want to throw at my users yet, and am being forced to evaluate alternative DEs. (SDDM is god awful slow and the cursor can take tens of seconds to show up sometimes, KDE session initialization takes much longer than KDE4, race conditions can cause context bubble windows to get permanently stuck on the plasma-desktop, etc.) [VersionInfo] Qt: 5.7.1 KDE Frameworks: 5.28.0 plasmashell: 5.8.6 thanks, --stephen
Re: Where are Kate syntax files stored?
On 05/08/17 18:24, Kevin Krammer wrote: On Saturday, 2017-08-05, 17:39:49, Nikos Chantziaras wrote: Syntax highlighting XML files used to come with katepart, but that's gone now in KDE5. I did a brute-force grep on my filesystem, but still can't find the syntax XML files :-/ Where are they? I think they are part of the KTextEditor Framework now, Kate and friends depend on. Hm, it doesn't install any xml files.
Re: Where are Kate syntax files stored?
On 05/08/17 18:31, René J.V. Bertin wrote: On Saturday August 05 2017 17:24:13 Kevin Krammer wrote: I think they are part of the KTextEditor Framework now, Kate and friends depend on. The SyntaxHighlighting framework, nowadays. AFAIK the system location for the highlighthing files is $prefix/share/org.kde.syntax-highlighting/syntax . User-specific copies (also those downloaded with Kate's built-in updater) are stored in ~/.local/share/org.kde.syntax-highlighting/syntax . That directory doesn't exist. In fact, this: $ find / -name "*syntax*" doesn't find anything relevant. There's also nothing in my ~/.local directory.
Re: Where are Kate syntax files stored?
2017-08-05 15:55 GMT-03:00 Nikos Chantziaras : > On 05/08/17 18:24, Kevin Krammer wrote: >> >> On Saturday, 2017-08-05, 17:39:49, Nikos Chantziaras wrote: >>> >>> Syntax highlighting XML files used to come with katepart, but that's >>> gone now in KDE5. I did a brute-force grep on my filesystem, but still >>> can't find the syntax XML files :-/ >>> >>> Where are they? >> >> >> I think they are part of the KTextEditor Framework now, Kate and friends >> depend on. > > > Hm, it doesn't install any xml files. The built-in syntax highlighting XML files are packed into a Qt resource (qrc). This improves performance when loading them. I don't remember if it's installed as a separate qrc file or if it's embedded into the library, though. Why do you need them? You can get them from the SyntaxHighlighting framework source code[1], and you can install modified versions in the user path René mentioned. [1] https://cgit.kde.org/syntax-highlighting.git/tree/data/syntax) -- Nicolás
Re: Where are Kate syntax files stored?
On 05/08/17 22:00, Nicolás Alvarez wrote: 2017-08-05 15:55 GMT-03:00 Nikos Chantziaras : On 05/08/17 18:24, Kevin Krammer wrote: On Saturday, 2017-08-05, 17:39:49, Nikos Chantziaras wrote: Syntax highlighting XML files used to come with katepart, but that's gone now in KDE5. I did a brute-force grep on my filesystem, but still can't find the syntax XML files :-/ Where are they? I think they are part of the KTextEditor Framework now, Kate and friends depend on. Hm, it doesn't install any xml files. The built-in syntax highlighting XML files are packed into a Qt resource (qrc). This improves performance when loading them. I don't remember if it's installed as a separate qrc file or if it's embedded into the library, though. Why do you need them? You can get them from the SyntaxHighlighting framework source code[1], and you can install modified versions in the user path René mentioned. [1] https://cgit.kde.org/syntax-highlighting.git/tree/data/syntax) Ah, OK. No wonder I was unable to find them. Thanks for the link. The reason I need them is because I need to modify tads3.xml and update it due to changes in the language it defines the syntax for.
Re: Task manager window grouping failures and KWin window-action slowness
Stephen Dowdy posted on Sat, 05 Aug 2017 11:23:38 -0600 as excerpted: > I have LOTS of windows, and while task manager window grouping in KDE4 > started off pretty bad early on, it got better for me. > > In Debian Jessie, i would have issues running 3 different firefox > profiles with differing Class Instance names, where it would still > *usually* correctly separately group them, but sometimes draw the > incorrect icon for them. > > Now, in Debian Stretch, the icon managers are *TERRIBLE* at grouping my > firefox windows. > > I have *hundreds* of firefox windows, and i'm lucky if task manager > manages to make 1 or 2 groups of a few tens or dozens, and then ALL of > the rest become individual task manager icons. > > (race condition?) Sounds like it. Right here at the top I'll mention that my usage is much different than yours so the degree of practical help I can provide is very limited, but I do run live-git "kde family", from frameworks, thru plasma and apps, and follow plasma's (that's the whole desktop including kwin, plasma system settings, etc, not just the shell) development via the plasma-devel list which gets all the pre-master-merge discussion, and am thus at least somewhat aware of developments that don't directly affect my own use, but will affect yours. It's on that basis that I'm replying. I neither group windows nor use a taskbar at all, here, preferring window management alternatives such as the alt-tab switcher, multiple desktops with switching via desktop scroll or cube, the window list menu which I have configured to popup with a "middle" button click, etc. It also helps that I have a /huge/ desktop, a 65"/165cm 4K TV (3840x2160) as my primary monitor, with window rules set to default most windows to 1280x1080, so I can do a 6-off grid of three windows wide by two high, so I don't need to Z-axis stack them so deeply, particularly when using multiple desktops as well. (I also have a secondary 48"/122cm "full-HD" TV (1920x1080), on which I can and often do have a full-screen youtube or the like session playing, the idea being it can be full-screen on that monitor and still not encroach on my 3x2-window main work display area.) Between that and the fact that I'm an old-timer whose computer workflow consists of opening windows to work on, working on them, then closing them, closing and restarting windows/apps as needed rather than leaving them hanging around unused for days at a time, I don't usually get the number of windows you're quoting and thus don't tend to end up /needing/ to manage hundreds of windows at a time. Tho I will often open up to perhaps 50 firefox windows or so while catching up on news, along with a news/feed/mail reader (which close to the tray and I seldom have more than one open at a time), maybe a reply window for messages such as this, and perhaps 2-3 konsole windows if I'm updating (gentoo so that means building from sources) the system at the same time. But still almost never more than 100 windows, and most of the time under 50, quite a way from your several hundred. But it works for me, and if yours works for you... =:^) > I prefer using Icon-only Task Manager with "Show Launcher when not > running" (though, interestingly, in Icon-only mode, there's not "Group > Windows" setting button) > > I have tried switching "Alternatives" hoping that doing so would issue a > "regroup" operation, but it seems that the grouping algorithm is done > one-time at window creation in some common code? I'd expect so... people don't tend to like windows showing up in one group, then moving to a different one just because the name of the window changed or something similar, after all. > Is there any way to FORCE the code to re-evaluate grouping? Or, is this > bug fixed in subsequent Plasma or KDE Frameworks (or whatever component) > releases? One "hackish/manual" technique I've had some success with, is using the command line at first, then scripting if whatever bug is forcing it continues to happen frequently enough, to quit (kquitapp or killall, or using htop, ksysguard, etc) and restart whatever plasma component, whether that be kwin (kwin-x11), plasmashell (the desktop activities and panels themselves), krunner (the run dialog), xembedsniproxy (the "legacy" tray app proxy), etc. Just don't try to quit and restart ksmserver, startx, xinit, startkde, etc, or you'll shutdown the entire session! In fact, I've one entire hotkey launcher menu dedicated to resetting/ restarting various components, both kde/plasma related as above, and otherwise (resetting mouse accel (xset m(ouse)), keyboard repeat rate (xset r(epeat)), reloading my now kde-independent due to kde breaking what was working just fine with no work-alike alternative on major upgrades several times hotkey app (sxhkd for the hotkeys and a hand- rolled konsole/bash-script combo for hotkey menus) after editing its config, etc). Since I don't use window groupin