Jürgen Spitzmüller wrote:
> > I'm testing this approach, but this should definitely be fixed and the
> > last thing I'll do to branch (It's an awful depressing delicate mess).
>
> Oh, sure. I thought this was already in.
This is the only missing bit now, if no further critical issues arise (except
rgheck wrote:
> The old one is in.
Thanks.
> OK to put the new one in as soon as branch is open
> again?
Yes.
Jürgen
On 08/18/2009 06:30 AM, Jürgen Spitzmüller wrote:
#5893 LyX closes hidden dirty buffers without asking
=> Richard, please put in the original patch that reuses the existing popup.
The new approach that introduces new GUI strings will replace that in 1.6.5.
(A new string would break the string f
Pavel Sanda wrote:
> imho we should add to the annoucement special notice about the qt 4.5.[0/2]
> crashes and urging to upgrade for 1.6.4 esp. for package maintainers...
I'll do that.
Jürgen
Vincent van Ravesteijn - TNW wrote:
> > - an awful crash, very simple to reproduce,
>
> I'm testing this approach, but this should definitely be fixed and the last
> thing I'll do to branch (It's an awful depressing delicate mess).
Oh, sure. I thought this was already in.
Jürgen
Jürgen Spitzmüller wrote:
> It is time to get the release ready. My plan is to set it up at the weekend.
>
> There are two things which should be done before that, everything else will
> have to wait:
imho we should add to the annoucement special notice about the qt 4.5.[0/2]
crashes and urging
>It is time to get the release ready. My plan is to set
>it up at the weekend.
>>OK for these.
>
>>Jürgen
>
> - an awful crash, very simple to reproduce,
I'm testing this approach, but this should definitely be fixed and the last
thing I'll do to branch (It's an awful depressing delicate mess
rgheck wrote:
> Yes, which evolved into these:
I was hoping to maintain the string freeze.
Jürgen
Forget the previous... I keep having problems with M*#*#(# outlook.
Vincent
>Yes, which evolved into these:
> http://www.lyx.org/trac/changeset/31056
> http://www.lyx.org/trac/changeset/31057
> http://www.lyx.org/trac/changeset/31074
>per Vincent's suggestion that we save an emergency file in
>this case. The first is harmless cleanup. (Why was this ever
>in Buf
On 08/17/2009 10:29 AM, Jürgen Spitzmüller wrote:
rgheck wrote:
My patch too is delicate. I think it's fine, but there may still be a
possibility of people being asked multiple times if they want to save a
document. I guess that's not so bad, but if you want me just to commit
that one, then
rgheck wrote:
> My patch too is delicate. I think it's fine, but there may still be a
> possibility of people being asked multiple times if they want to save a
> document. I guess that's not so bad, but if you want me just to commit
> that one, then we can do that. It at least solves the dataloss p
On 08/16/2009 10:14 AM, Jürgen Spitzmüller wrote:
rgheck wrote:
Maybe the thing to do is not include it for 1.6.4, but commit it as soon
as 1.6.4 is out, so that it gets tested. I doubt that terribly many
people get bit by this bug. Not to say it isn't important, but we don't
want to make th
rgheck wrote:
> Maybe the thing to do is not include it for 1.6.4, but commit it as soon
> as 1.6.4 is out, so that it gets tested. I doubt that terribly many
> people get bit by this bug. Not to say it isn't important, but we don't
> want to make things worse...
Actually, I tend to agree.
We coul
On 08/15/2009 01:25 PM, Jürgen Spitzmüller wrote:
rgheck wrote:
I think we've done pretty well here. We said a while ago we wanted to do
two things: (i) Make it impossible completely to hide dirty buffers;
(ii) Protect against dataloss from destroying dirty buffers. I think we
did both, and
rgheck wrote:
> I think we've done pretty well here. We said a while ago we wanted to do
> two things: (i) Make it impossible completely to hide dirty buffers;
> (ii) Protect against dataloss from destroying dirty buffers. I think we
> did both, and Vincent did some nice cleanup along the way.
I a
Vincent van Ravesteijn wrote:
> I'm afraid it's getting pretty complex.. although I try to split
> everything in steps that are just cosmetical and steps that change logic.
Well, it's necessary anyway. If we come to think it's _too_ complex or risky
for 1.6.4, we still can ponder a more simple an
On 08/15/2009 12:42 PM, Jürgen Spitzmüller wrote:
rgheck wrote:
This has been done for trunk at r31056 and r31057. Up to you if you want
it for branch, Jurgen. I don't know that it is absolutely necessary.
It's just a safety net.
Let's see first how the general solution evolves.
(I h
Jürgen Spitzmüller schreef:
Vincent van Ravesteijn wrote:
Yes, and that's exactly where I raised my concerns about.
What concerns?
Jürgen
I'm afraid it's getting pretty complex.. although I try to split
everything in steps that are just cosmetical and steps that change logic.
Vi
Vincent van Ravesteijn wrote:
> Yes, and that's exactly where I raised my concerns about.
What concerns?
Jürgen
Jürgen Spitzmüller schreef:
Vincent van Ravesteijn wrote:
(I hope the whole thing does not get too complex).
hmmm.
I mean: with regard to 1.6.4 (only).
Jürgen
Yes, and that's exactly where I raised my concerns about.
Vincent
Vincent van Ravesteijn wrote:
> > (I hope the whole thing does not get too complex).
> >
>
> hmmm.
I mean: with regard to 1.6.4 (only).
Jürgen
(I hope the whole thing does not get too complex).
hmmm.
Vincent
rgheck wrote:
> This has been done for trunk at r31056 and r31057. Up to you if you want
> it for branch, Jurgen. I don't know that it is absolutely necessary.
> It's just a safety net.
Let's see first how the general solution evolves.
(I hope the whole thing does not get too complex).
Jürgen
On 08/15/2009 02:10 AM, Jürgen Spitzmüller wrote:
rgheck wrote:
I think it is good to have a backup to save dirty buffers. However, I
think I prefer to save an emergency file, and to issue an warning that
an emergency file is saved, rather than presenting a save/discard
dialog which pretends
rgheck wrote:
> > I think it is good to have a backup to save dirty buffers. However, I
> > think I prefer to save an emergency file, and to issue an warning that
> > an emergency file is saved, rather than presenting a save/discard
> > dialog which pretends like it's the normal workflow.
>
> That
On 08/14/2009 12:28 PM, Vincent van Ravesteijn wrote:
rgheck schreef:
I've lost track of what we think the status of the attached patch is.
rh
I think it is good to have a backup to save dirty buffers. However, I
think I prefer to save an emergency file, and to issue an warning that
an e
rgheck schreef:
I've lost track of what we think the status of the attached patch is.
rh
I think it is good to have a backup to save dirty buffers. However, I
think I prefer to save an emergency file, and to issue an warning that
an emergency file is saved, rather than presenting a save/d
Jürgen Spitzmüller schreef:
Vincent van Ravesteijn - TNW wrote:
Comments ?
It looks good in general, and I like the approach. Still one glitch, though:
the recipe in the bug report still holds:
Yes, I didn't address that yet. I first wanted to have a proper way to
hide buffers.
Vincent van Ravesteijn - TNW wrote:
> Comments ?
It looks good in general, and I like the approach. Still one glitch, though:
the recipe in the bug report still holds:
* View -> Split View
* Open Document in Splitted View
* Make change, don't save
* View -> Close Tab Group
=> The buffer is hidd
I've lost track of what we think the status of the attached patch is.
rh
Index: src/Buffer.cpp
===
--- src/Buffer.cpp (revision 31030)
+++ src/Buffer.cpp (working copy)
@@ -328,6 +328,20 @@
theBuf
>>> I meant on buffer hiding. If I hide a dirty buffer with this new
>>> patch, LyX just hides it without asking me if I want to save it.
>>>
>>>
>> Yes, that is right. The new patch doesn't try to ask about that:
>> Vincent didn't like where I was doing it, and I can't see any other
>> pla
rgheck schreef:
I meant on buffer hiding. If I hide a dirty buffer with this new
patch, LyX
just hides it without asking me if I want to save it.
Yes, that is right. The new patch doesn't try to ask about that:
Vincent didn't like where I was doing it, and I can't see any other
place;
rgheck schreef:
On 08/12/2009 12:54 PM, Jürgen Spitzmüller wrote:
rgheck wrote:
All of this is a still reason to wish we could do this somewhere else.
Maybe one way to do it would be in GuiView::closeEvent(). Here, we
could
check whether we are closing the last view. If so, then we can che
On 08/12/2009 12:54 PM, Jürgen Spitzmüller wrote:
rgheck wrote:
All of this is a still reason to wish we could do this somewhere else.
Maybe one way to do it would be in GuiView::closeEvent(). Here, we could
check whether we are closing the last view. If so, then we can check
whatever docume
rgheck wrote:
> All of this is a still reason to wish we could do this somewhere else.
> Maybe one way to do it would be in GuiView::closeEvent(). Here, we could
> check whether we are closing the last view. If so, then we can check
> whatever documents are still open, and do something appropriate.
On 08/12/2009 11:56 AM, Jürgen Spitzmüller wrote:
One remaining glitch: If the dirty buffer is a new document, the method should
bring up a dialog to enter a proper file name. Now it just saves the
newfileX.lyx, which is not very obvious (I first thought the document was
lost).
I'm not sure
rgheck wrote:
> Yes, that is right. The new patch doesn't try to ask about that: Vincent
> didn't like where I was doing it, and I can't see any other place; there
> were Pavel's worries; etc. So this one just asks when the Buffer itself
> is destroyed.
I see. Then I misread your description of th
On 08/12/2009 11:11 AM, Jürgen Spitzmüller wrote:
rgheck wrote:
With this, I don't get ask anymore if I want to die a dirty buffer.
Sorry, I don't understand. If I open LyX, type a few characters, and
choose "Close" or "Quit", I get asked as usual about closing.
I meant on
rgheck wrote:
> > With this, I don't get ask anymore if I want to die a dirty buffer.
> >
> >
>
> Sorry, I don't understand. If I open LyX, type a few characters, and
> choose "Close" or "Quit", I get asked as usual about closing.
I meant on buffer hiding. If I hide a dirty buffer with this ne
On 08/12/2009 10:56 AM, Abdelrazak Younes wrote:
rgheck wrote:
On 08/12/2009 04:11 AM, Abdelrazak Younes wrote:
Instead of switching the unsaved buffer one by one, what about
offering a dialog listing all the unsaved file with a checkbox and a
save button? The dialog would also have three butt
rgheck wrote:
On 08/12/2009 04:11 AM, Abdelrazak Younes wrote:
Instead of switching the unsaved buffer one by one, what about
offering a dialog listing all the unsaved file with a checkbox and a
save button? The dialog would also have three button: "Discard all
and exit", "Save all and exit",
On 08/12/2009 04:11 AM, Abdelrazak Younes wrote:
Instead of switching the unsaved buffer one by one, what about
offering a dialog listing all the unsaved file with a checkbox and a
save button? The dialog would also have three button: "Discard all and
exit", "Save all and exit", "Cancel exit".
On 08/12/2009 02:14 AM, Jürgen Spitzmüller wrote:
rgheck wrote:
So try the attached. The only change from before is the one line in
GuiView.cpp, which marks the Buffer clean if the user says she wants to
discard changes. It's clean in the sense that it doesn't need to be
saved. That way we d
On Wed, Aug 12, 2009 at 11:00:07AM +0200, Vincent van Ravesteijn - TNW wrote:
> >> Please tell me if there are further issues to be considered.
> >
> >If you close Windows Vista, LyX won't ask you to save dirty buffers
> >(dataloss).
>
> I couldn't solve it. For some reason, I don't get the WM_QU
>> Please tell me if there are further issues to be considered.
>
>If you close Windows Vista, LyX won't ask you to save dirty buffers (dataloss).
I couldn't solve it. For some reason, I don't get the WM_QUERYENDSESSION and
WM_ENDSESSION messages from Windows.
QtDesigner does get them :S..
Vi
rgheck wrote:
On 08/11/2009 12:21 PM, Jürgen Spitzmüller wrote:
If you add Pavel's valid concerns about multiple views to this, I
think theonly way to go now is your second approach: check for dirty
hidden buffers on exit. I agree that this is sub-optimal, but
everything else strikes me pretty
rgheck wrote:
> So try the attached. The only change from before is the one line in
> GuiView.cpp, which marks the Buffer clean if the user says she wants to
> discard changes. It's clean in the sense that it doesn't need to be
> saved. That way we don't get asked again about saving it when the Buf
On 08/11/2009 12:21 PM, Jürgen Spitzmüller wrote:
If you add Pavel's valid concerns about multiple views to this, I
think theonly way to go now is your second approach: check for dirty
hidden buffers on exit. I agree that this is sub-optimal, but
everything else strikes me pretty complicated fo
On 08/11/2009 12:00 PM, Pavel Sanda wrote:
Richard Heck wrote:
I propose something along the following lines, but I am not at all sure
about this. I'm trying to do two things here. (i) Check whether a Buffer is
dirty whenever it is destroyed. I see this as a last ditch effort to avoid
datalo
> Comments welcome. I'm not at all sure about this.
I don't want to save the buffer in removeWorkArea(), because it's decided in
GuiView::closeEvent that we don't do it, and then it seems strange that it is
done anyway. Moreover, saving the buffer seems to be the responsibility of
GuiView::clos
rgheck wrote:
> (ii) Do the
> same check whenever a tab is hidden. I don't think dirty tabs should be
> allowed to be hidden. It will lead to surprises later.
This is what I have tried as well, but it turns out it is more complicated
than it seems. If you hide a dirty buffer, and LyX asks you if
Richard Heck wrote:
> I propose something along the following lines, but I am not at all sure
> about this. I'm trying to do two things here. (i) Check whether a Buffer is
> dirty whenever it is destroyed. I see this as a last ditch effort to avoid
> dataloss, and one that should rarely if ever
On 08/11/2009 08:56 AM, Jürgen Spitzmüller wrote:
#5893 LyX closes hidden dirty buffers without asking
=> I have played a bit with this, but did not come up with a satisfactory
solution. I'm out of time ATM, so if no one else picks this up, we will have
to live with it (I know it's a dataloss,
On 08/11/2009 10:37 AM, Vincent van Ravesteijn - TNW wrote:
btw in gnome or kde you are going to be asked in the same way as in
windows nowadays or is that direct kill signal from dekstop manager?
I think we get a signal from Qt. See e.g. GuiView::closeEvent().
That's th
Vincent van Ravesteijn - TNW wrote:
> That's the crux, what do you mean by 'a' signal.
> QMainWindow::closeEvent(QCloseEvent * close_event) or
> QApplication::event(Qevent * ev) ?
I don't know if it's relevant, but LyX.cpp has this comment:
/*
Signals and Windows
===
The SIGHUP si
>> btw in gnome or kde you are going to be asked in the same way as in
>> windows nowadays or is that direct kill signal from dekstop manager?
>>
>>
>I think we get a signal from Qt. See e.g. GuiView::closeEvent().
>
That's the crux, what do you mean by 'a' signal.
QMainWindow::closeEvent(Q
On 08/11/2009 10:27 AM, Pavel Sanda wrote:
Richard Heck wrote:
I have a distinct memory of having been in this vicinity before, involving
closing via the window manager under X.
btw in gnome or kde you are going to be asked in the same way as in windows
nowadays or is that direct kil
Richard Heck wrote:
> I have a distinct memory of having been in this vicinity before, involving
> closing via the window manager under X.
btw in gnome or kde you are going to be asked in the same way as in windows
nowadays or is that direct kill signal from dekstop manager?
pavel
On 08/11/2009 10:10 AM, Vincent van Ravesteijn - TNW wrote:
looks like qt thing
Looks like we have to implement
I have a distinct memory of having been in this vicinity before,
involving closing via the window manager under X.
rh
bool GuiApplication::event(QEvent *ev)
{
>looks like qt thing
Looks like we have to implement
bool GuiApplication::event(QEvent *ev)
{
bool eaten = false;
switch (ev->type()) {
case QEvent::Close: {
QCloseEvent *closeEvent = static_cast(ev);
closeEvent->setAccepted(...);
if (closeEvent->isAccepted()
Pavel Sanda wrote:
> > No, LyX immediately quits (and also the dos box with any debug output).
>
> looks like qt thing
Or a LyX thing, unrelated to the frontend.
Perhaps some debugging in LyX.cpp (exec) helps?
Jürgen
Vincent van Ravesteijn - TNW wrote:
> >or at least you have enough time to see whats happening
> >insisde lyx machinery after getting quit signal.
>
> No, LyX immediately quits (and also the dos box with any debug output).
looks like qt thing
pavel
>> And fixing such a thing is a lot more difficult if you
>> have no chance of getting some debug info.
>
>simply run some other app which ask for confirmation and
>give cancel if possible.
Yes, that's what I did not to restart Windows every time.
>or at least you have enough time to see whats ha
Vincent van Ravesteijn - TNW wrote:
>
> >I had a quick look whether I could fix it and then I saw that at Vista,
>
> >LyX was just shut down.
>
> And fixing such a thing is a lot more difficult if you have no chance of
> getting some debug info.
simply run some other app which ask for confirma
>I had a quick look whether I could fix it and then I saw that at Vista,
>LyX was just shut down.
And fixing such a thing is a lot more difficult if you have no chance of
getting some debug info.
Vincen
>> No, it was reported yesterday on devel-list and I replied yesterday
>> evening asking him to report it.
>
>Hm, the issue reported (with XP) is this:
>http://www.lyx.org/trac/ticket/5525
>
Hmm, I've never seen that bug, otherwise I'd have shout earlier. (That's
strange, I was fixing bugs at An
Vincent van Ravesteijn - TNW wrote:
> No, it was reported yesterday on devel-list and I replied yesterday evening
> asking him to report it.
Hm, the issue reported (with XP) is this:
http://www.lyx.org/trac/ticket/5525
was the Vista problem reproduced by you? The OP did not report that.
Jürgen
>> If you close Windows Vista, LyX won't ask you to save dirty buffers
>> (dataloss).
>
>Is this on trac?
>
No, it was reported yesterday on devel-list and I replied yesterday evening
asking him to report it.
>Jürgen
Vincent
Vincent van Ravesteijn - TNW wrote:
> If you close Windows Vista, LyX won't ask you to save dirty buffers
> (dataloss).
Is this on trac?
Jürgen
> Please tell me if there are further issues to be considered.
If you close Windows Vista, LyX won't ask you to save dirty buffers (dataloss).
> Jürgen
Vincent
Jean-Marc Lasgouttes wrote:
> That said, I let you decide how to proceed.
I have followed your discussion, but I did not get all the details. Anyway, I
think if the new method is that controversial, I think we should go back to
the status quo ante in branch.
Jürgen
Le 16 juil. 09 à 08:01, Jürgen Spitzmüller a écrit :
Looking at status.16x, I see a long, steadily growing list, so I
think it's
time for some planning.
b.) tex2lyx issues
#5702 tex2lyx cannot deal with modules
#6059 New tex2lyx preamble parsing scheme breaks roundtrip
Since I will be u
On 07/16/2009 05:22 PM, Jean-Marc Lasgouttes wrote:
Le 16 juil. 09 à 21:21, rgheck a écrit :
I'd suggest closing the bug. Keytest has already found another
SIGSEGV, and is minimising the number of keycodes needed to reproduce.
I don't see any point spending time worrying about old irreducible
ke
Le 16 juil. 09 à 21:21, rgheck a écrit :
I'd suggest closing the bug. Keytest has already found another
SIGSEGV, and is minimising the number of keycodes needed to
reproduce.
I don't see any point spending time worrying about old irreducible
keytest bugs, when there are new reproducible keytes
On 07/16/2009 03:15 PM, John McCabe-Dansted wrote:
On Thu, Jul 16, 2009 at 9:52 PM, rgheck wrote:
#5997 lyx::Buffer::save calls 0x0016 (SIGSEGV)
Since this was a keypress crash, I have no idea how to reproduce.
Neither do I unfortunately. This was from an old version
On Thu, Jul 16, 2009 at 9:52 PM, rgheck wrote:
>> #5997 lyx::Buffer::save calls 0x0016 (SIGSEGV)
>>
>
> Since this was a keypress crash, I have no idea how to reproduce.
Neither do I unfortunately. This was from an old version of keytest
that didn't generate very useful logs.
I'm running key
On 07/16/2009 02:01 AM, Jürgen Spitzmüller wrote:
Looking at status.16x, I see a long, steadily growing list, so I think it's
time for some planning.
I think we have enough new features in and we should concentrate on
stabilization and crucial issues now (I know Vincent still has pending patches
Jürgen Spitzmüller writes:
> I don't think it's too much to ask that people respect that doing
> release management is not always a job where you can please everybody
> at every time
I don't understand, when I did it, I pleased everybody every time. Or
this is what I recall, at least. I'm sure I
Pavel Sanda wrote:
> thats right. but my feeling is that the real point here is to keep Vincent
> motivated while he has enough enthusiasm to fix years old bugs which nobody
> else would even touch. after all what the milestone 1.6.x means? if you
> consider those bugs as candy and bling worthless
Jürgen Spitzmüller wrote:
> People who do not see a reason to upgrade should stick with their version. I
> do not see the point of adding candy and bling just for the sake of getting
> people to upgrade. My aim is to make LyX as robust and reliable as possible,
> not to get as many users as poss
Jürgen Spitzmüller writes:
> If your colleague is fine with 1.6.3: fine. Why not?
+1
JMarc
Vincent van Ravesteijn - TNW wrote:
> >Remember, this is a maintenance release. New features
> >are secondary, our main aim is to make 1.6.x more robust.
>
> I know, but we also have to motivate people to upgrade. Also the people
> that do not experience large problems yet. The higher the version,
> >I think we have enough new features in and we should
> >concentrate on stabilization and crucial issues now
>
> I'm not overwhelmed by the amount of new features.
>
>Remember, this is a maintenance release. New features
>are secondary, our main aim is to make 1.6.x more robust.
I know, but
Vincent van Ravesteijn - TNW wrote:
> >I think we have enough new features in and we should
> >concentrate on stabilization and crucial issues now
>
> I'm not overwhelmed by the amount of new features.
Remember, this is a maintenance release. New features are secondary, our main
aim is to make 1.
>I think we have enough new features in and we should
>concentrate on stabilization and crucial issues now
I'm not overwhelmed by the amount of new features.
>(I know Vincent still has pending patches in the pipe;
>those will be still considered).
Yes, I'm still busy backporting the fixes tha
86 matches
Mail list logo
