April 2019 - Pharo-users - lists.pharo.org

A4BP and BpmFlow

by BrunoBB

Serge, I just created another thread to talk about both projects (we can discuss all here as Norbert request): A4BP https://github.com/A4BP BpmFlow https://github.com/brunobuzzi/BpmFlow Regards, Bruno -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 20, 2019

Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

by Norbert Hartl

I agree to everything Esteban said. It is about options. And Web is not the answer to everything, quite to contrary. For us Web is a limitation of power, you struggle mostly with backend connectivity (reaching out for your objects) and if you want to do something nice you end up doing it in javascript with a lot of libraries. It is hard to write something nice in a web environment and maintenance is hell. Norbert > Am 20.04.2019 um 10:43 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > Hi, > > First, your examples are biased :) > Still, you do not get the point: the point is that not everything has same requirements. Pharo is a tool to allow users to provide answers in a general cases, not just the two or twenty you can think about. > > Also, to counter your âCaseâ, here what I think: > - âMostâ applications nowadays have autoupdate mechanism that works perfectly fine to keep the applications up to date. Pharo in particular is particularly suitable for this kind of behaviour (I implemented this autoupdate mechanisms ten years ago, when autoupdate was still not âa thingâ). > - By doing a web application you may âsave" the distribution of updates version better, but you are âbuyingâ the cost of maintenance of an hybrid application that will relyâ¦ guess what? In third party frameworks! (Starting for JQuery, but a lot others if you want your app to look modern and cool). > - Tablets: yes this is a constraint (still, is just a constraint not present âin general"). But if you think a web application will work out of the box in a tablet you are fooling yourself (thinking on UX here). > - âPrepare 3 new imagesâ: if you are doing this manually today, you are doing something wrong. Also, if you need to install your images from scratch for each new user (instead just copying them), you are also doing something wrong. > > Let me put this counter example: Some years ago before I came to work for pharo I made this app called âthe lawsuit trackerâ to a legal office in Argentina. Since they had two offices in different regions I proposed a web application as a first solution which they rejected because âis uncomfortableâ. So I took wha I had in hand there and I made an app that mixed Magritte with Glamour (this was the origin of Voyage framework, btw). > - I added an autoupdate mechanism (they query for packages in a particular ftp location and they install them if new are found), > - local configuration was in an external file. > - I packaged it a âone-clickâ image with some extensions to verify which libc they where using (they target was to move to linux from windows in some couple of years). > > And I "installed itâ by sending a mail saying âdownload this, unpack and clickâ. > > So, each time there was a new version I was producing the same (with a script), and already installed versions were updating automatically. > > (Ah, btw I was collecting errors by fuelizing them and saving them in the database, so I was able to dig into errors later). > > This was 2011. > By 2012 I came to work for Pharo. > > Last time I went to Argentina (last year) I talked with the guy that is responsible of doing the âtechnical serviceâ of that place (he is a friend of mine): they are still using the same application (and very happy with it). > In the same time they opened two new offices so the user number passed from 18 to 35. > They completed the migration to linux. > > Everything is still working: > - Pharo 1.4 > - Stack VM > - MongoDB 3 to centralise information over a secure connection. > > Soâ¦ I have a very successful installation of a Pharo desktop application (even in moments were doing this was not easy, I needed to hack a lot to âcloseâ the image). > And not an hypothetical case, a real life case. > > Still: I DO NO SAY THIS SHOULD BE THE GENERAL CASE. > I say this has to be possible. > And I also say: there is a lot more use cases out there when this âwebâ answer just does not applies. > And of course there are other tons of cases were the web application is the right solution. > Why you want to constraint yourself to just one solution? > > When you develop an application you have to decide the best architecture possible taking into account the constraints you have, not some ideas of how things should be. > > Esteban > >> On 19 Apr 2019, at 23:50, TedVanGaalen <tedvga(a)gmail.com> wrote: >> >> Hi Esteban >> let me write an example: (lots of time at the moment) >> -------- >> Hypothetical CASE 1 Stand Alone Solution: >> >> Currently it's just a pilot/study project, but let's assume for a moment >> that after a year so of really hard working on it in Pharo, I finally >> completed my dental application system, that is, as as a stand-alone desktop >> application... >> >> After splatting a few initial bugs, the dental clinic is happy with my new >> dental application, and they paid my bill. Mods were relatively easy to >> implement, because it is Smalltalk, not to mention the fantastic debugger >> facilities, simply very cool. >> >> They need to run the app simultaneously on 4 computers: that is 4 stand >> alone apps running their own separated Smalltalk images. Using a Postgress >> server as a DB on one of their PCs tied everything together. Apart from >> having to install live Smalltalk images om each computer, backing them up >> etc. not much of a problem, one would think, right? So far so good. ...apart >> from having to install and maintain the app on each and every computer they >> use, that is... >> >> Two weeks later after my app went real: The clinic is expanding and another >> 3 computers will be added soon, meaning yet even more to install and >> maintain. Hey! also a new update of Pharo arrives, I need to update 7 images >> import my apps packages in the new images again. ( let alone the many system >> updates on especially Windows machines) Test if everything works ok again >> etc. Having no down-time is crucial: all done outside of the clinic's >> working hours, of course. Great. >> >> Oh, I almost forgot: they will install a iPads and/or Android tablets soon, >> which will mounted close near each patient chair. They do that anyway >> because analytical imaging apps and a drill controlling app of other firms >> run on these tablets. They would be happy if they could run my dental app on >> these tablets too, so they don't have walk back and forth to their PCs all >> the time. >> >> Jikes! Now I am really stuck! Because I wrote a stand alone app that doesn't >> run on these tablets! What can I do? >> Write special versions of my app for Androids and iPads? Impossible! this >> would take me a year or so. Nightmare. >> >> In the end the clinic dumped my app and thus me, and bought another app from >> another firm, which runs on all devices because it is a web app. How could I >> be so stupid not to make it a web browser app in the first place? >> -------- >> Hypothetical CASE 2: App as Web Browser App: >> >> Took a more modern approach: programmed my app for user access via a web >> browser, A web browser is, if you really look at it, in fact nothing more >> than a very advanced user terminal with endles GUI possibilities. Which btw >> allowed me to style the app esthetically in any way my customer likes. Now >> the cool thing is, on many devices, whether PCs, Macs, Android and Apple >> tablets and Phones the user GUI presentation and interaction is nearly >> identical. Which implies, I have to write my dental app only once, and it >> will run on any device that is connected to an intranet or internet. Not >> only that, there is just *one* single Pharo Image running instead of many >> stand alone apps on an ever changing nr of computers. .When installing a new >> Pharo version or update the app, I test it on another Pharo/Seaside server >> and can switch seamlessly between the two. The dental clinic is happy >> because it runs flawlessly on all devices they have and expanding or >> shrinking the number of devices is no problem. Not only that, In case of >> problems one can switch in no time to the shadow server app so we have >> continuity here. >> >> There is another important advantage as well. The users interacts with the >> app in a browser window only, (a thin client) that means they don't have >> access to the real application, that is, the delicate Smalltalk image of the >> Pharo/Seaside server app which runs 24/7 on a reasonably fast computer in a >> locked room with an emergency power supply of course, together with its >> friend the Database, and the room is only accessible by a responsible >> employee(s). >> >> I am happy too, not only because the customer is, but also because I avoided >> a nightmare and can do maintenance and updates, say, in 5 % of the time >> needed when I had to do maintenance for e.g. 7 stand alone apps running om >> separate computers. >> --------- >> So far for my hypothetical examples, just to illustrate. >> >> Note that on the internet, each site that you might visit is of course a web >> app of its own. So you probably interact with more web apps than you'd >> realize. Note that some are really advanced like e.g. web shops like Amazon. >> There are many good websites that function really great, but a lot are >> almost depressing. You're absolutely right that a lot of it is inferior, but >> you might have noticed also that things are slowly improving. >> >> This bad quality with (still) many web apps/sites is because as you know >> these are mostly built with chaotic hybrid systems/tools and unsafe >> languages like Javascript, ever changing packages, interfaces, tools etc. >> >> Compared to that, building web apps with Pharo/Seaside is a lot more >> straight forward and reliable, because everything is done in the Smalltalk >> image. >> >> Note that the web browser is not the limit itself, but rather the web app >> using the browser GUI. You can really design and build beautiful and >> ergonomically sound web apps, because there are so many possibilities. >> >> However, the main reason for choosing to make apps as web apps is that it is >> the only way to get your app and data accessible op nearly all devices. >> Build it once and run it everywhere. >> >> You see, this is a typical application developer's perspective, not that far >> from reality, I can tell you that. >> >> Kindly asking Tool Developers to learn more about the people and their >> environment they build tools for. >> because it's not only tech but a lot of things around it too. >> >> In any case Smalltalk/Pharo/Seaside is a great to build apps with. >> Unfortunately a lot of people still don't know this. >> Kind Regards >> Ted >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > >

April 20, 2019

Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

by Esteban Lorenzano

Hi, First, your examples are biased :) Still, you do not get the point: the point is that not everything has same requirements. Pharo is a tool to allow users to provide answers in a general cases, not just the two or twenty you can think about. Also, to counter your âCaseâ, here what I think: - âMostâ applications nowadays have autoupdate mechanism that works perfectly fine to keep the applications up to date. Pharo in particular is particularly suitable for this kind of behaviour (I implemented this autoupdate mechanisms ten years ago, when autoupdate was still not âa thingâ). - By doing a web application you may âsave" the distribution of updates version better, but you are âbuyingâ the cost of maintenance of an hybrid application that will relyâ¦ guess what? In third party frameworks! (Starting for JQuery, but a lot others if you want your app to look modern and cool). - Tablets: yes this is a constraint (still, is just a constraint not present âin general"). But if you think a web application will work out of the box in a tablet you are fooling yourself (thinking on UX here). - âPrepare 3 new imagesâ: if you are doing this manually today, you are doing something wrong. Also, if you need to install your images from scratch for each new user (instead just copying them), you are also doing something wrong. Let me put this counter example: Some years ago before I came to work for pharo I made this app called âthe lawsuit trackerâ to a legal office in Argentina. Since they had two offices in different regions I proposed a web application as a first solution which they rejected because âis uncomfortableâ. So I took wha I had in hand there and I made an app that mixed Magritte with Glamour (this was the origin of Voyage framework, btw). - I added an autoupdate mechanism (they query for packages in a particular ftp location and they install them if new are found), - local configuration was in an external file. - I packaged it a âone-clickâ image with some extensions to verify which libc they where using (they target was to move to linux from windows in some couple of years). And I "installed itâ by sending a mail saying âdownload this, unpack and clickâ. So, each time there was a new version I was producing the same (with a script), and already installed versions were updating automatically. (Ah, btw I was collecting errors by fuelizing them and saving them in the database, so I was able to dig into errors later). This was 2011. By 2012 I came to work for Pharo. Last time I went to Argentina (last year) I talked with the guy that is responsible of doing the âtechnical serviceâ of that place (he is a friend of mine): they are still using the same application (and very happy with it). In the same time they opened two new offices so the user number passed from 18 to 35. They completed the migration to linux. Everything is still working: - Pharo 1.4 - Stack VM - MongoDB 3 to centralise information over a secure connection. Soâ¦ I have a very successful installation of a Pharo desktop application (even in moments were doing this was not easy, I needed to hack a lot to âcloseâ the image). And not an hypothetical case, a real life case. Still: I DO NO SAY THIS SHOULD BE THE GENERAL CASE. I say this has to be possible. And I also say: there is a lot more use cases out there when this âwebâ answer just does not applies. And of course there are other tons of cases were the web application is the right solution. Why you want to constraint yourself to just one solution? When you develop an application you have to decide the best architecture possible taking into account the constraints you have, not some ideas of how things should be. Esteban > On 19 Apr 2019, at 23:50, TedVanGaalen <tedvga(a)gmail.com> wrote: > > Hi Esteban > let me write an example: (lots of time at the moment) > -------- > Hypothetical CASE 1 Stand Alone Solution: > > Currently it's just a pilot/study project, but let's assume for a moment > that after a year so of really hard working on it in Pharo, I finally > completed my dental application system, that is, as as a stand-alone desktop > application... > > After splatting a few initial bugs, the dental clinic is happy with my new > dental application, and they paid my bill. Mods were relatively easy to > implement, because it is Smalltalk, not to mention the fantastic debugger > facilities, simply very cool. > > They need to run the app simultaneously on 4 computers: that is 4 stand > alone apps running their own separated Smalltalk images. Using a Postgress > server as a DB on one of their PCs tied everything together. Apart from > having to install live Smalltalk images om each computer, backing them up > etc. not much of a problem, one would think, right? So far so good. ...apart > from having to install and maintain the app on each and every computer they > use, that is... > > Two weeks later after my app went real: The clinic is expanding and another > 3 computers will be added soon, meaning yet even more to install and > maintain. Hey! also a new update of Pharo arrives, I need to update 7 images > import my apps packages in the new images again. ( let alone the many system > updates on especially Windows machines) Test if everything works ok again > etc. Having no down-time is crucial: all done outside of the clinic's > working hours, of course. Great. > > Oh, I almost forgot: they will install a iPads and/or Android tablets soon, > which will mounted close near each patient chair. They do that anyway > because analytical imaging apps and a drill controlling app of other firms > run on these tablets. They would be happy if they could run my dental app on > these tablets too, so they don't have walk back and forth to their PCs all > the time. > > Jikes! Now I am really stuck! Because I wrote a stand alone app that doesn't > run on these tablets! What can I do? > Write special versions of my app for Androids and iPads? Impossible! this > would take me a year or so. Nightmare. > > In the end the clinic dumped my app and thus me, and bought another app from > another firm, which runs on all devices because it is a web app. How could I > be so stupid not to make it a web browser app in the first place? > -------- > Hypothetical CASE 2: App as Web Browser App: > > Took a more modern approach: programmed my app for user access via a web > browser, A web browser is, if you really look at it, in fact nothing more > than a very advanced user terminal with endles GUI possibilities. Which btw > allowed me to style the app esthetically in any way my customer likes. Now > the cool thing is, on many devices, whether PCs, Macs, Android and Apple > tablets and Phones the user GUI presentation and interaction is nearly > identical. Which implies, I have to write my dental app only once, and it > will run on any device that is connected to an intranet or internet. Not > only that, there is just *one* single Pharo Image running instead of many > stand alone apps on an ever changing nr of computers. .When installing a new > Pharo version or update the app, I test it on another Pharo/Seaside server > and can switch seamlessly between the two. The dental clinic is happy > because it runs flawlessly on all devices they have and expanding or > shrinking the number of devices is no problem. Not only that, In case of > problems one can switch in no time to the shadow server app so we have > continuity here. > > There is another important advantage as well. The users interacts with the > app in a browser window only, (a thin client) that means they don't have > access to the real application, that is, the delicate Smalltalk image of the > Pharo/Seaside server app which runs 24/7 on a reasonably fast computer in a > locked room with an emergency power supply of course, together with its > friend the Database, and the room is only accessible by a responsible > employee(s). > > I am happy too, not only because the customer is, but also because I avoided > a nightmare and can do maintenance and updates, say, in 5 % of the time > needed when I had to do maintenance for e.g. 7 stand alone apps running om > separate computers. > --------- > So far for my hypothetical examples, just to illustrate. > > Note that on the internet, each site that you might visit is of course a web > app of its own. So you probably interact with more web apps than you'd > realize. Note that some are really advanced like e.g. web shops like Amazon. > There are many good websites that function really great, but a lot are > almost depressing. You're absolutely right that a lot of it is inferior, but > you might have noticed also that things are slowly improving. > > This bad quality with (still) many web apps/sites is because as you know > these are mostly built with chaotic hybrid systems/tools and unsafe > languages like Javascript, ever changing packages, interfaces, tools etc. > > Compared to that, building web apps with Pharo/Seaside is a lot more > straight forward and reliable, because everything is done in the Smalltalk > image. > > Note that the web browser is not the limit itself, but rather the web app > using the browser GUI. You can really design and build beautiful and > ergonomically sound web apps, because there are so many possibilities. > > However, the main reason for choosing to make apps as web apps is that it is > the only way to get your app and data accessible op nearly all devices. > Build it once and run it everywhere. > > You see, this is a typical application developer's perspective, not that far > from reality, I can tell you that. > > Kindly asking Tool Developers to learn more about the people and their > environment they build tools for. > because it's not only tech but a lot of things around it too. > > In any case Smalltalk/Pharo/Seaside is a great to build apps with. > Unfortunately a lot of people still don't know this. > Kind Regards > Ted > > > > > > > > > > > > > > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

April 20, 2019

Small Pharo developer contract

by ducasse

Hi guys This may interest some of you. Stef

April 20, 2019

Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

by Offray Vladimir Luna CÃ¡rdenas

Hi, [...] On 19/04/19 4:50 p. m., TedVanGaalen wrote: > However, the main reason for choosing to make apps as web apps is that it is > the only way to get your app and data accessible op nearly all devices. > Build it once and run it everywhere. > > You see, this is a typical application developer's perspective, not that far > from reality, I can tell you that. [...] I'm with Esteban on this. Most of the apps I use are not web apps (not even for mail, where my client is Thunderbird most of the time). My thesis was wrote in a desktop app (TeXstudio), my outlining program (Leo), the text editor (text adept), the PDF reader (okular), the desktop UI (Awesome) and I could go on. The only exception is my Markdown editor (and of course the web browser), which is Zettlr, which is an electron app. BTW, Atom and other web based editors running electron are kind of slow compared with native desktop apps (with the exception of the pretty focused and light Zettlr). The only think I like from the web ubiquity is the "universal" good rendering for fronts and graphics, but as a paradigm for development is pretty fractured and lacks cohesion. There are some efforts, like PhosphorJS to have sane web interface. For me is kind of awesome how the last decades of development are kind of reinventing the desktop in the web... I would like something like Guacamole[1] for running "Pharo containers" and native desktop UIs in the web, without investing a lot of time on rewriting the desktop in the web, but having the possibility to run a self contained desktop app when connectivity is low, like in many places of the Global South, where most of the half+ of humanity without Internet lives, and even those of us who have it, know that net in only reliable on major cities of the Global South and not in every place of such cities. [1] https://guacamole.apache.org/ So the "typical application developer's perspective" depends on the place where such "typical" person is located. Having a robust native app looking for Pharo will be a strong selling point for the future for the humanity that will be connecting to the web in the decades to come (I just whish a way to embed web components in the GTK native app, but I think that such combinations will be possible). Cheers, Offray

April 20, 2019

Re: [Pharo-users] glamorous toolkit forum/maillist

by Ben Coman

On Sat, 20 Apr 2019 at 05:51, Steve Quezadas <steveeq1(a)gmail.com> wrote: > Forgive my ignorance, but what is Discord? > Click the link near the top of page... http://pharo.org/community cheers -ben >

April 20, 2019

Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

by CÃ©drick BÃ©ler

Doing a web only app is a solution but not the best one to me. And there are ways to update a desktop app, especially if pharo based. Ok for mobile but I think also this deserve specific dev. The holy grail of writing once deploy everywhere is nice but in my limited experience this is more a question of compromise and at the end you get something pretty annoying and inconsistent. If you cannot develop native (or even hybrid) on tablet, then pure web is an option but not a cool one. Last point is I want now distributed apps that work offline and online. Itâs doable with web apps but kind of more difficult to manage. In your hypothetical example, no connection = no app ? Another solution is using a local web server but it doesnât feel very native again. There are solutions like electron too but still, even if I find them quite nice, I cannot stand the launch time... So, to me, Iâm really happy that SPEC provides now native windows. And as you say there is seaside and all other web stack lib like zinc etc... so best of both world. My 2 cents, CÃ©drick > Le 19 avr. 2019 Ã 23:50, TedVanGaalen <tedvga(a)gmail.com> a Ã©crit : > > Hi Esteban > let me write an example: (lots of time at the moment) > -------- > Hypothetical CASE 1 Stand Alone Solution: > > Currently it's just a pilot/study project, but let's assume for a moment > that after a year so of really hard working on it in Pharo, I finally > completed my dental application system, that is, as as a stand-alone desktop > application... > > After splatting a few initial bugs, the dental clinic is happy with my new > dental application, and they paid my bill. Mods were relatively easy to > implement, because it is Smalltalk, not to mention the fantastic debugger > facilities, simply very cool. > > They need to run the app simultaneously on 4 computers: that is 4 stand > alone apps running their own separated Smalltalk images. Using a Postgress > server as a DB on one of their PCs tied everything together. Apart from > having to install live Smalltalk images om each computer, backing them up > etc. not much of a problem, one would think, right? So far so good. ...apart > from having to install and maintain the app on each and every computer they > use, that is... > > Two weeks later after my app went real: The clinic is expanding and another > 3 computers will be added soon, meaning yet even more to install and > maintain. Hey! also a new update of Pharo arrives, I need to update 7 images > import my apps packages in the new images again. ( let alone the many system > updates on especially Windows machines) Test if everything works ok again > etc. Having no down-time is crucial: all done outside of the clinic's > working hours, of course. Great. > > Oh, I almost forgot: they will install a iPads and/or Android tablets soon, > which will mounted close near each patient chair. They do that anyway > because analytical imaging apps and a drill controlling app of other firms > run on these tablets. They would be happy if they could run my dental app on > these tablets too, so they don't have walk back and forth to their PCs all > the time. > > Jikes! Now I am really stuck! Because I wrote a stand alone app that doesn't > run on these tablets! What can I do? > Write special versions of my app for Androids and iPads? Impossible! this > would take me a year or so. Nightmare. > > In the end the clinic dumped my app and thus me, and bought another app from > another firm, which runs on all devices because it is a web app. How could I > be so stupid not to make it a web browser app in the first place? > -------- > Hypothetical CASE 2: App as Web Browser App: > > Took a more modern approach: programmed my app for user access via a web > browser, A web browser is, if you really look at it, in fact nothing more > than a very advanced user terminal with endles GUI possibilities. Which btw > allowed me to style the app esthetically in any way my customer likes. Now > the cool thing is, on many devices, whether PCs, Macs, Android and Apple > tablets and Phones the user GUI presentation and interaction is nearly > identical. Which implies, I have to write my dental app only once, and it > will run on any device that is connected to an intranet or internet. Not > only that, there is just *one* single Pharo Image running instead of many > stand alone apps on an ever changing nr of computers. .When installing a new > Pharo version or update the app, I test it on another Pharo/Seaside server > and can switch seamlessly between the two. The dental clinic is happy > because it runs flawlessly on all devices they have and expanding or > shrinking the number of devices is no problem. Not only that, In case of > problems one can switch in no time to the shadow server app so we have > continuity here. > > There is another important advantage as well. The users interacts with the > app in a browser window only, (a thin client) that means they don't have > access to the real application, that is, the delicate Smalltalk image of the > Pharo/Seaside server app which runs 24/7 on a reasonably fast computer in a > locked room with an emergency power supply of course, together with its > friend the Database, and the room is only accessible by a responsible > employee(s). > > I am happy too, not only because the customer is, but also because I avoided > a nightmare and can do maintenance and updates, say, in 5 % of the time > needed when I had to do maintenance for e.g. 7 stand alone apps running om > separate computers. > --------- > So far for my hypothetical examples, just to illustrate. > > Note that on the internet, each site that you might visit is of course a web > app of its own. So you probably interact with more web apps than you'd > realize. Note that some are really advanced like e.g. web shops like Amazon. > There are many good websites that function really great, but a lot are > almost depressing. You're absolutely right that a lot of it is inferior, but > you might have noticed also that things are slowly improving. > > This bad quality with (still) many web apps/sites is because as you know > these are mostly built with chaotic hybrid systems/tools and unsafe > languages like Javascript, ever changing packages, interfaces, tools etc. > > Compared to that, building web apps with Pharo/Seaside is a lot more > straight forward and reliable, because everything is done in the Smalltalk > image. > > Note that the web browser is not the limit itself, but rather the web app > using the browser GUI. You can really design and build beautiful and > ergonomically sound web apps, because there are so many possibilities. > > However, the main reason for choosing to make apps as web apps is that it is > the only way to get your app and data accessible op nearly all devices. > Build it once and run it everywhere. > > You see, this is a typical application developer's perspective, not that far > from reality, I can tell you that. > > Kindly asking Tool Developers to learn more about the people and their > environment they build tools for. > because it's not only tech but a lot of things around it too. > > In any case Smalltalk/Pharo/Seaside is a great to build apps with. > Unfortunately a lot of people still don't know this. > Kind Regards > Ted > > > > > > > > > > > > > > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

April 19, 2019

Re: [Pharo-users] Why are package tags not proper sub-packages?

by Tim Mackinnon

Well I guess most usages are âload 3rd party baselineâ and you donât really care who owns the extension methods (all the sub-tags are normally part of the parent project anyway). If you do add any extensions to that project, you probably also donât notice they donât show up in any tags of the classes you extend (only in the containing project). Itâs subtle but probably doesnât affect execution, just readability. Tim Sent from my iPhone > On 19 Apr 2019, at 18:10, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > If that's the case, this sounds like a huge problem. I'm surprised no one > has reported it already.

April 19, 2019

Re: [Pharo-users] glamorous toolkit forum/maillist

by James Foster

Googling âWhat is Discordâ brought me to https://discordapp.com <https://discordapp.com/>. > On Apr 19, 2019, at 2:50 PM, Steve Quezadas <steveeq1(a)gmail.com> wrote: > > Forgive my ignorance, but what is Discord? > > On Thu, Apr 18, 2019 at 1:29 AM Serge Stinckwich <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>> wrote: > I think #gtoolkit channel on Discord is the best way to discuss with people. > > On Tue, Apr 16, 2019 at 6:37 PM Steve Quezadas <steveeq1(a)gmail.com <mailto:steveeq1@gmail.com>> wrote: > Is there a forum or maillist for glamorous toolkit? I can't find anything on the official website or google searches. > > > -- > Serge Stinckwicâhâ > Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) > âSorbonne University (SU) > French National Research Institute for Sustainable Development (IRD)â > Uâniversity of YaoundÃ© Iâ, Cameroun > "Programs must be written for people to read, and only incidentally for machines to execute." > https://twitter.com/SergeStinckwich <https://twitter.com/SergeStinckwich> > â

April 19, 2019

Re: [Pharo-users] glamorous toolkit forum/maillist

by Steve Quezadas

Forgive my ignorance, but what is Discord? On Thu, Apr 18, 2019 at 1:29 AM Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > I think #gtoolkit channel on Discord is the best way to discuss with > people. > > On Tue, Apr 16, 2019 at 6:37 PM Steve Quezadas <steveeq1(a)gmail.com> wrote: > >> Is there a forum or maillist for glamorous toolkit? I can't find anything >> on the official website or google searches. >> > > > -- > Serge Stinckwic > âhâ > > Int. Research Unit > on Modelling/Simulation of Complex Systems (UMMISCO) > âSorbonne University > (SU) > French National Research Institute for Sustainable Development (IRD)â > U > âniversity of YaoundÃ© Iâ, Cameroun > "Programs must be written for people to read, and only incidentally for > machines to execute." > https://twitter.com/SergeStinckwich > â >

April 19, 2019