Why “modern”? I suggest you use more descriptive adjectives.
I think the approach is a Mac-first app that follows Apple's design language, no?
Thought it was totally clear.
It looks like and acts like it was built for Sonoma, not for Sierra.
101–110 of 192 posts
Why “modern”? I suggest you use more descriptive adjectives.
I think the approach is a Mac-first app that follows Apple's design language, no?
Thought it was totally clear.
It looks like and acts like it was built for Sonoma, not for Sierra.
Cool! Surprised to hear you started with a native UI and pivoted to electron. What was the major blocker there? I recently got frustrated with OpenSCAD and decided to try CadQuery and Build123d. The modeling backend is a big step forward, but the GUI is not nearly as good as OpenSCAD. I managed to get it working via VSCode with a plugin, but I’m dreaming of embedding everything in a dedicated MacOS app so I can jump…
There aren't many great production-ready open-source frameworks for code-editor components in Swift. I assessed quite a few but found that the feature completeness was far from what I needed. I tried to fork [CodeEditSourceEditor]( https://github.com/CodeEditApp/CodeEditSourceEditor ) and add the extra features I wanted, but I think it would have taken me 6-12 months to get it to an acceptable state, meanwhile not sp…
To be frank, I don't see any additional features of the app over VSCode, other than it starts up faster, which does not matter much as VSCode starts up faster than the import cell of any notebooks I have. Also, one big reason I use VSCode for notebook is to get the Python LSP. Good luck to you though, I do think the demographics of scientists who find VSCode confusing is actually sizeable.
This sort of high performance minimalism is precisely what makes the Mac app ecosystem great. Not because you can't write the same thing on other platforms, but because everyone who cares about it has condensed on the Mac platform. Would love to see this adopt the document-based app API and the toolbar API.
This elitist and incorrect viewpoint has plagued macs for a very long time. I wish it would die.
How does this compare to the “official” Jupyter desktop app: https://github.com/jupyterlab/jupyterlab-desktop
Is this loading the same webpage whatever JupyterLab is serving or did you write the JavaScript machinery for cell management etc yourself?
If the latter, are interactive plotly graphs or IPython widgets on your radar?
I use notebooks the whole time, normally in vs-code and with github copilot setup. I found it quite painful to point it to a couple of environments I have, and confusing how i get it pointing to my gpt4 api keys. Once I did these two I was not sure how to prompt rather than typing a command. Good luck with this, don't mean this in a critical way, just trying to give some feedback of what I think when I first try it.
Earlier quoted context omitted.
That will be interesting. Happy to test and share feedback. Previously, I was a part of the DataSpell and PyCharm team building notebook support. Now working with dstack, where we support dev environments and super interested in remote support.
Thanks! I'll let you know when it's ready. What do you use now to work with remote environments? JupyterLab or VS Code?
- vim on the left half of the screen, a jupyter QtConsole on the right, showing any plots, possibly interactive.
- the kernel on the jupyter QtConsole can be running on a powerful remote host, e.g., with GPU, but the plots are displayed locally
- Focused window is always vim. From vim editing a .py and without ever leaving vim or touching the mouse, one connects once to the jupyter kernel of the QtConsole. Then one can send a selection of lines, or vim text objects, to be evaluated in the QtConsole with a few keystrokes. Code is shown+evaluated and plots are displayed in the QtConsole as if the code sent from vim had been typed there.
One gets the full power of both vim and jupyter kernels with native plots. No more browser based notebooks or other editors with half-baked vim bindings.