On Sat, 2013-04-06 at 23:59 -0400, Matthias Clasen wrote:
> Hey Tristan,
>
> thanks for sending this detailed status update. Here is some initial
> feedback after playing with the branch for a few minutes:
>
> 1. intltool - I don't like it, and really want to avoid adding a
> intltool dependency to GTK+. I've attached a small program that can
> get the job done for the .ui files in your branch.
>
I'm afraid that your efforts on writing an intltool-extract
replacement are misplaced.
>From my original mail:
> In order to properly extract translations of strings
> defined in .ui files, the files need to be listed
> with lines like the following in POTFILES.in:
>
> [type: gettext/glade]gtk/gtkfilechooserdefault.ui
>
> This breaks the build without adding IT_PROG_INTLTOOL()
> to configure.ac.
In other words, intltool extracts the translations from GTK+
just fine, without the added line to configure.ac
I've been asking around and it seems that translator teams
get the .po files from a website called damn lies. The .po
files presumably get put there by translator team leaders
who run intltool-update or such (perhaps as a batch process
in a script, I'm not clear on that part)... anyway... cd
into gtk+/ and intltool-update manually works fine to extract
translations.
However. Remove the important from configure.ac, and GTK+'s
makefiles in po/ (which are normally intltool generated) choke
on the entries in POTFILES.in.
To reproduce:
o Checkout composite-templates-new branch
o Revert the first commit (the one that adds IT_PROG_INTLTOOL)
o git clean -xdf
o ./autogen.sh .... your args
o make
Now things screw up, the makefiles in gtk+/po/, are not smart enough
to deal with the [type gettext/glade] annotations, and just abort
the whole build.
So I have to reiterate my question: How exactly does intltool make
your life difficult maintaining GTK+ ?
I don't understand why it causes you problems while every other
project containing .ui files get along fine.
> 2. All the composite dialogs flash black and in wrong size when
> mapped. I hope that is just an oversight, and can be corrected. I
> don't think we can merge it like that
I've witnessed the black flashing yes. It annoyed me but I didn't
once think it possibly that my branch was causing this (dialogs
are certainly constructed before being mapped, before any visual
surface is ever created for them, and all of the template building
is done quite synchronously before ever reaching ->map()).
Glade uses GtkAboutDialog, GtkFileChooserDialog, GtkColorChooserDialog
and maybe more, I did pay very strict attention to porting the
properties of existing composite widgets, and dont find them to
be in the wrong size (I may have missed a couple issues, as you
point out in your further comments, and thanks for catching them).
I'll look into this in more detail, and try using the doc-shooter
program to compare the before/after dialog sizes.
> 3. The print dialog segfaults.
Indeed, I've just tried it with gedit, actually (I was looking for
a good case).
I actually wrote off the print dialog because GTK+ doesnt have
a test case for it that I could find, and GTK+ master as well
as my branch segfault equally when the treeview is clicked.
I'll try to identify if it's a regression in my branch and
if I can fix it, using gedit.
>
> 4. The Pickers example in gtk3-demo has issues: the filechooser button
> has the wrong height, and the directory chooser doesn't show up at
> all. The filechooser also has an empy filter combo that should not be
> visible.
>
> 5. The Color Chooser example in gtk3-demo has issues: the alpha slider
> in the color editor has a round knob, instead of a pointy one.
>
> 6. The button order in the assistant is flipped.
I'll look into all of these problems right now.
Cheers,
-Tristan
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
