Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Native desktop client #6

Open
dizda opened this issue Dec 7, 2020 · 7 comments
Open

Native desktop client #6

dizda opened this issue Dec 7, 2020 · 7 comments

Comments

@dizda
Copy link

dizda commented Dec 7, 2020

Awesome tool! I could see myself using this, to replace my boring SublimeText as a notepad.

Have you thought about integrating into an webview app like electron (but lighter ofc), if so, that would become even more handy.

Good idea and good job.

@bbodi
Copy link
Owner

bbodi commented Dec 7, 2020

Hi, thanks :)

Could you please elaborate what you mean by being "more handy" by using electron?

@dizda
Copy link
Author

dizda commented Dec 8, 2020

Sorry, I mean, having this Notepad as a native tool rather than using it within' the web browser :)

@bbodi
Copy link
Owner

bbodi commented Dec 8, 2020

I see, thanks :)

One of the primary goal of NoteCalc is to be easily accessible (e.g. it was mainly born because Soulver is MacOS only).
Currently NoteCalc is available from Windows, Linux, MacOs, Android etc while maintaining a single codebase, and I see no benefits to make a native frontend for it.

For example on my android phone I created an icon for the NoteCalc website, so it looks and behaves like a native app.

However I admit that NoteCalc should work offline without internet connection, it is on my list.

Additionally, the app was written in a way to make it easy to write different frontend for it (99% of the application is the "backend", which does the parsing, calculations and generate what to render, and only a tiny part [the "frontend"] is responsible for rendering and input handling, and only this tiny part needs to be ported). Moreover the whole render system was designed in a character-based style, to be easy to write a console-based frontend.

So I am sure that I will write some frontend for it in the future, but not out of necessity, but out of fun, e.g. trying out some new programming language. And that frontend will be probably some lightweight app using the console or SDL/OpenGL.

@bbodi bbodi changed the title Electron-like Native desktop client Dec 8, 2020
@dizda
Copy link
Author

dizda commented Dec 8, 2020

I was not aware of Soulver, I'll have a look at it.

Actually, I haven't thought about testing it through a Progressive App on Google Chrome OSX, that's a good call, and should be a way to have it pretty close to a "desktop" native app without efforts :)

Currently NoteCalc is available from Windows, Linux, MacOs, Android etc while maintaining a single codebase, and I see no benefits to make a native frontend for it.

I was more thinking about something like https://github.com/Boscop/web-view which should supports the current code base if I'm not wrong.

Anyways, I'll have a look at the different options and may come back to you if my time allows it, thanks for your time and this amazing project.

@abhijit-hota
Copy link

Making it an PWA will be better.
#9

@dmose
Copy link

dmose commented Dec 21, 2020

Out of curiosity, what was the motivation for using Canvas rather than DOM?

@bbodi
Copy link
Owner

bbodi commented Dec 21, 2020

Hi,

Thanks for the question.

I think there is a premise that the chosen canvas-based solution is the more difficult choice, but I think it just stems from the fact that it seems easy to render/type thing in HTML.

As soon as the app needs more interaction with the editor (knowing where is the cursor, what is selected, using "line references" [alt+up arrow in NoteCalc to choose an other line], what has been updated etc), then updating and rendering only the changed lines with syntax- and other highlighting features, not to talk about upcoming features such as autocompletion dialog box, my opinion is that the canvas-based solution is simpler and can perform better, and it is trivial to port to OpenGL or to the terminal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants