Search This Blog

Introducing Pinta

Over the holiday break, I stumbled upon this article from OSNews stating that there was a need for something like Paint.NET for Gtk. Having some experience with porting Paint.NET to Mono Winforms before, I knew that that was a massive task. But it still got me curious about Cairo and creating a layered canvas, since I had never played with Cairo or Gtk.

After playing around for a few hours, I actually had a working paintbrush and canvas. Intrigued by my success, I played around with it for a few more days. By the end of the week I had a nifty little paint program with a few features. Now, a month later, it's time to open my little project up to the world: Pinta.

Pinta is a clone of Paint.NET. It already has a small, but hopefully useful, set of features like multiple layers and infinite levels of Undo/Redo.

I hope to implement the same feature set as Paint.NET. Currently there are several tools missing, as well as adjustments like brightness/contrast and levels and Paint.NET's effects.

Comments

This is fantastic. Paint .Net is a great project, but I really prefer using Linux and Mac OS X. I spend my days coding in C# on Windows but have been really wanting to write something more than just toys on top of Mono. Great work.

Really impressive. This will show also that Mono is exactly what users expect: a great framework to develop applications. And this application in particular shows simplicity and power on the same time, that could not be done without a great work of someone like you.

My congrats on this one! Hopefully to be included soon as a replacement for Gimp in some distro(s).

Excellent work. I've continued to be impressed by Paint.Net (never had much need for Gimp/PhotoshoP) but now that you've brought this to Linux - well sir, just wow! I think it's time to get involved :D

Wow, fantastic work! Truely you're a talented programmer to have knocked that up in a month. :)

Do you think you'll add plugins for it? If you do, I always thought it would be so much better if Paint.Net allowed plugin developers to register new tools on the tool palette, not just new effects under a menu.

I've always been put off by Paint.NET's non-commercial license. I've had to resort to using GIMP in the office and it's usually to do something that should be quick. However, GIMP's loading time is far from "quick" on my workstation and the user interface is too clumsy to get anything done in a short amount of time.

I hope Pinta will have a more liberal license that allows me to use it in the workplace.

Hey, great job! You mentioned adopting Mono.Addins which is great but what about existing Paint.NET Plugins? Will they be supported or will they have to adopt the Mono.Addins interfaces to work? I'm just wondering if it will be an easy transition or not. Also, have you talked to Rick Brewster to see what he thinks about this effort? I know he recently closed off the source citing that he did not like people re-branding his efforts. You have essentially done that here but for a good cause. Hopefully you can work with Rick and at least keep that line of communication open... maybe getting a little help here and there. I think this project is great and I wish you all the success. I will definitely be following your progress :)

While I think your work is amazing for just being coded in a month, I cannot stop thinking that this kind of efforts bring too much diversity to free software in general. Couldn't you work with Gimp devs to create a "Simple" UI to be enabled by default.

Don't get me wrong, I love Mono apps (Banshee, F-Spot...) and Mono dev tools and I kind of see why you'd prefer not to work with Gimp (plain C), but there was another possibility as Tom mentions, which is to fork Paint.NET from the last version that had a FOSS license.

@knocte: on the other hand, it's so much easier to work with your own code, rather than reusing and having to learn someone else's code (which may be huge and/or bloated, or may not share your logic).If this project got started so fast, I think it's partly because the developer masters his code base (plus the fact it's in C#). How much could he have achieved in just one month, if he had worked on GIMP instead?

Stifu: for sure. And Jonathan can do with his spare time what he wants.

But I'm thinking in a more general idea of benefit to open source. And for that you always have to think about the 2 extremes:

a) Imaging if all the potential contributors of free software had did what Jonathan did. There would be no collaboration at all in projects. All would be one-man projects. Definitely free software wouldn't even exist in this scenario.

b) Now think that for every use case out there, there would be only 2 free software projects existing (let's say one for KDE and another for Gnome). I would say that if this was the case, FLOSS today would be so much more advanced and spread.

@knocte: For me personally, hacking on GIMP is not a choice. I do not program in C/C++, and, God willing, I never will. :)

Having worked previously on doing a straight port of Paint.NET, I fully believe rewriting the interface and backend in Gtk/Cairo, and then borrowing some platform agnostic code from Paint.NET is the right way to go.

Paint.NET is *extremely* tied to Windows. P/Invokes number in the hundreds. And even if a straight port was done, no one on Linux would want a Winforms app. You can see this sentiment when companies port their software with Wine instead of writing a native version (Picasa, Google Earth).

To me (and the article I linked as my inspiration), there really is a difference in purpose between GIMP and Paint.NET. It's kinda like having both Gedit and OpenOffice at the same time. They both create text documents, but still have very different purposes.

a) You could program in not C/C++ for Gimp: I believe you already can use C# for plugins. For the rest, you can always use Vala which is very a-la Mono ;)

b) How about bringing all those p-invokes to an only-windows-specific assembly and working with them upstream? Now, not having done this will not pay off for what you want to do now: it will be difficult as well to separate Paint.NET agnostic parts into libraries, if there hasn't been much separation already upstream :(

PS: I get the point about the different purposes between GEdit and OpenOffice, however I don't get the comparison. What is the program that is needed in between the features of GEdit and OpenOffice? I think having those two is fine, I don't want anything more.

Sorry, but I find your suggestions pointless and I never said that Jonathan should do anything like you said. I only pointed him to the last Paint.NET source because maybe there is more code he can use in it(version 3.36 instead of 3.0).

FOSS is evolution. If Pinta does not find a developer community it will die eventually, but at the moment it has a lot of potential. Space limited distros like Ubuntu are likely to ship something this small and powerful because they have Mono already on the CD. Gimp had to go because it was too big and too powerful.

So as Thom in his OSnews article mentioned Gnome needs something like this and we should all thank Jonathan for starting it and moving the a to the end :)

We will see if Pinta or Nathive or whatever will eventually find a sustaining community, but it is no use in not starting it, because Pinta has a great head start because of all the Paint.NET code.

(~15.6MB total; The dependencies with no size listed were already installed as dependencies of packages that are included in Ubuntu and all mono related packages were removed before I started. Those are the uncompressed sizes. I used aptitude -R, so recommends weren't installed)

btw, one thing I noticed that's nice is it tells you what's missing when you try to run it, so I didn't have to search too much to find what I needed. Dependencies in the deb would have been nice, but I understand this is early stuff and that would be a hassle.

Popular posts from this blog

One cool new feature in Visual Studio 2010 is enhanced Multi Targeting. Presumably, its all about allowing developers to target both the 2.0 and 4.0 runtimes from VS2010, but what it really means is you can easily target Mono from within Visual Studio 2010.

Like this:

To enable this, you need to unzip this file to:C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v3.5\Profile

Once you do that, you can take your .NET project:

Go to project properties and switch it to the Mono 2.4 Profile:

Now it will compile using Mono's assemblies, and will flag methods that Mono does not contain, like thus:

This also works for Intellisense:

And Object Browser:

We are very excited about this feature, which should make it easy for people to ensure they are staying compatible with the Mono subset of the .NET framework without leaving Visual Studio. Once VS2010 is released, we will hopefully release the profile packs as we release each Mono version!

As part of this year's Google Summer of Code, there were two projects that got chosen that were on my personal 'to-do' list. I was happy these projects got chosen because frankly, my to-do list is not getting shorter nor are the days getting longer.

One of these is Ed Ropple's "Cloverleaf", which is an add-in to Visual Studio designed to facilitate writing and testing applications in Mono. We decided on the following features:

- Test in Mono: Clicking this would run the current solution/project on the Mono runtime on Windows.- Scan with MoMA/Gendarme: Clicking this would run MoMA or Gendarme (which can run MoMA) on the solution/project.- Test on Linux: Clicking this would take the solution/project output and copy it to a Linux machine or virtual machine, and automatically start it.

Ed did some great work over the summer, so for my Hack Week project I started polishing and packaging his code so we could get it into people's hands. Unfortunately, I only got…