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 ch...@chipp.com 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
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
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
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
CEO,
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:
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
On Sat, Jul 21, 2012 at 8:59 PM, Roger Eller roger.e.el...@sealedair.comwrote:
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
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 Wieder
On Sat, Jul 21, 2012 at 9:16 PM, Mark Wieder mwie...@ahsoftware.net 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
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
On Sat, Jul 21, 2012 at 9:34 PM, Chipp Walters ch...@chipp.com 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
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:
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
On Sat, Jul 21, 2012 at 10:06 PM, Chipp Walters ch...@chipp.com 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
On 7/21/12 7:49 PM, Andre Garzia wrote:
On Sat, Jul 21, 2012 at 9:34 PM, Chipp Walters ch...@chipp.com 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.
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
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
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
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 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
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
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. :
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
*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 people
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
25 matches
Mail list logo
