Re: (great) widget layout progress
On Tue, 2012-08-21 at 12:50 +0100, Michael Meeks wrote: Do we have a GtkFixed style back-compat hack that will continue to nail widgets into their places, but do it in TWIPS such that we could do a one-shot conversion of everything and then iterate ? [ then let the designers re-work them incrementally ]. Planned something of that nature, in parallel with converter utility thing. i.e. have converter do the simplest conversion possible to a GtkGrid rather than guess/assign some layout. [*] maybe the cast-happy syntax looks a bit vile. In my experience it is remarkably common for even programmers to tweak the XML and rename / loose widgets in such a way that the code crashes later ;-) Yeah, maybe's kendy's suggestion might be the way to go, make it a build time problem. Anyhow - I'm rather excited about this - it looks insanely cool :-) are there any notable blockers stopping us getting it into master ? a) I'm working on a windows install to make sure it doesn't fall over and die under windows immediately b) print dialog looks busted, so some change has screwed that over. c) I need to stick my notes on the wiki So, here's a nagging concern of my own, not big enough to bother me greatly, but I haven't measured the size of increase due to the xml .ui files vs the size of reduction of the binary resource format. I presume that the .ui format is bigger, though its possible that the trivially-simple xml format I'm using for just the translations that maps to the single always-there en-US .ui file vs the full resource copy of the binary scheme offsets that a bit. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: (great) widget layout progress
How much work would it be to make this directly use gettext? I thought the long term goal was to switch from custom translation formats to gettext, so using yet another custom translation format for something like this seems a bit odd. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: (great) widget layout progress
Hi there, On Wed, 2012-08-22 at 17:55 +0200, khagaroth wrote: How much work would it be to make this directly use gettext? I thought the long term goal was to switch from custom translation formats to gettext, so using yet another custom translation format for something like this seems a bit odd. We had a prototype patch to use gettext on top of a key-id translation (IIRC). Unfortunately, despite the apparent simplicity of the patch, gettext started returning the most amazing results - perhaps some threading issue or ... I'd like to see some live/gettext integration working first ;-) clearly for translators to be able to see the results of their work quickly would be just wonderful - Andras is the expert here. ATB, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: (great) widget layout progress
On Wed, 2012-08-22 at 16:36 +0100, Caolán McNamara wrote:
Planned something of that nature, in parallel with converter utility
thing. i.e. have converter do the simplest conversion possible to a
GtkGrid rather than guess/assign some layout.
Sounds sensible to me :-)
Yeah, maybe's kendy's suggestion might be the way to go, make it a build
time problem.
Would work nicely I think; presumably we need some make magic for these
guys anyway to install them in some clever way.
I wonder if creating a sub-class that you could derive from:
class FooDialog : agen::ui::FooDialog {
};
that had all the Widget *m_pWidget; fluff in it ? and a suitable
pre-canned constructor table that could be size optimised later ?
a) I'm working on a windows install to make sure it doesn't fall over
and die under windows immediately
Great :-)
b) print dialog looks busted, so some change has screwed that over.
c) I need to stick my notes on the wiki
So we're nearly there - exciting times indeed :-)
So, here's a nagging concern of my own, not big enough to bother me
greatly, but I haven't measured the size of increase due to the xml .ui
files vs the size of reduction of the binary resource format. I presume
that the .ui format is bigger, though its possible that the
trivially-simple xml format I'm using for just the translations that
maps to the single always-there en-US .ui file vs the full resource copy
of the binary scheme offsets that a bit.
IMHO binary hand-packed formats are always utterly worse than layering
generic compression on top of something which since we always read
linearly should be trivial.
Can we not whack the UI files into a single .zip file ? I suspect that
would make them substantially smaller (glade produces some quite verbose
XML element-wise IIRC). [ Perhaps with a first-check (like the
images.zip accesses) to a directory tree so people can prototype their
changes in a live build ].
Anyhow - it sounds like some impressive work,
Good stuff,
Michael.
--
michael.me...@suse.com , Pseudo Engineer, itinerant idiot
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: (great) widget layout progress
On Wed, 2012-08-22 at 17:55 +0200, khagaroth wrote: How much work would it be to make this directly use gettext? I thought the long term goal was to switch from custom translation formats to gettext, so using yet another custom translation format for something like this seems a bit odd. Timar had/has some plans around moving to using gettext directly throughout LibO. But that doesn't exist right now, so rather than make that a blocker on this I've stuffed in a simple solution. When (if?) we move to gettext natively then it basically becomes fairly trivial to directly use gettext especially as that knows about .ui files already for extraction purposes and doesn't know about .src files. So conversion to .ui is a bit of a help towards directly using gettext. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: (great) widget layout progress
Hi Caolan,
On Mon, 2012-08-20 at 17:03 +0100, Caolán McNamara wrote:
Making a bit of progress in widget layout.
It looks really beautiful to me :-) I loved the container enabling etc.
Incremental Conversion: Here's an incremental conversion from the
binary format to to .ui. In this case no code changes happen at all.
Once the .ui widget ids (and their types) match the ids that the
existing code expects then magic makes it work out of the box if the
ui is correctly named and put in the right place.
http://cgit.freedesktop.org/libreoffice/core/commit/?h=feature/cmclayouttransid=aefe9698a6982eaefdae51dbaebc15a4e0bd28a7
Wow ! that is even more awesome :-)
The idea here is that, with the right conversion utility, the .src files
could be converted to some basic glade-editable skeleton and there's no
programming ability required to knock that into shape for submission.
The submitted .ui can then be dropped in as-is, and/or code then
optimized to complete the conversion.
So - Kohei started to try to write one of these in python for the
resource files before; not sure if you're aware of that. I suspect some
of it could be re-targetted / re-used the code is here:
http://cgit.freedesktop.org/libreoffice/build/tree/scratch/layout-src2xml/README?h=libreoffice-3-4
It'd be great to resurrect / build on that if we can to automate the
container-isation; though it is rather a tricky task I suspect.
Do we have a GtkFixed style back-compat hack that will continue to
nail widgets into their places, but do it in TWIPS such that we could do
a one-shot conversion of everything and then iterate ? [ then let the
designers re-work them incrementally ].
[*] maybe the cast-happy syntax looks a bit vile. Perhaps a bit family
of get_foos_by_name, or a get_by_nameT template instead ?
So - I had a few thoughts here ;-)
http://cgit.freedesktop.org/libreoffice/core/commit/?h=feature/cmclayouttransid=064c21aec9245148e90290afd00c46b0999d19c4
One of the things I love about the new model is shrinking the
generated / dialog code-size - by killing all those bazillions of
function calls in constructors.
+ m_pDivIntervalNF =
static_castNumericField*(m_pUIBuilder-get_by_name(linesspin));
+ m_pDivRowsFT = m_pUIBuilder-get_by_name(lines);
...
I suspect it would be more efficient (if we can) to build a descriptor
of the fields (with their types), and map (and verbose-type / NULL
check) all in one place. In my experience it is remarkably common for
even programmers to tweak the XML and rename / loose widgets in such a
way that the code crashes later ;-) I'm sure as a C++ programmer there
is some magic template-ness that could do this in a single line with
better type-safety:
typedef struct {
const char *name;
void **member;
type_info type;
} CnxData;
CnxData aCnxs[] = {
{ linespin, m_pDivInternalNF, typeof(*m_pDivInternalNF) },
{ lines, m_pDivRowsFT, typeof(*m_pDivRowsFT) }
};
m_pUIBuilder-connect_data (aCnxs);
or whatever - presumably with some more macro goodness to align the
member names with the widget names:
CnxData aCnxs[] = { CNX(DivInternalNF), CNX(DivRows) };
etc. I guess glade also has this automatic signal connection goodness
that does a similar thing, and we could map to our links quite nicely -
but of course, manual connections are fine too.
Anyhow - I'm rather excited about this - it looks insanely cool :-) are
there any notable blockers stopping us getting it into master ?
Thanks !
Michael.
--
michael.me...@suse.com , Pseudo Engineer, itinerant idiot
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
