Emerald Editor Discussion
March 28, 2017, 04:56:56 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: EE Project Lead  (Read 11822 times)
0 Members and 1 Guest are viewing this topic.
Pvt_Ryan
Master Jeweller
******
Posts: 422



WWW
« on: May 16, 2008, 11:13:20 am »

As EE has become pretty much vapourware and I would like to see it take off.

I am putting myself forward to take over as project lead.

I will happily point out I have never managed a project (that included other people) before and so will be learning as I go along.

Please let me know your thoughts.
Logged
rageboy
Jeweller
*****
Posts: 305

Ankit Singla


« Reply #1 on: May 16, 2008, 03:31:42 pm »

Sounds good to me. Do we know yet what we're using for a base?
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #2 on: May 16, 2008, 04:10:08 pm »

The original plan was to use wxStEdit (Scintilla wrapper in wxWidgets) and even that's what's in the SVN tree, however after a couple of builds at my original insistence of it being portable and thus have no unusual external dependencies, we were getting 3MB executables that didn't do as much as CE does currently.

Scintilla is still a viable component IMHO, however I don't believe wxWidgets is the way forward. If only there were some kind of platform neutral toolkit that didn't bring massive dependencies with it (which would rule out both GTK and wxWidgets unless small static-linked binaries are possible)

However, I think that we do need to find some direction now; CE is all but dead other than what is going on here, and I would very much like EE to start coming into life.
Logged

"Cleverly disguised as a responsible adult!"
rageboy
Jeweller
*****
Posts: 305

Ankit Singla


« Reply #3 on: May 16, 2008, 05:52:06 pm »

What are things like gVim and xEmacs written in? How are those cross-platform? 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.
Logged
pn8830
Global Moderator
Jeweller
*****
Posts: 252



« Reply #4 on: May 16, 2008, 07:01:56 pm »

Guys,
Whatever works for you I'll support. It's better to have some movement then no movement.
PN.
Logged

Entities should not be multiplied beyond necessity
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #5 on: May 16, 2008, 07:58:44 pm »

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.

.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.

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:
  • Small size
  • No external dependencies (everything can be statically compiled without making a lots-of-MB executable)
  • As little OS-dependent code as possible
  • Extensible through plugins (either through exposed-via-C APIs, or some other language perhaps that can be parsed internally)
Logged

"Cleverly disguised as a responsible adult!"
rageboy
Jeweller
*****
Posts: 305

Ankit Singla


« Reply #6 on: May 16, 2008, 08:15:47 pm »

Thanks, Pete.

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?

Quote

.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.

Quote

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:
  • Small size

I think this and the next point are solved by OS-specific GUIs

Quote
  • 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.

Quote
  • Extensible through plugins (either through exposed-via-C APIs, or some other language perhaps that can be parsed internally)
« Last Edit: May 16, 2008, 08:17:57 pm by rageboy » Logged
Pvt_Ryan
Master Jeweller
******
Posts: 422



WWW
« Reply #7 on: May 22, 2008, 04:01:39 pm »

Ok here's what i am envisaging..

EE Should be modular as mentioned in other threads (not unlike eclipse)

The way I see EE being developed is we have a backend library that handles fileio and memory etc, this backend will be accessed via a frontend gui via an api.

For example:

User clicks shortcut
program starts
In GUI user selects open xxx.txt
GUI makes an api call to the interface "open" passing the filename.
backend reads file into memory and then passes the file contents (by reference to the memory location) back to GUI

The idea is that the library should be completly independant from the gui so that anyone could rewrite the gui from scratch just by calling the backend library.

The library should of course be staticly linked.



Logged
rageboy
Jeweller
*****
Posts: 305

Ankit Singla


« Reply #8 on: May 22, 2008, 04:08:04 pm »

I agree.  But I know very little about programming GUIs. I'm wondering what effect this will have on the size of our binary and the time to open/exit the program.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #9 on: May 22, 2008, 09:52:04 pm »

I agree; I see it as something similar.

Having thought about it over the last few hours, my personal feeling on it is as follows - I may be elaborating on what you're thinking, or I may be off in a slightly different direction, but see what you think.

At the bottom you'd have the EE core, which would handle file I/O, memory and manage plugins.

At the top, you'd have the GUI. As you've said, the GUI would issue API calls to the core, which would then go do stuff. The GUI could also make API calls to plugins through some defined interface.

The main problem is that I don't see how the GUI can be completely detached from the backend; so much of EE revolves around the editing widget (if nothing else, stuff like syntax highlighting and code folding, some of which should live in the core anyway where you have the syntax file parsing system)

The other problem you will quickly run into is if plugins require user interfaces (aka chrome), since you need to keep some APIs available for handling preferences in the core, as well as some GUI stuff.

Then again depending on how the GUI API structure is spec'ed out it might make some kind of sense.

Sorry, I'm just rambling, but it is a big thing in my mind.
Logged

"Cleverly disguised as a responsible adult!"
Pvt_Ryan
Master Jeweller
******
Posts: 422



WWW
« Reply #10 on: May 23, 2008, 09:53:53 am »

I see what you are saying, I think the solution is 2 APIs

1 for the core
1 for the GUI

this way any call to the GUI API by a plugin should override the default.

the order of loading should be

core
core-plugins
GUI
GUI-plugins

with the "settings" for the one lower down overriding those above it.
Logged
Pvt_Ryan
Master Jeweller
******
Posts: 422



WWW
« Reply #11 on: June 23, 2008, 10:32:23 am »

Additionally this would allow us to make the front end completely OS independent and only change the backend library between OSs
Logged
rageboy
Jeweller
*****
Posts: 305

Ankit Singla


« Reply #12 on: April 25, 2009, 09:23:11 am »

Quick question that I feel like was addressed at some point but I don't see it here:

If we do separate this into core, gui, and plugins (say for instance like Pidgin), would it hamper our load time? I don't want to have to put a bunch of crap in memory just for a text editor, because as fully functioned as we want this to be, it's still going to be a text editor at heart.

And as featureful as things like vim and emacs are (even the graphical versions of these), they load nearly instantly. If EE does ever get off the ground, I would definitely want open/close time to be minimal.
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.13 seconds with 18 queries.