But I wonder if https://gtoolkit.com would work for you?

That looks super awesome

It does, and the developers are on this Slack. I have no idea how easily it’ll plug into everything else you need to use.

Yeah, and even if it's not very moldable (ha ha), MIT license + opensource is a pretty close second best solution to having a library

Glamorous toolkit is a smalltalk product built in Pharo to my knowledge. It is Tudor Girba's project, and he has spent years on this very complex system. Given Smalltalk's great age, Pharo is indeed one of the most sophisticated IDE's on the planet. However, I find smalltalk horrible, and although i tried learning it with the Adele Goldberg Smalltalk-80 book, it just seemed perverse to send the message "plus" to the number 2 along with a message content of 2 to add 2+2. I gave it a try, but after learning Assembler, PL/1, FORTRAN, i must have been contaminated by the Algol family to the point where smalltalk is a no-go.

Yeah, after looking at it, unfortunately won't be too useful other than for architecture design inspiration. I have hard requirement around gamedev usecases so i'm stuck to a C-like language

Thanks for the mention, @Peter Abrahamsen. @ikrima: Glamorous Toolkit has a rather extensive infrastructure for various languages, including C. The environment itself is implemented in Pharo, indeed. However, it is meant to be a platform for creating system-specific (not just language specific) environments. This also includes debugging and inspection, too, not just the editing part. GT comes with a dedicated graphical stack. The actual rendering is based on Skia (https://skia.org). If you are looking at only editing, you might also want to take a look at MPS (https://www.jetbrains.com/mps). In any case, if you have questions about GT, I’d be happy to address them.

@Edward de Jong / Beads Project Curious that the consistent message sending semantics you hate about Smalltalk is exactly what I love about it.

How much access to the GPU do you have from within Glamorous Toolkit? Is there support for OpenGL, Vulkan, DX 12, Metal? Skia is a 2D graphics API; how do I render in 3D?

Yeah the appeal of Smalltalk or IO is reducing 'many different kinds of things' to different cases of 'very few kinds of things'. Basic arithmetic operators, control flow and function are all built up from the core object-message-method idea. This almost seems philosophically 'mathematical' - reducing the number of ideas. Now I'm not saying these are the best core set of ideas (and not saying they're not), but just trying to elaborate on the motivation and appeal.

Re: Smalltalk. My concerns with Smalltalk for my project are: [1] It compiles to interpreted bytecode, so a compiler and interpreter for my language is expected to run a lot slower than one written in C++ (which I am currently using). [2] I need to be able to use specialized graphics libraries written in C++, that have no equivalent in other languages. Binding to C++ from another language is not easy. [3] How practical is it to build a GPU accelerated 3D user interface within Smalltalk? If I have to rebuild the graphics & UI stack from scratch then I'm not getting any benefit.

If someone wanted to use SmallTalk for speedy direct graphics stuff, maybe you'd want to generate C or something like that? i.e. use ST as the meta language. Isn't Pharo self hosting using this method?

@Doug Moen @shalabh Glamorous Toolkit is indeed implemented in Pharo and replaces the Pharo environment to essentially create a new Smalltalk system. The current graphical stack is a 2D vector graphics one with which we want to express the development environment interface, like the editor or the inspector. The heavy work of rendering is delegated to C/C++. In our case, this is Skia, but the same can apply to other rendering targets. For example, Skia does support GPU acceleration. However, the goal of Glamorous Toolkit is to be a platform for creating IDEs for various other languages.

@Tudor Girba I spent more time over the weekend looking at glamorous toolkit and have to say hats off. It's amazingly impressive and is the almost the "final form" of what i've been trying to cobble together for the last decade in my spare time (tongue in-cheek) ironically it was also super depressing the more i researched it: - Programming today: constant iterating on reinventing triangular wheels - Me: uh guys, use a circle and move on. need to build horse-carriage then a car - GToolkit: here's a completed ModelT - Me: 😍 it's everything i want....Oh it only runs on diesel, i need it on electric. fml 😭

@Tudor Girba One obstacle that I expect with adaption GToolkit to other languages is the size of minimally meaningful code fragments. In Smalltalk, it's a method, which is typically small. The code structure that ties all the methods together is not expressed in syntax and thus doesn't show up in an editor. GToolkit looks tailored to this situation. Now consider Python, for example, where the in-memory representation of a module is built up by executing a potentially very long script. You can't safely decompose this into, say, function definitions beause the programmer might have defined a function, used it, and then redefined it, all in the code of a single module (yes, that's definitely bad practice, but it's possible). So you need to be able to look at the complete module in an editor at some point. Wouldn't you then lose most of the advantages of the GToolkit approach?

Not at all. We are actually working on that part. There already exists a case that shows how it would work: the SmaCC language for defining parsers is a contiguous string. It can either be seen as a string and we augment the code in a large editor, or we have another view (people might call it a projection) that allows us to edit the productions separately.

Multiple views looks like a nice solution indeed!

@Doug Moen is Woden something for you? https://github.com/woden-engine/woden

@Erik Stel Thanks for the Woden reference. I'm not looking for a game engine. Woden uses the AbstractGPU package, written by the same author, to access the GPU, and that is of greater interest. Pharo doesn't have a standard framework for GPU accelerated graphics. Glamorous Toolkit uses a custom version of Pharo that replaces the 2D rendering system with Skia, which is a GPU accelerated 2D vector graphics library. I would need the ability to write Pharo code that mixes Skia 2D graphics and AbstractGPU 3D graphics in the same widget. One way forward is to fork the GToolkit version of Pharo, and fork AbstractGPU, and create a new Pharo distro where the two GPU graphics layers are integrated, so that they can both output graphics to the same shared OpenGL or Vulkan context. Seems like a big commitment, so I have to consider if this is the best way to get a GUI for Curv. Another consideration is that I'd like the ability to run the Curv GUI in a web browser, probably using Web Assembly, and I don't see how this approach would get me there.

I had hoped that Web Assembly would end the tyranny of JS in the browser; alas, the powers that be deemed that Web Assembly programs would run in a separate thread and be unable to touch the screen which runs in a different thread. So for now Web Assembly is for heavy CPU work, and is not the trapdoor that us JS-haters were hoping for. If you are using a static language, there is no reason to do just in time compilation; ahead of time compilation can be extremely efficient, and not need the super fancy super complex V8 engine, which makes everyone dependent on Google's Chrome. I think everyone outside the browser companies had been hoping for a simple virtual machine that included graphical primitives that we could all program to; that would have been the beginning of a new era, where we are running virtual machines in the browser that give platform independence yet GPU accelerated graphics. Adobe AIR does this outside the browser, but I and many others were all hoping for a single unified 2D and 3D graphical interface that would span IOS, Android, desktop and web, and then we could stop all this framework and simplify the development stack tremendously; perhaps down to a single language.

Yeah, I wish AIR had made some inroads and Flash hadn't died off. They had their virtues.

Yes, Web Assembly is getting a graphics layer. The WASI project is going to adopt WebGPU as its low level graphics API. This will provide the same API for WebAssembly modules running both inside and outside a web browser. The WebGPU standard is still being designed, so this all still in the future. In general, Web Assembly is a work in progress; it isn't finished yet. Mozilla and Google are both working on their own open source implementations of a WebGPU library, which will be portable to all major operating systems. These libraries will have a C interface, and there is a single shared copy of the C header file on github that is compatible with either WebGPU library implementation. In addition to these C bindings, there will be a Javascript binding in all major web browsers (Safari, Edge, Chrome, Firefox), and there will be a WebAssembly binding courtesy of WASI. Once WebGPU is further along, I'm going to use it instead of OpenGL in Curv as my GPU programming interface. The virtue of all this technology I just mentioned is that it isn't proprietary to just one company. Instead, it is the product of industry consortiums, and is being standardized as a collection of W3C standards. There will be multiple compatible open source implementations. This is a big improvement over AIR and Flash. Because it is standardized and open source with multiple implementations, the tech isn't going to vanish when the one company that owns the sole proprietary implementation loses interest.

Adobe sold off the air project to karman Which I believe is owned by Samsung, or some other Korean firm. And it still works, but there are some issues with web GL in regards to text entry fields. It turns out that text entry and soft keyboards are deeply intertwined to the lowest levels of the operating system, and that to do text entry in the field is more than 1 million lines of code, it’s more cold than all the rest of the Graphics Layer put together. It is in fact the single reason why operating systems are so few in quantity, you can do the whole corner of the operating system very easily as the wirth did in his Lilith machine, And there are numerous embedded machine microkernels that are very tiny. But the second you want to support Korean Japanese Chinese Thai text and put Support suddenly things get really hard. And let’s not forget about Hebrew and Arabic which are two important languages that are written right to left, and have to support switching direction and one entry field. So we have webGL will be great for presentation but Will it just fall down when it comes to having text entry That supports the tougher languages which by the way a significant fraction of the world uses. Graphic layer that doesn’t have text entry it’s going to be acceptable for video games but not for business purposes and since were talking about the virtual machine for the future of mankind it’s going to take a while for them to figure this out and I don’t think it’s gonna happen that quickly.

If you are building a research system to explore the future of coding, then ASCII text entry might be good enough, depending on what you are researching. The ability to work with a small code base that one person can understand, that allows rapid iteration, might be more important to advancing your research, than the ability to support all the world's languages. And if the resulting system is only useful to 100,000,000 people, instead of to all 7,000,000,000 people, maybe that's good enough for you. Once the ideas are proven to work, then some trillion dollar corporation can take those ideas and replace your 20,000 lines of code with 20,000,000 lines of code. I think there is a virtue in not overengineering stuff that isn't important to your project.

This is the problem: each special, real world case multiples complexity by a factor. Next thing you know, you have a cross-cutting 1/1000 edge case that now takes 20% of your code to handle. Stack up a few dozen of those and boom 20k goes to 20M.

This problem is one reason why good ideas from research systems don't easily become available in production. The trillion-dollar corporation dealing with the messy real-world issues is unlikely to spend much time exploring research work. They will implement a solution based on the technology they have and the tools their developers are familiar with. I suspect the only way out would be a transition to truely modular software, but unfortunately I don't see why trillion-dollar coroporations should care, so it's probably not going to happen. In that universe, text handling would be a component you could use in your research system. A piece of software made by paid professional developers which every user of your research system would buy, at a very low price because it would be the same component used in mass-market OS and Web apps.