Message 67117

Author
nicoe
Date
2021-04-30.13:43:54
Message id
67117

Content

* Cédric Krier  [2021-04-30 10:49 +0200]: 

>> >For me it is a complex code to maintain for
>>
>> I could understand the argument of the complexity for the javascript version
>> (because of the margin, the usage of "getBoundingRect" which is not exactly
>> self-explanatory) but the GTK one is not really complex.
>>
>> But something even more simple could use the height of the screen.
>
>The base height is not really the problem (and yes the screen height
>should probably be used as it is fixed).
>The problem is to know the height of a row before having the row. (I
>really do not like to use another random treeview than the one which
>will display the record).

Well the menu is not a random treeview. It's a treeview which is almost
guaranteed to be there and in which the size of the row will be the minimal
size of the rows (because menu entries are Char fields which can not contain
carriage return).

One issue I have is that the expander could make the row bigger then the usual
ones.

>> Even more so if we take into account the web and the different handheld
>> terminals people could use there.
>>
>> According to https://www.w3schools.com/browsers/browsers_display.asp the
>> resolutions of the screen of people browsing their website are:
>>
>> - Other high resolutions: 52.2%
>> - 1366x768: 24.8%
>> - 1920x1080: 19.2%
>> - Lower: 10.7%
>>
>> (I would have bet that 1920x1080 was the biggest something like 60%, I am far
>> from the truth. It's a bit sad that wikipedia or google do not make their data
>> about this available as they are more mainstream).
>
>So we can take 1080 as reference which correspond to my screen and
>numbers.

The issue is that it's your screen (and mine) but only ⅕ of the screen used by
people in the wild. If we stick only to the numbers found by this survey we
should use 768, but it's not future proof and I infer that people will have 4K
(2160 or even 4320) screens in the not so distant future.

>> >(which could even be a configuration parameter if needed).
>>
>> Why not but it seems a bit too technical to explain to the users.
>
>For me it is for special usage. Like if someone is using the client on a
>unusual screen size. (It is the same as for the search limit).
>
>Or maybe instead of adding a new value, we could still reuse the search
>limit for something like:
>
>limit = int(CONFIG['client.limit'] / min(len(fnames), 10))

Indeed it could work. I prefer this solution to another parameter.

The difficulty is to convey the meaning that the goal is to fill the screen
with the minimal amount of requests.
History
Date User Action Args
2021-04-30 13:43:54nicoesetrecipients: + ced, pokoli, reviewbot
2021-04-30 13:43:54nicoelinkissue10043 messages
2021-04-30 13:43:54nicoecreate

Showing 10 items. Show all history (warning: this could be VERY long)