In watching Chipp's videos, I wish LiveCode's Preferences would contain a
control for setting the default image quality. For example, to "good" to avoid
the repeated resetting.
One could do this by changing the templateimage, but a preference would be
handy.
Jim Lambert
That's it. Like using a blown up iPhone app on your iPad. It's not the density
the causes the problem it's the relationship between density and the number of
pixels: pixels / density = size. By working out the size we can determine if a
device screen is large enough for us to present the tablet
Monte,
I'm not sure I understand the issue. Take the absolute worse case
scenario-- a 320W x 480H iPhone 3GS vs the same size screen but 4x the
density 640,960 Retina iPhone. One screen is literally four times the
density of the other, yet using this library the buttons are virtually the
same phys
Good point to get in mind ! Thanks Andre.
Le 22 juil. 2012 à 02:49, Andre Garzia a écrit :
> On Sat, Jul 21, 2012 at 9:34 PM, Chipp Walters wrote:
>
>> I typically think either we're designing for Tablets or Phones-- but not
>> for both at the same time. Most devs I've seen tend to develop 2 di
The problem is people's finger size and eyesight doesn't change with the pixel
density of their device. Using this method would result in controls that are
too large on some devices and too small on others. Then there's the question of
when to show a tablet UI vs a handheld UI.
Cheers
--
M E R
On 22/07/2012, at 10:34 AM, Chipp Walters wrote:
> I typically think either we're designing for Tablets or Phones-- but not
> for both at the same time. Most devs I've seen tend to develop 2 different
> apps if they need to support both.
I think that's unnecessary. Most of your code can go in a
Andre-
Saturday, July 21, 2012, 5:24:59 PM, you wrote:
>> Can you shell to xrandr to get this?
>>
> Is there a xrandr on Android? :-O
I just checked and there isn't on ICS, at any rate.
--
-Mark Wieder
mwie...@ahsoftware.net
___
use-livecode mai
On 7/21/12 8:43 PM, Chipp Walters wrote:
Jacque,
This framework works pretty much like you first described. I suspect you
will find it worthwhile for your projects.
Yup, I was just looking at the scripts. It's a lot like I described. :)
I see a stub in there from Ken's library that toggles w
Jacque,
This framework works pretty much like you first described. I suspect you
will find it worthwhile for your projects.
--
Chipp Walters
CEO, Altuit, Inc.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscrib
On 7/21/12 7:49 PM, Andre Garzia wrote:
On Sat, Jul 21, 2012 at 9:34 PM, Chipp Walters wrote:
I typically think either we're designing for Tablets or Phones-- but not
for both at the same time. Most devs I've seen tend to develop 2 different
apps if they need to support both.
There is one g
On Sat, Jul 21, 2012 at 10:06 PM, Chipp Walters wrote:
> Andre,
>
> I suppose if you wanted to develop both for phone and tablet, you could use
> 2 different stacks, each using the same altMobileResizer framework and then
> branch to them by editing the openStack handler on cd 1 of the main stack
Andre,
I suppose if you wanted to develop both for phone and tablet, you could use
2 different stacks, each using the same altMobileResizer framework and then
branch to them by editing the openStack handler on cd 1 of the main stack.
There is one good case for developing a single application that
FYI, New 5 min video explaining how to use the plugin:
http://youtu.be/TLWD5KsstFc
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.
On Sat, Jul 21, 2012 at 9:34 PM, Chipp Walters wrote:
> I typically think either we're designing for Tablets or Phones-- but not
> for both at the same time. Most devs I've seen tend to develop 2 different
> apps if they need to support both.
>
There is one good case for developing a single appl
I think what folks are asking for is a 'responsive' design for layout.
While I agree it's a nice goal, I'm not so sure how necessary it is.
I typically think either we're designing for Tablets or Phones-- but not
for both at the same time. Most devs I've seen tend to develop 2 different
apps if th
AndreOiD (Andre's original ideas)
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Hi Monte,
Landscape should work just fine-- it's the rotation which can possibly
cause problems. One way to do this is with 2 stacks. Another way to do it
is with a large square stack and different cards. The library has the
ability to render objects on all cards at startup, or using a preOpenCard
On Sat, Jul 21, 2012 at 9:16 PM, Mark Wieder wrote:
> Andre-
>
> Saturday, July 21, 2012, 5:08:46 PM, you wrote:
>
> > If we can figure out this then we can present a better layout. Another
> > thing would be a good way to return the screen physical size, for
> example 7
> > inches for Nexus 7 an
Andre-
Saturday, July 21, 2012, 5:08:46 PM, you wrote:
> If we can figure out this then we can present a better layout. Another
> thing would be a good way to return the screen physical size, for example 7
> inches for Nexus 7 and Kindle Fire.
Can you shell to xrandr to get this?
--
-Mark Wied
On Sat, Jul 21, 2012 at 8:59 PM, Roger Eller wrote:
> > Also screen density on android is a headache because a high density phone
> > could be higher res than a low density tablet. What are your thoughts on
> > dealing with that?
>
> To be fair, try editing a stack for the new iPad resolution even
> Also screen density on android is a headache because a high density phone
> could be higher res than a low density tablet. What are your thoughts on
> dealing with that?
To be fair, try editing a stack for the new iPad resolution even on a
1920x1200 monitor. However, the resTool stack that was
Hi chipp
Thanks for the video. This looks like a really helpful tool and I'm keen to get
my hands on it.
Do you have any ideas for handling landscape and tablet views? For tablets I
think in most cases you would want a different stack so using a main stack with
most of the code and a handheld
Chipp,
Nice tool. Very clear presentation.
Thanks,
Jim Lambert
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listi
42 minutes of HD instruction; time well spent! I can't wait to get the
stsResizeLib.
~Roger
On Sat, Jul 21, 2012 at 7:56 AM, Chipp Walters wrote:
> Check out my latest resizing library (using part of Ken's stsResizeLib).
>
> http://www.youtube.com/watch?v=vY6r46O0cVA
>
> --
> Chipp Walters
> C
Monte,
I agree with you. We all know by now that Apple discourages using faux
Apple-like controls UNLESS they are pixel perfect and strictly follow the
Apple UI guidelines. But, they readily accept different interfaces as long
as they are well done. Plus, being able to code one GUI and have it run
I've thought about this a little. While I think the current situation is not
ideal I also think that what people want is not what people would get if we had
a native appearance on ios.
The issue is we really need to be able to work in the appearance we are
building for. If it were me steering t
*Yes*, just tried now on iPad, ...
... on the test program, in the button Ask, change the
"iPhone.." with "mobile.", do the same in the button
"Connect", adjust the stack size for the size of your device and RUN ! :-)
On a future release I will change the test program so p
That's cool. So, if you used mobileControlSet instead of iPhoneControlSet,
would it still work with iPad? It should, I would think.
~Roger
On Fri, Jul 20, 2012 at 2:04 PM, Guglielmo Braguglia wrote:
> the library doesn't need any tweak, is the enclose demo test program
> that every body need to
Hi Roger,
the library doesn't need any tweak, is the enclose demo test program
that every body need to adjust for their needs (/I have written the test
program for desktop and iPad because I use them; the library,
fortunately, doesn't use any specific OS function/). :-)
Guglielmo
/P.S. : To
Maybe I wasn't clear. By Controls, I mean fields, buttons, etc. It seems
a little odd as a design choice to say "well if you want your field on
mobile to look like the platform you are building for, even though you
selected the platform in the Standalone Application Preferences, you have
to write
I would call mergExt a suite of "native functionality add-ons" (officially:
externals), specific to iOS only, rather than native controls for mobile.
If runrev were to support native controls in the IDE, they would
automatically change to the appropriate look-and-feel of the platform,
either when
Because that would take more work, and nobody has done that work yet. I don't
think anybody will either unless you can make an argument for how much extra
revenue it will bring in for RR. I'm not being snarky here. There are hundreds
of questions just like that in the QCC.
I will say however,
I've never really understood this issue: Why is it that one has to code
the native controls on Android/ios? Why doesn't the compiler/standalone
builder/whatever you want to call it just convert rr controls to native
ones?
--
On the first day, God created the heavens and the Earth
On the second
33 matches
Mail list logo
