Correction: Actually I was wrong, you dont even need to delete shortcuts to make the IDE completely inaccessible to user. The moment you create the morph that covers the Pharo window, that morph can also receive all events which means no Pharo shortcuts will be able to trigger unless of course you make the morph to return the events back to the object that can trigger the IDE tools.
And what I am describing here is not some advanced concept this is super basic Pharo development. No magic, nothing special. On Tue, Aug 23, 2016 at 11:31 PM Dimitris Chloupis <kilon.al...@gmail.com> wrote: > "Only if you think deployment means shipping your entire development > environment to users and telling them to get on with it." > > No > > Including the Pharo enviroment is a great idea because it makes remote > debugging a possibility. Pharo has tools to connect to another running > image and control its execution and debugging capabilites which give you > the massive advantage of being able to examine bugs up close and personal > without the need of the user filling bug reports. You can do this online > and offline. Thats the appeal of Pharo anyway. You user can message you > and you can connect to his image , fix the error and allow him to continue > execution without losing his live data. Try that with you dream deployment > tool. > > Actually its standard practice in deployment when something goes wrong you > are basically screwed. Fine grained error correction is not even a question > , just stone age uninstall and re install. > > Hiding the IDE from the user is very simple. > > I fail to see how Pharo is worse from pretty much every other language > that requires installation in order to work when Pharo is just a standalone > folder. > > We must be living in parallel universes. > > "All other applications written in pharo are web apps so deployment is not > an > issue." > > Why you think thats a problem for dekstop apps ? Its actually pretty > simple, pharo allows you to create a window or a frame that covers its > entire window the moment this happens the user will no longer be able to > trigger the world menu, unless he uses shortcuts which can be removed too. > > This is the approach that PharoLauncher, Phratch and DrGeo follow. > > The debugger will still trigger in case of error but then you will need a > form of error reporting anyway, unless you prefer your pharo app freezing > with no error message which obviously is not the standard practice in any > dynamic programming language. Sure if you come from C/C++ crash and burn > maybe acceptable but is not acceptable for Pharo standards. I suspect it > wont be very acceptable for your user either. > > "There may be good reasons for the lack of attention paid to the deployment > of apps but pretending there is no problem is crazy." > > We read question like this from time to time in the mailing list from > beginners but for experienced pharo coder I never read any serious > complain. > > "Also, it gives people with more limited bandwidth connections the options > of downloading the entire thing, or a highly stripped version that is much > smaller." > > There are plans to modularize pharo image , there is even an image that > offers a minimal set of libraries though its not recommended for general > consumption. It can be used as template if size is such a big concern. > > There is also project Spoon that managed to deploy Squeak (Pharo's > ancestor) apps that were down to kbs in size. But smaller you go the more > power and flexibility you sacrifice. Suffice to say devs did not care so > much about Spoon. > > Size wise zipped Pharo folder is 30mbs , probably even less if you use > 7zip or some other more efficient compression. My connection is > 100-200kbs/sec which means it does not take more than 3-4 minutes to > download. So I fail to see where is the actual problem. > > Yeah sure if you are on dial up it will take you forever but then the > whole internet will take you forever anyway. People play games that are > tens of Gigabytes in size of download and they don't complain about size. > > This whole get the IDE together with the app is no longer a Smalltalk > breakthrough anyway. > > Python the language I was coding in before porting to Pharo comes with a > ton of tools that range from inspectors, debugger, live refactoring tools > and even profilers , error reporting tools, testing tools or even > manipulation of the syntax itself through the AST module. And this is > common for most if not every dynamic language out there. > > Even games nowadays ship with their own error reporting tools, profilers, > anylitics, benchmark tools etc. and of course the usual modding tools. > > > On Tue, Aug 23, 2016 at 10:28 PM kmo <vox...@gmail.com> wrote: > >> <<Pharo has the easiest deployment in any language I have used.>> >> >> Only if you think deployment means shipping your entire development >> environment to users and telling them to get on with it. >> >> Pharo is absolutely the worst language for deployment in the world. This >> is >> why, after all these years, there have only ever been three desktop >> applications written in it - phratch, dr geo, and the a legal database >> thing. (i suppose you could be generous and include pharo launcher as >> well - >> though that's a bit incestuous). >> >> All other applications written in pharo are web apps so deployment is not >> an >> issue. >> >> There may be good reasons for the lack of attention paid to the deployment >> of apps but pretending there is no problem is crazy. >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/standalone-runtime-executable-tp4911677p4912370.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >>
