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
I forgot to mention the most exciting thing of all
I'm intending to add parameterized chunks; so you can define a chunk to
illustrate an algorithm which you can then "instantiate" in various
places to work on specific data.
I've been using this model a lot for one project and had to keep
I have modified keytest to give one screenshot per key press. I think
this makes the screenshots actually useful as this can make it clear
what the keycodes are actually meant to be doing.
Sample output of four new bugs occuring at the latest branch r30978 is at:
http://gmatht.homelinux.net/xp/
Gorjanc Gregor wrote:
Based upon previous work I used literate classes since
this has been proposed earlier. However, Jean-Marc has been working on another
approach with modules,
which make literate classes for R-LyX obsolete. Right Jean-Marc? Can this
approach also be used for noweb
and work o
>> Based upon previous work I used literate classes since
>> this has been proposed earlier. However, Jean-Marc has been working on
>> another approach with modules,
>> which make literate classes for R-LyX obsolete. Right Jean-Marc? Can this
>> approach also be used for noweb
>> and work of Sam?
Sam Liddicott schreef:
Vincent van Ravesteijn - TNW wrote:
>> Can I use it on Windows ?
I haven't got windows to try but AFAIk there is nothign
windows-specific or even path-related in it, so I guess you
can, as long as you have a decent awk for windows.
>
> Please let me know ho
Vincent van Ravesteijn - TNW wrote:
>> Can I use it on Windows ?
I haven't got windows to try but AFAIk there is nothign
windows-specific or even path-related in it, so I guess you
can, as long as you have a decent awk for windows.
>
> Please let me know how you get on.
Can't i
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
Even so, I'm not sure that the page rank is increased that much by
changing the title of that page. I think it's more important that
other pages link to it, ideally using a suitable link text.
we already do this from the official page and it does not help.
The more pages that link to it, the
Vincent van Ravesteijn - TNW wrote:
>> Can I use it on Windows ?
>
> I haven't got windows to try but AFAIk there is nothign
> windows-specific or even path-related in it, so I guess you
> can, as long as you have a decent awk for windows.
>
> Please let me know how you get on.
Can't
Gorjanc Gregor wrote:
Hi Sam!
This sounds interesting, though a bit to technical for me. My work regarding
the literate programming
with LyX was with R - statistical package that provides tangle and weave
commands that extract R code
and replace code with results, respectively.
Aye, I read
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
>> Can I use it on Windows ?
>
> I haven't got windows to try but AFAIk there is nothign
> windows-specific or even path-related in it, so I guess you
> can, as long as you have a decent awk for windows.
>
> Please let me know how you get on.
Can't it be done using Python (hoping this i
Hi Sam!
This sounds interesting, though a bit to technical for me. My work regarding
the literate programming
with LyX was with R - statistical package that provides tangle and weave
commands that extract R code
and replace code with results, respectively. Based upon previous work I used
litera
Vincent van Ravesteijn - TNW wrote:
notangle (which was buggy) is not used to generate
the source, instead an awk script, newfangle, is used,
fixing various notangle bugs; such as:
Can I use it on Windows ?
I haven't got windows to try but AFAIk there is nothign windows-specific
or eve
> notangle (which was buggy) is not used to generate
> the source, instead an awk script, newfangle, is used,
> fixing various notangle bugs; such as:
Can I use it on Windows ?
Vincent
At the suggestion of kayvan, I posted this message that was originally
sent to lyx-users. I hope I got the right addresses for Cc:
I've posted on http://www.lyx.org/trac/attachment/ticket/6137/
my alternative literate programming style with Lyx. I put this together
because literate programming
> 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
On 08/11/2009 03:40 AM, Abdelrazak Younes wrote:
So, if setPixmap() returns true, then can't we do something like
reset() the cached_item_ and just get rid if that QImage?
You can try. Last time I did, I failed. But I was so upset about this
piece of code that maybe the solution was much sim
>> 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
In case you wonder what holds the release: it's not much. We have resolved the
tex2lyx issues, AFAICS, and we have resolved many critical issues in the
meantime.
The following three issues are on my radar (trac has three more bugs targetted
to 1.6.4, but those are complex longtimers that still
Pavel Sanda writes:
> ahh, thats misunderstanding. there will be cascade of 3 dialogs:
> 1. emergency found - original/recover
> 2. delete emergency file - yes/no
> 3. warning Do not forget to save your file now!
>
> i only added "don't show me again" to 3. it is not as so easy to lose it.
OK the
Jean-Marc Lasgouttes wrote:
> Pavel Sanda writes:
> > could you elaborate more? this dialog cascade is not going to appear
> > often.
>
> I mean this is a case where the user may be annoyed that we made it so
> easy to loose the emergency file: click on "don't show me again" one
> day, and lose a
Pavel Sanda writes:
> could you elaborate more? this dialog cascade is not going to appear
> often.
I mean this is a case where the user may be annoyed that we made it so
easy to loose the emergency file: click on "don't show me again" one
day, and lose a file 6 months later by mistake.
JMarc
rgheck wrote:
On 08/10/2009 05:01 PM, Abdelrazak Younes wrote:
On 10/08/2009 22:46, rgheck wrote:
On 08/10/2009 04:21 PM, Abdelrazak Younes wrote:
QPixmap are implicitly shared. So this means that when you do a =
b, a will be a shadow copy of b up until it is modified, thus
occupying zero add
44 matches
Mail list logo
