Re: [Development] Revisiting high-DPI configuration options
Hello, Everyone and Thiago. >> SVG icons are not shown at all in static builds of Qt, but png icons are >> fine (both icons are taken from resorse file). Static and shred Qt 5.6.1 >> build were done with same config settings except of cause "static". > Remember to force the inclusion of the svg icon plugin into your application. This seems a valuable advise which worked for me. I finally found how to do this, In pro-file add: QTPLUGIN *= qsvg Without this svg icons just do not render SILENTLY (in "static"). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QtMultimedia] Still is supported, active?
Hello, Everyone. > If you want this bug fixed, or to improve the QtMM quality there are far > better ways: > - Get a Qt support license from the Qt Company and raise the issue > to them. They very often help raising important customer issues like > this one to P1 since in the end, it's that money that pays Qt Company > developers. > - Try to fix the issue yourself. You already did more than many > users by bisecting the issue, thanks for that. But if this issue is > really a showstopper like you say, it can't be that Yoan is the only > person in the world that can and would be willing to fix it. > - Hire somebody to fix the bug. We at Woboq can help fixing nasty > issues like those in a very reasonable timeframe, KDAB does so as well. Here is also one important detail. If Denis need to decide to hire someone he need information about plans of fixing the bug. If he need to wait 1/2 year to get estimation that this bug is not going to be fixed in nearest months this can make him piss off. Easy imaginable! If "Fix Version" is filled by Yoann Lopes 6 months ago then he will get this estimation and can decide to hire Woboq or someone else to fix or whatever. Currently he is in "floating"/unstable/non-informative situation. So less reasons to act smart and more food for emotional letters. If this situation looks fine for maintainers then there is no sense in shutting up Denis. What to expect? People cry/insult if it hurts and no one listen. So predictable! Maintainers need to think about bug-reporters ALSO ... and keep bug-reporters in stable state. Imagine if for this bug "Fix Version" was filled with "Qt 6.0" then Denis Shienkov will get estimation of what waits him. And he can act. If for some reasons this estimation will be changed by maintainer to let's say 6.5 (or 5.10) then bug-reporter will send email notification to Denis about change of attitude to the bug he care about. Easy! So IMHO here we have violation of Best Practices of bug-tracking from maintainer and emotional angry-letter as the result of 1/2 year influence of this violation on bug-reporter. Simple! That is why I propose to create query in bug-tracker which will show up such violations. This is not about fixing bugs ... this is about respecting from maintainer’s side the bug-tracker fields which need to be filled and which influences bug-reporters. Just fill 3 fields. Done! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QtMultimedia] Still is supported, active?
Hello, Everyone. >> So while I agree that angriness is not helpful for mail list ... messages >> like this >> are probably the seed to rethink strategy of working with bugs. > Somewhat a side remark, but the unfortunate consequence of this thinking is > that the objectively best way to get a lot of Qt developers interested in your > problem is to write e-mails that breach of etiquette (to put it mildly). This will NOT ever be a result (unfortunate consequence) of such thinking. And this is again about details. Proposed reaction is NOT about fixing Denis's bug. Proposed improvements probably will not help with exactly this bug ever as this is more about maintainer's work. Because if fixing start to be a result of insulting in emails/mailinglist ... then mailinglist became in majority "insulting platform" Improvement is for making bug-tracking better is sense of giving less reasons for bug-reporters in general to ever write such letters. And as result will be lower insulting ... and NOT like you have said > "objectively best way to get a lot of Qt developers interested in your > problem is to write e-mails that breach of etiquette" ... we always meet this devil in details. Predictable "unfortunate consequence" of not improving will be more such letters (IMHO). Which mean that "objectively best way" (as you have said) to react to such letters is to improve bug-trackering in general ... to give less food to write such letters. Food for this is "floating"/unstable state of reporter which comes from silent behaviour of maintainer (bug is unprocessed ... which means necessary fields are still blank). Do NOT make reporter's state unstable and you will never get unstable messages from reporter. EASY! > If Denis would have written a reasonable e-mail asking about the status of Qt > Multimedia (without insults, attacks, and wishing anyone to hell), we most > probably won't have this discussion. > I think Denis should end this e-mail thread by apologizing, and start a new > one > in a reasonable way. Agree. But his behavior is the result of some objective problems which should not be rejected ALSO. I think this is about of mutual respect. Maintainer have to consider influence of keeping silent about bugs as NEGATIVE INFLUENCE on bug-reporter. And IMHO this influence is not fully understanded by some maintainers ... and now we have Denis's letter. I do not know what can be the best analogy ... probably it is like when you ask librarian about some missing book you can not find and he/she does not answer ... with not NO, not YES ... zero reaction on you ... just keep doing something he/she was doing ... this surely earlier or later will piss you off. And next event - reaction ... it depends on person. And you gess what ... some people will start insulting! So here we are ... predictable percent of insulting in such cases. Again IMHO ... in this case probably better to ask both sides to make 1 step toward peace. Yoann Lopes to process the bug (fill the fields ... not fixing it ... fixing is up to mainteiners plans which should come from bugs priority) and Denis Shienkov to apologies for rudeness. PS People with high emotional level can be considered as bad because of negative effect of insulting overs. BUT having such persons inside society helps find problems earlier because they are ones who feels problems most painfully because of this high emotionality. So this feature can be used by society in positive key. And I do not reject that insulting practice badly influence society too. Here we simply have phenomenon (medal) with two sides And I agree that probably we can start another thread for discussion of ways to improve bug-tracker. Because this thread has some too negative messages which gives unproductive effect for cooperation for improving things. Let's see if Denis will start the new thread for making bug-tracker better place. And I will copy with pleasure my letter about my vision on improvements in this thread. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Qt-creator] [Windows] Qt Versions/Kit auto-detection doesn't work on snapshots
Title: Re: [Qt-creator] [Windows] Qt Versions/Kit auto-detection doesn't work on snapshots
Hello, Julius.
I noticed a strange behavior on snapshots for a while now. Neither Qt versions nor kits are detected at all.
With Creator 4.0.x, everything works perfectly (Qt 5.6.1 & Qt 5.7, MinGW and MSVC 2015).
I tried:
● Installing 4.0.83 snapshots to a different location with a new profile
● Installing 4.0.83 snapshots to a different location with an existing profile
● Manually overwriting 4.0.x with an existing profile
● Manually overwriting 4.0.x with a new profile
None of these options resolve the issue. The Qt versions stays empty, although I can use already configured kits in my projects.
Returning back to the stable release makes them return.
What do you mean works perfectly. It is possible to install independent Qt version 4.0.x from QtC-only installer in some separate folder and get any Auto-detection of Qt-kits in its Build & Run settings!?
It never worked for me for every version of QtC. And this is probably because "autodetected" Qt-kits are not autodetected at all ... but they are those that QtC have in settings in QtC's installation folder. This is how I think this "autodetection" is really happening.
Is this a known issue, or even expected? Should I file a bug?
I think this is issue and bug ... but in misleading naming ("Auto-detected") in QtC GUI.
So you have chance to fight for the bug only from this perspective :)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QtMultimedia] Still is supported, active?
Hello, Everyone. > Bugs are fixed when they are fixed. You won't get any estimate before the > developer actually starts fixing the issue. And even then, it may take months > or more until it actually gets fixed. Agree but devil is in details. Currently there is a practice to not fill-out necessary fields for the bugs and not to change its status. I exactly mean * Not changing from Reported to Opened (or Need Info or Closed) ... like it is with discussed QTBUG-53019 (1/2 year old) * Not assigning responsible person in Assignee field like it is for ex. with QTBUG-46812 (1 year old) * Not assigning Fix Version/s ... which can mean there is no plans for the bug. No plans can be because of 3 reasons: I do not care and going to silently ignore the bug OR I agree with the bug but have so many bugs to fix already so that this is to far from my 1 month plan (or 3 month plan or 1 year plan ... nobody knows what plan is meant) OR I except the bug but do not want to bother myself with filling this field about my plans Having these details like this make such letters from time to time appear in mailing list. This is natural and is predictable result. So while I agree that angriness is not helpful for mail list ... messages like this are probably the seed to rethink strategy of working with bugs. This is probably means that we need some easy to use query in bug-tracker system which can show up "unprocessed bugs" ... which is bugs with state Reported OR no Assignee OR no Fix version With sorting from oldest creation date to newest. All unprocessed bugs make people float in unconditional state like floating 1: was the bug accepted or not (state is still Reported) floating 2: does anyone (mighty to fix it) knows about it (Assignee filed is empty) floating 3: how long approximately to wait for fix ... month, 3 months, year, 10 years (Fix Version blank) This unconditional state make people do what they do. For example angry letter can be easy the result of "floating 1". May be my request need more buzz so that it will be processed. If Yoann Lopes will fill the bugs fields why in the world would Denis Shienkov ever wrote this letter. Never. Because attitude to the bug will be clear to him. And Denis can only live with this (like trying to fix himself, or hire someone or stick to Qt 5.5.1 forever or whatever else) I IMHO see Denis Shienkov's personal attacks to Yoann Lopes quite reasonable not in sense of not-fixing the bug but in sense of not filling bug's fields ... Those fields are in the bug-tracker system FOR A REASON and it is MORE THAN IMPORTANT for reporter to see them filled. So I am trying to say that there is tendency for qt-devs maintainers to ignore value of described fields for reporters of bugs and angry letter is predictable result of this tendency. Instead of trying to shut up the Denis we better discuss current situation with bug-tracker and decide to make some clear for everyone tools which can show up forgotten bugs (described idea of unprocessed bug query) which makes people write angry. And I totally agree that "Bugs are fixed when they are fixed". And agree that maintainers need to respect Best Practices of working with bug-tracking ALSO (which exactly mean filling out ALL these 3 fields ... they ALL are important). >> Otherwise there is an impression that I talk there to myself or to a blank >> wall. You see. He is telling that he feels unheard... he see no reaction ... and he start making buzz in mailing list. Very predictable. But why this reaction should be exactly in fixing the bug? It can be enough to fill the bug's fields I think. Maintainers also have limited working-time. So what I propose IMHO seems to be a good balance for maintainers and bug-reporters. So I have 3 questions in my mind about this: Can we discuss this theme (about bug-tracker system) with some practical things which can be improved from ballancing perspectives of view to tracking of bugs? Can Qt Product Managers arise the importance of Best Practices of working with bugs-tracker for developers? Can someone create this query inside bug-tracker system and share it with everyone so that unprocessed bugs can be shown? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Revisiting high-DPI configuration options
> Startup. Approximately how many icons app have to have to see influence on app's startup? >> Also there was idea in this thread earlier that SVG rendering can be done >> much faster ... like in old Opera browser. Why Qt company cann't ask Opera >> to share this part of old Presto engine? They decided to not use Presto >> nowdays so no loses for them. > I can't speak for business decisions. But however faster that engine is, it'll > still be orders of magnitude slower than PNG. But scaling is a problem. >> But for people who really want raster images to be aplied ... may be it is >> possible to add some method to QIcon which will store this specially >> rastered QPixmap in icon and will render icon with this pixmap if icon size >> is small. But I am sure most apps will be happy with just SVG rendering. >> This is such a detailed work ... not sure that many apps creators will >> decide this work as a high priority. > As Morten said, Qt does not have a choice: we have to support both SVG and > raster icons. Agree. I am about details. If user can only select SVG OR PNG this is one way to support both icon formats. I was trying to say that combined variant is imaginable and is interesting because can have benefits of both formats. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Revisiting high-DPI configuration options
Hello, Everyone. > That's one reason, but there are two more equally, if not more important: > 1) SVG rendering is orders of magnitude slower than PNG. Icon-heavy > applications suffer if they use it. Why SVG support of QIcon can not cache rendered result? So re-rendering will be as fast as for PNGs. Or you are saying about app startup time? Also there was idea in this thread earlier that SVG rendering can be done much faster ... like in old Opera browser. Why Qt company cann't ask Opera to share this part of old Presto engine? They decided to not use Presto nowdays so no loses for them. > 2) SVG icons designed for higher resolution, with a lot of details, look > complex and polluted in lower resolutions. From past experience, icon artists > prefer to render the SVG to a lower resolution and retouch them. This is a problem. But I do not see many such icons in Material-style. They are mostly simple. So I would expect modern styled-apps will not have this problem massively. But for people who really want raster images to be aplied ... may be it is possible to add some method to QIcon which will store this specially rastered QPixmap in icon and will render icon with this pixmap if icon size is small. But I am sure most apps will be happy with just SVG rendering. This is such a detailed work ... not sure that many apps creators will decide this work as a high priority. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Revisiting high-DPI configuration options
Heello, Everyone! > Then again, our SVG support is embarrassingly poor, Exactly! For example if you set SVG icon for button and then scale the app with something like QT_SCALE_FACTOR=2 before running the app ... icon will be bluered like this is not SVG! With QT_SCALE_FACTOR=1 icon looks fine. But fonts looks sharp for both QT_SCALE_FACTOR=1 and =2. Strange? (Qt 5.6.1, Windows). SVG icons are not shown at all in static builds of Qt, but png icons are fine (both icons are taken from resorse file). Static and shred Qt 5.6.1 build were done with same config settings except of cause "static". Strange too. (Qt 5.6.1, Windows). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Revisiting high-DPI configuration options
Hello, Everyone! > Or, come up with another gesture for that kind of zooming. > The devil’s in the details, and we’ve had a proliferation of details over the > last few years. > ... and many other thoughts I wanted to say that right DPI for screen should give only default scale factor for the app. And app should be able to change the scale factor easy at runtime and with fractional values so that user can unjust the scale factor according to himself and his current environment. So here I confirm that I see that "HighDPI" and "scaling factor" should be solved with the same technology. BUT ... we need screen's DPI only as a starting guess for setting the scale factor. Later we need to let user adjust it. I think that Qt lib should not go deeper in this by now ... like forcing some standard way to do scaling for the app. With common gesture or std shortcut. And this is simply because we are not sure what the best way is. I think what Qt have to make app scaling as easy as calling of one function and advertise on every corner that apps have to use this function and let user change scale factor if app wants to be considered "modern" and "good". After that users and apps will create the best practice in this area and then Qt can implement it. Currently it is too early. I am not sure that this "setScaleFactor" function is currently implemented. For example here http://blog.qt.io/blog/2016/01/26/high-dpi-support-in-qt-5-6/ I see only use of environment variable before start of the app for manual setting of scale factor. But why I can not change it in runtime is still unclear for me. I agree that changing of scale factor means that size of window will be changed. And what if this cannot be done more ... end of screen size ... what to do? Well we have layouts for this. But here is the problem ... Qt layouts have not been changed/extended for so long that in current new conditions devs would probably think that they are not happy with standard Qt layouts and would like to extend them (for example Horizontal layout can not ever layout things vertically ... even if there is no space in horizontal direction and plenty in vertical). But here is the problem ... we have mechanism to extend widgets (Promotion) but this mechanism somehow is absent for layouts! Why?! I am not sure about QML layouts problems ... probably anchors make it easier to define custom layouting in QML (but still not sure that everything is without problems in QML) but with widgets ... I never saw news about adding or extending any widget-layout. But this is in need after setScaleFactor will be implemented! ... because you can scroll the page vertically but horizontal scrolling is a bad tone ... so there is need in some std layout which will use vertical direction if the layout is out of horizontal space and there devs need possibility to extend layouts something like we have for widgets. Another problem will be with icons. They will scale bad. We are used to make icons with versions like _x2, _x3 ... and what we going to do if scale factor will be fractional? ... have icons versions like _1.1 _1.2 _1.3? Probably we need to rethink why in the world we make so many copies of one icon in compile time if we can make one SVG icon which can be scaled to any size without loss of crispness in runtime. Especially material design makes this easier because we mostly see only contours in material design icons. So the next step for Qt can be supporting of SVG-icons as main and preferable way for setting icons. In this case icons can be scaled clearly. I mean that this scaling-problem have to be discussed more in this terms ... in terms of support of already known technologies which by now were not developed enough to make fractional runtime scaling easy ... but not only in terms of getting right DPI. Right DPI-factor is not close to the problem solution ... at ALL! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Revisiting high-DPI configuration options
Hello, Everyone! > The scope of this is the Qt::AA_EnanbleHighDpiScaling mode. I’d like to > focus on two aspects: > 1) Automatic scale factor configuration based on system settings. There so many debates about this topic and how to get real DPI for all devices correctly. But I personally does get this as SO important thing. And this is because people are different and have different preferences about reading from screen (because of eyes or just personally). Which brings me to understanding that it does not matter what is the DPI of screen. It matter only how large PERSON want program font normally be. So I would expect that the main intention in developing of apps should be moved toward giving the user possibility to scale the app. And you are done! All this problems in getting correct DPI of screen would NOT be so painfull. Your phone or monitor or OS or something resulted in incorrect scale factor? ... does not matter! ... increase/decrease scale factor for that app as you like ... and here you are ... having this app comfortable for eyes and personal preferences (not for DPI of scrrent ... most people even do not know what it is and why they should care)! App should remember of couse this setting to restore it back at restart > 2) Handling fractional scale factors (rounding). Previous idea need fractional scale factors to work ... FOR SURE! PS I can give many more cases then getting right DPI does not give usability to user. 1. Developers or Designers are young, have good eyes are pretty conformable with small fonts. They produce app with HighDPI support which correctly scales to DPI of HighDPI user device. But ... this does not mean that old persons would feel comfortable with the app ... their eyes see not as good as when they were young. 2. Could be a reverse case ... like you want smaller because devs created app which seems larger to you. 3. Devs and Designers usually have good tech. I mean good monitors, modern phones with good crisp screen. But user's tablet/phone can be not modern or be cheap or with tons of scratches (for example with plastic (not glass screens)). Sooo ... visibility is much worse ... but DPI could be same. 4. You are OK with design and size of app's fonts at your notebook/tablet with like 10'', devs and designer see things the same good as you and your screen is modern and good with gorilla glass or something same and DPI scale factor was determined exactly as it is. But now you are inside city transport ... and guess what ... you are shaken! ... and this mean you see the screen worse ... you need to increase the scale! And if you sit/lay still in the bedroom you what smaller font to see more info at once. I have nothing against getting right DPI at app's startup ... I wanted just to say that I see that it is actually NOT THE MAIN PURPOSE! ... for usability! May be Qt need to move accents from getting right DPI to making it user changeable ... FRACTIONALLY (as a good new practice)! Like 10-20 % steps ... not just 2,3,4,5. I do not see much trend in Qt-discussions/apps-interfaces about user-defined scale factor. But only THIS is important to user. And NOT DPI ;) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
