What are things like gVim and xEmacs written in? How are those cross-platform?
gVim is written in C; at least as far as I can tell the project has the guts of Vim as its base, with separate GUI frontends squished onto it.
xEmacs uses Cygwin as a compile environment, which suggests that it uses some of the Cygwin libraries; this would make portability a lot more complicated (gVim at least can be made portable, but it would be difficult from what I understand to truly make Cygwin-dependent apps portable)
I guess we could have three separate projects, where we have a backend that's the same across platforms and a casing that's platform-specific. Or we could use something like .NET/Mono, neither of which I've ever worked with.
In answer to the first point, it would be doable but my personal preference (and I suspect other peoples') would be to keep the code between the versions as close as possible, so as to do as little porting as possible. To completely rebuild a GUI application between platforms is no mean feat, unless you have some kind of portable abstraction layer.
And this, my friend, is why we're open source. I agree that it wouldn't be easy, but from a user standpoint it would probably be the most preferred solution. What do you mean by portable abstraction layer exactly? If you mean a GUI toolkit, then you're not really rebuilding the GUI at all. If you mean a way for the GUI layer to hook into the backend, this is exactly what I'm proposing. As long as that layer doesn't change between releases (adding features is okay...changing existing parts of the API is generally bad), then it should be fine, right?
.NET/Mono brings with it again a whole issue of dependencies; Win users will require one version of the .NET framework (there are AFAIK 4 main streams, 1.0, 2.0, 3.0 and 3.5 but there are probably others too)
Last time I downloaded .NET for my XP machine it was a 22MB download, so to me I think .NET/Mono is not really the answer for an application which has a community-led requirement for portability, not to mention small size.
The thing about this is, most Windows users will have one of the .NET frameworks already because it's needed for other apps. I'm not saying this is the way to go, or that it should even be considered because non-Windows users will have to download the entire package, but we need to find some type of framework, and other than GTK and Scintilla, it's all I know that is multi-flavor.
It would seem that we can use the Scintilla component as discussed before, although I'm the first to admit that I'm not a C/C++ programmer, so I'm not sure how well it would work for us, but from what I do understand of it, it should be possible to use that as a base component, add the plugin system previously mentioned, and keep as little GUI code as necessary to be OS dependent, and abstractify the code in such a way that porting is really a formality, rather than a burden.
I realise that right now what I'm saying is a long way off, but I would suggest that whatever route is chosen, it needs to fulfil the wider community's requirements, which for development purposes sets minimum criteria of:
I think this and the next point are solved by OS-specific GUIs
- No external dependencies (everything can be statically compiled without making a lots-of-MB executable)
- As little OS-dependent code as possible
I'm not completely sure why this is a requirement. The point of being open source is that we'll have devs that are experienced in different OSes so we can have them all work on the backend (if they want) and work on the OS specific stuff for the OS they're most familiar with if they are doing UI.
What may work is something like we start with a UI that's not OS specific and then when we get bigger split off to OS specific GUIs. This will involve planning the project to keep the backend and GUI as separate as possible, anyway, which is why I brought it up, but I'm not completely sure we want to do that for something as "simple" as a text editor. I'm not sure if it will make the program any bigger, but it would make development...or division of work, anyway...easier.
- Extensible through plugins (either through exposed-via-C APIs, or some other language perhaps that can be parsed internally)