Quote Originally Posted by elcuco View Post
Anyone tred this code...?

Anyway, I tested your code. In order to make it run I needed to apply this patch:
Qt Code: 
  1. diff -ru qcodeedit-0.1.0-beta-orig/example/example.pro qcodeedit-0.1.0-beta/example/example.pro
  2. --- qcodeedit-0.1.0-beta-orig/example/example.pro       2006-07-28 16:37:06.000000000 +0300
  3. +++ qcodeedit-0.1.0-beta/example/example.pro    2006-08-01 23:03:25.000000000 +0300
  4. @@ -4,8 +4,10 @@
  5.  
  6.  TEMPLATE = app
  7.  TARGET = example
  8. -
  9. +INCLUDEPATH +=  ../include ../src ../src/editor ../src/language ../src/generic
  10. +DEFINES += _QCODE_EDIT_GENERIC_
  11.  CONFIG += release qcodeedit
  12. +LIBS += -L../src/ -lqcodeedit
To copy to clipboard, switch view to plain text mode 
I also needed to copy the *.so file into the example dir. When you type text the application does work, but when pasting large portions of text (qwidget.cpp was my test case) or load it via the command line the text does not get painted.

About the code itself:
The idea of having different contexts in the language definitions if cool. This means that different color can be applied to the same word depending of it's location on the text.

I am not sure that putting the colors definitions inside the syntax declaration is a good idea: you are not able to modify the colors of your syntax. For example, people which have a pink desktop will have problems with your code, since the text editor will always be with white background.

I am not sure that re-inventing the wheel and defining a new syntax declaration is a good idea. If you choose another project language definitions are will gain a lot of syntaxes for free, and you now only have to code an engine to display them. For example:

Sharp develop also use XML for describing the syntaxes:
http://www.icsharpcode.net/OpenSource/SD/

GtkSourceView also uses XML (see also my minimal implementation for this definitions)
http://gtksourceview.sourceforge.net/

And also notepad++ (win32 application):
http://notepad-plus.sourceforge.net/uk/site.htm

Another suggestion can be using plain "ini" files instead XML. This will make the construction on new syntax definition files much easier.
I'm pleased to have some feedback but I must inform you that the code I posted here is quite out-of-date... I've continued developping it for use with Edyuk and you can always find the latest version on the SVN trunk or (a little older one) on the latest surce package.

The syntax definition in itself still needs some work. Honestly I didn't pretend to have crafted the ultimate file format here. I just thought about one that would be human readable and has some convinience. I'm not against using other ones but as you might have noticed I'm using some rather special mechanism like the href stuff and the context aware definitions (or nested definitions). Besides if you want to support another generic definition format all you need is to reimplement the some interfaces for highlighting, paren matching, ... and also create and add proper definitions to the factory.

About the colors : I didn't had much time to think about that but you're probably right... I should place them in a separate file. I'll give it a try in a next version.

Using INI files should allow faster and a little easier syntax creation but it would also make them look ugly when using nested/context-aware highlighting definitions...

The convention in Qt is that only Trolltech issues classes with names like QClassName. Third-party developers are expected to put initials after the Q to identify it as theirs, as in QfmcCodeEdit. You can find the naming guidelines here. You are supposed to register the initials with Trolltech, but I have registered my own (ij) and have not heard from them and it has not appeared on their site.
I had never heard of that and, IMHO, it's rubbish... Long prefixes make the code longer to type and sometimes harder to understand. Moreover, everytime I use the Q prefix it's to state a self-sufficient component (apart from Qt dependencies of course ) that is meant to become someday a library well-integrated into Qt... Ultimately, if the Trolls asked me to change that I'd rather put a namespace than changing all class names...