You don't need to walk any tree's, if you need to notebook from the scintilla, just store a pointer to the notebook in the scintilla, ex. using g_object_set_data() or more painfully by subclassing it.

That pointer needs to be updated properly when the doc is moved. I rather save that and walk the tree, it's cheap enough. (g_object_get_data() is a hash-table lookup which isn't exactly free either)

A few pointer compares up the tree is likely to be cheaper than the hash and has the advantage that sneaky plugins that move the widgets can't forget to update the pointer, so I'd say leave it as is.


There is no "notebooks_arr" in the current code. Instead there is a macro which makes it easy to transition to such an array later on.

Seriously, if foreach_* macros are so frowned upon, why is Geany still full of them? I'm literally just following existing Geany-style with that macro.

I personally like these macros, they are easy to understand and nicely short. I've also seen them used in other projects.

I don't like any macros, and I suspect that the use of them is one of the things on Matthews list :)

But leave it there for now, it will have to be up to the maintainer to decide when its committed, either way won't take much to change.


Yep, that's why my previous message, I'll try not to interfere here too much since no one is interested in the type of stuff I'm talking about probably (cleanup up the code en masse).

I would still love to collaborate with you and other devs, even if I'm not going to make the uncertain (for me, anyway) big cleanup personally.

Split window functionality should not depend on the "big cleanup".  Matthew may have a point that it might be easier after the cleanup, but so far its simple enough.  Just keep going :)

On the plugin API, its gonna break, plugins will have to know about two notebooks, so at least some new functions are needed.  

But if you keep to your current arrangement of making the new functions a new name (even if its adding 2 to the end :) whilst keeping the old function, and you are careful about always adding to the end of structures, it may get away without an ABI break.  That would be good because it means that old plugins will not break (clearly they won't use any of the new functionality which may hinder their usefullness, but they should not break).  

Currently there is a situation where some distros have a version of Geany that does not match the versions of geany-plugins they have, and it would be good to avoid that meaning that users can't use any plugins at all.


Best regards.

Devel mailing list