Lars Gullik Bjønnes wrote:
> I have no patch.
I meant the one that I sent. It is in now since Jean-Marc said yes.
> But the above (lyx-qt -x 'command-sequence buffer-new;
> lyx-quit') can be used so that we are sure to use the same things when
> timing, and of course to say that I don't have a
Georg Baum <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
|
| > Georg Baum <[EMAIL PROTECTED]>
| > writes:
| > | so I came up with the attached. This reduces startup time for math
| > | documents from 9.8 seconds to 6.8 seconds (1.4cvs, qt) for me.
| > |
| > | I propose to put this bot
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> so I came up with the attached. This reduces startup time for
Georg> math documents from 9.8 seconds to 6.8 seconds (1.4cvs, qt) for
Georg> me.
Georg> I propose to put this both into 1.3 and 1.4. OK?
Yes, very good idea.
JMarc
Lars Gullik Bjønnes wrote:
> Georg Baum <[EMAIL PROTECTED]>
> writes:
> | so I came up with the attached. This reduces startup time for math
> | documents from 9.8 seconds to 6.8 seconds (1.4cvs, qt) for me.
> |
> | I propose to put this both into 1.3 and 1.4. OK?
>
> btw. I have a startup time
Georg Baum <[EMAIL PROTECTED]> writes:
| Jean-Marc Lasgouttes wrote:
|
| >> "Georg" == Georg Baum
| >> <[EMAIL PROTECTED]>
| >> writes:
| >
| > Georg> I am sure that a textdgree sign is available in one of the
| > Georg> other fonts, but I don't know how to declare it in lib/symbol
|
Jean-Marc Lasgouttes wrote:
>> "Georg" == Georg Baum
>> <[EMAIL PROTECTED]>
>> writes:
>
> Georg> I am sure that a textdgree sign is available in one of the
> Georg> other fonts, but I don't know how to declare it in lib/symbol
> Georg> so that it works in all encodings.
>
> It seems
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> I am sure that a textdgree sign is available in one of the
Georg> other fonts, but I don't know how to declare it in lib/symbol
Georg> so that it works in all encodings.
It seems to be in text companion encoding (TS1). Do we have that
Lars Gullik Bjønnes wrote:
> This is only moving the math init from lyx startup to the first time
> someone uses math, right?
yes.
> then ok.
thanks.
Jürgen
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| Georg Baum wrote:
| > Jean-Marc Lasgouttes wrote:
| > > I think that this patch always makes sense, irrespectively of whether
| > > we manage to improve this font querying later...
| > >
| > > I'd propose to apply it.
| >
| > Me too.
|
| Lars?
T
Jean-Marc Lasgouttes wrote:
> So shall we make a new latex-xft-fonts based on bakoma, or shall we
> propose to install mathml-fonts?
We have that already, see the wiki: http://wiki.lyx.org/pmwiki.php/FAQ/Qt
(although the text is a bit confusing)
> Georg> but LyX still can't find a symbol font (I
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Jean-Marc Lasgouttes wrote:
>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>>
Lars> But what is the delay caused by. Not everyone sees it. Is it the
Lars> sheer number of fonts, or is it that some fonts are missing?
Georg Baum wrote:
> Jean-Marc Lasgouttes wrote:
> > I think that this patch always makes sense, irrespectively of whether
> > we manage to improve this font querying later...
> >
> > I'd propose to apply it.
>
> Me too.
Lars?
Jürgen
Jean-Marc Lasgouttes wrote:
>> "Lars" == Lars Gullik Bjønnes
>> <[EMAIL PROTECTED]> writes:
>
> Lars> But what is the delay caused by. Not everyone sees it. Is it the
> Lars> sheer number of fonts, or is it that some fonts are missing?
It seems that a noticeable part of the delay happens
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> But what is the delay caused by. Not everyone sees it. Is it the
Lars> sheer number of fonts, or is it that some fonts are missing?
I think that this patch always makes sense, irrespectively of whether
we manage to improve this
Jean-Marc Lasgouttes wrote:
> Andre> Do _we_ look at every font or is it Qt?
>
> Not sure. Anyway, it looks like we actually try to load the fonts, and
> using QFontDatabase to look for availability seems more reasonable.
Probably. Anyway, I think initMath() should be moved to math_hullinset
none
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Do _we_ look at every font or is it Qt?
Not sure. Anyway, it looks like we actually try to load the fonts, and
using QFontDatabase to look for availability seems more reasonable.
John, is there a reason why this has not been done
On Sun, Dec 11, 2005 at 04:58:07PM +0100, Helge Hafting wrote:
> On Sat, Dec 10, 2005 at 01:49:36PM +0100, Lars Gullik Bjønnes wrote:
> > Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
> >
> > | What do you think?
> >
> > In 1.5 we should move towards making all the mathed initialization
> > la
On Sat, Dec 10, 2005 at 12:40:05PM +0100, Juergen Spitzmueller wrote:
> Juergen Spitzmueller wrote:
> > It seems the behaviour was changed by André on 2004-04-13 during a major
> > macro rewrite.
>
> The attached patch restores the behaviour of 1.3: initMath() is not called on
> startup, but the
On Sat, Dec 10, 2005 at 01:49:36PM +0100, Lars Gullik Bjønnes wrote:
> Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
>
> | What do you think?
>
> In 1.5 we should move towards making all the mathed initialization
> lazy. We should try to avoid paying for stuff/features that is not
> used.
Goo
Lars Gullik Bjønnes wrote:
> But what is the delay caused by. Not everyone sees it.
> Is it the sheer number of fonts, or is it that some fonts are missing?
I think it is the sheer number of fonts. It is at least that people with lots
of fonts see the delay, while others with less fonts (like Jea
Lars Gullik Bjønnes wrote:
> Some testing first, then we'll decide.
Certainly.
> But if not now, we should move towards delayed initialization of math
> as well.
I think so, too. After 1.4, we should try to do more clever initialization
(whatever that means).
> What does initMath really do?
v
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| What do you think?
In 1.5 we should move towards making all the mathed initialization
lazy. We should try to avoid paying for stuff/features that is not
used.
--
Lgb
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| Juergen Spitzmueller wrote:
| > It seems the behaviour was changed by André on 2004-04-13 during a major
| > macro rewrite.
|
| The attached patch restores the behaviour of 1.3: initMath() is not called on
| startup, but the first time a math i
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| Juergen Spitzmueller wrote:
| > It seems the behaviour was changed by André on 2004-04-13 during a major
| > macro rewrite.
|
| The attached patch restores the behaviour of 1.3: initMath() is not called on
| startup, but the first time a math i
Juergen Spitzmueller wrote:
> It seems the behaviour was changed by André on 2004-04-13 during a major
> macro rewrite.
The attached patch restores the behaviour of 1.3: initMath() is not called on
startup, but the first time a math inset is being inserted (or when a
document with math insets is
Juergen Spitzmueller wrote:
> > The 1.3 approach is better then, because only a subset of documents
> > actually uses math. It is so nice to have a fast-starting lyx for
> > writing letters & notes, and for looking at exisiting lyx documents. I
> > actually use math, but not in the majority of my
Helge Hafting wrote:
> A substantial improvement.
> This change alone cuts the startup time from 3.5s to 1.5s
> on my opteron.
> (time lyx -x lyx-quit)
OK. I suspected this.
> Still on the slow side compared to lyx-1.3, but much better.
> I don't get any math symbols though, but that's what this
On Fri, Dec 09, 2005 at 12:59:34PM +0100, Juergen Spitzmueller wrote:
> Helge Hafting wrote:
> > Well, I have 20321 fonts according to xfontsel. The fonts are
> > serverd by xfs, not the xserver itself. I hope lyx-qt 1.4 isn't having
> > a look
> > at all of them during startup. qt itself is not
On Fri, Dec 09, 2005 at 04:42:13PM +0100, Jean-Marc Lasgouttes wrote:
> > "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
>
> Also what happens with "lyx -dbg init,font -x lyx-quit"?
Setting debug level to init,font
Debugging `init' (Program initialisation)
Debugging `font' (F
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Helge Hafting wrote:
>> Well, I have 20321 fonts according to xfontsel. The fonts are
>> serverd by xfs, not the xserver itself. I hope lyx-qt 1.4 isn't
>> having a look at all of them during startup. qt itself is not
Helge Hafting wrote:
> Well, I have 20321 fonts according to xfontsel. The fonts are
> serverd by xfs, not the xserver itself. I hope lyx-qt 1.4 isn't having
> a look
> at all of them during startup. qt itself is not the problem - lyx-qt 1.3
> starts in less than a second on the same machine.
I
Helge Hafting wrote:
> The 1.3 approach is better then, because only a subset of documents
> actually uses math. It is so nice to have a fast-starting lyx for writing
> letters & notes, and for looking at exisiting lyx documents. I actually
> use math, but not in the majority of my documents.
I a
Juergen Spitzmueller wrote:
Georg Baum wrote:
qt itself is not the problem - lyx-qt 1.3
starts in less than a second on the same machine.
Same here.
I think 1.3 searches for the math symbol fonts only if you insert a math
formula (judging by the font debug messages), while 1.
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Helge Hafting wrote:
>> Well, I have 20321 fonts according to xfontsel.
Georg> I have 19975.
I have only 4934 :)
JMarc
Georg Baum wrote:
> > qt itself is not the problem - lyx-qt 1.3
> > starts in less than a second on the same machine.
>
> Same here.
I think 1.3 searches for the math symbol fonts only if you insert a math
formula (judging by the font debug messages), while 1.4 searches at startup.
I have a remar
Helge Hafting wrote:
> Well, I have 20321 fonts according to xfontsel.
I have 19975.
> The fonts are
> serverd by xfs, not the xserver itself. I hope lyx-qt 1.4 isn't having
> a look
> at all of them during startup.
Maybe it does exactly that?
> qt itself is not the problem - lyx-qt 1.3
> s
Georg Baum wrote:
I get almost the same results (4.9s for 1.4, 0.8 for 1.3 on a 1.3 GHz duron
for
/usr/bin/time lyx -x lyx-quit
(qt frontend) The time for 1.4 drastically improves for the xforms frontend:
1.5s. The reason is that lyx_gui::font_available takes quite some time in
the qt case. Th
Jean-Marc Lasgouttes wrote:
>> "Georg" == Georg Baum
>> <[EMAIL PROTECTED]>
>> writes:
>
> Georg> The reason is that lyx_gui::font_available takes quite some
> Georg> time in the qt case. This is called several times from math
> Georg> initialization (initSymbols).
>
> How do you kno
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> The reason is that lyx_gui::font_available takes quite some
Georg> time in the qt case. This is called several times from math
Georg> initialization (initSymbols).
How do you know the time is spent there? The code in
qfont_loader::ava
Helge Hafting wrote:
> Well, this helped -- a little.
> With
> $ ./configure --prefix=/usr/local --with-frontend=qt --with-gnu-ld
> --with-qt-includes=/usr/include/qt3 --disable-debug
> --disable-concept-checks --disable-stdlib-debug --enable-optimization=-O2
> I got 4.7s starting lyx instead of 5
On Wed, Nov 09, 2005 at 08:24:58AM +0200, Martin Vermeer wrote:
> > The idea is that each frontend author is free to implement the dialogs
> > as he wants. There is no contraint on their layout and/or text.
>
> But that's a bug, not a feature, right? We _should_ strive for uniformity.
This would
On 10 Nov 2005, Lars Gullik Bjønnes wrote:
> | Lars> Yes, why not... (have an english translation as well...)
> |
> | I do not see what problem this would solve, actually.
>
> It would probably make us see problems in l10n/i18n sooner, sine all
> languages (even english) would be on equal footin
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> | The current mechanism with "[[...]]" ensures both.
|
| Lars> Well... it is fairly ugly. A nicer syntax could be choosen.
|
| Why? I think it is clearer for a non progra
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> | The current mechanism with "[[...]]" ensures both.
Lars> Well... it is fairly ugly. A nicer syntax could be choosen.
Why? I think it is clearer for a non programmer that this thing is a
note. The goal was not to have a synta
Georg Baum <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
|
| > Georg Baum <[EMAIL PROTECTED]>
| > writes:
| >
| > | Can you give an example? That would mean that the machinery to
| > | disambiguate such words with "fly[[as in 'to fly']]" and "fly[[as in 'a
| > | fly']]" in messages.C
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>> In anycase we need to change to have only one way of defining
>> shortcuts.
>>
>> But all this is 1.5 stuff.
Georg> Yes.
Note that this is something that should be tackled early enough in the
1.5.x cycle. It is a pity that we have this
Lars Gullik Bjønnes wrote:
> Georg Baum <[EMAIL PROTECTED]>
> writes:
>
> | Can you give an example? That would mean that the machinery to
> | disambiguate such words with "fly[[as in 'to fly']]" and "fly[[as in 'a
> | fly']]" in messages.C is not needed at all.
>
> And I don't think we should u
Georg Baum wrote:
Can you give an example? That would mean that the machinery to disambiguate
such words with "fly[[as in 'to fly']]" and "fly[[as in 'a fly']]" in
messages.C is not needed at all.
I was wrong. I thought they couldn't possibly have made the assumption
that a string always ca
Georg Baum <[EMAIL PROTECTED]> writes:
| Can you give an example? That would mean that the machinery to disambiguate
| such words with "fly[[as in 'to fly']]" and "fly[[as in 'a fly']]" in
| messages.C is not needed at all.
And I don't think we should use that style of disambiguating the
phrases
Helge Hafting wrote:
> On Wed, Nov 09, 2005 at 09:21:25PM +0100, Georg Baum wrote:
>> This does only work if the original string is different, too, but in the
>> example above it is not.
>
> Are you sure?
Pretty sure. From
http://www.gnu.org/software/gettext/manual/html_chapter/gettext_7.html#S
On Wed, Nov 09, 2005 at 09:21:25PM +0100, Georg Baum wrote:
> Am Mittwoch, 9. November 2005 20:16 schrieb Helge Hafting:
[...]
> > It doesn't look like a big problem though. In cases where different
> shortcut
> > is needed, simply write "&Drucken" in the one case and "D&rucken" in the
> other c
Am Mittwoch, 9. November 2005 20:16 schrieb Helge Hafting:
> On Wed, Nov 09, 2005 at 03:11:25PM +0100, Georg Baum wrote:
> > Fictive example: The string "&Print" needs the translation "&Drucken"
in
> > xforms and "D&rucken" in qt.
> >
> > This string could be duplicated as follows, using the mach
On Wed, Nov 09, 2005 at 03:11:25PM +0100, Georg Baum wrote:
> Jean-Marc Lasgouttes wrote:
>
> > All of this is doable IMO. But a major problem I see is that
> > translators may need to use different shortcuts for a string in
> > different frontends. How do we make that possible?
>
> Fictive examp
Jean-Marc Lasgouttes wrote:
> Yes, but this means the translators would have to ask us to add tags
> everytime they have a special needs. And the french trnalsator will be
> surprised to see this duplicated string, since he does not know it was
> requested by the german translator...
True. Unfort
> "Bernhard" == Bernhard Reiter <[EMAIL PROTECTED]> writes:
Bernhard> what about |D&r_ucken (yielding |Drucken for xforms,
Bernhard> D&rucken for qt and Dr_ucken for gtk?) - if two or more
Bernhard> shortcuts are identical, omit their shortcut token, e.g.
Bernhard> |Speichern _unter... (Save a
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> The xforms sources would contain &Print[[xforms]], and the qt
Georg> sources would contain &Print[[qt]]. Of course we have a
Georg> duplicated string to translate, but this is not worse than the
Georg> current state.
Yes, but this mea
> Fictive example: The string "&Print" needs the translation "&Drucken" in
> xforms and "D&rucken" in qt.
>
> This string could be duplicated as follows, using the machinery for ambigous
> translations:
>
> originaltranslation
> &Print[[xforms]]&Drucken
> &Print[[qt]]D&ruc
> "John" == John C Spray <[EMAIL PROTECTED]> writes:
John> I disagree. Although there is a benefit to developers in having
John> relatively uniform frontends, it is more valuable to the user to
John> have whichever frontend they use fit in with their desktop
John> environment. As a trivial exa
Jean-Marc Lasgouttes wrote:
> All of this is doable IMO. But a major problem I see is that
> translators may need to use different shortcuts for a string in
> different frontends. How do we make that possible?
Fictive example: The string "&Print" needs the translation "&Drucken" in
xforms and "D&
On Wed, 2005-11-09 at 14:06 +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> >> More like 95%, if it weren't for the sad fact that qt and xforms
> >> have different syntax for specifying keyboard shortcuts.
>
> Martin> Is this fixable?
>
> Her
(Thanks to whoever did it for re-subscribing me to the dev list)
I'm making this last post to both lists and then will try to find the
time to look into things on the lyx-devel side.
As I alluded to before, NeXT/OPEN/GNUstep/Cocoa allows one to
dynamically add and remove language support from
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>> More like 95%, if it weren't for the sad fact that qt and xforms
>> have different syntax for specifying keyboard shortcuts.
Martin> Is this fixable?
Here is how I would do that:
1. change frontend::scex and frontend::idex to unde
On Wed, 2005-11-09 at 08:24 +0200, Martin Vermeer wrote:
> > The idea is that each frontend author is free to implement the dialogs
> > as he wants. There is no contraint on their layout and/or text.
>
> But that's a bug, not a feature, right? We _should_ strive for uniformity.
I disagree. Altho
Martin Vermeer wrote:
>> >I suspect 50% of the strings would turn out to be common.
>> More like 95%, if it weren't for the sad fact that
>> qt and xforms have different syntax for specifying keyboard
>> shortcuts.
> Is this fixable?
Sure. Given that XForms is now the junior partner, create a new
On Wed, Nov 09, 2005 at 11:35:04AM +0100, Helge Hafting wrote:
> Jean-Marc Lasgouttes wrote:
>
> >>"Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
> >>
> >>
> >Angus> It doesn't actually make anybody's life easier because the
> >Angus> different frontends do actually ha
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>> The idea is that each frontend author is free to implement the
>> dialogs as he wants. There is no contraint on their layout and/or
>> text.
Martin> But that's a bug, not a feature, right? We _should_ strive for
Martin> uniformity.
Jean-Marc Lasgouttes wrote:
"Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> It doesn't actually make anybody's life easier because the
Angus> different frontends do actually have subtly different dialogs
Angus> and messages.
I suspect 50% of the strings would turn out
On Tue, 08 Nov 2005 23:53:39 +0100 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
wrote:
> > "Alex" == Alex <[EMAIL PROTECTED]> writes:
>
> Alex> Why? The GUI indepence means same content, different look. Isn't
> Alex> it?
>
> The idea is that each frontend author is free to implement the dialog
> "Alex" == Alex <[EMAIL PROTECTED]> writes:
Alex> Why? The GUI indepence means same content, different look. Isn't
Alex> it?
The idea is that each frontend author is free to implement the dialogs
as he wants. There is no contraint on their layout and/or text.
JMarc
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> It doesn't actually make anybody's life easier because the
Angus> different frontends do actually have subtly different dialogs
Angus> and messages.
I suspect 50% of the strings would turn out to be common.
JMarc
Dear Angus & List,
>> Ingar>> As a translator I have to say that the number of toolkits
>> Ingar>> increase the amount of work for the translators as well.
>> JML> Note we could make an effort to change this: use the &shortcut
>> Is it possible to create a translation code internally, to handle
[EMAIL PROTECTED] wrote:
> Dear All,
>
> Ingar>> As a translator I have to say that the number of toolkits
> Ingar>> increase the amount of work for the translators as well.
> Ingar>> Different toolsets have different ways to specify shortcuts and
> Ingar>> each have to be translated manually.
>
Dear All,
Ingar>> As a translator I have to say that the number of toolkits
Ingar>> increase the amount of work for the translators as well.
Ingar>> Different toolsets have different ways to specify shortcuts and
Ingar>> each have to be translated manually.
JML> Note we could make an effort to ch
73 matches
Mail list logo
