Re: Is it time to rename .C to .cpp now?
Bo Peng wrote: Is there any reason *not* to do it now? It does not help the user. Use your energy on things that will help the user. Regards, Asger
Re: Is it time to rename .C to .cpp now?
I propose to leave this for 1.6, I don't expect so many new files in 1.5 so the advantages would not be so many. On the other hand after 1.5 and the xml merging this would be the right time. Is there any reason *not* to do it now? As a matter of fact, I do not see unmerged branches as a big problem. Since there are only filename changes, one can 1. update branch with trunk 2. produce a patch for the trunk with 'svn diff' 3. sync with renamed trunk 4. manually edit the patch, globally replace .C with .cpp 5. apply the patch to the branch. I can see at least one advantage of this: do it now and we do not have to bring this problem up the tenth time. Bo
Restarting the LyX documentation project
Hello LyXers, I want to restart to work on the documentation but at first want to have you OK about the HOW. The documentation is currently out of date, many menu names have changed since the last release, new features like change tracking are not or not properly explained. Then main problem I see is that we don't have somebody who's actively working on the documentation. But besides this the inconsistent documentation we currently have is a result that the developer of a new feature add a section to the userguide without cross-checking if the section is consistent with others. That can be excused due to lack of time but for the future I propose this way: --- When a new feature is implemented to be released in the next LyX version the developer(s) who wrote the feature create a separate LyX-document describing the feature. Then somebody who wasn't involved in the development of the feature checks if he's able to use the feature as described. This would help us to implement features user friendly because the revisers of the document will lead to feedback about the implementation, the usability and the stability of the feature before the feature is released. If the feature is stable its describing document is implemented into the userguide. --- This sounds a bit theoretic but the current way we implement features is not user friendly: I noticed that only a few people know the new change tracking feature of LyX 1.4.x and those who found the menu entry for this asked me how to use it because the feature isn't properly explained in the docs or in the wiki. Even if they know to handle change tracking because they've used this in MS Word, they of course ask me why the changes don't appear in the PDF but only in the DVI output. All these small bits should be explained somewhere. -- These are my plans: I started to work on the docs before I started the Win installer project, the docs can be found here: http://wiki.lyx.org/LyX/DocumentationDevelopment We have lots and lots of questions in the lyx-users list that were already answered some time ago, so I will describe the several features with all its details in several documents. This will hopefully enable the users to find a solution for their special problem without searching in mailing lists. These documents are a good starting point for developers when they want to implement new functionality or support for LaTeX-packages. The basic things and informations of the special documents will be part of the userguide. To see what I mean have a look at the Floats/Figures/Tables manual I'm currently working on (It is not yet ready!): http://wiki.lyx.org/uploads/LyX/LyXDevelDocumentation/Tables.pdf (http://wiki.lyx.org/uploads/LyX/LyXDevelDocumentation/Tables.rar) It contains lots answers to special problems asked in the users-list but also the basics. The section about booktabs is for example a good test for the booktabs implementation of LyX 1.5svn: Is the implementation feature complete?, can the example tables be created easily enough?, etc.. The special docs as well as the basic userguide will have a detailed description of every menu entry and toolbar button. The lack of this information is currently the most annoying thing for new users. The special docs can be used as testing documents before new versions of LyX are released. This will hopefully avoid buggy releases like LyX 1.4.0. I noticed most of the bugs I reported for this release by checking the math features using my math documentation: http://wiki.lyx.org/LyX/LyXMathebefehle This math manual will be the second specials documentation when it is translated into English. regards Uwe
Re: Is it time to rename .C to .cpp now?
On Tuesday 24 October 2006 8:58 pm, Bo Peng wrote: > > please not that in this case it is not necessary to run > > autogen.sh or configure. That is only needed for bigger changes > > (deleting/adding a directory etc.) > > My understanding is every addition/removal of files leads to > autogen.sh. They are frankly not rare events. > > > No, Lars has some not merged branches. I wo't oppose such a change, but I > > won't do it either. > > Then we wil never be able to do it since everyone has his unmerged > branches. It is the best time I have seen in months because all big > changes are in trunk. I propose to leave this for 1.6, I don't expect so many new files in 1.5 so the advantages would not be so many. On the other hand after 1.5 and the xml merging this would be the right time. > Other votes? (I should have proposed this to Denmark people, since > they can vote easily, or act without votes.) Since I am one the Denmark people does that makes me Danish? ;-) > Bo -- José Abílio
KCachegrind and LyX
Hello, I'm reading arguments to and fro about the fastness of the new Qt4 frontend. Just a question. Has someone tried Valgrind / Cachegrind / KCachegrind on the Qt4 frontend and the last working Qt3 frontend after the unicode transition, and a 1.4 version ? At least, it would give more scientific data where (Qt4, Unicode) LyX has lost and gained some speed lately. For KDE, the use of these tools have given good (optimization) results. Cheers, Charles
Re: [patch] fix inputenc
On Tue, Oct 24, 2006 at 04:53:44PM +0200, Jean-Marc Lasgouttes wrote: > > "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: > > Juergen> Jean-Marc Lasgouttes wrote: > >> PS: especially since the teTeX 2.0 on my machine does not do utf8 > >> :( > > Juergen> teTeX 2.0 was released in Feb 2003, initial, "partial, > Juergen> experimental" support for utf8 in unicode with the LaTeX > Juergen> 2003-12 release (see > Juergen> http://www.latex-project.org/ltnews/ltnews15.pdf). > > Juergen> So you'd need teTeX 3 at least (or TeXLive 2004 at least). > > My point is that I may not be the only one in this situation. LaTeX is > supposed to be very stable, after all. Yep. I have teTeX 2 on my Solaris box, too. Never had the need to upgrade it till now... -- Enrico
Re: [patch] fix inputenc
On Tuesday 24 October 2006 8:42 pm, Georg Baum wrote: > > What about docbook? Is this always utf8? > > AFAIK docbook files can be encoded in utf8, latin1 and a number of other > encodings, but all relevant tools are able to process utf8. If we use xml, not if we go with sgml. While in the meeting I found that some of those did not work, because in sgml we have a list of allowed characters and those were not on it. The enconding lists that we have in lib are similar to some of sgml definition (I don't remember if this is the standard terminology but this is the idea) files. python has a dictionary that has the convertion: http://docs.python.org/lib/module-htmlentitydefs.html -- José Abílio
cursor behavior
some cursor weirdness just for the record: 1. when typing in math the cursor blinks before the math inset before returning to the right position 2. cursor and selection are not synchronized: - when selecting with the keyboard the cursor moves before the selection - when selecting with the mouse the cursor lags behind the selection (and therefore also outside the selection when making the selection smaller)
Re: The cursor is seriously broken..
i think that the positioning of the cursor is nicer with the attached (moves it 2 pixels to the right...) - cursor_->setGeometry(x, y, 2, h); + cursor_->setGeometry(x + 2, y, 2, h); Indeed. Committed. Michael
Re: [Patch] Fix some LFUN_WINDOW_CLOSE bugs.
On Tue, 24 Oct 2006, Abdelrazak Younes wrote: > > (For some reason, while reading the above I assumed that LFUN_WINDOW_CLOSE > > would invoke LYX_QUIT if it was the last window. > > That's right. Ok, I'll just modify it slightly. This hould be fine: The function 'window-close' closes the active LyX window. If no LyX window is currently in focus, the last window in focus will be closed. Closing the last LyX window will also close LyX (by calling 'lyx-quit'). See 'window-new' for more details. /C -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Is it time to rename .C to .cpp now?
> My understanding is every addition/removal of files leads to > autogen.sh. Yes and No. So, to some extend, make might go wrong after 'svn up', and it is safer to go through the whole lenghy process. In my case, 'scons install -j4' is all I need to do. Anyway, I know the performance problem of scons... :-) There has been a big thread on scons/dev yesterday because Thomas has released his waf 1.0 which claims to be 10 times faster than scons. The scons developers seem to be interested, although Thomas' proposal was more extreme: release scons as it is and switch to waf! Bo
Re: Random notes
Jose, let me summarize Georg's patch list: - bugs in bugzilla with the fileformat keyword (can only be fixed in a major release) - esint (more or less finished) - nomencl (finished) - xymatrix (almost working implementation) - image cache (works well; needs lyxrc options) - navigation across child documents (stable; potential performance issues) I think we should consider at least a few of these issues. Georg has done a lot of good things for LyX and I think it is time to show our gratitude. If he needs these features for his thesis, we should take care of them. (After all, if the work was done in past, it does not really violate the feature freeze, does it? :-) ) I don't think a quick release is that important. If you would do this alpha release, and then add a phase of two or three weeks of fixing known bugs that are already in 1.4 (and of course all that appear in the alpha release), then this delay will be very worthwhile. I would imagine that not only safe fixes are allowed in this phase, but also some mildly risky ones. After that phase the rules would be stricter. The alpha release should come quickly such that people stay focused. However, there should be multiple pre-releases. We need time to address all open bugs. What's wrong with a new pre-release every two weeks? Michael
Re: Is it time to rename .C to .cpp now?
Am Dienstag, 24. Oktober 2006 21:58 schrieb Bo Peng: > > please not that in this case it is not necessary to run > > autogen.sh or configure. That is only needed for bigger changes > > (deleting/adding a directory etc.) > > My understanding is every addition/removal of files leads to > autogen.sh. Yes and No. The auto stuff is supposed to detect such changes and run the necessary programs automatically. This normally works for simple file addition/removal, but for more complicated changes autogen.sh is indeed needed. Georg
Re: Random notes
On Tue, Oct 24, 2006 at 09:59:07AM -0500, Bo Peng wrote: > > I don't know what others think, but I would not add a mistake to another > > mistake. I mean, it was a mistake the sudden drop of qt3, but now that > > the decision was made it would be another mistake to revert it. > > However, I would like to know what Bo thinks about it, as he is left > > in the cold with his Cygwin port. > > I fully agree with Enrico and it would be another mistake to revert > qt3. I like qt3 and it is almost good enough for me. But once we > remove it, let it go peacefully, please. > > As of cygwin, it would be difficult to port lyx-1.5/qt4 to it since > cygwin does not have qt4 yet (have not checked the latest version). It > does not really matter though since qt4 will come up eventually, and > lyx-1.4.x will still exist for a while, right? I think you're right. Qt4/X11 might be ported to Cygwin sooner than later. In the meantime I'll try to let it compile and run using my Qt4/Win ;-) -- Enrico
Re: Is it time to rename .C to .cpp now?
please not that in this case it is not necessary to run autogen.sh or configure. That is only needed for bigger changes (deleting/adding a directory etc.) My understanding is every addition/removal of files leads to autogen.sh. They are frankly not rare events. No, Lars has some not merged branches. I wo't oppose such a change, but I won't do it either. Then we wil never be able to do it since everyone has his unmerged branches. It is the best time I have seen in months because all big changes are in trunk. Other votes? (I should have proposed this to Denmark people, since they can vote easily, or act without votes.) Bo
Re: UI for New/Close Window
Here a first attempt for tabs, it's the JMarc approach,
because it's the simples way. It's only a additional
switch by a QTabBar, but I don't know how to get the
current name and how to emit a switch signal.
Peter
Index: LyXView.h
===
--- LyXView.h (revision 15526)
+++ LyXView.h (working copy)
@@ -153,6 +153,9 @@
/// updates the title of the window
void updateWindowTitle();
+/// updates the tab view
+ virtual void updateTab() = 0;
+
/// reset autosave timer
void resetAutosaveTimer();
Index: qt4/GuiView.h
===
--- qt4/GuiView.h (revision 15526)
+++ qt4/GuiView.h (working copy)
@@ -26,7 +26,7 @@
#include
class QToolBar;
-
+class TabHeader;
//class FuncRequest;
//class string;
@@ -66,6 +66,8 @@
virtual void clearMessage();
virtual bool hasFocus() const;
+virtual void updateTab();
+
/// show - display the top-level window
void show();
@@ -75,6 +77,7 @@
/// menu item has been selected
void activated(FuncRequest const &);
+void initTab(QWidget* workArea);
Q_SIGNALS:
void closing(int);
@@ -86,6 +89,8 @@
/// populate a toplevel menu and all its children on demand
void updateMenu(QAction *);
+void currentTabChanged (int index);
+
protected:
/// make sure we quit cleanly
virtual void closeEvent(QCloseEvent * e);
@@ -116,6 +121,8 @@
void updateFloatingGeometry();
///
QRect floatingGeometry_;
+
+TabHeader* t;
};
} // namespace frontend
Index: qt4/GuiImplementation.C
===
--- qt4/GuiImplementation.C (revision 15526)
+++ qt4/GuiImplementation.C (working copy)
@@ -104,6 +104,7 @@
view->setWorkArea(work_areas_[id]);
view->setCentralWidget(work_areas_[id]);
+view->initTab(work_areas_[id]);
return id;
}
Index: qt4/GuiView.C
===
--- qt4/GuiView.C (revision 15526)
+++ qt4/GuiView.C (working copy)
@@ -45,14 +45,29 @@
#include
#include
#include
+#include
-
#include
using std::string;
using std::endl;
+class TabHeader : public QWidget
+{
+public:
+ QTabBar* tabbar;
+ TabHeader(QWidget* w)
+ {
+ tabbar = new QTabBar;
+ QVBoxLayout* l = new QVBoxLayout;
+ l->addWidget(tabbar);
+ l->addWidget(w);
+ l->setMargin(0);
+ setLayout(l);
+ }
+};
+
namespace lyx {
using support::subst;
@@ -67,6 +82,7 @@
} // namespace anon
+
GuiView::GuiView(int id)
: QMainWindow(), LyXView(id), commandbuffer_(0)
{
@@ -222,7 +238,25 @@
statusbar_timer_.stop();
}
+void GuiView::initTab(QWidget* workarea)
+{
+t = new TabHeader(workarea);
+setCentralWidget(t);
+QObject::connect(t->tabbar, SIGNAL(currentChanged(int)),
+ this, SLOT(currentTabChanged(int)));
+}
+void GuiView::currentTabChanged (int index)
+{
+
+}
+
+void GuiView::updateTab()
+{
+QString getName("todo");
+t->tabbar->addTab(getName);
+}
+
void GuiView::updateStatusBar()
{
// let the user see the explicit message
Index: LyXView.C
===
--- LyXView.C (revision 15526)
+++ LyXView.C (working copy)
@@ -144,6 +144,7 @@
updateToolbars();
updateLayoutChoice();
updateWindowTitle();
+updateTab();
if (loaded) {
connectBuffer(*work_area_->bufferView().buffer());
showErrorList("Parse");
Re: Is it time to rename .C to .cpp now?
Am Dienstag, 24. Oktober 2006 21:20 schrieb Bo Peng: > The 'scons advantage' in another email means there is always one > command to run. No autogen.sh, no configure. scons runs (cached) > configure every time and ensure a correct build. Ah, I see, but please not that in this case it is not necessary to run autogen.sh or configure. That is only needed for bigger changes (deleting/adding a directory etc.) > In this moc case, I have to ask again: > > is it time to rename .C to .cpp now? ** > > We are at the end of *big* changes and all big branches have been > merged. No, Lars has some not merged branches. I wo't oppose such a change, but I won't do it either. Georg
Re: [patch] fix inputenc
Am Dienstag, 24. Oktober 2006 15:37 schrieb Jean-Marc Lasgouttes:
> > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>
> Georg> This patch resurrects inputenc support.
>
> It look great to me. The only missing link is being able to export
> latex names as fallback, but I do not know how difficult this is.
What do you mean with latex names? If you mean to export some characters
like ö to \"o, then this is something I did not look at on purpose. For me
it was important that everything that works in 1.4 will also work in 1.5.
As I wrote in another mail, exporting unicode characters to LaTeX commands
is an additional feature that IMHO is not needed for 1.5 if it is too much
work.
Or do you mean that something else is missing that was possible in 1.4?
> What about docbook? Is this always utf8?
AFAIK docbook files can be encoded in utf8, latin1 and a number of other
encodings, but all relevant tools are able to process utf8.
> Georg> As stated in the comment there is one hack, but it is
> Georg> acceptable IMO because the alternative would be to do LaTeX
> Georg> export to narrow streams and calling an explicit conversion
> Georg> function in every inset.
>
> From reading the code and comment, I did not understand what happens
> at this place of the code.
Is this changed comment understandable?
if (change_encoding) {
lyxerr[Debug::LATEX] << "Converting paragraph to encoding "
<< language->encoding()->iconvName() << endl;
docstring const par = par_stream.str();
// Convert the paragraph to the 8bit encoding that we need to
// output.
std::vector const encoded = lyx::from_ucs4(par.c_str(),
par.size(), language->encoding()->iconvName());
// Interpret this as if it was in the 8 bit encoding of the
// document language and convert it back to UCS4. That means
// that faked does not contain pure UCS4 anymore, but what
// will be written to the output file will be correct, because
// the real output stream will do a UCS4 -> document language
// encoding conversion.
// This is of course a hack, but not a bigger one than mixing
// two encodings in one file.
// FIXME: Catch iconv conversion errors and display an error
// dialog.
std::vector const faked = lyx::to_ucs4(encoded.data(),
encoded.size(), doc_language->encoding()->iconvName());
std::vector::const_iterator const end = faked.end();
std::vector::const_iterator it = faked.begin();
for (; it != end; ++it)
ucs4.put(*it);
}
If not I have to think more.
Georg
Re: Random notes
Am Dienstag, 24. Oktober 2006 01:07 schrieb José Matos: > Again following the previous reasoning, I propose the following, we should > revert the removal of qt3 from lyx 1.5, now that we have manage to keep it > until the feature freeze it would look like throwing the baby with the water > (following one previous analogy of Angus on this list). > > This should only be done on the condition that there are people interested in > having it on shape for 1.5 release. Georg and Jürgen do I assume correctly > that you would welcome this change? No. IMO it was a mistake to skip the "let those who care keep it working in svn while others ignore it" phase. But now the baby is already thrown out and dead. I was willing to keep the qt3 frontend working as long as that would not require too much work, because it was mature and I believe it would have been useful for a number of people. That worked quite well during the last weeks, because Abdel's qt4 code was well written and I could adapt it quickly to qt3. I am not willing to bring it back to life, resurrecting all the many bits that are required for that would be far too much effort. > Georg you have mentioned other changes, what are they? Several bugs in bugzilla with the fileformat keyword: http://bugzilla.lyx.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=fileformat&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED Most of them are simple, and we can only fix these for a major release. Some of them were postponed from 1.2.0 to 1.3.0 to to 1.4.0 to 1.5.0, because they were not allowed to be fixed in freeze mode because of the freeze, and were not allowed to be fixed after the .0 releaswe because of the file format change. At least the easy ones should be fixed, otherwise they will stay open forever. I don't have patches for these, and it is unlikely I'll work on them, but I really think it is important to fix them. Then I have more or less finished support for esint that I need for my thesis: http://bugzilla.lyx.org/show_bug.cgi?id=2108 Current support for integrals other than \int in LyX is a mess. symbols from several not matching fonts are used. Then I think it would be a very bad idea to not put the nomencl inset in 1.5.0. It is finished, I have a few minor complaints that I will send the next week when Ugras is back from his holidays, but these issues can easily be fixed. lyx2lyx conversion is also almost finished, and finally there is no risk to break existing stuff. Another important point is complete support for \xymatrix: http://bugzilla.lyx.org/show_bug.cgi?id=2238 Since it is not possible in mathed to enter known commands as ERT you can not use everything that \xymatrix offers. Prof. Gumm complained some time ago about this, and he was right. After a hard fight I was able to commit a fix during the 1.4.0 freeze that brought back at least the level of support that 1.3.x had. This was a regression, the fix was safe and indeed so far no bugs resulting from this were discovered, so it was IMO no question to put it in. This is an example for a exhausting discussion I will no longer take part in. As a first step it would be enough if mathed was able to read and write all \xymatrix arguments correctly. Then you can e.g. write the formula as text and convert it to math, or correctly import existing documents with tex2lyx. I already haven an almost working implementation of this first step. > Some of your changes in the 1.4 branch seem quite interesting. The image cache works well now. The only thing that would be needed before it can be put in trunk are some lyxrc options for cache size, cache file lifetime and code that uses these options to cleanup the cache. The navigation across child documents is also stable, but it has the problem that it causes all child documents to be loaded if you open the master, and this can take some time. Either we need to speed up loading of a document (actually I don't know why it is so slow), or we need to implement loading of child documents in the background. I do not want to push either of these into 1.5.0, but if somebody has a good idea how to solve the remaining problems it may be sensible to include one or both. I implemented the first for large documents with many images, and the second one because it is essential for navigating in my thesis. Both are applications where LyX is supposed to make the life easier. The rest in my branch is either already in trunk, bug fixing stuff or incomplete. > I would like to have a tentative date for a pre-release. How much time do the > respective owners expect to need to have the new features in such a state > that they can be presented to users without having them screaming away? This week I will only finish the command inset lyx2lyx stuff. I
Is it time to rename .C to .cpp now?
Yes. The GuiImplementation files are missing from Makefile.dialogs. Sorry Bo, that is no scons advantage, you have to add them to scons.manifest as well (which is already done). The 'scons advantage' in another email means there is always one command to run. No autogen.sh, no configure. scons runs (cached) configure every time and ensure a correct build. In this moc case, I have to ask again: is it time to rename .C to .cpp now? ** We are at the end of *big* changes and all big branches have been merged. I would propose that we do this now, before we all turn to the bug fixing mode. (This is relevant to the moc problem because scons can not automatically moc the files because of the .C extension.) Cheers, Bo
Re: [patch] new InsetCommandParams
Am Dienstag, 24. Oktober 2006 16:15 schrieb Jean-Marc Lasgouttes: > > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: > > Georg> Can somebody add him to the credits stuff please? I don't know > Georg> how that works. > > I did it (also for the new Galician translator). Thanks. > Please check that I > did it right (I kind of guessed the alphabetic ordering). Ugras, I do not really know how the components of your name fit together, so please check this. Georg
Re: rev 15538 does not compile
Am Dienstag, 24. Oktober 2006 20:54 schrieb José Matos: > make[7]: *** [GuiImplementation.lo] Error 1 > > Anyone else sees this? Yes. The GuiImplementation files are missing from Makefile.dialogs. Sorry Bo, that is no scons advantage, you have to add them to scons.manifest as well (which is already done). Georg
Re: [patch] new InsetCommandParams
Jean-Marc Lasgouttes wrote: Also, Michael, you should not change CREDITS directly, but edit generate_contributions.py. I propagated your latest change. Thank you very much! (You must be watching the svn logs very very carefully.) Michael
Re: rev 15538 does not compile
José Matos wrote: Hi, when updating today I get this: make[7]: Entering directory `/home/jamatos/lyx/lyx-devel/src/frontends/qt4' if /bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -I../../../src -I../../../src/frontends -I../../../images -DQT_SHARED -I/usr/include/QtCore -I/usr/include/QtGui -I../../../boost -I../../../src/frontends/controllers -Wextra -Wall -O -MT GuiImplementation.lo -MD -MP -MF ".deps/GuiImplementation.Tpo" -c -o GuiImplementation.lo GuiImplementation.C; \ then mv -f ".deps/GuiImplementation.Tpo" ".deps/GuiImplementation.Plo"; else rm -f ".deps/GuiImplementation.Tpo"; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -I../../../src -I../../../src/frontends -I../../../images -DQT_SHARED -I/usr/include/QtCore -I/usr/include/QtGui -I../../../boost -I../../../src/frontends/controllers -Wextra -Wall -O -MT GuiImplementation.lo -MD -MP -MF .deps/GuiImplementation.Tpo -c GuiImplementation.C -o GuiImplementation.o GuiImplementation.C:156:37: error: GuiImplementation_moc.cpp: No such file or directory make[7]: *** [GuiImplementation.lo] Error 1 Anyone else sees this? yeah, but it went away after running cmake again...
rev 15538 does not compile
Hi, when updating today I get this: make[7]: Entering directory `/home/jamatos/lyx/lyx-devel/src/frontends/qt4' if /bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -I../../../src -I../../../src/frontends -I../../../images -DQT_SHARED -I/usr/include/QtCore -I/usr/include/QtGui -I../../../boost -I../../../src/frontends/controllers -Wextra -Wall -O -MT GuiImplementation.lo -MD -MP -MF ".deps/GuiImplementation.Tpo" -c -o GuiImplementation.lo GuiImplementation.C; \ then mv -f ".deps/GuiImplementation.Tpo" ".deps/GuiImplementation.Plo"; else rm -f ".deps/GuiImplementation.Tpo"; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -I../../../src -I../../../src/frontends -I../../../images -DQT_SHARED -I/usr/include/QtCore -I/usr/include/QtGui -I../../../boost -I../../../src/frontends/controllers -Wextra -Wall -O -MT GuiImplementation.lo -MD -MP -MF .deps/GuiImplementation.Tpo -c GuiImplementation.C -o GuiImplementation.o GuiImplementation.C:156:37: error: GuiImplementation_moc.cpp: No such file or directory make[7]: *** [GuiImplementation.lo] Error 1 Anyone else sees this? -- José Abílio
Re: About scrolling speed
Martin Vermeer wrote: By the way, I cannot see any text rendering difference between the two version. Looks to me that the text is anti-aliased in both cases. Looks to me that this setRenderHint() is just a helper for something else. In windows, you can turn off anti-aliasing. The Qt setRenderHint overrides that setting. When you turned anti-aliasing off, you should not comment out the setRenderHint, but rather call it with a ",false" as second parameter. I notice now that one of the machines we were using had anti-aliasing turned off in windows, so that's the explanation. I guess you can remove those setRenderHint lines, so that we respect the windows setting people might have. Regards, Asger
Re: The cursor is seriously broken..
Abdelrazak Younes wrote:
I have just fixed that. Very simple... I should look at the code before
commenting... The former state was probably due to temporary debugging
state from Andre :-)
i think that the positioning of the cursor is nicer with the attached
(moves it 2 pixels to the right...)
Index: GuiWorkArea.C
===
--- GuiWorkArea.C (revision 15537)
+++ GuiWorkArea.C (working copy)
@@ -599,7 +599,7 @@
void GuiWorkArea::showCursor(int x, int y, int h, CursorShape shape)
{
- cursor_->setGeometry(x, y, 2, h);
+ cursor_->setGeometry(x + 2, y, 2, h);
cursor_->shape_ = shape;
cursor_->on_ = true;
cursor_->show();
Re: Invalid formatting code
Juergen Spitzmueller wrote: Hm, yes, would be fine with me (i.e. %A, %x), even though the output is different to what we have now, of course. Do we need to include %A? I think %x alone would be enough. %#x gives the date plus weekday in the current locale on Windows. Is there a UNIX equivalent? Joost
Re: About scrolling speed
On Tue, Oct 24, 2006 at 05:53:05PM +0200, Abdelrazak Younes wrote: > Asger Ottar Alstrup wrote: ... > By the way, I cannot see any text rendering difference between the two > version. Looks to me that the text is anti-aliased in both cases. Looks > to me that this setRenderHint() is just a helper for something else. Yes. http://en.wikipedia.org/wiki/Font_hinting - Martin pgpxT3KrYkB1o.pgp Description: PGP signature
Re: Invalid formatting code
On Tuesday 24 October 2006 2:46 pm, Jean-Marc Lasgouttes wrote: > > "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: > > Juergen> Jean-Marc Lasgouttes wrote: > >> Can boost do that for us? > > Juergen> No idea. Which method do you think of? > > Well, I hoped somebody would look for it :) So, I went to boost.org, > and it seems that there is a library that _may_ be useful: > http://www.boost.org/doc/html/date_time.html > > Now the question is whether we need something so complicated. Since we require python we can use it, the module time has what you are requiring... We can either call it through its C interface or use a pipe to get a result. Just an idea. > JMarc -- José Abílio
Re: [Patch] updated fix for 2550
On Tue, Oct 24, 2006 at 04:27:57PM +0200, Jean-Marc Lasgouttes wrote: > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > Martin> On Thu, Oct 19, 2006 at 03:41:39PM +0200, Jean-Marc Lasgouttes > Martin> wrote: > >> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > >> > Martin> Attached. Can this go in (trunk)? > >> Why not. If it works, I want this in 1.4 too. > >> > >> JMarc > > Martin> Here is the 1.4 version. Works for me. > > Please apply. Ah, it's already in, r15415. Seems I neglected to post to the list. - Martin pgpmYNJpJaxaZ.pgp Description: PGP signature
Re: The cursor is seriously broken..
Abdelrazak Younes wrote: Hi Andre, I just merged my tree with SVN and I see now big black blinking square instead of the cursor. Anybody else seeing that? I have just fixed that. Very simple... I should look at the code before commenting... The former state was probably due to temporary debugging state from Andre :-) So, painting wise, I'd say that LyX is in a pretty good shape :-) Abdel.
Re: About scrolling speed
Abdelrazak Younes wrote: One thing that is maybe impacting the scrolling speed is the bogus cursor. I guess painting a big square square in addition does not help. Indeed... Without it, the UserGuide test is now at 15 seconds! That's better than ever! By the way, you will need the attached patch to disable the cursor. Abdel. Index: frontends/WorkArea.C === --- frontends/WorkArea.C(revision 15520) +++ frontends/WorkArea.C(working copy) @@ -288,7 +288,7 @@ return; cursor_visible_ = true; - showCursor(x, y, h, shape); + //showCursor(x, y, h, shape); }
Re: r 15535 does not compile.
Bo Peng wrote:
Index: src/lyxfunc.C
===
--- src/lyxfunc.C (revision 15535)
+++ src/lyxfunc.C (working copy)
@@ -1039,7 +1039,7 @@
view()->saveSavedPositions();
}
- LyX::ref().quit(argument == "force");
+ LyX::ref().quit();
break;
case LFUN_TOC_VIEW: {
Is needed, but I am not sure this should be done. Abdel, have you
overlooked something?
Yes, and the fix is already in.
Abdel.
About multiple windows and typing speed
Hello, As to experiment wether LyX is really that slow or not, I've made a little experiment: 1) Open the UserGuide in 5 different windows (choose "Switch to document" in order to have synchronized view of the same document. 2) type as fast as you can. There's an almost imperceptible delay before each character is shown on screen (I'd say less that 0.2 seconds) and the 5 views are updated at the same time on two different screens; my laptop has a dual head video card: - 3 window on the CRT screen - 2 window on my laptop screen I don't know about linux and MacOS but I personally don't need LyX to be any faster, thank you very much. Abdel.
Re: UI for New/Close Window
Joost Verburg wrote: Enrico Forestieri wrote: Indeed, I can confirm that what I said is true in Office 2000 powerpoint, don't know for later versions. What I meant to say is that the X button should never close all open document windows. With current trunk, this doesn't even close a single document if there's still one window opened and I like this very much. Abdel.
Re: LyX does not compile
I guess you also need to ./autogen.sh. Another reason why scons is more convenient. :-) No autogen.sh, no configure.sh. Bo
Re: About scrolling speed
Abdelrazak Younes wrote: Asger Ottar Alstrup wrote: Abdelrazak Younes wrote: Before Denmark, the UserGuide PageDown test was at 18 seconds. Now it is at 25 seconds. I hope you have some more code in store for speed ;-) It might very well be the anti-aliasing we enabled. Can you try to revert that? Just search for setRenderHint and comment those guys out. If this is the case, I guess anti-aliasing should be optional through some preference setting. The difference is minimal but it is there, I now have better results with a different window size: - 21 s with setRenderHint(QPainter::TextAntialiasing) - 22-23 s without. So I guess this setRenderHint() is not guilty of anything. If anything, I would say the contrary. One thing that is maybe impacting the scrolling speed is the bogus cursor. I guess painting a big square square in addition does not help. Indeed... Without it, the UserGuide test is now at 15 seconds! That's better than ever! There's some bright light at the end of the tunnel :-) Abdel.
Re: UI for New/Close Window
Enrico Forestieri wrote: Indeed, I can confirm that what I said is true in Office 2000 powerpoint, don't know for later versions. What I meant to say is that the X button should never close all open document windows. The current Office versions work fine, so it looks like a stupid mistake in Office/Powerpoint 2000. Joost
Re: LyX does not compile
Bennett Helm wrote: On Oct 24, 2006, at 2:22 AM, Abdelrazak Younes wrote: Bo Peng wrote: On 10/23/06, Michael Gerz <[EMAIL PROTECTED]> wrote: Abdel, can you help me? This is due to a scons_manifest problem. Will be fixed in five minutes. I could have sweared I did the right change... I probably f***ed up the scons change when I merged my tree. Sorry about that. I have the same problem, but I don't use scons. make clean in qt4/, reconfigure, make, and I still get GuiImplementation.C:123:37: error: GuiImplementation_moc.cpp: No such file or directory I guess you also need to ./autogen.sh. Abdel.
Re: LyX does not compile
make clean in qt4/, reconfigure, make, and I still get GuiImplementation.C:123:37: error: GuiImplementation_moc.cpp: No such file or directory Someone needs to update autotools. Not me for the next few hours. Maybe you can figure it out by yourself. Bo
Re: About scrolling speed
Asger Ottar Alstrup wrote: Abdelrazak Younes wrote: Before Denmark, the UserGuide PageDown test was at 18 seconds. Now it is at 25 seconds. I hope you have some more code in store for speed ;-) It might very well be the anti-aliasing we enabled. Can you try to revert that? Just search for setRenderHint and comment those guys out. If this is the case, I guess anti-aliasing should be optional through some preference setting. The difference is minimal but it is there, I now have better results with a different window size: - 21 s with setRenderHint(QPainter::TextAntialiasing) - 22-23 s without. So I guess this setRenderHint() is not guilty of anything. If anything, I would say the contrary. One thing that is maybe impacting the scrolling speed is the bogus cursor. I guess painting a big square square in addition does not help. By the way, I cannot see any text rendering difference between the two version. Looks to me that the text is anti-aliased in both cases. Looks to me that this setRenderHint() is just a helper for something else. Abdel.
Re: LyX does not compile
On Oct 24, 2006, at 2:22 AM, Abdelrazak Younes wrote: Bo Peng wrote: On 10/23/06, Michael Gerz <[EMAIL PROTECTED]> wrote: Abdel, can you help me? This is due to a scons_manifest problem. Will be fixed in five minutes. I could have sweared I did the right change... I probably f***ed up the scons change when I merged my tree. Sorry about that. I have the same problem, but I don't use scons. make clean in qt4/, reconfigure, make, and I still get GuiImplementation.C:123:37: error: GuiImplementation_moc.cpp: No such file or directory Bennett
Re: [patch] fix inputenc
Jean-Marc Lasgouttes wrote: > My point is that I may not be the only one in this situation. LaTeX is > supposed to be very stable, after all. I know. I share these concerns. Jürgen
r 15535 does not compile.
Index: src/lyxfunc.C
===
--- src/lyxfunc.C (revision 15535)
+++ src/lyxfunc.C (working copy)
@@ -1039,7 +1039,7 @@
view()->saveSavedPositions();
}
- LyX::ref().quit(argument == "force");
+ LyX::ref().quit();
break;
case LFUN_TOC_VIEW: {
Is needed, but I am not sure this should be done. Abdel, have you
overlooked something?
Bo
Re: Invalid formatting code
Jean-Marc Lasgouttes wrote: > l7n? localization. Seems I missed some chars ;-) Jürgen
Re: LyX does not compile
I could have sweared I did the right change... I probably f***ed up the scons change when I merged my tree. Sorry about that. Not a problem. You could not have done anything if you had to change cmake, scons and autotools. :-) I can take care of scons, this is the least I can do to help. Bo
Re: UI for New/Close Window
Jean-Marc Lasgouttes wrote: "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> There are two solutions: Abdelrazak> 1) Make the central widget a QTabWidget in GuiView (which Abdelrazak> is a QMainApplication). Then host a new QWorkArea for each Abdelrazak> tab. In this context, this would mean that two WorkArea in Abdelrazak> two tabs or in two split windows would look the same to Abdelrazak> the parent GuiView. Abdelrazak> 2) Make the GuiWorkArea viewport a tab widget and handle Abdelrazak> the buffer switch there. This would mean that there's only Abdelrazak> one WorkArea. Abdelrazak> I like 1) more but 2) might be easier to do. I do not know how this fits in your discussion, but we could just have a tab strip (in a backend toolbar, maybe?) and manage the switches by hand (with LFUNs). Well, that is a possibility indeed (using QTabBar instead of the full blown QTabWidget). But I'd rather use QTabWidget with solution 1) because this will allow us to do nitty things like "Detach Tab in new Window" or "Detach Tab in split Window". > I suspect that letting Qt handle all that will > remove some of our liberty. Pensée du Jour: Liberty is good only if you make use of it. Abdel.
Re: Random notes
I don't know what others think, but I would not add a mistake to another mistake. I mean, it was a mistake the sudden drop of qt3, but now that the decision was made it would be another mistake to revert it. However, I would like to know what Bo thinks about it, as he is left in the cold with his Cygwin port. I fully agree with Enrico and it would be another mistake to revert qt3. I like qt3 and it is almost good enough for me. But once we remove it, let it go peacefully, please. As of cygwin, it would be difficult to port lyx-1.5/qt4 to it since cygwin does not have qt4 yet (have not checked the latest version). It does not really matter though since qt4 will come up eventually, and lyx-1.4.x will still exist for a while, right? Cheers, Bo
Re: [Patch] Fix some LFUN_WINDOW_CLOSE bugs.
[EMAIL PROTECTED] wrote: On Tue, 24 Oct 2006, Abdelrazak Younes wrote: Hello, This patch sanitize the different way to exit from lyx: 1) exit request with a direct call to LFUN_WINDOW_CLOSE: user menu. 2) automatic exit when the last window is closed. Does this change the description in any way? No. (For some reason, while reading the above I assumed that LFUN_WINDOW_CLOSE would invoke LYX_QUIT if it was the last window. That's right. This might not be the case, but I thought I'd better check if the description needs to be altered). The function 'window-close' closes the active LyX window. If no LyX window is currently in focus, the last window in focus will be closed, and closing the last LyX window will also close LyX. See 'window-new' for more details. /C
Re: [patch] fix inputenc
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Jean-Marc Lasgouttes wrote: >> PS: especially since the teTeX 2.0 on my machine does not do utf8 >> :( Juergen> teTeX 2.0 was released in Feb 2003, initial, "partial, Juergen> experimental" support for utf8 in unicode with the LaTeX Juergen> 2003-12 release (see Juergen> http://www.latex-project.org/ltnews/ltnews15.pdf). Juergen> So you'd need teTeX 3 at least (or TeXLive 2004 at least). My point is that I may not be the only one in this situation. LaTeX is supposed to be very stable, after all. JMarc
Re: [patch] fix inputenc
Jean-Marc Lasgouttes wrote: > PS: especially since the teTeX 2.0 on my machine does not do utf8 :( teTeX 2.0 was released in Feb 2003, initial, "partial, experimental" support for utf8 in unicode with the LaTeX 2003-12 release (see http://www.latex-project.org/ltnews/ltnews15.pdf). So you'd need teTeX 3 at least (or TeXLive 2004 at least). Jürgen
Re: Invalid formatting code
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Jean-Marc Lasgouttes wrote: >> Well, I hoped somebody would look for it :) So, I went to >> boost.org, and it seems that there is a library that _may_ be >> useful: http://www.boost.org/doc/html/date_time.html Juergen> Hm, seems to be more l7n-friendly than strftime, from what I Juergen> can see. l7n? JMarc
Re: Invalid formatting code
Jean-Marc Lasgouttes wrote: > Well, I hoped somebody would look for it :) So, I went to boost.org, > and it seems that there is a library that _may_ be useful: > http://www.boost.org/doc/html/date_time.html Hm, seems to be more l7n-friendly than strftime, from what I can see. > Now the question is whether we need something so complicated. I don't know. Jürgen
Re: About scrolling speed
Jean-Marc Lasgouttes wrote: > http://www.aa.org/en_information_aa.cfm I see, thanks. That's indeed something different than AAA (and the LyX meetings, as far as I can see). Jürgen
Re: [Patch] updated fix for 2550
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> On Thu, Oct 19, 2006 at 03:41:39PM +0200, Jean-Marc Lasgouttes Martin> wrote: >> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: >> Martin> Attached. Can this go in (trunk)? >> Why not. If it works, I want this in 1.4 too. >> >> JMarc Martin> Here is the 1.4 version. Works for me. Please apply. JMarc
Re: Is this a math bug of 1.4.3
On Tue, Oct 24, 2006 at 02:43:22PM +0200, Jean-Marc Lasgouttes wrote:
> > "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
>
> Peter> Enrico Forestieri wrote:
> >> On Tue, Oct 24, 2006 at 09:06:18AM +0200, Jean-Marc Lasgouttes
> >> wrote:
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
> Enrico> There is instead a bug in the Windows version as when you type
> Enrico> {whatever}^2 everything enclosed by braces disappear...
> >>> Do we know more about this ?
> >> It seems to be due to MSVC, as I don't get it using GCC. I think
> >> Peter was investigating it.
> >>
>
> Peter> Yes, only msvc eats 'whatever' but I didn't found the reason
> Peter> for this.
>
> It is when doing cut and paste, right? Is it the selection that is
> wrong or the paste operation?
No, this also happens when you directly use the keyboard to write it in.
Clearly, you hit \{ to obtain the brace inset.
--
Enrico
Re: [Patch] Fix some LFUN_WINDOW_CLOSE bugs.
On Tue, 24 Oct 2006, Abdelrazak Younes wrote: > Hello, > > This patch sanitize the different way to exit from lyx: > > 1) exit request with a direct call to LFUN_WINDOW_CLOSE: user menu. > > 2) automatic exit when the last window is closed. Does this change the description in any way? (For some reason, while reading the above I assumed that LFUN_WINDOW_CLOSE would invoke LYX_QUIT if it was the last window. This might not be the case, but I thought I'd better check if the description needs to be altered). The function 'window-close' closes the active LyX window. If no LyX window is currently in focus, the last window in focus will be closed, and closing the last LyX window will also close LyX. See 'window-new' for more details. /C -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: [patch] new InsetCommandParams
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> Can somebody add him to the credits stuff please? I don't know Georg> how that works. I did it (also for the new Galician translator). Please check that I did it right (I kind of guessed the alphabetic ordering). Also, Michael, you should not change CREDITS directly, but edit generate_contributions.py. I propagated your latest change. JMarc
Re: Invalid formatting code
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Jean-Marc Lasgouttes wrote: >> Can boost do that for us? Juergen> No idea. Which method do you think of? Well, I hoped somebody would look for it :) So, I went to boost.org, and it seems that there is a library that _may_ be useful: http://www.boost.org/doc/html/date_time.html Now the question is whether we need something so complicated. JMarc
Re: About scrolling speed
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> What's AA? I only know the AAA meetings. http://www.aa.org/en_information_aa.cfm JMarc
Re: Random notes
> "José" == José Matos <[EMAIL PROTECTED]> writes: José> Mixing the two previous paragraphs, that means that we should José> release a product as soon as possible when certain requirements José> are met, those requirements are: - to have a stable frontend; - José> no (known) regressions are allowed against old documents, if a José> document works for 1.4 it should work as well in 1.5 without any José> change from user. - The last requirement does not applies José> vice-versa, it is possible to have a document that works for 1.5 José> that when backported does not work for 1.4, I will try to fix José> those cases but they are not our priority (back-port is a José> convenience). Agreed. José> My proposal follows that coming from the meeting to enter a José> period of feature freeze, that is no more features are allowed José> at this point. Our goal now should be to stabilise the new José> changes and to coordinate with the present stable branch to make José> the transition the smoothest possible for the new stable release José> (1.5 when released). OK. José> Again following the previous reasoning, I propose the José> following, we should revert the removal of qt3 from lyx 1.5, now José> that we have manage to keep it until the feature freeze it would José> look like throwing the baby with the water (following one José> previous analogy of Angus on this list). I guess Juergen and Georg are the ones who can answer to this. Were there many changes after qt3 was nuked? José> For 1.6 I propose to remove qt3 and completely have it José> superseeded by qt4. This is OK. Thanks for doing that José, JMarc
Re: About scrolling speed
José Matos wrote: > It will be fun to have at one of the meetings and say "Hello, my name is > Jürgen S. and I am a lyx developer". I'll noted that sentence for the case I'll enter reality ;-) > That will make the meeting look like an AA meeting, I can only laugh with > such analogy. ;-) What's AA? I only know the AAA meetings. Jürgen
Re: [patch] fix inputenc
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> This patch resurrects inputenc support. It look great to me. The only missing link is being able to export latex names as fallback, but I do not know how difficult this is. What about docbook? Is this always utf8? Georg> As stated in the comment there is one hack, but it is Georg> acceptable IMO because the alternative would be to do LaTeX Georg> export to narrow streams and calling an explicit conversion Georg> function in every inset. >From reading the code and comment, I did not understand what happens at this place of the code. This patch seems to go in the right direction. JMarc PS: especially since the teTeX 2.0 on my machine does not do utf8 :(
Re: Invalid formatting code
Jean-Marc Lasgouttes wrote: > Can boost do that for us? No idea. Which method do you think of? > We could also set the date format in lyxrc.dist and be done with it. Yes, why not. Jürgen
Re: About scrolling speed
> "Asger" == Asger Ottar Alstrup <[EMAIL PROTECTED]> writes: Asger> It might very well be the anti-aliasing we enabled. Can you try Asger> to revert that? Just search for setRenderHint and comment those Asger> guys out. If this is the case, I guess anti-aliasing should be Asger> optional through some preference setting. Are you sure this is anti aliasing? We always had this on... Hinting is something different. Asger> The profilings were conflicting depending on the tools used, Asger> but on Windows using Glowcode, my results showed that rendering Asger> alone took around 70% of all time. updateMetrics was next in Asger> line with 7%. The rest was scattered all over the place. Did you try documents with a lot of math in windows, like http://bugzilla.lyx.org/show_bug.cgi?id=2900 JMarc PS: thanks for the technical details. They _are_ appreciated.
Re: About scrolling speed
On Tuesday 24 October 2006 9:53 am, Juergen Spitzmueller wrote: > To clarify, Jürgen V. is the "real" Jürgen, I'm just a parvenu. It will be fun to have at one of the meetings and say "Hello, my name is Jürgen S. and I am a lyx developer". That will make the meeting look like an AA meeting, I can only laugh with such analogy. ;-) > Jürgen -- José Abílio
Re: UI for New/Close Window
> "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes: Joost> You're wrong here. Clicking the X only closes the current Joost> window, not the others. That's also how Microsoft Office works. Joost> Having both a "Close Window" menu entry and an X button is not Joost> necessary. This is wrong. Menus and windows decoration serve different purposes. Of course we should have both. It is like saying that LyX should not have a File>Quit menu entry. In particular, a menu entry can be used with the keyboard. JMarc
[Patch] Fix some LFUN_WINDOW_CLOSE bugs.
Hello,
This patch sanitize the different way to exit from lyx:
1) exit request with a direct call to LFUN_WINDOW_CLOSE: user menu.
2) automatic exit when the last window is closed.
I needed some more small changes to the LFUN in order to make this work
properly for all tested use cases.
Bo, concerning session stuff, I had to change things a bit again. So
now, the geometry saving is ensured to be done because LyXView::close()
is _always_ called on exit.
I am all ears WRT comments to the code and bug reports. But I can't work
on this in the short term so I am going going to commit this now as this
a clear improvement over the current situation.
Abdel.
Index: src/frontends/Gui.h
===
--- src/frontends/Gui.h (revision 15520)
+++ src/frontends/Gui.h (working copy)
@@ -46,6 +46,8 @@
virtual int newWorkArea(unsigned int width, unsigned int height, int
view_id) = 0;
///
virtual WorkArea & workArea(int id) = 0;
+ ///
+ virtual bool closeAll() = 0;
///
std::vector const & viewIds() { return view_ids_; };
Index: src/frontends/qt4/Alert_pimpl.C
===
--- src/frontends/qt4/Alert_pimpl.C (revision 15520)
+++ src/frontends/qt4/Alert_pimpl.C (working copy)
@@ -28,24 +28,39 @@
#include
+using std::pair;
+using std::make_pair;
namespace lyx {
using lyx::support::bformat;
using lyx::docstring;
-using std::pair;
-using std::make_pair;
+namespace {
+class MessageBox: public QMessageBox
+{
+public:
+ MessageBox(QWidget * parent = 0): QMessageBox(parent)
+ {
+ setAttribute(Qt::WA_DeleteOnClose, true);
+ setAttribute(Qt::WA_QuitOnClose, false);
+ }
+};
+} // anonymous namespace
+
+
int prompt_pimpl(docstring const & tit, docstring const & question,
int default_button, int cancel_button,
docstring const & b1, docstring const & b2, docstring const &
b3)
{
docstring const title = bformat(_("LyX: %1$s"), tit);
+ MessageBox mb;
+
// FIXME replace that with theApp->gui()->currentView()
- int res = QMessageBox::information(qApp->focusWidget(),
+ int res = mb.information(qApp->focusWidget(),
toqstr(title),
toqstr(formatted(question)),
toqstr(b1),
@@ -63,7 +78,9 @@
void warning_pimpl(docstring const & tit, docstring const & message)
{
docstring const title = bformat(_("LyX: %1$s"), tit);
- QMessageBox::warning(qApp->focusWidget(),
+
+ MessageBox mb;
+ mb.warning(qApp->focusWidget(),
toqstr(title),
toqstr(formatted(message)));
}
@@ -72,7 +89,8 @@
void error_pimpl(docstring const & tit, docstring const & message)
{
docstring const title = bformat(_("LyX: %1$s"), tit);
- QMessageBox::critical(qApp->focusWidget(),
+ MessageBox mb;
+ mb.critical(qApp->focusWidget(),
toqstr(title),
toqstr(formatted(message)));
}
@@ -81,7 +99,8 @@
void information_pimpl(docstring const & tit, docstring const & message)
{
docstring const title = bformat(_("LyX: %1$s"), tit);
- QMessageBox::information(qApp->focusWidget(),
+ MessageBox mb;
+ mb.information(qApp->focusWidget(),
toqstr(title),
toqstr(formatted(message)));
}
Index: src/frontends/qt4/GuiApplication.C
===
--- src/frontends/qt4/GuiApplication.C (revision 15520)
+++ src/frontends/qt4/GuiApplication.C (working copy)
@@ -165,7 +165,7 @@
// trigger LFUN_LYX_QUIT instead of QApplication::quit() directly
// since LFUN_LYX_QUIT may have more cleanup stuff
- dispatch(FuncRequest(LFUN_LYX_QUIT));
+ dispatch(FuncRequest(LFUN_LYX_QUIT, "force"));
}
Index: src/frontends/qt4/GuiImplementation.C
===
--- src/frontends/qt4/GuiImplementation.C (revision 15520)
+++ src/frontends/qt4/GuiImplementation.C (working copy)
@@ -20,6 +20,7 @@
#include "GuiWorkArea.h"
#include "BufferView.h"
+#include "bufferlist.h"
#include "funcrequest.h"
#include "lyxfunc.h"
@@ -42,9 +43,6 @@
views_[id] = new GuiView(id);
view_ids_.push_back(id);
- QObject::connect(views_[id], SIGNAL(destroyed(QObject *)),
- this, SLOT(cleanupViews(QObject *)));
-
return id;
}
@@ -57,9 +55,39 @@
}
-void GuiImplementation::cleanupViews(QObject * qobj)
+bool GuiImplementation::closeAll()
{
- GuiView * view = static_cast(qobj);
+ if (!theBufferList().quitWriteAll())
+ return
Re: UI for New/Close Window
On Oct 24, 2006, at 3:12 AM, Jean-Marc Lasgouttes wrote: "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes: Joost> Now we have the possibility of multiple windows in a single Joost> instance, there is no need anymore to have multiple instances. Joost> Allowing only a single LyX process will make sure that there is Joost> only one version of the same document in memory (even though Joost> you can have multiple views of the same document), so you will Joost> never save the wrong version. This is already what happens in OSX. How would windows handle that? Yes. I thin that, like in firefox, we could have an option telling whether new/opened documents should be in a new window or in the same window. We are not going to get people to agree on that. I agree. I have found that on Macs, people expect the new window behavior and are confused when, upon opening a new file, LyX apparently closes the old file -- without giving them a chance to save it. (Of course that's false, but it's a natural assumption given the almost universal behavior of applications opening a new window for new documents. Only a few programs -- mostly designed for developers -- use tabs for separate editable documents.) Bennett
Re: UI for New/Close Window
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> There are two solutions: Abdelrazak> 1) Make the central widget a QTabWidget in GuiView (which Abdelrazak> is a QMainApplication). Then host a new QWorkArea for each Abdelrazak> tab. In this context, this would mean that two WorkArea in Abdelrazak> two tabs or in two split windows would look the same to Abdelrazak> the parent GuiView. Abdelrazak> 2) Make the GuiWorkArea viewport a tab widget and handle Abdelrazak> the buffer switch there. This would mean that there's only Abdelrazak> one WorkArea. Abdelrazak> I like 1) more but 2) might be easier to do. I do not know how this fits in your discussion, but we could just have a tab strip (in a backend toolbar, maybe?) and manage the switches by hand (with LFUNs). I suspect that letting Qt handle all that will remove some of our liberty. JMarc
Re: Invalid formatting code
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Joost Verburg wrote:
>> Juergen Spitzmueller wrote: > %e is not the same as %d, see my
>> comment on bugzilla.
>>
>> There is indeed a minor difference. %#d on Windows should be like
>> %e on UNIX.
>>
>> Why not use %x for both, which gives the date representation
>> appropriate for the current locale?
Juergen> Hm, yes, would be fine with me (i.e. %A, %x), even though the
Juergen> output is different to what we have now, of course. In the
Juergen> long term, I think we should provide different possibilities,
Juergen> like most word processors do ("Tuesday", "Tuesday, October 24
Juergen> 2006", "Tuesday, 24/10/2006", "24/10/2006" etc.). And I think
Juergen> we'd need to translate between the differing arguments of the
Juergen> original unix strftime and the ms rip-off nevertheless (i.e.
Juergen> %e <-> %#d etc.).
Can boost do that for us?
We could also set the date format in lyxrc.dist and be done with it.
JMarc
Re: About scrolling speed
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Abdelrazak Younes wrote: >> PS: I didn't know that there was two Jurgen in this list. I was >> confused by the fact Jurgen (S) criticized the Denmark people while >> he was part of them :-) Juergen> To clarify, Jürgen V. is the "real" Jürgen, I'm just a Juergen> parvenu. Well, these days you are the real Juergen, and he is a has been :) JMarc
Re: Is this a math bug of 1.4.3
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
Peter> Enrico Forestieri wrote:
>> On Tue, Oct 24, 2006 at 09:06:18AM +0200, Jean-Marc Lasgouttes
>> wrote:
"Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> There is instead a bug in the Windows version as when you type
Enrico> {whatever}^2 everything enclosed by braces disappear...
>>> Do we know more about this ?
>> It seems to be due to MSVC, as I don't get it using GCC. I think
>> Peter was investigating it.
>>
Peter> Yes, only msvc eats 'whatever' but I didn't found the reason
Peter> for this.
It is when doing cut and paste, right? Is it the selection that is
wrong or the paste operation?
JMarc
Re: Random notes
José Matos wrote: Hi fellow developers, So with this said I look forward to see Georg (who seems to always read my mind when it comes to lyx2lyx), Abdel (to pay you a beverage for qt4 work) or Noted ;-) As a release manager I am a firm believer in the principle of "releasing earlier, release often", I also believe that as a project we will only survive and thrive if we present a stable product to our users as well to (prospective) future developers. No one will waste their time if the developing platform is not stable. Right... Christmas (2006) would be a perfect date for a delivery :-). At least the goal should be to release 1.5.0 within a year after 1.4.0. My proposal follows that coming from the meeting to enter a period of feature freeze, that is no more features are allowed at this point. So, sorry Peter, I guess this is too late for the TabWidget :-( But don't feel demotivated I reckon such simple and useful addition would be welcome in 1.5.1, wouldn't it Jose? As seen from the discussions from Abdel and Lars we seem to be near from a time where frontends will be loaded on demand. Yes, that is even possible now. This seems to mean that branches are good places for frontend that not yet complete and active. Again following the previous reasoning, I propose the following, we should revert the removal of qt3 from lyx 1.5, now that we have manage to keep it until the feature freeze it would look like throwing the baby with the water (following one previous analogy of Angus on this list). This should only be done on the condition that there are people interested in having it on shape for 1.5 release. Georg and Jürgen do I assume correctly that you would welcome this change? This is more difficult than it seems. Especially now that Andre has changed significantly the WorkArea/Painter/Cursor interface and it seems that it is not ready yet. At least _I_ won't help any qt3 work. For 1.6 I propose to remove qt3 and completely have it superseeded by qt4. 1.5 Features: - Unicode / new encodings. - Multiple windows. - Change tracking - Multiple windows. - Sessions I think I will fix the major multiple-windows bugs pretty soon now so that Bo can work on the session stuff. I trust in your judgement to decide on what is this state. On the other hand we need a quick release, or else all the flurry in the mailing list was useless, so I suggest a deadline for the alpha release of three weeks. That is Monday, 13 November 2006. I reckon this will be enough time to fix the most obvious and visible bugs. Abdel.
Re: How to cook an omelet
Edwin Leuven wrote: Edwin Leuven wrote: Edwin Leuven wrote: updated patch attached. the attached is going in now (i also remove some unused code) http://www.lyx.org/trac/changeset/15526 (love talking of myself, just like home ;-) Less talk more action... Some other bugs are still waiting! :-) Abdel.
Re: How to cook an omelet
Edwin Leuven wrote: Edwin Leuven wrote: updated patch attached. the attached is going in now (i also remove some unused code) http://www.lyx.org/trac/changeset/15526 (love talking of myself, just like home ;-)
Re: How to cook an omelet
Edwin Leuven wrote:
Asger Ottar Alstrup wrote:
- The preferences dialog has the wrong size initially
updated patch attached.
the attached is going in now (i also remove some unused code)
Index: panelstack.C
===
--- panelstack.C(revision 15525)
+++ panelstack.C(working copy)
@@ -15,10 +15,9 @@
#include "qt_helpers.h"
#include
-#include
#include
#include
-#include
+#include
#include
@@ -37,17 +36,6 @@
stack_ = new QStackedWidget(this);
list_->setColumnCount(1);
- list_->setSizePolicy(QSizePolicy(QSizePolicy::Expanding,
QSizePolicy::Expanding));
- stack_->setSizePolicy(QSizePolicy(QSizePolicy::Expanding,
QSizePolicy::Expanding));
-
- list_->setSortingEnabled(false);
-// list_->setHorizontalScrollBarPolicy(Qt::ScrollBarAlwaysOff);
-// list_->setVerticalScrollBarPolicy(Qt::ScrollBarAlwaysOff);
-// list_->addColumn("");
-// list_->setColumnWidthMode(0, QTreeWidget::Maximum);
-
-// list_->setResizeMode(QTreeWidget::AllColumns);
-
QStringList HeaderLabels; HeaderLabels << QString("Category");
list_->setHeaderLabels(HeaderLabels);
@@ -72,7 +60,6 @@
if (parent.empty()) {
item = new QTreeWidgetItem(list_);
item->setText(0, name);
- //list_->addTopLevelItem(item);
}
else {
PanelMap::iterator it = panel_map_.find(parent);
@@ -85,23 +72,11 @@
item = new QTreeWidgetItem(it->second);
item->setText(0, name);
- //it->second->addChild(item);
}
panel_map_[n] = item;
- list_->setFixedWidth(list_->sizeHint().width());
-/*
- item->setFlags(false);
- item->setOpen(true);
-
- // calculate the real size the current item needs in the listview
- int itemsize = item->width(list_->fontMetrics(), list_, 0) + 10
- + list_->treeStepSize() * (item->depth() + 1) +
list_->itemMargin();
- // adjust the listview width to the max. itemsize
- if (itemsize > list_->minimumWidth())
- list_->setMinimumWidth(itemsize);
- */
+ list_->setMinimumWidth(list_->header()->sectionSize(0) +
list_->indentation());
}
@@ -110,9 +85,6 @@
addCategory(name, parent);
QTreeWidgetItem * item = panel_map_.find(name)->second;
- // reset the selectability set by addCategory
-// item->setSelectable(true);
-
widget_map_[item] = panel;
stack_->addWidget(panel);
stack_->setMinimumSize(panel->minimumSize());
@@ -142,10 +114,11 @@
stack_->setCurrentWidget(cit->second);
}
-#include "panelstack_moc.cpp"
+QSize PanelStack::sizeHint() const
+{
+ return QSize(list_->width() + stack_->width(),
+ qMax(list_->height(), stack_->height()));
+}
-namespace lyx {
-
-
-} // namespace lyx
+#include "panelstack_moc.cpp"
Index: panelstack.h
===
--- panelstack.h(revision 15525)
+++ panelstack.h(working copy)
@@ -43,6 +43,7 @@
/// set current panel by logical name
void setCurrentPanel(lyx::docstring const &);
+ virtual QSize sizeHint() const;
public Q_SLOTS:
/// set current panel from an item
void switchPanel(QTreeWidgetItem * i, QTreeWidgetItem* previous=0);
Re: How to cook an omelet
Edwin Leuven wrote:
Asger Ottar Alstrup wrote:
- The preferences dialog has the wrong size initially
updated patch attached.
works for me, so will commit soon unless someone doesn't like it...
Index: panelstack.C
===
--- panelstack.C(revision 15525)
+++ panelstack.C(working copy)
@@ -15,10 +15,10 @@
#include "qt_helpers.h"
#include
-#include
#include
#include
#include
+#include
#include
@@ -90,7 +90,7 @@
panel_map_[n] = item;
- list_->setFixedWidth(list_->sizeHint().width());
+ list_->setMinimumWidth(list_->header()->sectionSize(0) +
list_->indentation());
/*
item->setFlags(false);
item->setOpen(true);
@@ -142,10 +142,11 @@
stack_->setCurrentWidget(cit->second);
}
-#include "panelstack_moc.cpp"
+QSize PanelStack::sizeHint() const
+{
+ return QSize(list_->width() + stack_->width(),
+ list_->height() + stack_->height());
+}
-namespace lyx {
-
-
-} // namespace lyx
+#include "panelstack_moc.cpp"
Index: panelstack.h
===
--- panelstack.h(revision 15525)
+++ panelstack.h(working copy)
@@ -43,6 +43,7 @@
/// set current panel by logical name
void setCurrentPanel(lyx::docstring const &);
+ virtual QSize sizeHint() const;
public Q_SLOTS:
/// set current panel from an item
void switchPanel(QTreeWidgetItem * i, QTreeWidgetItem* previous=0);
Re: Random notes
On Tue, Oct 24, 2006 at 12:07:13AM +0100, José Matos wrote: > Hi fellow developers, Hi José, hope you recovered from your tour de force ;-) > I am not trying to remember or forget anyone in particular, it was > interesting to meet Charles De Miramon (I hope I get the name right) last > year in Paris. Hello John, Enrico, Bo, Peter, Edwin, Uwe and ... (please fill > your name if I forgot, I apologise for that) we are waiting you in the next > meeting. I think you only forgot Joost (among the currently active ones), which is doing a superb job with the Windows installer. I feel honoured that you include me in that list even if I consider myself only an half-developer, as the time I can spare on lyx development precludes big contributions from me. I hope I can find the time to fix some long standing bugs such as the html export, though. > As a release manager I am a firm believer in the principle of > "releasing > earlier, release often", I also believe that as a project we will only > survive and thrive if we present a stable product to our users as well to > (prospective) future developers. No one will waste their time if the > developing platform is not stable. Yes, staying on a firm ground is very important. > Again following the previous reasoning, I propose the following, we > should > revert the removal of qt3 from lyx 1.5, now that we have manage to keep it > until the feature freeze it would look like throwing the baby with the water > (following one previous analogy of Angus on this list). I don't know what others think, but I would not add a mistake to another mistake. I mean, it was a mistake the sudden drop of qt3, but now that the decision was made it would be another mistake to revert it. However, I would like to know what Bo thinks about it, as he is left in the cold with his Cygwin port. > Thank you for reading until this point. :-) It's always a pleasure reading resonable argumentations ;-) -- Enrico
Re: About scrolling speed
Abdelrazak Younes wrote: > PS: I didn't know that there was two Jurgen in this list. I was confused > by the fact Jurgen (S) criticized the Denmark people while he was part > of them :-) To clarify, Jürgen V. is the "real" Jürgen, I'm just a parvenu. Jürgen
Re: Invalid formatting code
Joost Verburg wrote:
> Juergen Spitzmueller wrote:
> > %e is not the same as %d, see my comment on bugzilla.
>
> There is indeed a minor difference. %#d on Windows should be like %e on
> UNIX.
>
> Why not use %x for both, which gives the date representation appropriate
> for the current locale?
Hm, yes, would be fine with me (i.e. %A, %x), even though the output is
different to what we have now, of course.
In the long term, I think we should provide different possibilities, like most
word processors do ("Tuesday", "Tuesday, October 24 2006", "Tuesday,
24/10/2006", "24/10/2006" etc.). And I think we'd need to translate between
the differing arguments of the original unix strftime and the ms rip-off
nevertheless (i.e. %e <-> %#d etc.).
> > also, someone who can reproduce the crash with date-insert on windows,
> > please test the patch I proposed there.
>
> Your patch won't help. The Microsoft CRT validates all input for
> security reasons. You get an assertion immediately.
OK, that's all I wanted to know.
> Joost
Jürgen
Re: About scrolling speed
On Tue, 2006-10-24 at 10:03 +0200, Juergen Vigna wrote: > > Asger Ottar Alstrup wrote: > > One conclusion is clear: The only sure way to get substantially faster > > rendering is to draw less on the screen, as discussed earlier today, > > either by introducing the old singlePar optimisation, or do some > > drawing-caching scheme. > > I'm of the opinion that in 1.6 we should work in be able to decide if > we have to redraw just *one* row, one paragraph or the whole of the > screen. Especially the *one* row stuff would increase "typing" performance > a lot (and make it usefull again ;) > > Greets, > > Jürgen But that is happening right now... see rowpainter.C, variable row_has_changed etc. You can test it by turning on debugging for Debug::PAINTING. Don't ask me what's consuming all the drawing time. Of course if you scroll page wise up or down, you're going to repaint pretty much every screenful that you see. - Martin signature.asc Description: This is a digitally signed message part
Re: UI for New/Close Window
Peter Kümmel wrote: Martin Vermeer wrote: We _have_ tabs. But -- they are arranged vertically under a pulldown menu :-) I would love it to have tabs for the multiple documents. Implementing tabs was the reason for me to become a lyx developer. Currently we have one QWidget which shows all documents. This is GuiWorkArea. We could replace this widget with a QTabWidget and host the original QWidget in all tabs. Then, when the tab is changed the viewing QWidget is updated with the new document (as now), but is visiable in the new tab. This changes seems not so critical. Abdel could you give me some tips we I have to start? There are two solutions: 1) Make the central widget a QTabWidget in GuiView (which is a QMainApplication). Then host a new QWorkArea for each tab. In this context, this would mean that two WorkArea in two tabs or in two split windows would look the same to the parent GuiView. 2) Make the GuiWorkArea viewport a tab widget and handle the buffer switch there. This would mean that there's only one WorkArea. I like 1) more but 2) might be easier to do. Abdel.
Re: UI for New/Close Window
On Tue, Oct 24, 2006 at 10:11:41AM +0200, Joost Verburg wrote: > Enrico Forestieri wrote: > >> Good. This last thing is the most important one. If you keep everything > >> in a single instance you prevent many problems. > > > > And open the door to other problems... see my other post. > > You can have your command line option. I'm talking about the normal > behavior for end-users, not debugging and crash testing. Joost, I was simply trying to point out that there could be implications that you or me are not able to foresee. Please, try the shared path example I illustrated in the other post. It is really not about debugging or testing... -- Enrico
Re: UI for New/Close Window
On Tue, Oct 24, 2006 at 10:22:44AM +0200, [EMAIL PROTECTED] wrote: > On Tue, 24 Oct 2006, Joost Verburg wrote: > > > Enrico Forestieri wrote: > > > > Why? Isn't the X button enough? > > > > > > Huh? You were asking for a way to open a new window with the same > > > document loaded in it, or did I get you wrong? > > > > > For example, the first time I used > > > powerpoint with two different documents, I was really surprised and > > > upset by the fact that quitting a document window by hitting the X > > > shaped icon in the upper right corner was also quitting the other > > > window. > > > > You're wrong here. Clicking the X only closes the current window, not the > > others. That's also how Microsoft Office works. > > It's kind of strong to state that he's "wrong". Can you say for sure this > is how *all* versions of powerpoint has worked? Indeed, I can confirm that what I said is true in Office 2000 powerpoint, don't know for later versions. -- Enrico
Re: UI for New/Close Window
On Tue, 24 Oct 2006, Joost Verburg wrote: > Enrico Forestieri wrote: > > > Why? Isn't the X button enough? > > > > Huh? You were asking for a way to open a new window with the same > > document loaded in it, or did I get you wrong? > > > For example, the first time I used > > powerpoint with two different documents, I was really surprised and > > upset by the fact that quitting a document window by hitting the X > > shaped icon in the upper right corner was also quitting the other > > window. > > You're wrong here. Clicking the X only closes the current window, not the > others. That's also how Microsoft Office works. It's kind of strong to state that he's "wrong". Can you say for sure this is how *all* versions of powerpoint has worked? > Having both a "Close Window" menu entry and an X button is not necessary. A menu entry has the advantage that it allows you to see the keyboard shortcut for closing the window. But maybe there is some other way to let users know this. (I know about Alt-F4 and Ctrl-F4, but I'm not certain the average user does). /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: About scrolling speed
Juergen Vigna wrote: Hi Abdel, as much as I know before we started on fixing bugs there I was not able to scroll trough the UserGuide without hitting an Assert ;) But this has nothing to do with speed ;-) More seriously, I was of course speaking about a built that was before the scrolling breakage (which was very recent contrarily to what you might think). Please note that I am not criticizing your work. I think Andre's solution for the painter and the workarea is elegant and I would have done the same if I were not limited by the multiple frontends support. I think that this is due to the "more" metrics calculations we have to do in order to fix all that scrolling bugs and with it the removal of the nullpainter which was not calculating important stuff as *normal* text, and therefore with it in place the x positions of the insets where all wrong! Year, that and maybe also the font stuff that Asger mentioned yesterday. Abdel. PS: I didn't know that there was two Jurgen in this list. I was confused by the fact Jurgen (S) criticized the Denmark people while he was part of them :-)
Re: Is this a math bug of 1.4.3
Enrico Forestieri wrote:
> On Tue, Oct 24, 2006 at 09:06:18AM +0200, Jean-Marc Lasgouttes wrote:
>
>>> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>> Enrico> There is instead a bug in the Windows version as when you type
>> Enrico> {whatever}^2 everything enclosed by braces disappear...
>>
>> Do we know more about this ?
>
> It seems to be due to MSVC, as I don't get it using GCC. I think
> Peter was investigating it.
>
Yes, only msvc eats 'whatever' but I didn't found the reason for this.
--
Peter Kümmel
Re: Is this a math bug of 1.4.3
On Tue, Oct 24, 2006 at 09:06:18AM +0200, Jean-Marc Lasgouttes wrote:
> > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> Enrico> There is instead a bug in the Windows version as when you type
> Enrico> {whatever}^2 everything enclosed by braces disappear...
>
> Do we know more about this ?
It seems to be due to MSVC, as I don't get it using GCC. I think
Peter was investigating it.
--
Enrico
Re: UI for New/Close Window
Enrico Forestieri wrote: Good. This last thing is the most important one. If you keep everything in a single instance you prevent many problems. And open the door to other problems... see my other post. You can have your command line option. I'm talking about the normal behavior for end-users, not debugging and crash testing. Joost
Re: UI for New/Close Window
Enrico Forestieri wrote: Why? Isn't the X button enough? Huh? You were asking for a way to open a new window with the same document loaded in it, or did I get you wrong? For example, the first time I used powerpoint with two different documents, I was really surprised and upset by the fact that quitting a document window by hitting the X shaped icon in the upper right corner was also quitting the other window. You're wrong here. Clicking the X only closes the current window, not the others. That's also how Microsoft Office works. Having both a "Close Window" menu entry and an X button is not necessary. Joost
Re: About scrolling speed
Asger Ottar Alstrup wrote: One conclusion is clear: The only sure way to get substantially faster rendering is to draw less on the screen, as discussed earlier today, either by introducing the old singlePar optimisation, or do some drawing-caching scheme. I'm of the opinion that in 1.6 we should work in be able to decide if we have to redraw just *one* row, one paragraph or the whole of the screen. Especially the *one* row stuff would increase "typing" performance a lot (and make it usefull again ;) Greets, Jürgen -- ** Würth Phoenix S.r.l. Dr. Jürgen Vigna System Integration Via Kravogl 4, I-39100 Bolzano Phone: +39 0471 564111 Direct: +39 0471 564172 Fax:+39 0471 564122 mailto:[EMAIL PROTECTED] http://www.wuerth-phoenix.com
Re: UI for New/Close Window
On Tue, Oct 24, 2006 at 09:15:25AM +0200, Joost Verburg wrote: > Abdelrazak Younes wrote: > >> We should avoid a situation where one can have multiple instances, > >> each with multiple windows. Otherwise it becomes very confusing and it > >> will be impossible to tell which windows share the same data, which > >> results in data-loss because of saving the wrong versions. > > > > Agreed. > > Good. This last thing is the most important one. If you keep everything > in a single instance you prevent many problems. And open the door to other problems... see my other post. -- Enrico
Re: UI for New/Close Window
Martin Vermeer wrote: > We _have_ tabs. But -- they are arranged vertically under a pulldown > menu :-) I would love it to have tabs for the multiple documents. Implementing tabs was the reason for me to become a lyx developer. Currently we have one QWidget which shows all documents. We could replace this widget with a QTabWidget and host the original QWidget in all tabs. Then, when the tab is changed the viewing QWidget is updated with the new document (as now), but is visiable in the new tab. This changes seems not so critical. Abdel could you give me some tips we I have to start? Peter
Re: About scrolling speed
Hi Abdel, as much as I know before we started on fixing bugs there I was not able to scroll trough the UserGuide without hitting an Assert ;) I think that this is due to the "more" metrics calculations we have to do in order to fix all that scrolling bugs and with it the removal of the nullpainter which was not calculating important stuff as *normal* text, and therefore with it in place the x positions of the insets where all wrong! Greets, Jürgen Abdelrazak Younes wrote: Hi Andre, Before Denmark, the UserGuide PageDown test was at 18 seconds. Now it is at 25 seconds. I hope you have some more code in store for speed ;-) Abdel. -- ** Würth Phoenix S.r.l. Dr. Jürgen Vigna System Integration Via Kravogl 4, I-39100 Bolzano Phone: +39 0471 564111 Direct: +39 0471 564172 Fax:+39 0471 564122 mailto:[EMAIL PROTECTED] http://www.wuerth-phoenix.com
Re: UI for New/Close Window
On Tue, Oct 24, 2006 at 08:09:10AM +0200, Joost Verburg wrote: > Enrico Forestieri wrote: > > Please not. I don't want my screen cluttered with 10 windows if I have > > 10 documents opened at the same time, because I can only work with one > > at the same time. Having the option to have a new window is ok, though. > > They don't have to be on your screen, you can minimize them. Apart from the fact that a new window consumes more resources, I could say that I don't like to have my task bar cluttered by them ;-) > > Maybe a "Clone Window"? > > Why? Isn't the X button enough? Huh? You were asking for a way to open a new window with the same document loaded in it, or did I get you wrong? > > But a way to create a new instance if so wanted. > > Then please explain me how you will know which window belongs to which > LyX process. If you don't know this difference, you can easily loose > your data by clicking save in the wrong window. But even if there is a > way to identify the different instances you are likely to make this error. I was simply saying that I am ok with this, but I also want the possibility of launching a new instance. I always hate the software that doesn't give any alternative. For example, I could experiment something that can potentially lead to an hard crash and I want to avoid the risk of losing the work I am doing in another LyX window. > Now we have the possibility of multiple windows in a single instance, > there is no need anymore to have multiple instances. Allowing only a > single LyX process will make sure that there is only one version of the > same document in memory (even though you can have multiple views of the > same document), so you will never save the wrong version. As I already said, I have no objection to this being the default behaviour, but I also want to be able to use a switch on the command line letting me launch a new instance. > > This is not aimed at you, Joost, but frankly I am tired with this kind > > of argumentation, which IMO is due to the lobotomization performed by > > Word & Co. > > If we add a "New Window" feature with the same name but totally > different from all major office application, that's not going to make > things more clear for the users. Now I don't get you here. If I use the menu "New Window", I don't expect to have a new instance of LyX. I am talking about a way of externally launch a new instance of LyX. Perhaps I was even going further with respect to what you had in mind. My idea was along these lines: When you invoke lyx, there should be a way to check if another instance is already running, and, if so, pass to it the request of opening a new document (or whatever) in a new window or in a new buffer (this could be selectable by a preference setting). But: there should be a switch telling lyx to not bother checking for an already running instance and always start a new process. This way I can avoid strange situations. For example, I often found that on Windows I cannot kill (for a reason or another) a running instance of a program. Last time this happened to me right with lyx and I traced it to the fact that it was trying to check for the existence of a file I had in lastfiles, but was not able to do so because it was a shared path and I had no internet connection at that point. I was not able to kill it and if your idea was implemented, I should have rebooted in order to launch another instance... Indeed, the damn thing only died after a reboot, but it took more than *ten* minutes to do so! > The most important thing is however that we need to think about all the > results of adding such a new feature. If it becomes possible to have > multiple LyX processes with multiple windows thing become very confusing. Now you are talking with the average Windows user in mind. Windows users are not the only ones. For example, the first time I used powerpoint with two different documents, I was really surprised and upset by the fact that quitting a document window by hitting the X shaped icon in the upper right corner was also quitting the other window. Indeed, I was even more confused, because it was asking me if I wanted to quit the other window which had unsaved changes. Damn'd thing, I thought, I was not asking you to quit the other window. Then I understood what that other X shaped icon in an inner corner was meaning. So, there are users and users. Some will be confused, others will not. Please, can we stop using the average Windows user as the unit of measure? -- Enrico
Re: Invalid formatting code
Juergen Spitzmueller wrote: %e is not the same as %d, see my comment on bugzilla. There is indeed a minor difference. %#d on Windows should be like %e on UNIX. Why not use %x for both, which gives the date representation appropriate for the current locale? also, someone who can reproduce the crash with date-insert on windows, please test the patch I proposed there. Your patch won't help. The Microsoft CRT validates all input for security reasons. You get an assertion immediately. Joost
Re: UI for New/Close Window
Abdelrazak Younes wrote: I am sure this is possible (as many apps do this by default on Windows) but I don't know _how_ to do it portably. Maybe it requires OS-specific code. Joost
Re: Invalid formatting code
Joost Verburg wrote: > Hi, > > %e is not supported as a formatting code for strftime by all compilers. > At least with Windows/MSVC this causes change merging to fail (see > Bugzilla 2923). > > Can I upload the attached patch to 1.4 and 1.5? Did you read http://bugzilla.lyx.org/show_bug.cgi?id=2839 ? %e is not the same as %d, see my comment on bugzilla. I think the appropriate strings would be %A, %#d %B %Y for windows and %A, %e %B %Y for Unix also, someone who can reproduce the crash with date-insert on windows, please test the patch I proposed there. Jürgen > Regards, > > Joost
