Of technology choices ...
... and the regrets there after.
Some (long) time ago (2007) I created a plugin for an open source project. I'm talking about the DBGP plugin for Notepad++. I remember how awesome it was to get it working back then. Let me explain.
I did some Win32 development, but it was always with Delphi. I completely understood Win32, I just never was able to do it "the VS6 way". Why I choose N++? It was an editor I used on daily basis and it looked nice and I figured out it had an simple enough plug-in system. Why did I even bother with a debugger?
Well, I was always a sucker for debuggers. On linux, gdb is like my best friend. I learned programming in Turbo Pascal (yes, those old DOS days). It had a debugger. Not to mention later, Delphi, Visual Studio... And not long before than, I experimented with DBG (a commercial/OSS debugging engine for PHP). There were a few debugging options for PHP but it wasn't until I found XDebug, that I really got excited about it again. Sadly back then, there was no good free client to use with XDebug. All of this contributed towards me starting to experiment and finally implementing a DBGP plugin.
Any way, N++ had a plugin template in C++, that was made up of 3 parts:
the non-interactive part, containing the raw plugin interface, menu registration, windows messages and a way to interact with the scintilla component in N++,
and an extension of this window template to be used as a docking window.
Yes, N++ has an internal window docking manager.
It was a real kick porting everything to pascal and seeing it work, I even made a bunch of helper classes and I released a Delphi Plugin Template (no idea if it still works - I know I'd need to change at least one thing).
It wasn't until I made a couple releases of the DBGP plugin that I started to realize what was its biggest technology problem. Yes, the N++ internal docking manager. It was just too limited and in some cases Delphi VCL components just did not want to play along. One instance was, I think, a pannel component that linked the control together in a funny matter in which, when a native Win32 function was searching backwards (find previous element on a cyclic single linked list, remember?) got stuck in an endless loop. But the worst part was the docking. N++ only has 4 docking spaces (up, down, left and right). For a debugger to be useful, you need a lot of small windows in sight (at least local context, stack, optionally immediate, global context, breakpoint list, existing sessions ...) With 4 docking places, thats just not possible.
So I did what I could and took the JVCL library and used its (much better) docking implementation inside one docked N++ plugin window. At least something.
But when time passed I got more frustrated with this limitation and with lack of actual PHP work I just didn't do much of any updates to the plugin.
I currently help out with another debugger, that is inside a much newer IDE and without this limitation, the user experience is much better.
Just want to point out, the bad technology choice wasn't that much Delphi, as some would expect, it was actually N++. Please don't misunderstand, N++ is a great editor, Don Ho, Jens and others do an amazing job. If only somebody would refresh the docking manager, that would really give the product some extra value. (Yes yes, I hear the screams, "do it yourself"... no time, sadly)
P.S.: I just remember one other thing that got me also really disappointed. I wanted to create a submenu in the plugins menu using the VLC ContextMenu component. And even when I was able to create the menu, I could not get any callbacks to work, because there was no way to route the main window message loop into this class. It just got exposed to the plugin. Sad, sad.
P.P.S: Another frustrating thing I couldn't get Don Ho to change was the callbacks, that get registered with N++ on plugin startup, those for plugin menu items. They don't contain any sort of identifier argument. So if you register menu item A with function X and menu item B with function X, when function X gets called, you have no chance to find out whether it was called because of item A or B. Very frustrating for a person trying to provide a nice class based plugin template.