Mobile Image Editing
Greetings list people! I am currently working on a project where we will be editing images on a mobile device. I'm running into an issue where the formatted height and width of the image change. Most of the images are natively 1600x1200 but we initially display them scaled to fit on the screen. When the user does any edit action at a zoomed out level, the image is downsized to the current zoom. Once downsized, if you zoom in on the image and edit, the formatted size doesn't change. Is there any way around this? What we would really like is to edit the image and keep it at the full resolution. We are currently using the native LiveCode paint/bucket tools. Although most of my testing is in the IDE at the moment, we do use resize handlers to format for the actual device resolution. Thanks for any thoughts or pointers, Brian ___ 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
Re: Widget properties
> After a day or two with BBC BASIC on a black screen teenagers will "do > anything for me" when they see the, supposedly, > old-fashioned LiveCode IDE and the ever-so-sexy WYSIWYG GUI. Using the ol' psychology on 'em. Wily! ___ 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
JWT Token Decode
Subject says it all. Has anyone done this in LC? In JavaScript it's decodeURIComponent. Thanks! Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net ___ 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
Ken Burns LC Stack
I downloaded the Ken Burns LC Stack and found that it doesn’t seem to work. Is anyone else finding it doesn’t work? Thanks, Rick ___ 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
Re: Widget properties
Here's my 25p's worth: Ever since widgets 'appeared' I have thought of them as second class citizens insofar as: 1. They are 'bits of stuff' where experts (the LiveCode team and so on) have done the heavy lifting for those of us who haven't got the skill, motivation or time to work out how to get that sort of thing together in LiveCode itself. 2. I certainly never get into widgets when I teach computer programming for a number of reasons: 2.1. While I teach children to program with LiveCode, the ultimate aim is to equip them with a series of transferrable skills they can take 'to the table' of any programming language: the ability to drop in a prepackaged 'does-it-for-you' add-on (one of the things that sets my teeth on edge about Python) does not, as far as I am concerned, constitute computer programming as such. Of course people might start shouting at me, at this point, and say, "Well then, why don't you go back to command-line programming?", to which my riposte is, "That's why I START my programming with teenagers (it's a bit too much for preteens) with BASIC programming on my BBC Micro machines I have lovingly curated in my school." After a day or two with BBC BASIC on a black screen teenagers will "do anything for me" when they see the, supposedly, old-fashioned LiveCode IDE and the ever-so-sexy WYSIWYG GUI. 2.2. While a LiveCode button can be examined via its property inspector, a widget largely cannot, so a learner cannot really begin to understand how it is put together. 3. Widgets are, undoubtedly very clever insofar as they provide tools and services out of the box, and types like myself don't have to spend an awful lot of effort working out how to roll our own. 4. I suppose the 'price' of a widget is just exactly that one cannot really get t its underpinnings (properties) in quite the way one can withg a native LiveCode object. Having said all this, I don't use widgets (beyond fooling around with them when I have a spare moment), and on my teaching computers the widgets section of the revTools palette is never exposed. Were widgets to be "integrated" into LiveCode as per buttons, fields, images and so forth, with properties palettes allowing a vast number of variables to be accessible, my attitude towards them might change; but that seems unlikely to happen as they are quite different beasts to buttons, fields, images and so on. Best, Richmond. On 7.04.22 9:24, Richard Gaskin via use-livecode wrote: Thank you for your reply, Monte. Comments inline: Monte Goulding wrote: >> On 7 Apr 2022, at 11:25 am, Richard Gaskin wrote: >> Can you help me understand how it's better than "the properties", >> and why this superior method isn't used for engine controls? > > Because the array created by export and used by import contains > the state of the widget as is saved when saving the stack. The > content may or may not be the same as the property names exposed > to user scripts but a widget created with that state should be > the same as if it were saved in the stack and the stack re-opened. I've never used a widget in production yet, so I can't say I have an opinion there. If the uses for widgets are viewed as sufficiently different from engine-based controls that "the properties" so many of us enjoy wouldn't apply, I'm okay with that. Just looking to understand. >> That the company has such a narrowly specific view of the >> applicability of "the properties" is indeed helpful. Thank >> you for chiming in. > > I’m not the company. Pardon my imprecision. I think the readers here are likely aware that the company is comprised of many people, and there are likely many different opinions on a wide range of topics, including this. Please read that as "a significant member of the company". > Mark may spend a lot more time pondering the utility of `the > properties` than I do and indeed may have a different opinion. > Indeed my opinion was much closer to yours is now when I sent > in a PR for LC 6.1 all those years ago ;-) One of the challenges with a tool as vastly capable as LiveCode is wrapping one's head around all the use-cases, and all the perceived priorities. Various members of the company and the community have expressed a wide range of opinions on many things. If "the properties" winds up being like the pointer tool requests I used to ask about, no worries. I stopped asking about those years ago. Indeed, even with "the properties" I've had a few discussions on this with different team members going back to Dr Brett, back when LCB was in its earliest stages. In my own mind having two different methods for obtaining property data for two classes of objects is akin to having two different words for "rect" or other basic features. Where a useful implementation has been chosen and established so long ago, it seems worth mirroring in new implementations. But TBH, since I haven't used widgets in production at all, the only
Re: Widget properties
Thank you for your reply, Monte. Comments inline: Monte Goulding wrote: >> On 7 Apr 2022, at 11:25 am, Richard Gaskin wrote: >> Can you help me understand how it's better than "the properties", >> and why this superior method isn't used for engine controls? > > Because the array created by export and used by import contains > the state of the widget as is saved when saving the stack. The > content may or may not be the same as the property names exposed > to user scripts but a widget created with that state should be > the same as if it were saved in the stack and the stack re-opened. I've never used a widget in production yet, so I can't say I have an opinion there. If the uses for widgets are viewed as sufficiently different from engine-based controls that "the properties" so many of us enjoy wouldn't apply, I'm okay with that. Just looking to understand. >> That the company has such a narrowly specific view of the >> applicability of "the properties" is indeed helpful. Thank >> you for chiming in. > > I’m not the company. Pardon my imprecision. I think the readers here are likely aware that the company is comprised of many people, and there are likely many different opinions on a wide range of topics, including this. Please read that as "a significant member of the company". > Mark may spend a lot more time pondering the utility of `the > properties` than I do and indeed may have a different opinion. > Indeed my opinion was much closer to yours is now when I sent > in a PR for LC 6.1 all those years ago ;-) One of the challenges with a tool as vastly capable as LiveCode is wrapping one's head around all the use-cases, and all the perceived priorities. Various members of the company and the community have expressed a wide range of opinions on many things. If "the properties" winds up being like the pointer tool requests I used to ask about, no worries. I stopped asking about those years ago. Indeed, even with "the properties" I've had a few discussions on this with different team members going back to Dr Brett, back when LCB was in its earliest stages. In my own mind having two different methods for obtaining property data for two classes of objects is akin to having two different words for "rect" or other basic features. Where a useful implementation has been chosen and established so long ago, it seems worth mirroring in new implementations. But TBH, since I haven't used widgets in production at all, the only time it comes to mind is when someone asks me about it for one of my tools, or in discussions like this one. This seemed a good time to see what the current vision is. I appreciate the clarity provided. >> How hard would it be for the team to map the existing means of >> extracting widget properties to "the properties”? > > I don’t think it would be particularly tricky to iterate the exported > property definitions to come up with a list of property names then > turn that into a key/value array. Whether it would provide the utility > you are looking for is a separate question. If it does what "the properties" does it would suit my needs. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
