Thoughts about the project and adding the first PR

[brupelo]

@gamecreature Rick, hi! nice to meet you :D

Why am I interested on the project?

Little bit of background about myself first :) . I'm a {python,c++,c,asm} coder, in that order of preference (order of preference driven by dev-performance vs runtime-performance). Nowadays I code all the tools frontends using python and backends in {c++/c/asm} (only if strictly necessary)

Anyway, couple of days ago I've discovered this project of yours when trying to find better alternatives to Scintilla/QScintilla... Thing is, I really love SublimeText and I'd like the text editors from my tools to expose the same behaviour pretty much the same. I've been using QScintilla as a main choice for long time but the only reason was mainly because it was the only choice I was aware of :( , (thanks ST for being closed-source :/)

When I was getting a grasp of the high level architecture of your project and played with the provided example apps I immediately thought... wow! this project is really awesome, not only because the c++ code is well-architected, clean and using proper good practices but also because contains many features that should be provided by modern text editors (IMHO).

How would I contribute to this project?

After getting familiar with the project I started thinking how I'd replace QScintilla (python wrappers of Scintilla) with edbee-lib and two choices came to my mind:

1) I'd port the whole project to python

Pros:

• Switch from the edit-compile-run cycle to the edit-run cycle using a non-redundant language as python would improve iteration times
• The python port would probably get a similar performance than the c++ counterpart implementation as it's relying quite a lot on qt builtin blocks
• In the long term the project would get widely adopted by the python community as there isn't a proper choice when it comes to text editor widgets so this would probably become THE main choice so the project would get a lot of traction

Cons:

• Porting this project to pure python (pyqt & pyside) would probably take me 3 or 4 weeks full-time job and I don't have that kind of luxury as my plate is already full with tons of high-prio projects.
• Just looked your blog to know more about your language choice preferences and I didn't see python mentioned anywhere in the tags... but I saw you liked Ruby so I immediately assumed you were not a python dev (quite important actually as you're the one who knows more about the project)
• The project is already well architected and there is no strong reason to use another language, plus... the assumption all existing contributors would favour python instead c++ may not be the case

2) I'd wrap the project to be used on python (pyqt or pyside2)

Pros:

• The current project will continue improving at the same pace
• Tests or examples will be done much faster, that will allow to create more github issues, so the project will be improved much faster
• Creating wrappers in both sip or shiboken is relatively easy. Using swig is not really a good choice though (qt wrappers on python use shiboken(pyside2) or sip(pyqt))
• Non intrusive solution, a wrapper is just a client with the library as dependency

So after a bit of thinking I decided to go with 2) ... :D

First PR proposal

After wasting 1 day creating some SIP wrappers of edbee-lib I've realized creating and compiling the wrappers wasn't really fast... mainly because it had to compile statically edbee-lib and this was taking me like ~1min (without wrapping all classes of edbee-lib) so I thought these times would be much shorter if instead my wrappers would use an edbee-lib dynamic library. Which means... create wrappers once and then just replace the dynamic library to get new features & improvements (if the edbee-lib interface doesn't change).

So that's what my first PR is all about, it's a first attempt to be able to build edbee-lib not just statically but also dynamically... I've tried to leave the default options untouched although I think including CONFIG+=staticlib in the .pro file is not a good. Unfortunately you can't use the -= operator when invoking qmake in the command line... ie: `qmake CONFIG-=staticlib won't work :/ .

Btw, I assume everyone here is familiar with how qmake works, some reference docs just in case:

• https://doc.qt.io/qt-5/qmake-manual.html
• https://doc.qt.io/qt-5/sharedlibrary.html
• https://doc.qt.io/qt-5/qmake-language.html
• https://doc.qt.io/qt-5/qmake-variable-reference.html

CONCLUSION

Sorry for the long thread, I had many more things to talk about but I'll refrain myself of doing so... let's see how this evolves... That said, here's my first PR

Ps. I'm from Spain so sorry for my creepy English ;D

[vadi2]

We use Edbee in Mudlet (http://github.com/mudlet/mudlet) and we won't be using the Python version - it'll be a big overhead for a C++ application to add a Python runtime 😕

[brupelo]

I see, if there is an existing c++ app having edbee-lib as dep I agree would make little sense to use the python wrapper at all. On the other hand, using the shared library could have obvious benefits in terms of updating without having to recompile at all the existing clients (edbee-app, mudlet, ...).

That said, I've been coding qt apps since qt2.0 and coded countless of c++ qt apps many years ago... nowadays I don't see any real benefit anymore by doing so (not even for high-performance real-time 3d heavy apps). The perfect combo for me nowadays is using python+pyqt/pyside(frontend) and c++(backend). Of course, this only applies if you're coding apps from scratch... porting existing big c++ apps to python is usually not worth the effort... at least in the short/middle term or if you don't have the proper resources.

[vadi2]

Yep. We're finding modern C++ with good tooling to be pretty productive. Would love to see you sneak improvements into edbee- lib in C++, though!

[gamecreature]

@brupelo I do agree that using a dynamic language like Python or Ruby would increase the pace of development iterations.

I will merge the PR! (it still builds without issues, and I like the option for dynamic linkage)
I don't know how muck impact CONFIG+=staticlib has for you..

[brupelo]

I don't know how muck impact CONFIG+=staticlib has for you..

Hiya Rick! No worries, not a big deal... For the wrapper I can just use a different .pri file without using staticlib at all. At first I though I'd modify the existing .pro file in the PR but then I thought that wouldn't be nice at all cos the PR would break travis or other existing deps... So I decided the PR shouldn't break anything while still adding some little extra value ;)

Btw, did I mention how cool your project is? Thing is, I've asked few things about ST (sublime_api) behaviour in the forums many times but it seems the author doesn't like to reveal many of the internal tricks :) . So until now my plan was trying to duplicate my favourite SublimeText features on QScintilla... in fact, you can see many of my Stackoverflow questions about QScintilla&Sublime... that was really a bad approach and I've never really liked Scintilla&Qscintilla at all but again, in python land this was the "best" choice I was aware of :/

With this cool project of yours having a nice Text Editor widget that has a very similar behaviour than SublimeText has become a reality! And that's pretty awesome, so thanks about that ;D

Yours,
Bruno

[brupelo]

@gamecreature Let me ask you, any experience with python? Do you like this language?

[gamecreature]

@brupelo, no unfortunately I've got almost no experience with Python. Ruby is the language I use daily. (I like Ruby very much!)

[brupelo]

@gamecreature Oh, that's unfortunate but I totally understand :) . Just asked cos I've posted few minutes ago a little experiment after 3 days working on it full-time trying to port edbee-lib to python.

The result is pylime. As you can see it's just WIP to see how many people will get interested on helping and making it real... if there isn't nobody interested on it after few days/weeks I'll just assume I've wasted 3 days and I'll throw the whole thing to the bin :/