- Cuttlefish Icon Chooser
- File Browser (not on Windows because it is unstable there)
- Terminal Tool View (not on Windows because it does not work there)
Details
- Reviewers
dhaumann - Group Reviewers
Kate - Commits
- R40:9644265ee91a: Enable three more plugins by default
Remove ~/.config and started Kate. All new plugins are enabled by default.
I also tested with a plugin that does exist (to simulate users that don't have the plasma5-sdk with the cuttlefish plugin installed). There was no error.
Diff Detail
- Repository
- R40 Kate
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Phabricator is not great about multi-commit chains and really wants to squash everything. The sanest way to do it is to make two separate patches; one for each commit you want to end up in the repo. See https://community.kde.org/Infrastructure/Phabricator#If_the_patches_are_all_for_the_same_project
Hmm... File Browser works badly on Windows and Terminal Tool View not at all.
The preview plugin has really great potential, but is it ready for being enabled by default already?
I can't comment on the cuttlefishplugin that much as I have not used it before and now when I installed it today I don't know how to invoke it...
I think it is better to let people enable plugins as they needed them in stead of enabling too many by default.
The problem with this approach is that it requires that they:
- Know about Kate's plugins
- Know that there are plugins that are disabled by default
- Know what the disabled plugins are or can do and understand the description
If it were up to me I'd enable them all by default. :p
I am with Kare here: I think we should care to not enable plugins by default that are known to be problematic on windows.
Can you #ifdef this or at least add a runtime check depending on the OS?
With repsect to the icon plugin: I have enabled it here, but I don't see anything?! :-) Any hints?
About Document Preview: being the one who wrote and pushed that plugin, I meanwhile am a bit disillusioned about the technological approach taken there, and have been rather tempted to propose the removal of that plugin again, hoping for a future implementation on more solid ground.
While doing the documents preview plugin with KParts technology initially seemed a clever and smart idea to reuse existing code and technology, sadly kxmlgui is not prepared for the rivaling request for keyboard shortcuts both by the currently focused texteditor view as well as the requests for the same by the kparts plugin used for the type to be previewed. Which actually is an issue with toolviews with richer UI as well, but the KParts plugins living in the preview plugin just escalate this more, given they usually come with a set of actions and their shortcuts.
I guess I should simply upload a patch to remove that plugin again separately, for a focussed discussion instead of hijacking things here. Edit: Done, see D16668
I'll try to find out how to do the ifdef to exclude Windows from the plugins that don't work there properly.
With repsect to the icon plugin: I have enabled it here, but I don't see anything?! :-) Any hints?
Right click in the editor text area. In the context menu, there is a new entry "Insert Icon with Cuttlefish".
- Don't add katefilebrowserplugin and katekonsoleplugin by default on Windows
- Don't add ktexteditorpreviewplugin by default because it should be replaced by something better
- add some comments
I would have preferred to only have one #indef WIN32. Preprocess statements should be reduced to the minimum, imho.