FWIW, I stopped using Qt Designer because it kept adding font settings and other stuff whenever I edited a .ui file. In the end, I ended up editing files with a plain text editor, so I know what is actually being changed.
IMHO, we shouldn't set fonts other than the ones defined by the KDE theme. Specially for setting a specific width. But overall, please try to keep it civil. I know this discussion has been going for a long time, and we are all tired and want to move on to something else. Let's step back a little and try to figure a solution that works for everyone. Regards, Alvaro On Tue, Sep 23, 2014 at 11:32 AM, Cristian Oneț <onet.crist...@gmail.com> wrote: > 2014-09-23 16:54 GMT+03:00 Allan <agande...@gmail.com>: >> On 23/09/14 14:00, Cristian Oneț wrote: >>> >>> 2014-09-23 15:52 GMT+03:00 Allan <agande...@gmail.com>: >>>> >>>> On 23/09/14 01:26, Jack wrote: >>>>> >>>>> >>>>> On 2014.09.22 18:12, Allan wrote: >>>>>> >>>>>> >>>>>> On 22/09/14 22:25, Jack wrote: >>>>>>> >>>>>>> >>>>>>> On 2014.09.22 15:17, Allan wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 22/09/14 19:04, Jack wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2014.09.22 13:08, Allan wrote: >>>>>>>>> [snip....] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I don't think it really matters what font the system is using, as >>>>>>>>>> long as that font is available. I'm using DejaVu Sans at the >>>>>>>>>> moment, but I understand that if that is not available, the system >>>>>>>>>> will substitute a similar one. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I'm not sure you understand my question. If the system is >>>>>>>>> displaying >>>>>>>>> a font other than the one you specify but doing the size calculation >>>>>>>>> based on the font you specified, then the calculation may not match >>>>>>>>> the display. I'm just trying to be sure the size calculations are >>>>>>>>> being done with whatever font is actually being displayed. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> As I specify the same font for both, wouldn't that avoid the >>>>>>>> situation >>>>>>>> you foresee? >>>>>>> >>>>>>> >>>>>>> Not necessarily. You specify font X for display, but the system uses >>>>>>> font Y. You specify font X for doing font matrix calculations, and my >>>>>>> question is whether you know for sure that it is doing those >>>>>>> calculations on font X or on font Y. Since those calculations are not >>>>>>> necessarily tied to the active display, I can imagine the system not >>>>>>> doing the font substitution. >>>>>> >>>>>> >>>>>> >>>>>> My non-expert view is that, if I specify font X, but the system >>>>>> substitutes font Y, then the system would only have cause to do that >>>>>> if font X was not available. So, I don't see how, some nano-seconds >>>>>> later, font X has suddenly become available and now gets used. I hope >>>>>> I don't need to keep checking? >>>>> >>>>> >>>>> I'm no more an expert than you, but I take a slightly paranoid approach >>>>> here. First, I don't know that non-availability is the only reason for >>>>> a system to use a font other than the one requested. I can imagine a >>>>> use case where user preference takes precedence, for example. (Think >>>>> css.) I can also imagine that when asked for font metrics for a >>>>> non-available font, the system might use some defaults, and not >>>>> necessarily those for the font it substituted in a particular instance. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> So far, all looks well on both systems now. The column widths are >>>>>>>> identical, and the only difference is in the overall width of the >>>>>>>> tableWidget. That, I believe, comes from the margins, which do >>>>>>>> differ, but I have already taken that into account. The aspect >>>>>>>> ratios >>>>>>>> of the two screens are different, too. >>>>> >>>>> >>>>> Again, taking the paranoid view, I'm not sure "both systems" is a >>>>> sufficient sample. I take Cristian's view here that it is generally not >>>>> a good idea to override the user's choice of system default font. Think >>>>> of a vision impaired user who has chosen a particularly large font, or a >>>>> font chosen specifically for readability. If you can query what font >>>>> was actually used, and then use that to request the metric calculations, >>>>> shouldn't that give equivalent results? >>>>>> >>>>>> >>>>>> >>>>>>> Are the fonts identical? >>>>>> >>>>>> >>>>>> >>>>>> I take it you mean between my two systems? Again, my non-expert view >>>>>> is that if the two fonts have the same name, then the are identical. >>>>>> Otherwise, they would not be the same font. >>>>> >>>>> >>>>> I accept that - but if those two systems are both using the font you >>>>> requested, then what happens when a system does not have that font >>>>> available? >>>>>> >>>>>> >>>>>> >>>>>>> If not, then why should the column widths be identical? >>>>>> >>>>>> >>>>>> >>>>>> If the columns contain the same data and use the same font, then that >>>>>> gives me the information needed to calculate/obtain the pixel width, >>>>>> and therefore I use that to set the column width. >>>>> >>>>> >>>>> Again, the question is whether you can be sure that is the font that >>>>> will always be used? New train of thought - what about non-Roman >>>>> character sets? Greek? Cyrillic? Arabic? It may be that the >>>>> procedure you use will set up appropriate column widths, but if that is >>>>> the case, then what have you actually gained from specifying a font? >>>>>> >>>>>> >>>>>> >>>>>>> I assume the point is for the column to display the text in it >>>>>>> without clipping and without wasting space. To me, different fonts >>>>>>> are likely to need different column widths. >>>>>> >>>>>> >>>>>> >>>>>> Yes, that was exactly the problem I had, which led me to specify the >>>>>> actual font to use for both calculations and display, within the >>>>>> plugin, to avoid the idiosyncrasies of different distros. It seems to >>>>>> be working. >>>>>> >>>>> While my argument is certainly more academic than practical, the >>>>> minimalist in me asks why you would specify more than you need to. My >>>>> paranoid self asks whether your font specification has really done what >>>>> you expect, or if it simply happens to achieve the expected results in >>>>> the cases you have tested. (Just for context, I have several friends >>>>> that would call this exchange a "violent agreement.") >>>>> >>>>> Jack >>>> >>>> >>>> >>>> To cut a long story short, perhaps we should "violently agree" on a font >>>> selector button on the first wizard page, opening a small window with >>>> suitable combo boxes? >>> >>> >>> Are you serious? I didn't read the above dialog completely. >>> >>> Regards, >>> Cristian >> >> >> Well, there was a fair amount of to-ing and fro-ing! So far as I am >> concerned, what it boiled down to is this. You have expressed more than >> once the inadvisability of hard coding values, and I totally understand >> that, especially having had to contend with font variations. I now have got >> that sorted, but only by 'hard coding' the font. I tried using >> QApplication::font(), but I have no idea what that will produce on different >> systems, although it appears to produce non-identical results here. >> QWidget::font() looks the same. >> >> I mentioned half-jokingly that a Chinese user might not be too happy, and >> Jack mentioned other non-Roman fonts. I really have no idea what one of >> these might produce. >> >> So, I was fairly serious in what I said, but it sounds like you may think >> otherwise. > > So now the advice of not to hardcode fonts is used as an argument to > add a font selector on the first page of the CVS importer? Why not add > then a resolution selector while we're at it. > > Now seriously, why don't we simply trust the system configuration > which is under the user's control? Why do we have to doubt everything > and conceive impossible scenarios to handle when the common use case > is not polished? > > Regards, > Cristian > >> >> Allan >> >> >> > _______________________________________________ > KMyMoney-devel mailing list > KMyMoney-devel@kde.org > https://mail.kde.org/mailman/listinfo/kmymoney-devel _______________________________________________ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel