Emerald Editor Discussion
June 26, 2017, 09:40:12 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: Moving on from here  (Read 9495 times)
0 Members and 1 Guest are viewing this topic.
Zhrakkan
Official Mascot!
Beta Testers
Gem Cutter
***
Posts: 177



WWW
« on: May 28, 2006, 02:48:17 am »

I think we need to have a discussion of how to proceed.
We have to have a path forward now.

We need a base install of the tools we are basing off of, and how to proceed from here.

Arantor, have you been designated as the Project Manager, and you make the overall decisions on how to proceed?
Logged

News Manager and Unofficial Mascot
Join the Emerald Editor Project - Message Me!
Emerald Editor - "A Jewel of an Editor"
-----by the way, that name is pronounced "Za-Rack-In"
daemon
Developers
Gem Cutter
***
Posts: 107


WWW
« Reply #1 on: May 28, 2006, 06:13:32 am »

Well, we have a roadmap. I would like to see the coding standards and license finalized and then major work can begin.

That being said, however, I'm already working on cleaning up the wxStEdit base in my working copy and writing the API documentation. I'm documenting the entire base so that I'm familiar with all the internals and to get familiar with wxWidgets.

As for the tools we're basing it off of: an open source, cross-platform version of CE is our goal for 1.0, perhaps mixing in some features from BBEdit on the mac.
« Last Edit: May 28, 2006, 06:50:28 am by daemon » Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #2 on: May 28, 2006, 10:16:17 am »

Wise words...

Zhrakkan, I'm only unofficially the project manager because I was one of the first (the first?) person to suggest a new version of CE, being EE, on the CE forums, and because I set up the website I kind of became the project manager by default.

That said, I do seem to have acquired final say on things, although even if I was officially the project manager (as opposed to the administrator of the site) I would try not to use executive power too much. Whenever I've made a semi-official decision, I've tried to keep the best balance of everything that has been said before and only tend to make a decision once the discussion appears to have stalled.

We do have a kind of base install - the one alpha started with, and the one that is currently in SVN.

The roadmap is still up for discussion and debate if anyone wants to discuss it.

I agree though, EE 1.0 is basically CE 3.70 but open-source and cross-platform. We can tweak and add features as we go - such as the enhanced search/replace - and how we do it is up to us, such as having plugins etc.

I think we need to formalise the roadmap next and get that set, along with license, and whether we implement a core containing most features, and then a plugin system, or a core containing only the most core features - and plugins for everything else.

Once that's set, we can move forwards, I think.
Logged

"Cleverly disguised as a responsible adult!"
daemon
Developers
Gem Cutter
***
Posts: 107


WWW
« Reply #3 on: May 28, 2006, 04:22:26 pm »

I think that this is a fairly good roadmap: http://forum.emeraldeditor.com/index.php?topic=18.0

Just combine .1 and .2 and the only chores under it are refactoring, ripping out useless features (namely "Bookmarks"), cleaning up the code, reworking the UI. And as I cleanup the code, I can work on a to-do list to see what changes need to be done to incorporate the rest.

And I think that the majority of the features in 1.0 should be core-based, but maybe things like FTP and scientific calculator should come as bundled plugins.
Logged
Derek Parnell
Lead Architect
Miner
**
Posts: 36



« Reply #4 on: May 28, 2006, 11:05:52 pm »

I'm very concerned that the architecture is not being defined or specified. It seems that people are already to write code before knowing how the whole application is going to hang together, etc... That is a certain death sentence for any application.

If we have learned anything from the years of writing software its that successful software knows what it is. I've seen no real discussion of yet about the internal architecture.
Logged

--
Derek Parnell
"Down with Mediocrity!"
daemon
Developers
Gem Cutter
***
Posts: 107


WWW
« Reply #5 on: May 29, 2006, 06:31:54 am »

But it has:

- We're using wxStEdit as a base, which I'm documenting, cleaning, and reducing to a core (http://forum.emeraldeditor.com/index.php?topic=46.0 & http://forum.emeraldeditor.com/index.php?topic=91.0)
- The GUI is going to be independently written separately so it can stand on its own (http://forum.emeraldeditor.com/index.php?topic=22.0)
- There's a roadmap for when to implement the features (http://forum.emeraldeditor.com/index.php?topic=18.0)
- A target feature list (http://forum.emeraldeditor.com/index.php?topic=4.0)
- It's going to be (well... already is) cross-platform, which means OS-specific calls are out
- The core code should be fairly compact with a plugins system to grow
- Syntax highlighting is going to be independent files in XML format (http://forum.emeraldeditor.com/index.php?topic=62.0)

There's still a few things left to determine, but I think we're definitely on the right track. Also, when I finish cleaning up the core and documenting, the internals will become a lot clearer.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #6 on: May 29, 2006, 11:00:07 am »

True, we have a valid base, which compiles and can be reduced to a very minimalist core. Rewriting the backend for Scintilla could prove interesting (to support extensible syntaxes), though.

The one issue that this can bring is that the internal code core that we will have will already have a number of features - all the basic editing features, syntax highlighting core etc. - and then plugins can be added as necessary.
Logged

"Cleverly disguised as a responsible adult!"
Zhrakkan
Official Mascot!
Beta Testers
Gem Cutter
***
Posts: 177



WWW
« Reply #7 on: May 30, 2006, 02:36:14 pm »

I'm very concerned that the architecture is not being defined or specified. It seems that people are already to write code before knowing how the whole application is going to hang together, etc... That is a certain death sentence for any application.

If we have learned anything from the years of writing software its that successful software knows what it is. I've seen no real discussion of yet about the internal architecture.

I agree...I am not a programmer so this is a little out of my arena...but I think we need to make sure we have decisions made on what to to before we start hacking code...
Logged

News Manager and Unofficial Mascot
Join the Emerald Editor Project - Message Me!
Emerald Editor - "A Jewel of an Editor"
-----by the way, that name is pronounced "Za-Rack-In"
Zhrakkan
Official Mascot!
Beta Testers
Gem Cutter
***
Posts: 177



WWW
« Reply #8 on: June 08, 2006, 10:07:55 pm »

Arantor,

Now that you are the Project Manager.
Where are we headed now.

What issues are number 1 on the plate.?
Logged

News Manager and Unofficial Mascot
Join the Emerald Editor Project - Message Me!
Emerald Editor - "A Jewel of an Editor"
-----by the way, that name is pronounced "Za-Rack-In"
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #9 on: June 08, 2006, 10:39:30 pm »

Very good question.

I know daemon is still playing around cleaning up the core from StEdit at the moment, so once he's done that we can look at it. (I'm not enough of a C++ coder to make any comments right now)

Looking at what we have, it seems that wxStEdit gives us somewhere between Milestone 0.1 and Milestone 0.4! (Based on my original roadmap, which might need reworking)

I don't want to move backwards to move forwards, as it were, and if some of the features are already present in our core, I'd like to try and keep them.

In general, though, I think a few more concrete decisions need to be taken, before we can start moving forwards really well. There are some loose ends that really need tidying up, like the following:

  • Auto completion vs. code completion vs. just syntax highlighting:
     
    • CE does syntax highlighting only.
    • Autocomplete (just to finish a known word, maybe on a hotkey trigger, a bit like OpenOffice offers) is trivially easy to add in if you already have the syntax available.
    • Code completion (based on IDE-style) - very contentious issue. Some people (Matthew1344 for example) would like to see EE as a fully fledged generic IDE, but I believe this is against the project goals for EE.
    • I believe therefore that syntax highlighting is critical to the project, autocompletion not quite so critical, but enough to be considered core code rather than a plugin.
  • Syntax format:
     
    • XML has several things going for it; there are several tools out there which can edit XML if given a schema. It is a standard format. It also can be extended in a logical, nested manner should it be required, and we already have an example XML format in our SVN.
    • There is also an XML parsing module included with wxWidgets, so that seems fairly easy to bolt on for the purposes of processing.
    • However, an XML schema will be much larger (trivial examples suggested a three-fold increase over a comparative custom format.
    • XML does have a natural structure for what we want; there are examples where ranges are defined by different start and end blocks (e.g. in bash scripts, they are defined by a keyword for the start, and the reverse of the keyword for the end, such as case ... esac)
    • I think XML is the route to take, although the schema I have proposed is not necessarily the best for the job. It is in SVN for anyone who's curious.
  • Plugin system:
     
    • This is also a fairly contentious issue, and one I am not really experienced enough as a C++ programmer to comment on. We have three proposals, Lua, AngelScript, Tcl, or even C++ and Java. The majority seems to be suggesting Lua.
    • From my own personal perspective, Java and C++ should probably be out. I do not believe the speed increase, or size decrease, of compiled code will benefit many users if the script parser is written properly; I also want to avoid platform specific issues (even Java has that, a well-known online gaming site which is based on Java completely fails to work using the Sun JRE but surprisingly successfully with the older Microsoft JVM)
    • I still think it should be totally embeddable: although there has been talk of "acceptable" dependencies, the average Windows user is not going to be able to source and/or install such things, and that goes for the programmers too. (Particularly if you have to start messing with regsvr32) If any of the proposed solutions can't be totally embedded without leaving dependencies (building libraries may be OK under some circumstances) then it may not be appropriate for us. Tcl with Swig does sound feasible, though.

I want to make these decisions, then amend the roadmap based on what we have.

The GUI does also need cleaning up, it looks too messy at the moment (CE seems so uncluttered by comparison) but the above is a much larger issue to resolve. Once the above have been decided - I'm looking for comments from the forum first before I make any concrete decisions; the above are huge issues that will affect EE for its future life, so I want to get it right - I'll amend the roadmap and take it from there.

In summary, I think:
  • Syntax highlighting, with optional autocomplete only (no IDE-style context-sensitive stuff, simply based on available keywords)
  • Syntax format: based on XML, although probably leaner than the one I put in the SVN.
  • Plugin format: I'm happy to go along with pretty much anything, provided that it is embeddable (and thus portable), provided that no dependencies are left behind, except possibly libraries that can be moved easily (no Registry use here)

Anyone have any major disagreements when looking towards EE 1.0? We can look at some of these features later, but for now... And if no-one has any burning disagreements, we'll move forward in this direction.
Logged

"Cleverly disguised as a responsible adult!"
Matthew1344
Gem Cutter
****
Posts: 103


« Reply #10 on: June 09, 2006, 05:11:32 pm »

As I said, I do love code completion.  HOWEVER, it has been made more obvious to me that there are possibly unsolvable problems with trying to build a non-language-specific IDE.

For selfish me, this issue becomes directly tied to the Plug-In feature.  If there is even *potential* that a plugin could be written for code completion, then I am satisfied with that.  Let's exclude code completion from the "core features" and move on.

Regarding autocompletion, if everybody agrees that it should be part of the core, then that's fine... as long as it can be turned off if anyone is annoyed by it.
Logged
Feldon
Gem Cutter
****
Posts: 106


« Reply #11 on: June 10, 2006, 12:41:23 am »

Autocomplete is fine, just add it to user preferences.

I think XML is the right way to go for syntax files.

I've heard lots of good things about Lua.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #12 on: June 12, 2006, 10:00:08 pm »

I'm pretty certain now how the autocomplete can be slotted in alongside the current syntax highlighting (at least in theory Smiley)

I'm going to work on the XML syntax now and see if I can't come up with a streamlined version of my original that's more suitable. I'll post in the Syntax forums when I'm done and we can have a look then.

Lua does look good, but I'm not really enough of a coder to comment. I do note that a lot of large projects have used it, so perhaps it is the right way to go. Then again, Tcl with SWIG may also be applicable, although I'm still trying to figure out if SWIG then becomes a project dependence, not so much from a runtime point of view but from the build-time. The developers will of course be able to build it, since SWIG will be available to them, but I'd rather not restrict it and make it a build dependence for *nix.
Logged

"Cleverly disguised as a responsible adult!"
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.232 seconds with 18 queries.