[Geany-Devel] splitwindow2

[Lex Trotman]

[...]

> 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.


Cheers
Lex


>
> Best regards.
>
> ______________________________**_________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-**bin/mailman/listinfo/devel<https://lists.geany.org/cgi-bin/mailman/listinfo/devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20131012/631da41a/attachment.html>