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
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.
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.
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.
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).
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.
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.
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!
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'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.
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!).
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.
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...
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.
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.
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.
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).
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!
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.
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 :)
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.
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.
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
> 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.
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.
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.
#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.
"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).
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.
