[Geany-devel] Sidebar and MsgWindow Notebook Patches
lists.ban at xxxxx
Tue Mar 22 15:24:48 UTC 2011
Le 21/03/2011 23:10, Matthew Brush a écrit :
> On 03/21/11 10:38, Colomban Wendling wrote:
>> Le 20/03/2011 22:35, Matthew Brush a écrit :
>>> I have not thoroughly tested the implications of this, like if somewhere
>>> Geany is using the tab order or location within a specific notebook to
>>> access the children. If this is the case, it will be an opportunity to
>>> fix the code that is doing that.
>> I think it need to be better tested before adding it, but I agree that
>> fixing code depending on tab ordering would be good (it there is some).
> I've been using since I patched it, so far so good, but it's still very
> little testing. I did notice Webhelper doesn't remove his tab if it's
> been moved to the other notebook, FYI (I didn't check gwh code to
Nothing really surprising unfortunately; and this will be a real problem
for many plugins... any plugin using gtk_notebook_remove_page(), or even
gtk_container_remove(nb, child) -- basically everyone that don't simply
Actually after some thinking, one should use
gtk_container_remove(gtk_widget_get_parent(child), child), e.g. don't
expect the child to be in a particular parent.
Then we need not to make a tab detachable if the plugin don't expect it,
e.g. if it haven't set the tab name we need for restoring.
>>> I need some guidance on how to make the order and location of the tabs
>>> to be persistent so it it's saved/loaded with the session. Any hints
>>> would be appreciated.
>> This is the big problem I guess, and it probably need to be addressed
>> before applying the patches, because it's likely to need some tuning.
>> I think the problem is that we need to be able to identify a tab in
>> order to save its state. Maybe simply needing the child to have a name
>> (set with gtk_widget_set_name()) would work, though it'd need plugins to
>> be adapted to benefit of the change.
> Not all tabs in a notebook need to be detachable/reorderable, and it
> still works fine if only some are, so plugins could adapt anytime in the
> future. So really we could only care about the "core" tabs for now, if
> that would make it easier.
> Moving forward, do you think I should keep working on this? If so, is
> it best to just keep sending patches to the ML, or should I setup a
> repository+branch for this on GitHub and just let you pull out what you
I think it's an interesting feature that moves forward to a better UI
customization, so if you're interested by it, I definitely say "yes,
keep working on it" :)
I think patches are better, at least for now we're supposed to use SVN;
this will make easier for other people (Nick, Enrico, even interested
users) to get the patches.
And since when you pushed a patch to a remote Git repository you can't
ammend it anymore (well, you willn't be able to push the modified one),
it'll be easier for you to update your patches ^^
> Thanks for looking at the patches and thanks especially for the feedback
> on the other stuff. If no one tells me, I'd just keep making those
> mistakes :)
No problem :) And I know, my patches had the same kind of problems when
I started sending some ^^
More information about the Devel