[Geany-devel] Sidebar and MsgWindow Notebook Patches

[Colomban Wendling]

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

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
gtk_widget_destroy(child).
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.

Right, agreed.

> 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
> want?

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

Cheers,
Colomban