KDiff3: Fixes pasting UTF8 from clipboard #13

Signed-off-by: Roman Savochenko roman@home.home

Taken from there — https://bugs.pearsoncomputing.net/show_bug.cgi?id=3195

Just allows to paste texts with UTF-8 symbols from clipboard without its cropping.

The patch needs a bit of rework before we can accept it.

wBuf should be of type TQCString instead of TQByteArray
using wBuf.size()-1 is incorrect. size() is the size of the underlying data buffer, there is no guarantee that it is the same as the string length. We need to use wBuf.length() instead.

@roman can you update the patch and submit it again? or let me know if you want me to do it.

The patch needs a bit of rework before we can accept it.

Needs not.

wBuf should be of type TQCString instead of TQByteArray

No

using wBuf.size()-1 is incorrect. size() is the size of the underlying data buffer, there is no guarantee that it is the same as the string length. We need to use wBuf.length() instead.

Is correct since any stream from QString ends by EOF (0).

@roman can you update the patch and submit it again? or let me know if you want me to do it.

Update yourself if you want to rewrite any my code without a reason, especially if that code well tested in years!

@roman

if you want to propose code changes to a public project, you need to collaborate with the project team
if you want the dev team to work with you, you need to collaborate with the project team
if you want your code changes to be accepted, you need to collaborate with the project team
if you want other users to comment or review your code changes, you need to collaborate with the project team

Instead with your comments and arrogance, you are disrespecting and insulting all those individual who spend hours of their free time to keep this beautiful project alive and make it better.

@roman

if you want to propose code changes to a public project, you need to collaborate with the project team

if you want the dev team to work with you, you need to collaborate with the project team

if you want your code changes to be accepted, you need to collaborate with the project team

if you want other users to comment or review your code changes, you need to collaborate with the project team

@MicheleC
I have no need in all four items, I just share results of my efforts, and you whether apply them or I'll hold all those fixes and improvements in my really STABLE repository! So, I won't listen your comments!

Instead with your comments and arrogance, you are disrespecting and insulting all those individual who spend hours of their free time to keep this beautiful project alive and make it better.

Really! And how do you insult me when completely zeroing my efforts and time to find and test all those, when start to do that from the beginning? Did you think about that?
And do not tell about everyone again, tell about yourself!!!

See things as you like it and think what you prefer. I just brought to your attention that this is not the way to collaborate with an open source project.

See things as you like it and think what you prefer. I just brought to your attention that this is not the way to collaborate with an open source project.

And that is just your "seeing things as you like it and think what you prefer", and I have own open source project, then I know very WELL how "collaborate with an open source project"! :)

See things as you like it and think what you prefer. I just brought to your attention that this is not the way to collaborate with an open source project.

And that is just your "seeing things as you like it and think what you prefer", and I have own open source project, then I know very WELL how "collaborate with an open source project"! :)

@roman come back to the topic, please.

why do you think it should be TQByteArray? What is the advantage of using this type?

I hope with technical arguments we could reach some consent. More over it will give a nice ending to the discussion that got somehow personal without reason.

And finally it would provide some knowledge why one or the other type is used in some situations.

In my opinion it is not necessary to go to byte level if not needed. In the context it might be not of big difference, but it is about the style of coding and at the end Michele has the final word. So why it is a big problem for you to change this part of your patch. Please, give me just the technical part - the personal, we could discuss in private, or not as you like, but it has no place in public technical discussions.

Thank you

@roman

if you want to propose code changes to a public project, you need to collaborate with the project team

if you want the dev team to work with you, you need to collaborate with the project team

if you want your code changes to be accepted, you need to collaborate with the project team

if you want other users to comment or review your code changes, you need to collaborate with the project team

@MicheleC
I have no need in all four items, I just share results of my efforts, and you whether apply them or I'll hold all those fixes and improvements in my really STABLE repository! So, I won't listen your comments!

Instead with your comments and arrogance, you are disrespecting and insulting all those individual who spend hours of their free time to keep this beautiful project alive and make it better.

Really! And how do you insult me when completely zeroing my efforts and time to find and test all those, when start to do that from the beginning? Did you think about that?
And do not tell about everyone again, tell about yourself!!!

@roman, your case to KJobViewer was an excellent example that even the constant repetition patch works, so it is right, it does not lead to a hack to become the right fix. Only a thorough analysis helped that a real fix was made. Your stubborn unwillingness to discuss, cooperate on analyzing and testing the repair of the true essence of the problems makes us consider every your patch to be a hack that requires detailed examination. Your attitude is therefore completely unconstructive, and it is you who will collide the value of your efforts.

why do you think it should be TQByteArray? What is the advantage of using this type?

@deloptes
OK, let's say from other side, why do you think that must be anything and not TQByteArray?

In my opinion it is not necessary to go to byte level if not needed. In the context it might be not of big difference, but it is about the style of coding and at the end Michele has the final word. So why it is a big problem for you to change this part of your patch. Please, give me just the technical part - the personal, we could discuss in private, or not as you like, but it has no place in public technical discussions.

In my opinion that works and used in other parts TDE, why must I search something other? Do you think I have many time for constantly rewriting well worked and long tested code? :)

@roman, your case to KJobViewer was an excellent example that even the constant repetition patch works, so it is right, it does not lead to a hack to become the right fix.

@SlavekB
Must I remind you all your stupid cases? :)

Only a thorough analysis helped that a real fix was made.

OK, let's revert all my patches with "bad analysis" starting from KPDF, to do TDE especially "wonderful"! :)

Your stubborn unwillingness to discuss, cooperate on analyzing and testing the repair of the true essence of the problems makes us consider every your patch to be a hack that requires detailed examination. Your attitude is therefore completely unconstructive, and it is you who will collide the value of your efforts.

Your misunderstanding, that somebody uses the crashable functions and wants to fix that without treating about "pretty look" of the code, that is something really stubborn! :)

OK, let's say from other side, why do you think that must be anything and not TQByteArray?

Because TQTextCodec::codecForName("UTF-8")->fromUnicode(data); returns a TQCString object

To add to Slavek's comment, we review every patch, no matter who the author is. Even our own patches are published as pull requests first and need to be reviewed before we merge them, because we can all make mistakes and someone else reviewing the code is a good way to spot them or offer a different point of view.

OK, let's say from other side, why do you think that must be anything and not TQByteArray?

Because TQTextCodec::codecForName("UTF-8")->fromUnicode(data); returns a TQCString object

What do you say?

QByteArray QTextEncoder::fromUnicode(const QString &str)
Converts the Unicode string str into an encoded QByteArray.

To add to Slavek's comment, we review every patch, no matter who the author is. Even our own patches are published as pull requests first and need to be reviewed before we merge them, because we can all make mistakes and someone else reviewing the code is a good way to spot them or offer a different point of view.

OK, but without me. :)

Because TQTextCodec::codecForName("UTF-8")->fromUnicode(data); returns a TQCString object

What do you say?
QByteArray QTextEncoder::fromUnicode(const QString &str)
Converts the Unicode string str into an encoded QByteArray.

This (.h and .cpp) is the method called in your patch and it returns a TQCString:

class TQ_EXPORT TQTextCodec {
[...]
    TQCString fromUnicode(const TQString& uc) const;
    
[---]

TQCString TQTextCodec::fromUnicode(const TQString& uc) const
{
    int l = uc.length();
    return fromUnicode(uc,l);
}

By the way could I ask what source code you are looking at? TDE code use the TQ prefix for TQt3 classes (as in TQByteArray, TQTextCodec and TQString) but your code is using Q only.

By the way could I ask what source code you are looking at? TDE code use the TQ prefix for TQt3 classes (as in TQByteArray, TQTextCodec and TQString) but your code is using Q only.

I use the original Qt specification, where the prototype is this one, so QByteArray is TRUE even if you redefined that in the tqtinterface.

why do you think it should be TQByteArray? What is the advantage of using this type?

@deloptes
OK, let's say from other side, why do you think that must be anything and not TQByteArray?

Because here it is about data which is text and UTF is already handled very well in the TQCString. There is no need to go one level below this class (which is the bytes).
It would also properly fit in the context.

As mentioned it works for you and I don't mind using this approach, when it is about your own repository. This is your own decision. But in the case you are submitting to someone else your patch and if you want him/her to adopt them, you should cooperate, because it is not your decision anymore.

In my opinion it is not necessary to go to byte level if not needed. In the context it might be not of big difference, but it is about the style of coding and at the end Michele has the final word. So why it is a big problem for you to change this part of your patch. Please, give me just the technical part - the personal, we could discuss in private, or not as you like, but it has no place in public technical discussions.

In my opinion that works and used in other parts TDE, why must I search something other? Do you think I have many time for constantly rewriting well worked and long tested code? :)

Well, perhaps those other parts need to be updated as well.
No one is forcing you to do this work. We are talking only about this patch and I, personally, do not understand what kind of problem you have with changing this to TQCString. IMO it really doesn't matter in this case and it is unnecessary waste of time on all sides. Why do you think I have time to write this? Because I respect everybody here, trying to make TDE better and I see unnecessary struggle, which can be avoided. So if you were so kind to rethink and be more cooperative, it would be just great. BTW it is called somewhere "cooperative game theory" that bring us forward. I guess, everybody would agree that you are welcome to improve TDE, but it also means you are part of the coalition.

It's just my 5c.

> > why do you think it should be TQByteArray? What is the advantage of using this type? > > @deloptes > OK, let's say from other side, why do you think that must be anything and not TQByteArray? > Because here it is about data which is text and UTF is already handled very well in the TQCString. There is no need to go one level below this class (which is the bytes). It would also properly fit in the context. As mentioned it works for you and I don't mind using this approach, when it is about your own repository. This is your own decision. But in the case you are submitting to someone else your patch and if you want him/her to adopt them, you should cooperate, because it is not your decision anymore. > > In my opinion it is not necessary to go to byte level if not needed. In the context it might be not of big difference, but it is about the style of coding and at the end Michele has the final word. So why it is a big problem for you to change this part of your patch. Please, give me just the technical part - the personal, we could discuss in private, or not as you like, but it has no place in public technical discussions. > > In my opinion that works and used in other parts TDE, why must I search something other? Do you think I have many time for constantly rewriting well worked and long tested code? :) > Well, perhaps those other parts need to be updated as well. No one is forcing you to do this work. We are talking only about this patch and I, personally, do not understand what kind of problem you have with changing this to TQCString. IMO it really doesn't matter in this case and it is unnecessary waste of time on all sides. Why do you think I have time to write this? Because I respect everybody here, trying to make TDE better and I see unnecessary struggle, which can be avoided. So if you were so kind to rethink and be more cooperative, it would be just great. BTW it is called somewhere "cooperative game theory" that bring us forward. I guess, everybody would agree that you are welcome to improve TDE, but it also means you are part of the coalition. It's just my 5c.

Well, perhaps those other parts need to be updated as well.

@deloptes
Sure, rewrite all Qt, since it is a standard Qt function! In TDE like to rewrite what need not be rewrote! :)

QByteArray QTextEncoder::fromUnicode(const QString &str)
Converts the Unicode string str into an encoded QByteArray.

Well, perhaps those other parts need to be updated as well.

@deloptes
Sure, rewrite all Qt, since it is a standard Qt function! In TDE like to rewrite what need not be rewrote! :)
QByteArray QTextEncoder::fromUnicode(const QString &str)
Converts the Unicode string str into an encoded QByteArray.

I have no idea what documentation you are based, but for the original Qt 3.3 there is no method with such signature:

virtual QCString fromUnicode ( const QString & uc, int & lenInOut ) const
QCString fromUnicode ( const QString & uc ) const

In the source code are available:

    virtual QCString fromUnicode(const QString& uc, int& lenInOut) const;

    QCString fromUnicode(const QString& uc) const;

    virtual QByteArray fromUnicode(const QString& uc, int from, int len) const;

See archive of the original Qt 3.3 documentation: https://doc.qt.io/archives/3.3/qtextcodec.html

The same API is valid for TQt3 and tqtinterface, only with T prefix. So no, there is really no method that you allegedly use. So it is obvious that the code is desirable to change, regardless of whether it would be designed for original Qt 3.3 or our TQt3.

@roman, your case to KJobViewer was an excellent example that even the constant repetition patch works, so it is right, it does not lead to a hack to become the right fix.

@SlavekB
Must I remind you all your stupid cases? :)

I would not need to mention the case of your incorrect patch for KJobViewer, but you pointed out it as a proof of your "perfect patch".

Only a thorough analysis helped that a real fix was made.

OK, let's revert all my patches with "bad analysis" starting from KPDF, to do TDE especially "wonderful"! :)

No one says that all your patches are hacks. Exactly for this reason, the code is revised before merging. If the code is good, it is merged. If any part is not good, we will ask to change it. If something is suspicious, we will ask for an explanation. In short, it is necessary to cooperate.

Your stubborn unwillingness to discuss, cooperate on analyzing and testing the repair of the true essence of the problems makes us consider every your patch to be a hack that requires detailed examination. Your attitude is therefore completely unconstructive, and it is you who will collide the value of your efforts.

Your misunderstanding, that somebody uses the crashable functions and wants to fix that without treating about "pretty look" of the code, that is something really stubborn! :)

This is not about "pretty look" of the code, but whether the patch solves a real bug or just hides the consequence of a bug that remains in the code and will manifest itself in other situations. Our goal is to fix bugs, not to mask individual cases of their consequences and thus make revealing real bugs more complicated.

I have no idea what documentation you are based, but for the original Qt 3.3 there is no method with such signature:

@SlavekB
So, see the documentation for what the stupid tqinterface was created for — https://het.as.utexas.edu/HET/Software/html/qtextcodec.html :)

@SlavekB

I would not need to mention the case of your incorrect patch for KJobViewer, but you pointed out it as a proof of your "perfect patch".

And I am not ashamed of the patch that solved the problem of crashing for a long time!

No one says that all your patches are hacks. Exactly for this reason, the code is revised before merging. If the code is good, it is merged. If any part is not good, we will ask to change it. If something is suspicious, we will ask for an explanation. In short, it is necessary to cooperate.

What is a sign of "a community with high mutual trust", of course? And if me do not accept your revision, in the view of understanding the case with KRfb and KJobViewer? :)

This is not about "pretty look" of the code, but whether the patch solves a real bug or just hides the consequence of a bug that remains in the code and will manifest itself in other situations. Our goal is to fix bugs, not to mask individual cases of their consequences and thus make revealing real bugs more complicated.

When the patch resolves the case at least for one additional person, that is already TRUE patch and must be accepted as a ground for other fixes and don't reject during 10 years! And you misunderstand this still, and that was about the "pretty look" code!!!

@SlavekB
So, see the documentation for what the stupid tqinterface was created for — https://het.as.utexas.edu/HET/Software/html/qtextcodec.html :)

This is Qt4 documentation, not TQt3.

@MicheleC

@SlavekB
So, see the documentation for what the stupid tqinterface was created for — https://het.as.utexas.edu/HET/Software/html/qtextcodec.html :)

This is Qt4 documentation, not TQt3.

And the stupid tqinterfase was created for binding of what?
In any case, all the higher Qt versions confirm that is using QByteArray is a TRUE way!

And the stupid tqinterfase was created for binding of what?
In any case, all the higher Qt versions confirm that is using QByteArray is a TRUE way!

Well, at the end everything is a byte :) or even a bit. I suggest we do assembler (joking).

What would be the issue for you to change it here to TQCString? The object is destroyed by the end of this function.

What would be the issue for you to change it here to TQCString? The object is destroyed by the end of this function.

I need not that and don't want to do the stupid work!

@roman, I thank you for all your explanations.

Now I understand that all your patches are great, regardless of whether they solve or do not solve a bugs. And that it is a great honor for us, that you give us these great results of your efforts.

For this PR I now understand that your patch is absolutely right and great, and that the problem is on our side, that TDE does not use and never used the API Qt >= 4.0.

@roman, I thank you for all your explanations.

Now I understand that all your patches are great, regardless of whether they solve or do not solve a bugs. And that it is a great honor for us, that you give us these great results of your efforts.

How sadly. :/ But no, I have understand that about you far ago! :)
Since your own changes you apply without any revision or even testing, those we are watching in the 14.1.x "wonderful" mess, but my-own 10 year testing fixes you say as not fixes ( @deloptes ). :)

For this PR I now understand that your patch is absolutely right and great, and that the problem is on our side, that TDE does not use and never used the API Qt >= 4.0.

Really! Do you relate to TDE in whole or you just are breaking down it here? :)

Let's open tqtinterface-trinity-14.1.0/qtinterface/interface_tqt3/tqapplication.h and see the surprise: :)

#ifdef USE_QT3

// Reimplement the QApplication class
// For Qt3, no changes are needed

#include <ntqapplication.h>

// X11/X.h defines Time as unsigned long
void set_tqt_x_time(unsigned long x);
unsigned long get_tqt_x_time(void);
void set_tqt_x_user_time(unsigned long x);
unsigned long get_tqt_x_user_time(void);

#endif // USE_QT3

#ifdef USE_QT4

// Reimplement the QApplication class
// For Qt4, some changes are needed

#include <tqt4/Qt/ntqapplication.h>

#endif // USE_QT4

I updated the patch myself to adapt it to the TDE way. PR #14 is a replacement for this one.

@SlavekB @deloptes I think we have already wasted enough valuable time commenting here to no use. I will reject this PR because it does not meet the requirements and @roman does not bother following conventions and cooperate.
Let's stop wasting our time!

@MicheleC

Let's stop wasting our time!

That is you only, who are wasting your own and my time struggling through absolutely non principal stuffs!!!

@MicheleC

Let's stop wasting our time!

That is you only, who are wasting your own and my time struggling through absolutely non principal stuffs!!!

Now everybody is enlightened with your wisdom. The time was worth it. Otherwise, we poor stupid creatures would be walking on this earth in darkness.

At least I was amused. And this is no waste of time.

KDiff3: Fixes pasting UTF8 from clipboard #13

Εξεταστές