I helped a friend upgrade his lyx 1.3.7 to 1.5.1, and waited for his
praises while he played with the new version
F: Where is the layout menu?
B: Was there a layout menu? Yes, I remember that. It is removed.
F: OK, but where does it go? Where is layout - bold?
B: Bold? Let me see no
On Fri, Sep 28, 2007 at 01:03:38AM -0500, Bo Peng wrote:
I helped a friend upgrade his lyx 1.3.7 to 1.5.1, and waited for his
praises while he played with the new version
snip
It's because nobody ever finished character styles. It should have gone
like this:
F: Where's bold?
B: Why do
Abdelrazak Younes wrote:
I'd strongly suggest that 1.5.2 not be released until this can be ported
there.
I am afraid that backporting the whole metrics/draw is too much work.
Too bad. Was that particular case in branch anyway?
Jürgen
Dov Feldstern wrote:
My previous patch handled the encoding --- I still think it should be
applied in full (I will send in an updated patch soon). Jurgen had said
he applied only those parts he understood, so I gather that the rest was
not understood well enough --- I will try to comment it
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I'd strongly suggest that 1.5.2 not be released until this can be ported
there.
I am afraid that backporting the whole metrics/draw is too much work.
Too bad. Was that particular case in branch anyway?
Maybe, one have to play with '-dbg
Richard Heck wrote:
Towards working on this slowness issue---is there some easy way to get
access to a high-precision timer, so I can toss a few statements into
various places in the code like this:
newTime = getTime();
lyxerr That took newTime - oldTime endl;
oldTime = newTime;
Abdelrazak Younes wrote:
Helge Hafting wrote:
Arrange one paragraph with 25 lines.
Type a string og W's in the next paragraph. The W's comes out with
great speed until this second paragraph needs to linewrap. The wrap
takes a long time, and then things continue at great speed. The
linewrap
Bennett Helm wrote:
On Sep 27, 2007, at 12:23 PM, Abdelrazak Younes wrote:
Bennett Helm wrote:
OK. Creating a math inset causes it to quit immediately, without
saving (without even an emergency save). There's nothing written to
the crash log, but the following appears in console.log:
Leuven, E. wrote:
Please report back if you see other oddities.
paragraph breaking is slower in trunk than in 1.5
if i load the userguide and break a paragraph there is a noticeable delay...
This is dues to the embedding stuff. The attached patch will help you.
Bo, could you please do
Bo Peng [EMAIL PROTECTED] writes:
I would guess there is a non-zero error code returned.
Then we can do the following.
1. check the return value of configure.py
2. Check the return status of the long LATEX configure run.
Looks good to me, and the worst that can happen seems to be missing
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I'd like to reformat the '-dbg painting' info so that they become a bit
more meaningful (in line with trunk), is that OK with you?
depends. Please post the patches.
Here it is.
Abdel.
Index: frontends/qt4/QLPainter.cpp
Leuven, E. wrote:
there is an issue with collapseables in trunk
open say a footnote and click inside it, and then outside. the workareas then
shifts
This is solved in latest trunk. Please report back if you see other
oddities.
Abdel.
Abdelrazak Younes wrote:
Helge Hafting wrote:
Arrange one paragraph with 25 lines.
Type a string og W's in the next paragraph. The W's comes out with
great speed until this second paragraph needs to linewrap. The wrap
takes a long time, and then things continue at great speed. The
linewrap
Dov Feldstern wrote:
Juergen Spitzmueller wrote:
Jean-Marc Lasgouttes wrote:
Juergen, could you tell me when setting local_font is necessary? I did
not see the problem when creating a new listing inset with caption.
The problem showed up when you created a listings inset with a caption
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I have backported this fix from trunk. It is safe IMO and should go in
1.5.2.
OK.
Done.
Abdel.
Hi,
I wanted to test a new he.po file, but since compiling it with today's svn
and installing I can't make it work. It is probably something that I changed
in the .po file in the last week. When trying to launch LyX the following
error appears:
Assertion triggered in const std::string
John Levon wrote:
On Fri, Sep 28, 2007 at 01:03:38AM -0500, Bo Peng wrote:
I helped a friend upgrade his lyx 1.3.7 to 1.5.1, and waited for his
praises while he played with the new version
It's because nobody ever finished character styles. It should have gone
like this:
F:
Jürgen Spitzmüller wrote:
Richard Heck wrote:
Don't have current branch here to test (yet).
Create a new file.
Enter some text. InsertNoteLyXNote. Exit the inset. Backspace.
Segfault.
Cannot reproduce with 1.5svn. Just to make sure: how do you exit? To the
right? With the mouse or
Don't have current branch here to test (yet).
Create a new file.
Enter some text. InsertNoteLyXNote. Exit the inset. Backspace.
Segfault.
Richard
Hans Meine wrote:
Am Freitag, 28. September 2007 09:28:53 schrieb Abdelrazak Younes:
Richard Heck wrote:
Towards working on this slowness issue---is there some easy way to get
access to a high-precision timer, so I can toss a few statements into
various places in the code like this:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Here it is.
OK.
And done.
FYI, I have another inset drawing optimization in the pipe.
Abdel.
Abdelrazak Younes wrote:
I have backported this fix from trunk. It is safe IMO and should go in
1.5.2.
OK.
Jürgen
Abdelrazak Younes [EMAIL PROTECTED] writes:
Too bad for those using 4.1... I'll enclose the session code between
#ifdef, sorry about that.
That's OK with me.
JMarc
Abdelrazak Younes [EMAIL PROTECTED] writes:
That's a good idea actually (IMHO). Now shout me you LateX experts :-)
Each of these things should be done by the proper latex style (there
are several) and is specific for e.g. sections. It shall therefore be
done in document settings. Making this
Helge Hafting [EMAIL PROTECTED] writes:
What should a UI look like? Minimize confusion by
making it consistent with the rest of the app, and preferably
quite a few other apps as well. Make exceptions only when
there is a reason, but don't be afraid in those cases.
+1
JMarc
Depends on what you mean. it's also bad
yeah, that's what i meant
Ideally we'd like to redraw on the inset button and nothing
else. We may achieve this goal before 1.6 with a bit more of cleanup.
ok
Abdelrazak Younes wrote:
Richard Heck wrote:
Towards working on this slowness issue---is there some easy way to
get access to a high-precision timer, so I can toss a few statements
into various places in the code like this:
newTime = getTime();
lyxerr That took newTime - oldTime
Richard Heck wrote:
Don't have current branch here to test (yet).
Create a new file.
Enter some text. InsertNoteLyXNote. Exit the inset. Backspace.
Segfault.
Cannot reproduce with 1.5svn. Just to make sure: how do you exit? To the
right? With the mouse or with keyboard?
Jürgen
On Friday 28 September 2007 11:13:04 Uwe Stöhr wrote:
No, it's only an UI and LaTeX-output change.
Will the current output be equivalent to the previous? Starting from the
same document, of course.
regards Uwe
--
José Abílio
Abdelrazak Younes wrote:
Here it is.
OK.
Jürgen
On Fri, Sep 28, 2007 at 11:47:58AM +0200, Leuven, E. wrote:
Please report back if you see other oddities.
paragraph breaking is slower in trunk than in 1.5
We recently also had a updateLabel() creep. By now there are 38
instances of updateLabels() in the code. This somehow does not
sound
Edwin Leuven wrote:
needs a restart to take effect
this is still the case
Hi Juergen,
I have backported this fix from trunk. It is safe IMO and should go in
1.5.2.
Abdel.
Index: BufferView.cpp
===
--- BufferView.cpp (revision 20564)
+++ BufferView.cpp (working copy)
@@ -1482,13 +1482,19 @@
Andre Poenitz [EMAIL PROTECTED] writes:
Right. Especially with focus-follows-mouse and/or autoraise.
Autoraise is asking for trouble anyway.
JMarc
Bo, could you please do something about that?
I have no time to fix this now so disabling it is fine to me.
Bo
+lots---though, that said, there are times you just need a bit of boldface.
It is easy enough for latex people to do \textbf{}. Why do we
discourage the use of it??
Bo
Leuven, E. wrote:
when i hover a collapsable i see
{111}[110]
is this good or bad?
Depends on what you mean. It is good because it is what's expected (the
whole screen is redrawn on mouse hover) but it's also bad because of
that. Ideally we'd like to redraw on the inset button and nothing
Tommaso Cucinotta wrote:
Abdelrazak Younes ha scritto:
Wether docked or dialogged, may I suggest having another checkbox
out there saying something like Automatically update style, personally
to be preferenced as checked by default ?
If I understood you correctly this is already done by the new
Jürgen Spitzmüller wrote:
I think we are basically ready (the one remaining bug I wanted to have fixed,
2178, did not get enough attention and thus will be postponed).
I'd like to release 1.5.2 next week. My plan is to set up the tarball on
Tuesday and beg you to test it on various systems
Does this implies any file format change? :-)
No, it's only an UI and LaTeX-output change.
regards Uwe
Helge Hafting wrote:
Abdelrazak Younes wrote:
Helge Hafting wrote:
Arrange one paragraph with 25 lines.
Type a string og W's in the next paragraph. The W's comes out with
great speed until this second paragraph needs to linewrap. The wrap
takes a long time, and then things continue at great
Abdelrazak Younes ha scritto:
Wether docked or dialogged, may I suggest having another checkbox
out there saying something like Automatically update style, personally
to be preferenced as checked by default ?
If I understood you correctly this is already done by the new
Immediate Apply check
Please report back if you see other oddities.
paragraph breaking is slower in trunk than in 1.5
if i load the userguide and break a paragraph there is a noticeable delay...
Pavel Sanda wrote:
hi,
1. open new document.
2. keep one key pressed until the whole page is filled
by the given char and next page is scrolled.
3. try to select block of text via shift+up arrow
4. the whole text except the last line of paragraph disappears.
anybodu can confirm ?
I can't
Andre Poenitz wrote:
On Thu, Sep 27, 2007 at 10:47:15AM +0200, Jean-Marc Lasgouttes wrote:
Face it, an undocked window is not a dialog, but a second class window,
palette-like with a smallish greyish title bar. I don't like them
(which is my prerogative).
It looks the way we want it
Dov Feldstern wrote:
Abdelrazak Younes wrote:
Dov Feldstern wrote:
Hi!
I have a cursor inside an inset. How can I easily get to the
paragraph containing this inset? What I really want is to get to the
character which represents the inset I'm in, so that I can get its font.
If you have
Abdelrazak Younes wrote:
Dov Feldstern wrote:
Hi!
I have a cursor inside an inset. How can I easily get to the paragraph
containing this inset? What I really want is to get to the character
which represents the inset I'm in, so that I can get its font.
If you have access to the Cursor this
Am Freitag, 28. September 2007 09:28:53 schrieb Abdelrazak Younes:
Richard Heck wrote:
Towards working on this slowness issue---is there some easy way to get
access to a high-precision timer, so I can toss a few statements into
various places in the code like this:
newTime = getTime();
Hi!
I have a cursor inside an inset. How can I easily get to the paragraph
containing this inset? What I really want is to get to the character
which represents the inset I'm in, so that I can get its font.
Thanks!
Dov
Dov Feldstern wrote:
Hi!
I have a cursor inside an inset. How can I easily get to the paragraph
containing this inset? What I really want is to get to the character
which represents the inset I'm in, so that I can get its font.
If you have access to the Cursor this information is in the
I think we are basically ready (the one remaining bug I wanted to have fixed,
2178, did not get enough attention and thus will be postponed).
I'd like to release 1.5.2 next week. My plan is to set up the tarball on
Tuesday and beg you to test it on various systems until Friday. This will
i really don't like this direct apply
it also gives nasty results when i put line spacing to custom: it
assumes zero and the text becomes garbled
Abdelrazak Younes wrote:
Exactly :-)
More seriously, I've cleaned up the design quite a quite now and I
think some of these optimizations should be possible now. You are
welcome to give me a hand ;-)
Optimizing drawing would surely be interesting - if I can find
enough contigous free time.
On Fri, Sep 28, 2007 at 01:52:54PM +0200, Jean-Marc Lasgouttes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
Right. Especially with focus-follows-mouse and/or autoraise.
Autoraise is asking for trouble anyway.
It has been working for me for 15 years and I fail to see why it
suddenly
Abdelrazak Younes wrote:
Helge Hafting wrote:
Arrange one paragraph with 25 lines.
Type a string og W's in the next paragraph. The W's comes out with
great speed until this second paragraph needs to linewrap. The wrap
takes a long time, and then things continue at great speed. The
linewrap
On Fri, Sep 28, 2007 at 09:28:53AM +0200, Abdelrazak Younes wrote:
Richard Heck wrote:
Towards working on this slowness issue---is there some easy way to get
access to a high-precision timer, so I can toss a few statements into
various places in the code like this:
newTime = getTime();
Abdelrazak Younes wrote:
Pavel Sanda wrote:
hi,
1. open new document.
2. keep one key pressed until the whole page is filled
by the given char and next page is scrolled.
3. try to select block of text via shift+up arrow
4. the whole text except the last line of paragraph disappears.
This is dues to the embedding stuff. The attached patch will help you.
much better, thanks
Abdelrazak Younes wrote:
I'd like to reformat the '-dbg painting' info so that they become a bit
more meaningful (in line with trunk), is that OK with you?
depends. Please post the patches.
Jürgen
when i hover a collapsable i see
{111}[110]
is this good or bad?
On Fri, Sep 28, 2007 at 02:16:40PM -0400, Richard Heck wrote:
Well, as I understand it, LyX is supposed to be a semantic text
processor. That's certainly where John's comment was coming from, and
mine. But people are not accustomed to thinking about writing that way,
in large part because
On Freitag 28 September 2007, Andre Poenitz wrote:
On Fri, Sep 28, 2007 at 09:28:53AM +0200, Abdelrazak Younes wrote:
Richard Heck wrote:
Towards working on this slowness issue---is there some easy way to get
access to a high-precision timer, so I can toss a few statements into
various
Bo Peng wrote:
+lots---though, that said, there are times you just need a bit of boldface.
It is easy enough for latex people to do \textbf{}. Why do we
discourage the use of it??
Well, as I understand it, LyX is supposed to be a semantic text
processor. That's certainly where John's
Well, as I understand it, LyX is supposed to be a semantic text
processor. That's certainly where John's comment was coming from, and
mine. But people are not accustomed to thinking about writing that way,
in large part because standard word processors don't encourage it. So,
the thought
On Fri, Sep 28, 2007 at 07:25:29PM +0100, John Levon wrote:
We make it kind of difficult to let them be encouraged. If LyX were to
An old discussion people might find interesting:
http://marc.info/?l=lyx-develm=104974730920332w=2
I accidentally made the mockup 404 though.
(From the days when
On Fri, Sep 28, 2007 at 01:35:49PM -0500, Bo Peng wrote:
But before text style becomes useful, shouldnot we put bold
buttons/menu items back? It is frustrating for new users that this
IMHO, yes, but let's not make it difficult to remove again.
john
I'm still experimenting. But here's something I did notice:
if (singleParUpdate) {
// Inserting characters does not change par height
ParagraphMetrics const pms
= cur.bv().parMetrics(cur.bottom().text(), cur.bottom().pit());
if (pms.dim().height()
John Levon wrote:
Some time ago I posted a list of the big ticket items missing from LyX.
I think that character styles is basically the only thing left that's
truly crucial
What precisely do you think is missing in the present implementation?
Not that I think it's complete. I just want to
Jurgen:
Would you agree to add following menu items (bold, emph, underline,
code) and toolbar icon (bold) to 1.5.2?
John and Richard agree with this change. Basically speaking, although
we should encourage the use of the text layouts, we should not
deprive users from these simple, frequently
Bo Peng wrote:
+ Item Toogle Bold|B font-bold
+ Item Toogle Emphasize|E font-emph
+ Item Toogle Underline|n font-underline
+ Item Toogle Code|o font-code
either Google or Toggle i'd suggest ;-)
Bo Peng wrote:
Well, as I understand it, LyX is supposed to be a semantic text
processor. That's certainly where John's comment was coming from, and
mine. But people are not accustomed to thinking about writing that way,
in large part because standard word processors don't encourage it. So,
the
On 9/28/07, Edwin Leuven [EMAIL PROTECTED] wrote:
Bo Peng wrote:
+ Item Toogle Bold|B font-bold
+ Item Toogle Emphasize|E font-emph
+ Item Toogle Underline|n font-underline
+ Item Toogle Code|o font-code
either Google or Toggle i'd suggest
On Fri, Sep 28, 2007 at 03:05:31PM -0400, Richard Heck wrote:
John Levon wrote:
Some time ago I posted a list of the big ticket items missing from LyX.
I think that character styles is basically the only thing left that's
truly crucial
What precisely do you think is missing in the
On Fri, Sep 28, 2007 at 02:20:39PM -0500, Bo Peng wrote:
John and Richard agree with this change. Basically speaking, although
we should encourage the use of the text layouts, we should not
deprive users from these simple, frequently used, functions. It should
be a user's choice what to use.
Here's what I've found. The time is all being spent in
Toolbars::update(). For some reason I haven't yet figured out---I have
to go to a lecture---we're taking forever there when we have an external
selection. It can take as long as 120ms (wall time, but that's what the
user sees) to get
Edwin Leuven wrote:
i really don't like this direct apply
Would you prefer that it is unchecked by default? I'm OK with that. I
can put the last chosen state in the session so that everyone is happy.
it also gives nasty results when i put line spacing to custom: it
assumes zero and the
Richard Heck wrote:
I'm still experimenting. But here's something I did notice:
if (singleParUpdate) {
// Inserting characters does not change par height
ParagraphMetrics const pms
= cur.bv().parMetrics(cur.bottom().text(), cur.bottom().pit());
if
OK, thanks for explaining. If it matters, see below
Abdelrazak Younes wrote:
Richard Heck wrote:
I'm still experimenting. But here's something I did notice:
if (singleParUpdate) {
// Inserting characters does not change par height
ParagraphMetrics const pms
=
Richard Heck wrote:
Here's what I've found. The time is all being spent in
Toolbars::update(). For some reason I haven't yet figured out---I have
to go to a lecture---we're taking forever there when we have an external
selection. It can take as long as 120ms (wall time, but that's what the
Abdelrazak Younes wrote:
Edwin Leuven wrote:
i really don't like this direct apply
Would you prefer that it is unchecked by default? I'm OK with that. I
can put the last chosen state in the session so that everyone is happy.
yes please
it also gives nasty results when i put line spacing
Abdelrazak Younes wrote:
I can't reproduce the selection problem (because I'm not on X11) but
could you please apply this patch and report if the slowness problem
still persist?
I'll try this tonight. I've been guessing that this had something to do
with the code that got introduced to solve
Jean-Marc, would that be the right patch?
Andre'
Index: lyxinclude.m4
===
--- lyxinclude.m4 (revision 20359)
+++ lyxinclude.m4 (working copy)
@@ -216,7 +216,7 @@
AC_ARG_ENABLE(pch,
Juergen,
This patch back port the look and feel of text insets from trunk:
multi-rows or multi-paragraph Text will be automatically expanded to the
full width. This has two main benefits:
1) It optimize drawing in non-wide insets.
2) It gets rid of the wide() hack.
It works well and I've
Abdelrazak Younes wrote:
Juergen,
This patch back port the look and feel of text insets from trunk:
multi-rows or multi-paragraph Text will be automatically expanded to the
full width. This has two main benefits:
1) It optimize drawing in non-wide insets.
2) It gets rid of the wide() hack.
Edwin Leuven wrote:
Abdelrazak Younes wrote:
Edwin Leuven wrote:
i really don't like this direct apply
Would you prefer that it is unchecked by default? I'm OK with that. I
can put the last chosen state in the session so that everyone is happy.
yes please
OK.
it also gives nasty
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Juergen,
This patch back port the look and feel of text insets from trunk:
multi-rows or multi-paragraph Text will be automatically expanded to
the full width. This has two main benefits:
1) It optimize drawing in non-wide insets.
2) It
I helped a friend upgrade his lyx 1.3.7 to 1.5.1, and waited for his
praises while he played with the new version
F: Where is the layout menu?
B: Was there a layout menu? Yes, I remember that. It is removed.
F: OK, but where does it go? Where is layout -> bold?
B: Bold? Let me see no
On Fri, Sep 28, 2007 at 01:03:38AM -0500, Bo Peng wrote:
> I helped a friend upgrade his lyx 1.3.7 to 1.5.1, and waited for his
> praises while he played with the new version
It's because nobody ever finished character styles. It should have gone
like this:
F: Where's bold?
B: Why do you
Abdelrazak Younes wrote:
> > I'd strongly suggest that 1.5.2 not be released until this can be ported
> > there.
>
> I am afraid that backporting the whole metrics/draw is too much work.
Too bad. Was that particular case in branch anyway?
Jürgen
Dov Feldstern wrote:
> My previous patch handled the encoding --- I still think it should be
> applied in full (I will send in an updated patch soon). Jurgen had said
> he applied only those parts he understood, so I gather that the rest was
> not understood well enough --- I will try to comment
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I'd strongly suggest that 1.5.2 not be released until this can be ported
there.
I am afraid that backporting the whole metrics/draw is too much work.
Too bad. Was that particular case in branch anyway?
Maybe, one have to play with '-dbg
Richard Heck wrote:
Towards working on this slowness issue---is there some easy way to get
access to a high-precision timer, so I can toss a few statements into
various places in the code like this:
newTime = getTime();
lyxerr << "That took " << newTime - oldTime << endl;
oldTime =
Abdelrazak Younes wrote:
Helge Hafting wrote:
Arrange one paragraph with 25 lines.
Type a string og W's in the next paragraph. The W's comes out with
great speed until this second paragraph needs to linewrap. The wrap
takes a "long" time, and then things continue at great speed. The
linewrap
Bennett Helm wrote:
On Sep 27, 2007, at 12:23 PM, Abdelrazak Younes wrote:
Bennett Helm wrote:
OK. Creating a math inset causes it to quit immediately, without
saving (without even an emergency save). There's nothing written to
the crash log, but the following appears in console.log:
Leuven, E. wrote:
Please report back if you see other oddities.
paragraph breaking is slower in trunk than in 1.5
if i load the userguide and break a paragraph there is a noticeable delay...
This is dues to the embedding stuff. The attached patch will help you.
Bo, could you please do
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> I would guess there is a non-zero error code returned.
>
> Then we can do the following.
>
> 1. check the return value of configure.py
> 2. Check the return status of the long LATEX configure run.
Looks good to me, and the worst that can happen seems to
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I'd like to reformat the '-dbg painting' info so that they become a bit
more meaningful (in line with trunk), is that OK with you?
depends. Please post the patches.
Here it is.
Abdel.
Index: frontends/qt4/QLPainter.cpp
Leuven, E. wrote:
there is an issue with collapseables in trunk
open say a footnote and click inside it, and then outside. the workareas then
shifts
This is solved in latest trunk. Please report back if you see other
oddities.
Abdel.
Abdelrazak Younes wrote:
Helge Hafting wrote:
Arrange one paragraph with 25 lines.
Type a string og W's in the next paragraph. The W's comes out with
great speed until this second paragraph needs to linewrap. The wrap
takes a "long" time, and then things continue at great speed. The
linewrap
Dov Feldstern wrote:
Juergen Spitzmueller wrote:
Jean-Marc Lasgouttes wrote:
Juergen, could you tell me when setting local_font is necessary? I did
not see the problem when creating a new listing inset with caption.
The problem showed up when you created a listings inset with a caption
1 - 100 of 172 matches
Mail list logo
