Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4
On 2010-10-21, Vincent van Ravesteijn wrote: > > but now we have new problem - how to notice user that exporting is still > in progress or finished (some subvserion of hourglass cursor?). > Status bar: Moving icons. Text. Messages. greyed out (or otherwise modified) export toolbar buttons? Günter
Re: r35575 - lyx-devel/trunk/src
Stephan Witt wrote:
> I made a new patch to implement getDiff() and use it to avoid the query for
> log message
> before checkIn() is done and the confirmation on revert when no diff is found.
thanks for your patience, i went closely through the patch now and generally
liked the approach.
> +FileName const CVS::getDiff(OperationMode opmode)
> +{
> + FileName tmpf = FileName::tempName("lyxvcout");
> + if (tmpf.empty()) {
> + LYXERR(Debug::LYXVC, "Could not generate logfile " << tmpf);
> + return tmpf;
> + }
> +
> + doVCCommand("cvs diff " + getTarget(opmode)
> + + " > " + quoteName(tmpf.toFilesystemEncoding()),
> + FileName(owner_->filePath()), false);
> + return tmpf;
> +}
the error case is suspicious. if tempName fails or "cvs diff" fails how you
detect
this on a higher stage? cmiiw but if something fails you identify it with having
empty diff, which looks wrong, even more if you release lock automatically in
such
a case...
> +int CVS::update(OperationMode opmode, FileName const tmpf)
unless you want to mix this with repoupdate why is opmode here?
> + // should a log message provided for next checkin?
> + virtual bool checkInWithMessage() { return true; }
> + // should a confirmation before revert requested?
> + virtual bool revertWithConfirmation() { return true; }
i would change naming, so its clear what the function really does.
for example isCheckinWithConfirmation...
> private:
> support::FileName file_;
> // revision number from scanMaster
> std::string version_;
> /// The user currently keeping the lock on the VC file.
> std::string locker_;
> +
> + virtual std::string const getTarget(OperationMode opmode);
> + virtual support::FileName const getDiff(OperationMode opmode);
> + virtual int edit();
> + virtual int unedit();
> + virtual int update(OperationMode opmode, support::FileName const tmpf);
> + virtual bool const hasDiff(OperationMode opmode);
> + virtual bool const hasDiff() { return hasDiff(File); }
> };
comments missing
> --- src/LyXVC.cpp (Revision 35732)
> +++ src/LyXVC.cpp (Arbeitskopie)
> @@ -163,9 +163,10 @@
> docstring empty(_("(no log message)"));
> docstring response;
> string log;
> - bool ok = Alert::askForText(response, _("LyX VC: Log Message"));
> + bool dolog = vcs->checkInWithMessage();
> + bool ok = !dolog || Alert::askForText(response, _("LyX VC: Log
> Message"));
hmm, but if !dolog then user automatically gets "cancel" message?
> if (ok) {
> - if (response.empty())
> + if (dolog && response.empty())
> response = empty;
why response=empty harms in !nodolog?
> @@ -212,8 +213,9 @@
> docstring text = bformat(_("Reverting to the stored version of the "
> "document %1$s will lose all current
> changes.\n\n"
> "Do you want to revert to the older version?"),
> file);
> - int const ret = Alert::prompt(_("Revert to stored version of
> document?"),
> - text, 0, 1, _("&Revert"), _("&Cancel"));
> + bool const doask = vcs->revertWithConfirmation();
i would need to check whats above this function in guiview but isn't possible
that we will skip
reverting in case the document is edited but not saved?
> + int const ret = doask ? Alert::prompt(_("Revert to stored version of
> document?"),
> + text, 0, 1, _("&Revert"), _("&Cancel")) : 0;
correspondingly to your previous coding style one would expect ret = doask &&
prompt ; ;)
pavel
Re: r35767 - lyx-devel/trunk/lib/doc
sa...@lyx.org wrote:
> Author: sanda
> Date: Fri Oct 22 01:34:22 2010
> New Revision: 35767
> URL: http://www.lyx.org/trac/changeset/35767
>
> Log:
> (no log message)
>
> Modified:
>lyx-devel/trunk/lib/doc/Additional.lyx
i looked why lyx ignored my message and it looks that
Alert::askForText(response, _("LyX VC: Log Message"));
does not return messages anymore in trunk.
pavel
Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files
Jürgen Spitzmüller wrote: > The second thing I did is fixing a thinko (I think). In this thinko-part smells like trunk stuff unless it really fixes something. pavel
Beta (status update #1, was: Some thoughts on further development process towards beta and RCs)
Pavel Sanda wrote: > hi, status update #1, the most urgent bug is gone. > 1) short resume for things we need before releasing beta > - Richard has some pending work on lyx2lyx which will finish some JMarc work. > - pending patch from Gregory Jefferis for CT, Vincent might have look on it. http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg153396.html > - #6809 - converting to older LyX versions doesn't work under standard > conditions > (lesser importance) - there was patch from John http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg162416.html Vincent, does it have green light from you? the plan for release is the end of next week or the first week of november, showstoppers have highest priority in bugzilla as usual. other feedback? pavel
Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4
Status bar: Moving icons. Text. Messages. Op 22 okt 2010 01:13 schreef "Pavel Sanda" : Richard Heck wrote: > On 10/20/2010 08:59 PM, Peter Kümmel wrote: >> Am Dienstag, den 19.10.2010, 20... i checked that export works on simple document here too. but now we have new problem - how to notice user that exporting is still in progress or finished (some subvserion of hourglass cursor?). pavel
Re: [PATCH] Sweave support (was: Re: Beta plans (again, again))
Gregor GORJANC wrote: > > I finally found some time for making an infrastructure for running sweave > > with our own customizations. As you can see the patch is trivial, but > > I would like to be sure that it works on windows. > > Can I download somewhere a binary to test this? there will be new release in very few weeks. if you have some experiences with patching this change does not need to recompile anything... pavel
Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4
Richard Heck wrote: > On 10/20/2010 08:59 PM, Peter Kümmel wrote: >> Am Dienstag, den 19.10.2010, 20:40 -0400 schrieb Richard Heck: >> >>> I think what's happening is this. If you export pdf (say) without there >>> already being a pdf file there, then everything is fine. But if the pdf >>> file exists, then LyX will try to ask the user whether to overwrite. >>> This means creating a dialog as a child of the parent. But the parent, >>> from what I can tell, is in the main thread, and that's not allowed. >>> >>> I'll paste the full error I get below. As you'll see, LyX crashes here. >>> Here's the backtrace: >>> >> Could you check if it still crashes? >> >> > No crash! Nice work. Seems to work with child documents, too. i checked that export works on simple document here too. but now we have new problem - how to notice user that exporting is still in progress or finished (some subvserion of hourglass cursor?). pavel
Re: r35575 - lyx-devel/trunk/src
Stephan Witt wrote:
> >> If the principle way is ok I can do the same for the RCS and SVN backend
> >> too.
> >>
> >> One question regarding the "View log" button of repoUpdate:
> >> here on Mac the dialog to display the log is unusable.
> >> It is blocked by the next confirmation dialog.
> >> Is this platform specific or on all platforms?
> >
> > no, this glitch is on all platforms (iirc resize did work, but the button
> > was
> > silent).
>
> On Mac it's blocked completely.
>
> > i carry the idea of trying to show that dialog as nonmodal. it maybe
> > oneliner somewhere, but i never really get to solve it...
>
> Ok.
i tried hopeless experiment to set the log window modal for this usecases
but it does not work. dispatch returns from show-dialog lfun and does not
wait for completion and i guess it would need deeper surgery or completely
new dialog to arrange this.
maybe there is another way how to trigger the dialog which would wait,
but my curiousity is exhausted now ;)
pavel
diff --git a/src/VCBackend.cpp b/src/VCBackend.cpp
index 15b6033..9a6ff9d 100644
--- a/src/VCBackend.cpp
+++ b/src/VCBackend.cpp
@@ -824,7 +824,7 @@ string SVN::repoUpdate()
int ret = frontend::Alert::prompt(_("Changes detected"),
text, 0, 1, _("&Yes"), _("&No"), _("View &Log
..."));
if (ret == 2 ) {
- dispatch(FuncRequest(LFUN_DIALOG_SHOW, "file " +
tmpf.absFileName()));
+ dispatch(FuncRequest(LFUN_DIALOG_SHOW, "vclogmodal " +
tmpf.absFileName()));
ret = frontend::Alert::prompt(_("Changes detected"),
text, 0, 1, _("&Yes"), _("&No"));
hideDialogs("file", 0);
diff --git a/src/frontends/qt4/GuiLog.cpp b/src/frontends/qt4/GuiLog.cpp
index e5a8a96..d3c99a9 100644
--- a/src/frontends/qt4/GuiLog.cpp
+++ b/src/frontends/qt4/GuiLog.cpp
@@ -218,6 +218,7 @@ bool GuiLog::initialiseParams(string const & data)
logTypeCO->setEnabled(logtype == "latex");
logTypeCO->clear();
+ setModal(false);
FileName log(logfile);
@@ -238,9 +239,11 @@ bool GuiLog::initialiseParams(string const & data)
} else if (logtype == "lyx2lyx") {
type_ = Lyx2lyxLog;
logTypeCO->addItem(qt_("LyX2LyX"), toqstr(logtype));
- } else if (logtype == "vc") {
+ } else if (logtype == "vc" || logtype == "vcn") {
type_ = VCLog;
logTypeCO->addItem(qt_("Version Control"), toqstr(logtype));
+ if (logtype == "vcn" )
+ setModal(true);
} else
return false;
diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp
index e24ec97..8ed0770 100644
--- a/src/frontends/qt4/GuiView.cpp
+++ b/src/frontends/qt4/GuiView.cpp
@@ -1575,7 +1575,7 @@ bool GuiView::getStatus(FuncRequest const & cmd,
FuncStatus & flag)
enable =
FileName(doc_buffer->logName()).isReadableFile();
else if (name == "spellchecker")
enable = theSpellChecker() && !doc_buffer->isReadonly();
- else if (name == "vclog")
+ else if (prefixIs(name, "vclog"))
enable = doc_buffer->lyxvc().inUse();
break;
}
@@ -3191,7 +3191,10 @@ void GuiView::dispatch(FuncRequest const & cmd,
DispatchResult & dr)
}
data += Lexer::quoteString(logfile);
showDialog("log", data);
- } else if (name == "vclog") {
+ } else if (prefixIs(name, "vclog")) {
+ string type = "vc";
+ if (name == "vclogmodal")
+ type = "vcn";
string const data = "vc " +
Lexer::quoteString(doc_buffer->lyxvc().getLogFile());
showDialog("log", data);
Re: r35760 - lyx-devel/trunk/src/frontends/qt4
Yes. Because paramstodialog made the status change to valid and enabled the restore button even when the user didn't change anything yet. Or we add the same "if" before bc.restore, or change buttoncontroller to offer the possibility to change some fields without changing its status. Op 21 okt 2010 23:43 schreef "RGH" : On 10/21/2010 05:03 PM, Vincent van Ravesteijn wrote: > > On Thu, Oct 21, 2010 at 9:34 PM, Richard H... Do you remember why it was needed? or seemed needed? rh
Re: r35760 - lyx-devel/trunk/src/frontends/qt4
On 10/21/2010 05:03 PM, Vincent van Ravesteijn wrote: On Thu, Oct 21, 2010 at 9:34 PM, Richard Heck wrote: On 10/21/2010 02:29 PM, Vincent van Ravesteijn wrote: This does not look ok. If the dialog is on the initial state, the restore button should not be enabled at all. I think the dialog is erroneously is the initial state. Perhaps. It looks like restore() is being called twice. Once at the very end of GuiDocument::paramsToDialog and then from GuiDialog::slotRestore(). Can the first go? Richard Wasn't it me that added one of those ... :( ? Do you remember why it was needed? or seemed needed? rh
Re: r35760 - lyx-devel/trunk/src/frontends/qt4
On Thu, Oct 21, 2010 at 9:34 PM, Richard Heck wrote: > On 10/21/2010 02:29 PM, Vincent van Ravesteijn wrote: >> >> This does not look ok. If the dialog is on the initial state, the restore >> button should not be enabled at all. >> >> I think the dialog is erroneously is the initial state. >> > Perhaps. It looks like restore() is being called twice. Once at the very end > of GuiDocument::paramsToDialog and then from GuiDialog::slotRestore(). Can > the first go? > > Richard > Wasn't it me that added one of those ... :( ? Vincent
Re: r35760 - lyx-devel/trunk/src/frontends/qt4
On 10/21/2010 02:29 PM, Vincent van Ravesteijn wrote: This does not look ok. If the dialog is on the initial state, the restore button should not be enabled at all. I think the dialog is erroneously is the initial state. Perhaps. It looks like restore() is being called twice. Once at the very end of GuiDocument::paramsToDialog and then from GuiDialog::slotRestore(). Can the first go? Richard
Re: r35760 - lyx-devel/trunk/src/frontends/qt4
This does not look ok. If the dialog is on the initial state, the restore button should not be enabled at all. I think the dialog is erroneously is the initial state. Op 21 okt 2010 20:25 schreef : Author: rgheck Date: Thu Oct 21 20:25:15 2010 New Revision: 35760 URL: http://www.lyx.org/trac/changeset/35760 Log: Restore should, uh, restore the initial state. Other half of #6964. Modified: lyx-devel/trunk/src/frontends/qt4/ButtonPolicy.cpp Modified: lyx-devel/trunk/src/frontends/qt4/ButtonPolicy.cpp == --- lyx-devel/trunk/src/frontends/qt4/ButtonPolicy.cpp Thu Oct 21 20:20:12 2010(r35759) +++ lyx-devel/trunk/src/frontends/qt4/ButtonPolicy.cpp Thu Oct 21 20:25:15 2010(r35760) @@ -398,6 +398,7 @@ state_machine_[INITIAL][SMI_VALID] = VALID; state_machine_[INITIAL][SMI_INVALID] = INVALID; state_machine_[INITIAL][SMI_READ_ONLY] = RO_INITIAL; + state_machine_[INITIAL][SMI_RESTORE] = INITIAL; // State::VALID state_machine_[VALID][SMI_VALID] = VALID; state_machine_[VALID][SMI_READ_WRITE] = VALID; @@ -419,6 +420,7 @@ state_machine_[RO_INITIAL][SMI_VALID] = RO_VALID; state_machine_[RO_INITIAL][SMI_INVALID] = RO_INVALID; state_machine_[RO_INITIAL][SMI_READ_WRITE] = INITIAL; + state_machine_[RO_INITIAL][SMI_RESTORE] = INITIAL; // State::RO_VALID state_machine_[RO_VALID][SMI_VALID] = RO_VALID; state_machine_[RO_VALID][SMI_READ_ONLY] = RO_VALID;
Re: [RFC] [patch] bug 6944: crash on drag and drop multiple files
Jürgen Spitzmüller wrote: > Does this make sense? Nobody? Jürgen
Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4
On 10/20/2010 08:59 PM, Peter Kümmel wrote: Am Dienstag, den 19.10.2010, 20:40 -0400 schrieb Richard Heck: I think what's happening is this. If you export pdf (say) without there already being a pdf file there, then everything is fine. But if the pdf file exists, then LyX will try to ask the user whether to overwrite. This means creating a dialog as a child of the parent. But the parent, from what I can tell, is in the main thread, and that's not allowed. I'll paste the full error I get below. As you'll see, LyX crashes here. Here's the backtrace: Could you check if it still crashes? No crash! Nice work. Seems to work with child documents, too. Richard
