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
> wrote:
>
> Hi Folks...
>
>
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 like
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/pixel
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 proper
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
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 to
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 a
On Sat, Sep 29, 2012 at 7:46 PM, Richard Gaskin
wrote:
> 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
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 re
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:
> 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
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
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 9/28/1
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
d yet, hopefully RunRev knows an equivalent of
"iphoneDeviceScale()" is critical for Android development.
Regards,
Scott Rossi
Creative Director
Tactile Media, UX Design
On 9/28/12 5:23 PM, "Richard Gaskin" wrote:
>Follow-up on a possible workaround just in case we still don
e 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
tware development services
mergExt - There's an external for that!
On 29/09/2012, at 10:16 AM, Richard Gaskin 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 t
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 b
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 j
19 matches
Mail list logo