Pavel Sanda wrote:
> you are right. feel free to change it the way you like and commit it.
Uwe, OK to xommit the attached?
Jürgen
Index: lib/doc/EmbeddedObjects.lyx
===
--- lib/doc/EmbeddedObjects.lyx (Revision 19077)
+++ lib/doc/Emb
Jürgen Spitzmüller wrote:
Uwe Stöhr wrote:
I'm awaiting the final LyX 1.5.0 release. I usually check bugzilla daily
and think the only missing problems are lyx2lyx bugs.
+ Dov's patches.
And my two crash-fixing patches.
Abdel.
Uwe Stöhr wrote:
> I'm awaiting the final LyX 1.5.0 release. I usually check bugzilla daily
> and think the only missing problems are lyx2lyx bugs.
+ Dov's patches.
Jürgen
Hello LyXers,
I haven't found the time to follow the devel-list the last days, so somebody might have posted
something similar.
I'm awaiting the final LyX 1.5.0 release. I usually check bugzilla daily and think the only missing
problems are lyx2lyx bugs. Anders worked hard the last days with
Hi!
Here I will try to explain my understanding of the issues leading to
bugs 1820 and 3613. This is partly because I feel that it's important
that as many people as possible be aware of these, for future
development; partly in order to explain the patches I'm proposing for
these two bugs, so
Le 12 juil. 07 à 16:10, Richard Heck a écrit :
Go ahead and file the enhancement bug with a note pointing to this
thread. We can sort out the details later.
Done: bug #4022.
Mael.
Martin Vermeer wrote:
On Sun, Jul 15, 2007 at 09:59:32AM -0400, Paul A. Rubin wrote:
Hi,
Before I put this is in as an enhancement request, I wanted to make sure it
doesn't already exist. I know you can define counters in a layout function.
Is there a mechanism to specify, say when defi
Dov Feldstern wrote:
Dov Feldstern wrote:
Hi!
Attached find a patch for the last remaining problem with bug 3613.
It's a format change. The problem it solves is due to some missed
cases way back in format change 249.
I'm attaching example files which demonstrate the problem (and which
this
Dov Feldstern wrote:
Hi!
Attached find a patch for the last remaining problem with bug 3613. It's
a format change. The problem it solves is due to some missed cases way
back in format change 249.
I'm attaching example files which demonstrate the problem (and which
this patch fixes).
There
Jürgen Spitzmüller schrieb:
1.5.2: T2=T1+2/3month, feature release, big patch and cleanup allowed
Probably yes. Depends on what remains from the 1.5.1 bugfixing and what bug
reports we have. Main focus is _always_ on stability. New features should
therefore be very well tested and straig
Jürgen Spitzmüller schrieb:
Abdelrazak Younes wrote:
As soon as do some cleanups (like I've done in my mvc branch)
back-porting will get more and more complicated. Backporting will
require additional work whereas developing feature and doing cleanup
directly in the stable branch will not.
Hi!
Is there any way for me to only apply one of the stages if the original
format number of the file being converted was under 249?
The problem with my current patch for bug 3613 is this:
Files from pre-249 are wrong, but post-249 don't have the problem. So my
new stage (277) should only ru
>So how about something like
you are right. feel free to change it the way you like and commit it.
thanks
pavel
--- EmbeddedObjects.lyx 2007-07-03 12:55:59.0 +0200
+++ /trash/embed.lyx2007-07-15 18:04:12.0 +0200
@@ -28202,6 +28203,10 @@
\end_inset
is recognized and printe
Pavel Sanda wrote:
> listings manual advices LuxiMono fonts from CTAN. i've tried them and it
> works well. i think this will be asked more often - what about little
> update of our docs ?
Good idea. However,
> + If you don't have bold keywords when typewriter family of fonts is used,
> + you can
On Sun, Jul 15, 2007 at 09:59:32AM -0400, Paul A. Rubin wrote:
> Hi,
>
> Before I put this is in as an enhancement request, I wanted to make sure it
> doesn't already exist. I know you can define counters in a layout function.
> Is there a mechanism to specify, say when defining a section
>>> 3. Rather TeX question - when typewriter font family is set, keywords are
>>> no more bold (maybe it is not possible to typeset this font in bold,
>>> dunno)
>>
>> This is quite likely.
>
> You have to use a typewriter font that actually provides bold faces.
listings manual advices LuxiMono fo
Paul A. Rubin wrote:
Hi,
Before I put this is in as an enhancement request, I wanted to make
sure it doesn't already exist. I know you can define counters in a
layout function. Is there a mechanism to specify, say when defining a
section style, that certain counters get reset at the start o
Bo Peng wrote:
> > No. Why do you think new features cannot go into the stable series?
>
> Maybe I am wrong, but in general the stable series do not allow format
> changes. That is to say, 1.5.0 should be able to read all files
> generated by 1.5.x.
I didn't state anything different. However, not
No. Why do you think new features cannot go into the stable series?
Maybe I am wrong, but in general the stable series do not allow format
changes. That is to say, 1.5.0 should be able to read all files
generated by 1.5.x.
Cheers,
Bo
Sven Hoexter wrote:
On Sun, Jul 15, 2007 at 12:08:13PM +0200, Peter Kümmel wrote:
Hi,
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove BugfixSignal, and
create the signal at runtime. But we then have to clean up correc
Hi,
Before I put this is in as an enhancement request, I wanted to make sure
it doesn't already exist. I know you can define counters in a layout
function. Is there a mechanism to specify, say when defining a section
style, that certain counters get reset at the start of the section? If
no
On Sun, Jul 15, 2007 at 12:08:13PM +0200, Peter Kümmel wrote:
Hi,
> Yes, this could be. We should simply NOT use the static solution.
> Does attached patch work on Debian? If yes we could remove BugfixSignal, and
> create the signal at runtime. But we then have to clean up correctly.
Ok I tried y
Roger Mc Murtrie wrote:
Is there any relationship between this problem and Bug 4014, Comment 16
due to some changes in boost?
I don't think so.
Abdel.
Jürgen Spitzmüller wrote:
effort (but that's exactly the point where our opinions differ).
Exactly ;-)
Abdel.
Abdelrazak Younes wrote:
> As soon as do some cleanups (like I've done in my mvc branch)
> back-porting will get more and more complicated. Backporting will
> require additional work whereas developing feature and doing cleanup
> directly in the stable branch will not.
I see your point, but IMHO a
Abdelrazak Younes wrote:
Hum, maybe the problem is in our side and not boost. This comment and
code in frontends/Dialogs.cpp seems suspicious to me:
// Note that static boost signals break some compilers, so this wrapper
// initialises the signal dynamically when it is first invoked.
templa
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Why that?
Why that what? You think that 1.6 will come in less than a year?
No. Why do you think new features cannot go into the stable series? As I've
outlined, I'm very open to backporting features that are tested and
straightforward (at l
Abdelrazak Younes wrote:
> > Why that?
>
> Why that what? You think that 1.6 will come in less than a year?
No. Why do you think new features cannot go into the stable series? As I've
outlined, I'm very open to backporting features that are tested and
straightforward (at least after 1.5.1). This
Abdelrazak Younes wrote:
The only solution is just to get rid of this BugfixSignal. Actually,
this hideSignal is not needed at all!
Something like the attached. I guess this signal was needed at some
point but not anymore.
Updated patch attached.
Abdel.
Index: frontends/Dialogs.cpp
===
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
In the current scheme new feature will have to wait one year minimum
before going to the public. In my proposed scheme new feature will be
available every 3 month.
Why that?
Why that what? You think that 1.6 will come in less than a year?
A
Abdelrazak Younes wrote:
> In the current scheme new feature will have to wait one year minimum
> before going to the public. In my proposed scheme new feature will be
> available every 3 month.
Why that?
Jürgen
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create th
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create the signal at runtime. But w
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create the signal at runtime. But we then have to clean up co
Peter Kümmel wrote:
> Abdelrazak Younes wrote:
>> Peter Kümmel wrote:
>>> Abdelrazak Younes wrote:
Peter Kümmel wrote:
> Yes, this could be. We should simply NOT use the static solution.
> Does attached patch work on Debian? If yes we could remove
> BugfixSignal, and
> create t
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> Abdelrazak Younes wrote:
>>> Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create the signal at runtime. But we
Hi,
I would love to have frontend support for \cancel{} which strikes out
parts in a formula as provided by cancel.sty. Looking at the svn it
seems to be pretty analog to e.g. implementing \sqrt{}. So I would like
to try this myself. I have c programming experience but no c++. Also it
looks as I
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove
BugfixSignal, and
create the signal at runtime. But we then have to clean up correctly.
Your solution wi
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I don't see the advantage of this. I'd rather do a 1.5.x branch and let
people do some more adventourous development (or new features) in trunk.
I am thinking of GUI development. Dialogs, context menu, etc...
I don't see why this cannot happe
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>>
>> Yes, this could be. We should simply NOT use the static solution.
>> Does attached patch work on Debian? If yes we could remove
>> BugfixSignal, and
>> create the signal at runtime. But we then have to clean up correctly.
>
> Your solution will
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>>
>> Yes, this could be. We should simply NOT use the static solution.
>> Does attached patch work on Debian? If yes we could remove
>> BugfixSignal, and
>> create the signal at runtime. But we then have to clean up correctly.
>
> Your solution will
Abdelrazak Younes wrote:
> > I don't see the advantage of this. I'd rather do a 1.5.x branch and let
> > people do some more adventourous development (or new features) in trunk.
>
> I am thinking of GUI development. Dialogs, context menu, etc...
I don't see why this cannot happen in the current sc
Peter Kümmel wrote:
Yes, this could be. We should simply NOT use the static solution.
Does attached patch work on Debian? If yes we could remove BugfixSignal, and
create the signal at runtime. But we then have to clean up correctly.
Your solution will only work with the first instance...
Abde
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Dov Feldstern wrote:
We create the 1.5.x branch *now*, but don't release yet.
That depends on how Juergen will manage the "stable" series. I
personally would like that we continue trunk development on the 1.5
series instead of opening a new 1
Abdelrazak Younes wrote:
> Hum, maybe the problem is in our side and not boost. This comment and
> code in frontends/Dialogs.cpp seems suspicious to me:
Yes, once again a static variable.
>
> // Note that static boost signals break some compilers, so this wrapper
> // initialises the signal dy
Abdelrazak Younes wrote:
> Abdelrazak Younes wrote:
>> Peter Kümmel wrote:
>>> Maybe someone has an idea:
>>>
>>> 74 LyXView::LyXView(int id)
>>> 75 : work_area_(0),
>>> 76 toolbars_(new Toolbars(*this)),
>>> 77 autosave_timeout_(new Timeout(5000)),
>>> 7
Abdelrazak Younes wrote:
> Hum, maybe the problem is in our side and not boost. This comment and
> code in frontends/Dialogs.cpp seems suspicious to me:
Yes, once again a static variable.
>
> // Note that static boost signals break some compilers, so this wrapper
> // initialises the signal dyna
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Maybe someone has an idea:
74 LyXView::LyXView(int id)
75 : work_area_(0),
76 toolbars_(new Toolbars(*this)),
77 autosave_timeout_(new Timeout(5000)),
78 dialogs_(new Dialogs(*this)),
79
Abdelrazak Younes wrote:
> Dov Feldstern wrote:
> > We create the 1.5.x branch *now*, but don't release yet.
>
> That depends on how Juergen will manage the "stable" series. I
> personally would like that we continue trunk development on the 1.5
> series instead of opening a new 1.5.x branch. I wo
Peter Kümmel wrote:
Maybe someone has an idea:
74 LyXView::LyXView(int id)
75 : work_area_(0),
76toolbars_(new Toolbars(*this)),
77autosave_timeout_(new Timeout(5000)),
78dialogs_(new Dialogs(*this)),
79controlcomm
On Sun, Jul 15, 2007 at 11:19:50AM +0200, Abdelrazak Younes wrote:
> Dov Feldstern wrote:
> > We create the 1.5.x branch *now*, but don't release yet.
>
> That depends on how Juergen will manage the "stable" series. I personally
> would like that we continue trunk development on the 1.5 series
On Sun, Jul 15, 2007 at 03:18:35AM +0300, Dov Feldstern wrote:
> Joost Verburg wrote:
> > Abdelrazak Younes wrote:
> >> Quite frankly, as there is no format change and that this needs some more
> >> testing, I'd prefer that you wait for 1.5.1 which will hopefully happen
> >> very soon. Just look
Sven Hoexter wrote:
> On Sun, Jul 15, 2007 at 10:18:03AM +0200, Peter Kümmel wrote:
>> Sven Hoexter wrote:
>>> Hi,
>>> while preparing a Debian package for the upcoming 1.5 release I've
>>> experienced a huge performance problem with 1.5rc1. Now I tried to find a
>>> reason and had to find out that
Dov Feldstern wrote:
We create the 1.5.x branch *now*, but don't release yet.
That depends on how Juergen will manage the "stable" series. I
personally would like that we continue trunk development on the 1.5
series instead of opening a new 1.5.x branch. I would like to propose
that we alt
On Sun, Jul 15, 2007 at 10:18:03AM +0200, Peter Kümmel wrote:
> Sven Hoexter wrote:
> > Hi,
> > while preparing a Debian package for the upcoming 1.5 release I've
> > experienced a huge performance problem with 1.5rc1. Now I tried to find a
> > reason and had to find out that the current trunk will
Bo Peng wrote:
This patch properly shut down what's needed to avoid the crashes.
OK?
I do not know this part of the code so you decide. Also, I did not use
multi-view when I had the crashes.
I suppose it depends on the machine and on when the statusbar timer was
timed out.
Anyway, this pa
Sven Hoexter wrote:
> Hi,
> while preparing a Debian package for the upcoming 1.5 release I've
> experienced a huge performance problem with 1.5rc1. Now I tried to find a
> reason and had to find out that the current trunk will segfault when I build
> it with the boost libs provided in the Debian a
57 matches
Mail list logo
