Improved Support for Custom Color Schemas
- improved “Colors” tab in the “Fonts & Colors” config page
- configurable colors: search & replace, code folding, indentation line,
- schema export and import honor background colors (bug #291868) and font
- “highlight selection” plugin and “search and replace” plugin now use search & replace colors from Kate’s color schema
Line Modification System
- new option to disable in the editor settings: Appearance > Borders > [ ] Show line modification markers
- colors of the line modification system are configurable
- reworked config page (including advanced settings for remote debugging)
- support for remote debugging
- new option in Open/Save config page: [ ] Add newline at end of file on save
- all fixes in the bug tracker
Q_INVOKABLE bool insertLine(int line, const QString &s),
which can be invoked in our scripting by a call of ‘document.insertLine(5, “hello world”)’. The API only contains basic functions. But for instance Kile maybe also wants to provide a function called ‘document.insertSection()’ or similar LaTeX related functions. The question now is as follows: How can Kile extend our QObject based prototype with their own QObject based classes?
We do not want to make the class KateScriptDocument public. Instead, we just want to return a QScriptValue containing a QObject based KateScriptDocument. You can think of the problem also as follows:
If you have any idea or other solutions how to do it right, please let us know!
Years ago, there was a blog on the planet with the title “How to crash (almost) every Qt/KDE Application and how to fix it“. In short, if you are showing a dialog, KWin prevents you from closing the application by clicking on the close button in the window decoration. However, through D-Bus, you can still quit the application. A solution was also provided: Use a guarded pointer to create the dialog.While this fixes the issue, it looks like fixing the blame, and not the real issue. Stricktly speaking, even the Qt documentation would be wrong then.
Searching for ‘Accepted’ on lxr.kde.org shows lots of dialogs that lead to possible crashes. I wonder whether developers are really aware of this crash? Even if we took care of this issue as proposed, it’s just a matter of time until dialogs are created the `wrong’ way again (do we have krazy checks for that?). In Kate, no one took care of this situation, meaning that you can indeed crash the application through D-Bus.
Is there a better way to fix this?