Interesting. On Tue, Oct 6, 2015 at 12:57 AM, J. Liles <[email protected]> wrote:
> > > On Mon, Oct 5, 2015 at 2:48 PM, Maxim Kovgan <[email protected]> wrote: > >> All this is really good news, >> then all I need is to come up with (preferrably existing) scaling factor >> determination algorithm :) >> Lemme dig a bit, I'll come back laters. >> > > Well, good luck. I personally don't think it's possible. You can't please > everyone. > > I dealt with this recently when I switched to a new laptop with a slightly > higher resolution screen. At about the same time, a new KDE version came > out. Suddenly all the fonts looked tiny. OK, I thought, the driver must be > misinformed about the physical dimensions of the screen, so I measured it > and created an appropriate entry in the Xorg configuration for it. Now > the fonts were huge! So, I had to experiment with fake dimensions, > restarting X every time, until I found a set that produced the same > apparent font size as I had prior to the upgrade. > > > So, suppose I alter NTK to do the same kind of scaling based on DPI... > Well, in order to trick the KDE heuristic, I've lied about the physical > dimensions, so even if the NTK heuristic is "correct" by some definition, > it will produce incorrect results in this configuration. But if I remove > the bogus dimensions, all the KDE fonts will be huge again. Plus, I'll have > to restart X a hundred more times while I fiddle with it. > OK, so I understand the problem was only with matching font sizes to the scaling factor. Right? (I expect there would be calibrating diff between various ways various desktop envs/window managers are managing fonts rendering) > It would have been better if KDE had just given me a slider by which to > control its UI scaling, would it not? I'm sure they put a lot of work > into their on heuristic, but the result was nevertheless unusable. > > >> >> >> >> On Tue, Oct 6, 2015 at 12:43 AM, J. Liles <[email protected]> wrote: >> >>> >>> >>> On Mon, Oct 5, 2015 at 2:21 PM, Maxim Kovgan <[email protected]> wrote: >>> >>>> Firstly, it's a lenovo y50-70 laptop. >>>> >>> >>> Interesting. >>> >>> >>>> What I'd really want is NTK (or rather FLTK) to support scalable UI, >>>> seems SVG should be a good candidate, unless you have something else in >>>> mind already. >>>> >>> >>> I have no say in what FLTK does. I'm not sure what you're getting at >>> with SVG. Everything in Non, barring one or two icons icons is entirely >>> vector already and would scale up or down just fine. No need to bring XML >>> anywhere near it. >>> >>> >>>> So the decision how to actually display the graphics should be done >>>> based "on the device", I'd go for a heuristic of resolution+DPI allowing >>>> to know physical size and determine a scaling factor for everything. >>>> This would allow to keep standard proportion of visual objects. >>>> and a "nice to have" - to allow overriding that factor from either >>>> apps' preferences OR via conf file. >>>> So if the user decides to use 100" display, it would be easy to adjust >>>> pixel size of things according to the need at hand. >>>> >>> >>> If you're aware of some reasonable standard heuristic for determining a >>> scaling factor that already exists, I'd be interested in hearing about it. >>> I'm not interested in just making something up, because that's likely to >>> generate more complaints than anything. In my experimental branch, I had a >>> scaling factor added to ntk-chtheme that would impact all NTK programs--but >>> the user would have to go in there and change it. >>> >>> >>>> >>>> >>>> On Mon, Oct 5, 2015 at 11:51 PM, J. Liles <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Mon, Oct 5, 2015 at 1:42 PM, Maxim Kovgan <[email protected]> >>>>> wrote: >>>>> >>>>>> Here's my "Hi" >>>>>> Firstly - kudos for the UI concept and the rather minimal working >>>>>> environment - excellent. >>>>>> My laptop and screen have a resolution of 3840x2160, and non tools >>>>>> look VERY TINY there, >>>>>> Naturally, I'm interested in patching the UI to adopt to my display >>>>>> size, dpi & resolution so the system looks conveniently sized. >>>>>> N.B. >>>>>> If you guys have ideas how and maybe it's part done in someone's >>>>>> branch/fork of the code - I'd be happy to either work on that patch >>>>>> AND/OR >>>>>> test it) >>>>>> pointers would be nice on where the code handling widgets sizing >>>>>> resides, and possibly present refactoring ideas/branches/forks to look at >>>>>> to achieve the above - would be nice. >>>>>> Didn't go through the issues, but I've noticed the FLTK itself is a >>>>>> fork off FLTK, so I guess the only way to understand the fork would be to >>>>>> eat with it :) >>>>>> >>>>>> My availability is an expected one from fully employed deployed >>>>>> family man, but If I start chewing on something - I'm usually finishing >>>>>> it, >>>>>> so it's sporadic, but when my kids wake me up at nights I don't go to >>>>>> sleep >>>>>> right away. >>>>>> >>>>>> Best regards all. >>>>>> >>>>> >>>>> I take it that your laptop has an Apple Retina display? >>>>> >>>>> I've thought about handling this. I actually experimented with some >>>>> changes to NTK a few years ago to scale everything up by a certain >>>>> percentage. But I'm not really sure that's the best thing to do. I have a >>>>> display of the same resolution as yours, but mine is 50", so everything >>>>> looks fine. I can imagine that squeezing that into a 13" laptop screen >>>>> would make everything pretty hard to read... What would you want >>>>> personally? Would having all of the text and graphics scaled up the same >>>>> amount be sufficient? >>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Maxim Kovgan >>>> >>> >>> >> >> >> -- >> Maxim Kovgan >> > > -- Maxim Kovgan
