[Qt-creator] R.I.P. for QPlainTextEdit in Qr Creator 17?

[apoenitz]

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'