On Sat, Jun 21, 2025 at 04:17:09PM +0200, Henry Skoglund wrote: > > [...] > > > Thanks for answering, it's all working fine now with the new > Utils::PlainTextEdit. > > Perhaps I'm doing it wrong, i.e. I shouldn't take a hard dependency on the > built-in editor being of a certain class. > > Say I were to write a new plugin to Qt Creator having only one command, like > F5 in Notepad in Windows: inserting the current date and time where the text > cursor is. > > What would the best approach be? (Utils::MacroExpander could probably be > good enough for inserting the date but what about the time.)
I am afraid that "best" is subjective, and as any "Contemporary Truth (tm)" relative in time and space. I can, however, offer my personal opinion, mostly based on historical evidence, on how to approach this. My order of plans would be: Plan A: In case the functionality you want to add might be interesting not just for you but also for a handful-or-more of other users, the "best" approach would be trying to contribute you feature to Qt Creator itself. For smaller stuff that'd usually be integrating it into the best suited existing plugin, for more exotic stuff or large functionality or things that would require unusual external dependencies, that could mean a new plugin. Disadvantage here: You have to go through the whole procedure of creating a Qt Account, signing the CLA, making your peace with Gerrit, publishing your change, running through the review process, sticking to possibly weird-appearing coding conventions, etc, etc. Advantage here: Once it is in, you have a de-facto guarantee that your code is kept compilable, and every test you add (hint, hint... ;-)) will very likely pass before the next release, so your personal maintenace effort would be rather small after the initial investment. And your feature is practically available for everyone out there. Plan B: If Plan A is not acceptable (for whatever reason, e.g. you don't want the CLA, or hace Qt Account, or live your own coding style, or the feature does not seem to be of general interest, or...) it would make sense to stick to access to internal functionality that is /documented/ (which is, admittedly, not much, and to some degree for a reason) -- or -- ask (e.g. here) how stable a certain "interface" is expected to be. This will likely result in hints which interface to prefer (in this particular case here e.g. using TextEditorWidget::fromEditor() instead of the qobject_cast, which would, in case you assigned it explicitly to a 'QPlainTextEdit *' caused a compilation error, or, in case of using 'auto' (which I personally would not recommend, but would actually have worked in this particular situation indeed) just have worked. This is no strict guarantee that these things will stay stable. but I am currently not aware of a case where such things (then usually with a comment in the code who uses it, and why) changed without co-ordination with the user. Disadvantage here: You (or, say, github...) will need (as long as you want to...) take care of providing builds for the platforms you expect to use, or to be used by people using your plugin. Advantage here: Code remains under your full control, you can do whatver you want without coordinating with someone else. Plan C: That's a bit speculative, since it is rather new, and I don't have real evidence how it works out in practice: Base your plugin on the interfaces exposed through Lua. Right now the plan is to keep those /really/ stable. Disadvantage here: This is rather new, not heavily field-tested. The exposed interfaces are at the moment rather limited (even though they are e.g. good enough to keep the Qt AI Assistant going) so you may need to ask for them to be extended to cover your use case, e.g. by a message on the list here or at bugreports.qt-project.org. Advantage: Effectively the same as in Plan B, plus no need to build yourself for multiple host platforms etc. Plan D: Everything else. Best regards, Andre' -- Qt-creator mailing list Qt-creator@qt-project.org https://lists.qt-project.org/listinfo/qt-creator
