Setting the scale factor to 80% (for 1.25% screenpixelsvale) doesn't work?
I have done that in the past and it worked fine - just always using the
reciprocal of the screen pixel scale.
Sent from my iPhone
> On Apr 16, 2017, at 1:49 PM, Tom Glod via use-livecode
>
Hi Folks...
Is there anything that can be done to prevent windows from scaling my stack
when the system is set top use 125% or 150% "scaling" options?
In livecode ... that is reflected in the systempixelscale and
screenpixelscale properties.
My stack and the images and controls on it looks
Hello,
Great to see all of you in San Diego! Hope you are all enjoying a warm
night or safely returning home.
Question for the list: In 6.5.2 it was possible to set the pixelScale
property on MacOS, but it looks like that is not possible in 6.7. I am
getting a Can't set this property
Hi David, check out 'scaleFactor' in the dictionary
-
Some are born coders, some achieve coding, and some have coding thrust upon
them. - William Shakespeare Hugh Senior
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/pixelScale-support-on-desktop
Monte Goulding wrote:
I think in this case where it's easy to show that its virtually
impossible to design a satisfactory UI for both devices then it
would be beneficial to have at least some screenshots. Just two
screenshots of the same stack in different density screens of
similar size
Monte Goulding wrote:
Google assumes we are all working in java where the density is
abstracted into 4 common plus a couple of less common density groups.
LiveCode doesn't do that abstraction for us so we get the actual
pixels on screen.
The DisplayMetrics class has a density property
What I mean is to a java dev the screen is in an abstracted width, height and
density. We need to work in the actual width, height and density.
Regarding the bug report it might be good I we could add a recipe. Perhaps a
recipe for creating a ldpi and xhdpi emulator at the same screen size then
Monte Goulding wrote:
Regarding the bug report it might be good I we could add a recipe.
Perhaps a recipe for creating a ldpi and xhdpi emulator at the same
screen size then a stack to run on them. Then a couple of screenshots
to save them the time of actually doing it...
Are they now
On Sat, Sep 29, 2012 at 7:46 PM, Richard Gaskin
ambassa...@fourthworld.comwrote:
Monte Goulding wrote:
Regarding the bug report it might be good I we could add a recipe.
Perhaps a recipe for creating a ldpi and xhdpi emulator at the same
screen size then a stack to run on them. Then a
I think in this case where it's easy to show that its virtually impossible to
design a satisfactory UI for both devices then it would be beneficial to have
at least some screenshots. Just two screenshots of the same stack in different
density screens of similar size should do the job. If I get
I've long thought that this is a design flaw in the QCC. There should be
two fields, one to specify whether the entry is a bug or an enhancement
request and a separate one to define the severity. That way, a request
such as this could go in as a critical enhancement whereas now there is no
way
I finally got a chance to review the v5.5.2 notes for Android, and it
seems there's still no pixelScale or pixelDensity function - is that
correct?
Given that it's a one-liner in the Android API and how essential it is
in developing for that platform, I'm hoping I've just missed something
Follow-up on a possible workaround just in case we still don't have a
pixelScale function:
The docs note that we can get the screeRect and workingScreenRect
functions, which will tell us the difference between the two which is
the height of the Status bar...
So given that the Status bar
development services
mergExt - There's an external for that!
On 29/09/2012, at 10:16 AM, Richard Gaskin ambassa...@fourthworld.com wrote:
I finally got a chance to review the v5.5.2 notes for Android, and it seems
there's still no pixelScale or pixelDensity function - is that correct?
Given that it's
in case we still don't have a
pixelScale function:
The docs note that we can get the screeRect and workingScreenRect functions,
which will tell us the difference between the two which is the height of the
Status bar...
So given that the Status bar is normally of a given size, anyone here
a
pixelScale function:
The docs note that we can get the screeRect and workingScreenRect
functions, which will tell us the difference between the two which is
the height of the Status bar...
So given that the Status bar is normally of a given size, anyone here
found a reason why using
It's slightly more complicated because for some reason android devices might
have a different dpi in width and height. So we need xdpi and ydpi. Or maybe
given its unlikely to be all that critical the. Maybe an average of the two.
Cheers
--
M E R Goulding
Software development services
mergExt
Wow, Monte, I haven't heard of this before, and I don't believe Google
makes any mention of this in their resolution development notes. Do you
have any links/pointers to devices that have this kind of display?
Thanks Regards,
Scott Rossi
Creative Director
Tactile Media, UX Design
On
Google assumes we are all working in java where the density is abstracted into
4 common plus a couple of less common density groups. LiveCode doesn't do that
abstraction for us so we get the actual pixels on screen.
The DisplayMetrics class has a density property which gives you the abstracted
19 matches
Mail list logo
