After having a frustrating experience with using Flashdevelop with wine, I ended up installing VirtualBox, with XP inside. This does work well but I see it as a stop gap solution (ie. I need a whole VM with a native Flex SDK and all the patching that windows needs just to run FlashDevelop). Obviously a native application that runs in GTK (or whatever window manager - I think even qt is LGPL now) is going to be far better.

I too am in great support of this effort and would even throw some $$ via paypal if this would go towards the linux port?

I too am greatly anticipating a linux port. MonoDevelop is great and it would be absolutely badass if FlashDevelop were integrated into it via a plugin. This is basically the only thing preventing me from moving 100% into linux.

Guys, I know that the MD was a fork of the SD... I just typed wrong!

I have follow the SD project for a long time... Sorry about the mistakes.

Anything new about that ?

I am using ubuntu and I am not willing to go back to windows for many obvious reasons.. I found out also that flashdevelop has a good support with Haxe, and it is so far the best ide for developing flash applications with Haxe. I could myself pitch in for a donation to help you guys port flashdevelop in linux.

Bump!

I would be happy to donate to get a version running on Linux as well!

FlashDevelop rocks!

Thanks for all the efforts

Someone had some success patching FD to somewhat run on Linux with wine:
http://flashdevelop.org/community/viewt ... f=9&t=7535

It's apparently not really convincing and virtualization is still the best option right now (VirtualBox + Ultimate XP do a great job) - especially as FD4 will come with a native Mac/Linux helper to fix most of the virtualization issues:
http://flashdevelop.org/community/viewt ... f=9&t=7621

I know that many ideas have bounced back and forth regarding a multi-platform version of FlashDevelop. Some have suggested that we get FlashDevelop running as-is, using a compatibility layer like Wine. Others have suggested that FlashDevelop be rewritten for Mono, GTK+ or some other framework, then compiled across platforms. I love FlashDevelop on Windows, and I don't think it should change.

Linux has come a long way since I used to use Mandrake. I'm using a GNOME environment, and have found that many of the applications I enjoy most are GTK-based, with some exceptions like Opera, which uses Qt, I believe. I'm not a big fan of the look/feel of Java-based applications.

I am really enjoying the Mono-compatible version of FDBuild from FD4. It works in Windows, and it is working great in Linux. As has been mentioned previously, incompatibilities in the DockPanel Suite and ScintillaNET are significant hurdles if FlashDevelop were to be 100% cross-platform. I don't think this is necessary.

The UI for MonoDevelop feels reminiscent of FlashDevelop to me. I know that the possibility of writing MonoDevelop addins has been mentioned on this thread. FlashDevelop itself is a collection of plugins, each performing specific tasks within the IDE. If I have time, my approach will be to see if more plugins may be made compatible with Mono, like FDBuild. FlashDevelop can then be the plugin "container" on Windows, and MonoDevelop could be the "container" on Linux or Mac OS. This is probably an over-simplification -- I'm sure there are important differences between the architecture of FlashDevelop and MonoDevelop, but this is what I will be looking into.

If I had to pick a "first step", it probably would be either a "simple" plugin to try porting, or adding support for the FlashDevelop project type. Since FDBuild works fine on Linux, it's only logical to wire up support for creating new project files, or editing the properties using an IDE.

I know I'm not the only one who has thought along the lines of MonoDevelop addins, but I thought I'd mention this while it is on my mind.

Well I have a very basic MonoDevelop AS3 binding but it was written (by someone else) for an older version of MD. I've updated it not too long ago and the basics were working: you can create an AS3 project and MD will support (without coloring) AS3 and MXML.

It was under GIT source control and if someone is interested in contributing I can create a github project and push the source.

I also think FD is fine as a Windows application and MonoDevelop could be planed as a long term evolution.

I tried to create a basic add-in for MonoDevelop last night. I was able to compile, but could not get it to appear in the add-in list, so something probably went wrong. I'd love to try working with what you have -- knowing that an add-in worked at some time is more useful than an add-in which never did.

There are three options in my mind that seem pretty suitable:

1.) Create a language binding for MonoDevelop

On the up side, we will be able to take advantage of other features in the IDE, like tooltips for code completion and various string editing or refactoring tools. It may take time to configure, but it could leverage C# code from FlashDevelop, but would be different from FlashDevelop in important ways. Similar to Visual Studio, files must be explicitly added to the project, and the project file format would be different than FlashDevelop. As a result, it would be less like FlashDevelop on Linux, and more like Flash support added to Visual Studio.

2.) Create plugins for gedit

gedit is a great lightweight editor. It would definitely be possible to add project support, which could function like FlashDevelop to include each file in the directory, wherever the project is placed, and could use the same project files as FlashDevelop. However, plugins for gedit are written in Python or C, so code would not transfer directly the same way. There are also more features that would need to be added, but it would "feel" more like FlashDevelop once the process is done. There also are many syntax files available for gedit, unlike MonoDevelop, which has a very small language selection outside of .NET.

3.) Create something new, using Mono

I think this is obvious, but maybe hasn't been discussed as thoroughly. The third approach is to obviously write something new in C#, or to port the "core" of FlashDevelop (perhaps minus the docking system, or without Scintilla) and to add features over time. This would leverage more of the existing code, and could ensure that project files and other features work in the same way.

Hey!

I just discovered a scintilla-sharp project, and compiled their example:

http://www.eclecticdesignstudio.com/cod ... -Sharp.png

It throws an error when I try to open a file, perhaps because it was written for a different version of Mono, but this looks like a promising start. If I can get it to open and save files and projects successfully, perhaps there would be a way to backfill features and plugins from FlashDevelop?

Creating a new FlashDevelop from scratch is a huge work and isn't likely to be as good as FD4 anytime soon - honestly we aren't really hot about that.

MonoDevelop is vastly different than FD but it's a full-featured IDE where some work from FD could be reasonably adapted.

I thought about gedit & others: I had the idea that FD completion could run as a service (ie. no GUI) using Mono and could be invoked by any code editor able to call it with the appropriate context (ie. the editor code and cursor position) and able to then display the completion information returned by the service. This again would offer a totally different experience and you'd probably lose tons of features.

I see what was happening now.

When you try to open a file or create a new file, that is when it would attempt to initialize Scintilla. It was missing the library for GTK Scintilla, so that is why it failed. Using their sources, I was able to compile by editing gtkscintilla2/scintilla/gtk/makefile and adding -fPIC to CXXFLAGS. However, I was not able to recompile their scintilla-sharp wrapper ... the makefile got stuck and I don't have a lot of experience with makefiles. It also includes a Visual Studio project, for compiling on Windows, I assume, as well as a GTK Scintilla binary for Windows.

Once I added my copy of libgtkscintilla2.so (dll) to /usr/lib, I was able to try their project again. This time it had a segmentation fault, after several successful calls to the library. Unfortunately since I was not able to recompile their wrapper DLL, I wouldn't be able to see the actual calling code and fix the problem unless the makefile were fixed. It probably works fine on Windows.

I wasn't really thinking about a total rewrite ... I was thinking more along the lines of porting FlashDevelop, but piece by piece, and not all at once. Plugin by plugin. It's obviously important to have an editor at the core of it all, so that's why I was seeing if scintilla-sharp would work.

What if FlashDevelop used scintilla-sharp instead of ScintillaNET? If it were possible to compile the Scintilla binary on Windows using Mono, that would probably solve one big "key" to doing a port. I would play with it more on my end, but like I said, the Makefile for non-Windows users is getting stuck, and I'm not currently sure of how to fix it. The problem might be obvious to a Mac or Linux user who normally uses makefiles.

It would be an interesting idea to provide completion as a service ... kind of like the way that the haXe compiler provides completion? I know users who have been able to readily integrate haXe completion into Linux applications because of this compiler support, though I know that FlashDevelop's completion is faster than haXe's ... in FlashDevelop. Not sure if that's a fair comparison

Oh, I forgot to say -- if you still have those add-in files for MonoDevelop, I'd love taking a look at it.

It looks as though MonoDevelop is flexible enough to allow plugins to define how files are loaded and saved. I think that using the same project file format is very important for compatibility. It also appears there is a "GetItemFiles" method which can be extended, so maybe it would be possible to use FlashDevelop projects, and to automatically include the contents of its directory?