- Pharo-users - lists.pharo.org

[ANN] Bittrex API
by Ben Coman Jan. 16, 2018

Jan. 16, 2018

Thanks everyone who advised on Zinc, REST, NeoJSON, HMAC & Libsodium to help me on my way to implement an interface to the Bittrex bitcoin exchange. I've got to the point where I'm happy to make an initial 0.x release. After all my years having fun hacking around Pharo, this is my first (tiny) product. Hopefully it may grow. :) The implementation is probably closest to a Command pattern with a class per entry-point. All the v1.1 entry points are implemented except a few to deposit & withdraw money from the exchange. These are currently infrequent events for me and left for manual action. I'm optimistic that I'll add a few more exchanges so I created a github org to group them together. Contributions welcome. Please see quick start instructions here... https://github.com/Traadh/bittrex Have fun and take care... https://imgs.xkcd.com/comics/engineer_syllogism.png cheers -ben

2 3

Re: [Pharo-users] Databases
by Offray Vladimir Luna CÃ¡rdenas Jan. 16, 2018

Jan. 16, 2018

Hi, In my casoe UDBC2 and SQLite have worked pretty well, but I have a problem in the transition from Pharo 4.0 to 5.0 and UDBC that was quickly fixed once I asked for community support (if I remember was related with the location of the Sqlite binary). I could help with testing such scenario. But yes, SQLite is kind of the out of the box solution for databases in all other programming languages, so we need to be sure this experience is working for our users also (I remember one of our workshop participants complaining about how this default was even alien for Pharo). It's difficult to transmit some sense of stability in a quickly evolving software like this, but I think that is important to have some defaults working out of the box. Cheers, Offray On 15/01/18 04:13, Benoit St-Jean via Pharo-users wrote: > Subject: > Databases > From: > Benoit St-Jean <bstjean(a)yahoo.com> > Date: > 15/01/18 04:13 > > To: > "pharo-users(a)lists.pharo.org" <pharo-users(a)lists.pharo.org>, > "squeak-dev(a)lists.squeakfoundation.org" > <squeak-dev(a)lists.squeakfoundation.org> > > > Bear with me for a moment... > > First and foremost, this post is *not intended in any way* to > criticize the work of anyone who could have worked on those > packages/projects/frameworks. > > Now, I'll tell you a story to make my point. > > Often times, in public or in private, I help newcomers on Quora, IRC, > the mailing list(s) or elsewhere with various Smalltalk environments.Â > Often times, I try to be helpful getting them started on Squeak or > Pharo.Â Often times, they are just amazed by how powerful Smalltalk > is...Â > > Now, the sad part.Â Everything goes well until they just want to "code > something" to experiment and they ask me about databases... > > -How can I connect to a MySQL (or insert your favorite database here) > with Squeak/Pharo ? > > > As far as I can remember, the database connectivity with Squeak/Pharo > has always been an area where, as a Squeak/Pharo community, we suck > big time.Â I don't recall the last time I loaded a package, ran the > tests and everything was fine.Â There is almost ALWAYS something > broken with the databases packages.Â Understandibly, Squeak and Pharo > were for a long time moving targets.Â Whether it was VM changes (FFI, > NativeBoost, uFFI, 32 vs 64 bit, OS differences/problems, differences > between Squeak and Pharo, etc), code refactoring (cryptography class > name changes), the > DateAndTime/Timestamp/TimeStamp/Date(Magnitude)/Date(Timespan) were > used from one version to the other in the driver, code that was > removed by some cleanup, compiler changes/problems/incompatibilities, > etc.Â In other words, database connectivity needs some love. > > Unfortunately, it looks like there doesn't seem to be a consensus or a > shared desire to fix things *together*.Â There is duplicate effort all > over the place.Â Just as an example, I listed the various > implementations of MySQL packages that exists (I did not list the 8-9 > of them that had no code but a project listed on one of those sites).Â > So, let's say you are a newcomer and you want to connect to a MySQL > database.Â Here are the choices you are offered (and remember, as a > newcomer, you have NO clue which one to pick) : > > > Databases supported : Project name > > 1) SqueakSource > > MySQL : Automatic Object Storage To MySQL > OpenDBX > SqueakDBX > > > 2) SmalltalkHub > > DBX/Talk / DBXDatabaseModel > GlorpDriverMySQL > PharoExtras / ODBC > DBXTalk / Garage > UDBC > UDBC2 > > 3) GitHub.io > > dbxtalk > > 4) GitHub > > pharo-rdbms/garage > > Now, let's say you picked one package.Â In some cases, if you are > lucky, the code will load without any problem or warning.Â And then, > you run the tests.Â That is where it almost *always* breaks! > > Today, I tried to load *each and everyone of them* in a Pharo 6.1 > (Windows) image : none of them worked right out of the box! > > In other words, that newcomer I told you about just goes from "WOW!!!" > to "WHAT?!?!" in 10 seconds.Â People are usually not so impressed with > a TestRunner that fails a gazillion unit tests... > > So, now the nice part... > > Database connectivity is, in my humble opinion, a MUST for Pharo and > Squeak. I think it's about time we do *something* about the current > state of this mess.Â There are enough brilliant and talented people in > the Squeak and Pharo communities to fix this situation.Â At least, we > could start *talking* about it if we want to address the problems.Â > Ideally, we would come up with a will to change things and establish a > plan. > > In a perfect world, we'd have something like JDBC (or some kind of > Smalltalk universal driver) in Smalltalk for native drivers.Â Plus > ODBC connectivity. Plus it would have to work right-out-of-the-box.Â > Plus documentation that has at least an example with > Connect/SELECT/UPDATE/DELETE/CREATE/DROP/disconnect simple examples to > get newbies started.Â Plus a solid suite of tests to beat the sh*t out > of that code. Plus a compatibility layer for Squeak/Pharo > differences.Â To that regard, Glorp is an example to follow!Â IMHO, > it's about time we share stuff to maximize our efforts! > > As I told someone recently, it's about time we do something about > databases (RDBMS).Â And as I told that person, I don't mind writing > Smalltalk code and SQL scripts and running tests.Â Even do performance > testing.Â My MySQL Server currently has close to 1 billion records to > torture the MySQL driver if needed.Â And I can also work on SQLite.Â > And Oracle.Â And DB/2.Â And MySQL Server.Â And I don't mind installing > other RDBMS on my machine and test other driver ports.Â Now, it's just > a matter of knowing if we all want to work together. > > As for OpenDBX/DBX, I'm not sure.Â Having another dependency (and C > code) that we more or less control doesn't inspire me.Â I have yet to > see how DBX/OpenDBX gives me any advantage over, say, ODBC... > > As I said, it's time to discuss! > > Anyone interested? > Â > -----------------

1 0

[ann] gt connector
by Tudor Girba Jan. 16, 2018

Jan. 16, 2018

Hi, Towards the end of last year we worked on GT Connector, a new kind of interface that allows us to exercise and test the limits (or the lack thereof) of Bloc. It looks like this: You can see it in action here: https://twitter.com/feenkcom/status/936109463462965248 In the current implementation, the Connector allows us to navigate and connect example methods. The focus is not on examples, but on the connections. We used examples because the engine was already around and offered us a nice use case. We want to extend it in the near future to other kinds of objects. There are a couple of things that are worth noting: â¢ The editor works live, and the connection points appear and disappear as you type. â¢ The layout of the editor elements is based on a tree-based graph layout that only works with constrains (no actual visible edges between the editor elements). â¢ The editor works live, so adding new elements to the scene properly rearranges the scene. â¢ But, perhaps, the most exciting part is the fact that the lines connect an element from inside the text editor element with another that lives outside of the editor element. All these validate the architecture of Bloc of having exactly one rendering tree. It was not an obvious goal a couple of years ago, but we are really happy that it works. To put it in perspective, let's compare this with the html world. Text is text is rendered through the DOM tree. If you want graphics you might use something like SVG which comes with its own tree. However, these are two distinct worlds, and you cannot go from one to another, or at least not easily. This is the case in most engines we looked at. Why is this important? One thing we learn in the Smalltalk world is that covering the same space with less concepts opens up a whole dimension of creativity that is simply not possible outside of it. The goal with Bloc is to enable new kinds of user interfaces. As we are late to the game of modern interfaces, even though the field was invented in Smalltalk, our only chance to take the lead again is to rethink the model. Let's look at the Connector again. In most user interfaces we have panes on the outside, and visuals confined within the boundaries of those panes. Interestingly, we can trace this pattern to the very first Smalltalk interfaces. In the Connector interface we have no boundaries with text and visualization being intertwined to form a new kind of workflow. Talking about workflows, we now have two distinct and novel ways to explore examples: one is Connector, and the other one is the expandable code editor. For example, the scene from above looks like this in the example expanding editor: Both of these interfaces are not found in other infrastructures, and yet they were both inexpensive to implement in Bloc. We believe this will have a deep impact for all sorts of interfaces, and especially for the IDE. If you are interested in more details related to the IDE, take a look at the following paper from 2015: http://scg.unibe.ch/archive/papers/Girb15b-PervasiveSoftwareVisualizations.… Please let us know what you think. Cheers, The feenk team -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

7 6

Iceberg Branching
by Evan Donahue Jan. 15, 2018

Jan. 15, 2018

What's the current status of branching? I can create, switch, and commit to branches, but my attempts to load code from other branches throws errors. Since branching isn't thoroughly documented in the readme yet afaict, I just wanted to check whether it was known to be 'under development' and I should leave it alone, or whether I should try to be more proactive about reporting the errors I'm getting. Thanks, Evan

3 3

[ANN] OpenSSL-Pharo works on Windows
by Pierce Ng Jan. 15, 2018

Jan. 15, 2018

Hi all, OpenSSL-Pharo now works on Windows. Tested on Windows 10 with a fresh 32-bit Pharo 6.1 zip package downloaded from pharo.org. On Windows this library uses libeay.dll which is bundled with the Pharo VM. Metacello new baseline: 'OpenSSL'; smalltalkhubUser: 'PierceNg' project: 'OpenSSL-Pharo'; load. Pierce

8 10

Re: [Pharo-users] Databases
by Sven Van Caekenberghe Jan. 15, 2018

Jan. 15, 2018

BenoÃ®t, Yes, of course databases are important and I know many users ask for them, but on the other hand, the low development activity can only mean that there is not enough interest (or some existing solutions work well enough). There are many SQL and non-SQL databases out there, as well as many, incompatible Smalltalk implementations. I do not believe that there can be one magic solution to fix all problems everywhere. Remember that setting up a database is often a challenge by itself. I do not think the current situation is bad, it is just confusing. Making a good meta overview (i.e. documentation writing) and testing solutions would already help many people. To add to your list, I recently wrote a new PostgreSQL client, P3, that is using only TCP networking (no native library mess). It supports most recent Pharo distributions. https://github.com/svenvc/P3 P3 can be used under Glorp. Glorp in still being maintained and in active use, but could use some love in the promotion department. Here is some documentation http://files.pharo.org/books-pdfs/booklet-Glorp/2017-05-02-Glorp-Spiral.pdf https://medium.com/concerning-pharo/reddit-st-in-10-cool-pharo-classes-1b53… https://github.com/SquareBracketAssociates/Booklet-Reddit (updated version of the former) https://bintray.com/squarebracketassociates/wip/download_file?file_path=red… Actually, few languages have as nice an Object Relational Mapper as Glorp. There is also Voyage that seems quite popular. Sven > On 15 Jan 2018, at 10:13, Benoit St-Jean via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > From: Benoit St-Jean <bstjean(a)yahoo.com> > Subject: Databases > Date: 15 January 2018 at 10:13:10 GMT+1 > To: "pharo-users(a)lists.pharo.org" <pharo-users(a)lists.pharo.org>, "squeak-dev(a)lists.squeakfoundation.org" <squeak-dev(a)lists.squeakfoundation.org> > Reply-To: Benoit St-Jean <bstjean(a)yahoo.com> > > > Bear with me for a moment... > > First and foremost, this post is *not intended in any way* to criticize the work of anyone who could have worked on those packages/projects/frameworks. > > Now, I'll tell you a story to make my point. > > Often times, in public or in private, I help newcomers on Quora, IRC, the mailing list(s) or elsewhere with various Smalltalk environments. Often times, I try to be helpful getting them started on Squeak or Pharo. Often times, they are just amazed by how powerful Smalltalk is... > > Now, the sad part. Everything goes well until they just want to "code something" to experiment and they ask me about databases... > > -How can I connect to a MySQL (or insert your favorite database here) with Squeak/Pharo ? > > > As far as I can remember, the database connectivity with Squeak/Pharo has always been an area where, as a Squeak/Pharo community, we suck big time. I don't recall the last time I loaded a package, ran the tests and everything was fine. There is almost ALWAYS something broken with the databases packages. Understandibly, Squeak and Pharo were for a long time moving targets. Whether it was VM changes (FFI, NativeBoost, uFFI, 32 vs 64 bit, OS differences/problems, differences between Squeak and Pharo, etc), code refactoring (cryptography class name changes), the DateAndTime/Timestamp/TimeStamp/Date(Magnitude)/Date(Timespan) were used from one version to the other in the driver, code that was removed by some cleanup, compiler changes/problems/incompatibilities, etc. In other words, database connectivity needs some love. > > Unfortunately, it looks like there doesn't seem to be a consensus or a shared desire to fix things *together*. There is duplicate effort all over the place. Just as an example, I listed the various implementations of MySQL packages that exists (I did not list the 8-9 of them that had no code but a project listed on one of those sites). So, let's say you are a newcomer and you want to connect to a MySQL database. Here are the choices you are offered (and remember, as a newcomer, you have NO clue which one to pick) : > > > Databases supported : Project name > > 1) SqueakSource > > MySQL : Automatic Object Storage To MySQL > OpenDBX > SqueakDBX > > > 2) SmalltalkHub > > DBX/Talk / DBXDatabaseModel > GlorpDriverMySQL > PharoExtras / ODBC > DBXTalk / Garage > UDBC > UDBC2 > > 3) GitHub.io > > dbxtalk > > 4) GitHub > > pharo-rdbms/garage > > Now, let's say you picked one package. In some cases, if you are lucky, the code will load without any problem or warning. And then, you run the tests. That is where it almost *always* breaks! > > Today, I tried to load *each and everyone of them* in a Pharo 6.1 (Windows) image : none of them worked right out of the box! > > In other words, that newcomer I told you about just goes from "WOW!!!" to "WHAT?!?!" in 10 seconds. People are usually not so impressed with a TestRunner that fails a gazillion unit tests... > > So, now the nice part... > > Database connectivity is, in my humble opinion, a MUST for Pharo and Squeak. I think it's about time we do *something* about the current state of this mess. There are enough brilliant and talented people in the Squeak and Pharo communities to fix this situation. At least, we could start *talking* about it if we want to address the problems. Ideally, we would come up with a will to change things and establish a plan. > > In a perfect world, we'd have something like JDBC (or some kind of Smalltalk universal driver) in Smalltalk for native drivers. Plus ODBC connectivity. Plus it would have to work right-out-of-the-box. Plus documentation that has at least an example with Connect/SELECT/UPDATE/DELETE/CREATE/DROP/disconnect simple examples to get newbies started. Plus a solid suite of tests to beat the sh*t out of that code. Plus a compatibility layer for Squeak/Pharo differences. To that regard, Glorp is an example to follow! IMHO, it's about time we share stuff to maximize our efforts! > > As I told someone recently, it's about time we do something about databases (RDBMS). And as I told that person, I don't mind writing Smalltalk code and SQL scripts and running tests. Even do performance testing. My MySQL Server currently has close to 1 billion records to torture the MySQL driver if needed. And I can also work on SQLite. And Oracle. And DB/2. And MySQL Server. And I don't mind installing other RDBMS on my machine and test other driver ports. Now, it's just a matter of knowing if we all want to work together. > > As for OpenDBX/DBX, I'm not sure. Having another dependency (and C code) that we more or less control doesn't inspire me. I have yet to see how DBX/OpenDBX gives me any advantage over, say, ODBC... > > As I said, it's time to discuss! > > Anyone interested? > > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > >

2 3

[Seaside] WAComponent instances tree + proper page refreshing for user (back button) - confusion
by Petr Fischer Jan. 15, 2018

Jan. 15, 2018

Hello, sorry for crossposting (from Seaside list), but I probably do not understand something very basic in Seaside - how to properly refresh instantiated WAComponent tree (data views) and when (+ back button problems). Seaside manual says ("About Callbacks" section): "Do not change state while rendering... Just produce output and define callbacks that do the fancy stuff you canât do while rendering." OK, then my small example: 1) Suppose I have a page - WAMyListPage (WAComponent sub class), which presents a list of items from DB table, easy. 2) When WAMyListPage is instantiated at the beginnig, it loads 10 rows from the DB, creates WAMyItem (WAComponent subclass) for every DB row and puts these WAMyItem instances to the WAMyListPage instance variable "items" (OrderedCollection) 3) WAMyListPage is rendered to the browser (simple render call on all WAMyItem "items" components in a loop) - 10 items (db rows) are displayed - OK 4) User 1 clicks on the WAMyItem component from the rendered list (on the WAMyListPage) and goes into item detail page (detail page is not interesting here) 5) User 2 deletes 5 items/rows from the database (some way) 6) User 1 clicks browser back button and returns to the WAMyListPage, two cases can occur: A) typically, the "list page" is cached in the browser and browser immediatelly renders the list page from the cache (without request) - with all 10 old items (no refresh, broken old view with some non existing items) B) request from the browser to the Seaside app is made again (with old Seaside URL from browser history), then Seaside app just renders old state of WAMyListPage instance from the history and again - there is all 10 old WAMyItem items instantiated, so, broken again, old items in the view My question - where can I do a proper refresh of WAMyListPage list items? (manual refresh button in the Seaside app is unacceptable) Note: I can solve this by reloading WAMyListPage "items" instvar collection in every renderContentOn: (reload from DB, reload all WAMyItem instances) + instruct the browser to not cache any web page (in HTTP headers), so in point (6A) above, browser will ignore caching and make request to Seaside app again. In this way, everything works, WAMyListPage is actual every time, but main Seaside rule "Do not change state while rendering" is violated (WAMyItems are reinstantiated in every renderContentOn:). So, how do I face this? Thanks very much! pf

1 0

Databases
by Benoit St-Jean Jan. 15, 2018

Jan. 15, 2018

Bear with me for a moment... First and foremost, this post is *not intended in any way* to criticize the work of anyone who could have worked on those packages/projects/frameworks. Now, I'll tell you a story to make my point. Often times, in public or in private, I help newcomers on Quora, IRC, the mailing list(s) or elsewhere with various Smalltalk environments.Â Often times, I try to be helpful getting them started on Squeak or Pharo.Â Often times, they are just amazed by how powerful Smalltalk is...Â Now, the sad part.Â Everything goes well until they just want to "code something" to experiment and they ask me about databases... -How can I connect to a MySQL (or insert your favorite database here) with Squeak/Pharo ? As far as I can remember, the database connectivity with Squeak/Pharo has always been an area where, as a Squeak/Pharo community, we suck big time.Â I don't recall the last time I loaded a package, ran the tests and everything was fine.Â There is almost ALWAYS something broken with the databases packages.Â Understandibly, Squeak and Pharo were for a long time moving targets.Â Whether it was VM changes (FFI, NativeBoost, uFFI, 32 vs 64 bit, OS differences/problems, differences between Squeak and Pharo, etc), code refactoring (cryptography class name changes), the DateAndTime/Timestamp/TimeStamp/Date(Magnitude)/Date(Timespan) were used from one version to the other in the driver, code that was removed by some cleanup, compiler changes/problems/incompatibilities, etc.Â In other words, database connectivity needs some love. Unfortunately, it looks like there doesn't seem to be a consensus or a shared desire to fix things *together*.Â There is duplicate effort all over the place.Â Just as an example, I listed the various implementations of MySQL packages that exists (I did not list the 8-9 of them that had no code but a project listed on one of those sites).Â So, let's say you are a newcomer and you want to connect to a MySQL database.Â Here are the choices you are offered (and remember, as a newcomer, you have NO clue which one to pick) : Databases supported : Project name 1) SqueakSource MySQL : Automatic Object Storage To MySQL OpenDBX SqueakDBX 2) SmalltalkHub DBX/Talk / DBXDatabaseModel GlorpDriverMySQL PharoExtras / ODBC DBXTalk / Garage UDBC UDBC2 3) GitHub.io dbxtalk 4) GitHub pharo-rdbms/garage Now, let's say you picked one package.Â In some cases, if you are lucky, the code will load without any problem or warning.Â And then, you run the tests.Â That is where it almost *always* breaks! Today, I tried to load *each and everyone of them* in a Pharo 6.1 (Windows) image : none of them worked right out of the box! In other words, that newcomer I told you about just goes from "WOW!!!" to "WHAT?!?!" in 10 seconds.Â People are usually not so impressed with a TestRunner that fails a gazillion unit tests... So, now the nice part... Database connectivity is, in my humble opinion, a MUST for Pharo and Squeak. I think it's about time we do *something* about the current state of this mess.Â There are enough brilliant and talented people in the Squeak and Pharo communities to fix this situation.Â At least, we could start *talking* about it if we want to address the problems.Â Ideally, we would come up with a will to change things and establish a plan. In a perfect world, we'd have something like JDBC (or some kind of Smalltalk universal driver) in Smalltalk for native drivers.Â Plus ODBC connectivity. Plus it would have to work right-out-of-the-box.Â Plus documentation that has at least an example with Connect/SELECT/UPDATE/DELETE/CREATE/DROP/disconnect simple examples to get newbies started.Â Plus a solid suite of tests to beat the sh*t out of that code. Plus a compatibility layer for Squeak/Pharo differences.Â To that regard, Glorp is an example to follow!Â IMHO, it's about time we share stuff to maximize our efforts! As I told someone recently, it's about time we do something about databases (RDBMS).Â And as I told that person, I don't mind writing Smalltalk code and SQL scripts and running tests.Â Even do performance testing.Â My MySQL Server currently has close to 1 billion records to torture the MySQL driver if needed.Â And I can also work on SQLite.Â And Oracle.Â And DB/2.Â And MySQL Server.Â And I don't mind installing other RDBMS on my machine and test other driver ports.Â Now, it's just a matter of knowing if we all want to work together. As for OpenDBX/DBX, I'm not sure.Â Having another dependency (and C code) that we more or less control doesn't inspire me.Â I have yet to see how DBX/OpenDBX gives me any advantage over, say, ODBC... As I said, it's time to discuss! Anyone interested?Â ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein)

1 0

bloc next experiments
by Tudor Girba Jan. 14, 2018

Jan. 14, 2018

Hi, Happy New Year! We were asked about the roadmap of Bloc several times. It is a perfectly reasonable request given that Bloc is supposed to offer the UI infrastructure for the future of Pharo. However, I was reluctant to provide one because we do not really have a classic roadmap. When we develop Bloc and GT we think in terms of experiments and examples that we want to play with to get us to our goal. Features are a consequence of that. This approach allowed us on multiple occasions to stumble across functional possibilities that we would have not been able to think about before seeing the experiments. It also works the other way around: as we move ahead, we sometime discover modeling problems and we sometimes chase them all the way down. Having said that, we can specify the next examples and experiments that we consider for the next months. Here they are: â¢ Drag and drop that can be customized on an instance basis. In the process, revisit event management and explore making it use Announcements. Use this for the diagramming engine. â¢ Scrollbar for infinite list and the scalable element. â¢ Apply layout once. For example, this would allow us to apply a layout but still be able to drag elements in custom positions without disturbing the others. The first application is in the context of creating diagrams and visualizations. â¢ Apply layout with animation. For example, in Connector, a new example should be spawned and moved to its position through a smooth animation. This will also allow us to play with the concept of animation and MVVM. â¢ Introduce the concept of elevation. This is important for scenes in which we have overlapping elements that are not part of the composition tree. For example, in Connector, the lines connect inner elements inside the text, but they belong to the root. such as a visualization (but not only). For this to work, we need a better element traversing structure. â¢ Experiment with theming. The theming mechanism should be instance specific with per-widget defaults, and the theme values should ideally be injected in the widgets. The CSS implementation from Glenn is one direction. As developing and maintaining themes can be a nightmare in the long run, the theming mechanism to provide debugging tools. â¢ Experiment with delegating animations through the model. Typical MVVM or MVC focus on the behavior of an interaction. We want to get smooth live interfaces and the animation logic should be influence-able by the model. For example, hovering over a button, enlarges the button with extra details about the action. â¢ Basic widgets: list, input box, button, radio button, checkbox, menu, dropdown menu, toggling button, tabs, toolbar. â¢ Table and tree widgets. â¢ Pager interface (similar to the one in the current inspector) with resizable panes. Have fun, The feenk team -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."

1 0

Any perspective of Woden in Pharo 6.1/7 ?????
by Casimiro - GMAIL Jan. 14, 2018

Jan. 14, 2018

Is there any perspective of Woden working in Pharo 6.1 or later versions (7)???? Best regards, Casimiro -- The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions. == This email may be signed using PGP key *ID: 0x4134A417*

5 7