Re: OSX File Extension
I seem to recall a Wikipedia article that lists all of the file extensions not file types but file extensions. You might want to look to see if yours is already in use. Kee Nethery > On Sep 7, 2019, at 10:44 PM, JB via use-livecode > wrote: > > Thanks for the info! I guess I will just start > using what I want and see if it catches on. > > JB > >> On Sep 7, 2019, at 10:39 PM, Richard Gaskin via use-livecode >> wrote: >> >> Apple no longer maintains a file type code registry.Richard GaskinFourth >> World Systems >> ___ >> 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 >> > > > ___ > 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 ___ 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: OSX File Extension
Thanks for the info! I guess I will just start using what I want and see if it catches on. JB > On Sep 7, 2019, at 10:39 PM, Richard Gaskin via use-livecode > wrote: > > Apple no longer maintains a file type code registry.Richard GaskinFourth > World Systems > ___ > 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 > ___ 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: OSX File Extension
Apple no longer maintains a file type code registry.Richard GaskinFourth World Systems ___ 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
OSX File Extension
Years ago you could create a file type or extension like jpeg, zip, pict etc. and then you would need to register that extension with Apple. If I create a new file extension do I need to register that extension with Apple or just start using it. The reason I am asking is I am creating a new form of compression for files and similar to zip files I want my own extension after the file name. The compression is not zip or any other and no other program will be able to expand it. JB ___ 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: OT: Catalina - the end of ad hoc & in-house development?
Everyone is signing the praises of tools to jump through Apple's hoops, but I see no one refuting Peter's original claims that Catalina is a ste towards the end of ad-hoc and in-house development for the Apple platform and I would agree. Apple's goal for OSX is to get to the same place as iOS, where all OSX apps go through the Apple store operation for a 30% cut. Eventually, you will not be able to distribute an OSX application yourself directly to a friend who runs OSX. It will go through Apple and, yes, it may be a "free" app, but the endlessly changing hurtles that are discussed frequency on this list for iOS will become the same for OSX and that overhead will kill off a certain number of developers who just do not have the time or patience or money to jump through those hoops. And because - those sort of small ad-hoc or in-house developers - will never contribute significantly to Apple's bottom line, Apple really doesn't care one bit about them. My 2 cents from having been close to Apple since the Lisa was released. ___ 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: OT: Catalina - the end of ad hoc & in-house development?
I have an idea on how to get a single ‘Capsule’ app notorized that can open and run any stack file as a standalone. It does mean that the stack won’t be compiled quite like a true standalone but does allow users to open any stack on their desktops. Perhaps there’s a way we could even get it to run other non-notorized compiled apps within it. It’s only a fledgling idea so if anyone else can pip me to the post you’re more than welcome to. Sean Cole Pi Digital Prod Ltd ___ 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: high resolution when printing to pdf, either from images or pdf widgets
On Sep 7, 2019, at 4:29 AM, Mark Waddingham via use-livecode wrote: > > On 2019-09-06 21:10, Dr. Hawkins via use-livecode wrote: >> On Aug 28, 2019, at 12:07 AM, Mark Waddingham via use-livecode >> wrote: >>> On 2019-08-27 17:24, Dr. Hawkins via use-livecode wrote: >>> I'm not entirely clear what Monte meant by 'print to pdf directly' in one >>> of those comments... The 'print to pdf' mechanism in the engine isn't >>> really any different from the normal printing mechanism, its just that >>> rather than funnel the sequence of paths, images, text being rendered >>> through the system printer it funnels it through libcairo's >>> (https://cairographics.org/) >>> PDF output functionality. >> Can this be adjusted for higher resolution? >> *is* there a way to send out at full resolution? > > I'm not sure I entirely follow - PDF is primarily a vector format so there is > 'resolution' as such. In regards to images then the engine/pdfprinter tries > to preserve the original image when printing - so if you print a large JPEG > scaled down to 100x100, the original JPEG will be passed into the PDF and then > that will be scaled down when rendered (i.e. as much information in the > original > is preserved in the output). ' Currently, the pdf gets 72’d when the engine renders. Could it simply be adjusted for, say, 300 dpi resolution on output? > >> I don’t need it to be the original, but rather visually indistinguishable. > > Then that changes things slightly - particularly if your originals are scans > which contain images rather than vectors... In this case, the render the PDF > at a larger size and scale down approach should be able to give you want you > want. My originals are almost if not entirely text, lines, and boxes. > >> As I think about it, I don’t think I’ve ever said *anything* nice >> about pdf. I’ve generally called it a bastardization >> of postscript, but in this case, “castration” might be a better word . >> . . (but then, when talking about cars, >> I refer to the period from the early 70s to the mid 90s as “the Great >> Emasculation” . . .) > > Heh - the main thing to remember about PDF is that it is designed to be a > description of what a postscript interpreter would output before things > get rasterized. The idea is that it is a flat sequence of things to render > and thus doesn't require the 'overhead' of a full programming language VM > to do so. Of course, whilst it is that, it has also become a rather > complicated > on-disk data structure. That’s not making me dislike it less :) >> My first attempt seemed to work, save for an approximately 25% size >> reduction I can’t explain. more below . . . >> I get a graphic of the same size as the pdf started, but the image is >> about 3/4 the original >> size. The rest is transparent area. >> My screen density is 108.79, but livecode doesn’t know that at the >> user code level, does it? >> However, that reduction *is* similar to 72/108.79 . . > > Physical screen density is irrelevant here - the engine uses a fixed > notion of 72dpi... The 3/4 reduction suggests something PDF side is actually > using 96dpi (72/96 = 3/4)... Perhaps Monte could chime in and comment? > > It might be you just have to adjust the zoom factor to scale up the PDF > slightly more so it fills the rect you want. I’m thinking that a variable density would be derivable here. Just increasing the zoom seem likely to do it, though: I start with a 612 wide pdf widget (8.5”), zoom it 400%, and get a graphic 4x612 wide. However, only the left and top 3/4 or so of the graphic is used, With the rest being blank. The right and bottom are transparent. On top of that, when I change the width back to 612, the resolution is apparently downscaled with it. ___ 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: OT: Catalina - the end of ad hoc & in-house development?
I just wanted to chime in on singing the praises for Matthias’ tool as well. It has made code-signing and notarizing Mac applications so easy and fast for me. And it has a feature that allows it to work with the third party tool DropDMG (which I already used)… so even more amazing! A huge gift to anyone using LC for Mac development. (He has some other free tools which are also excellent.) -- Scott Morrow Elementary Software (Now with 20% less chalk dust!) web https://elementarysoftware.com/ email sc...@elementarysoftware.com booth 1-800-615-0867 -- > On Sep 7, 2019, at 8:27 AM, J. Landman Gay via use-livecode > wrote: > > I can't recommend Matthias' tool enough, it can do all Apple requires with a > click. > > Notarization does not go through Apple's approval process, no human ever sees > it, it's entirely automated. It simply adds a token that proves you are a > verified developer in good standing. Once that token is "stapled" to your > app, Gatekeeper won't object when the app is opened. If you choose not to > embed the token then users do need an internet connection so that Apple's > servers can verify the token. Matthias' Notarization Helper does both > notarization and stapling. > > However, notarization only applies to Mac apps. There are no distribution > limits for those. It does not apply to iOS apps, which I believe hasn't > changed. You can still use ad hoc distribution for iOS apps as before, up to > 100 devices. > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > On September 7, 2019 6:55:45 AM JJS via use-livecode > wrote: > >> I forgot, it was Mattias Rebbe who wrote the notarizing app which you >> can you fro free, aint that great! >> >> He also made an excellent lesson which is on lessons.livecode.com >> >> >> Op 7-9-2019 om 13:36 schreef JJS via use-livecode: >>> Well said. >>> >>> There is help on this. >>> >>> On of the list members will jump in i guess and he made an excellent >>> tool which will help you out notarizing and all other stuff Apple >>> tries to kill you with. >>> >>> If you already have a Apple dev account (only 100$ per year) which >>> gives you the ability to help 100 people(am i correct?) (thought there >>> was an option for 1000??) then this tool will help you do these things >>> and you can go on with coding as before. >>> >>> I also put stuff on Google Play which is not intended for everybody, >>> but i use a password combination, just like banks do with their apps. >>> Their apps are also not for everyone, but only they who have an account. >>> >>> You could do that too, so only people with access credentials can >>> access the app. >>> >>> Indeed you gave a few reasons why i choose not to develop for Apple, >>> unless i can make enough money with it which compensates for it. >>> >>> >>> Jerry(Sphere) >>> >>> Op 7-9-2019 om 13:18 schreef Peter Reid via use-livecode: I've been using LiveCode as my development platform since 1999. Practically all the apps I've developed have been for in-house use by my family, friends and customers - all very low numbers of copies distributed in an informal manner. I've no interest in App Store distribution and the users of my apps trust me such that they do not need my apps to be "approved" by Apple. What's more important to them is how quickly I can release new apps and new versions of existing apps. Up to and including macOS Mojave my users can run my apps with the minor inconvenience of having to right-click an app and approve its use, just once. With macOS Catalina, if I understand things, it's not so simple, instead these are the options: 1. Code-sign and notarise my apps – I'm not interested in this for my kind of apps which are essentially in-house/at home developments. 2. Using an active Internet connection, go through the right-click technique as now not just once, but EVERY time the app is opened. In the past the 'Security & Privacy' General tab had a 3rd option for the setting 'Allow apps downloaded from:' which allowed you to install and use apps from any source. It seems that this is not possible with Catalina. So with Catalina my users will need an Internet connection and will have to go through the right-click authorisation process every time they open one of my apps. More seriously, it is becoming increasingly difficult to recommend the combination of the Mac plus LiveCode for app development. Up to now I've done all my app development on Mac+LC, even where the target platform is Windows or Android or Linux – I find it's simply faster, less error-prone and more pleasant with the Mac. However, from Catalina onwards even simple little utility apps, created for
Re: Hactoberfest is coming...
Just want to point out a good candidate for pull requests here. Ripe for some sample xtalk code: https://github.com/EricAlcaide/Rosetta_Project -- Mark Wieder ahsoftw...@gmail.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
Re: OT: Catalina - the end of ad hoc & in-house development?
I will add that this situation is not unique to LC, it will apply to any environment that creates a compiled app. I still think that LC will be an optimal choice given the ease of development - especially with the way Mac apps are packaged (everything can be inside the .app folder). Thanks, 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: OT: Catalina - the end of ad hoc & in-house development?
I can't recommend Matthias' tool enough, it can do all Apple requires with a click. Notarization does not go through Apple's approval process, no human ever sees it, it's entirely automated. It simply adds a token that proves you are a verified developer in good standing. Once that token is "stapled" to your app, Gatekeeper won't object when the app is opened. If you choose not to embed the token then users do need an internet connection so that Apple's servers can verify the token. Matthias' Notarization Helper does both notarization and stapling. However, notarization only applies to Mac apps. There are no distribution limits for those. It does not apply to iOS apps, which I believe hasn't changed. You can still use ad hoc distribution for iOS apps as before, up to 100 devices. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On September 7, 2019 6:55:45 AM JJS via use-livecode wrote: I forgot, it was Mattias Rebbe who wrote the notarizing app which you can you fro free, aint that great! He also made an excellent lesson which is on lessons.livecode.com Op 7-9-2019 om 13:36 schreef JJS via use-livecode: Well said. There is help on this. On of the list members will jump in i guess and he made an excellent tool which will help you out notarizing and all other stuff Apple tries to kill you with. If you already have a Apple dev account (only 100$ per year) which gives you the ability to help 100 people(am i correct?) (thought there was an option for 1000??) then this tool will help you do these things and you can go on with coding as before. I also put stuff on Google Play which is not intended for everybody, but i use a password combination, just like banks do with their apps. Their apps are also not for everyone, but only they who have an account. You could do that too, so only people with access credentials can access the app. Indeed you gave a few reasons why i choose not to develop for Apple, unless i can make enough money with it which compensates for it. Jerry(Sphere) Op 7-9-2019 om 13:18 schreef Peter Reid via use-livecode: I've been using LiveCode as my development platform since 1999. Practically all the apps I've developed have been for in-house use by my family, friends and customers - all very low numbers of copies distributed in an informal manner. I've no interest in App Store distribution and the users of my apps trust me such that they do not need my apps to be "approved" by Apple. What's more important to them is how quickly I can release new apps and new versions of existing apps. Up to and including macOS Mojave my users can run my apps with the minor inconvenience of having to right-click an app and approve its use, just once. With macOS Catalina, if I understand things, it's not so simple, instead these are the options: 1. Code-sign and notarise my apps – I'm not interested in this for my kind of apps which are essentially in-house/at home developments. 2. Using an active Internet connection, go through the right-click technique as now not just once, but EVERY time the app is opened. In the past the 'Security & Privacy' General tab had a 3rd option for the setting 'Allow apps downloaded from:' which allowed you to install and use apps from any source. It seems that this is not possible with Catalina. So with Catalina my users will need an Internet connection and will have to go through the right-click authorisation process every time they open one of my apps. More seriously, it is becoming increasingly difficult to recommend the combination of the Mac plus LiveCode for app development. Up to now I've done all my app development on Mac+LC, even where the target platform is Windows or Android or Linux – I find it's simply faster, less error-prone and more pleasant with the Mac. However, from Catalina onwards even simple little utility apps, created for short-term use, will be tedious when opening or you have to learn about the complexity of code-signing and notarising and accept slower development cycles due to the need for Apple's approval! This is quite depressing, especially since I abandoned iOS development due to Apple's distribution restrictions. Back when the iPad 2 had just been released I developed for one of my customers an app to support health & safety audits for a national UK retail chain. The app took me 15 days to develop in total. As a result of being able to field a team of 10-20 staff with iPads running my app, my customer was able to carry out 350 half-day H audits for 3 years. However I was unable to roll-out this app to other customers as the ad hoc distribution method I was using was limited to 100 iPads per year and the App Store was not appropriate for this type of app. As a result of the limitations Apple impose on tablet app distribution, recently I developed a speech-aid app just for small Android tablets and larger phones. I have not made an iOS app. This app is
Re: OT: Catalina - the end of ad hoc & in-house development?
One part you say seems incorrect. I’ve been running Catalina full time since the first developer build, and I’ve seen various combinations of problems. For the one you’re talking about, where right-click Open still doesn’t open the app, in the security control panel where it used to say open applications from anywhere, it now should show a message asking for permission to open the specific application that you just attempted to open. ___ 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: OT: Catalina - the end of ad hoc & in-house development?
Hi Peter, We are all pretty miffed about the overly restrictive nature of developing native apps. These is a lot of time wasted on the ever changing hoops one must jump through just to develop in-house or small audience apps. Not only is it pushing away developers from developing for specific device platforms, it is pushing us all to only write for the web. At least that always works, although it not as fast as we would like it to be. Send your frustrations to Apple. We can only hope they will listen and change. They did a survey of their developers a couple of months ago, and they allowed us to add comments. I found myself writing quite the rant to them about everything they need to change! We share your pain. Please know you are in good company. Cheers, 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: OT: Catalina - the end of ad hoc & in-house development?
use for free (should it be written) Op 7-9-2019 om 13:53 schreef JJS via use-livecode: I forgot, it was Mattias Rebbe who wrote the notarizing app which you can you fro free, aint that great! He also made an excellent lesson which is on lessons.livecode.com Op 7-9-2019 om 13:36 schreef JJS via use-livecode: Well said. There is help on this. On of the list members will jump in i guess and he made an excellent tool which will help you out notarizing and all other stuff Apple tries to kill you with. If you already have a Apple dev account (only 100$ per year) which gives you the ability to help 100 people(am i correct?) (thought there was an option for 1000??) then this tool will help you do these things and you can go on with coding as before. I also put stuff on Google Play which is not intended for everybody, but i use a password combination, just like banks do with their apps. Their apps are also not for everyone, but only they who have an account. You could do that too, so only people with access credentials can access the app. Indeed you gave a few reasons why i choose not to develop for Apple, unless i can make enough money with it which compensates for it. Jerry(Sphere) Op 7-9-2019 om 13:18 schreef Peter Reid via use-livecode: I've been using LiveCode as my development platform since 1999. Practically all the apps I've developed have been for in-house use by my family, friends and customers - all very low numbers of copies distributed in an informal manner. I've no interest in App Store distribution and the users of my apps trust me such that they do not need my apps to be "approved" by Apple. What's more important to them is how quickly I can release new apps and new versions of existing apps. Up to and including macOS Mojave my users can run my apps with the minor inconvenience of having to right-click an app and approve its use, just once. With macOS Catalina, if I understand things, it's not so simple, instead these are the options: 1. Code-sign and notarise my apps – I'm not interested in this for my kind of apps which are essentially in-house/at home developments. 2. Using an active Internet connection, go through the right-click technique as now not just once, but EVERY time the app is opened. In the past the 'Security & Privacy' General tab had a 3rd option for the setting 'Allow apps downloaded from:' which allowed you to install and use apps from any source. It seems that this is not possible with Catalina. So with Catalina my users will need an Internet connection and will have to go through the right-click authorisation process every time they open one of my apps. More seriously, it is becoming increasingly difficult to recommend the combination of the Mac plus LiveCode for app development. Up to now I've done all my app development on Mac+LC, even where the target platform is Windows or Android or Linux – I find it's simply faster, less error-prone and more pleasant with the Mac. However, from Catalina onwards even simple little utility apps, created for short-term use, will be tedious when opening or you have to learn about the complexity of code-signing and notarising and accept slower development cycles due to the need for Apple's approval! This is quite depressing, especially since I abandoned iOS development due to Apple's distribution restrictions. Back when the iPad 2 had just been released I developed for one of my customers an app to support health & safety audits for a national UK retail chain. The app took me 15 days to develop in total. As a result of being able to field a team of 10-20 staff with iPads running my app, my customer was able to carry out 350 half-day H audits for 3 years. However I was unable to roll-out this app to other customers as the ad hoc distribution method I was using was limited to 100 iPads per year and the App Store was not appropriate for this type of app. As a result of the limitations Apple impose on tablet app distribution, recently I developed a speech-aid app just for small Android tablets and larger phones. I have not made an iOS app. This app is low volume (in terms of number of users) and requires significant personalising in order to be effective for its users (typically they are stroke victims). I chose to deliver the app on Android because of the facility to use developer mode and because of price – Android 7in tablet plus minimal add-ons: £80, Apple iPad plus add-ons: £320. Some of my users of this app already have an iPad but they are having to buy a cheap Android tablet. Like the Mac and Catalina, the iPad and iOS is driving away potential app developers due to Apple's rigid control of the delivery mechanisms. Maybe I'm wrong, Catalina will be OK – if I am wrong, please correct me! Regards Peter -- Peter Reid Loughborough, UK ___ use-livecode mailing list use-livecode@lists.runrev.com Please
Re: OT: Catalina - the end of ad hoc & in-house development?
I forgot, it was Mattias Rebbe who wrote the notarizing app which you can you fro free, aint that great! He also made an excellent lesson which is on lessons.livecode.com Op 7-9-2019 om 13:36 schreef JJS via use-livecode: Well said. There is help on this. On of the list members will jump in i guess and he made an excellent tool which will help you out notarizing and all other stuff Apple tries to kill you with. If you already have a Apple dev account (only 100$ per year) which gives you the ability to help 100 people(am i correct?) (thought there was an option for 1000??) then this tool will help you do these things and you can go on with coding as before. I also put stuff on Google Play which is not intended for everybody, but i use a password combination, just like banks do with their apps. Their apps are also not for everyone, but only they who have an account. You could do that too, so only people with access credentials can access the app. Indeed you gave a few reasons why i choose not to develop for Apple, unless i can make enough money with it which compensates for it. Jerry(Sphere) Op 7-9-2019 om 13:18 schreef Peter Reid via use-livecode: I've been using LiveCode as my development platform since 1999. Practically all the apps I've developed have been for in-house use by my family, friends and customers - all very low numbers of copies distributed in an informal manner. I've no interest in App Store distribution and the users of my apps trust me such that they do not need my apps to be "approved" by Apple. What's more important to them is how quickly I can release new apps and new versions of existing apps. Up to and including macOS Mojave my users can run my apps with the minor inconvenience of having to right-click an app and approve its use, just once. With macOS Catalina, if I understand things, it's not so simple, instead these are the options: 1. Code-sign and notarise my apps – I'm not interested in this for my kind of apps which are essentially in-house/at home developments. 2. Using an active Internet connection, go through the right-click technique as now not just once, but EVERY time the app is opened. In the past the 'Security & Privacy' General tab had a 3rd option for the setting 'Allow apps downloaded from:' which allowed you to install and use apps from any source. It seems that this is not possible with Catalina. So with Catalina my users will need an Internet connection and will have to go through the right-click authorisation process every time they open one of my apps. More seriously, it is becoming increasingly difficult to recommend the combination of the Mac plus LiveCode for app development. Up to now I've done all my app development on Mac+LC, even where the target platform is Windows or Android or Linux – I find it's simply faster, less error-prone and more pleasant with the Mac. However, from Catalina onwards even simple little utility apps, created for short-term use, will be tedious when opening or you have to learn about the complexity of code-signing and notarising and accept slower development cycles due to the need for Apple's approval! This is quite depressing, especially since I abandoned iOS development due to Apple's distribution restrictions. Back when the iPad 2 had just been released I developed for one of my customers an app to support health & safety audits for a national UK retail chain. The app took me 15 days to develop in total. As a result of being able to field a team of 10-20 staff with iPads running my app, my customer was able to carry out 350 half-day H audits for 3 years. However I was unable to roll-out this app to other customers as the ad hoc distribution method I was using was limited to 100 iPads per year and the App Store was not appropriate for this type of app. As a result of the limitations Apple impose on tablet app distribution, recently I developed a speech-aid app just for small Android tablets and larger phones. I have not made an iOS app. This app is low volume (in terms of number of users) and requires significant personalising in order to be effective for its users (typically they are stroke victims). I chose to deliver the app on Android because of the facility to use developer mode and because of price – Android 7in tablet plus minimal add-ons: £80, Apple iPad plus add-ons: £320. Some of my users of this app already have an iPad but they are having to buy a cheap Android tablet. Like the Mac and Catalina, the iPad and iOS is driving away potential app developers due to Apple's rigid control of the delivery mechanisms. Maybe I'm wrong, Catalina will be OK – if I am wrong, please correct me! Regards Peter -- Peter Reid Loughborough, UK ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
Re: OT: Catalina - the end of ad hoc & in-house development?
Well said. There is help on this. On of the list members will jump in i guess and he made an excellent tool which will help you out notarizing and all other stuff Apple tries to kill you with. If you already have a Apple dev account (only 100$ per year) which gives you the ability to help 100 people(am i correct?) (thought there was an option for 1000??) then this tool will help you do these things and you can go on with coding as before. I also put stuff on Google Play which is not intended for everybody, but i use a password combination, just like banks do with their apps. Their apps are also not for everyone, but only they who have an account. You could do that too, so only people with access credentials can access the app. Indeed you gave a few reasons why i choose not to develop for Apple, unless i can make enough money with it which compensates for it. Jerry(Sphere) Op 7-9-2019 om 13:18 schreef Peter Reid via use-livecode: I've been using LiveCode as my development platform since 1999. Practically all the apps I've developed have been for in-house use by my family, friends and customers - all very low numbers of copies distributed in an informal manner. I've no interest in App Store distribution and the users of my apps trust me such that they do not need my apps to be "approved" by Apple. What's more important to them is how quickly I can release new apps and new versions of existing apps. Up to and including macOS Mojave my users can run my apps with the minor inconvenience of having to right-click an app and approve its use, just once. With macOS Catalina, if I understand things, it's not so simple, instead these are the options: 1. Code-sign and notarise my apps – I'm not interested in this for my kind of apps which are essentially in-house/at home developments. 2. Using an active Internet connection, go through the right-click technique as now not just once, but EVERY time the app is opened. In the past the 'Security & Privacy' General tab had a 3rd option for the setting 'Allow apps downloaded from:' which allowed you to install and use apps from any source. It seems that this is not possible with Catalina. So with Catalina my users will need an Internet connection and will have to go through the right-click authorisation process every time they open one of my apps. More seriously, it is becoming increasingly difficult to recommend the combination of the Mac plus LiveCode for app development. Up to now I've done all my app development on Mac+LC, even where the target platform is Windows or Android or Linux – I find it's simply faster, less error-prone and more pleasant with the Mac. However, from Catalina onwards even simple little utility apps, created for short-term use, will be tedious when opening or you have to learn about the complexity of code-signing and notarising and accept slower development cycles due to the need for Apple's approval! This is quite depressing, especially since I abandoned iOS development due to Apple's distribution restrictions. Back when the iPad 2 had just been released I developed for one of my customers an app to support health & safety audits for a national UK retail chain. The app took me 15 days to develop in total. As a result of being able to field a team of 10-20 staff with iPads running my app, my customer was able to carry out 350 half-day H audits for 3 years. However I was unable to roll-out this app to other customers as the ad hoc distribution method I was using was limited to 100 iPads per year and the App Store was not appropriate for this type of app. As a result of the limitations Apple impose on tablet app distribution, recently I developed a speech-aid app just for small Android tablets and larger phones. I have not made an iOS app. This app is low volume (in terms of number of users) and requires significant personalising in order to be effective for its users (typically they are stroke victims). I chose to deliver the app on Android because of the facility to use developer mode and because of price – Android 7in tablet plus minimal add-ons: £80, Apple iPad plus add-ons: £320. Some of my users of this app already have an iPad but they are having to buy a cheap Android tablet. Like the Mac and Catalina, the iPad and iOS is driving away potential app developers due to Apple's rigid control of the delivery mechanisms. Maybe I'm wrong, Catalina will be OK – if I am wrong, please correct me! Regards Peter -- Peter Reid Loughborough, UK ___ 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 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription
Re: high resolution when printing to pdf, either from images or pdf widgets
On 2019-09-06 21:10, Dr. Hawkins via use-livecode wrote: On Aug 28, 2019, at 12:07 AM, Mark Waddingham via use-livecode wrote: On 2019-08-27 17:24, Dr. Hawkins via use-livecode wrote: I'm not entirely clear what Monte meant by 'print to pdf directly' in one of those comments... The 'print to pdf' mechanism in the engine isn't really any different from the normal printing mechanism, its just that rather than funnel the sequence of paths, images, text being rendered through the system printer it funnels it through libcairo's (https://cairographics.org/) PDF output functionality. Can this be adjusted for higher resolution? *is* there a way to send out at full resolution? I'm not sure I entirely follow - PDF is primarily a vector format so there is 'resolution' as such. In regards to images then the engine/pdfprinter tries to preserve the original image when printing - so if you print a large JPEG scaled down to 100x100, the original JPEG will be passed into the PDF and then that will be scaled down when rendered (i.e. as much information in the original is preserved in the output). I don’t need it to be the original, but rather visually indistinguishable. Then that changes things slightly - particularly if your originals are scans which contain images rather than vectors... In this case, the render the PDF at a larger size and scale down approach should be able to give you want you want. As I think about it, I don’t think I’ve ever said *anything* nice about pdf. I’ve generally called it a bastardization of postscript, but in this case, “castration” might be a better word . . . (but then, when talking about cars, I refer to the period from the early 70s to the mid 90s as “the Great Emasculation” . . .) Heh - the main thing to remember about PDF is that it is designed to be a description of what a postscript interpreter would output before things get rasterized. The idea is that it is a flat sequence of things to render and thus doesn't require the 'overhead' of a full programming language VM to do so. Of course, whilst it is that, it has also become a rather complicated on-disk data structure. My first attempt seemed to work, save for an approximately 25% size reduction I can’t explain. more below . . . I get a graphic of the same size as the pdf started, but the image is about 3/4 the original size. The rest is transparent area. My screen density is 108.79, but livecode doesn’t know that at the user code level, does it? However, that reduction *is* similar to 72/108.79 . . Physical screen density is irrelevant here - the engine uses a fixed notion of 72dpi... The 3/4 reduction suggests something PDF side is actually using 96dpi (72/96 = 3/4)... Perhaps Monte could chime in and comment? It might be you just have to adjust the zoom factor to scale up the PDF slightly more so it fills the rect you want. Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ 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
OT: Catalina - the end of ad hoc & in-house development?
I've been using LiveCode as my development platform since 1999. Practically all the apps I've developed have been for in-house use by my family, friends and customers - all very low numbers of copies distributed in an informal manner. I've no interest in App Store distribution and the users of my apps trust me such that they do not need my apps to be "approved" by Apple. What's more important to them is how quickly I can release new apps and new versions of existing apps. Up to and including macOS Mojave my users can run my apps with the minor inconvenience of having to right-click an app and approve its use, just once. With macOS Catalina, if I understand things, it's not so simple, instead these are the options: 1. Code-sign and notarise my apps – I'm not interested in this for my kind of apps which are essentially in-house/at home developments. 2. Using an active Internet connection, go through the right-click technique as now not just once, but EVERY time the app is opened. In the past the 'Security & Privacy' General tab had a 3rd option for the setting 'Allow apps downloaded from:' which allowed you to install and use apps from any source. It seems that this is not possible with Catalina. So with Catalina my users will need an Internet connection and will have to go through the right-click authorisation process every time they open one of my apps. More seriously, it is becoming increasingly difficult to recommend the combination of the Mac plus LiveCode for app development. Up to now I've done all my app development on Mac+LC, even where the target platform is Windows or Android or Linux – I find it's simply faster, less error-prone and more pleasant with the Mac. However, from Catalina onwards even simple little utility apps, created for short-term use, will be tedious when opening or you have to learn about the complexity of code-signing and notarising and accept slower development cycles due to the need for Apple's approval! This is quite depressing, especially since I abandoned iOS development due to Apple's distribution restrictions. Back when the iPad 2 had just been released I developed for one of my customers an app to support health & safety audits for a national UK retail chain. The app took me 15 days to develop in total. As a result of being able to field a team of 10-20 staff with iPads running my app, my customer was able to carry out 350 half-day H audits for 3 years. However I was unable to roll-out this app to other customers as the ad hoc distribution method I was using was limited to 100 iPads per year and the App Store was not appropriate for this type of app. As a result of the limitations Apple impose on tablet app distribution, recently I developed a speech-aid app just for small Android tablets and larger phones. I have not made an iOS app. This app is low volume (in terms of number of users) and requires significant personalising in order to be effective for its users (typically they are stroke victims). I chose to deliver the app on Android because of the facility to use developer mode and because of price – Android 7in tablet plus minimal add-ons: £80, Apple iPad plus add-ons: £320. Some of my users of this app already have an iPad but they are having to buy a cheap Android tablet. Like the Mac and Catalina, the iPad and iOS is driving away potential app developers due to Apple's rigid control of the delivery mechanisms. Maybe I'm wrong, Catalina will be OK – if I am wrong, please correct me! Regards Peter -- Peter Reid Loughborough, UK ___ 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
