On Thu, 2013-04-11 at 13:36 +0900, Tristan Van Berkom wrote: First, let me apologize for the rather harsh tone in my message yesterday. I had a big "WTF" moment when I saw how the composite templates patches played badly with my branch. Your message made things look easier to fix than I expected.
> So, this is how I propose we handle the situation: > > o First, you rebase your branch in such a way > that the filechooserdefault is reverted as > the first commit in your branch. I'll do something like this. First, revert the commit. Then, merge my branch. Doing a straight rebase is not trivial, as places-sidebar has gotten master merged into it a few times to keep up with general development. And finally, apply your commit again with lots of changes. > o Second, I know you wont like this part but > I need you to put the instance members on > a private structure. > > We do not support automatically assigning > component pointers to public structure offsets. > > And frankly, using a public structure defined > openly in gtkfilechooserprivate.h is an open > invitation for other components to access > the components of GtkFileChooserDefault directly > (which I think we both feel is unintended). I totally agree with this for *public* widgets, those that go into the public API. But for GtkFileChooserDefault, I have two objections: 1. It's a private, internal widget, never meant to be exported. 2. I'd really really really like to keep the file chooser's code as similar as possible between gtk2 and gtk3. Otherwise, cherry-picking fixes becomes much harder. I do appreciate having the private stuff in the .c file. And I definitely don't like the current state (well, before your patches) where the GtkFileChooserDefault struct is not in gtkfilechooserdefault.h, but in a gtkfilechooserprivate.h file. I don't remember why it ended up there; probably so that the unit tests would be able to poke at internal widgets. *That* is not the right thing to do, anyway, so I'm happy to see the struct move elsewhere. But the objections still stand. I haven't even seen how the code for composite templates pokes at structs... but why does it have to care whether the struct is private or public? Could we have: gtkfilechooserdefault.h: /* no struct definitions at all */ typedef struct GtkFileChooserDefault *GtkFileChooserDefault; typedef struct GtkFileChooserDefaultClass *GtkFileChooserDefaultClass; gtkfilechooserdefault.c: /* complete structure definitions */ struct GtkFileChooserDefault { GtkBox parent; blah blah; } ? > o If you have made any changes to the UI, i.e. > changes like spacing settings, expand/align > settings of any widgets in the filechooser, > any newly added widgets, anything that actually > changes the UI components, I would like you > to list those changes to me so I can make > the changes while splitting up gtkfilechooserdefault.ui > into 2 .ui files. Sorry, you lost me - what would those two files be for? (GtkPlacesSidebar is a self-contained thing which is mostly a GtkTreeView...) Federico _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list