Problem with Shortcut “Go to specified desktop&position”.
Problem with Shortcut “Go to specified desktop&position”.
Pierre Hébert
1. it works fine on the device i develop
but when i built the apk and load it on another device
2. the vertical position is offset slightly upward
with each page always something more.
both devices has the same screenresolution.
dev-device has hardware-keys, Android 4.2.2
target-device has softkeys which are hidden, Android 4.4.3
i recognized this for my 2 latest templates.
maybe this problem exists longer.
horizontal position seems to be ok.
scrolling pages up/down left/right is ok too.
]]>
D5 Creation
< ![CDATA[
This is due to not perfect scaling: it is not always possible to compute the exact available screen size because the size of the status or navigation bars cannot be queried. Hence a default value is used, but if these bars have a different height, then the launcher window height may be incorrect, and it may even affect width in some border cases.
]]>
< ![CDATA[
Pierre Hébert both screen res. are exactly the same. 1080×1920. no status bar, no softkeys.
i can understand a few pixels difference but here the gap is 40 pixels for each page. 1 page 40pixel. 2 page 80 pixel.
it’s the size of the softkeys i’ve defined when displayed.
all other stuff seams to match, except for the aforementioned minimal differences.
]]>
< ![CDATA[
Even when both devices have the same number of pixels, it does not mean that the app will have this whole surface for it. The gap is due to some error because of hidden/displayed bar(s), and the launcher “think” that one of these bars is displayed or not. It is not possible to know whether a device has softkeys or not and the error may come from here, maybe.
]]>
< ![CDATA[
Pierre Hébert as i wrote before ALL other stuff seams to be almost perfect there must be a difference between calculation screensize at position items and go to desktop position. or something similar ;-(
]]>
< ![CDATA[
Even thought this seems an issue with the bar, it’s really strange that the offset increase linearly with the horizontal position/page.
gerd reuter you can always use scripts to go to the position in case this is a big problem for you. (Save the position in the tag of the item to avoid having one script for each if possible)
]]>
< ![CDATA[
TrianguloY i have tried it with the original navbar from omnirom (also hidden), which is bigger than this which i use. the same result. ~40 pixels.
i have noticed some weeks ago something similar. i installed a theme on a s4 and it was amazing how differnt it was to my original ;-(
yes of course i can do a lot of stuff with scripting, but why should i do this when the function/action i need is already there?
pierre can drop all actions because we can do this with scripting. would make no sense in my opinion.
in conclusion: when there is a function/action it should work as expected.
]]>
< ![CDATA[
Pierre Hébert when will the position for “goto specified desktop&position” be calculated? when setting the shurtcut? or when execute?
]]>
< ![CDATA[
(A bit off topic: is ‘shurtcut’ an English word?
‘shortcut’ is the one I know, not sure if it’s a mistake or one of those internet-words. You use both, so I guess it’s a mistake. But I can be wrong)
]]>
< ![CDATA[
the bookmark is set as an absolute position at time of its creation.
It can be scaled once when loaded from a template but never modified again later.
When activated it triggers a scroll offset like this : target position minus current position.
]]>
< ![CDATA[
TrianguloY
???
]]>
< ![CDATA[
Pierre Hébert ok that means to me that during calculating the postion of “gtsd&p” while loading the template LLX does not know that the navbar is hidden? but knows it later, because everything else is positioned well.
means also to script this stuff when i want to “share” my templates-
that’s really annoying… sorry.
]]>
< ![CDATA[
( gerd reuter I only say that ‘shurtcut’ is perhaps a mistake. Just to let you know, nothing more.)
(In case you didn’t notice you use that word sometimes)
]]>
< ![CDATA[
TrianguloY i used it because its name in LLX is shurtcut. i would use honkytonk or whatever when LLX would use it 😉
but nevertheless i think it is the “correct” word or at least common.
shurtcut means also abbreviation, which it is.
and not a hairstyle ;-)))
]]>
< ![CDATA[
When using a grid everything seems fine because it is dynamically adjusted to match the application window. But when the template is loaded, the exact size is not known yet (it is defined later by the Android system). Can you send me the template, or a sample that shows the problem ?
(Although I like “honkytonk” – really funny! -, the right word is shortcut)
]]>
< ![CDATA[
Pierre Hébert i can send you the last template 😉
nevertheless i made a workaround which should work
https://plus.google.com/u/0/+gerdreuter/posts/7sBqa9YrzFA
]]>