On Mon, Mar 22, 2004 at 10:00:22PM +, Angus Leeming wrote:
> > We only need to reap children every 10 minutes or whatever
>
> Then we go back to the timer and the whole thing has been a waste of
> time?
Why do you say that? It's completely normal and expected practice.
> It is trivially ea
Ok, this code should be able to handle multiple simultaneaous SIGCHLD
signals safely and no cycles are wasted in a busy GUI loop. In fact
things will just work automagically even if there is *no* GUI loop.
Of course, Win32 users are stuffed ;-)
--
Angus? src/support/lyxlib-orig.C
? src/support
John Levon wrote:
> On Mon, Mar 22, 2004 at 06:54:15PM +, Angus Leeming wrote:
>
>> It turns out that QEventLoop exists only for Qt >= 3.1. I'm running
>> RH8 here (Qt 3.0.5). For Qt < 3.1, the trick seems to be to use a
>> QTimer with 0 timeout. That *does* work.
>
> Excuse me if I'm misund
On Mon, Mar 22, 2004 at 06:54:15PM +, Angus Leeming wrote:
> It turns out that QEventLoop exists only for Qt >= 3.1. I'm running
> RH8 here (Qt 3.0.5). For Qt < 3.1, the trick seems to be to use a
> QTimer with 0 timeout. That *does* work.
Excuse me if I'm misunderstanding, is this going to
Kuba Ober wrote:
>> The xforms event loop in my tree now looks like:
>>
>> while (!finished) {
>> ForkedcallsController::get().handleCompletedProcesses();
>> if (fl_check_forms() == FL_EVENT) {
>> ...
>> }
>> }
>>
>> where handleCompletedProcesses() simp
Jean-Marc Lasgouttes wrote:
> > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>
> Georg> No, I did not explain it in detail. The problem is that
> Georg> includedFilename(), that gets called by loadIfNeeded() with the
> Georg> buffer that originally came from LaTeXFeatures, returns in some
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> No, I did not explain it in detail. The problem is that
Georg> includedFilename(), that gets called by loadIfNeeded() with the
Georg> buffer that originally came from LaTeXFeatures, returns in some
Georg> cases a wrong filename for rel
Jean-Marc Lasgouttes wrote:
>> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
> Georg> The problem now is that loadIfNeeded() is called with that
> Georg> buffer, but it really needs the buffer of the file that
> Georg> contains the inset.
>
> Why? From the code, I do not see what problem
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> When splitting the initial paragraph in UserGuide20 (i.e. 20
Andre> copies of the UserGuide concatenated) we spend 76% of the time
Andre> in
Andre> [17] 76.0 0.06 30.41 1659902
Andre> ShareContainer::get(ParameterStruct const&)
And
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> LaTeXFeatures::buffer_ is in fact the master buffer, because it
Georg> is a reference that is set in the constructor.
Yes.
Georg> The problem now is that loadIfNeeded() is called with that
Georg> buffer, but it really needs the buff
> "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes:
Kayvan> I want to Insert->File->ASCII as Lines, but this option is
Kayvan> grayed out along with "LyX Document" and "Ascii as
Kayvan> paragraphs".
This is cured by the following patch.
Andre', this patch also cures the handling of rea
> "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes:
Kayvan> Here is a cleanup fix
Applied.
JMarc
> The xforms event loop in my tree now looks like:
>
> while (!finished) {
> ForkedcallsController::get().handleCompletedProcesses();
> if (fl_check_forms() == FL_EVENT) {
> ...
> }
> }
>
> where handleCompletedProcesses() simply checks whether a SIGCHLD
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Martin Vermeer wrote:
>> On Mon, Mar 22, 2004 at 09:12:56AM +, Angus Leeming spake
>> thusly:
>>
>>> > > Should this be made more clearly a warning or info message?
>>> Like > "... Color \"" << lyxname << '"' added to color tab
Martin Vermeer wrote:
> On Mon, Mar 22, 2004 at 09:12:56AM +, Angus Leeming spake
> thusly:
>
>> >
>> > Should this be made more clearly a warning or info message? Like
>> > "... Color \"" << lyxname << '"' added to color table" << endl ?
>>
>> Yes. That is exactly what the code is doing, a
On Mon, Mar 22, 2004 at 09:12:56AM +, Angus Leeming spake thusly:
> >
> > Should this be made more clearly a warning or info message? Like
> > "... Color \"" << lyxname << '"' added to color table" << endl ?
>
> Yes. That is exactly what the code is doing, after all. Moreover, I
> think tha
The following patches add proper detection of gsview and acroread on
windows (bug 1508).
Additionally, the 1.4.0 version gets rid of the \ps_command lyxrc
variable, which has not been used since the demise of the figinset.
I will apply them shortly.
JMarc
Index: lib/ChangeLog
=
On Mon, 22 Mar 2004, Angus Leeming wrote:
> Things have changed in LyX 1.4.x. You'd use
> Insert->Special Formatting->Vertical Space
> which can be bound to the accelerator key of your choice.
Does any of the GUI (Qt, Xforms) allow you to define shortcuts that takes
the time into consideration, e
The xforms event loop in my tree now looks like:
while (!finished) {
ForkedcallsController::get().handleCompletedProcesses();
if (fl_check_forms() == FL_EVENT) {
...
}
}
where handleCompletedProcesses() simply checks whether a SIGCHLD
signal has been r
> "Martin" == Martin Forsgren <[EMAIL PROTECTED]> writes:
Martin> I've got an idéa of a new feature in the gui. As it is now it
Martin> doesn't mather how many enter you press, you still cant get
Martin> more then a new part. Thats good but what if it transformed to
Martin> a vertical space i
Martin Forsgren wrote:
> I've got an idÃa of a new feature in the gui.
> As it is now it doesn't mather how many enter
> you press, you still cant get more then a new
> part. Thats good but what if it transformed to
> a vertical space if you pressed one more enter.
> And if you pressed once more
Martin Forsgren wrote:
Hi, Martin.
> I've got an idéa of a new feature in the gui.
> As it is now it doesn't mather how many enter
> you press, you still cant get more then a new
> part. Thats good but what if it transformed to
> a vertical space if you pressed one more enter.
> And if you press
I've got an idéa of a new feature in the gui.
As it is now it doesn't mather how many enter
you press, you still cant get more then a new
part. Thats good but what if it transformed to
a vertical space if you pressed one more enter.
And if you pressed once more you got an vertical
fill.
Just a s
Alfredo Braunstein wrote:
> [which reminds me: maybe it's time to talk about DEPM again?
> [*ducking*]
I stayed out of the conversation last time(s) so suggest that you
start...
--
Angus
Angus Leeming wrote:
> Alfredo Braunstein wrote:
>
>> This is the patch, for if someone wants to test it and tell me how
>> it feels like.
>
> Do things like math insets in display mode also return true for
> breakAfter?
Right now these two go in parallel.
display = break after + break before
Alfredo Braunstein wrote:
> This is the patch, for if someone wants to test it and tell me how
> it feels like.
Do things like math insets in display mode also return true for
breakAfter?
--
Angus
This is the patch, for if someone wants to test it and tell me how it feels
like.
Alfredo
? ChangeLog-old
? PosIterator.C-save
? PosIterator.h-save
? bfri.C
? safe
? textcursor.C-save
? textcursor.h-save
? insets/insetcollapsable-save.C
? insets/insettext-save.C
Index: cursor.C
===
On Mon, Mar 22, 2004 at 12:36:48PM +, Angus Leeming wrote:
> Let's be careful here. Could you check the attached patch? If you're
> happy, I'll commit it.
Looks magic
john
--
"Spammers get STABBED by GOD." - Ron Echeverri
John Levon wrote:
> Actually I've changed my mind, your code (modulo SIGPIPE issue) is
> fine, with one change: we should do the emergencyCleanup *first* so
> if the lyxerr *does* have problems, then we've at least made an
> effort to save the files ASAP.
Makes sense.
> I think it's fine to do su
On Mon, Mar 22, 2004 at 10:37:30AM +, Angus Leeming wrote:
> > Not really happy actually. If we get a SIGPIPE and a SIGSEGV, we'd
> > lose the SIGSEGV afaics.
>
> Hence my statement that we should remove the SIGPIPE. Ie, SIGPIPE
> signals should not be handled by error_handler. In fact we do
Gets rid of the unused nopop_ variable and rewrites Cursor::dispatch
to:
1. Get rid of the horrible 'operator=(safe)' call;
2. Make clear that the only member variable updated is Cursor::disp_:
DispatchResult LCursor::dispatch(FuncRequest const & cmd)
{
LCursor temp_cursor(*this);
FuncReq
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
Alfredo> which is more compact (and simpler to code), but it's a bit
Alfredo> disconcerting that text that comes before (the footnote)
Alfredo> shown actually after (weell, it not so uncommon for
Alfredo> footnotes). This could be m
Don't appear to be used anymore.
$ grep -r noPop ../src
../src/cursor.h:void noPop();
$ grep -r nopop_ ../src
../src/cursor.C:nopop_ = false;
../src/cursor.C:if (nopop_ || !disp_.dispatched())
../src/cursor.h:bool nopop_;
Ok to remove?
--
Angus
John Levon wrote:
> On Mon, Mar 22, 2004 at 09:28:01AM +, Angus Leeming wrote:
>
>> John Levon wrote:
>> >> Or should the code in child_handler be truly trivial:
>> > Yes.
>>
>> John, I take it that you're (almost) happy with the existing signal
>> handling code in error_handler below. To my
Angus Leeming wrote:
> Cute, but doesn't scale well if you have multiple insets on one line.
True.
>> Otherwise (snapshot7) ,
>
> Yes please!
There are still a number of problems, mainly due to the fact that the inset
doesn't have his own row but just vertically enlarges the row it's in:
1) it
On Mon, Mar 22, 2004 at 09:28:01AM +, Angus Leeming wrote:
> John Levon wrote:
> >> Or should the code in child_handler be truly trivial:
> > Yes.
>
> John, I take it that you're (almost) happy with the existing signal
> handling code in error_handler below. To my mind it needs only a
> han
Alfredo Braunstein wrote:
> There are two possibilities: either (snapshot6) we allow text after
> the inset button:
>
> blah blah blah blah [foot] blah blah
> ++
> ||
> ||
> +---
Kayvan A. Sylvan wrote:
> I don't know when this bug popped up, but I can no longer select
> with the mouse (click-hold-drag) although the SHIFT-move method of
> text selection seems to work.
The problem is that the relevant code has been commented out.
Unfortunately, it doesn't compile, so the
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | John Levon wrote:
Or should the code in child_handler be truly trivial:
>>> Yes.
>>
> | John, I take it that you're (almost) happy with the existing
> | signal handling code in error_handler below. To my mind it nee
Angus Leeming <[EMAIL PROTECTED]> writes:
| John Levon wrote:
>>> Or should the code in child_handler be truly trivial:
>> Yes.
>
| John, I take it that you're (almost) happy with the existing signal
| handling code in error_handler below. To my mind it needs only a
| handling_error flag to ensu
John Levon wrote:
>> Or should the code in child_handler be truly trivial:
> Yes.
John, I take it that you're (almost) happy with the existing signal
handling code in error_handler below. To my mind it needs only a
handling_error flag to ensure that it handles multiple signals
safely. (The SIGP
Martin Vermeer wrote:
> On Sun, Mar 21, 2004 at 01:27:21PM -0800, Kayvan A. Sylvan spake
> thusly:
>
>> I have a lyx document with a branch called "titlepage" (for when I
>> want to turn a custom titlepage off or on).
>>
>> When LyX reads it, I see:
>>
>> no text in updateScrollbar
>>
On Sun, Mar 21, 2004 at 01:27:21PM -0800, Kayvan A. Sylvan spake thusly:
> I have a lyx document with a branch called "titlepage" (for when I want
> to turn a custom titlepage off or on).
>
> When LyX reads it, I see:
>
> no text in updateScrollbar
> Buffer::Buffer()
> LColor::getFr
43 matches
Mail list logo
