You may remember that back in November last year, I wrote about the lack of a decent Paint.NET-like application for Linux (or, more specifically, for Gtk+ distributions, since Qt has Krita). As it turns out, this compelled Novell employee Jonathan Pobst to code a Paint.NET clone in Gtk+ using Cairo. Version 0.1 is here, and it’s remarkably advanced for something so young.
“Over the holiday break, I stumbled upon this article from OSAlert stating that there was a need for something like Paint.NET for Gtk,” Pobst writes on his blog, “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,” he continues, “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.”
It’s called Pinta, and it’s currently at version 0.1 – in other words, a number of features are still missing. Its interface is very reminiscent of Paint.NET’s, but other than the code for adjustments and effects (which is taken straight from Paint.NET), Pinta is original code. It’s Gtk+, so it already runs on Linux, Windows, and Mac OS X.
You can obviously build the release from source yourself, but a SUSE .rpm is also provided. Using alien
, it’s relatively straightforward to convert the .rpm to a .deb for those of us using Debian-based systems (like myself). The .deb package created by alien
works flawlessly on my machine.
sudo apt-get update<br />
sudo apt-get install alien<br />
sudo alien -k pinta.rpm<br />
sudo dpkg -i pinta.deb
Be sure to match the names of the packages, of course.
For a 0.1 release, this is already a great application – especially considering it’s only seen a month’s worth of development. I’m excited about what the future will bring for Pinta. It isn’t specifically mentioned, but I’m sure Pobst could use a hand in development.
I see that GNU/Linux guys are at it again, copying and cloning.
Nice addition though.
Edited 2010-02-08 13:29 UTC
Err, in this case, it’s good they’re cloning, since Paint.NET… Is a Windows-only application. It just so happens it’s a damn good one.
Why should the guy reinvent the wheel when he can use MIT-licensed code instead that is proven to work well?
Because Paint.NET is Windows-only. There’s a lot of stuff in Paint.NET that’s written FOR Windows. A port would inevitably be broken, incomplete, and always outdated. A native Gtk+ version, using Paint.NET code where it makes sense, is a a much better approach.
I think that was coolvibe’s point – that Paint.NET is open, and borrowing from it for a *nix port is just fine.
Read before you spout. He took effects and adjustments from Paint.NET, because it was MIT-licensed. From the website:
(sorry for the doublepost, dunno how the fsck that happened)
Edited 2010-02-08 14:03 UTC
Read before you spout. He took effects and adjustments from Paint.NET, because it was MIT-licensed. From the website:
Yeah, because Microsoft have never copied from other people.
</sarcasm>
Edited 2010-02-08 14:01 UTC
Microsoft don^aEURTMt copy other companies; they buy them out.
Yes, but only after they have copied the ideas and the original comapny has almost gone bankrupt.
I’ve actually modded you back up, because while it might hurt it’s the truth. It’s not that we don’t have alternatives in the Linux world, but for some reason if you say you’re going to clone something from the Windows world it get headlines. Go figure.
Aside OOo, none of the Linux software I use regularly / every day is a Windows clone:
* Dolphin looks and behaves nothing like Windows Explorer
* k3b only look vaguely like Nero in the sense that nearly every other CD burning package also looks just like that.
* Firefox and Opera are cross platform anyway
* Kmail feels nothing like Outlook aside having the generic e-mail layout underpin.
* Eclipse (aside being cross platform) feels nothing like Visual Studio
* Kopete feels very different to MSN aside some very basic generic layouts
….etc
People keep harping on about how GNU/Linux copies from Windows / OS X, but in truth there is usually just one or two logical layouts for an application of a specific function and you’ll often find that numerous applications of that genre will all mostly follow the same layout regardless of platform (eg every instant messenger has the same ‘contact list’ and ‘chat window’ set up. every e-mail client – inc. cloud mail – will have a ‘folder list’ (inbox et al), ‘folder contents’ (e-mails) and the ‘item preview pane’)
And you can hardly complain about “copying” when a gap in a market is filled on one platform because they see a product neatly fill a gap in the market on an opposing platform (which is essentially what’s happened here – albeit with a little push from OS News).
If you didn’t allow for products to “copy” in that sense, then quite frankly we’d either only end up with one product per genre. eg:
* 1 type of TV set,
* 1 type of MP3 player, etc
or we’d end up with lot’s of competing products that are massively incompatible. (eg
* several TV sets that all receive different radio transmission standards,
* different portable music players that have their own patented media that no-other media player can play.
This is why I think the problem mainly arises when details are cloned, like how Microsoft’s ribbon bar is considered for OOo. This is because it’s the details that sets one product apart from another – the rest is just common sense and usability. eg it makes sense for all TVs to decode the same RF signals and for all portable digital music players to support MP3 (or at least come with software to convert MP3 to a natively supported file format) and it makes usability sense for all instant messengers to have a ‘contacts list’ and a ‘chat’ window.
Sorry for the lengthy post by the way.
All I saw was this:
* File manager
* CD burner
* Web browser
* E-mail client
* IDE
* IM client
Different names and functions, but it^aEURTMs all the same stuff. Where^aEURTMs the real innovation? Where^aEURTMs the stuff that Windows and Windows software cannot do? Where^aEURTMs the paradigm shift?
How about the fact that it’s Free? And open?
That’s a pretty big feature to me.
As I’ve said before, Microsoft and Apple don’t really innovate, and I personally do not expect FOSS to do so either. They take other people’s ideas, and make them marketable.
Edited 2010-02-08 16:59 UTC
I appreciate what you’re saying, but I think you’ve missed the point of my post.
I’m comparing like for like. If I described functions Linux can do that Windows couldn’t (or visa versa) then it wouldn’t be a very good example of software copying software.
Sure there’s real innovation in Windows, OS X and Linux, (though personally I’d argue that we’re on a plateau in terms of software innovation*) but I’m talking about everyday bog standard applications that real people use and use regularly.
Sadly, for the most part and in terms of standard applications, the scope for real innovation (and I mean original ideas rather than evolutionary ideas like taking the toolbar and making it prettier – as per the ribbon bar) is limited as GUIs are 2 decades old and usability dictates a certain degree of layout.
Thus, in todays computing, it’s usually the details that makes or breaks a product…..at least, that’s been my observations
* that said the problem with innovation is it always seems so obvious in retrospect yet impossible to think up at the time.
So to summarise (because this post has be a bit of a mess with a number of random thoughts):
* You’ve missed the point of my post.
* The reason I chose generic applications is because I’m discussing software copying software – thus it would be pointless to compare a Windows application against a Linux application that doesn’t perform the same functions.
Edited 2010-02-08 17:33 UTC
KDE’s Plasma desktop is fairly innovative. Not very different, the way you normally would use it, from any other desktop, but in the way it’s designed so that the user can relatively easily mold it and adapt it into whatever s/he likes. Considering how radical it actually is, I think the fact that so many (though only a few) people complain so loudly about the “cashew” says a lot about its success: the small, cosmetic niggles irritate some people, but they don’t even notice that they use something entirely different.
Writing off anything that isn’t a paradigm shift as just “the same stuff” is stupid. Everything in computing is just a slight variation on the same stuff. Where is anything in any OS that you cannot do in any other OS? We’re not going to see a anything close to a paradigm shift in desktop computing until augmented reality takes off and even then most people will write it off as a pointless variation on what went before.
As long as something makes one thing I do slightly easier than it was before then that is more than good enough for me.
Sometimes, the present paradigm works well enough. Open Source projects certainly do innovate, I dare say as much as Windows or OS X (tho I expect some will disagree). It’s just that, sometimes, every now and then, the tools you already have right now are the best solutions for the problems you want to solve.
Edited 2010-02-09 23:58 UTC
sorry but krita can’t really compare to pain.net…. krita is a lot more powerfull
Not everybody needs a sledgehammer.
Indeed, hence Collinm’s point that Krita can’t be compared to Paint.net.
+1,
some people are not able to read correctly
That’s when Kolourpaint comes in handy
What is missing in Gimp, that we need a new paint program in the GTk world?
Nothing is missing in Gimp, but sometimes you need a flyswatter to swat a fly, not a tactical nuke.
it’s not that something would be missing in gimp
infact it’s the complete oposite:
it’s overcomplete and as a result to complex for most of the people
paint.net doesn’t target the pro, it’s targeting the average guy who once a year needs to remove red eyes from the christmas-pictures
it’s a perfect example of less sometimes being more
Something like GIMP-Lite would be popular, IMO. Keep the features to a basic set, simplify the user interface, and make it a stand-alone portable application.
Missing from Gimp? Easy. A usable interface.
Oh, come on. Gimp isn’t that hard to use. Also, it’s not a paint program.
I disagree: Gimp is too hard to use for simple image processing, my proof?
I tried to use Gimp to do some trivial image processing (cropping, zooming, brightness changing etc) and found it hard to use whereas I had no issue using Paint.NET for the same tasks..
GIMP is actually very difficult to learn, even coming from a background in Photoshop or PSP. It took me years to really get a good workflow going in it. That said, it also took quite some time for me to learn the commercial software mentioned above. That could be because I’m not that artistically inclined; my talents lie in hardware hacking. Regardless, it’s like anything else that you strive to learn and grow comfortable with; at first you need those training wheels but over time you get good at it.
Also, GIMP is just as much a paint program as any other advanced image editor. If you use it to paint, it’s a paint program. It just also happens to be much more besides.
http://arstechnica.com/open-source/reviews/2010/02/hands-on-new-sin…
Enjoy.
What’s missing is exactly where it’s strength lies.
Hell yeah, sir!
I have always been a paint.net addict.
So much for portability of .net applications – rewrite is actually simpler. You have bigger chance of running normal win32 app using wine than finding something written for .net working with mono.
Uh…
The core of the application that does all teh hard stuff was a copy and paste job. He rewrote it in Cairo so it could take advantage of the Linux GUI features that lack support if you are using Mono’s winforms implimentation (which is just there for a convenience to get your .net app up and running quickly).
A Java app would be equaly as “portable” if the developer used a native set of widgits on windows that had limited support on Linux and OS X.
Well, you could copy&paste system-independent painting algorithms even if they were written in C++, so it is not much of an achievement. .NET and Java promised to take care of system-dependent stuff (like gui, networking, threads) too. The difference is that Java with SWT and Swing actually delivers on this promise.
and .NET w/ Gtk# fulfills that promise too.
Paint.NET isn’t even hindered from running on Linux because it uses Windows.Forms, it’s hindered because Paint.NET calls out to win32 C/C++ libraries.
If the author had chosen to use Java and SWT, it would still have the same problems.
If you want to create cross platform applications using C#, but like the Visual Studio Tools… use this:
http://jrwren.wrenfam.com/blog/2008/11/01/gtk-in-visual-studio-2008…
Gtk crossplatform? Sure, if you accept ‘working as expected under x11, buggy everywhere else’ as good enough (example: https://bugzilla.gnome.org/show_bug.cgi?id=598299 ).
because i’m not going to install mono to run that program
This program does not use Mono IN ANY WAY – does it?
EDIT: Heh, it does. Didn’t notice. I’m left wondering – for what?
Edited 2010-02-08 15:10 UTC
It’s written in C#, it just uses gtk# instead of winforms for the UI.
“You must be new here”?
(yeah, I know, bad target).
The fact that you see the words “Novell” and “Gtk+” strewn together should be enough of a hint.
Edited 2010-02-08 16:07 UTC
Well, it’s a clone of a .NET program, from which it re-uses some code. How would it *not* be using Mono?
So that he doesn’t feel like he’s trying to kill himself while coding the application, as is the case with C?
Is there something wrong using a technology that works?
C’mon, if you do not use software that does the job for some obscure reason like software patents, interesting how you get around without the likes of mp3 and h264.. which are patented by much more patent-litigious companies than Microsoft
There is nothing wrong with a developer using freedom that mono provides. And in turn, using the amazing software that mono enables to produce.
That’s only my opinion, not related with any company, cultist organization or people.
Edited 2010-02-08 16:09 UTC
Well that’s a repeatedly made statement, but one that after years still fail to produce much evidence of being true. There may be many examples of such in the vertical applications space. But it’s not surprising if those developers prefer to stay with .NET proper(or Java) rather than bother with Mono.
As for getting the leverage of amazing .NET applications, the porting requirements of Paint.NET show it to be a non starter. And while the regular examples showed when discussing Mono applications are not bad, they are far short of amazing. And most of them have alternatives, consider better by many.
The speed of witch Tomboy was ported to C++, can show that Mono is as a useful prototype tool and where it really shines. But considering the manhours going into Tomboy, that is not compelling either.
For me personally, it simply comes down to I have been a .Net developer on Windows for close to a decade now. I have no desire to learn a new language while I am already very proficient with C#.
There does not seem to be a large contingent of people falling over themselves to write brand new apps for Linux in C/C++ (as opposed to iPhone or something), so you may be stuck with apps written in languages where the willing programmers are.
And even fewer writing in Mono and C#, your point being?
Simply that you shouldn’t discourage already scarce developers from using the language that they want to use, or you are likely to get nothing at all.
i haven’t found a mono program that i liked and i’ve tested many of them from banshee to tomboy.
microsoft used patents against tomtom and other companies.
Well, wouldn’t necessarily agree. Docky is actually quite nice. Banshee is also nice and feature rich. I don’t think it’s the programs that should be judged.
banshee doesn’t give me anything new and exiting over rhythmbox
What was TomTom doing? I bet it did not fall under the no lawsuit promis.
they ware using FAT
+ two other patents
Edited 2010-02-08 18:50 UTC
Did either of those patents have a community promise that said they would not sue over non-licensed use?
voting down my comment doesn’t make me like mono and mono programs!
You also have Nathive.
From their website (http://www.nathive.org):
Nathive is a libre software image editor, similar to Adobe Photoshop, Corel Photo-Paint or GIMP, but focused on usability, logic and providing a smooth learning curve for everyone. The project runs in the Gnome desktop environment and anyone is welcome to collaborate on it with code, translations or ideas.
This project is in the alpha phase, so it is an incomplete work, unfit for the end user yet. The intention is to achieve a professional graphic editor progressively without giving up initial usability. Nathive is written from scratch in Python / C using GTK+, and is designed to be simple, lightweight, and easy to install and use.
Other raster graphics programs can be found at
http://www.opensourcesoftwaredirectory.com/#Graphics_Raster+graphic…
Heck, why are all GTK programs so ugly? That’s what came to my mind when looking at the screenshots.
Entirely subjective. I think they look quite nice especially when the Clearlooks theme (the default these days) is used.
It’s a matter of opinion I guess, but I find GTK+ to be high up on my own list of aesthetically pleasing interfaces. My favorites being OS X, then BeOS, I’d say GTK+ is third. Down at the bottom of my list are Windows XP and prior, KDE (yes, even 4.x), CDE, and the older GTK/Gnome 1.x interfaces.
Every new release of Gnome it seems GTK+ gets more visually pleasing, and I couldn’t be happier. Linux Mint Helena looks great on my x86 machine.
Though I am happy with the clone; I would have want it to be done using Qt.
Just a personal feeling!
Whatever happened to Qyoto (C# and .Net bindings for Qt)?
The full C# KDE library, and thusly some C# Qt library, is listed as fully supported and mature by http://www.kde.org
I _think_ it still uses Qyoto. I think C# just hasn’t made the same splash on KDE/Qt as it has on Gnome.
That is because QT/KDE developers already have C++ on their disposal.
GNOME developers were always against C++, wanting to do OOP in C, which although possible, makes you do by hand lots of stuff which other languages do automatically.
Their love for C# happened just after some of their programmers have discovered some of the productivity gains to use an higher level language.
True.
Some other additional issues could be:
* The main development environment involves downloading a fair number of GTK/Gnome libraries.
* No Qt Creator for C# (afaik), and programming interfaces by hand is just dull.
* Lack of press.
I would think that C++ would be the dominating factor though. The difference between C# and C++ just doesn’t seem as sharp as the difference in C# and C.
(PS – I like Qyoto and KDE#)
Why would anyone use C# for Qt, when there are perfectly good Qt bindings for Python, C, C++, Ruby and Java?
If you have Qt libraries installed, why would you bother also with Mono?
It isn’t as though KDE needs anything like a Paint.NET clone, when it already has the more functional and far more mature Krita program.
KDE doesn’t need Banshee … it has Amarok.
KDE doesn’t need FSpot … it has digikam.
KDE deosn’t need a Paint.NET clone … it has Krita.
KDE deosn’t need GNOME Do … it has krunner.
In each case above, with the possible exception of the last, the native KDE application is better and more functional than the GNOME/Mono try-hard equivalent.
Hence, KDE doesn’t need C# and Mono at all, there is no point.
C# is a quite nice language to work with. Like Java, it supports what most seem to use in C++ and gets rid of allot of the convolutedness, and Java isn’t listed as having a mature KDE binding (neither is C).
What’s the point of the whole Banshee/Amarok, Do/Krunner, etc comparison. You wouldn’t be using those apps anyways because they are clearly meant for Gnome. I mean, by that logic why support Python bindings for KDE since Exaile isn’t as good as Amarok, Deluge isn’t as good as Ktorrent, Emesene is comparable to Kmess, etc.
The whole reason why GNOME users say they shun KDE applications is because of the need to install Qt libraries.
However, GNOME users would have to install Qt libraries these days in order to run some desirable desktop applications such as VLC or SMPlayer, and there are still no GTK+ applications (or GTK# applications) as good as Amarok or K3b.
Anyway … if the point is that if GNOME users are loath to install Qt libraries and so they miss out on K3b, Amarok, VLC and (relevant to this topic) Krita, then clearly it is equally as reasonable for KDE users to be loath to install the completely un-necessary Mono libraries.
Because C# and other CLR based languages in the Mono environment are interesting to program in?
C# is hardly very similar to Ruby or Python. The are no current C bindings.
Many programmers prefer C# over Java, and they are more different than a lot of people would have you believe.
I personally think C# and the Qt/KDE apis are a nice fit, as to me C# feels like a cleaned up C++. For instance, in Qyoto we map Qt’s Q_PROPERTYs directly onto C# properties, instead of needing the moc pre-processor as in C++.
There is a problem with C# … part of the hooks that C# programs use are Microsoft’s patented, closed technologies.
This makes C# and .NET unsuitable for use on a FOSS platform.
Happily, for KDE/Qt, from a users perspective, there is no need to install support for C# and .NET programs, because there are as yet no compelling applications.
As a programmer, you quite possibly find C# and .NET interesting to program, but you may find that your program will be very short on users amongst those that use a KDE/Qt desktop.
Relating all this back to the topic at hand, which is this: “Introducing Pinta, a Gtk+ Clone of Paint.NET”. You will probably find that KDE users won’t bother with Pinta, because it requires Mono (which isn’t installed with KDE by default), and KDE already has Krita, which is more functional, way more stable and mature, and is better integrated into the KDE desktop.
http://en.wikipedia.org/wiki/Krita
http://www.krita.org/
http://www.krita.org/features
It will be a long, long while before Pinta ever reaches parity (in terms of both functionality and performance) with Krita on a KDE desktop, if indeed it ever does.
Edited 2010-02-11 02:12 UTC
Wouldn’t it be more useful to use Vala? It’s pretty similar to C# so it would be easier for that crowd to adopt it.
I don’t know.. With all of this heat that’s accompanied with Mono you’d think more people would embrace Vala or Genie.
Maybe I’m wrong.
Since Vala is basically a clone of C# (as you state), I don’t think there’s any reason to believe that C# is encumbered in ways that Vala would not be.
The only real difference is that Vala does not use a runtime. If you are going to argue against using a runtime, then you also discount apps written in Python or Java or Ruby or Perl.
Well, I never stated it was a clone. I simply wrote it is pretty similar. Vala does come close to C#, but it does have some differences.
I don’t really know what you’re getting at with the whole runtime thing. Last time I checked, Mono has a lot of risk behind it whereas Python and others aren’t based on .NET technology. Or am I missing something?
EDIT:
I also don’t think it’s the language at fault here. I thought it was all about the framework.
Edited 2010-02-08 19:21 UTC
All programming languages have runtimes. They can be bigger or smaller, simple or complex, but that is all.
No, Vala really has no runtime. It compiles directly to C, no bytecode, interpreters or whatever. It also has no standard library. The result only depends on GLib (they use GObject to implement the object model) and the C library (for obvious reasons).
Vala is very interesting but I wouldn’t use it because it doesn’t look mature enough. The website looks like it’s incomplete, there doesn’t seem to be much tool support, there doesn’t seem to be much of a community around it and documentation is lacking.
Edited 2010-02-09 23:54 UTC
Then I advise you to go back to your compiler design classes, since you seem to have missed quite a few of them.
All languages have runtimes!
Assembly – The microcode used by the processor to perform all steps required by the each instruction
C – The code that usually lives in crt0 and allows main() to be called from the OS, execution of atexit() registed callbacks, sbr() style of memory management from malloc and friends
C++ – Same as C, plus the code to ensure proper initialization of constructors for static objects, object construction/destruction, management of stack unwinding for exceptions
Should I carry on with more examples?
A runtime is more than just people know JVM or CLR for. It is all the required library infrastructure a language needs to exist.
For example, on embedded systems the languages sometimes target directly the hardware, without any OS support. On those cases, the required infrastructure to start the application and interface with the hardware is the runtime.
Again, please remember to attend your compiler classes.
That depends on how you define “runtime”. While strictly speaking libc is a runtime, for all practical purposes it’s already installed everywhere. If you say “requires the libc runtime” then that would just confuse end users.
Is the kernel part of the runtime too? Is the CPU part of the runtime too? How about the BIOS? I could go on and go on.
I am not interested in the strict definition of “runtime”. I am interested in what *end users* would consider a “runtime”. Anything that you have to install externally to get the app running is definitely a runtime to them. Anything that’s already installed, while strictly a runtime, is not considered a runtime by end users because they don’t have to deal with it.
Then by your definition, .Net is not a runtime, because on Windows Vista and Windows 7 it is already installed.
Apparently they reused a lot of code from the original Paint .NET so obviously that wouldn’t have been possible if they had gone with Vala instead.
I know what you mean though, I don’t actually believe that there is much risk with Mono what with the MS community promises and everything, but even I would think twice before using it just because of the amount of hysteria surrounding the whole thing. Choosing Vala would probably be a more politically astute choice in many situations. Oh, and there is always C of course, but only for the real masochists
P.S. This isn’t a dig against Mono, I actually think C# is a decent language, but the stinky FUD cloud IS present and I personally would want to avoid it.
If you let them bully you out of using your preferred language, then the FUDsters win (they’re just like terrorists – their goal is to terrorize you into using what they want instead of what YOU want). If they see that they get what they want, then what’s to stop them from endlessly FUDing something else until we’re left with nothing?
Don’t let the FUDsters rob you of your freedom.
Use the language/framework that YOU want to use. Don’t let them bully you into using something else.
(That goes for ANY language preference – whether it be Java, Python, Ruby, Perl, F#, D, Scheme, whatever).
Don’t let anonymous cowards on the internet bully you.
I don’t think I’m being bullied if I make a decision based on the reality that a significant number of people are anti-Mono for whatever reason. If it could affect the success of a project, it’s worth taking into account. For some projects C#/Mono might still be the best solution even after factoring in the controversy. But other peoples opinions do make a difference, so they have to be taken into account, even if you don’t agree with them. It’s just being practical.
Also, you talk about “FUDsters” like it’s all some sort of singular, concerted effort. I don’t think that’s necessarily the case, I think that a bunch of people just happen to share the same concerns.
Not really. The Vala syntax is based on C#, but it’s not just a straightforward copy, such that C# code will compile unmodified. Nor does Vala provide the .NET APIs (or runtime), so anything using (e.g) .NET collections classes would need to be rewritten to use glib equivalents instead.
Btw, there’s a nice article about Vala in the new GNOME Journal issue:
http://gnomejournal.org/article/80/writing-multimedia-applications-…
Finally! A lightweight painting program that can be used to make simple modifications instead of opening gimp.
And I don’t care if he “copied” paint.NET. Everybody copies everybody in this industry. In fact, the different civilisations copied one another. “Greece copied from Egypt, The Roman empire copied from Greece…”
I don’t get what is so great about these “simplified” image editors that are appearing on GNOME lately. For the kind of changes that you’re suggesting – I am guessing crop, rotate, remove red eyes, adjust brightness, gamma, apply a few filters, etc. – one already can perform them without having to open GIMP: Digikam, Gwenview, F-Spot (I suppose, but it probably does) all have these features built-in.
For anything more complex than that, you probably will want to have something as capable as GIMP or Krita around, complexity and all. I just don’t see what’s there in between that justify these “lightweight” image editors. Kolourpaint would probably fit in that range but apart from the fact that it looks like an “enhanced MS Paint” it doesn’t strike me as a terribly useful image editor (My daughters love it, though!).
The reason that they’re better than GIMP usability wise is because GIMP does a lot more than they currently can and you can bet that the moment that they have to add these features, the complexity level will start to go up.
There is an application on Mac called Seahorse that claims to be exactly a GIMP clone minus the complexity and although a nice application, I just don’t see any compelling reason to use it. And it does not appear to be THAT popular either which kind of adds to my point.
I think that it is great that we have people tackling these needs from different angles in order to come up with things that have better usability or that think of new ways to perform the same tasks. And it is even better that Mono can be used to produce these applications in such short period. But they’re neither here nor there. Not yet.
As for the copying, no arguments there. It is great that some projects can borrow code and ideas from other projects and create something new off it. That’s the whole purpose of Open Source after all! I don’t know why some people get so hung up on it…
Edited 2010-02-08 21:14 UTC
At work I have both photoshop and paint.net installed. However when I need to quickly crop and fix some images I always start paint.net. I just find it quicker and easier for quick and easy work. I can start it, do what I want and save the image in paint.net before photoshop has even started up. Sure there are things I use photoshop for, but I’m sure happy I have the choice.
It still requires the Mono VM to load. Hardly lightweight.
decent Pain.NET-like application
->
decent Paint.NET-like application
congratulations you got the joke
by the way, the developer has posted debian packages on his site. I had to install mono-2.0-runtime and gtk-sharp2 packages first but so far this is a great app!
based on mono anyone ????
For photo’s take Fotoxx, written by Kornelix, it is small, easy to learn and not written in mono.
If you need more use gimp.
I downloaded the .deb package for Ubuntu (you don’t need to use alien), and it works well. It is surprisingly good for a brand new application.
Also, I like the name. It’s simple, and sounds cool, unlike Paint.NET. Also, it means “paints” or “paint” (as a command) in Spanish.
So Pinta occupies a niche. What’s the big deal about that?
I understand the distancing from C#/Mono for those that don’t want to have anything to do with proprietary entanglements (such as the worries with Tomboy and Microsoft threats). But I rather enjoyed Paint.NET when I still used Windows, and I suspect Pinta’s primary appeal will remain with that userbase. Oh, and I’m a Gnome user. KDE just did not grab me. Of course there’s always alternatives; such is the nature of the beast in GNU/Linux, always.