ASCII art editor designed for the Mac | Hacker News Reader

ASCII art editor designed for the Mac

monodraw.helftone.com

220 pointslalmachado107 comments

This stuff is great for commenting code. I like to draw pictures in my comments. Now we need a LaTeX to ASCII to go with it:

     /*                                                                            
      * A = M G M^T                                                                
      *                         _               _   _   _                          
      * f(u,v) = [u^3 u^2 u 1] | A00 A01 A02 A03 | | v^3 |                         
      *                        | A10 A11 A12 A13 | | v^2 |                         
      *                        | A20 A21 A22 A23 | |  v  |                         
      *                        | A30 A31 A32 A33 | |  1  |                         
      *                         -               -   -   -                          
      *                                                                            
      *          ___3    ___3                                                      
      * f(u,v) = \       \       A[i][j] u^(3-i) v^(3-j)                           
      *          /__j=0  /__i=0                                                    
      *                                                                            
      */

Like in JavE: http://www.jave.de/docs/formula2/formula2.html?

Cool. I may try that out. I would like to use LaTeX notation though : $\sum_{i=0}^{n-1} \sin 2\pi i/3$

It seems like nroff+eqn ought to be able to do the job, but the GNU implementation I have handy doesn't seem up to the task. Sympy, on the other hand, does the job beautifully, especially if you're using unicode: http://docs.sympy.org/dev/tutorial/printing.html

Neither is LaTeX syntax, though.

Hey guys, I'm the developer of the app - glad to see it appear on HN. I'm working on it as we speak, so that we can ship the beta out ASAP.

If anyone has any questions, just shoot - happy to answers :)

Thanks!

Did you intentionally do this? or is it a response to strange white spacing in chrome? http://i.imgur.com/VE2JT1N.png

I'm on Win8.1, Chrome (latest stable), 1366x768

Apologies that the robot didn't render correctly in your browser - here's how it should look http://imgur.com/pst21UO

I believe this is caused by the font used to render it, which is not a monospaced. We'll investigate it first thing tomorrow morning and make sure it works on all platforms / browsers.

Sorry about that - thanks for letting me know :/

I also have a (yet different) version of the robot rendered in my browser (Firefox on Ubuntu). I'm sure it is due to the font, which is monospaced but which probably doesn't include all the Unicode code points that you are using in your image.

Which is one of the weaknesses of using Unicode characters in "ASCII" art---anything outside ASCII itself risks being missing in monospace fonts. Some of it is pretty well guaranteed (like the DOS-pedigreed box-drawing characters), but a lot of that is going to vary from system to system to system depending on just what fonts are installed.

Perhaps you could have an option to render only a common subset of characters? Otherwise the central premise of the tool is substantially undermined.

EDIT: To illustrate (and maybe help debug), the version on mine looks like this: http://i.imgur.com/WI4eRLo.png

Looks really promising. Do you already know what the price of the application will be once it's finished?

No, we haven't settled on a price yet (I don't know what it should be). If you have any thoughts on the subject, I'm all ears :)

Our top priority currently is to create tool that we're proud of and which ours users love. The financial side is only secondary (although very important). When we get close to releasing v1, we'll put more thought into it. The beta will be free to use for everyone (and that should last quite a while).

The development of Monodraw will be very open from now on, I'll be writing about my thought process about all aspects, if you're interested make sure you follow our blog.

Pricing will of course depend on the size of your userbase and what you feel you need to fairly compensate the dev work put into this, but I can give you my feedback as a consumer.

If the price point were about $19 or less, I'd think about it, maybe play with it a bit, and probably buy it without too much hesitation if it worked well.

At $9.95, it would be an impulse buy that I might not even bother to properly evaluate first, just because it's so useful and looks so good. (I know I should try before I buy, but I'm being honest about my purchase behavior)

If it were higher-priced, in the $39-$89 range, I'd think very carefully about why exactly I needed it, and probably make due without unless there was a very compelling case I could make for it.

Any higher than that, especially getting into three figures, and I wouldn't buy at all.

Impressive, nice work!

Can't wait to get my hands on it. How long before Beta comes out?

I don't want to give any estimates as they would just be broken, lead to user disappointment and put unnecessary pressure on us.

But I can tell you that from the bits that we have left, none of them require any internal architectural changes and it's mostly just implementing missing bits and pieces.

We have two major improvements that are left to be implemented (I'm in the middle of the first one) and the rest are minor. For example, document zoom is trivial to implement (practically, it involves putting some UI controls and some small bits of code to tie loose ends).

I'll be very open about the development process and try to keep everyone informed as much as possible. My advice would be to follow @Monodraw, our blog and/or myself (@milend).

Why Mac and not Linux/Windows.

So, there are two related questions on that subject.

1) Why Mac? Because I'm an Mac / iOS developer and I know Cocoa. I have no experience programming for Windows (e.g., MFC, WinForms, WPF) nor Linux (GTK+ / Qt - I dabbled a bit many years ago but that's about it).

2) Why not use a cross-platform toolkit? Fundamentally, a cross-platform app is at odds with our core value - providing the best user experience. In practical terms, this means we have to use the native toolkit for the platform. While it is true that you can use a cross-platform toolkit, the experience will never be as good as it can be. Moreover, not only do I lack experience with such toolkits, if we want to make a cross-platform app, we would want it to feel native on all major OSs. This involves an incredible amount of work and resources that we do not have.

It all boils down to the fact that we want to make the best app for the platform that we have experience with.

Hope that clarifies the reason why it's Mac-only.

Will you be supporting ANSI / VT100 escape codes?

Possibly, depending on user demand. The first beta build will not have support for ANSI, though.

In general, the best way to have your voice heard would be to drop us an email, so that we can have at least some quantified data - thanks.

This is the kind of tool I've been wishing for for years. I can think of lots of uses for it, both practical and fun.

I'm particularly happy to see that you're building it as a native application rather than a Web app, so I can trust that I'll be able to use it for years to come, even if the product pivots, gets acquired, or changes for other reasons.

Thank you for making something that users can actually own, rather than just access.

Thank you - I'm glad that we are on the same page :)

I've got nothing against web apps, I use some on a daily basis - they have their own set of advantages over native apps.

But for the purposes of Monodraw, I wanted to provide the absolutely best user experience. I want 60fps with tons of elements on screen, I want to be able to tap into the OS and integrate with it. Our auto-tracing code would take advantage of all your computer's cores. I even wrote my own custom text layout engine and now you can do some really cool things with it. I love the interactivity and fluidity of native apps.

You're absolutely right that once you have the app, it's yours to keep. Our proposition is simple - we will charge for the software and our users / the market will decide whether it's financially viable. Our job is to make an outstanding product that delights customers.

This is pretty neat. I'd much rather have a web version for two reasons though:

1) Most of the time I'm making ASCII art it's kind of a one-off (not a daily thing). I'd say it's a thing I want to do maybe once a week or month. So I'm liable to forget I have this installed, and go google something. (My applications folder is full of "this looks handy" things that I never ended up using).

2) Most of the times where this would be useful to me is when I'm doing graphics coding, where a visual comment with maybe some equations is handy... but if I'm doing graphics coding I'm usually in windows (apple's opengl drivers suck), and I'm definitely not going to reboot.

This looks really promising! I'll probably use it to make diagrams for org-mode in Emacs.

One thing though, please charge for it. I'm sure plenty of people would be willing to throw money at you for this.

Thank you :)

Yes, we are going to charge for it because we have to - we are a very small independent software studio without any funding.

The future of the software belongs in the hands of our users, they will decide if our work is worth it and support us financially.

Do you know about M-x artist-mode or M-x picture-mode ? With the first one you can draw shapes with your mouse, the second is keyboard only.

Looks great! Sometimes I use http://asciiflow.com for my ASCII diagrams needs.

Do you actually like the newer ASCIIflow? I prefer the older one myself: http://www.asciidraw.com/#Draw

I have mixed feelings about this. The features are pretty much the same, but I like the grid in the newer version.

Lovely idea, seems very tastefully done. I find myself occasionally using artist-mode in emacs, and I have endless nostalgia for extended ASCII box-drawing, having made crappy RPGs for a good 25 years.

I actually feel like this could have a genuinely useful place on the modern internet. If you look at the success of animated gifs, it's a lo-fi, lightweight solution to video. I think this could be the same for quick diagrams, on blogs or in tweets.

Is there colour support? Outputting HTML and CSS snippets with `white-space: pre` would be great.

Anyway, will definitely check it out when it's shipped!

Thanks :)

There's currently no colour support, as my focus has been to make a solid v1. I've looked into ANSI escape sequences to support colour and it should be quite easy to add.

Part of the problem when I work on Monodraw is that there are so many cool things I stumble upon related to text art and I want to do them all but have to restrain myself, as there's only so much I can do.

We do have something related to HTML / CSS output in the pipeline which I'll be talking about more over the next few weeks.

I found some really interesting software I'd not heard of through this thread so I thought I'd post this for anyone else interested:

http://picoe.ca/products/pablodraw/

More of a paint than a draw, but pretty damn cool and xplatform.

Also Monodraw looks absolutely awesome. I'll be paying for it when you release it

ASCII? The arrows alone scream UTF-8 and require proper charset- and font-support.

But it's a cute tool, no question.

I've designed the app so that you can choose your character set - Unicode or ASCII. This is a property of the document and can be changed on the fly, so you should be able to use the tool for text in a legacy environments as well.

Will it support CP437 (http://en.wikipedia.org/wiki/Code_page_437 )?

It's quite easy for me to support arbitrary character sets, so if there's enough demand, I can definitely implement it. If you can just drop us an email (see "How do I provide feedback" section at the bottom), that'd be great - thanks.

But it won't be supported in the initial public beta build, as we have to prioritise other areas (sorry!).

> We would generally not hesitate to drop support for older versions of OS X if it allows us to improve the user experience.

That's an attitude I love to see. Especially since OS X updates are now free and afaik all hardware that supports 10.9 will run 10.10.

Very nice looking and polished job!

> That's an attitude I love to see.

Because when OSX n+1 is released, it's immediately impossible to get any work done on OSX n?

I'm still on 10.6 and see no reason to upgrade.

>Because when OSX n+1 is released, it's immediately impossible to get any work done on OSX n?

No, but as a developer, I can do much more on OS X n+1. And you're not even on n, you're on something like n-4.

Curious though, is it hardware holding you back, or do you simply not like the direction Apple is going with OS X atm?

In my opinion, 10.6 was the closest thing Apple's had to a Windows XP. I mostly skipped 10.7 and 10.8, but now use 10.9 on everything that can run it, and keep 10.6 on the machines that can't.

NIR the original poster, but I'm held back by hardware. 10.6 works great with even 2GB of RAM, whereas anything past that often grinds even with 4, and of course, being macs, upgrading memory on laptops is basically impossible.

Whether you can upgrade and how much you can put in varies by machine, but Apple publishes instructions for upgrading your own RAM: http://support.apple.com/kb/HT1651, http://support.apple.com/kb/ht1270

The Apple laptops that could come with as little as 2GB of RAM used completely standard SO-DIMMs that could be replaced by removing just a few Philips-head screws; on most models, it's 3 screws under the battery. It's not even close to impossible.

Because when OSX n+1 is released, it's immediately impossible to get any work done on OSX n?

No - but the same logic applies to application software, right? If SuperApp m+1 requires OSX n+1, surely you can continue to get work done with what you have now - SuperApp m running on OSX n?

There's no reason for developers to handicap SuperApp m+1 by avoiding all OSX n+1 APIs...

One of the major reasons for that position is that OS X updates are now free.

The user experience comes first, no compromises. But please note that I'm not saying that I'll drop support for 10.9 because there's some convenient API on 10.10 that will save me a few days of work. 10.10 would be a requirement if and only if it provides a meaningfully better experience.

I also think some developers might start requiring 10.10 for their next major versions, assuming they have been designed in line with Yosemite's new visual language. Supporting both < 10.10 and >= 10.10 UI-wise would involve non-trivial amounts of work, would for most small indies would be impractical.

Looks very promising. I used to draw .nfo's a long time ago, this is a tool I wish I had back then. I would use it today for commenting on code, if only it were web based instead of Mac only.

Oh, why are all the cool toys coming out for Mac these days?

My co-workers who run Windows hate me for this; every few days I get super excited about some awesome tiny tool that saves me time, and explain in rushed tones how awesome it is, only for my co-workers to groan once again when I sheepishly mention its "Mac only"... on the other hand, they have some awesome apps I don't either!

Almost the first search result [1], not sure how they compare in detail but it seems quite similar.

[1] http://www.torchsoft.com/en/aas_information.html

The OS and its ecosystem inspires folks to create beautiful stuff with a great attention to detail.

I don't think all the cool tools are coming out for the Mac but it's undoubtedly skewed towards it. The reasons for this are a mix of cultural, social and technical, along with momentum.

Speaking for myself, when I was getting into serious programming, it was right in the heyday of the Delicious Generation (Delicious Library, Disco, AppZapper and more). Back in the 10.4 / 10.5 days, eye candy and ease-of-use were the top priority. Some notable apps came out and they in turn inspired other developers to follow the same path - a polished user experience is absolutely vital. This creates a self-perpetuating cycle, where the existence of such apps creates fans who dream of making apps like that (I'm one of these).

..because the PC one has been out since 1986

http://www.syaross.org/thedraw/

http://artscene.textfiles.com/ansi/information/ansidraw.txt

More developers use OS X these days?

Check out "aacircuits" for Windows. It's been around for at least 15 years, but is oriented towards drawing circuit diagrams:

http://www.tech-chat.de/aacircuit.html

As I recall, folks used it for inserting circuit diagrams into usenet posts. I've used it for sticking skeletal hookup diagrams into my microcontroller source code. When I write a code to access a particular device such as a specialized chip, I like to include in the comments a diagram that will at least let you demonstrate the code.

As an aside, the cool toys are coming out for this "operating system" called Python. ;-)

This is great. I needed to draw some ASCII art as part of a network design project I was doing and having something like this would have saved me a ton of time.

http://i.imgur.com/za2WQUF.png

There is only one text example on the page, and it is messed up.

Nice project! In the past I have used asciio (cross platform): http://search.cpan.org/dist/App-Asciio/lib/App/Asciio.pm

Demo: https://www.youtube.com/watch?v=0l9W84PhOyI

Any plans for a windows version?

I would love to but I'm not a Windows developer (I have no experience on that platform), so there are no immediate plans. Depending on how things go, we might re-consider.

I'm also playing with the idea in my head of collaborating with some Windows developer to make it happen, although it's nothing more than just a thought. If any Windows developers are interested, please get in touch - thanks :)

I'm told that a number of developers have had luck with using GNUstep to port Mac apps to other platforms.

Now this is a text editor. Somewhere between Emacs and MS Paint. Not sure how I'd want extraneous whitespace to show up (where are my newlines? or can you only select rectangles). The execution looks refreshing.

As far as the internal data model is concerned, there are no newlines. All shapes exist in an abstract discrete coordinate system and draw to it (if you're using the text tool, you can insert new lines etc but that's internal to the text shape, the canvas only cares about what characters appear at what abstract point).

Of course, when we export as text, we need to insert newlines so that it renders the way it's displayed.

Thanks for the kinds words about the execution :)

http://www.jave.de/

This is great! I was a member of many ansi and ascii groups back in the day and anyone who makes anything related to text art has my utmost respect.

I really wish it was multi-platform though.

Hey! A shout out from the developer of Email Effects, a now pretty much defunct ASCII art editor that was all the rage in 1997 :) Good luck with your project.

The website doesn't work for me (win8.1, ff32):

1. The screenshots are not displayed fully, but clipped at the window edge.

2. The robot displays improperly, maybe because of missing font?

1. That's part of the design, should be apparent at most sizes but if your browser width is around the 2000px mark, it will look more like a bug.

2. Sorry about that, the issue seems related to the font metrics which results in the robot looking misaligned. We'll fix that it in the next few days. Here's how it should look correctly - http://imgur.com/pst21UO

You're using Windows and you're using Firefox - two things that the target demographic for this product would never do.

I like it! It's not just ASCII, though.

Thanks! I replied to fensipens explaining that the app can work in both Unicode or ASCII mode, which can be switched on the fly.

The reason why I made the screencast in Unicode mode is simply because it looks nicer :)

Why? Why would you want this? Its not like I'm running a dialup BBS.

If you have to ask you will never know.

Very nicely done, I love it! Thank you!

What's the point?

ASCII period.

Looks great!

> Plain text has been around for decades and it's here to stay. Monodraw allows you to easily create text-based art – like diagrams, layouts, flow charts and visually represent algorithms, data structures, binary formats and more. Because it's all just text, it can be easily embedded almost anywhere.

> [...]

> Monodraw is designed for the Mac from the ground up – everything from the text layout engine to the interface is made to take advantage of OS X.

Is that perhaps a philosophical disconnect, or is it just me?

Granted, the most significant thing is that files created with this tool can be used anywhere else. Not that the editing experience of those files will be the same everywhere.

You're quite right that the most important thing about the tool is that you can take the exported plain text result and put it in your code, web pages, etc.

But when it comes to actually creating the content, we want to provide the best user experience. Monodraw can be thought of as a drawing app which was designed assuming the output would be ASCII.

In my view, those aspects are orthogonal - you can have a hard to use tool that exports into a standard format or an excellent tool that produces proprietary files.

Please don't put "Show HN" in titles when software isn't ready for everyone to try out yet: https://news.ycombinator.com/showhn.html.

Would anyone be interested in a programming language/framework which uses ascii art as syntax?

for example using boxes to denote classes and methods, and maybe arrows for events.

Check out Funciton (http://esolangs.org/wiki/Funciton) - an esoteric programming language that is based on a similar idea.

Sounds cumbersome.

I guess it would be cumbersome in a standard editor, maybe an ide which had function to create new methods and classes would be needed. also the added benefit is that the code could serve as a diagram of itself.

But if you're going to use an IDE to generate all the ASCII, why not just use regular graphics instead?

I guess because then you can view it in any editor later. Or view it in a simple terminal.

The folks at the Viewpoints Research Institute created a DSL to describe the TCP/IP stack using an ASCII diagram: http://www.moserware.com/2008/04/towards-moores-law-software... Befunge is also a sort of control flow diagram: http://en.wikipedia.org/wiki/Befunge

Sigvehtml[1] kind of does this (disclaimer: I made it).

[1]: https://github.com/sigvef/sigvehtml

How is the better than Ascii Pumper (http://www.findbestopensource.com/product/asciipumper) ?

It seems to be a completely different kind of app, for a start.

Why is it "for Mac"? Just use something like Qt and make it cross platform. Come on, it's not the dark ages anymore!

You simply can't create an app with a high-quality, Mac-conforming, polished UI with cross-platform tools like Qt. The apps always end up with small but noticeable differences and peculiarities compared to 'native' Mac apps.

You can argue about the merits of wanting such a UI, but given that the Monodraw developer does, creating a Mac-only app is the only option.

I usually care about functionality more than about small noticeable differences between platforms. "Not available at all" is way worse in my books than "doesn't look like 100% native".

Sure, any cross platform UI can be a trade-off. The question is what is more important, to leave out users of all other platforms by making the UI look more native, or to reach more users.

There's more to "look and feel" than just look. Qt's been using native rendering APIs for years, but they still have to emulate the native functionality, and when they get it wrong that's a lot more annoying than getting the look wrong.

I'm currently rewriting my Mac application. Its prototype was written in Qt, but I'm now dropping Qt for several reasons:

1. I demoed my application to my friends and they all complained that it didn't behave exactly like a native Mac application.

2. Qt5 has a lot of UI bugs on Mac OS X.

3. The LGPL license of Qt may not compatible with Mac App Store [1].

4. I could buy the commercial license of Qt, but it's $215/month for Mac OS X. I don't know if my app is going to sell at all, so I can't afford that kind of burden.

[1] http://blog.qt.digia.com/blog/2014/10/01/benefits-of-the-ind...

#1 and #2 are understandable.

#3 is Apple's fault. I'm not using OS X so I don't know about their installation policies. Do they require to use their store to install applications now? In the past you could just provide packages on your own.

As to 3), unless you are making closed source changes to Qt, I can't think of any way that the LGPL could make your app incompatible with the Mac App Store.

"designed for Mac" makes me sick these days. It's not hard to make good cross-platform software, especially if you only care about sane POSIX systems.

Not when it comes to GUIs! All the cross-platform frameworks seem to have issues that make them less than ideal.

Far more sane to have POSIX core code, then develop the GUI for each platform in the preferred mode.

And when it comes to graphics and drawing, divergences become even more extreme. POSIX is not relevant when it comes to pushing pixels.

I'll admit that I don't have a lot of experience with GUIs, but wouldn't Qt or GTK+ be suitable for this sort of thing?

Also, for an ASCII art editor, I'd say that even something as simple as an xterm-compatible terminal application would be suitable ;)

GTK+ works on Mac, but is pretty poor. I can't comment on Qt though, but in principle, yes I believe it is suitable.

An xterm-based[0] version of this would be very cool! Though the surface tool wouldn't work well in that situation.

[0]: http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#Mouse...

Qt has gotten much better over the past few years, but Qt apps on OS X still stick out like a sore thumb to anyone who is familiar with what Cocoa provides for free that Qt has to emulate.

Less than ideal is still way better than "it doesn't work on your system at all".

"You can please some of the people all of the time, you can please all of the people some of the time, but you can’t please all of the people all of the time"

I think a lack of focus in development, with the purpose of trying to please everyone, is a huge novice mistake when it comes to development.

Not these days anymore. Platform specific releases of desktop applications like these is a major novice mistake which inherits outdated mindset from the previous era. Unless we are talking about low level code.

Says who? Last time I checked, in all major platforms (Windows, Mac, Linux) there are platform specific releases that are doing great (commercial and open source).

(note: I consider KDE/Gnome programs as "Linux/*BSD-specific releases", which they pretty much are in practice).

If you have resources for such releases. We are talking about another choice here (i.e. either one platform only with native UI, or many platforms with cross platform one).

Is it really? Try: "Nobody wants to buy the app" vs "Ppl on X OS wants to buy your app".

If "nobody wants it", I doubt anybody on OS X would want it either.

I'd rather one great looking, well functioning app on one platform, than mediocre crap on several (but hey, I'm also on a Mac).

Reply on news.ycombinator.com