Emerald Editor Discussion
April 23, 2017, 08:54:02 am *
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] 2
  Print  
Author Topic: Development environment  (Read 12187 times)
0 Members and 1 Guest are viewing this topic.
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« on: April 26, 2006, 01:13:21 am »

Hmm. Before we can possibly begin, there are two major things which need to be thrashed out: development environment/language and UI toolkit.

First, development environment.

Suggestions:
* Java
* Mono
* Python
* Perl
* C/C++

Having looked through the comments, and having had a look through the documentation and forums about the above, I've come to the following conclusion:
* Java is not suitable. While crossplatform, it is not as fast as native solutions, and is a memory hog, which is not what we are aiming at here.
* Python is not overly suited, partly because it is not as lightweight as a native program - it is an interpreted language, needing the Python interpreter to be available on the system. The same is also true of the likes of Perl (and bindings) and PHP (and bindings, e.g. PHP-GTK)
* Mono is a valid solution, but seems to be for massive projects, where enterprise-scale cross-platform development is the aim. I don't think Mono is particularly suited to small, lightweight applications.
* C/C++ appears to be the favourite. I think we should look at C/C++ as the development language.

What about toolkits? Without being funny, I don't particularly want to implement the system in C/C++ for Windows (direct calls to the Windows API), only to have to rewrite them all to X, or whatever happens to be running.

Valid possibilities:
* GTK+
* Qt
* wxWindows
* Scintilla (either alone or with one of the above)
* MFC

If we are trying to keep things moving in a small, fast environment where we are minimising external toolkits, I think GTK+ and Qt are ones to avoid. Both are functional and effective, but large (GTK's installer is about 4MB, and that's precompiled code! I couldn't find Qt binaries for Windows for comparison, but it's 31MB of source to download and play with)

wxWindows, however, is much smaller and - as been commented upon - can build quite small executables. (1MB is not small, but with a bit of tuning, I'm sure we can reduce that!), so I'm leaning towards it.

Scintilla is one of the things I'm a bit on the fence about. It is a valid solution, but what I want to avoid is to plug in a module that does 95% of what we want whilst providing a lot of "features" we won't use. I also want to avoid some of the whining mentioned elsewhere on the premise that if we build it to do what we want, we don't have to worry about exceptions and not exposing functions that aren't applicable (I remember trying to write a text editor in Visual Basic some time ago, using the Rich Text Editor control available on the college computers, and spent more code working round "features" I didn't want than anything else!)

MFC will virtually tie it to Windows with little hope of extricating it later, so that's virtually an instant no-no.

Certainly I think wxWindows is a good idea, but Scintilla I'm not sure about. It is also unclear from the site whether the Windows version needs GTK or not (I'm guessing not, though)

I'm also thinking about using the likes of MinGW and GCC to build release editions (and test code, of course)

What does everyone think?
Logged

"Cleverly disguised as a responsible adult!"
zet
Prospector
*
Posts: 4


« Reply #1 on: April 26, 2006, 06:56:54 am »

I would prefer C / C++ for the reasons you mentioned and from what I read here this is quite a common opinion.
In that case, the libs are the for question and it seems that quite a few people are interested in a cross plattform editor. I would appreciate that too.

I am using codeblocks which is using WX for some time and installed it a few days on Linux (My major OS is windows - I don't have much linux skills). I am very pleased with codeblocks - it loads quite fast and doesn't seem to be memorygreedy and feels stable and reacts very quickly on any action I do. It does a very well job on developing too (much better than Dev-CPP which was developed in Delphi).

I wouldn't prefer GTK from what the applications looked like that were using it (Gimp, Freeciv, ...).

I downloaded scintilla yesterday and compiled it (with Codeblocks) and it compiled without too many problems - just had to the linker all the libs. The scite application is also a quite good sample - it loads nearly instantly from the start. The lexer is also said to be stable and support lots of languages. I wouldn't try to reinvent the wheel here, it is very complex to write a stable working lexer. The Scite application has alltogether 1.3 mb, this isn't too much. It loadded the glee.h file that has over 8000 lines of code practically instantly. Loading a huge file (that was binary since glee.h is the hugest text file I can currently imagine being on my system) made scite crash - but for binaries it would have to include a hex editor anyway.

Does scintilla have some GUI access? I haven't looked in too deeply yesterday night. Would be nice, in that case I would already have everything to start developing Smiley - not that I have the time to do, but I guess that is not different for anyone here Wink

As I said in a post before, I would prefer Lua as for loading config files and eventually doing other stuff too. The LuaDLL is quite small (~130kb) and it runs fast and stable. Loading and saving config files in Lua is extremly simple. Because Lua offers a way to load DLLs at runtime, it would also do a nice job as plugin language - it can connect other C/C++ code with the core application in a way like a translator withouth giving up much speed. It offers a stable and simple interface for communication between different applications / Libs. I recently included some Lualibs in my project and now it has access to the net via http, ftp etc. And it was very simple to make that work...
Most features that makes editing source simple (auto completion, codechecking, automatic help depending on text at cursorposition,...) are a very well target for a scripting language like lua and it is *much* easier to edit luascripts that can even be reloaded during runtime than recompiling each time a feature is being tested. It would also give people the chance to contribute that are not capable or willing to download and compile the source + dependencies. If a stable inteface exists to a intern API of the editor (GUI and text development), a developer that wants to add a plugin could freely chose between lua or his own favourite language that can "talk" lua. In that case, only one type of an API must be provided from the editors side.

I think it could save lot's of time (and making it simpler to develop) if we chose scintilla and maybe lua without sacrificing speed or size.
Logged
SnakE
Miner
**
Posts: 13


« Reply #2 on: April 26, 2006, 01:00:38 pm »

I agree that C/C++ based upon MinGW/cygwin/gcc is the most suitable combination for lightweight solutions.

As to Scintilla.  Though it's not an environment but actually an implementation.  I'm pretty sure that CE didn't have any lexer, nor had it any code analysis facilities.  That's why it was so small and fast.  Any analysis will add to the editor's complexity and size, reduce its performance and usability.  Surely you won't be able to add a new language into a complete lexer as you were able in CE.  I'm afraid that the user won't be able to add new languages at all, but language parsers would be distributed as sort of plugins.  And, with Scintilla, just forget about supporting CE's syntax files.

Please consider.
Logged
zet
Prospector
*
Posts: 4


« Reply #3 on: April 26, 2006, 01:21:13 pm »

Yes, I saw that the lexer files seemed to be compiled into.
On the other hand, the lexer of CE had some troubles with some multiline comments in some of my luafiles.

Are there other alternatives that fit our case? I looked for syntax highlighters not so long ago and all of them seemed to be pretty complicated. But I didn't spend too much time on reading and understanding (at least a few days). I only understood that the problem is complex, especially if the document should be rendered fast and can be modified. Scintilla seemed to be fast, stable and not too huge (it worked fine on my Zaurus that has a 400 Mhz cpu...), so I thought it might fit the problem here. Sadly I have no idea how a good lexer should look like.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #4 on: April 26, 2006, 01:44:34 pm »

To be honest, this is the sort of debate I was a little afraid of with the mention of toolkits like Scintilla. I guess frmo what I'm seeing it has 85-95% of the features we need, and we will end up spending our time working round everything else, which I am very keen to avoid.

I am strongly considering taking wxWindows as the base (as mentioned) and building a custom editing/lexer solution, with input from Scintilla (in the loosest sense, such that we could look through Scintilla's code and add in what we needed, and leave out what we didn't). I also feel that trying to shoehorn in some of the features we will want will be very difficult.

I haven't discounted CE's syntax files, and what I'm wondering is whether we could approach it in a different light... maybe, for simple languages, we could keep using CE's syntax files (maybe run through an import package of some kind) and leave it at that, looking to highlight individual words, function names etc.

Then, for more complex languages, we could have a plugin-style system, either pure C/C++ DLL-like plugin or Lua script or something, to handle autocomplete and other more complex features. (Code folding would be handled separately, as part of the lexer, I would imagine)

This is something we need to establish early on - and stick to it. It will be very difficult to rebuild the source if we change mid-way through development.
Logged

"Cleverly disguised as a responsible adult!"
zet
Prospector
*
Posts: 4


« Reply #5 on: April 26, 2006, 03:26:29 pm »

It's just that I don't know how a good lexer works and how to write it - I just think that it is certainly nothing that should be considered as "easy" and this debate is important just as you say "we need to establish early on - and stick to it. ".
I can understand the argument "Do it yourself" since this is the way it surely gets just as one wants it to be. For my own case I know that I would prefer a package that does a good job, even if it can do more than needed and is missing a few features, instead of hacking something that gets more and more complicated and turns out to be unusable - just my personal nightmare. I made some good experiences using opensource libs (i.e. ODE), and I think that if there's a lib out there that can do
* syntax highlighting
* Mouse feedback
* codefolding
* custom lexfiles
* at small size
* with good performance
, then it should be preferred instead of writing it ourselves.

Codeblocks and WXlua offer some kind of syntaxhighlighting too - how do they do this? Anyone knows?
Logged
dsvick
Beta Testers
Senior Miner
***
Posts: 52



WWW
« Reply #6 on: April 26, 2006, 05:58:21 pm »

Not to further hijack this thread but my opinion is that there should only be one way of doing it, not one way for one type of language/file and another for more complex ones. That would lead to all sorts of 'how complex is complex?' questions. I'd suggest a single, fairly robust, method of handling the languages. Either in the CE way with the syntax files or, as mentioned above, with a plug in type of extending it for new languages. I'm leaning towards the original CE method just because of the wide variety of user types, some of whom would probably rather switch editors to get their language definitions they way they want them, than to learn how to write a plug in.

It has to be easy to add, remove, and change the keywords. For that I think I'd rather see an interface that does it for you rather than editing the source syntax file or having to create your own plugin just to move some keywords from one grouping to another.
Logged

Dave
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #7 on: April 26, 2006, 06:01:15 pm »

Very little in programming is "easy", because there are usually half a dozen ways of doing anything.

Scintilla does some of the above, and can be extended to cover some of the others (e.g. it doesn't do code folding itself, but there is a good example of how to on the Scintilla site). I think I'll have to try it and see what happens.

I have also noticed that a lot of people are looking for a hex editing feature, and if this is a feature we want to include, I'm not sure we could use Scintilla. I'm not even really sure integrating hex editing would be a great idea (maybe Emerald Hex Editor?) because I think it'll bloat up whatever we do.

I'm going to reread the Scintilla docs and see exactly what it offers, and set up some basic compiles, to see how big Scintilla apps start off at.

I do see where you're coming from on the subject of reinventing the wheel when there is a perfectly good one out there... I just want to avoid opening a can of worms that we don't need to.
Logged

"Cleverly disguised as a responsible adult!"
alpha
Developers
Senior Miner
***
Posts: 78


« Reply #8 on: April 26, 2006, 11:33:09 pm »

I installed Codeblocks (thank you zet) today and it looks like a good and fast IDE, it uses wxWidgets (http://www.wxwidgets.org) to render its windows. This looks just like MFC to me. May we also should use wxWidgets ...

Markus Schulz
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #9 on: April 26, 2006, 11:51:04 pm »

I've been playing around with test compilations of wxWidgets and Scintilla.

I'm thinking, provided no-one has any objections:
* wxWidgets for the UI codebase, which will allow most forms of interaction between operating systems (in other words, using wxWidgets removes the biggest hurdle for cross-platform coding)
* Modified Scintilla for the editing core.

To sum up my reasons:
* wxWidgets is cross platform, it's native C++ so it's fast and it builds native looking applications - which means no sluggish extra dependencies, nor multiple MBs of extra libraries. If nothing else, it'll make cross-compiling possible.
* Scintilla is a viable editing framework - provided that it is modified. The lexer system as currently implemented is very effective but doesn't allow runtime changes (as per CE syntax files) nor adding new ones without recompilation.

It must be possible to rewrite the lexer backend of Scintilla. I'm strongly considering making it not only a static-linked library (built directly into the main EXE / ELF / a.out as appropriate) but also bundling it with the source. It won't be pure Scintilla, and it will be a hardish job to write a workaround for newer Scintillas to cope with the massive reworking.

I know I have been hesitant to use Scintilla but I've been trying out SciTE and something quite remarkable happened - SciTE loaded a file that CE couldn't. Then again, how many people have 67MB text files kicking around their system...? Crimson loaded the file but died when the machine ran out of physical memory - it allocated something like 240MB physical RAM to handle that file, and was editable, but crashed on trying to unload the data. SciTE by comparison used only 120MB to handle the same thing. And it loaded much, much faster than CE did.

I'm convinced of the power of Scintilla but it will need reworking to be usable for EE.

Any thoughts, anyone?
Logged

"Cleverly disguised as a responsible adult!"
alpha
Developers
Senior Miner
***
Posts: 78


« Reply #10 on: April 27, 2006, 12:24:58 am »

Arantor,

this sounds like a plan, lets do it. May the Scintilla people can help us?  

Markus Schulz

PS: we should set a date when we want to be finished with planning, like two week from now?
Logged
samovar
Prospector
*
Posts: 1


« Reply #11 on: April 29, 2006, 10:10:57 pm »

I think that CrimsonEditor was written Delphi, and if EmeraldEditor is too I'd love to help.  Delphi is a tremendously productive environment, and with the use of recent versions and some care one can compile the source in .NET (and hence, very possibly, in Mono/dotGNU) as well as Win32.  

Note, however, that CrimsonEditor is exclusively for Win32; if a cross-platform solution is insisted on, you've aready had a considerable change of mission.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #12 on: April 30, 2006, 09:46:02 am »

I'm not sure if CE was written in Delphi; there is a syntax file for Pascal as part of its core syntax library, but I don't know how thorough that is.

I don't see building EE to make it cross platform as a considerable change of mission, because without the CE source it is a total rebuild in any event, and to build it in such a way as to make it buildable on any platform just seems to me to be a design-orientated feature addition.

Making it cross platform seems to have been one of the most requested features on the CE forums, and that was never going to happen without a total rebuild anyway.
Logged

"Cleverly disguised as a responsible adult!"
awmyhr
Senior Miner
***
Posts: 95

Maintainer of Obscure and Unused Ports


WWW
« Reply #13 on: May 18, 2006, 09:17:22 pm »

cross-platform is what has me interested in the project.  My current cross-platform editor of choice is 'nedit,' but on windows it requires cygwim, and on Mac OS (my os of choice) it is a fugly X app.  I'm hoping EE develops in such a way that ports use their native platform gui (i.e, Cocoa on Mac OS).  I saw this mentioned in another post, but now I can't find the post (or remember the author)
Logged

-->>  This Space 4 Rent  <<--
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #14 on: May 18, 2006, 10:50:00 pm »

Well, the builds we have done already show it using native controls, see http://forum.emeraldeditor.com/index.php?topic=69 for a Linux/GTK build - the project is using wxWidgets as its base so it should build quite happily using native controls on each platform.

Being cross-platform was one of the cornerstones to EE - it started out as being simply an open-source crossplatform version of Crimson Editor, but will morph a little as time goes on.
« Last Edit: May 26, 2006, 10:52:55 pm by Arantor » Logged

"Cleverly disguised as a responsible adult!"
Pages: [1] 2
  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.138 seconds with 18 queries.