Hi Luke, I am happy this looks exciting :). About the confusion part: The Glamorous Toolkit we are working on right now is a complete new world built on a complete new graphical stack that does is not based on the existing stack that ships with Pharo. It is not an evolution. It is a leap. The goal of the new GT is to propose a completely reshaped programming experience that enables moldable development. You will find the concepts from the old GT in the new world as well. For example, the Inspector is extensible in similar ways and the API is similar as well. But, in the new world, we are bringing the concept much further. For example, Documenter provides a whole new kind of a tool that can mold to unify multiple workflows (like data notebooks, code documentation, or tutorials) right in the IDE. Coder provides the infrastructure for manipulating code that can mold its shape as you type. Transcript allows you to embed various widgets to transform the otherwise dull experience of a console into a live one. Behind the scenes GT comes with several engines. The Examples engine enables example-driven development which also bridges the gap between testing and documentation effort, especially when combined with Documenter. Releaser is able to release deeply nested projects. Phlow offers an engine that shares similarities with Glamour. Completer provides moldable completion. Visualizer offers a couple of visualization engines such as Mondrian. All of these are possible because of the underlying graphical stack made of Sparta/Bloc/Brick. All in all, we believe that the new GT enables a new way of programming. Individual features can be attractive, but our goal is to reshape the development experience. Does this address the concern? Cheers, Doru -- www.feenk.com "Things happen when they happen, not when you talk about them happening."

Hi, Thanks for detailing your thoughts. Indeed, I know about your application. Whatever you can do with the current GT you will be able to do with the new one. Except that for the new one you will be able to do extra things. Here are a few: - You can build and share documents that embed those inspector views. This can be useful for reporting or sharing diagnostics with your users. - Because the underlying rendering engine is much more powerful, you can express modern and interfaces that integrate with the rest of the environment smoothly. - You likely have to deal with log files that might get large. First, the new editor allows you to smoothly work with such files. But, you can go well beyond this. Imagine that you build a tooling that produces the same editor only the text is interactive, and you might even embed visual artifacts right in the text to bridge the gap between what you would see in a typical console. For example, this tweet shows the new Transcript used to debug an animation. For every animation frame, we output the text corresponding with the frame and we insert the graphical preview corresponding to that step. You look at GT from the point of view of an end-user. You likely like the fact that you could mold the environment to your context and that you could do this incrementally. It happens that the same principles and tools can be applied to the whole programming, and once you do that, you actually can fundamentally change the act of programming. In fact, the same thing applies to the old GT: we built the new GT using that version and we believe that this allowed us to work much faster than if we would have used more traditional tools. The new GT pushes the envelope significantly further. So, that is why we are excited about that perspective, but even if you do not spend much time programming in Pharo, you can still take advantage for the user point of view as described above :). Is this answer better? Cheers, Doru -- www.feenk.com "Being happy is a matter of choice."

Hi Doru, Thank you very much for the detailed explanation. I have spent some time with the alpha now. I think it is absolutely fantastic! I love the new narrative style of the UI. This ties everything together beautifully and makes it easy to explore. That's really what I am lacking in my application. Currently it simply opens to a blank quasi-playground and it is not obvious what to type or how to get started. I started writing a separate HTML manual but I don't think that's the right medium -- much better with something interactive in the image like the Documenter. Just clicking around everything seemed to work basically smoothly for me. Maybe it's already time for me to port over to the new GT? Or what do you think the most likely obstacles would be in transitioning to this alpha version? Currently my custom inspector extensions are mostly based on Roassal and List/Tree/Table views. I also have one or two Glamour browsers. Is that all still there in one form or another?

Hi, Thanks for the feedback! I am happy you like the new possibilities and that you see the incentives to move to the new world :). The inspector part is working quite well. The main reason we call it an alpha is because of the missing pieces to get to a full environment. You noticed the issue of Spotter. The existing Spotter is the one that is included in the old GT and it lives in the Morphic world. When the focus is in the new inspector, that means that keybindings are handled by Bloc and this is a separate world from Morphic. At present time, we can embed Bloc in Morphic but not the other way around as we want no binding from Bloc to Morphic. For this reason, unhandled keys are not propagated from Bloc to Morphic and that is why pressing Shift+Enter does not open Spotter. So, we will have a Spotter, but that will be another implementation. Other unfinished tools are the Debugger and Coder, but these are likely less relevant for your use case. A few other missing pieces: - some widgets such as a tree are not yet implemented. So, we do not yet have a tree view in inspector. - the text editor requires a few enhancements for navigation support. - scrollbar The Miller-columns interface can be scrolled with the touchpad left-right. Can you confirm? About clicking vs double-clicking: Indeed, we now distinguish between selecting and spawning. As soon as there is a page to the right, selecting will populate that page. However, if there is no page to the right, simply selecting in a list will not spawn, like in the old inspector. Like this, you can work on a page without the page scrolling from underneath you. Please note that between pages we have triangles which are actually buttons. Selecting in a list shows a triangle. Clicking on the triangle spawns. So, you can either double-click to spawn, or you can select and then click on the triangle. Once spawned, simple selection is enough. Does this clarify the situation? About Roassal: In the new GT we have GtMondrian which is similar to the one from Roassal. We do not yet have support for creating charts (like bar or line charts). About the porting strategy: When you have the new GT loaded, the old Inspector will get a _GT pane that will essentially embed the new views in the old inspector. These also allow for interaction. Like this, you can port at your pace and switch only when you are ready. Cheers, Doru -- www.feenk.com "Every thing has its own flow."

Hi, The visualization you describe should be easily doable in the new world. Did you write the visualization in plain Roassal or with the RTMondrian API? Cheers, Doru -- www.feenk.com "The coherence of a trip is given by the clearness of the goal."

Hi, I share your feeling of wonder and also concern Luke. In my case, I used (old) GT tools to prototype Grafoscopio and now that the PhD thesis is practically done and only dissertation is pending, I would like to prepare myself to migrate Grafoscopio to Pharo 7, including bug fixing, stability, improved functionality, Iceberg for code management (but supporting Fossil instead of Git). I think that there is a lot of possibilities in the new GT tools and I like some of them going into interactive documentation (a line I was trying to explore with Pharo using Grafoscopio). But anytime I tried to use it I stumble upon a stop: * First time was something related with me having some kind of credential enabled in GitHub to simple use it. I lost a whole morning just enabling that and reporting it. It was related with some mozilla library for font redering that didn't work well at the end. * Today I tried with the prebuild Linux image and Pharo Launcher, but I got an error message about inability to determine proper VM and when I tried installing it from Pharo 7 I got something related with a MemoryFileWriteStream dependency to be resolved before proper installation. I understand that this is alpha software and demos look amazing, but just running them requires a lot of work that previous GT didn't require. This brings me this feeling that these jumps in Pharo put core of the user experience at risk (kind of) and you end wondering how much an old tech will be maintained once the jump to the new shinny stuff is done and which is the migration path. In my case, I would like to have something like a Zeroconf script that just takes care of the external libraries, VM and image, to have a real glipmse of the upcoming future, beside the Tweets (which look great BTW). Maybe it will happen in a year or two, once it is properly integrated with Pharo, Zeroconf and thought for "end users" of interactive documents, which don't want to enable GitHub stuff, deal with external rendering dependencies and so on. Now the experience of using GT is kind of hostile for that users. Anyway, keep the good work and sharing it. Hopefully at some point it will reach the beta status, where users like myself can use it smoothly and build on GT's promises and interesting features. Cheers, Offray On 21/12/18 10:59, Luke Gorrie wrote:

Tudor Girba-2 wrote Does this mean it will offer Pharo an alternative UI (what I think you mean), or that the final product will not be Pharo-based? ----- Cheers, Sean -- Sent from: http://forum.world.st/Moose-f1310756.html

I had a similar question - is this a heads-up of a future fork (and a future commercial offering?). Or is it more like there will be Pharo lean/dev (the current pharo) and a fuller/fatter Feenk, that is pharo based but augments with a richer set of tools? Or are we experimenting with a potential new pharo direction that drops the existing tools if the community likes it? Either way - I like the work, I just want to be careful of any politics. Tim On Sat, 22 Dec 2018, at 4:58 PM, Sean P. DeNigris wrote:

Hi Doru, On 21/12/18 17:40, Tudor Girba wrote: Thanks to you for this conversation. On the technical side, the 64Bit distribution in the smoothest installation of the new GT I had have so far. Just unzip it and launch the image and you are done! After that you are welcomed with a nice welcome window with beauty typographical render and you can explore what the GT has to offer and experience its potential first hand, which still brings kind of a mixed experience: * The new interfaces and some demo of the graphical elements look pretty good * After just some operations including window resizing I just get the Red Window of Death [1](https://i.imgur.com/Cbx7uyH.png). * I like the little triangles to expand thing in the document and the run buttons for embedded code, and the "embeddability" of elements in the document in a tree like fashion, which of course could lead to documents that embed pieces of documents, which embed pieces of documents... But the dual panel view of code in one side with results in the right panel of old GT didn't tend to create such "recursion". This dual modal view is the same of Atom[2](https://is.gd/kegaso) and CodiMD[3](https://is.gd/wudugi) for interactive documentation and I would like to see examples more in that line... but I don't know how it suits the philosophy behind Documenter, which seems more aligned to a modal non dual view of the document where you enter into edit mode once you click a piece of the document and into a view mode once you are out of it (instead of the proposed dual view). Would be nice to see is such dual view can be used to directly operate on the rendered view and see changes in the markup (i.e resizing an image in the rendered view changes the value on the edit view). * I like the different view that a document can have, markup wise: Pillar, Markdown, LaTeX, HTML, DeckJS AsciiDoc as is demoed in the authoring part [4](https://i.imgur.com/Jc1T5Rm.png). * Its difficult to travel between the panels of a playground. Previously you just make click in the lower circle representing the panel you want to go at it was done [5](https://i.imgur.com/4CDAM2o.png), but now clicking on the upper rectangle representing such panel has no effect [6](https://i.imgur.com/8Obo3Ct.png). * Auto-completion and shortcuts for selecting text doesn't work well on code cells of the new playground. Selecting whole words with Ctrl arrow doesn't work, neither using down arrows to choose from suggestions and even you can end with previous suggestions floating around your playground [7](https://i.imgur.com/4awyIft.png) [8](https://i.imgur.com/7qXc64b.png). * The default data science example didn't work at all [8](https://i.imgur.com/YhNb8el.png) I used Moose to build the first Grafoscopio versions, but there was a lot of stuff that was related with software analysis that I didn't really need for reproducible interactive documentation and publishing nor for data science, activism and storytelling. So once old GT was integrated into Pharo with Spec I used a more minimal setup to deliver a more focused experience. I think that most times this relationship between Pharo and Moose can be of creative tension, one pushing the boundaries and the other offering a more stable experience where the innovations of the former are integrated and debugged. But even after using Moose as a fully integrated vision of what old GT have to offer in the back and front end, I didn't see any migration path from previous Moose with the old GT to the current GT, which is kind of worrisome. I understand the idea of forks in FLOSS as a way of dealing with politics behind the FLOSS movement and the relationship between different  visions and actors (individuals, communities, enterprises, foundations, associations and so on). It has happened before with Squeak, Pharo and Cuis and I'm fine with that. And I understand that a healthy relationship with the past means sometimes to break with it and jump into the future. That's why I think that the role of for profit and non for profit institutions is to balance a sense of momentum and stability around FLOSS. I would like to see a more clear road map for GT, knowing ahead where backward compatibility will be broken and why, which are the visions and, more importantly, how to participate and where are the boundaries. These are difficult tasks, but if the participation and boundaries are explored collectively, you can also know about the first ones (visions, versions, forks, compatibility). In that sense I think that Pharo is putting a good example: we have a clear road map document and participation process in the public repositories, there are public channels for users and developers and the private companies know about them, so they can put the boundaries about what is going to be done in the open, with the community, and what is to be kept closed inside company's frontiers and channels and the company's own velocity. I don't know if Feenk is planing something similar for its new vision, product and identity, and I don't know if the new alternative will have its own non-profit organizations as a neutral entity for all players using GT, but would be good to know about that, not because there are not people willing to jump into the future, but we would like to know to which future we're jumping on.  Without that I think that is a safer bet for myself to rely on Pharo and see how migration paths could ensure compatibility with my own past and the one of my local community using Pharo and GT based tools. I hope that the open source nature of both products (Pharo and new GT) will ease the cross-pollination of the more interesting ideas, even without sharing code, visions or UI. I think that not only installation inconveniences is related alpha, but also this jumping from old GT to new one without a clear migration path (as is expected from alpha software and processes). I'm fine with that too, but I think that once the new GT reaches beta status the backward compatibility should be more important and meanwhile the non regard of that should be stated more promptly for previous and future GT users. I imagine that, at some point Feenk will provide its users and customers with clear support and migration paths regarding its open source products (kind of what happens with Canonical and the Long Term Support versions of Ubuntu). Yes, it does. It seems that a fork is coming, at least UI wise regarding Pharo and new GT, but if the community knows about it, I'm fine with that. I think this thread also clarifies what active users of old GT will expect from upcoming versions of new (non alpha) GT regarding compatibility, open processes, visions and so on. Hopefully we will reach that place together. Cheers, Offray

On 21/12/18 17:57, Ben Coman wrote: At that moment the script for disabling the GitHub credentials requirement was disabled but font rendering didn't work pretty well anyway. I 'm testing now the prebuild Linux image, following the mail by Tudor. Font rendering works pretty well and it is the smoothest installing experience so far (but I have already my first Red X screen of death already, few seconds after launching). I will post more detailed impressions later next week. Cheers, Offray

WOW On Thu, Dec 20, 2018 at 01:57 Tudor Girba <tudor(a)tudorgirba.com> wrote:

On 28/12/18 8:03, Tudor Girba wrote: And which parts you don't? I wrote a long mail regarding good and no so good parts of the new GT experience, including features possible forks, that I hope will be answered also in detail, to keep the big picture. Cheers, Offray

Hi Doru, This one is still pending: https://www.list.inf.unibe.ch/pipermail/moose-dev/2018-December/027542.html Of course we have slow days at end of year and I don't expect immediate answer, but now that discussion was active is good to point some pending conversation, even to be taken after holidays. Cheers, Offray On 29/12/18 6:38, Tudor Girba wrote:

Hi Doru, On 29/12/18 15:50, Tudor Girba wrote: It was also absent from the web archives of the Pharo mailing list and, as I'm not subscribed to Pharo-Dev I always get a warning about a rejected message (I don't know if this is related somehow to the mails being hard to find). Anyway, I'm hitting "Reply all" button so you'll have the answers from this thread also in your personal mail (and have stopped cc to Pharo-Dev). Thanks. Maybe the main window should indicate more promptly about expected but strange behaviors and point to the Issues repository, somehow. I don't think is only because other editors can't do it, but because some (most) times you don't want "to conflate two tasks that are /conceptually/ distinct and that, to ensure that people's time is used most effectively and that the final communication is most effective, ought also to be kept /practically/ distinct"[1] which are Composition and typesetting. This seems kind of strange in interactive documentation, because of the bad habits that WYSIWYG word processors installed on authors, but most of the time What You See Is **Only** What You Get, but you need enable comments to yourself, use admonitions, refer to bibliographic keys, and so son. That's why I think is a healthy practice to separate both, composition and typeseting and think in a bi-modal way, instead of a conflated way, in a similar fashion to what Bret Victor demos show for working with graphics and code in a bi-modal way [2][3]. I have experience, first hand, in "documentathons" using CodiMD, how document authors could benefit from bi-modal thinking for their documents, by showing side by side, Markdown and the rendered document changing in real time. I would like something similar for the Pharo environment. [1] http://ricardo.ecn.wfu.edu/~cottrell/wp.html [2] http://worrydream.com/#!/InventingOnPrinciple [3] https://i.imgur.com/vi6bX21.png [4] https://en.wikipedia.org/wiki/GNU_TeXmacs TeXmacs[4] has a really good What You See Is What You *Mea*n (WYSIWYM) editor that conflates composition and typography, but it works like a charm, specially while you're writing mathematics that I have not seen elsewhere (not even in comercial word processors). But when you start to push boundaries (for example by using non traditional templates) the visual approach shows its limits compared to a bi-modal editor. Some times when I was browsing the examples I made click on an icon that shows the document embedded in the document where the link appeared and then that happened again. I can't remember the icon or reproduce the experience. It seems that rendering in the lateral panel is working and I don't know how to get this nested embedding behavior again. Yes I saw them previously, but the editor make this more... explicit/"explorable"... maybe is related with the rendering, but they seem better now. In Linux those combinations don't work. Any way to get the previous one click behavior? What is the rationale behind having to press more keys, instead of the previous simpler approach? Some collision between shortcuts? Glad to help :-) [...] As I said, I don't have problems with breaking with the past as a healthy relationship with it. This has happened before. My issue is with not knowing that a jump will be done or where are we jumping on. And also with the places where the process will be open or close. Maybe the way to communicate advances is to work enclosed first and then releasing your prototypes to the open, maybe is about having public issue trackers with fixed deadlines... I don't know what works better for the interaction between feenk and the wider Pharo community, but I think that if the process is more explicit, we, the users of Pharo and old GT can adjust expectations. I really don't know if the cost are worthwhile ATM because I don't know what is the next step of the path in new GT. I like its new rendering  features, but I have just a static picture at each step and I don't know where the future is going or how to get there. For me is not about fixed futures but more about open processes and boundaries, as I told before, and with those known we can explore uncertain futures together. Maybe those offerings are invaluable... I really don't know as they're not closer to my context for live documentation, which is not for developers... once the roadmap and processes become clearer I could better asset that profit scenario. Yes, more that a roadmap, it seems more like a mission with some glimpses of what forms it can take. As said, I don't have problems with exploring unknowns together or discontinuities with the past. The main issue is more processes and boundaries. I don't want to invest time in a technology that wold be jumping to something incompatible in the future and the time I notice that is when the new glimpse is released. Well, once those guiding principles and ways to engage are more explicit and think that those of us who have been using GT will now how to and how much engage with the possibilities that feenk is building (they look impressive, as I said, but would like to know where/when quantum leaps are happening). Yes I will go slower. More than stability and predictability, I'm looking for known processes and boundaries. As I said, the fork would be UI wise, not in the core technologies. But some of us are relaying in the possibilities that current and future UI experiences are providing in Pharo to orientate our own developments and local communities. This critics mean to be constructive, explicitly trying to reach clarities in an open way and I hope that serves the wider Pharo communities. The work feenk is doing is a good showcase of interesting future possibilities and is important to have those futures open for the community and to know how to traverse/connect them. Cheers, Offray

This post seems to have come through from the moose mailing list... moose-dev(a)list.inf.unibe.ch On Sat, 29 Dec 2018 at 02:59, Kjell Godo <squeaklist(a)gmail.com> wrote: Kjell, This is awkward. Some of your posts seem human produced... http://forum.world.st/unsolicited-package-cache-use-td5060335.html But such off topic poetry is not appropriate, doubly so since the above looks bot generated. There have been several incidents in the past where the community has requested your account be blocked in response to such posts. The key red flag for me is that you've never responded directly to requests to block your account. http://forum.world.st/The-Inbox-Tools-LM-828-mcz-tp5082873p5082979.html On Wed, 15 Aug 2018 at 06:14, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: http://forum.world.st/unsolicited-package-cache-use-tp5060335p5063447.html On Thu, 18 Jan 2018 at 19:09, Tudor Girba <tudor(a)tudorgirba.com> wrote: http://forum.world.st/NAtiveBoost-error-tp4788132p4840572.html On Sat, 1 Aug 2015 at 21:46, Marcus Denker <marcus.denker(a)inria.fr> wrote: On Sat, 1 Aug 2015 at 22:38, Marcus Denker <marcus.denker(a)inria.fr> wrote: