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