|
PortingStrategy
Paint.NET Porting Strategy
BasicsPaint.NET has a very clean isolation between the engine and the system specific components. The ideal scenario is to ship a SystemLayer.dll file that will replace the one that comes with the official distribution of Paint.NET. Although I had originally hoped that the code could continue to support Mono and .NET on the same codebase, Rick suggested that I avoid this and go directly the route of replacing the library. Ideally the port would only require the src/SystemLayer directory to be ported but currently Paint.NET still contains a few places in the core engine that must be modified (for example, at startup the program checks the list of libraries and resources to be in the target directory, but some of these assemblies are not necessary for Linux or are useless on Linux) this has required some changes in the core of Paint.NET. In places that must be revisited in the future (unfinished implementation, stubs, routines turned into no-ops) I have added a WriteLine statement so we can keep track of what is missing. A complete port should produce no output on the console. DirectionsThe port is good enough to start the application, but many features are still not tested and there are many P/Invokes that remain in the source code. I have not really spent much time trying to test it, but testing will exhibit many features that must be ported to Linux. What needs to be done:
Repeat until we are done, and the application is working like a charm. Current StatePaint.NET starts up, it is possible to load and save files, and run many of the effects. There are still a few bugs left and the SystemLayer work has not been completed, so a few things might break every once in a while. It is recommended that you start with Mono 1.2.6, although a few features (saving) requires Mono from SVN as there were a few bugs that prevented it from running correctly. P/InvokeThere are a number of cases where Paint.NET is using P/Invoke, in some cases it is using functionality from the Windows OS that is available in Unix in a different form. Porting this code should be pretty straight forward. In some other cases the P/Invokes are used to call into features in the various Windows.Forms controls that is not exposed in the Windows.Forms API but is part of the underlying Win32 control. In these cases, sometimes the functionality is also part of the internals of Mono's Managed Windows.Forms implementation. In those cases you can access the internal features by using Reflection and Invoke, for example, consider this code that replaces the call to P/Invoke with an internal call MethodInfo drop_down = typeof (ComboBox).GetMethod ("DropDownListBox",
BindingFlags.Instance|BindingFlags.NonPublic);
if (drop_down == null){
Console.WriteLine ("ShowComboBox: Warning, no DropDownlistBox found");
return;
}
drop_down.Invoke (comboBox, new object [0]);This was just an illustration, a better way is to just call the method that takes care of this on the comboBox: comboBox.Dropped = value; Building Paint.NET on LinuxFirst, you should check the code out from SVN, once you have the source code, the easiest way of testing it is to use the standard Unix source configuration and installation setup: cd src ./configure make make install Alternatively, you can use MonoDevelop to build Paint.NET. To use it, just open the src/paintdotnet.sln solution and rebuild the solution (press F5) to run. Original SourceTo track the changes and assist us in writing a 'Lessons in Porting' document, the original source code as obtained from http://www.getpaint.net is checked into this directory: http://paint-mono.googlecode.com/svn/vendor/pdn_src_3_0 This is the vendor/pdn_src_3_0 branch. ContributingIf you want to contribute to this effort, please mail me your login information, and I will add you to this project. Alternatively, you can contact other members of the administration group. |
Sign in to add a comment
Paint Mono should use GTK to integrate well and stop self-drawn-widgets expansion.
I know, but the entire UI would have to be rewritten and changed, then it would be paint.net to the end user would it?
Hey.
This does not build on Ubuntu, (Just using ./configure; make; make install) apparently because the command for gmcs is not gmcs rather gmcs2. I went through all the makefiles manually and changed all the references to gmcs2 manually, did alias gmcs="gmcs2", nothing worked. Would be appreciated if you would fix it. Thanks for doing this project.
There is a PPA repository for Ubuntu jaunty here: https://launchpad.net/~xmlich02/+archive/ppa However it does rely on one older package from the hardy repository: http://packages.ubuntu.com/hardy/libmono-mozilla0.1-cil
What is the likelihood that Paint.mono will continue to be developed into the future considering that the Paint.net project has now closed its source code?
Depending on the license applied to the source code, we could potentially maintain paint-mono as a separate fork and develop this independently. This could be ideal, as Paint.NET v4 is supposed to be a total rewrite.
I reworked this a bit on my own PC by combining everything into a single visual studio project ( instead of multiple ) It kind of runs on Mono/Suse but not too well. I want to strip out unnecessary code ( eg auto updates, installer, etc ) and sort of get it down to a bare bones single exe that can run on linux/mono without too much effort (defaulting some registry values needed too) I find the current build a difficult to make. I find it will run on mono even if built on windows, but the posix stuff does not work on mono for windows. I think microsoft has a better optimizer and will get better performance if compiled in visual studio. I can share my hacked together project if any one wants, just email! Thanks
Any news? Project updated Dec 20, 2007 by miguel.de.icaza((((((