PDA

View Full Version : Qt 4.3.0 lots of Bugs!



VireX
10th June 2007, 20:03
Ok, I upgraded to 4.3 today, and basically most of my skin is now messed up.

Example, border-image property now has "Stretch and repeat", and instead of stretching it normally and in an amazing way like in 4.2, now they messed it up completely for the sake of a tiny millisecond optimization by "dividing the image into 9 parts and repeating the middle-parts for more optimization". This rule just pixelates all my treewidgets and other things. I can actually see the lines of color changes, its not even a gradient anymore just a bunch of lines of awful graphic rendering.

Why did they make skinning 100x worse in 4.3, did they forget to test it??? Or did they think the pixelation bugs are just better looking?

Doesn't make any logical sense, why they would fix something that wasn't broken.

In addition, normal PNG images are now blurry and awful. Somehow, some of my backgrounds just felt like disappearing. My TreeWidget now has a horizontal scrollbar that wasn't there in 4.2.3, plus a bunch of other random bugs that make absolutely no sense. Really did they beta test for 1 week, because I don't see how they can go from the awesomeness of 4.2.3 to 4.3's crappy untested graphics enhancements. The only thing they did well in 4.3 is the new stylable widgets in stylesheets.

marcel
10th June 2007, 20:26
I don't think they messed anything up.
Most likely you didn't do everything by the book :).

As for blurry things, etc... check if you have any antialiasing enabled.
And for things that weren't there in the prev version, most likely there have been added functions and parameters that let you take them out.

Regards

VireX
10th June 2007, 22:41
How do I check if anti-aliasing exists? And why didn't tell inform me of changes in the change logs???

VireX
10th June 2007, 23:08
Here's another AWFUL 4.3.0 bug, really dumb too...

If you make a table view, and put some buttons inside the cellwidgets, and at same time put some text under the buttons (so you can sort the buttons appropriately), it will RANDOMLY delete/hide some buttons for absolutely no reason, if you keep clicking sort, it will continue to hide/show random buttons.

Wow its like they released 4.3.0 without ANY testing... never seen this many bugs from Qt before. So very un-qt-like.

OH and let's add one more to the list, QApplication::alert() is just awful, it flashes even when the windows is activated, my own Win32 API Flash() function is so much better. And alert doesnt even allow you to change the flags.

jacek
10th June 2007, 23:34
Really did they beta test for 1 week, because...
Beta tests are when the product is released to the public for everyone to test. Did you test 4.3 beta (it was released almost three months ago)?

You metion "lots of bugs", but so far you gave only six examples of differences you have encountered after the upgrade. Just like Marcel noted, first make sure that they are really caused by bugs and not because you have relied on some undocumented features. We will happily help you to verify that, but we will need some code to be able to reproduce that behaviour.

VireX
10th June 2007, 23:53
No they're definitely bugs, because, when you change from 4.2.3 to 4.3, it works good in 4.2.3, but in 4.3 it makes it worse than it is. This is called a bug because its an unforeseen effect of code changes in 4.3 that isn't for the better.

I didn't use any "undocumented" anything, I used correct ways to do everything according to 4.2.3, and I have attempted to fix it using the 4.3 docs, but its unfixable because of internal bugs.

Example, the QAbstractItemView is buggy, if you add buttons to a TableWidget to like a column of cells, (large one), and then also add some text to that cell, SetItemText, and SetWidgetItem etc, and if you keep pressing sort a bunch of times, buttons will start disappearing. This is truly a bug... I would report it, but it may already been reported, I don't see how it can be missed by 3 months of testing, unless people are not testing stuff.

jacek
11th June 2007, 00:11
Example, the QAbstractItemView is buggy, if you add buttons to a TableWidget to like a column of cells, (large one), and then also add some text to that cell, SetItemText, and SetWidgetItem etc, and if you keep pressing sort a bunch of times, buttons will start disappearing. This is truly a bug...
Could you post a minimal compilable example for us to test?


I would report it, but it may already been reported,
Then check it: http://trolltech.com/developer/task-tracker
The Trolls can't fix bugs they aren't aware of.


...unless people are not testing stuff.
Exactly. You complain about the outcomes of beta tests, but did you participate in them?

VireX
11th June 2007, 00:48
No because Beta doesn't give out a compiled installer with all the DLLs etc... I couldn't participate because I cannot waste my time to figure out how to compile Qt from source code.

I'm trying to recreate it, but I can't recreate it in a small app, only in my own app something is missing. Maybe only happens when the thing is overloaded like my main app. With lots of buttons and rows. I will keep trying.

I also checked tracker i didn't see anything but I dont know whether its been reported under a different name or title etc.

Meanwhile I think Qt changed its TransformationMode, so that when Border-Image is resized, using QImage, it uses TransformationMode = Quick instead of smooth like it usually does, so I think that's the cause of 99% of my blurry images. What do you think?

VireX
11th June 2007, 01:11
Oh btw here I reproduced this bug... so easy... Sorting is broken.



#include <QtGui>

int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QTableWidget* qt = new QTableWidget;
qt->verticalHeader()->setVisible(false);
qt->setSortingEnabled(true);
qt->sortItems(0, Qt::AscendingOrder);
qt->setRowCount(75);
qt->setColumnCount(2);
QTableWidgetItem *__colItem = new QTableWidgetItem();
__colItem->setText(QApplication::translate("t", "test", 0, QApplication::UnicodeUTF8));
qt->setHorizontalHeaderItem(0, __colItem);
QTableWidgetItem* ax[75];
for(int i = 0; i < 75; i++){
ax[i] = new QTableWidgetItem(QString("Ebeeef%1").arg(i));
qt->setItem(i, 0, ax[i]);
qt->setCellWidget(i, 0, new QPushButton("ff"));
}
qt->show();
return app.exec();
}


I reported it to TaskTracker, but they said "mail sent" and didn't put it on yet....
This is definitely a bug.

wysota
11th June 2007, 01:19
No because Beta doesn't give out a compiled installer with all the DLLs etc... I couldn't participate because I cannot waste my time to figure out how to compile Qt from source code.
So don't complain it's not tested. Others are wasting their time so that you can use a well written product for free (both as in free beer and free speech). Why not return the favour?


I'm trying to recreate it, but I can't recreate it in a small app, only in my own app something is missing. Maybe only happens when the thing is overloaded like my main app. With lots of buttons and rows.
Or maybe the bug is in your code and not Qt's :) I think that if that happens to be the case, you should officially promise to compile and test Qt4.4 beta when it comes out and report any bugs you should find.


I also checked tracker i didn't see anything but I dont know whether its been reported under a different name or title etc.
You can try using the search engine...


Meanwhile I think Qt changed its TransformationMode, so that when Border-Image is resized, using QImage, it uses TransformationMode = Quick instead of smooth like it usually does, so I think that's the cause of 99% of my blurry images. What do you think?

Actually Qt by default uses FastTransformation and it has always been like that. Please attach the picture along the QSS you have in your code that causes it to be blurry. Better yet provide a simple single function code for us to help you test it.


Oh btw here I reproduced this bug... so easy... Sorting is broken.

In what way broken? What did you expect to see and what did you receive?


I reported it to TaskTracker, but they said "mail sent" and didn't put it on yet....
It's middle of the night in Norway, let them come to work, read your mail and verify the bug first... You should receive an automatic reply stating your report has been received and somebody should get back to you on the report within upcoming days.

VireX
11th June 2007, 01:40
1. It's easy for them to compile since they compile it constantly to test, so why can't they just include everything the way it is in installer like lib folder and bin folder?? Is that so hard, forcing me to compile it myself just makes me run away as well as thousands of other potentially good testers. That's their fault not mine. And I will complain if it's not tested well because that is what all programmers do with their client. I tried to participate, but i couldn't find any compiled files.
2. It's not in my code, why would my code suddenly decide its not gonna work when I switch from 4.2.3 to 4.3.0, that makes no logical sense.
3. I did use the search engine.
4. Then why is my images messed up now? It's blurry, I don't have a screenshot of old version, but I am telling you it's blurry, all I had in CSS was:
border-image: url(Stuff.png) 3;
border-width: 3;

It's a round circle button. Something changed, and now all the border-image stuff is wrong, example when it stretches instead of a smooth transition in a gradient, where you dont see the lines of color changes, now you can actually see the gradient changing color every 5 lines in big images. In addition, buttons that are just not repeating or stretched using border-image are blurred or choppy/pixelated. Test it, it's simple, just make a round button image in a Qapp, then save as transparent png, and then on QPushButton{ border-image: put the image here. It will do the same to your button.

I will try and get you one...
5. I told you, buttons are randomly disappearing from the tablewidget, test the code and you'll see. Only because of sorting etc.
6. I didn't get an autoresponse... weird... Didn't appear either in tasktracker.

jacek
11th June 2007, 01:41
Oh btw here I reproduced this bug... so easy... Sorting is broken.
I've compiled your example using Qt 4.2.3 and got this:
1255

Are you sure that the problem is really with the transition from 4.2.3 to 4.3.0?

VireX
11th June 2007, 01:59
Yep, see you can see the bug too.
This didn't happen in 4.2.3, in 4.2.3 this would have all the buttons there, no Ebeef etc.

And I'm not gonna resubmit this bug to tasktracker again, I typed a lot of stuff in that form, submitted it and i got a screen saying "mail sent", and I never got an email, nor did my bug appear anywhere...

Methedrine
11th June 2007, 02:16
Oh btw here I reproduced this bug... so easy... Sorting is broken.


I compiled this code with Qt 4.2.2, Qt 4.2.3 and Qt 4.3.0 and it always looks and behaves the same. What should the bug be, specifically?

OS: Windows XP Pro SP2
Compiler: MSVC 2005

jacek
11th June 2007, 02:46
Yep, see you can see the bug too.
But that particular bug is in your code.

Look:
...
qt->setSortingEnabled(true);
qt->sortItems(0, Qt::AscendingOrder);
...
for(int i = 0; i < 75; i++){
ax[i] = new QTableWidgetItem(QString("Ebeeef%1").arg(i));
qt->setItem(i, 0, ax[i]);
qt->setCellWidget(i, 0, new QPushButton("ff"));
}
...
First you tell Qt to sort all of the items alphabetically and then you add them in non-alphabetical order, so Qt has to sort the items after every setItem(). In result you invoke setCellWidget() either zero or more than once on certain cells.

The proper way to do it is:
for(int i = 0; i < 75; i++){
ax[i] = new QTableWidgetItem(QString("Ebeeef%1").arg(i));
qt->setItem(i, 0, ax[i]);
qt->setCellWidget(ax[i]->row(), 0, new QPushButton("ff"));
}

It works fine on Qt 4.2.3, but on Qt 4.3.0 there's indeed some problem with cell widgets and sorting.

VireX
11th June 2007, 02:48
The bug is that it doesnt sort it properly, it makes random buttons disappear, this makes absolutely no sense. I dont understand your question.

Yes you are right jacek, but it is just weird that it somehow worked in 4.2.3 and not in 4.3.0

VireX
11th June 2007, 03:43
Ok I found a way to compare the two and show you... One image is from PHotoshop, the other is the result from border-image... See how it pixelates the borders? Started in Qt 4.3, because of the new "divide into 9 equal parts and only stretch middle pieces appropriately", whatever this was done for, I guess maybe for optimization? Or just the fact that they poorly tested this or documented it. And it's not just me saying this, many of my Qt friends are saying this so dont just blame me. Either way, they didn't need to fix what was NOT broken.

http://img171.imageshack.us/img171/6238/testbadimgik1.png
http://img524.imageshack.us/img524/5595/testgoodimgxz7.png

See the pixely borders? Why, it was looking so sweet in 4.2.3, why did they need to do this? Feel free to post this on TaskTracker for me, because I dont think TaskTracker likes my email.

If you cannot see it, zoom in on the image, the inner button, the inner-circle is the one used in border-image, not the outer circle, outer circle is FINE. Notice the places its pixelated? Basically It looks like they cut up that image into 9 pieces, and stretched the middle parts, exactly as the docs say... its a horrible idea, nothing matches now. Always messed up corners in almost ALL my border-images.
>>---

As for the Sorting problem, this also worked perfectly in 4.2.3, why would they change sorting in 4.3, when it worked fine in 4.2.3? I dont even see this in the change logs. And Jacek showed me how to fix my SAMPLE APP, buttttt, I cannot do this in my own application because of the way I programmed it, it would take a lot of rewriting of major classes to fix it that way.

Also, what I've noticed is, that when a button disappears it replaces the wrong area.. Like if you load the list VIA sortItems, and enable sorting, everything looks fine, but when you click sort, u see a blank button in row 3... but now row 73 (3 from last), has row 3's button... so weird.

>--- EDIT: Nother bug to our big list.. should 4.3.0 be recalled? :P ----<
deleteLater() on any window, then you try exiting App... QApplication doesn't exist.

wysota
11th June 2007, 09:03
Yes you are right jacek, but it is just weird that it somehow worked in 4.2.3 and not in 4.3.0

Your code was incorrect so you can't assume it worked in 4.2.3. The sorting issue might be caused because of the fact that the items with cell widgets don't contain any DisplayRole data. You could check what happens if you add some text to it.


And I'm not gonna resubmit this bug to tasktracker again, I typed a lot of stuff in that form, submitted it and i got a screen saying "mail sent", and I never got an email, nor did my bug appear anywhere...
It was 2 AM in Norway when you sent the mail! Please let people working in Trolltech come to work and download your email. When they do, the info email about the report being received will be sent to you. If you have a commercial licence, then email or phone your support and ask for help. If you're using the free licence - don't use arguments that contain the word "client" in them, because you're not Trolltech's client, so they don't have to give you anything. And there is a perfectly good reason why unstable code is not shipped in binary form.


Started in Qt 4.3, because of the new "divide into 9 equal parts and only stretch middle pieces appropriately", whatever this was done for, I guess maybe for optimization?
Correct me if I'm wrong, but border-image used to cut the image in 9 pieces in Qt 4.2 as well and it complies with what the CSS standard says. It's what it was actually meant to do...


Or just the fact that they poorly tested this or documented it. And it's not just me saying this, many of my Qt friends are saying this so dont just blame me. Either way, they didn't need to fix what was NOT broken.
Please reproduce the error using code and not using Photoshop.



Feel free to post this on TaskTracker for me, because I dont think TaskTracker likes my email.
At 2am I wouldn't like your email either :)


Basically It looks like they cut up that image into 9 pieces, and stretched the middle parts, exactly as the docs say...
So that's exactly what it's meant to do, right?


And Jacek showed me how to fix my SAMPLE APP, buttttt, I cannot do this in my own application because of the way I programmed it, it would take a lot of rewriting of major classes to fix it that way.
So after all it is you who has buggy code :)


deleteLater() on any window, then you try exiting App... QApplication doesn't exist.
Example code, please.

VireX
11th June 2007, 20:14
Your code was incorrect so you can't assume it worked in 4.2.3. The sorting issue might be caused because of the fact that the items with cell widgets don't contain any DisplayRole data. You could check what happens if you add some text to it.

My code was not incorrect in 4.2.3, as it worked at that time, and you yourself (or perhaps it was jacek cant remember) suggested that I do setItems under the setCellWidget.


It was 2 AM in Norway when you sent the mail! Please let people working in Trolltech come to work and download your email. When they do, the info email about the report being received will be sent to you. If you have a commercial licence, then email or phone your support and ask for help. If you're using the free licence - don't use arguments that contain the word "client" in them, because you're not Trolltech's client, so they don't have to give you anything. And there is a perfectly good reason why unstable code is not shipped in binary form.
I guess you're trying to tell me that trolltech does not know how to use server-side coding or something, because I don't believe CODE looks at time and goes "Oh well I am not going to send an auto-response at this time of night"


Correct me if I'm wrong, but border-image used to cut the image in 9 pieces in Qt 4.2 as well and it complies with what the CSS standard says. It's what it was actually meant to do...
Yes that's true, I compared the 4.2 and 4.3 docs, but for some reason, now, it doesn't work well.. Try it yourself, make a gradient about this size from black to gray, [________]
its a small image, about 100px width by 30px height; ALSO make sure you put a small 1 px border around this image in a light gray color, and make sure the gradient looks like a rounded border-radius box. Now, make a laaaaarge TreeWidget, make it about 100widthX700 height. Now set the border-image on that, border-width 2. Run the program, and you will see how horribly Qt likes to render your gradient.

But perhaps this has something to do with the "experimental DX code" that I read somewhere in the changelogs.


Please reproduce the error using code and not using Photoshop.
How many times do I have to explain to you how to reproduce it, have you tried to reproduce it with code? This is an image rendering problem, not a code problem, its a code problem inside Qt not outside.


At 2am I wouldn't like your email either :)
Code doesn't care about time.


So that's exactly what it's meant to do, right?
Yes but in Qt 4.2.3 it did this smoothly, but in 4.3.0, it pixelates it like as if saving your image in a bad quality.


So after all it is you who has buggy code :)
No, because if a code works fine in one version, then next version your code is somehow now labeled buggy, that means either the documentation for 4.2.3 was wrong, or 4.3.0 documentation is wrong. Because they both dont say anything about how I coded it as being wrong. If in 4.2.3 it worked, and 4.3.0 it doesn't it means someone in Qt changed the code for that in a bad way, and downgraded Qt's code for that purpose.


Example code, please.
I explained to you the problem, you can try it yourself, I can't post code for every time one of my friends comes to me and tells me that Qt is bugged because of whatever reason.

My question to you is this... How come I couldn't find a single bug in 4.2.3, yet I can find at least 10 in 4.3.0.... There is obviously a reason for this.

Methedrine
11th June 2007, 21:18
*stuff*

No code - no help. Stop wasting our time with posts like the ones you made in this thread. If you have a problem, supply a minimum compilable example (or if not possible, at least the code around the area which is causing trouble).

VireX
11th June 2007, 21:23
I supply tons of code examples, only to be said "thats your fault", when its clear as DAY that its a QT bug. I proved to you the bug, by showing you the example that jacek even admited was wrong by Qt to mess the cell widget up. That code would work fine in 4.2.3, what went wrong?

The graphics bug, I cannot post the code, because I dont know whats causing the bug, I told you to try to put a border-image on a complex image, and you will see it yourself, if you don't see it yourself, I'm sorry, but I can't post any code, if I did I would have to post code for 5000 lines or so.

I'm not wasting your time, I'm telling you theres a bug, and telling you exactly how it happened, and explaining why it might be happening, I can't post the code for border-image, because if it's not as simple as I explained to recreate, then it's very difficult for me to find out whats causing it and what "Area" of code to post.

mm78
11th June 2007, 21:27
How come I couldn't find a single bug in 4.2.3, yet I can find at least 10 in 4.3.0.... There is obviously a reason for this.

One of the reasons could be bad eyesight. You don't seriously believe that there were no bugs in 4.2.3? Actually, it's not at all impossible that your code worked with 4.2.3 because of bugs in 4.2.3, and that it doesn't work with 4.3.0 because those bugs were fixed. And referring to an earlier post in this thread: such a bug would be an instance of "undocumented feature". Something that wasn't meant to work accidentally works - just by chance. Never ever write code that depends on undocumented features unless you can accept that your code might break in the future.

Also, it's quite obvious that you're capable of reproducing the bugs you're complaining about so you must have some code. Why don't you post your code for us? If you can't even be bothered to post your code then why on earth would we be bothered to write it? After all these are your problems - not ours - and most of us don't get any sort of kick out of helping fussbudgets such as you.

My advice to you is simple: stick to 4.2.3 or post your code. Read this (http://en.wikipedia.org/wiki/Beta_version#Beta) and try out the beta next time. It really isn't that hard nor time consuming to compile Qt. And again, if you can't be bothered why would we?

Edit: How can it be clear as the day that this is a Qt bug, and how come you know how it happened and why it might be happening, when you don't know what is causing it or even which area of your code is triggering it?

wysota
11th June 2007, 22:23
My code was not incorrect in 4.2.3, as it worked at that time

If something works, it doesn't mean it's correct.


and you yourself (or perhaps it was jacek cant remember) suggested that I do setItems under the setCellWidget.
So as I said, Jacek pointed out an error in your code, so it was not correct.


I guess you're trying to tell me that trolltech does not know how to use server-side coding or something, because I don't believe CODE looks at time and goes "Oh well I am not going to send an auto-response at this time of night"
No, I'm trying to tell you that auto-response is sent when the message is downloaded from the mail server and not when it is delivered to the mail server. At least it looked like so for every single bug report I posted to Trolltech thus far.


Yes that's true, I compared the 4.2 and 4.3 docs, but for some reason, now, it doesn't work well.. Try it yourself, make a gradient about this size from black to gray, [________]
its a small image, about 100px width by 30px height; ALSO make sure you put a small 1 px border around this image in a light gray color, and make sure the gradient looks like a rounded border-radius box. Now, make a laaaaarge TreeWidget, make it about 100widthX700 height. Now set the border-image on that, border-width 2. Run the program, and you will see how horribly Qt likes to render your gradient.
First of all with Qt 4.3 I wouldn't use an image for a gradient because Qt can make one for me without problems. The behaviour you describe seems perfectly normal. If you stretch an image, it gets distorted. What's so unusual about it? What would you expect it to do?


But perhaps this has something to do with the "experimental DX code" that I read somewhere in the changelogs.
I don't think so.



How many times do I have to explain to you how to reproduce it, have you tried to reproduce it with code? This is an image rendering problem, not a code problem, its a code problem inside Qt not outside.
Don't explain, show the code used to reproduce it so I can see the difference between 4.2.3 and 4.3.0 myself instead of relying on your words.


Yes but in Qt 4.2.3 it did this smoothly, but in 4.3.0, it pixelates it like as if saving your image in a bad quality.
So you agree that it didn't work correctly in Qt 4.2.3 and it does work correctly in Qt 4.3.0? So where is the bug?


No, because if a code works fine in one version, then next version your code is somehow now labeled buggy, that means either the documentation for 4.2.3 was wrong, or 4.3.0 documentation is wrong.

No. Your code was abusing some presumed faulty behaviour.


Because they both dont say anything about how I coded it as being wrong.
Documentation serves as information on how to do things and not how to not do them.


If in 4.2.3 it worked, and 4.3.0 it doesn't it means someone in Qt changed the code for that in a bad way, and downgraded Qt's code for that purpose.
It means that someone changed some code. Nothing more.


I explained to you the problem, you can try it yourself, I can't post code for every time one of my friends comes to me and tells me that Qt is bugged because of whatever reason.
I'm sorry, but now you are rude. I have devoted hundreds of hours of my private time to solve problems people have - yours too. I have written dozens of example applications, tested different solutions to many problems and corrected many incorrect written lines of code. And now you say you can't write a 10 line example to help us isolate your problem? Did anyone force you to look for help here? Did anyone ask you to pay for the help you received? Did anyone expressed any demands to you or any of your associates regarding the code he/she wrote for you regarding the copyright or any form of gratitude? Could we expect less cooperation with you than asking you to describe your problem in a way that seems best for us to understand it?


There is obviously a reason for this.
Sure there is, but different from what seems obvious to you.

VireX
11th June 2007, 22:30
When you make a program with 1000s of lines of code, and then switch to 4.3.0 to find half your code broken, anyone with a brain would consider this a bug in 4.3.0 not a bug in 4.2.3. If it worked by chance, why would they need to fix it?

I am not blind, because I know bugs exist in 4.2.3, but I haven't encountered any of them in my experience, because they are very few and rare. I may have encountered one or two, but I fixed them with work-arounds, it wasn't anything that is similar to the bugs in 4.3.0 which I cannot do anything about, because I am powerless, as these fixes or bugs or whatever, are not fixable, and I have tried for several hours.

I will test any beta, to help out. But I am not going to test some code thats about 5 folders with 30 pieces of code each, and compile that, when i know that has problems in the past. I hate compiling other people's large code, because it always has tons of compiler errors and it's undocumented. And it's incredibly time consuming. You get me the dlls and libs in mingw form, and I'll test them for you any time you want. But I don't see why Qt would force people to compile it themselves when Qt can easily compile it themselves and put a small download link of zip, I dont need an installer either. I don't give my beta programs to my clients as SOurce code... I give them a working compilable version of my program.

I didn't add any feature to my program that was UNDOCUMENTED, sorting is quite well documented, and so is setCellWidget, I see no message such as "If you use sorting, don't use cellwidgets, because your buttons may disappear" and I don't see any message such in border-image documentation about "In qt 4.3.0, we changed some things so that some border images may become pixelated and blurry, to fix this do this this and that.", it worked fine in 4.2.3, why change the way it renders border-image??

It's clear as day it's a Qt bug, because it worked in 4.2.3, and it stopped working in 4.3.0, even though by the documentation I followed, my methods are correct. If they are wrong, then why wasn't a proper method mentioned in the docs of those functions?

I bothered enough to post tons of code for you to try, I even typed many paragraphs explaining how you can recreate it. I also told you other information as to what might be causing it, but I cannot pinpoint it since I do not have the Qt source in front of me or no my way around it. That is why I won't post code, because it is unrelated to my code.

EDIT @wysota:

First of all with Qt 4.3 I wouldn't use an image for a gradient because Qt can make one for me without problems. The behaviour you describe seems perfectly normal. If you stretch an image, it gets distorted. What's so unusual about it? What would you expect it to do?
Yes, but why would I type 10 lines to make gradients + a nice rounder border, when I can just do border-image: url() ? If I stretch an image it will get distorted you are correct sir, but Qt 4.2.3 had code that enhanced rendering, so that when you do stretch it, it stretches it appropriately, and makes it look perfect. While in 4.3.0, someone removed that code so that it stretches it in a bad pixelated way.

jacek
11th June 2007, 22:32
How come I couldn't find a single bug in 4.2.3, yet I can find at least 10 in 4.3.0
If you have a version number x.y.z, then the higher x and y the more features given software contains, the higher z the less bugs. If you want to compare number of bugs, compare 4.3.0 with 4.2.0.

VireX
11th June 2007, 22:35
Exactly, you're absolutely right jacek, but people here are telling me that 4.3.0 has less bugs than 4.2.3.

VireX
11th June 2007, 22:43
So you agree that it didn't work correctly in Qt 4.2.3 and it does work correctly in Qt 4.3.0? So where is the bug?
No, I said it worked well in 4.2.3, and bad in 4.3.0... Why would they fix what was perfect in 4.2.3?


No. Your code was abusing some presumed faulty behaviour.
That may be the case in many places. Not in this situation. I wasn't abusing anything when i used border-image, nor when I sorted via sortItems on a QTableWidgetItem, along with a cellWidget in same cell, you would expect the behavior of 4.2.3, not the behavior of 4.3.0, are you sure disappearing buttons in 4.3, is my fault, I don't think i put hide() or switchButtonPlaces() anywhere.


I'm sorry, but now you are rude. I have devoted hundreds of hours of my private time to solve problems people have - yours too.
I know, you are a great person and a pillar of the Qt community, and I thank you for everytime you have helped me and others in the past. But you misread my quote, I never said your work wasn't appreciated, nor did I say, I am too lazy to post code, I told you I cannot post code for something that I dont know what the problem is. I can post you thousands of lines of code, but I doubt you will find it in there? Border-Image bug is not something I can post code for, if you want the code here it is:
border-image: url(img/button.png) 5;
border-width: 5;
Is this the code you wanted? That's the only way I can reproduce it for you... I didn't do anything regarding image manipulation to cause this, this is completely based off of inner-source of Qt, not my source.
The other Qt bug, for cellwidgets, I told you, i can't reproduce it, but in the sample app was the only way to reproduce it, even when I do Jacek's fix, it doesn't help. When you change button-text and cellitem text again, and sort button is clicked again, the bug reappears and buttons start disappearing on random, I cannot know exactly why it happens. If I find some other better way to reproduce it, i'll give it to you, but I cannot at the moment.

wysota
11th June 2007, 23:01
No, I said it worked well in 4.2.3, and bad in 4.3.0...
Which one? You have mentioned more than one unexpected behaviour here.


I wasn't abusing anything when i used border-image,
I think you have.


nor when I sorted via sortItems on a QTableWidgetItem, along with a cellWidget in same cell
I won't argue with that, I only have the release candidate version, so I can't test it, but Jacek seems to agree that there's a bug here, so I won't say otherwise.


I told you I cannot post code for something that I dont know what the problem is.
We're not asking you to reproduce the problem but to reproduce the result using code presumed incorrect. We can't test your code without seeing it.


I can post you thousands of lines of code, but I doubt you will find it in there?
I won't debug your application :) I can help you find a solution to a function that doesn't work as expected, but I need to have it.


Border-Image bug is not something I can post code for,
Why not?


if you want the code here it is:
border-image: url(img/button.png) 5;
border-width: 5;
Is this the code you wanted? That's the only way I can reproduce it for you...
But does it really reproduce the error?

Try this:

#include <QApplication>
#include <QPushButton>

int main(int argc, char **agrv){
QApplication app(argc, argv);
QPushButton bt("Testing");
bt.setStyleSheet("border-image: url(img/button.png) 5; border-width: 5;");
bt.show();
return app.exec();
}

Does this yield a correct result in 4.2 but not in 4.3?

mm78
11th June 2007, 23:03
When you make a program with 1000s of lines of code, and then switch to 4.3.0 to find half your code broken, anyone with a brain would consider this a bug in 4.3.0 not a bug in 4.2.3.
Did you ever consider that this in fact might be caused by bugs in your code?


If it worked by chance, why would they need to fix it?
Because it wasn't supposed or expected to work? Now I'm not talking about the feature in general, but your way of using it.


I am not blind, because I know bugs exist in 4.2.3, but I haven't encountered any of them in my experience, because they are very few and rare.
They are not few and rare. Do a search on Tasktracker, or scan the change log for 4.3.0 for the word "bug". There were plenty of bugs in 4.2.3. There are bugs in 4.3.0 too, and their nature is not different from those in 4.2.3.


I may have encountered one or two, but I fixed them with work-arounds...
Maybe your problems are caused by these work-arounds?


I will test any beta, to help out. But I am not going to test some code thats about 5 folders with 30 pieces of code each, and compile that, when i know that has problems in the past. I hate compiling other people's large code, because it always has tons of compiler errors and it's undocumented. And it's incredibly time consuming.
Come on! You download the source, then run configure and make. It's quite easy. If you're on a slow computer it takes some time, but just leave it over night. And it IS documented. You don't have to test the Qt code either. All you need to test is your application. If you did this when the beta was released and had reported your problems to Trolltech then, they would have had 3 months to investigate your problems.


I don't give my beta programs to my clients as SOurce code...
I don't know who your clients are. Are they software developers? Can you expect them to know how to use a compiler? Can Trolltech expect that their customers know how to use a compiler? Actually you don't even need to know how to use a compiler, all you need to do is run configure and make.


I didn't add any feature to my program that was UNDOCUMENTED, sorting is quite well documented, and so is setCellWidget, I see no message such as "If you use sorting, don't use cellwidgets, because your buttons may disappear"...
If the documentation said that it would be documented. It's when the documentation doesn't say anything that it's called undocumented. And I'm not talking about general features, but about which functions should be called when, with what arguments and what kind of restrictions there are, and so on.


I bothered enough to post tons of code for you to try, I even typed many paragraphs explaining how you can recreate it.
I'm sorry, but I'm not going to sit down and write code based on your explanation to find the cause of your problems. How many lines of code would I have to write? 5000? I suspect no one else is going to do that either, and why should we when you don't?

jacek
11th June 2007, 23:12
Exactly, you're absolutely right jacek, but people here are telling me that 4.3.0 has less bugs than 4.2.3.
Where? Nobody said that there are no bugs in 4.3.0. We just want to verify that what you have encountered are really Qt bugs, because that's the first step in getting them fixed. It seems that you are more interested in complaining than in resolving issues.

VireX
11th June 2007, 23:13
Exactly, I can't tell you whats causing the problem so dont bother typing 5000 lines, but I explained what could be causing the code, and if you wanted you can try some code for 5 minutes and maybe u might reproduce it. Quite frankly I expected tons of people on this forum to see this bug, since I'm sure border-image is used quite frequently. I didn't code anything to make border-image not work... :S. I even isolated the code, so that I can eliminate any "CSS conflicts" that may be causing the problem but its not that either. I cannot tell you whats wrong, except of what I explained, I thought from my explanation you may be able to say "well maybe you forgot to code ____ along with border-image" and I would go "oooh im so sorry i forgot", but it doesn't seem like that kind of a simple problem, it seems more like a bug in qt.

I didn't make any workarounds that may cause trouble, example, I had a bug where sometimes when you delete an item from a treewidget, the item leaves a graphical representation of it, and doesn't update the widget WM_Paint or something, but after changing some of the delete code, it worked fine. Not exactly a work around, just me using an improper way of coding showing a bug in Qt... The bug does exist, but it can be fixed by your own coding, as is the bugs in this thread. The bug can be fixed, but in certain situations it shows its ugly head. I just can't figure out what situation it is, which is why i posted the bug here first before reporting to task tracker and wasting Qt developer's time. To confirm if its a bug, and so far, I think I have confirmed it, since its not a problem that someone can easily fix.

I am not interested in complaining, I want to resolve these problems as fast as possible. But even when I explain the bug countless times, no one can come up with an idea to reproduce it, everyone seems more interested in proving to me that its not a Qt bug and its my fault. I can't reproduce it myself either, but it happens in my program for some reason, and I dont know what part or AREA is causing it...it's completely a mystery. But doesn't mean it's my fault, even if I did something that caused it, it is still something that Qt made possible thru version 4.3.0. Me coding it wrong, just helped prove a bug in Qt exists thats all.

wysota
11th June 2007, 23:43
but I explained what could be causing the code
No, you didn't. You said Qt is buggy...


and if you wanted you can try some code for 5 minutes and maybe u might reproduce it.
Why don't you code for 5 minutes and reproduce the bug so that we could verify that?


Quite frankly I expected tons of people on this forum to see this bug, since I'm sure border-image is used quite frequently.
Maybe it works for them as expected...


I thought from my explanation you may be able to say "well maybe you forgot to code ____ along with border-image" and I would go "oooh im so sorry i forgot"
Maybe you forgot to read in the documentation that border-image takes parameters stating what to do with the centre image in horizontal and vertical directions?

As you can see here:
http://doc.trolltech.com/qq/qq20-pushbuttons.png

The gradient in the biggest button is stretched. The image is from Qt 4.2 and I assume you're facing the same behaviour - stretched centre image. So it seems Qt 4.2 used to work exactly the same as Qt 4.3


but it doesn't seem like that kind of a simple problem, it seems more like a bug in qt.
No, I won't repeat myself again :)

Edit: Here is a screenshot of two apps, one running 4.2.3 and one running 4.3.0rc1. They look pretty simmilar to me.

VireX
12th June 2007, 00:14
Ok, you kept asking why I cant reproduce it, well because I said I cannot reproduce it, well now I can, and you know why I couldn't reproduce the bug? because I was accidently using the 4.2.3 DLLs since they are in my PATH variable, and I forgot to put the 4.3.0 DLLs into my other folder which has the "reproducing" files. So yes it is definitely because of 4.3.0 changes. And DEFINITELY not my code.

To prove it, heres some CODE that you finally wanted. In addition some scr shots.
http://img145.imageshack.us/img145/3545/proofofqtbugja9.png



#include <QtGui>

int main(int argc, char *argv[])
{
QApplication app(argc, argv);
app.setStyle(QApplication::setStyle("Plastique")); // not related to bug prolly
QDialog* qddd;
qddd = new QDialog;
QPushButton* qb = new QPushButton("Test", qddd);
qb->setMinimumSize(QSize(62, 47));
qb->setMaximumSize(QSize(62, 47));
qb->setStyleSheet("border-image: url(test.png) 2;\
border-width: 2;");
qddd->show();
return app.exec();
}

http://img385.imageshack.us/img385/641/testwc7.png
<--- Save this image as a png in your test folder!!!! (test.png dont forget to rename)

Now this is the undeniable proof, please prove me wrong now that this is not a Qt bug.

Methedrine
12th June 2007, 00:15
About your problem with disappearing QPushButtons when sorting your table, I can confirm that there are 2 bugs. Calling sort() after adding all items is not a bug, though. It's as recommended in the documentation:


If you want to set several items of a particular row (say, by calling setItem() in a loop), you may want to turn off sorting before doing so, and turn it back on afterwards; this will allow you to use the same row argument for all items in the same row (i.e. setItem() will not move the row).

Here is the code I used for spotting and reproducing your problem:


#include <QtGui>
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QTableWidget* qt = new QTableWidget;
qt->verticalHeader()->setVisible(false);
qt->setSortingEnabled(true);
qt->setRowCount(75);
qt->setColumnCount(1);
QTableWidgetItem *__colItem = new QTableWidgetItem();
__colItem->setText(QApplication::translate("t", "test", 0, QApplication::UnicodeUTF8));
qt->setHorizontalHeaderItem(0, __colItem);
for(int i = 0; i < 75; i++){
qt->setCellWidget(i, 0, new QPushButton("ff"));
qt->setItem(i, 0, new QTableWidgetItem(QString("Ebeeef%1").arg(i)));
}
qt->sortItems(0, Qt::AscendingOrder);
qt->show();
return app.exec();
}

For some weird reason, when sorting the list ascending, there is exactly one pushbutton (always the same) not displaying. When sorting descending, all show up. That bug is new in Qt 4.3.0, didnt have 4.2.3 at hand on this machine, but it works in 4.2.2.

Did you report that as a bug already or should I submit it to TrollTech's task tracker?

VireX
12th June 2007, 00:23
They gave me a tracker ID: #166442, said they got it, but I dont see it on tasktracker, says that ID doesn't exist, and not sure if I explained it correctly.

Methedrine, in my code at the moment, I do this:

setSortingEnabled(false);
additemsAndcellWidgets();
setSortingEnabled(true);
sortItems(0, Qt::AscendingOrder);

This is my code at the moment, and it still has problems, so the "recommendation" you told me, I knew this already, and it doesn't help. It does help with the "initial" showing of the items, but once a user clicks the Header section to sort again, the bug reappears!!

Here's the code to reproduce now:


#include <QtGui>

int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QTableWidget* qt = new QTableWidget;
qt->verticalHeader()->setVisible(false);
qt->setRowCount(75);
qt->setColumnCount(2);
qt->setSortingEnabled(false);
/*qt->setSortingEnabled(true);
qt->sortItems(0, Qt::AscendingOrder);*/
QTableWidgetItem *__colItem = new QTableWidgetItem();
__colItem->setText(QApplication::translate("t", "test", 0, QApplication::UnicodeUTF8));
qt->setHorizontalHeaderItem(0, __colItem);
QTableWidgetItem* ax[75];
for(int i = 0; i < 75; i++){
ax[i] = new QTableWidgetItem(QString("Ebeeef%1").arg(i));
qt->setItem(i, 0, ax[i]);
qt->setCellWidget(ax[i]->row(), 0, new QPushButton(QString("Ebeeef%1").arg(i)));
}
qt->sortItems(0, Qt::AscendingOrder);
qt->setSortingEnabled(true);
qt->show();
return app.exec();
}


EDIT: I CHANGED THE CODE. Here's what I discovered:
1) If you do:
qt->setSortingEnabled(true);
qt->sortItems(0, Qt::AscendingOrder);
Your code will instantly show the missing buttons bug.
If you do:
qt->sortItems(0, Qt::AscendingOrder);
qt->setSortingEnabled(true);
Your code will only show the bug if you click the HEADERVIEW to sort again (eg. descending).
2) ax[i]->row(); doesn't make a difference.

Methedrine
12th June 2007, 00:46
They gave me a tracker ID: #166442, said they got it, but I dont see it on tasktracker, says that ID doesn't exist, and not sure if I explained it correctly.


Ok, I didn't find it yet either, but I'll give them a few more days.



This is my code at the moment, and it still has problems, so the "recommendation" you told me, I knew this already, and it doesn't help. It does help with the "initial" showing of the items, but once a user clicks the Header section to sort again, the bug reappears!!


Do setCellWidget before doing setCellItem and you'll notice that there is (at least in my case) only one button missing.

wysota
12th June 2007, 00:57
Hmm... for me the image seems to look fine (4.3rc1, based on the fact there was no rc2 I assume that's what became 4.3.0) ... Oh, and I corrected your code a bit :)


#include <QtGui>

int main(int argc, char *argv[])
{
QApplication app(argc, argv);
app.setStyle(QApplication::setStyle("Plastique")); // not related to bug prolly
QPushButton qb("Test");
qb.setFixedSize(62, 47);
//qb.setSizePolicy(QSizePolicy::Expanding, QSizePolicy::Expanding);
qb.setStyleSheet("border-image: url(test.png) 2;\
border-width: 2;");
qb.show();
return app.exec();
}

Just tell me... what's the point of using border-image if your button has a fixed size?


They gave me a tracker ID: #166442, said they got it, but I dont see it on tasktracker, says that ID doesn't exist, and not sure if I explained it correctly.

That's the autoreply email probably.

VireX
12th June 2007, 01:48
mm, try downloading 4.3.0 Mingw compiled version (make sure you're using Windows XP). Maybe difference is the mingw stuff?

I used border-image, because background-image on a pushbutton has more bugs.

I'm reporting this bug, it's definitely a bug...

wysota
12th June 2007, 08:57
Tough luck, I don't have WindowsXP. But look - now you are blaming the compiler :)


I used border-image, because background-image on a pushbutton has more bugs.
I didn't say anything about using background-image. By the way, what are these bugs you mention?


I'm reporting this bug, it's definitely a bug...
Lol... Be my guest although there is a chance they won't reproduce it either :)

high_flyer
12th June 2007, 10:01
I fully agree with Methedrine.
From the start, your tone is complaintative and arrogant.
I have used Qt since version 2.3, and came across things that MIGHT be bugs VERY seldom.
Qt is meanwhile a very mature kit, and the likelihood that you stumble on a bug (or so many as you claim) is highly unlikely, specially, since from your own code it is evident, that you are no C++ guru, and many trolls are.
So, first, my advice to you, change your attitude, it is not good for your blood pressure and ulcerous.
Second, a bug is only then a bug when you use a CORRECT code, in the way it was supposed to be used, and then the effect is not the documented/expected effect.
Since you did not provide such reproduced bug behaviour code, you can't claim bug, and only then you might claim it a bug, and even then you should use "maybe", and not that assertive and frankly irritating tone.

And - your tone is not in place even if you were fully right from the start.
As long as you are not paying for the product, there is no room for such complaintative tone.

Don't get me wrong.
Its not that we are not interested to know of new bugs - quite the contrary.
But instead of so many words and posts that actually bring nothing, just post a short post with bug description and example code, that reproduced what you think is a bug.
No need to use degrading and arrogant language.

VireX
12th June 2007, 18:55
Talking to me about arrogance when you are walking in here telling me that my code is wrong without even seeing my code? Then making assumptions on what kind of C++ Guru I am without ever meeting me before or reviewing tons of my code? Who's the arrogant know-it-all conclusion-jumper here?? Only you...

I used correct code, I didn't randomly type code that I pulled out of thin air, I look at examples in Qt and I use the documentation very well, so stop jumping to these silly childish conclusions that I'm arrogant or this or that, or that I'm just not good at C++ and other mean and disrespectful assumptions. I have not shown any of you any disrespect, and I've had about 200 posts, where I never claimed this was 100% a Qt bug, and I never even posted on TaskTracker before, and I always ask here first if I have a problem before I assume the worst, or else I wouldn't have made this silly thread which has had 0 results and full of nasty comments blaming me for bugs in Qt.

Now I have kept my attitude quite clean without resorting to disrespectful words such as "rude" "arrogant" or other insults that is quite childish.

I did provide reproduced bug, so you can stop typing your arrogant post and actually READ MY POSTS with an 8th grade comprehension level at least.

It seems like you guys are more interested in blaming me and acting like Qt is infallible rather than looking at this with an open mind that Qt may actually have bugs. I may not be a Qt Guru, but dont you dare make assumptions about my C++ skills since you truly do not know what my experience is. I used proper code that any logical person would think up by reading documents, examples, and asking on these forums, if my code is wrong, then so is half the people on this forum since I have had help from them for many things.

I have seen quite a few versions of Qt, and never has there been this many bugs that I can easily spot, and don't tell me the difference between a QT BUG and a bug that appears to be a Qt bug but is actually my own mistake, I've had plenty experience with both. I'm not some Qt coder that just started yesterday, I know the differences. I don't come on this forum and talk about Qt bugs unless I have exhausted every other option. I understand that 4.x.z, when z is rising there is usually less bugs, when x is rising there is usually more bugs because of new features and usual 'recoding' of old features. All I am doing as a duty is talking about these bugs and reporting them and confirming them, as any Qt programmer would.

Up to this point I have kept my tone quite mature, and attitude quite openminded, I have not blamed anyone except I have said that these are Qt bugs that could have been fixed in beta, and 4.2.3 worked and therefore why ruin 4.3.0? This is merely a calm suggestion not the exaggeration you are coughing out now. Stop demonizing me and my attitude it doesn't help anyone except make hate. If you truly believe it's not a bug, prove it by fixing it with my reproducable code, if you can't reproduce it, that's not my problem, but it does happen in my current state and if you can't reproduce the environment, doesn't mean the bug doesn't exist. Now stop blaming me, and instead fix the bug if you think I am THIS WRONG, instead of ranting.

From the start of this thread I have been treated as some "jumping-to-conclusions" "arrogant" and insistant newbie at Qt, because you see so many in your experience, but I am not making up these bugs i am truly right about them, as you can see no one can find a valid solution for them. I came here to confirm that you cannot find a valid solution for them, since I already tried every possible solution for many hours before I came here. If it was my mistake, I'm sure this thread would have ended in page 1.

Back on topic to Wysota's question:
background-image doesn't work well, not because of bugs, but because I have multiple push buttons with border-image etc, which override background-image and mess up my buttons. Also if you do pushbutton { background-image } it doesn't work for me, turns out a white plain button.

high_flyer
12th June 2007, 19:55
Your reaction in this post is totally out of proportion, IMHO.

Man.... chill out will you?
I was not putting you down (nietehr did anyone else here), I (and few others) was trying to tell you how at least to some of us, your text looks like, and that your attidude is counter productive - to you.

, I didn't randomly type code that I pulled out of thin air, I look at examples in Qt and I use the documentation very well
Thats is still no a guarantee for a bug free code.
And niether did the tolls (randomally type code out of thin air).

so stop jumping to these silly childish conclusions
your code was found faluty in previous posts on this thread, which actually should not have been based on what you say.
These are no conculsions, these are facts.
In addition, as wysota used your code and did not manage to reproduce at least one of your "bugs".
That alone dismisses it as a Qt bug. (see I did read your posts).
You claim that you explained the bug, and that no one here trys to reproduce it, but you fail your self to submit such code.
Is it really so hard for you to accept, that the only way this can be verfied as bug is buy reproducing it?
And is it so hard to accept, that peole will not sit and try to feadle with code and reproduce what you claim is a bug, whic you your self can't reproduce??
Ofcourse, the fact your code if faulty, does not mean you are wrong, but if we need to take guess about it, we would first think that your code is the problem and not Qt - which is why every one here is so eager to first make sure YOUR code is ok.
I do the same thing with my own code,and I stumbled on "real bugs" in Qt VERY seldom, which is why most here tend to think, that before claiming bug, your code should thoroughly br examined - its nothing personal, and you should not take so either.

As I said, if you think there is a bug, just post a bug report (as you meanwhile did).
End of story.
What is this this whole blame game good for?


but I am not making up these bugs i am truly right about them, as you can see no one can find a valid solution for them
That is because no one is able to reproduce them.


if you can't reproduce it, that's not my problem
Most probably it is, which is what you fail to understand.

Peace V:cool:

wysota
12th June 2007, 20:17
I used correct code,
Ok, let's assume we believe you and your code is correct and you're a great programmer who can write bugless code and complains about buggy Qt code. I suggest you just subclass QPushButton and reimplement the code responsible for causing the malfunction. You can probably also reimplement the sorting proxy code - there is probably one line of code which is incorrect. Finding that for a person with your skills should be a snap. You might also want to dig into Qt source code yourself and repair what has been broken by those jerky lame Trolls. Then you can send a patch to them and I'm sure they'll evaluate it and include in the next release. Hey, maybe they'll even hire you!



so stop jumping to these silly childish conclusions that I'm arrogant or this or that,
So stop behaving arrogant. For me one of the most arrogant things a programmer could say is that he doesn't make mistakes in his code. I have already found some in code you provided few posts earlier.


or that I'm just not good at C++ and other mean and disrespectful assumptions.
Nobody said anything about your C++ skills.


where I never claimed this was 100% a Qt bug,
Now you have :) You found (well, maybe that's not the best word for it, because you don't know where they are) about 10 bugs in Qt which gives an average of 1 bug per 20 posts. Not bad... I have found several bugs myself but my "bug per post" statistics are not so impressive.


which has had 0 results and full of nasty comments blaming me for bugs in Qt.
Nobody is blaming you for anything.


I did provide reproduced bug,
I can't reproduce your bug with border-image.


It seems like you guys are more interested in blaming me and acting like Qt is infallible rather than looking at this with an open mind that Qt may actually have bugs.
But we agree that Qt contains bugs. We're just not eagar to call every unexpected behaviour a bug.


I used proper code that any logical person would think up by reading documents,
We haven't seen your code in action and I don't think we're making any assumptions about it.


if my code is wrong, then so is half the people on this forum since I have had help from them for many things.
We don't say you can't write proper code, we only say to try to verify your code first before taking on 3rd party code.


I have seen quite a few versions of Qt, and never has there been this many bugs that I can easily spot
Obviously you haven't seen Qt 4.0.0 and 4.0.1 :)


All I am doing as a duty is talking about these bugs and reporting them and confirming them, as any Qt programmer would.
Let's summarize:
1. we agree that there is a problem with sorting the table containing cell widgets
2. we couldn't reproduce your border-image problem

Ad. 2. - I've been thinking a bit about it and came to a conclusion that your widget might have slightly different dimensions that you think and that is causing the distortion you're experiencing. You are using border-image in a wrong way - it was not meant for things you're using it for. You should use a custom style or background-image tag.



Back on topic to Wysota's question:
background-image doesn't work well, not because of bugs, but because I have multiple push buttons with border-image etc, which override background-image and mess up my buttons.
You are using both border-image and background-image at once? What for?


Also if you do pushbutton { background-image } it doesn't work for me, turns out a white plain button.
Could you provide a minimal compilable example reproducing the problem?

VireX
12th June 2007, 20:44
Ok ok, to settle your arguments, let me explain.

@high_flyer,
I reproduced the bug using sample code and posted it here, if you cannot reproduce it even though it happens in my computers, I'm not blaming you for not being able to code, I'm just saying you failed to set up the current environment with which i cannot help you with.
-Nobody found any mistake in my code, as this Qt task tracker can explain that this is a bug , and I submitted new code based off of Jacek's correction (which in fact did not correct the problem): http://trolltech.com/developer/task-tracker/index_html?method=entry&id=166714
-Anyone with my environment and my code can reproduce the bug with the code I gave them, including many of my friends. As wysota himself said he used RC1, which may not have the distortion in it.
-People can reproduce these bugs, and cannot find a solution, as we are not going to change the Qt source code on how it renders border-image, and dont feel it is necessary to override sortItems function.

@wysota:
I am not behaving arrogant, I never said my code is always perfect, but in this case it is not my code that is causing the problems, as you can see yourself, the code I used was pretty much OK aside from the fact of "setFixedSize" instead of the QtDesigner code "setMinimumSize and setMaximumSize".
-you can't reproduce my bug, because you are not using Windows XP with mingw and 4.3.0... Doesn't mean the bug doesn't exist, or that 10 other people can't reproduce it.
-you have seen my code in action.
-yes i haven't seen 4.0.0.0, sorry, I wasn't around back then, but for 3-4 versions 4.3.0 seems to have the most bugs.

1. we agree the bug is in cellWidgets, as expressed by http://trolltech.com/developer/task-tracker/index_html?method=entry&id=166714
2. We agree there is a border-image problem, since a couple people have reproduced it, and you're right as a Qt Developer himself told me in email that I should not use border-image for that purpose anymore as of 4.3.0, even though it was in the QtStylesheet example program, and instead I should use background-image, which I told you doesn't work, and Qt developer explained that you have to use background image like so or my image wont appear!!!:
background-image: url(test.png);
border: none;
I didn't know about border:none;

So that explains the border-image bug as well, they just fixed it so border-image doesn't fill content anymore, and its true, but it would have been helpful to know about border:none; before hand.

Only problem now is my images repeat rather than stretch, border-image in Qt 4.2.3 was best, I dont know why it needed a difference as this... border-image you would put on any widget and it would stretch it and fit itself appropriately now I have to use background-image and background-image just repeats the image it doesn't stretch, so now i got buttons that like like this: [ ] [ ] [ ] instead of [_______]

wysota
12th June 2007, 21:15
but in this case it is not my code that is causing the problems, as you can see yourself,
The problem is I can't see it for myself because you didn't provide the code that reproduces the problem.


the code I used was pretty much OK aside from the fact of "setFixedSize" instead of the QtDesigner code "setMinimumSize and setMaximumSize".
No, it wasn't :)


-you can't reproduce my bug, because you are not using Windows XP with mingw and 4.3.0
Oh come on! Your blaming compiler differences for such things? Don't be silly, I'm using the exactly same compiler, only on a different operating system. Compiler won't suddenly start causing distortions in images, especially if it didn't cause them before.


... Doesn't mean the bug doesn't exist, or that 10 other people can't reproduce it.
So far nobody said he/she reproduced it.


-you have seen my code in action.
No, I haven't. The code you provided is not the one that generated those images. And you have seen your (and my) code in action as well and it works exactly the same under 4.2 and 4.3 - it stretches the image in both of these versions.


yes i haven't seen 4.0.0.0, sorry, I wasn't around back then, but for 3-4 versions 4.3.0 seems to have the most bugs.
4.3.0 - 190 bugs found
4.3rc1 - 118 bugs found
4.2.3 - 305 bugs found
4.2.2 - 648 bugs found
4.2.1 - 324 bugs found
4.2.0 - 354 bugs found
4.1.5 - 18 bugs found
4.1.4 - 313 bugs found
4.1.3 - 294 bugs found
4.1.2 - 306 bugs found
4.1.1 - 283 bugs found
4.1.0 - 577 bugs found
4.0.1 - 637 bugs found
4.0.0 - 436 bugs found

Care to comment?

By the way, please note how it agrees with what was already said - the lower the revision number, the more bugs found. You said you agree with that statement but now you say 4.3.0 has the most bugs since 3-4 releases (so since circa 4.2.1) - of course it will have the most bugs found! It has the lowest possible revision number! But compared to other "0" revisions, it looks pretty good.


2. We agree there is a border-image problem, since a couple people have reproduced it,
The problem is you are using it incorrectly...


and you're right as a Qt Developer himself told me in email that I should not use border-image for that purpose anymore as of 4.3.0, even though it was in the QtStylesheet example program,
Yes! That's what we're trying to tell you since the very beginning - you were relying on an incorrectly implemented feature and now that it has been corrected your code that is using it started malfunctioning.


and instead I should use background-image, which I told you doesn't work,
Sure it works. You just didn't know how to use it. Qt documentation about style sheets is still immature and it's mentioned a couple of times in different resources.


I didn't know about border:none;
So you admit your code was not correct? (I start sounding like Jacek)


So that explains the border-image bug as well, they just fixed it so border-image doesn't fill content anymore, and its true, but it would have been helpful to know about border:none; before hand.
Sure it would. So after all there is no border-image and no background-image bug, right?


Only problem now is my images repeat rather than stretch,
Did you tell them to stretch using background-repeat or simmilar?


border-image in Qt 4.2.3 was best, I dont know why it needed a difference as this...
Because it was not working the way it should. It should work according to what CSS says and not according to your or Trolltech liking. That's what is called following the standard.


border-image you would put on any widget and it would stretch it and fit itself appropriately
Border image is for providing borders made from images, not providing background made from images.

VireX
12th June 2007, 23:46
But background-image is still bugged, I programmed in CSS for years before getting into programming, they dont use border:none; to display the image, this is indeed an odd feature of trolltech not a standard of CSS.

Now I have no way to stretch the image so that it looks like border-image in 4.2.3.
Since border-image was used in 4.2.3 I assumed my code was correct, and indeed it was correct for 4.2.3, this still is not my faulty code, because they suddenly changed it in 4.3.0 without any warnings.

4.3.0 has the least bugs because its only like 12 days old, what did you expect? Wait about a month and you'll see it will surpass all the previous versions.

I was not using border-image incorrectly according to Qt and Trolltech at v4.3.0, I was using it incorrectly according to CSS standard yes, but since it worked in 4.2.3, I decided to stick with it, no one said "we're changing border-image in 4.3.0 so you're gonna have to remove many of your border-image and replace with background-image". In fact Stylesheet example still uses border-image, so stop saying I have incorrect code.

I am not blaming compiler differences, I'm blaming environment differences. That code has reproduced the pixelation bug in several people's Qt compilers. Not yours because you have a DIFFERENT VERSION OF QT and a DIFFERENT OPERATING SYSTEM, how can you possibly say that Qt reacts exactly the same in all situations. Use my environment, since your profile says you do have Windows XP, meaning you probably can replicate my bug. Till then, dont argue with me, until you proven me wrong about the bug. I'm not here lying to you, I didn't produce that image out of thin air, I am not a liar as you claim.

It's like you're afraid to admit that border-image is rendered differently between 4.2.3 and 4.3.0, just try it in my environment, and you will see you are wrong.

"OK aside from the fact of "setFixedSize" instead of the QtDesigner code "setMinimumSize and setMaximumSize"." ---- "No it wasn't"
NO, it was, you said "oh btw i fixed your code" and thats all you changed. The code is fine, it works fine in 4.2.3, it renders border-image differently in 4.3.0 because of standardization. Simple logic man.

So what would be your solution to [ ] to [___________] for a big button? Because background-image doesn't stretch accordingly to the size of the button.

magland
13th June 2007, 00:39
Looks like this thread has stopped being about the identifying/solving bugs (if it ever was) and has turned into an issue of
(a) whether or not Qt 4.3.0 is really buggy
(b) whether or not VireX is a competant programmer, and is being treated fairly

Its good entertainment, but I think most would agree that nothing is contructive is likely to come. If these are important bugs, others will I'm sure post them in a more constructive and respectful manner, giving due appreciation for the volunteers who contribute their time to make this site a reliable source for good Qt help. :)

For example, macbeth recently asked a question about a possible clipping problem in 4.3.0, and provided a very helpful test program... it will, I'm sure, lead to a constructive solution.

JM

wysota
13th June 2007, 00:42
But background-image is still bugged
It's not bugged. I could agree that it's not very mature, but certainly not bugged. At least not based on what you have just written.


I programmed in CSS for years before getting into programming, they dont use border:none; to display the image, this is indeed an odd feature of trolltech not a standard of CSS.
Correct me if I'm wrong, but in most cases "none" is a default value for "border" property in CSS. Qt behaves differently than CSS for HTML, because it handles something quite different so you can't expect everything to work exactly the same. This is relatively new technology and it's probably the only toolkit supporting such an approach. It has to take some time to make every aspect work. I could point many much more annoying "features" in QSS than the necessity to use border: none;


Now I have no way to stretch the image so that it looks like border-image in 4.2.3.
Why do you want to stretch an image for a fixed size button?


Since border-image was used in 4.2.3 I assumed my code was correct
Yes, we know you did. That's what we told you at the very beginning.


and indeed it was correct for 4.2.3
No, it was just working. If I do:

QString str = "xxx";
char *ptr = str.toByteArray().data();
printf("%s\n", ptr);
it will work, but it won't be correct. It makes use of an unreliable assumption that nothing will overwrite the memory containing the char * data between two last lines of the above code. But if something DOES overwrite it (for example when using threads or having many very busy processes or just having bad luck), it will break.


this still is not my faulty code, because they suddenly changed it in 4.3.0 without any warnings.
I'm almost sure the changelog lists that "border-image" has been fixed. Would you expect a big message "Hey all you people who use border-image in an incorrect way - you code might break in 4.3 because we fixed that nasty bug in border-image causing blablabla..."?


4.3.0 has the least bugs because its only like 12 days old, what did you expect?
I expected you to bring up that argument and you did :) Most bugs are reported at the very beginning, that's one thing and the other is that the number of reported bugs should be calculated relatively to amount of new code in the product in question. That's why "0" revisions have the most bugs - they introduce the most new features. I don't expect Qt 4.3 to be in any way different from 4.2.2, 4.2.0 and 4.1.0 - they all introduced new features and they have the most bugs. But I doubt 4.3.0 will have more bugs reported than 4.2.2 :)



Wait about a month and you'll see it will surpass all the previous versions.
I'm pretty sure it won't, especially that summer holidays are coming and people won't write as much code as during the rest of the year thus they will not be reporting problems. I also assume Trolltech will want to release a new (fixed) version of Qt before DevDays, so some of the bugs will be discovered in 4.3.1 or later.


I was not using border-image incorrectly according to Qt and Trolltech at v4.3.0
You were using it incorrectly. The property is to supply borders and scalable centre and that's exactly what it does.


I was using it incorrectly according to CSS standard yes, but since it worked in 4.2.3, I decided to stick with it, no one said "we're changing border-image in 4.3.0 so you're gonna have to remove many of your border-image and replace with background-image".
True. And no one said "don't use QPrinter to bake muffins". Why would anyone have to warn you about using code that simply doesn't fit to what you do?


In fact Stylesheet example still uses border-image, so stop saying I have incorrect code.
You have incorrect code and the stylesheet example is old and buggy. It will be replaced with a new one - Trolls are already working on that. And hey! somehow I know about it even though I didn't cry "Stylesheet example is buggy!". Trolltech has some channels of communication with its clients and users. If you don't use them, don't blame Trolls for that.


I am not blaming compiler differences, I'm blaming environment differences.
Like what differences?


That code has reproduced the pixelation bug in several people's Qt compilers. Not yours because you have a DIFFERENT VERSION OF QT
Nope :)


and a DIFFERENT OPERATING SYSTEM
So? You think there are any platform dependent issues involved in border-image?
Take a look at src/gui/styles/qstylesheetstyle.cpp at methods cutBorderImage() and drawBorderImage() and tell me which parts of code may be influenced by the operating system or the compiler or any other "environment" difference. The only thing that might be influencing my system is that my version of Qt could have been patched before being packaged. But I don't think this is the case.

The only thing that might have influence is the one I tried to explained a few posts before.


how can you possibly say that Qt reacts exactly the same in all situations.
Because I read its source code when I want to learn how it works


Use my environment, since your profile says you do have Windows XP,
No, my profile doesn't say anything about Windows XP. It says "Windows", not "Windows XP".


Till then, dont argue with me, until you proven me wrong about the bug.
But there is no bug... I thought we agreed to that :) You were using border-image incorrectly.


I am not a liar as you claim.
Hmm... where do I claim such things?


It's like you're afraid to admit that border-image is rendered differently between 4.2.3 and 4.3.0
I admit, border-image may be rendered differently in 4.2 and 4.3. But it's not a bug in 4.3 but in 4.2.



NO, it was, you said "oh btw i fixed your code" and thats all you changed.
No, you were using a dialog that contained the widget. Do you see that in my code?


The code is fine, it works fine in 4.2.3,
Please understand - if something works, it does not automatically mean "it's fine".


So what would be your solution to [ ] to [___________] for a big button? Because background-image doesn't stretch accordingly to the size of the button.
In general it depends what the button looks like. I'd probably use border-image with a nice scalable or repeatable centre part or a gradient using brand new Qt 4.3 features. The image you used in your example won't work, because it neither scales nor repeats itself. If I were to use such a complicated shape, I'd implement my own style and/or draw it using QPainter.

BTW. Thanks for a great flame war... eeem... discussion. I already feel fresh blood flowing through my veins.

jacek
13th June 2007, 01:01
I'm not here lying to you, I didn't produce that image out of thin air, I am not a liar as you claim.
You are first to use that word here. There's really no reason for being so emotional about few bugs.

VireX
13th June 2007, 08:37
There's no reason to assume I have incorrect code and argue semantics, when my code follows the documents and examples produced by Qt themselves.

And you implied I was lying when you kept saying "you cant reproduce the bug" etc. Anyone with the code I posted can reproduce the border-image BUG. It is a bug, because it's a bad way to render border-image. It worked better in 4.2.3, and if anyone argues otherwise, then I can counter-argue by saying we don't need border:none; for background-image since thats not a CSS standard either. Why does Qt even need to standardize to CSS? I would want a better type of type like : stretch-image: or something, something I can use as in 4.2.3.

You're telling me now I have to do 10x more work to get the same thing, such as overriding styles etc... Really silly stuff.

You also say "why do you need stretching for one fixed button?" no I have hundreds of buttons that are all different shapes and sizes, and border-image is the only way to do it. Now I can't fix my skin, what would you do? And please don't tell me a complex solution as "overriding this or that" without some sort of example code, because I feel that is unnecessary to go from one line of CSS code to 30 lines of C++.

I'm glad I got your blood flowing, maybe it helps your blood pressure a bit and brings fresh life into your organs :).

wysota
13th June 2007, 08:57
I rest my case. Do what you want... I have better things to do than to convince you that a fix is not a bug. I'm not telling you anything, you don't have to do anything. You can keep crying your code needs changes. If you're willing to pay for it, I'm sure someone will correct the code for you.

VireX
13th June 2007, 09:29
And I rest my case...
I came here for help, I told you my theory that it's a bug, you told me it was not a bug but instead my faulty coding, then I showed you the reproducable code, you told me I was using it wrong, when it works in 4.2.3, and explaining to me what a fix is etc, when I know what you're talking about, I know they recoded it to what "they see is best", but I dont care, I don't think any Qt developer would want border-image changed from 4.2.3's nice stretchy images, to 4.3.0's crappy literal border-images. background-image is not sufficient for the job, neither is any other CSS feature. by disabling border-image's uniqueness, you're just taking away features rather than standardizing. Standardizing doesn't mean you should downgrade so that you can fit OLD CSS's standardization.

I showed you reproducable code, and you replied saying you can't reproduce it, since you have a different version and different environment. Well the point is, I can reproduce it, if I can reproduce it, and everyone can see it, the bug does exist. Example I once had a program that would work in Windows XP, and not work well in Windows 98 and ME, I couldn't figure out why, then I finally found out that the packer I was using disabled support for 98/ME, but there was only one guy complaining about it out of 1000s ? So does that mean the bug didn't exist, that it was just "that guys problem"?

I am not trying to trick you here, or find bugs that don't exist, or show you fake screenshots. The bug is real. Once I have proven that, now you said, it's not a bug, it's a fix. Ok fixes mean BETTER not WORSE. I don't care what you're standardizing to, if a fix makes an OK feature worse, in other words, disadvantage rather than advantage, then why bother fixing it as such?

That's like saying to a guy "hey i invented the machine gun", and someone going "no, the single rifle is the standard to the army, we can't just switch to this machine gun, it would ruin warfare, and its expensive, and bulky, and it just wont work well with our army, you should downgrade and standardize to us."... And in fact generals did say this when the machine gun first came out. Guess what, that standardization rule was overruled and machine guns were used.

The point is, I don't care if its a fix or a bug, but to me, it's a bug because it has a negative effect rather than a positive one. You tell me, that my code is wrong, because I use border-image on something that isn't a border, Ok maybe you're right, but you offer no alternative situation, you mentioned background-image, well background-image is WEAK and doesn't work. You mentioned something like Style this or that, or override this or that, well why would I spend hours trying to get this to work, when it was so easy in 4.2.3, I think it's more advantegous to downgrade to 4.2.3 then.

Put yourself in my shoes for once, I have spent hours trying to figure out a way around this, there is no way, and it's all because some Qt developer though "hey well let's standardize so that our features are worse but at least it can follow CSS guidelines now"... They never offered a solution for this problem. No one has, offered a simple solution to this. Well I guess the only excuse now is "why would you want to make oval buttons?".

The point of fixes is to become better, the point of criticism of bugs is to fix the bugs and make better features. This happens everywhere. And even If I say "ok, forget it, 4.3.0 has a better border-image feature", someone else will come and argue otherwise, who has the same situation.

I have no clue why you cant reproduce the bug, but it exists, and the Qt developer can reproduce it, so obviously you have some fault here too.

high_flyer
13th June 2007, 10:29
I know I shouldn't, but here goes...

And I rest my case...
A case without evidence is no case. (if we are using the court of law language)

I came here for help, I told you my theory that it's a bug,
Well this sentence sums up your problem.
What help did you expect if the bug is indeed in Qt?
Only the trolls can help with that.
So as said here many times already, just fill a bug report, and go happy about your way, no need to get so worked up about it.

And you are correct - you came with a theory about a bug.
Bugs are like a crime, and the author is innocent until proved guilty.
Theory proves nothing.
And there is only one way to prove a bug, and that is by reproducing it.
And just like in criminal law, the burden of proof lies on the side of the complainant - in this case you.
The evidence is the code that YOU have to supply that when we (or any one else) runs it, the bug will be visible.
You failed to do that (the ones who did run your code didn't experience any bugs), and even the code you did supply, was practically "squeezed" out of you, not before the 9th!!! post - which actually should have been supplied by you in the first post!
It really doesn't matter why the bug is not reproduced by us, the fact it is not, is what is important. (assuming we are using the said Qt version of course).


if a fix makes an OK feature worse, in other words, disadvantage rather than advantage, then why bother fixing it as such?
Let me put it this way:
What you used at first was a bug, that you used as a feature.
When the bug was fixed, the code relying on the bug stopped working.
You saw it as an advantage, by misusing a bug.
But that does not make the (original) bug a feature, even if you managed to use it in a (to you) helpful way.
The fact you actually managed to use bug as a feature, (as was told to you by the trolls ) was a misuse of the code, and is probably due to you misunderstanding the way it should actually work, as it does after the fix.


Put yourself in my shoes for once
We were and will be in your shoes many times.
Each time we have code that does not do what we expect, there is a little thought behind the head that says - "it must be a Qt bug".
But as I said in my previous posts, a careful examination of our own code usually reveals it is our mistake not Qt's.
So we all know exactly what you are going through.


so obviously you have some fault here too.
Obviously.

wysota
13th June 2007, 10:32
If you want specific help, ask specific questions. If you want help with specific buttons, ask questions about specific buttons, providing mockups if possible. We won't be guessing what kind of buttons you have in your application. I gave you a general answer for a general question - you didn't like it and that's your choice.

About what you have written above - you didn't say any theories, you just expressed accusations. I won't comment the rest, I don't see a point in starting the discussion all over again. Just please don't be so certain everybody else thinks the same you think or writes code the same way you do. I can understand the current behaviour is not what you expect, but don't assume everybody else is using border-image for the things you're using it. In particular I want border-image to work as it should and have some other tag or property or whatever that does something else (I'm sure it's just a matter of time before "stretch" is added to background-repeat or some simmilar tag).

VireX
13th June 2007, 16:19
There is no way, that anyone who uses Qt 4.3.0, and my code, and my image, cannot reproduce the bug. There is just no way code can randomly create bugs in my computer and not do it in yours, as you said "how does operating system make a difference?" So then why do I get it and you don't. If I get it, at least 1000 other Qt programmers get it as well simple as that.

Qt Stylesheet example is written that way, granted it's old code, but I'm sure a 1000 other people used border-image the way i used it, by simply looking at a Qt example. By removing the "bug" and fixing it so that it doesn't stretch properly anymore, then you're saying that it's ok to upset 1000 coders to satisfy another 1000 coders who use border-image the correct way, without making an extra feature to make both the 1000 coders happy.

I told you specifics, but I can't make a list of my buttons and their sizes, all I can tell you is they are different widths, and the only way to add an image to a button without knowing its size so that it automatically stretches, is to use border-image. I have not seen a specific example of this done anywhere except in Qt Stylesheet example, so I ask now, if it's a feature no one uses, then how do people skin buttons? You can't skin buttons without a border-image feature that stretches images for you.

This means any developer that switches to 4.3.0, that has skin buttons has to now find some way to fix it, and this "way" is undocumented and not taught to anyone.

wysota
13th June 2007, 17:49
If you use border-image the proper way (i.e. with proper images), you'll get a proper result. And if you don't want to tell more about your buttons, I'm sorry but I won't be able to help you, I'm not a seer.

Brandybuck
13th June 2007, 17:53
When you make a program with 1000s of lines of code, and then switch to 4.3.0 to find half your code broken, anyone with a brain would consider this a bug in 4.3.0 not a bug in 4.2.3. If it worked by chance, why would they need to fix it?
I do not know the new CSS stuff, so I cannot comment on this bug. But I can recount numerous instances where a new release of a library revealed bugs that I myself created. To assume that all bugs come from someone else is very egotistical.

Just this week I discovered two bugs when rebuilding an application with 4.3.0. One bug was Trolltech's, and I logged it. But the other bug was definitely mine. I was making an erroneous assumption regarding 4.2.3 behavior.

Jimmy2775
13th June 2007, 18:52
...And no one said "don't use QPrinter to bake muffins"...

This thread has been dramatic, entertaining and somewhat educational, but for some reason that line just killed me. :D

croland
13th June 2007, 19:20
Hey maybe the image is bad :p

Thanks everyone for the thread. I'm going to use images for a resizable button in a product soon and I can make sure I use the 4.3.0 approach.

I love that line too Jimmy :). Wysota can I use as my sig?

wysota
13th June 2007, 19:44
Wysota can I use as my sig?

Sure. I can give it into public domain :)

mm78
13th June 2007, 20:37
Qt Stylesheet example is written that way, granted it's old code, but I'm sure a 1000 other people used border-image the way i used it, by simply looking at a Qt example. By removing the "bug" and fixing it so that it doesn't stretch properly anymore, then you're saying that it's ok to upset 1000 coders to satisfy another 1000 coders who use border-image the correct way, without making an extra feature to make both the 1000 coders happy.

Others have already told you what I'm about to tell you, but I'll tell you anyway. Seems like it can't be repeated enough (and I will repeat a lot).

It wasn't a "bug", it was a bug! A real one. Much more real that the bug you're claiming. Believe it or not: the border-image didn't stretch correctly in 4.2.3, but it does in 4.3.0.

People who used border-image for what it was intended for, which is to provide a border image, got bad results in 4.2.3 because the image was stretched incorrectly. The corners were hideous, and people all around the world were very unhappy.

The border-image property was never intended to be used to set a background image. That's what background-image is for. Unfortunately for you background-image doesn't do what you want it to do, but that doesn't prove that the 4.3.0 behaviour of border-image is wrong. Once again: border-image was broken in 4.2.3 and it was fixed in 4.3.0. Fixing this was the correct thing to do.

Everyone who use border-image for what it is intended for, which is to provide borders without repulsive corners, are now happy because the corners are no longer looking nasty. Everyone who depend on the border-image bug in 4.2.3 as a hack to get stretched backgrounds are unhappy, but seriously, and please be honest now, do you really think that Trolltech should keep bugs in Qt so that people who are depending on these bugs will stay happy? Shouldn't they fix the bugs so that everyone who uses the feature for what it is intended for will be happy?

Your problem isn't that border-image don't stretch any more. Your problem is that background-image don't stretch. It never did and that is why you did your border-image hack in the first place. Let me repeat: the problem you are experiencing now is caused by a hack, this hack depends on a bug in 4.2.3, the hack was written by you and it's located in your code! It worked with 4.2.3, but it doesn't work with 4.3.0 and that's something you simply have to accept.

Now there are several alternatives for how you can handle this, but considering your rejection of the suggestions you already got from others I won't tell you unless you ask.

And just for curiosity: did you report this to Trolltech yet? If they tell you that this indeed is a bug and that border-image will be changed to stretch the image for 4.3.1, complete with appalling corners and everything, I'll not only eat my hat, but I'll also help you with building all future beta versions of Qt so that you can find the bugs and report them to Trolltech before the final releases.

Good day.

(Edit: the f-word replaced with something milder)

marcel
13th June 2007, 20:43
People who used border-image for what it was intended for, which is to provide a border image, got bad results in 4.2.3 because the image stretched. The corners got fucked up. They were very unhappy.
:) Oh yeah. You mean the corners were "nasty"?
This is my first post in this thread...

I'm really curious what will happen next. This is like a miniseries.

Another thing: does this mean we can use the f word regularly from now on?

EDIT: Looks like we can say it after all, but only if we are really mad: http://www.qtcentre.org/forum/f-qt-programming-2/t-a-text-editor-with-line-numbers-174.html/?highlight=fuck

wysota
13th June 2007, 22:03
:) Oh yeah. You mean the corners were "nasty"?

Another thing: does this mean we can use the f word regularly from now on?

We don't do any censoring but the rules of good behaviour and personal culture suggest you shouldn't. I was even thinking about asking the author of those words to use kinder words next time, but I'm a little fed up with this thread. I'm reading few others that are really interesting and making up strange parallels about flying planes on the ground. I think I'll even post something to my blog... (yeah! a short remark about my private site! Maybe someone finally comes to visit it!)


EDIT: Looks like we can say it after all, but only if we are really mad: http://www.qtcentre.org/forum/f-qt-programming-2/t-a-text-editor-with-line-numbers-174.html/?highlight=fuck

Please don't :)

high_flyer
13th June 2007, 23:31
Maybe someone finally comes to visit it
I read it from time to time :) (when I have the time)

mm78
13th June 2007, 23:42
Can you verify that the following code gives you what you want?


#include <QtGui>

int main(int argc, char *argv[])
{
QApplication app(argc, argv);
app.setStyle(QApplication::setStyle("Plastique")); // not related to bug prolly
QDialog* qddd;
qddd = new QDialog;
QPushButton* qb = new QPushButton("Test", qddd);

// Changed these three lines
qb->setMinimumSize(QSize(66, 47));
qb->setMaximumSize(QSize(66, 47));
qb->setStyleSheet("border-image: url(test.png) 0 0 0 0 stretch; border-width: 2;");

qddd->show();
return app.exec();
}


Works like a charm with Qt 4.3.0 on my Linux box.

All I did was read the Qt 4.3.0 Documentation (http://doc.trolltech.com/4.3/stylesheet.html#list-of-properties) and follow the link to the CSS Draft Specification (http://www.w3.org/TR/css3-background/#the-border-image) for details.

Note that this code is still using border-image, so it's still not the correct thing even if it works. It can break in the future. The correct code would use background-image in combination with background-size. Check the CSS Specification for details. Unfortunately Qt 4.3.0 (nor 4.2.3) doesn't support the background-size property (yet). This you can report to Trolltech as a feature suggestion and they might add support for it in the future.

Note that because of the border-width property I've added 4px to the image width and height. If you shrink the button smaller than this size it won't look nice. I'm sure the same is the case with Qt 4.2.3.

I hope this makes up for using the f-word in an earlier post. :rolleyes:

VireX
14th June 2007, 00:14
Thank you so much mm78, for providing a solution. Although those settings don't quite work for me, they are basically the same method I used to fix the problem.

But before your post I have figured out one solution, instead of using border-image hack in 4.2.3, I will now use border-image hack in 4.3.0... border-image "hack/bug" still works, only thing you have to do is play with the border-width a little bit to get the correct fitting border on the background image.

Qt Trolltech didn't say border-image was a bug in 4.2.3 NOR 4.3.0, just a matter of fixing up 4.3.0 so that it works better, the developer told me to use background-image, which was a pathetic substitute for the great border-image. But I will definitely wait quite a while before I upgrade to 4.3.1 >_<, unless something draws me in like 4.3.0 did, and I will definitely make sure any CSS changes are precisely studied before I "switch" again.

mm78
14th June 2007, 00:22
In which way don't they work?

The four zeroes in:


qb->setStyleSheet("border-image: url(test.png) 0 0 0 0 stretch; border-width: 2;");

circumvents the "cutting in 9 and scale the centre" feature by defining the whole image as the centre. Unless you do this I suspect you can fiddle as much as you want with the image size and borders, but nonetheless the image will be cut in 9 and stretched in a way you don't want it to be stretched in.

There is nothing pathetic about background-image, and as earlier said it's the correct thing. The real problem here is the missing support for background-size in Qt. Read the CSS spec!

VireX
14th June 2007, 02:26
Yeah, I understand what you were trying to do, but when I tried it, it didn't quite work out the way i wanted :S, but putting 12 stretch; made it work... I use to have 3 stretch; in 4.2.3

VireX
19th June 2007, 23:50
I apologize for reviving this old thread, but I wanted to apologize for the arguments.

Border-Image bug (http://trolltech.com/developer/task-tracker/index_html?id=167466)

mm78
20th June 2007, 22:05
Sweet, just but be aware that the image will still be cut into nine parts and stretched appropriately if necessary, so how your buttons end up looking depends on the image and the numbers you provide to border-image and border-width, and how you scale your buttons.

I suggest you download the latest 4.3.1 snapshot and try it yourself. I also suggest you read this (http://www.w3.org/TR/css3-background/#the-border-image) if you didn't already.