> Basically it is about if you want to have a pen width in model or paint > device coordinates. Both use cases exist and IMHO none of them is more > important than the other.
Agree on the importance on both but the inconsistency applies in both use cases. >> Most likely no more than setRenderHint(Qt::CosmeticDefaultPen, >> true). > > As long as you don't eliminate this flag I agree for Qwt. Yes the flag is essential to the change. But I think it is debatable if we should maintain compatibility with explicit pen size of 0. On the other hand any app that explicitly set size 0 is deliberately asking for a cosmetic pen since otherwise it would seem pretty silly. But the current behaviour makes it impossible to animate pen thickness from 1 to 0 right now. > But I would have to write a lot of documentation, that pens set from the > application code will be handled in Qwt differently than the user is used > from other parts of the application. Right now we actually have this situation: QPen pen; // cosmetic, black 1 pixel pen.setWith(2); // magically makes it non cosmetic, black 2 pixel pen.setCosmetic(true); // back to cosmetic for real now So with introducing the explicit flag we mentioned above, you wouldn't have to deal with this inconsistency in Qwt any more. Right we we don't have this option at all when dealing with cosmetic pens so from a documentation perspective I think it would be easier than the current solution. >> In fact all non-0 values for pen >> width are non-cosmetic by default so making only the default constructor >> a special case with a cosmetic pen of size 1 is arbitrary and confusing >> regardless if you are using a cosmetic pen or not in your application. > > Yes it is and I've seen several situations where this leaded to > irritations - but this is how it is like many versions of Qt. > If it were about introducing a new API I would completely agree, but your > suggestion breaks many applications doing graphics. And worst of all it > is about introducing a type of bug QA departments usually never finds > ( not very likely than someone loads and zooms the exported PDF document > in a PDF viewer ). We will certainly not introduce a new QPainter-like API again, that is pretty certain so we are stuck with improving on what we have. (unless you count the canvas API in qt5) I still think it is worth updating the few issues that are broken when we are doing a new major version of Qt and we are already looking into changing some of the other inconsistencies in QPainter. After all what is the point of doing a major version unless we don't even allow ourselves to change broken defaults. Changing this in a minor release is obviously not going to happen so its either now or never. If the change is documented properly I think it is worth it. But this it is obviously still up for discussion. > I never spent time on further explorations, but if it is still this way > and the cosmetic attribute was the reason you might introduce a > performance issues with changing the default setting as well. I will leave that question for the graphics guys. I find it really strange that the performance impact of this would be significant and doubt that this is currently the case but I could easily be mistaking. Jens _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
