Monodraw: ASCII art editor for the Mac(monodraw.helftone.com)
monodraw.helftone.com
Monodraw: ASCII art editor for the Mac
https://monodraw.helftone.com/
108 comments
By the way, Finder will let you get info on just about any document and check 'Locked' or 'Stationary Pad'.
Locking should prompt you on any attempt to change the document to unlock or duplicate.
Stationary Pad will automatically create a local copy when you open the file, and instead open that copy.
Locking should prompt you on any attempt to change the document to unlock or duplicate.
Stationary Pad will automatically create a local copy when you open the file, and instead open that copy.
That's cool that you use it in these ways. Do you have any example newsletters or flowcharts we can look at?
While Monodraw seems to have business related features I feel the need to mention "Mœbius ANSI Art Editor"[0] a cross platform open source alternative.
Moebius is a new ANSI and ASCII Editor for MacOS, Windows, and Linux.
With a neat Moebius Server feature that allows collaboration by multiple users on the same canvas through a server instance.
[0]: https://blocktronics.github.io/moebius/
Moebius is a new ANSI and ASCII Editor for MacOS, Windows, and Linux.
With a neat Moebius Server feature that allows collaboration by multiple users on the same canvas through a server instance.
[0]: https://blocktronics.github.io/moebius/
This has like...none of the features of Monodraw? Drawings aren't objects - this is just a canvas. This is not an alternative to Monodraw - but an ASCII painting app.
> a cross platform
Not a cross-platform, but JavaScript-extension with cross-platform Chromium browser bundled.
Not a cross-platform, but JavaScript-extension with cross-platform Chromium browser bundled.
As far as I can see there are Electron apps for all major desktop OSes, that's pretty much as cross-platform as it gets, for a desktop app.
Electron app is "JavaScript-app + Chromium browser (or any other browser)"
Without browser this "browser extension" (Web-app) could not run on any platform.
Without browser this "browser extension" (Web-app) could not run on any platform.
Electron is a runtime environment that evolved out of a browser, not a browser. This app doesn't have any browser functionality I can see, like open arbitrary websites, but it does have its own system menus, icon, it's directly executable by the OS. By that logic no software written in an interpreted language can never be cross-platform, you'll always need a runtime environment.
> but it does have its own system menus, icon,
Desktop files (on Linux & Windows) are just nothing than a text file with description/meta info and a link to local executable or any other sort of file* - that is NOT related in any way to executable at all.
> it's directly executable by the OS.
Because it is browser (Chromium) with a custom browser-extension by design.[0]
[0] https://en.wikipedia.org/wiki/Electron_(software_framework)
Desktop files (on Linux & Windows) are just nothing than a text file with description/meta info and a link to local executable or any other sort of file* - that is NOT related in any way to executable at all.
> it's directly executable by the OS.
Because it is browser (Chromium) with a custom browser-extension by design.[0]
[0] https://en.wikipedia.org/wiki/Electron_(software_framework)
No screenshots or am I blind?
That's pretty neat. I didn't realize 16 Colors uses the server feature. https://16colo.rs/servers/
[deleted]
I learned about Monodraw from Thorsten Ball’s interpreter / compiler books. The book has really beautiful illustrations and ASCII drawings, when I asked the author they directed me to Monodraw
Here is a sample chapter from the book (in PDF) - https://compilerbook.com/sample.pdf
Here is a sample chapter from the book (in PDF) - https://compilerbook.com/sample.pdf
Ha! I was going to comment in here that I used Monodraw for the book and really fell in love with the tool.
What I did more recently is to use Monodraw to create diagrams of CFGs and put those next to the test cases (see [0] or [1]) which exercise those graphs - the power of ASCII, you can just copy the graphs into your code.
[0]: https://twitter.com/thorstenball/status/1363053307409932288 [1]: https://twitter.com/thorstenball/status/1368802505963016197
What I did more recently is to use Monodraw to create diagrams of CFGs and put those next to the test cases (see [0] or [1]) which exercise those graphs - the power of ASCII, you can just copy the graphs into your code.
[0]: https://twitter.com/thorstenball/status/1363053307409932288 [1]: https://twitter.com/thorstenball/status/1368802505963016197
FYI, Emacs bundles w/ the package `artist-mode` that seems to have equivalent functionality, you can even draw w/ the mouse.
Demo: https://www.youtube.com/watch?v=LDbi56U5qRw&ab_channel=gnuma...
Demo: https://www.youtube.com/watch?v=LDbi56U5qRw&ab_channel=gnuma...
Today I learned... one more thing that emacs can do!
ASCIIFlow is a less full featured web app with similar functionality to Monodraw, for all the windows/linux/chromebook users wishing for an electron version
https://asciiflow.com
https://asciiflow.com
I was looking to see if this had been mentioned yet. As a Monodraw owner who recently has been forced to only use a Windows laptop for work I was pleasantly surprised a couple months ago by another article on hacker news that referenced this great web app. Just so happened in the comments here I also learned about Moebius which I also want to try out.
I used asciiflow for a bit then discovered how easy it is to lose your work. (or, at least, it was)
Then started using monodraw. Love it.
Then started using monodraw. Love it.
Literally just came here to link to asciiflow. It's great!
This is why I love the Mac. Even obscure apps have a beautiful interface and easy to use web site. I know this is incendiary, but I must say it: on Windows, this app's site would have seven giant, fake download buttons, the actual download would play an ad, and the app would look like something from a fever dream.
There was a windows compatible app posted here and I can't see ads or fakery. I do see the fever dream aspect, but you have to concede that we are talking about ANSI art here. Which is basically fever dream art in a lot of cases.
FWIW, this looks like a follow up to https://news.ycombinator.com/item?id=27831789 (Svgbob – Create a graphical representation of text diagrams)
Some past threads:
Show HN: Monodraw, an ASCII Art Editor for Mac - https://news.ycombinator.com/item?id=9545252 - May 2015 (53 comments)
Monodraw: Powerful ASCII Art Editor for Developers (Mac) - https://news.ycombinator.com/item?id=9145945 - March 2015 (3 comments)
Show HN: Monodraw for Mac, ASCII Art Editor – Beta Available - https://news.ycombinator.com/item?id=9138039 - March 2015 (11 comments)
ASCII art editor designed for the Mac - https://news.ycombinator.com/item?id=8445087 - Oct 2014 (107 comments)
Some past threads:
Show HN: Monodraw, an ASCII Art Editor for Mac - https://news.ycombinator.com/item?id=9545252 - May 2015 (53 comments)
Monodraw: Powerful ASCII Art Editor for Developers (Mac) - https://news.ycombinator.com/item?id=9145945 - March 2015 (3 comments)
Show HN: Monodraw for Mac, ASCII Art Editor – Beta Available - https://news.ycombinator.com/item?id=9138039 - March 2015 (11 comments)
ASCII art editor designed for the Mac - https://news.ycombinator.com/item?id=8445087 - Oct 2014 (107 comments)
Unfortunately in minimal maintenance mode for the last 3 years. https://blog.helftone.com/monodraw-maintenance-mode/
Still works well though.
Still works well though.
An implicit assumption in software seems to be that for it to stay relevant, it must be perpetually evolving. But there is something to be said for deciding a piece of software has reached it's intended potential and simply maintaining it.
Granted, it sounds like the author feels like there are more meaningful things to add or change, but that doesn't mean the software is any less relevant than it was 3 years back.
Granted, it sounds like the author feels like there are more meaningful things to add or change, but that doesn't mean the software is any less relevant than it was 3 years back.
Do Mac apps stay functional for long without work put into maintenance by their developers, with all the breaking changes introduced by Apple?
Looks like they’ve released Dark Mode support and Apple Silicon support since that blog post. So maintenance does actually mean maintenance.
In reality it is still maintained though I think. They released an update to bring native Apple Silicon support for example: https://blog.helftone.com/monodraw-v1.5-apple-silicon-macos-...
The post even mentions a Big Sur / Monterey visual refresh currently in development. As "maintenance mode" projects go, this looks like the best of the best.
I have a small tutorial on how to create kind of responsive elements in Monodraw: https://trusz.github.io/posts/monodraw-tips-anchors/
I’m the author of Monodraw, happy to answer any questions.
I really wanted to thank you for making such a great piece of software. I always use it in my code documentation!
Monodraw is always a delight to use. People like you make me think that software engineering still has some hope :)
Looks like a really great app! However, screen shots from older versions of Mac OS on a product page always make me a bit worried about the future of an app. Do you intend to update the UI and such to match Big Sur and the upcoming Monterey?
It's been on my list and we've made some progress but to be completely transparent, I've been extremely overloaded and it's been hard to set aside time for it.
So, I'll try to get to it eventually but no promises on timeline.
So, I'll try to get to it eventually but no promises on timeline.
Completely understandable. Best of luck!
What are some specific things people have done with your software that surprised you, or made you feel proud of what you've created?
I get the occasional email from users about how much they love Monodraw which makes me so happy.
I've been told it was used for wire-framing and mind-mapping which I never envisioned!
I've been told it was used for wire-framing and mind-mapping which I never envisioned!
@ragnot, @Khaine, @typon et al: Thank you for the very kind words about Monodraw - it made my day!
I also wanted to thank you for making such an awesome piece of software.
What a relief it is to see a snappy, lightweight native app.
Remember, when embedding ASCII art in HTML, hide it from screenreaders and provide alt text. Otherwise it's an incomprehensible mess of seemingly random characters.
Good point, any pointers to how I'd best do that?
Not the OP, but I'd just wrap it up like this:
> ...most screenreaders will consider the element with role="img" set on it to be to be like a black box, and not access the individual elements inside it.
(https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...)
<div aria-role="img" aria-label="{your alt-text here}">
<pre>...</pre>
</div>
> ...most screenreaders will consider the element with role="img" set on it to be to be like a black box, and not access the individual elements inside it.
(https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...)
Neat! I'll make sure to do it this way. That makes me wonder, what else on the websites I (not a web dev) maintain might need special treatment for accessibility. Pity the Chrome dev tools don't seem to help with that.
Does it have layers like in photoshop? Or does the group functionality let you overlay and then move the group away without ruining the underlying drawing?
Looks absolutely amazing.. I wish there was a Linux version.
If you're interested in this, I'd encourage you to look at MarkDeep (https://casual-effects.com/markdeep/).
This allows you to write Markdown-style documents, including ASCII-art diagrams, but which render beautifully in any browser with JavaScript. Using Monodraw or ASCIIFlow as the front-end editor, you can drop most results in a Markdeep document. Bonus: good inline math typesetting plus loads of other awesome document features.
This allows you to write Markdown-style documents, including ASCII-art diagrams, but which render beautifully in any browser with JavaScript. Using Monodraw or ASCIIFlow as the front-end editor, you can drop most results in a Markdeep document. Bonus: good inline math typesetting plus loads of other awesome document features.
I've always liked ascii flow https://asciiflow.com
But actually more often I've needed things like https://github.com/weidagang/text-diagram as it is much easier to maintain
But I actually need more types of diagrams, so slowly, as one of many little side projects, I've been building a little library for all kinds of ascii diagram generation
But actually more often I've needed things like https://github.com/weidagang/text-diagram as it is much easier to maintain
But I actually need more types of diagrams, so slowly, as one of many little side projects, I've been building a little library for all kinds of ascii diagram generation
That sounds great, I don't suppose you have anything of that project that's ready to share (even just to look at, not use)?
This really is excellent. I can see a lot more sequence diagrams and illustrations getting into my code comments in future. Well worth $10.
This looks pretty cool, though unfortunately I'm not near my Mac so I can't really check it out. I'd be interested to know how its freehand pencil tool compares to JavE's (http://www.jave.de/). I always thought that was the coolest feature of JavE.
[deleted]
What's the purpose of being able to embed an image in the sheet? Is it intended to be an aid to `tracing' an image when creating ASCII art, or does it have some other purpose?
I’ve used images scattered around the art board for reference. I like to copy brandur’s diagrams a lot, so I’ll usually have a couple of his on my board to reference.
I need this so much... I have to use Lucid Charts in Confluence...
This could have been OmniGraffle's April Fools'.
This looks really cool, and I'd totally buy this if it had a windows version. I don't a mac, nor do I really want one.
Can it use other Unicode character drawing glyphs? We now have PETSCII, ATASCII, 2x3 mosaics...
Similar:
git://bitreich.org/gramscii
git://bitreich.org/gramscii
[deleted]
Ah, good ol' ambiguous-width box drawing characters. They are not ASCII and their width is not prescribed by the Unicode standard and mostly determined by domestic conventions. Stick to ASCII drawing for the maximal portability.
Late reply but I just downloaded it, and it supports that. Change document mode to ASCII and you get
X
/ \
/ \ X
| |--------+ / \
\ / | / \
\ / +-------->| |
V \ /
+--------------------+ \ /
|lkjhlkjhlkjh lkjh | ---+ V
+--------------------+ | +--------------------+
+---> |lkjhlkjhlkjh lkjh |
+--------------------+Long time Monodraw user here as well. While I still use it quite often for README.md docs, excalidraw has replaced most of the use cases I had, along with having a much nicer and upbeat feel (something I'm generally after when writing boring technical docs).
Anyway Monodraw is just awesome in its own way, and I really like the easy way you can draw stuff in it, ASCII is so restricting it simplifies design decisions for us art plebs quite a bit. I just wish there could be a way to export it as a xkcd / excalidraw style PNG after you've done drawing.
Anyway Monodraw is just awesome in its own way, and I really like the easy way you can draw stuff in it, ASCII is so restricting it simplifies design decisions for us art plebs quite a bit. I just wish there could be a way to export it as a xkcd / excalidraw style PNG after you've done drawing.
Love the Sketch-style feel.
This looks really cool. Well done! And no electron. Will definitely try it out
I get the hate that Electron gets for it's weight and overhead, but this is a perfect example of why Electron has value.
This app has no dependency on native OS for anything beyond writing data. It doesn't need to compile heavy code bases, it doesn't need fast GPU or other access. It could have very well been an electron app, and it would have the benefit of being widely available on many platforms.
I'd love to be able to use this app, but as a Linux and Windows user, I'm unable to. So I'll be searching for an alternative that runs on the platforms I have access to.
That said, no hate on the author for building the tool to their needs and desires. It's a fantastic looking app, and looks well executed. Wish I could use it.
This app has no dependency on native OS for anything beyond writing data. It doesn't need to compile heavy code bases, it doesn't need fast GPU or other access. It could have very well been an electron app, and it would have the benefit of being widely available on many platforms.
I'd love to be able to use this app, but as a Linux and Windows user, I'm unable to. So I'll be searching for an alternative that runs on the platforms I have access to.
That said, no hate on the author for building the tool to their needs and desires. It's a fantastic looking app, and looks well executed. Wish I could use it.
It would not be possible to do this in electron.
To have the same great native feeling UI you’d need to use AppKit - not HTML.
Don’t get me started at the usual shortcuts and general platform behavior most electron apps get wrong.
To have the same great native feeling UI you’d need to use AppKit - not HTML.
Don’t get me started at the usual shortcuts and general platform behavior most electron apps get wrong.
The insistance on native feeling UI and shortcuts is something I only see from Mac users. I think the app would work perfectly well in Electron but would just attract the usual complaints from Mac users.
One potential conclusion: Mac users understand the productivity increase and the value of apps feeling native, since the Apple ecosystem is one of the primary places to get such a native experience today.
This shouldn't necessarily be interpreted as "Mac users are special flowers", but rather, "Mac users may have stronger opinions about this because they've experienced the benefits of native apps".
I've been around the block with operating systems, and was primarily a Linux user for many years. Later in my career, I started to appreciate the simplicity and consistency of the Apple ecosystem, and while I recognize that's not everyone's thing, it lets me focus on the job at hand and spend less time learning how to use new apps/tools. This is valuable.
This shouldn't necessarily be interpreted as "Mac users are special flowers", but rather, "Mac users may have stronger opinions about this because they've experienced the benefits of native apps".
I've been around the block with operating systems, and was primarily a Linux user for many years. Later in my career, I started to appreciate the simplicity and consistency of the Apple ecosystem, and while I recognize that's not everyone's thing, it lets me focus on the job at hand and spend less time learning how to use new apps/tools. This is valuable.
That's a great conclusion. Sadly the way it's usually felt is through entitlement. I can't count the number of time where I've seen an electron/Flutter/anything app presented, and Mac users are once again asking for a native app while pretending to not understand why the app is cross platform in the first place.
If they're so attached to native apps, maybe they should build a website/community where people ready to pay more for native apps can say they want for example a native client for slack, discord, spotify, and then the companies can see if it's viable or not.
My problem is that these complaints are exactly like "the back button is broken", it doesn't bring anything new or interesting to talk about, people never propose to help a project or to pay money for new features, they just complain and never stop. This isn't good content for Hacker News in general.
If they're so attached to native apps, maybe they should build a website/community where people ready to pay more for native apps can say they want for example a native client for slack, discord, spotify, and then the companies can see if it's viable or not.
My problem is that these complaints are exactly like "the back button is broken", it doesn't bring anything new or interesting to talk about, people never propose to help a project or to pay money for new features, they just complain and never stop. This isn't good content for Hacker News in general.
I'd say that if you had to choose a desktop platform to build paid apps for Mac OS is the best choice. Mac users tend to spend (more) money on software.
BTW. there is a paid native slack client: https://shrugs.app
BTW. there is a paid native slack client: https://shrugs.app
Another take on it is that Mac decided to go a different path on a few different UI things in the past, and that has persisted to this day.
Look at how *nix, Windows, Sun, BSD, Chrome OS (which is basically a linux anyways) all use Ctrl, Meta (alt), and Shift for their hotkeys, compared to how Mac uses Hyper (cmd).
Also look at how Mac has one instance of an app's tool bar/menu that all windows share.
I'll agree that the consistent UI is a boon, but there's a large lack of discoverability imo, and some things that are just entirely lacking, like the ability to move windows around with hotkeys.
Look at how *nix, Windows, Sun, BSD, Chrome OS (which is basically a linux anyways) all use Ctrl, Meta (alt), and Shift for their hotkeys, compared to how Mac uses Hyper (cmd).
Also look at how Mac has one instance of an app's tool bar/menu that all windows share.
I'll agree that the consistent UI is a boon, but there's a large lack of discoverability imo, and some things that are just entirely lacking, like the ability to move windows around with hotkeys.
You've got the order reversed. Mac pretty much defined the modern WIMP UI and was the only real game in town for consumers & professionals from 1984 - 1990 when Windows 3 was released, and during this time an entire industry (DTP) was built atop Mac's strong UI foundations.
It's more accurate to say that in modern UIs the others decided to each go their own different paths and replicate part of what made the MacOS experience special, but they also tended to forget to include a lot of the little details that made it great, and have never had the same dedication to consistency.
Re: discoverability, there's an order to discovering advanced options in MacOS - hold Option and click on menus. You'll be surprised how far that gets you. The whole idea of MacOS and native apps is you learn how to use the system once, and you're rewarded from thereon out. Not all things are discoverable without these keys because not all things are relevant for everyday uses and can add clutter - its a design choice to make simple things easy and hard things possible. They're not always perfect but they're still the best game in town.
RE: moving windows with hotkeys, just get an app like Magnet, problem solved.
It's more accurate to say that in modern UIs the others decided to each go their own different paths and replicate part of what made the MacOS experience special, but they also tended to forget to include a lot of the little details that made it great, and have never had the same dedication to consistency.
Re: discoverability, there's an order to discovering advanced options in MacOS - hold Option and click on menus. You'll be surprised how far that gets you. The whole idea of MacOS and native apps is you learn how to use the system once, and you're rewarded from thereon out. Not all things are discoverable without these keys because not all things are relevant for everyday uses and can add clutter - its a design choice to make simple things easy and hard things possible. They're not always perfect but they're still the best game in town.
RE: moving windows with hotkeys, just get an app like Magnet, problem solved.
Because some of us are shut down with responses of "be happy you got this app at all" (Linux users) or somehow get ignored when we speak up (Windows users - though I guess Windows hw often having more cpu power and memory leads to less complaints?)
I'd rather not have the app than have a version that feels out of place on my system.
An Electron app always requires extra muscle memory. Every Electron app is different from the other, they all miss the UI consistency that makes the Mac so productive to use.
I'd be interested to hear as to why you couldn't achieve the functionality of this app in Electron.
I agree with you that it's almost impossible to get a native UI feel in electron, but that's not always the first priority.
If the end goal of the application is to present a custom interface for drawing on a monospace grid for ASCII art, I'm not sure I see the argument that a native UI is necessary over any cross-platform kit like QT or even an html based UI. I totally agree on shortcuts being a problem. Dealing with those cross-platform can be a headache when sufficient care is not being taken. Especially from an outsider to the platform.
As a long-time linux user, most of the interactions on OSX feel wrong to me, but I know it's me that's the problem. If I were to write shortcuts for the OSX platform, I'm sure I'd get most of them wrong. Conversely, if an OSX developer was writing shortcuts for a linux or windows platform, I'm sure they'd face the same issue. It really benefits to have a platform expert you can consult for testing.
I'm not trying to eschew the need and benefits of native apps here, I was trying to point out the fact that the large amount of hate for Electron (and similar web UI on desktop solutions) have their place.
Heck, this entire app could have been a web app. I'm sure a few out there exist to do very similar things.
There's dozens of ways to accomplish things in the wonderful field that is software development, and the whole "this tech is bad" cargo-cult is more a disservice than anything. There are pros and cons to every decision that goes into an application, and taking a stance against one method without considering the use cases and how it could benefit or hinder runs the risk of loosing out on promising tech or excluding people from using your project.
I've seen Monodraw a few times over the years, and I've lamented the fact that I haven't been able to use it, which is what drew me to make my original comment.
I agree with you that it's almost impossible to get a native UI feel in electron, but that's not always the first priority.
If the end goal of the application is to present a custom interface for drawing on a monospace grid for ASCII art, I'm not sure I see the argument that a native UI is necessary over any cross-platform kit like QT or even an html based UI. I totally agree on shortcuts being a problem. Dealing with those cross-platform can be a headache when sufficient care is not being taken. Especially from an outsider to the platform.
As a long-time linux user, most of the interactions on OSX feel wrong to me, but I know it's me that's the problem. If I were to write shortcuts for the OSX platform, I'm sure I'd get most of them wrong. Conversely, if an OSX developer was writing shortcuts for a linux or windows platform, I'm sure they'd face the same issue. It really benefits to have a platform expert you can consult for testing.
I'm not trying to eschew the need and benefits of native apps here, I was trying to point out the fact that the large amount of hate for Electron (and similar web UI on desktop solutions) have their place.
Heck, this entire app could have been a web app. I'm sure a few out there exist to do very similar things.
There's dozens of ways to accomplish things in the wonderful field that is software development, and the whole "this tech is bad" cargo-cult is more a disservice than anything. There are pros and cons to every decision that goes into an application, and taking a stance against one method without considering the use cases and how it could benefit or hinder runs the risk of loosing out on promising tech or excluding people from using your project.
I've seen Monodraw a few times over the years, and I've lamented the fact that I haven't been able to use it, which is what drew me to make my original comment.
One example: native document-based Mac apps have file handling functionality in the window's titlebar (rename, move, tag, etc). It's very convenient. Electron apps don't.
Another: native Mac apps by default reopen where you left off. Open windows, open documents, etc. Electron doesn't get this functionality automatically; you could spend time recreating it, but it still would integrate with native settings.
Another small example: native Mac UI controls reflect the system-wide accent color the user's selected. With Electron, you'd have to either spend time rebuilding the functionality or omit it.
Mac users like Macs because Macs work like Macs. Electron apps ignore the benefits and features Mac apps usually get automatically and just revert to the lowest common denominator.
Another: native Mac apps by default reopen where you left off. Open windows, open documents, etc. Electron doesn't get this functionality automatically; you could spend time recreating it, but it still would integrate with native settings.
Another small example: native Mac UI controls reflect the system-wide accent color the user's selected. With Electron, you'd have to either spend time rebuilding the functionality or omit it.
Mac users like Macs because Macs work like Macs. Electron apps ignore the benefits and features Mac apps usually get automatically and just revert to the lowest common denominator.
That's less of why the app couldn't be written in Electron and more of why Mac users wouldn't like an Electron app.
Perfectly valid reason why someone would want to write their app as a native app though, and I appreciate that.
Some of those are definitely things Electron gets wrong and should correct. Handling system-wide accent colors is exactly the kind of thing my UI kit (Electron in this argument) should be handling and not forcing everyone to re-invent.
I've never used or even heard of the titlebar file handling functionality and had to search that right now. This is exactly the kind of thing I've said about discoverability. I used OSX for three years daily, and I've been using it on and off as needed since around 2010. Some things that people love and use all the time are just not obvious to everyone.
Perfectly valid reason why someone would want to write their app as a native app though, and I appreciate that.
Some of those are definitely things Electron gets wrong and should correct. Handling system-wide accent colors is exactly the kind of thing my UI kit (Electron in this argument) should be handling and not forcing everyone to re-invent.
I've never used or even heard of the titlebar file handling functionality and had to search that right now. This is exactly the kind of thing I've said about discoverability. I used OSX for three years daily, and I've been using it on and off as needed since around 2010. Some things that people love and use all the time are just not obvious to everyone.
It's totally possible to do this in Electron. I've used plenty of Electron apps that were simply ripped off MacOS and dumped on Linux (Kitematic, for example). The entire Mac-native UI works perfectly fine on Linux, the only issue I ran into involved some Mac-ified ini files.
What do you mean by `Mac-native UI`?
I guess they tried to make the app look like a native app?
The interesting part is that this is even worse IMHO. Because you get into an uncanny-valley pretty soon.
I guess they tried to make the app look like a native app?
The interesting part is that this is even worse IMHO. Because you get into an uncanny-valley pretty soon.
Given the rapid development and maturity of virtualization, container, sandboxing, and emulation technology: to me it seems rather silly that it's not yet trivial to run macos and windows apps (and anything else one would want) transparently, side by side on the same machine. I'm not normally a microsoft fan, but their direction with WSL2/WSLg/WSA feels very interesting...
I like seeing devs embrace native frameworks. Electron apps just do UI so differently that its just a pain to use. For example dragging a file tab out of vs code doesnt create a new window like every other editor.
Just because it's not implemented yet doesn't mean it can't be implemented. Electron can do anything a native app can because it is a native app itself.
Anyway, you can do it without dragging which is actually even better. Just do Ctrl+K, O or on a Mac Cmd+K, O.
You can track when this feature is implemented here - https://github.com/microsoft/vscode/issues/8171
Anyway, you can do it without dragging which is actually even better. Just do Ctrl+K, O or on a Mac Cmd+K, O.
You can track when this feature is implemented here - https://github.com/microsoft/vscode/issues/8171
"you can do this thing in a completely different way than the native OS trains you to expect to do it, actually this is even better!"
Pfffft. Yeah, imagine using the mouse more than the keyboard for a coding tool though?
I think you underestimate a lot of the APIs for a platform and how they influence an app; Cocoa provides a lot for an application; for example, it can provide a lot of the structure for a document related app in terms of i.e undo/redo, window management, etc.
Get a Mac :) I would have not bought this app if it was not native. I love using it because the look and feel. I value this kind of beauty, call me a weirdo…
Lol. Had one for almost 3 years. Not interested in going back. I personally prefer my Linux laptop and home lab, with my Windows desktop for all things gaming and 3d CAD related.
I appreciate the vertical integration Apple has in all its products, but after feeling like I was fighting the system for almost 3 years, I was happy to no longer have to use it for my work machine.
To each there own though! I'm glad you enjoy it, and I'm glad to see Monodraw get the attention it deserves (it's genuinely a very cool app).
I appreciate the vertical integration Apple has in all its products, but after feeling like I was fighting the system for almost 3 years, I was happy to no longer have to use it for my work machine.
To each there own though! I'm glad you enjoy it, and I'm glad to see Monodraw get the attention it deserves (it's genuinely a very cool app).
> It could have very well been an electron app, and it would have the benefit of being widely available on many platforms.
There's nothing so intensive about it that it needs to be an Electron app either. It could just have easily been a cross-platform native app as well.
There's nothing so intensive about it that it needs to be an Electron app either. It could just have easily been a cross-platform native app as well.
This is why Qt or Flutter are interesting.
And think about how much more work it was. And how much more work it'll take to maintain and update.
It's an interesting choice to do native.
That said, very impressive work.
It's an interesting choice to do native.
That said, very impressive work.
> And think about how much more work it was. And how much more work it'll take to maintain and update.
This isn't really true when supporting a single platform, assuming the author is fluent in AppKit etc.
This isn't really true when supporting a single platform, assuming the author is fluent in AppKit etc.
AppKit apps also don’t usually break that easily. It’s surprisingly simple to get an abandoned OS X 10.0-10.4 era Cocoa app compiling and running on modern macOS, I’ve done it a couple times just for kicks.
I somewhat understand the hate for electron but as a non-Mac user I'd much rather have access to this app - and I suspect the author would rather have me pay them for it. For such niche software it seems silly to build it so platform specific.
To get that kind of native feel in an electron app is either impossible or going to take a lot more work than just using native SDK's. There's a reason people hate on electron, because it's a bloated alternative that merely comes close to having a native feel.
A couple of workflow tips for using Monodraw:
* Open a few docs in Monodraw at a time and leave them open for your different needs: text boxes, figlets, diagrams. Each with a few elements already waiting to be filled, cut & pasted, etc.
* For larger docs (e.g. newsletters) finish the writing in your text editor and bring it into Monodraw. Think Publisher or InDesign. Yeah, you can edit in here, but it's weird. Best for layout.
* Browse the sample file that opens by default when you load Monodraw. Good fodder in there.
* Snippets!
* Yes, it is just text but there is FILL to give order (front to back) of elements. This is really handy for making slides that expose a list one item at a time.
* Cut and Paste chunks in and out of your Monodraw file with your main document or take a clipped screen capture for dropping into a graphic or fancy format document (e.g. Illustrator). No need to export and paste.