That's correct: 2, 3, and 5 are currently available. This initial set was intended as a minimal (albeit limited) set that demonstrates the UI capabilities. More widgets/controls (including the ones you've mentioned) are definitely coming.
7 is something I've considered (along the lines of a redistributable "Scripton runtime" that packages up the scripts and bundles a portable Python distribution). However, that's currently much further down on the todo list.
That is exciting news. I will check out Scripton in greater depth, and with the right set of interface widgets I would be in the heart of your target market.
However, I'm assuming you want to drill down further into these (and have them displayed as a table for instance)? While the current version doesn't have that, it's definitely planned.
Thanks! The C++ bit comes in for the IPC (inter-process communication) between the IDE and Python.
There are a few different ways for the Python process to communicate (send data over for visualization, receive/transmit commands, etc) with the IDE. For instance, you could communicate over HTTP. Depending on the use case, that can have an appreciable performance overhead. Instead, Scripton uses a lower-level mechanism with a protocol optimized for sending binary payloads (eg: large numpy arrays, images, etc). This communication and processing is implemented in C++ as a native multithreaded node module. It effectively enables very low latency and high throughput visualizations.
Some folks do like hold-to-quit to avoid accidentally quitting (similar to Chrome's default behavior). However, point taken - it'll be configurable in the next update.
IMO, VSCode's codebase is excellent and quite well designed with most functionality abstracted out into injectable services. However, the interaction of these services and other bits of architecture do impose certain limitations that are tricky to workaround. One option is to fork vscode, write your own services, alter the architecture as necessary. You're then faced with keeping this in sync with the rapidly changing upstream code. Another alternative is to implement it as an extension, but that has a fair number of restrictions.
For certain projects, forking/extending may be the right call. However, for the degree of customization required for Scripton, writing from scratch turned out to be the more viable path (vs attempting to workaround/rewrite yet another component in vscode). The trade off here, of course, is that you lose out on the familiarity and ecosystem that VSCode has built over nearly a decade. The hope is that Scripton remains sufficiently familiar (eg: Search / CMD+P / etc work similar to vscode) while being compelling enough in its own right.
While the initial focus is on visualization capabilities, the missing IDE features are actively under development. Beyond cross-platform support, which PyCharm features would you consider essential and would like to see the most?
* docker compose service support (e.g. if I have a docker-compose.yml file in my project directory with redis and postgres services, pycharm lists the services in a UI and lets me start/stop/restart them easily from the IDE.)
* django app/model detection and completion from those models as I'm building things that query them
* "compound" runners, so I can start a npm watcher and a python watcher at the same time, and bounce them together as I iterate
* The debugger is really, really good. And it's practically automatic to jump from the PyCharm debugger to the Clion debugger when I'm dealing with a python package that has C++ modules.
* django and jinja template support as I build out things that present my results.
* ability to connect it to a data source and query/explore using sql directly against that, and see tabular results to help guide my other explorations
* Vim emulation in the editor... IdeaVim is a really good vim implementation, and I find I hate working without vim movements and commands.
The vscode extensions path, unfortunately, would have been too restrictive for many of Scripton's features/technical requirements (tightly coupled REPL, minimal IPC overhead, ...)
This is very frequently mentioned by people when they decide to fork vscode / build their own editor.
Its not a huge deal here (in theory) as this is a python IDE. One of the biggest issues I've seen with other editor forks / whatever is some first party Microsoft extensions (dotnet iirc, cpp) will not function outside Microsoft's vscode release.
Does your editor support vsix extensions? I assume no as you are just using monoco. Again, could be a dealbreaker for many.
However, I would like to eventually have something like Jetbrains' "perpetual fallback license" where you can keep using up to a particular version after, say, a year of subscription.
