I have been thinking about and writing down a prototype design for Emerald Editor. I'm not nearly done yet, but in the first chapter I discuss the programming language and GUI library used for EE. This was decided before I ever came to this site. Now, since we are redesigning EE from the ground up and starting over, we have the opportunity to rethink the decision.

Programming Language and GUI Library

Option 1: C++ and wxWidgets

Pros

This was the original plan and thus probably has the most support.

wxWidgets is more portable than the other options.

Cons

There is a movement within wxWidgets to modernize and redesign the API. This is not a bad thing; however, the risk is that as soon as Emerald Editor is implemented with it, wxWidgets 3 might come out, and the brand new Emerald Editor will be using outdated APIs.

Option 2: C++ and GTK+

Pros

GTK+ seems to be a nicer API than wxWidgets.

Cons

I don't know if GTK+ is supported on many platforms besides Windows and Linux.

I don't think GTK+ uses native Windows APIs for controls so it may not necessarily have the native look and feel on all platforms.

Option 3: C# and Windows Forms

Pros

C# is a cleaner language than C++ and allows for more elegant code and fewer bugs than C++.

C# seems to be becoming increasingly more common in the industry.

Cons

Running Emerald Editor in a virtual machine would likely slow things down a bit.

Windows forms has limited support on platforms other than Windows, but the support is growing as Mono advances in their implementation.

I personally am inclined to prefer option 3 with C#, but this is a weak preference. I think any of these options are descent, what do you all think?

Mostly I'm not a fan of Option 3 because I don't know C# but from what I understand it's not easily supported by other platforms. I am however willing to pick up a new language if I am incorrect, especially since I know C/C++ and have been exposed to Java.

Option 2 I like partly because the only other open source project I've gotten into devel-ish stages with is based on GTK+. I can't comment on con1, but with regards to con2, I'm not sure it uses native Windows APIs but it is infinitely themeable, and one of the built in themes, WIMP, integrates very well into XP (haven't used it with any other Windows).

For the con to option 1, would you expect the move to wxWidgets (which I also don't know, but am willing to learn) to be a time consuming process? I can't imagine they would make it that difficult. Also, if it's coming out anytime soon, the new API might come out before we get very far into EE in the first place, which would make things relatively easy to convert anyway.

As for wxWidgets 3, I think they actually do want to totally redesign the API, and it does not seem to be happening quickly. So my guess is that a considerable different API will be out in the future. I am sure they will have a layer of compatibility for a while so you can transition to the new API though.

Option 3 is using MS technology and will not be as portable as the 1st 2 options, while mono is coming along and will help with this due to its very nature it will be behind the MS version of C# so while the windows version will be updated easily we will have problems with other platforms. To compound this what happens if there is a code structure/method/function that we use and mono can't duplicate that functionality due to patents/copyright etc. Further issues arise if some of us (or the core devs) use MS VS 2k5 pro and others want to use the express edition as we are seeing at the moment with CE, some libraries are available to 1 and not the other. While I have uploaded the libraries for this, I would nt be overly comfortable doing it again as technically if i was caught and it is illegal then I could lose my job etc.

I would favour the GTK library simply as it is more common than wxwidgets and if the wxwidgets is going to get a revamp then as stated we may be in a bit of a pickle and would have to spend (probably) a whole release cycle to get it ported to the new API, because it would be undesirable to have mixed APIs in case of contamination/deprecated code being left.

One of the main goals of EE is to be a fast performer, particularly during startup. How fast?? On Windows it should be a suitable replacement for Notepad. At the moment, CE accomplishes that no problem.

My understanding with GTK+ is that while it is an excellent, fully-featured API, its somewhat sluggish. I'm just repeating gossip though, without any real knowledge.

I can't comment on GTK and I've never heard of QT4. As long as it's cross-platform, I have no complaints. I'm very open to learning a new API. Comment on CE being quick, though--and this is mostly with regards to the 3.72 beta: It seems to take longer, especially if I need to manually tell Windows to pick CE instead of Notepad (as in I needed to check the "Always use this program" box in the open with dialog). This might have something to do with CE's associations breaking with the 3.72 I have, but even with 3.70, I started experiencing a slow-down eventually that Notepad didn't give me. It wasn't unbearable (about a second or two slower than Notepad, *maybe*), so I didn't mind, but the same can't be said about the 3.72 delay.

QT4 would not be a problem as long as we stay with the GPL, which I don't recommend. I believe QT has four licensing modes: commercial, GPL, academic, and educational. So if your project has nothing to do with education and you don't want to shell out big bucks, you have to use the GPL in your project.

Option 3 is using MS technology and will not be as portable as the 1st 2 options, while mono is coming along and will help with this due to its very nature it will be behind the MS version of C# so while the windows version will be updated easily we will have problems with other platforms. To compound this what happens if there is a code structure/method/function that we use and mono can't duplicate that functionality due to patents/copyright etc. Further issues arise if some of us (or the core devs) use MS VS 2k5 pro and others want to use the express edition as we are seeing at the moment with CE, some libraries are available to 1 and not the other. While I have uploaded the libraries for this, I would nt be overly comfortable doing it again as technically if i was caught and it is illegal then I could lose my job etc.

This is possible, but as long as we test EE to constantly make sure it works in Mono, I doubt this would be a big problem.

QT4 would not be a problem as long as we stay with the GPL, which I don't recommend. I believe QT has four licensing modes: commercial, GPL, academic, and educational. So if your project has nothing to do with education and you don't want to shell out big bucks, you have to use the GPL in your project.

Phil

I thought we were most likely using GPL? I personally think it's the best choice of license for open source projects in general.

QT4 would not be a problem as long as we stay with the GPL, which I don't recommend. I believe QT has four licensing modes: commercial, GPL, academic, and educational. So if your project has nothing to do with education and you don't want to shell out big bucks, you have to use the GPL in your project.

Phil

I thought we were most likely using GPL? I personally think it's the best choice of license for open source projects in general.

See my recent discussion on the topic in the licensing thread pinned to this forum.

Well, although the original EE base was GPL, I have no problem in us choosing another license for a new build of code.

I originally proposed wxWidgets solely because you get the native look (you don't with GTK+ or Qt), and it is more portable than either GTK+ or Qt. It also has a nice wrapper for Scintilla, the original editing component of choice. That said, if we want to, we could write our own to suit.

GTK# (Mono GTK) is viable if we choose Mono, but I'm still not sure about whether Mono is the route to take, I've seen a number of applications dislike Mono intensely, especially on Linux.

I support C/C++ options. I would prefer rather GTK+ than wxWidget, exactly because it DOESN'T have native look and feel. It has the same look and feel on every platform.This is, in example, the reason why Firefox (GTK+) looks cool on anything just the same. Also, GTK are themeable, and finally, they are easier to program.

And if someone thinks GTK+ are sluggish, I reply that Internet Explorer has still to come close Firefox, both in speed and stability... And GIMP (on windows) is the not the only serious competitor for Adobe Photoshop for nothing.

On unices (linux, BSD, SUN, name it), wxWidget IS rendered with GTK+; just, its integration with GTK+ is somewhat... questionable. I would also argue that, while windows as a wider userbase, the userbase for a code-writing oriented text editor on the unices is, if not greater, at least quite interesting.

About QT4, I have recently had them in my hands (wengophone project), and... you... can't... set... the DAMNED FONT. Well, you can, but it's a hell, and it is not easily run-time configurable. QT4, on unices, still relies on X font rendering, while GTK has its own font rendering subsystem. KDE looks cool exactly because KDE libs rewrite the font system; so kde apps have a different font rendering engine than the other QT4 applications.

Oh, and one note (about C#): no one, really, is going to even run an editor based on a virtual machine. Eclipse works decently as an IDE, only for java, but it has nothing extraordinary as an editor. And I have no other example of VM based editors in mind. With all the other excellent editors out there, I would run away things as C# at full speed.

I support C/C++ options. I would prefer rather GTK+ than wxWidget, exactly because it DOESN'T have native look and feel. It has the same look and feel on every platform.This is, in example, the reason why Firefox (GTK+) looks cool on anything just the same.

True, but you'll note that Firefox has recently reported that version 3.0 is going to have the Mac look and feel on Macs because they were getting so many complaints about it.