On 07/20/12 21:54, Thomas Lübking wrote:
AFAIK you cannot use it in Qt 4.6
"In 4.6, an internal template class QStringBuilder has been added along
with a few helper functions. This class is marked internal and does not
appear in the documentation, because you aren't meant to instantiate it
in your code. Its use will be automatic, as described" [1] ... not here ;-)
The documentation may be wrong, but unless your Qt 4.6 users say
"doesn't work" i'd say "does" =)
Okay then -- will try whether it builds when patches arrive.
+ - @p max defines the demanded maximum reply length - the return
can be longer, but the client will not make use of that
+ negative values mean "uncapped"
What is this used for?
Performance and/or remote queries. I don't consider typing "a" and
getting a list with a hundred entries which i will then navigate for the
address a use case - so there's no point in presenting more than <place
random number here> entries (or look them up, or transmit them)
Good point. Could you please add that to the comments in the source code?
This also falls into the "wanna use an AbstractModel instead" case.
I don't follow, sorry. I assume that you mean that you'd like to switch
the recipients input/handling into some kind of Qt's model class instead
of keeping track of them in the current way, right? If so, I don't object.
+ struct Completion {
+ int pos, length;
+ QMenu *popup;
+ QLineEdit *receiver;
+ } m_completion;
I don't know what is this class for. Could you please add comments?
Just a container for some completion related variables.
Useless if we use a regular QCompleter
I meant that I'd like to have these comments in the code. Thanks for
explanation, if it isn't necessary now, no need to think about it anymore.
25 #include "Sample.h"
26 #include "AnotherClass.h"
27 #include "BClass.h"
I assume "Sample.h" is the source header and "AnotherClass.h" and
"BClass.h" are random local includes?
Correct. The header corresponding to the .cpp file should be first,
followed by non-Qt system headers (<algorithm> etc) in the alphabetical
order, followed by Qt headers in the alphabetical order, followed by
Trojita headers, again in alphabetical order.
I placed it where the autocompletion used to be and because ..
OK, just the generic "if it's a QObject, use QObject's features", "if
it's something else, take care" remark. The question didn't mean to
imply that there's something wrong in particular, just a code which
triggered my "check this" alert.
because they are tied to the config options.
... i assume the addressbook backend should be configurable.
Right, but I still consider them different enough. Basically anything
IMAP-specific is now set up in createModels()/nukeModels() due to the
fact that nothing such can even outlive the base Model. This will have
to change a bit when multiple accounts come into play, though.
That's why I'd like to keep anything not building of top of
Imap::Mailbox::Model out of this pair of functions.
Feel free to react to the settings being updated in the same way, but
please make it separate from Model and the related classes. These are
"fragile". Feel free to s/createModels/createImapModels/,
s/nukeModels/nukeImapModels/ and adding new pair of create/nuke...
funcitons calling the former along with your non-IMAP classes like the
completer.
In the present layout.
The present code (not introduced by me) inserts them anyway behind a
certain index and this here was done only when removing an entry.
Okay. I suspect I'm the author of that crappy code.
They do rely on each other - the re-layouting was pointless ;-)
(I however would suggest to replace the OFFSET_OF_FIRST_ADDRESSEE based
injection with a sublayout because right now just removing the warning
would break things.
Agreed, that whole class/component is a big hack already (as of now,
i.e. my code).
With kind regards
Jan
--
Trojita, a fast e-mail client -- http://trojita.flaska.net/
