Re: Unable to edit and save graphic in lyx-1.4.0 (Qt frontend)
I still fail to reproduce that. Can you send an example file, inclusing the graphic? Jürgen Anand Rangarajan wrote: I compiled and installed lyx-1.4.0 (Qt frontend) on a SUSE 10 x86_64 box. In lyx-1.4.0, I'm unable to edit and save a graphic. I wonder if I'm doing something stupid. Anyway, here's the problem. 1. Open a new lyx file. 2. Insert a graphic using the Insert graphic button on the toolbar. Browse and choose a file. 3. Set the width parameter to 4in. Click OK and the dialog vanishes. 4. Save the document. 5. Click on the graphic again. Change the width to 3in. 6. Try and click OK to save your changes to the graphic. 7. I cannot do this. The OK button on the dialog is grayed out and cannot be clicked. Consequently, I cannot make any changes to the graphic. I have to delete it and insert a new graphic with the properties that I want. Anand
Re: Ping! (Re: [Patch in parent] per-doc charstyles)
On Friday 17 March 2006 20:05, Martin Vermeer wrote: Has anybody looked at this? This message is one of the two/three messages in this folder marked as todo. ;-) FWIW I am interested. :-) Thinking aloud... what you are doing requires a file format change, right? - Martin -- José Abílio
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Moving on to LyX/Win 1.4, what should I compile? The release tar ball or a snapshot of the 1.4.x tree including the bug fixes that have gone in since 1.4.0 was announced? Personnally I'd prefer the plain 1.4.0 tarball, unless there are some very bad windows bugs. JMarc Mañana. Angus
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Angus Leeming wrote: Ok, I know that I'm a bit behind the times, but I've just uploaded LyX/Win 1.3.7-3 to http://wiki.lyx.org/Windows/LyX137. This thing uses the new Aspell dictionaries and seems to work well. Moving on to LyX/Win 1.4, what should I compile? The release tar ball or a snapshot of the 1.4.x tree including the bug fixes that have gone in since 1.4.0 was announced? Maybe it would be a good idea to provide both a 1.4.0 installer as well as a monthly development preview, so Windows will also be able to help testing. I reviewed the currently available installers (the official installer and the LyXWinInstaller) and their scripts. Both seem to have some flaws in the way their install and uninstall components and in the NSIS scripts. In my opinion, the best thing to do would be to combine the best parts of both installers into a new official installer. That's also less confusing for an end-user compared to having both official and unofficial versions. Joost
Re: Ping! (Re: [Patch in parent] per-doc charstyles)
On Sat, Mar 18, 2006 at 08:31:21AM +, Jose' Matos wrote: On Friday 17 March 2006 20:05, Martin Vermeer wrote: Has anybody looked at this? This message is one of the two/three messages in this folder marked as todo. ;-) FWIW I am interested. :-) Thinking aloud... what you are doing requires a file format change, right? Yes... user charstyle definitions in the header. Converting charstyle insets in the document back to ordinary font attributes on going back to an older LyX format would be nice to have ;-) - Martin pgpP7mHOjiSvX.pgp Description: PGP signature
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes a écrit : Moving on to LyX/Win 1.4, what should I compile? The release tar ball or a snapshot of the 1.4.x tree including the bug fixes that have gone in since 1.4.0 was announced? Personnally I'd prefer the plain 1.4.0 tarball, unless there are some very bad windows bugs. I think Angus fears that the time the installer is done and tested, 1.4.1 will be close to release. Jean-Marc you said that you want to shorten the delay between release. Why not make declare a 1.4.1 release candidate now and work from there. By the way, is there any performance improvement in current tree? IMHO the 1.4.0 performance on windows is quite bad and I don't think many people many people will switch from 1.3.7. Abdel.
qt4: remove (2nd) add dialog in add bib tex ref dialog
Title: qt4: remove (2nd) add dialog in add bib tex ref dialog
i personally think this is more convenient.
comments, opinions?
patch attached.
edwin
Index: Makefile.dialogs
===
--- Makefile.dialogs (revision 13415)
+++ Makefile.dialogs (working copy)
@@ -16,7 +16,6 @@
QAskForTextUi.ui \
QBibitemUi.ui \
QBibtexUi.ui \
- QBibtexAddUi.ui \
QBoxUi.ui \
QBranchUi.ui \
QChangesUi.ui \
Index: QBibtexDialog.C
===
--- QBibtexDialog.C (revision 13415)
+++ QBibtexDialog.C (working copy)
@@ -47,43 +47,14 @@
form, SLOT(slotOK()));
connect(closePB, SIGNAL(clicked()),
form, SLOT(slotClose()));
+ connect( addBibPB, SIGNAL( clicked() ), this, SLOT( browseBibPressed() ) );
+ connect( deletePB, SIGNAL( clicked() ), this, SLOT( deletePressed() ) );
+ connect( stylePB, SIGNAL( clicked() ), this, SLOT( browsePressed() ) );
+ connect( styleCB, SIGNAL( textChanged(const QString) ), this, SLOT( change_adaptor() ) );
+ connect( databaseLW, SIGNAL( selectionChanged() ), this, SLOT( databaseChanged() ) );
+ connect( bibtocCB, SIGNAL( toggled(bool) ), this, SLOT( change_adaptor() ) );
+ connect( btPrintCO, SIGNAL( activated(int) ), this, SLOT( change_adaptor() ) );
-connect( stylePB, SIGNAL( clicked() ), this, SLOT( browsePressed() ) );
-connect( deletePB, SIGNAL( clicked() ), this, SLOT( deletePressed() ) );
-connect( styleCB, SIGNAL( textChanged(const QString) ), this, SLOT( change_adaptor() ) );
-connect( databaseLB, SIGNAL( selectionChanged() ), this, SLOT( databaseChanged() ) );
-connect( bibtocCB, SIGNAL( toggled(bool) ), this, SLOT( change_adaptor() ) );
-connect( btPrintCO, SIGNAL( activated(int) ), this, SLOT( change_adaptor() ) );
-connect( addBibPB, SIGNAL( clicked() ), this, SLOT( addPressed() ) );
-
- add_ = new UiDialogUi::QBibtexAddUi(this, true);
-
- Qt2BC * bcview = new Qt2BC(add_bc_);
- add_bc_.view(bcview);
- add_bc_.bp(new OkCancelPolicy);
-
- bcview-setOK(add_-addPB);
- bcview-setCancel(add_-closePB);
-
- add_-bibED-setValidator(new PathValidator(false, add_-bibED));
- addCheckedLineEdit(add_bc_.view(), add_-bibED, 0);
-
- connect(add_-bibED, SIGNAL(textChanged(const QString)),
- this, SLOT(bibEDChanged()));
- connect(add_-addPB, SIGNAL(clicked()),
- this, SLOT(addDatabase()));
- connect(add_-bibLB, SIGNAL(selected(Q3ListBoxItem *)),
- this, SLOT(addDatabase()));
- connect(add_-bibLB, SIGNAL(selected(Q3ListBoxItem *)),
- add_, SLOT(accept()));
- connect(add_-bibLB, SIGNAL(currentChanged(Q3ListBoxItem *)),
- this, SLOT(availableChanged()));
- connect(add_-browsePB, SIGNAL(clicked()),
- this, SLOT(browseBibPressed()));
-
-connect( add_-addPB, SIGNAL( clicked() ), this, SLOT( accept() ) );
-connect( add_-closePB, SIGNAL( clicked() ), this, SLOT( reject() ) );
-
}
@@ -91,15 +62,6 @@
{}
-void QBibtexDialog::bibEDChanged()
-{
- // Indicate to the button controller that the contents have
- // changed. The actual test of validity is carried out by
- // the checkedLineEdit.
- add_bc_.valid(true);
-}
-
-
void QBibtexDialog::change_adaptor()
{
form_-changed();
@@ -139,66 +101,29 @@
string const f = ChangeExtension(file, );
bool present = false;
- for (unsigned int i = 0; i != add_-bibLB-count(); i++) {
- if (fromqstr(add_-bibLB-text(i)) == f)
+ for (unsigned int i = 0; i != databaseLW-count(); i++) {
+ if (fromqstr(databaseLW-item(i)-text()) == f)
present = true;
}
if (!present) {
- add_-bibLB-insertItem(toqstr(f));
+ databaseLW-addItem(toqstr(f));
form_-changed();
}
-
- add_-bibED-setText(toqstr(f));
}
}
-void QBibtexDialog::addPressed()
-{
- add_-exec();
- add_bc_.valid(false);
-}
-
-
-void QBibtexDialog::addDatabase()
-{
- int const sel = add_-bibLB-currentItem();
- string const file = trim(fromqstr(add_-bibED-text()));
-
- if (sel 0 file.empty())
- return;
-
- // Add the selected browser_bib keys to browser_database
- // multiple selections are possible
- for (unsigned int i = 0; i != add_-bibLB-count(); i++) {
- if (add_-bibLB-isSelected(i)) {
- // do not allow duplicates
- if ((databaseLB-findItem(add_-bibLB-text(i))) == 0)
-databaseLB-insertItem(add_-bibLB-text(i));
- }
- }
-
- if (!file.empty()) {
- QString const f = toqstr(ChangeExtension(file, ));
- if ((databaseLB-findItem(f)) == 0)
- databaseLB-insertItem(f);
- }
-
- form_-changed();
-}
-
-
void QBibtexDialog::deletePressed()
{
- databaseLB-removeItem(databaseLB-currentItem());
+ delete databaseLW-takeItem(databaseLW-currentRow());
}
void QBibtexDialog::databaseChanged()
{
- deletePB-setEnabled(!form_-readOnly() databaseLB-currentItem() != -1);
+ deletePB-setEnabled(!form_-readOnly() databaseLW-currentRow() != -1);
}
Index: QBibtexDialog.h
===
--- QBibtexDialog.h (revision 13415)
+++ QBibtexDialog.h
Re: qt4: remove (2nd) add dialog in add bib tex ref dialog
Leuven, E. wrote: i personally think this is more convenient. comments, opinions? fine with me. Jürgen
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Am Freitag, 17. März 2006 22:14 schrieb Kayvan A. Sylvan:
On Fri, Mar 17, 2006 at 08:29:28PM +0100, Georg Baum wrote:
Kayvan, are you listening? Why did you introduce this option also for
cygwin?
I think this was related to trying to compile for QT/Cygwin. If we can
compile for QT on Windows without this, then I am all for removing it.
This is the case according to Enrico and Abdel. I am going to commit the
attached patch to trunk unless somebody objects.
Georg
Log:
Remove unneeded test for gcc2 on cygwin
Don't set -mms-bitfields on cygwin
Index: config/cygwin.m4
===
--- config/cygwin.m4 (Revision 13415)
+++ config/cygwin.m4 (Arbeitskopie)
@@ -4,36 +4,19 @@
AC_DEFUN([CHECK_WITH_CYGWIN],
[
case $host_os in
- cygwin* | mingw* | pw32* )
+ mingw* | pw32* )
if test $GCC = yes; then
# Ensure MSVC-compatible struct packing convention.
# Depends on GCC version. gcc2 uses -fnative-struct while
# gcc3 uses -mms-bitfields.
- #
- msnative_struct=''
- AC_MSG_CHECKING([how to get MSVC-compatible struct packing])
- case `$CC --version | sed -e 's,\..*,.,' -e q` in
- 2.)
-if $CC -v --help 2/dev/null | grep fnative-struct /dev/null; then
-msnative_struct='-fnative-struct'
-fi
-;;
- *)
-if $CC -v --help 2/dev/null | grep ms-bitfields /dev/null; then
-msnative_struct='-mms-bitfields'
-fi
-;;
- esac
-
- if test x$msnative_struct = x; then
-AC_MSG_RESULT([no way])
-AC_MSG_WARN([produced libraries might be incompatible with MSVC libs])
- else
-CXXFLAGS=$CXXFLAGS $msnative_struct
-AC_MSG_RESULT([${msnative_struct}])
- fi
+ # We support only gcc3.
+ CXXFLAGS=$CXXFLAGS -mms-bitfields
fi
+;;
+ esac
+ case $host_os in
+ cygwin* | mingw* | pw32* )
# Export all symbols to Win32 DLL using MinGW 2.0 ld.
WIN32_LD_EXPORT_ALL_SYMBOLS=''
AC_MSG_CHECKING([whether ld accepts --export-all-symbols])
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes a écrit : Moving on to LyX/Win 1.4, what should I compile? The release tar ball or a snapshot of the 1.4.x tree including the bug fixes that have gone in since 1.4.0 was announced? Personnally I'd prefer the plain 1.4.0 tarball, unless there are some very bad windows bugs. Abdel: I think Angus fears that the time the installer is done and tested, 1.4.1 will be close to release. Jean-Marc you said that you want to shorten the delay between release. Why not make declare a 1.4.1 release candidate now and work from there. By the way, is there any performance improvement in current tree? IMHO the 1.4.0 performance on windows is quite bad and I don't think many people many people will switch from 1.3.7. Abdel. SH: This post reflects my point of view. It is not that there are very bad windows bugs but that there are so many of them. If the release contains the bug fixes to date and is called 1.4.0, then it is not as easy to compare with the original unfixed 1.4.0 So the declare a 1.4.1 release candidate makes sense to me, a 1.4.1pre_1. The users will be happier and it provides testing to the newly added bug fixes. It is pretty easy though, to have both 1.3.7 and 1.4.0 versions coexist peacefully with Windows. The Linux and WinLyX versions could be synced at 1.4.0pre_2 Releasing 1.4.1pre1 assuages Win users feeling of being neglected. I also like Joost's suggestions particulary in regard to 1.4.0 which might have adequate developer resources to support it. However the 1.3.7 idea, which seems ideal, will likely encounter practical resistance, such as a lower priority, and general lack of agreement. Regards, Stephen
Re: [patch] remove qt2 support
Am Freitag, 17. März 2006 21:42 schrieb Leuven, E.:
if qt2 goes, the attached should go (in) as well i think (i.e. remove
qgridview.[Ch])
You are right. I did not know that we had these classes! The full patch
would look like the attached. Dou you have commit privileges now, or
should I commit it for you?
Georg
Index: src/frontends/qt2/qgridview.h
===
--- src/frontends/qt2/qgridview.h (Revision 13415)
+++ src/frontends/qt2/qgridview.h (Arbeitskopie)
@@ -1,134 +0,0 @@
-/**
-** $Id: qgridview.h,v 1.3 2004/12/14 11:05:44 leeming Exp $
-**
-** Definition of QGridView class
-**
-** Created: 2001.05.23
-**
-** Copyright (C) 1992-2001 Trolltech AS. All rights reserved.
-**
-** This file is part of the widgets module of the Qt GUI Toolkit.
-**
-** This file may be distributed under the terms of the Q Public License
-** as defined by Trolltech AS of Norway and appearing in the file
-** LICENSE.QPL included in the packaging of this file.
-**
-** This file may be distributed and/or modified under the terms of the
-** GNU General Public License version 2 as published by the Free Software
-** Foundation and appearing in the file LICENSE.GPL included in the
-** packaging of this file.
-**
-** Licensees holding valid Qt Enterprise Edition or Qt Professional Edition
-** licenses may use this file in accordance with the Qt Commercial License
-** Agreement provided with the Software.
-**
-** This file is provided AS IS with NO WARRANTY OF ANY KIND, INCLUDING THE
-** WARRANTY OF DESIGN, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
-**
-** See http://www.trolltech.com/pricing.html or email [EMAIL PROTECTED] for
-** information about Qt Commercial License Agreements.
-** See http://www.trolltech.com/qpl/ for QPL licensing information.
-** See http://www.trolltech.com/gpl/ for GPL licensing information.
-**
-** Contact [EMAIL PROTECTED] if any conditions of this licensing are
-** not clear to you.
-**
-**/
-
-#ifndef QGRIDVIEW_H
-#define QGRIDVIEW_H
-
-#include qscrollview.h
-
-#ifndef QT_NO_GRIDVIEW
-
-class QGridViewPrivate;
-
-class QGridView : public QScrollView
-{
-Q_OBJECT
-Q_PROPERTY( int numRows READ numRows WRITE setNumRows )
-Q_PROPERTY( int numCols READ numCols WRITE setNumCols )
-Q_PROPERTY( int cellWidth READ cellWidth WRITE setCellWidth )
-Q_PROPERTY( int cellHeight READ cellHeight WRITE setCellHeight )
-public:
-
-QGridView( QWidget *parent=0, const char *name=0, WFlags f=0 );
- ~QGridView();
-
-int numRows() const;
-virtual void setNumRows( int );
-int numCols() const;
-virtual void setNumCols( int );
-
-int cellWidth() const;
-virtual void setCellWidth( int );
-int cellHeight() const;
-virtual void setCellHeight( int );
-
-QRect cellRect() const;
-QRect cellGeometry( int row, int column );
-QSize gridSize() const;
-
-int rowAt( int y ) const;
-int columnAt( int x ) const;
-
-void repaintCell( int row, int column, bool erase=TRUE );
-void updateCell( int row, int column );
-void ensureCellVisible( int row, int column );
-
-protected:
-virtual void paintCell( QPainter *, int row, int col ) = 0;
-virtual void paintEmptyArea( QPainter *p, int cx, int cy, int cw, int ch );
-
-void drawContents( QPainter *p, int cx, int cy, int cw, int ch );
-
-virtual void dimensionChange( int, int );
-
-private:
-void drawContents( QPainter* );
-void updateGrid();
-
-int nrows;
-int ncols;
-int cellw;
-int cellh;
-QGridViewPrivate* d;
-
-private: // Disabled copy constructor and operator=
-#if defined(Q_DISABLE_COPY)
-QGridView( const QGridView );
-QGridView operator=( const QGridView );
-#endif
-};
-
-inline int QGridView::cellWidth() const
-{ return cellw; }
-
-inline int QGridView::cellHeight() const
-{ return cellh; }
-
-inline int QGridView::rowAt( int y ) const
-{ return y / cellh; }
-
-inline int QGridView::columnAt( int x ) const
-{ return x / cellw; }
-
-inline int QGridView::numRows() const
-{ return nrows; }
-
-inline int QGridView::numCols() const
-{return ncols; }
-
-inline QRect QGridView::cellRect() const
-{ return QRect( 0, 0, cellw, cellh ); }
-
-inline QSize QGridView::gridSize() const
-{ return QSize( ncols * cellw, nrows * cellh ); }
-
-
-
-#endif // QT_NO_GRIDVIEW
-
-
-#endif // QTABLEVIEW_H
Index: src/frontends/qt2/Makefile.dialogs
===
--- src/frontends/qt2/Makefile.dialogs (Revision 13415)
+++ src/frontends/qt2/Makefile.dialogs (Arbeitskopie)
@@ -97,7 +97,6 @@ MOCFILES = \
QExternalDialog.C QExternalDialog.h \
QFloatDialog.C QFloatDialog.h \
QGraphicsDialog.C QGraphicsDialog.h \
- qgridview.C qgridview.h \
QIncludeDialog.C QIncludeDialog.h \
QIndexDialog.C QIndexDialog.h \
[patch] fix lib/configure.py invocation for builddir != srcdir
lib/configure.py cannot be run if you compile with a fresh builddir != srcdir. The reason is that the main configure script creates builddir/lib only after trying to run lib/configure.py. The attached patch fixes that. Does anybody know a better solution? If not I am going to put this in. Georg Index: configure.ac === --- configure.ac (Revision 13415) +++ configure.ac (Arbeitskopie) @@ -474,7 +474,7 @@ AC_CONFIG_FILES([Makefile m4/Makefile \ src/frontends/qt4/ui/Makefile \ ]) echo Running $LYX_ABS_TOP_SRCDIR/lib/configure.py --with-version-suffix=\$version_suffix\ -(cd lib python $LYX_ABS_TOP_SRCDIR/lib/configure.py --with-version-suffix=$version_suffix) +(test -d lib || mkdir lib cd lib python $LYX_ABS_TOP_SRCDIR/lib/configure.py --with-version-suffix=$version_suffix) AC_OUTPUT # show version information
Re: Qt4 frontend
On Fri, Mar 17, 2006 at 04:21:16PM +0200, Martin Vermeer wrote:
On Fri, Mar 17, 2006 at 02:49:13PM +0100, Abdelrazak Younes wrote:
...
Actually with your first patch, if you open a document, type Ctrl+end,
then only half of of screen is redrawn :-)
And if you open a new document (ctrl+n), the bottom part of the area is
not drawn.
Same with the second patch. The reason is that the grey areas that are
correctly drawn in paintText, are never exposed. I know how to do it,
it's easy... have to run now.
Here is the fix for the end-of-document problem.
What I would really like to know is if this helps when using LyX over a
slow line, i.e., does expose really send a rectangle of pixels from
the application to the server display, i.e., were all the earlier
painting operations to a local canvas only?
- Martin
Index: metricsinfo.h
===
--- metricsinfo.h (revision 13408)
+++ metricsinfo.h (working copy)
@@ -102,13 +102,14 @@ class ViewMetricsInfo
{
public:
ViewMetricsInfo(lyx::pit_type p1, lyx::pit_type p2, int y1, int y2,
- bool singlepar) : p1(p1), p2(p2), y1(y1), y2(y2),
- singlepar(singlepar) {}
+ bool singlepar, lyx::pit_type size) : p1(p1), p2(p2),
+ y1(y1), y2(y2), singlepar(singlepar), size(size) {}
lyx::pit_type p1;
lyx::pit_type p2;
int y1;
int y2;
bool singlepar;
+ lyx::pit_type size;
};
Index: BufferView_pimpl.C
===
--- BufferView_pimpl.C (revision 13408)
+++ BufferView_pimpl.C (working copy)
@@ -1348,6 +1348,8 @@ ViewMetricsInfo BufferView::Pimpl::metri
theCoords.clear();
BufferView bv = *bv_;
LyXText * const text = bv.text();
+ lyx::pit_type size = int(text-paragraphs().size());
+
if (anchor_ref_ int(text-paragraphs().size() - 1)) {
anchor_ref_ = int(text-paragraphs().size() - 1);
offset_ref_ = 0;
@@ -1434,7 +1436,8 @@ ViewMetricsInfo BufferView::Pimpl::metri
pit2: pit2
npit: npit
singlepar: singlepar
+ size: size
endl;
- return ViewMetricsInfo(pit1, pit2, y1, y2, singlepar);
+ return ViewMetricsInfo(pit1, pit2, y1, y2, singlepar, size);
}
Index: frontends/screen.C
===
--- frontends/screen.C (revision 13408)
+++ frontends/screen.C (working copy)
@@ -219,7 +219,10 @@ void LyXScreen::redraw(BufferView bv,
workarea().getPainter().start();
paintText(bv, vi);
lyxerr[Debug::DEBUG] Redraw screen endl;
- expose(0, 0, workarea().workWidth(), workarea().workHeight());
+ int const ymin = std::max(vi.y1, 0);
+ int const dymax = ( vi.p2 vi.size - 1 ?
+ vi.y2 - ymin : workarea().workHeight() - ymin );
+ expose(0, ymin, workarea().workWidth(), dymax);
workarea().getPainter().end();
theCoords.doneUpdating();
}
pgp4g8C5q8BQQ.pgp
Description: PGP signature
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Angus Leeming wrote: Ok, I know that I'm a bit behind the times, but I've just uploaded LyX/Win 1.3.7-3 to http://wiki.lyx.org/Windows/LyX137. This thing uses the new Aspell dictionaries and seems to work well. Great! I will download it instantly! THANK YOU! Moving on to LyX/Win 1.4, what should I compile? The release tar ball or a snapshot of the 1.4.x tree including the bug fixes that have gone in since 1.4.0 was announced? 1.4.0 has a serious problem when used with pdflatex (pdflatex fails due to too long filenames). I suggest using 1.4.1svn. Michael
Re: qt4: remove (2nd) add dialog in add bib tex ref dialog
Leuven, E. a écrit : i personally think this is more convenient. comments, opinions? This is fine with me also. Plus you have ported it to Qt4 API which is even better. But I am not much a Bibtex user. Would you want to give a go for Citation/AddCitation Dialog? I don't have the time right now to do it. Thanks, Abdel.
Re: Qt4 frontend
Martin Vermeer a écrit : On Fri, Mar 17, 2006 at 04:21:16PM +0200, Martin Vermeer wrote: On Fri, Mar 17, 2006 at 02:49:13PM +0100, Abdelrazak Younes wrote: ... Actually with your first patch, if you open a document, type Ctrl+end, then only half of of screen is redrawn :-) And if you open a new document (ctrl+n), the bottom part of the area is not drawn. Same with the second patch. The reason is that the grey areas that are correctly drawn in paintText, are never exposed. I know how to do it, it's easy... have to run now. Here is the fix for the end-of-document problem. Thanks. What I would really like to know is if this helps when using LyX over a slow line, i.e., does expose really send a rectangle of pixels from the application to the server display, i.e., were all the earlier painting operations to a local canvas only? I am not sure about qt2 but I am quite sure this is the case with qt4 yes especially with my last patch. But I have no way to test that under X11. From what I've read in Qt documentation, the combination of the two patches should help the Mac also. Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Georg Baum a écrit : Am Freitag, 17. März 2006 22:14 schrieb Kayvan A. Sylvan: On Fri, Mar 17, 2006 at 08:29:28PM +0100, Georg Baum wrote: Kayvan, are you listening? Why did you introduce this option also for cygwin? I think this was related to trying to compile for QT/Cygwin. If we can compile for QT on Windows without this, then I am all for removing it. This is the case according to Enrico and Abdel. I am going to commit the attached patch to trunk unless somebody objects. Great! Thanks, Abdel.
Re: [Patch] Wide inset rendering unpleasantness
Am Freitag, 17. März 2006 20:49 schrieb Martin Vermeer:
I committed it to trunk with these changes.
It contains too many const_casts for my taste. Also the purpose of
asTextInset() was to get rid of the the InsetText casts. I am going to
commit the attached modification unless I hear objections.
Georg
Log:
* src/insets/insetbase.h
* src/insets/insettext.h
(asTextInset): constify
src/rowpainter.C
RowPainter::paintInset): remove unneeded casts
paintPar): ditto
Index: src/insets/insetbase.h
===
--- src/insets/insetbase.h (Revision 13415)
+++ src/insets/insetbase.h (Arbeitskopie)
@@ -220,7 +220,7 @@ public:
/// does this contain text that can be change track marked in DVI?
virtual bool canTrackChanges() const { return false; }
/// is this inset based on the TextInset class?
- virtual InsetText * asTextInset() const { return 0; }
+ virtual InsetText const * asTextInset() const { return 0; }
/// return true if the inset should be removed automatically
virtual bool autoDelete() const;
Index: src/insets/insettext.h
===
--- src/insets/insettext.h (Revision 13415)
+++ src/insets/insettext.h (Arbeitskopie)
@@ -59,7 +59,7 @@ public:
///
bool canTrackChanges() const { return true; }
///
- InsetText * asTextInset() const { return const_castInsetText *(this); }
+ InsetText const * asTextInset() const { return this; }
///
int latex(Buffer const , std::ostream ,
OutputParams const ) const;
Index: src/rowpainter.C
===
--- src/rowpainter.C (Revision 13415)
+++ src/rowpainter.C (Arbeitskopie)
@@ -164,10 +164,10 @@ void RowPainter::paintInset(pos_type con
pi.ltr_pos = (text_.bidi.level(pos) % 2 == 0);
pi.erased_ = erased_ || isDeletedText(par_, pos);
theCoords.insets().add(inset, int(x_), yo_);
- InsetBase * in = const_castInsetBase *(inset);
+ InsetText const * const in = inset-asTextInset();
// non-wide insets are painted completely. Recursive
bool tmp = bv_.repaintAll();
- if (!in-asTextInset() || !static_castInsetText*(in)-Wide()) {
+ if (!in || !in-Wide()) {
bv_.repaintAll(true);
lyxerr[Debug::PAINTING] endl Paint inset fully endl;
}
@@ -812,12 +812,12 @@ void paintPar
// If this is the only object on the row, we can make it wide
for (pos_type i = rit-pos() ; i != rit-endpos(); ++i) {
- InsetBase* in
- = const_castInsetBase*(par.getInset(i));
- if (in in-asTextInset()) {
-static_castInsetText*(in)-Wide()
-= in_inset_alone_on_row
- static_castInsetText*(in)-Tall();
+ InsetBase const * const in = par.getInset(i);
+ if (in) {
+InsetText const * const t = in-asTextInset();
+if (t)
+ t-Wide() = in_inset_alone_on_row
+ t-Tall();
}
}
Re: Ping! (Re: [Patch in parent] per-doc charstyles)
Jose' Matos [EMAIL PROTECTED] writes: On Friday 17 March 2006 20:05, Martin Vermeer wrote: Has anybody looked at this? I looked at it. Seemed fine to me on a cursory glance. I'd have hollered otherwise :-P Angus This message is one of the two/three messages in this folder marked as todo. FWIW I am interested. Thinking aloud... what you are doing requires a file format change, right?
Re: Unable to edit and save graphic in lyx-1.4.0 (Qt frontend)
I still fail to reproduce that. Can you send an example file, inclusing the graphic? Jürgen I've attached a tar file called test_graphic.tgz. It contains test_graphic.lyx and a graphic. 1. Open the lyx file. 2. Click on the graphic. 3. Try and change the width parameter to 3in (from its current setting of 4in). 4. The OK and Apply buttons are grayed out and so you cannot make the changes. (Of course, this could be an idiosyncrasy of my compiled lyx-1.4.0 version). Anand test_graphic.tgz Description: application/compressed-tar
Re: [Patch] Wide inset rendering unpleasantness
On Sat, Mar 18, 2006 at 03:37:09PM +0100, Georg Baum wrote: Am Freitag, 17. März 2006 20:49 schrieb Martin Vermeer: I committed it to trunk with these changes. It contains too many const_casts for my taste. Also the purpose of asTextInset() was to get rid of the the InsetText casts. I am going to commit the attached modification unless I hear objections. It looks equivalent... did you try on math and tabulars in the users guide? (Paranoid as always) - Martin pgpA6An9TanVG.pgp Description: PGP signature
Re: Ping! (Re: [Patch in parent] per-doc charstyles)
On Sat, Mar 18, 2006 at 02:51:04PM +, Angus Leeming wrote: Jose' Matos [EMAIL PROTECTED] writes: On Friday 17 March 2006 20:05, Martin Vermeer wrote: Has anybody looked at this? I looked at it. Seemed fine to me on a cursory glance. I'd have hollered otherwise :-P Angus Thanks Angus, for looking at the code. And thanks Jose' for going to look at how it runs ;-) - Martin pgps9U1knBBbK.pgp Description: PGP signature
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Moving on to LyX/Win 1.4, what should I compile? The release tar ball or a snapshot of the 1.4.x tree including the bug fixes that have gone in since 1.4.0 was announced? Personnally I'd prefer the plain 1.4.0 tarball, unless there are some very bad windows bugs. Ok, I'll do that then. Maybe I'll put together a 1.4.x page too for the impatient ;-) In return, can I get you to copy http://wiki.lyx.org/uploads/Windows/LyX137/lyx-1.3.7_win32_setup_v3.exe to the ftp site in place of v2? Angus
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Joost Verburg [EMAIL PROTECTED] writes: In my opinion, the best thing to do would be to combine the best parts of both installers into a new official installer. That's also less confusing for an end-user compared to having both official and unofficial versions. That's a great idea! I think that you and Uwe should get together and bash this out between you. However, be warned. This subject seems to be one on which people have strong opinions. I'm not sure that you can please all of the people all of the time, so be prepared to tough it out. From my point of view, I don't want to download a heap of stuff that I've already got installed. Moreover, there are serious licensing issues with Uwe's version that means it can't become the official version at the moment. At least, that's my understanding of Jean-Marc's position. I'm sure he'll correct me if I'm putting words in his mouth ;-) Regards, Angus
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Angus Leeming [EMAIL PROTECTED] writes: Jean-Marc Lasgouttes lasgouttes at ... writes: Moving on to LyX/Win 1.4, what should I compile? The release tar ball or a snapshot of the 1.4.x tree including the bug fixes that have gone in since 1.4.0 was announced? Personnally I'd prefer the plain 1.4.0 tarball, unless there are some very bad windows bugs. Ok, I'll do that then. Maybe I'll put together a 1.4.x page too for the impatient One further question: unless something has changed recently, LyX 1.3.x and LyX 1.4.x won't live together peacefully unless I run configure --with-version-suffix when building LyX 1.4. Should I do that? Regards, Angus
Re: Unable to edit and save graphic in lyx-1.4.0 (Qt frontend)
Anand Rangarajan wrote: I've attached a tar file called test_graphic.tgz. It contains test_graphic.lyx and a graphic. I see. The problem is the eps file. The bounding box values are not parsed correctly by LyX. If you click on the Clipping pane in the graphics dialog, you'll se that two values are missing (markes red). That's why the OK button is disabled. The line in the file reads %%BoundingBox:58 199 546 602 If you run your graphic through eps2eps, you'll get a working graphic (see attached), where the line has been changed to %BoundingBox: 58 199 547 603 So maybe a whitespace problem. Jürgen LROC_Area_length_96_height_6_back_10-2.eps Description: image/eps
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Angus Leeming a écrit : Angus Leeming [EMAIL PROTECTED] writes: Jean-Marc Lasgouttes lasgouttes at ... writes: Moving on to LyX/Win 1.4, what should I compile? The release tar ball or a snapshot of the 1.4.x tree including the bug fixes that have gone in since 1.4.0 was announced? Personnally I'd prefer the plain 1.4.0 tarball, unless there are some very bad windows bugs. Ok, I'll do that then. Maybe I'll put together a 1.4.x page too for the impatient One further question: unless something has changed recently, LyX 1.3.x and LyX 1.4.x won't live together peacefully unless I run configure --with-version-suffix when building LyX 1.4. Should I do that? Yes please, Bennet is already doing that for MAC. Abdel.
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Angus Leeming wrote: One further question: unless something has changed recently, LyX 1.3.x and LyX 1.4.x won't live together peacefully unless I run configure --with-version-suffix when building LyX 1.4. Should I do that? I think we had this discussion before. IIRC, the conclusion was that it is not necessary to use --with-version-suffix. Installing 1.3.X and 1.4.X in distinct directories and using command line arg -userdir when invoking LyX may be enough. (On the other hand, it shouldn't hurt...) Michael
Re: [patch] fix lib/configure.py invocation for builddir != srcdir
Georg Baum [EMAIL PROTECTED] writes: lib/configure.py cannot be run if you compile with a fresh builddir != srcdir. The reason is that the main configure script creates builddir/lib only after trying to run lib/configure.py. The attached patch fixes that. Does anybody know a better solution? If not I am going to put this in. Just a second... What does foo || bar baz mean? Does it mean: 1) * Run foo. * If foo fails, run bar. * If foo succeeds, run baz. Or does it mean: 2) * Run foo. * If foo fails, run bar. * If bar succeeds, run baz. My understanding is that 1) is how the shell will interpret things. My understanding of your patch is that you think 2) is the way things work... Change: test -d lib || mkdir lib cd lib pthon ... to: test -d lib || mkdir lib; cd lib pthon ... Angus
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Michael Gerz a écrit : Angus Leeming wrote: One further question: unless something has changed recently, LyX 1.3.x and LyX 1.4.x won't live together peacefully unless I run configure --with-version-suffix when building LyX 1.4. Should I do that? I think we had this discussion before. IIRC, the conclusion was that it is not necessary to use --with-version-suffix. Installing 1.3.X and 1.4.X in distinct directories and using command line arg -userdir when invoking LyX may be enough. It is enough indeed but not very user friendly :-) Windows user just double-click... Another solution is to create a shortcut which contains the -userdir argument. That what I suggested to users using winlyx-1.4.0pre. Maybe NSIS is offering that king of functionality? (On the other hand, it shouldn't hurt...) Quite the contrary I would say. Michael
Re: Unable to edit and save graphic in lyx-1.4.0 (Qt frontend)
Am Samstag, 18. März 2006 16:14 schrieb Juergen Spitzmueller: I see. The problem is the eps file. The bounding box values are not parsed correctly by LyX. If you click on the Clipping pane in the graphics dialog, you'll se that two values are missing (markes red). That's why the OK button is disabled. So maybe a whitespace problem. Yes. The bounding box parser in LyX is too stupid. Georg
Citation dialog
Hi Edwin, hi John, I fully understand the complaints of the LyX users. The citation dialog of 1.3 is much more convenient than the one of 1.4! If there is any chance to revive the 1.3 solution, I would really like to see it back in 1.4.1 or 1.4.2. Michael
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Abdelrazak Younes [EMAIL PROTECTED] writes: Georg Baum a écrit : Am Freitag, 17. März 2006 22:14 schrieb Kayvan A. Sylvan: On Fri, Mar 17, 2006 at 08:29:28PM +0100, Georg Baum wrote: Kayvan, are you listening? Why did you introduce this option also for cygwin? I think this was related to trying to compile for QT/Cygwin. If we can compile for QT on Windows without this, then I am all for removing it. This is the case according to Enrico and Abdel. I am going to commit the attached patch to trunk unless somebody objects. Great! Abdel, Georg is removing the switch only for the cygwin compiler not mingw. However, if you use the cygwin compiler with -mno-cygwin I think you will get rid of it, as the host will qualify as cygwin... Let me check. I'll apply the patch and run autogen.sh... Confirmed. After running configure I get: Configuration Host type: i686-pc-cygwin Special build flags:compression use-aspell C Compiler: gcc -mno-cygwin C Compiler LyX flags: C Compiler flags: -I/c/MinGW/include -O2 C++ Compiler: g++ -mno-cygwin (3.4.4) C++ Compiler LyX flags: -fno-exceptions C++ Compiler flags: -I/c/MinGW/include -O2 Linker flags: Linker user flags: -L/usr/local/qt-win32/lib -lqt -lkernel32 -luser32 -lgdi32 -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -luuid -limm32 -lwinmm -lwsock32 -lwinspool -L/c/MinGW/lib Qt Frontend: Qt version: 3.3.5 Packaging: windows LyX binary dir: C:/Programmi/LyX-1.4.0/bin LyX files dir: C:/Programmi/LyX-1.4.0/Resources Configuration of LyX was successful. Type 'make' to compile the program, and then 'make install' to install it. This is interesting. I'll try to compile for a mingw target without the -mms-bitfield switch and see what happens... I bet nothing ;-) -- Enrico
Re: Unable to edit and save graphic in lyx-1.4.0 (Qt frontend)
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen Anand Rangarajan wrote: I've attached a tar file called test_graphic.tgz. It contains test_graphic.lyx and a graphic. Juergen I see. The problem is the eps file. The bounding box values Juergen are not parsed correctly by LyX. If you click on the Juergen Clipping pane in the graphics dialog, you'll se that two Juergen values are missing (markes red). That's why the OK button is Juergen disabled. This is probably http://bugzilla.lyx.org/show_bug.cgi?id=1235 Would be easy to fix. JMarc
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Abdelrazak Younes wrote: Quite the contrary I would say. Ok, then let's use --with-version-suffix. Michael
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg This is the case according to Enrico and Abdel. I am going to Georg commit the attached patch to trunk unless somebody objects. If it works, commit in branch too. JMarc
Re: [Patch] Wide inset rendering unpleasantness
Am Samstag, 18. März 2006 15:56 schrieb Martin Vermeer: It looks equivalent... did you try on math and tabulars in the users guide? (Paranoid as always) Why math? I can't see a change with tabulars. Georg
Re: [patch] fix lib/configure.py invocation for builddir != srcdir
Am Samstag, 18. März 2006 16:11 schrieb Angus Leeming: Georg Baum [EMAIL PROTECTED] writes: Just a second... What does foo || bar baz mean? Does it mean: 1) * Run foo. * If foo fails, run bar. * If foo succeeds, run baz. Or does it mean: 2) * Run foo. * If foo fails, run bar. * If bar succeeds, run baz. My understanding is that 1) is how the shell will interpret things. My understanding of your patch is that you think 2) is the way things work... I believe that it is like this: 3) * Run foo. * If foo fails, run bar and baz. * If foo succeeds, run baz. (left to right evaluation, no precedence of over || and vice versa) My shell (bash, version 2.05b) agrees with me here. Change: test -d lib || mkdir lib cd lib pthon ... to: test -d lib || mkdir lib; cd lib pthon ... I will do the change nevertheless, since I don't know how other shells will interpret it. Georg
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus From my point of view, I don't want to download a heap of stuff Angus that I've already got installed. We could have a network installer and a full installer. I really think the two installers should merge. Angus Moreover, there are serious licensing issues with Uwe's version Angus that means it can't become the official version at the moment. Angus At least, that's my understanding of Jean-Marc's position. I'm Angus sure he'll correct me if I'm putting words in his mouth ;-) Yes, the license for AFPL ghostscript and GSView forbid distribution for a fee. JMarc
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak I think Angus fears that the time the installer is done Abdelrazak and tested, 1.4.1 will be close to release. Then it will be trivial to use the installer framework for 1.4.1 :) Abdelrazak Jean-Marc you said that you want to shorten the delay Abdelrazak between release. Why not make declare a 1.4.1 release Abdelrazak candidate now and work from there. By the way, is there Abdelrazak any performance improvement in current tree? There are no speedups yet. I thought we would have really bad bugs to catter for, but I was wrong. Therefore I think we should add some speedup bugs. - bruteFind speedup: http://bugzilla.lyx.org/show_bug.cgi?id=2217 - maybe the expose tweaks, if you find something everybody is happy with. - maybe the singlerow patch, if it stabilizes in something that does not degrade the LyX experience too much. I did not try the latest iteration. - the qt background and update vs. redraw patches, although I suspect they do not help much. What else? I am tempted to keep the change tracking patches for the next round. There are many other small patches targetted at 1.4.1, and most of them could go in now. JMarc
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus One further question: unless something has changed recently, Angus LyX 1.3.x and LyX 1.4.x won't live together peacefully unless I Angus run configure --with-version-suffix when building LyX 1.4. Note that it is possible in windows to change the version-suffix code to let the binary names along (without -1.4.0). I did that for Mac already. JMarc
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Am Samstag, 18. März 2006 16:44 schrieb Enrico Forestieri: Abdel, Georg is removing the switch only for the cygwin compiler not mingw. But that is what Abdel wants. Or did I misunderstand anything? Georg
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Stephen == Stephen Harris [EMAIL PROTECTED] writes: Stephen So the declare a 1.4.1 release candidate makes sense to me, Stephen a 1.4.1pre_1. The users will be happier and it provides Stephen testing to the newly added bug fixes. Not a bad idea actually. Just skip 1.4.0 in windows. What I did not want was labelling 1.4.0 something that is not really 1.4.0. JMarc
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Enrico Forestieri a écrit : Abdelrazak Younes [EMAIL PROTECTED] writes: Georg Baum a écrit : Am Freitag, 17. März 2006 22:14 schrieb Kayvan A. Sylvan: On Fri, Mar 17, 2006 at 08:29:28PM +0100, Georg Baum wrote: Kayvan, are you listening? Why did you introduce this option also for cygwin? I think this was related to trying to compile for QT/Cygwin. If we can compile for QT on Windows without this, then I am all for removing it. This is the case according to Enrico and Abdel. I am going to commit the attached patch to trunk unless somebody objects. Great! Abdel, Georg is removing the switch only for the cygwin compiler not mingw. You're right... Why did you do that Georg? I was the one complaining about the option not the cygwin users... Could you please update your patch accordingly? However, if you use the cygwin compiler with -mno-cygwin I think you will get rid of it, as the host will qualify as cygwin... Let me check. I'll apply the patch and run autogen.sh... Confirmed. After running configure I get: This is interesting. I'll try to compile for a mingw target without the -mms-bitfield switch and see what happens... I bet nothing ;-) I have tried that in the past but did not succeed (compiling from cygwin a mingw target). The resulting executable never worked. This was related to some ld problems IIRC. I hope you'll have more success. Abdel.
Re: [patch] fix lib/configure.py invocation for builddir != srcdir
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg lib/configure.py cannot be run if you compile with a fresh Georg builddir != srcdir. The reason is that the main configure Georg script creates builddir/lib only after trying to run Georg lib/configure.py. The attached patch fixes that. Does anybody Georg know a better solution? If not I am going to put this in. Put it in. The better solution will be to run configure.py in userdir only. JMarc
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Georg Baum a écrit : Am Samstag, 18. März 2006 16:44 schrieb Enrico Forestieri: Abdel, Georg is removing the switch only for the cygwin compiler not mingw. But that is what Abdel wants. Or did I misunderstand anything? I was maybe not clear... Please do the change for mingw also. Abdel.
Re: [patch] fix lib/configure.py invocation for builddir != srcdir
Am Samstag, 18. März 2006 17:01 schrieb Jean-Marc Lasgouttes: Put it in. Done. The better solution will be to run configure.py in userdir only. That would also mean that LaTeXConfig.lyx would need to be created from a Makefile. Georg
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Abdelrazak Younes wrote: Abdel, Georg is removing the switch only for the cygwin compiler not mingw. But that is what Abdel wants. Or did I misunderstand anything? I was maybe not clear... Please do the change for mingw also. It is wise to remove the option for mingw? I think we are linking against a gettext and libiconv version that was (most likely) built by MSVC or another Non-MinGW compiler. Michael
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes a écrit : Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: There are no speedups yet. I thought we would have really bad bugs to catter for, but I was wrong. Therefore I think we should add some speedup bugs. Good! - bruteFind speedup: http://bugzilla.lyx.org/show_bug.cgi?id=2217 - maybe the expose tweaks, if you find something everybody is happy with. If you talk about the patch I've asked to Martin, I am not sure it will help much the qt2 frontend but it could not harm. It could maybe help more on Mac. - maybe the singlerow patch, if it stabilizes in something that does not degrade the LyX experience too much. I did not try the latest iteration. - the qt background and update vs. redraw patches, although I suspect they do not help much. Maybe not on X11 but they are the right thing to do and do not harm. What else? I would say that it's a good first step. No need to add more speedup fixes. The major one would have to wait (RandomAccessList and UpdateCounter). I am tempted to keep the change tracking patches for the next round. There are many other small patches targetted at 1.4.1, and most of them could go in now. Let them go ;-) Abdel.
Re: [patch] fix lib/configure.py invocation for builddir != srcdir
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg That would also mean that LaTeXConfig.lyx would need to be Georg created from a Makefile. No, it will only be created in the user directory. We should not create anything in the system directory. JMarc
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Abdelrazak Younes [EMAIL PROTECTED] writes: This is interesting. I'll try to compile for a mingw target without the -mms-bitfield switch and see what happens... I bet nothing I have tried that in the past but did not succeed (compiling from cygwin a mingw target). The resulting executable never worked. This was related to some ld problems IIRC. I hope you'll have more success. Strange, I do that all the time without any problem. Perhaps this is due to the fact that I also compile Qt using -mno-cygwin but following the exact procedure as if I was directly using the mingw compiler. This requires patching the Qt sources, but that should be done only for once. -- Enrico
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak I would say that it's a good first step. No need to add Abdelrazak more speedup fixes. The major one would have to wait Abdelrazak (RandomAccessList and UpdateCounter). Ha! I forgot about RandomAccessList! Did someone try it out on 1.4? I did and it seems to work in its latest incarnation. What would the UpdateCounter patch look like? Concerning LyX/Mac, we have several reports that make me believe that the whole document gets rebroken/displayed at times. This is very weird. JMarc
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus One further question: unless something has changed recently, Angus LyX 1.3.x and LyX 1.4.x won't live together peacefully unless I Angus run configure --with-version-suffix when building LyX 1.4. Note that it is possible in windows to change the version-suffix code to let the binary names along (without -1.4.0). I did that for Mac already. to let the binary names along means to leave the binary names alone? Sure, that would be a good idea. I'd really like people to be able to use LyX 1.3.x alongside LyX 1.4.x. Should I hold off building the binary until you do that or should I just use --with-version-suffix now (with the 1.4.0 tarball)? Angus
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Michael Gerz [EMAIL PROTECTED] writes: It is wise to remove the option for mingw? I think we are linking against a gettext and libiconv version that was (most likely) built by MSVC or another Non-MinGW compiler. Then why not compiling libiconv with mingw, too? It is quite strightforward to do. As regards gettext, if you configure with --with-included-gettext, it will be compiled alongside LyX. -- Enrico
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Michael Gerz a écrit : Abdelrazak Younes wrote: Abdel, Georg is removing the switch only for the cygwin compiler not mingw. But that is what Abdel wants. Or did I misunderstand anything? I was maybe not clear... Please do the change for mingw also. It is wise to remove the option for mingw? I think we are linking against a gettext and libiconv version that was (most likely) built by MSVC or another Non-MinGW compiler. I forgot about that. Are we linking with libiconv or just using iconv.exe? Same question for gettext. https://sourceforge.net/project/shownotes.php?release_id=389183 Says that the lib is compiled with mingw so this should not be a problem. I really need this option to be removed for the qt4 frontend when compiled with mingw. The correct solution would be to remove the option only for the frontends/qt4 directory but I don't know if this is possible with m4. Do we have an m4 expert on the list? Abdel.
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes wrote: Abdelrazak I would say that it's a good first step. No need to add Abdelrazak more speedup fixes. The major one would have to wait Abdelrazak (RandomAccessList and UpdateCounter). Ha! I forgot about RandomAccessList! Did someone try it out on 1.4? I did and it seems to work in its latest incarnation. where is the most recent version? If it has a chance to get into 1.4, I'd like to try it out. Jürgen P.S.: I've only the patch for bug 2322 (the bibtex style file thing) in my queue for 1.4.1
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Am Samstag, 18. März 2006 17:18 schrieb Michael Gerz: Abdelrazak Younes wrote: I was maybe not clear... Please do the change for mingw also. Oh, I thought you were using cygwin. How did you compile qt? It should work if you compile it with -mms-bitfields. It is wise to remove the option for mingw? I think we are linking against a gettext and libiconv version that was (most likely) built by MSVC or another Non-MinGW compiler. Exactly that was my reason to remove it for cygwin and not for mingw: On cygwin we assume that every library was compiled with the cygwin gcc compiler, but on mingw we assume that libraries are compiled by MSVC or gcc with -mms-bitfields. Sorry to be so pedantic here, but I really want to understand this issue before doing any change. Georg
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Stephen == Stephen Harris [EMAIL PROTECTED] writes: Stephen So the declare a 1.4.1 release candidate makes sense to me, Stephen a 1.4.1pre_1. The users will be happier and it provides Stephen testing to the newly added bug fixes. Not a bad idea actually. Just skip 1.4.0 in windows. What I did not want was labelling 1.4.0 something that is not really 1.4.0. Perhaps I should read the whole thread before I reply to any one mail :) Ok, so the consensus view is: Build a snapshot of the 1.4.x tree rather than use the 1.4.0 tarball. Use --with-version-suffix Call the resulting installer 1.4.1_pre1 DO IT SOON! Ok, Ok. I hear you! :) Angus
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Am Samstag, 18. März 2006 17:34 schrieb Abdelrazak Younes: I really need this option to be removed for the qt4 frontend when compiled with mingw. The correct solution would be to remove the option only for the frontends/qt4 directory but I don't know if this is possible with m4. This is not an m4 issue. Since several frontends can be built with --with-frontends='qt2 qt4 xforms' this would mean that parts of the code are compiled with -mms-bitfields and others without. That will for sure break things. Georg
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Am Samstag, 18. März 2006 17:25 schrieb Jean-Marc Lasgouttes: Ha! I forgot about RandomAccessList! Did someone try it out on 1.4? I did and it seems to work in its latest incarnation. It works well for me in 1.5. I did not try 1.4. Georg
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Georg Baum a écrit : Am Samstag, 18. März 2006 17:18 schrieb Michael Gerz: Abdelrazak Younes wrote: I was maybe not clear... Please do the change for mingw also. Oh, I thought you were using cygwin. How did you compile qt? It should work if you compile it with -mms-bitfields. I didn't compile Qt4, I used the official package for mingw. That's maybe the problem. I think we should support this official package. It is wise to remove the option for mingw? I think we are linking against a gettext and libiconv version that was (most likely) built by MSVC or another Non-MinGW compiler. Exactly that was my reason to remove it for cygwin and not for mingw: On cygwin we assume that every library was compiled with the cygwin gcc compiler, but on mingw we assume that libraries are compiled by MSVC or gcc with -mms-bitfields. Well except for Qt4.1... Sorry to be so pedantic here, but I really want to understand this issue before doing any change. No problem. The safest solution is to modify the autotools for the qt4 subdir only. Abdel.
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes a écrit : Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak I would say that it's a good first step. No need to add Abdelrazak more speedup fixes. The major one would have to wait Abdelrazak (RandomAccessList and UpdateCounter). Ha! I forgot about RandomAccessList! Did someone try it out on 1.4? I did and it seems to work in its latest incarnation. What would the UpdateCounter patch look like? It would be an optimisation for the call in BreakParagraph. But I have not worked on it at all yet. Abdel. Concerning LyX/Mac, we have several reports that make me believe that the whole document gets rebroken/displayed at times. This is very weird. JMarc
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Concerning LyX/Mac, we have several reports that make me believe that the whole document gets rebroken/displayed at times. This is very weird. Jean-Marc, LyX 1.4 has serious speed problems not only on the Mac. I tried to use 1.4.0pre4 for working on a big document (~60 pages) with lots of figures and equations, and went back to 1.3.7 in desperation. I see that you consider the userguide as a good speed test. Well, I can tell you that LyX 1.4 is blazingly fast editing the userguide with respect to my document... Things seems better with the official release. We are still far from the usability of 1.3.7, but I think that eventually you will get there ;-) -- Enrico
[patch] rowpainter.C
Martin, you have (accidentally?) reverted my rowpainter fix belonging to the fix of bug 2185 in trunk (with your speed up inside insets patch). I gonna commit the attached fix again. Jürgen Index: src/rowpainter.C === --- src/rowpainter.C (Revision 13417) +++ src/rowpainter.C (Arbeitskopie) @@ -753,7 +753,7 @@ bool CursorOnRow(PainterInfo pi, pit_t if (sl.text() == text sl.pit() == pit sl.pos() = rit-pos() - sl.pos() rit-endpos()) + sl.pos() = rit-endpos()) return true; } return false;
Re: qt4: remove (2nd) add dialog in add bib tex ref dialog
On Sat, Mar 18, 2006 at 12:51:07PM +0100, Leuven, E. wrote: i personally think this is more convenient. comments, opinions? Can't I have a qt3 version to look at? Do we really want the two frontends to diverge over these things? regards john
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Georg Baum [EMAIL PROTECTED] writes: Am Samstag, 18. März 2006 17:18 schrieb Michael Gerz: Abdelrazak Younes wrote: I was maybe not clear... Please do the change for mingw also. Oh, I thought you were using cygwin. How did you compile qt? It should work if you compile it with -mms-bitfields. It is wise to remove the option for mingw? I think we are linking against a gettext and libiconv version that was (most likely) built by MSVC or another Non-MinGW compiler. Exactly that was my reason to remove it for cygwin and not for mingw: On cygwin we assume that every library was compiled with the cygwin gcc compiler, but on mingw we assume that libraries are compiled by MSVC or gcc with -mms-bitfields. Sorry to be so pedantic here, but I really want to understand this issue before doing any change. Georg, I compile LyX with mingw as a target using cygwin. Cygwin has a minimal support for mingw as they use it only for compiling their setup.exe installation tool. Indeed, the only supported library is libz. I had to compile every library I needed for building LyX, and it turned out that I only needed Qt, aspell, and libiconv. Nothing more. So, given that those libraries don't use -mms-bitfields, I think it is safe avoiding it. Moreover, if those libraries don't use -mms-bitfields and you enforce it, problems arise (see Abdel case). I think it is easier to add -mms-bitfields to CPPFLAGS (if needed) than hacking some m4 file or editing Makefiles to remove it. Anyway, that's my 2 cents... -- Enrico
Re: [Patch] Wide inset rendering unpleasantness
On Sat, Mar 18, 2006 at 04:52:29PM +0100, Georg Baum wrote: Am Samstag, 18. März 2006 15:56 schrieb Martin Vermeer: It looks equivalent... did you try on math and tabulars in the users guide? (Paranoid as always) Why math? I can't see a change with tabulars. Ah yes, we got rid of math already. Good if things still work... shove it in. Thanks! (I remembered that getting rid of casts was the whole idea of the exercise, just after committing :-) - Martin pgpIIFSILvIyu.pgp Description: PGP signature
RE: qt4: remove (2nd) add dialog in add bib tex ref dialog
it is just the 1st dialog in the qt3 version, but when you click add... it directly pops up the file dialog to add a bib file. edwin -Original Message- From: John Levon [mailto:[EMAIL PROTECTED] Sent: Sat 18-Mar-06 18:12 To: Leuven, E. Cc: lyx-devel@lists.lyx.org Subject: Re: qt4: remove (2nd) add dialog in add bib tex ref dialog On Sat, Mar 18, 2006 at 12:51:07PM +0100, Leuven, E. wrote: i personally think this is more convenient. comments, opinions? Can't I have a qt3 version to look at? Do we really want the two frontends to diverge over these things? regards john
Re: qt4: remove (2nd) add dialog in add bib tex ref dialog
Leuven, E. wrote: it is just the 1st dialog in the qt3 version, but when you click add... it directly pops up the file dialog to add a bib file. So the scanned list of bib files is not available anymore? That's bad. Jürgen
Re: [patch] rowpainter.C
On Sat, Mar 18, 2006 at 06:03:41PM +0100, Juergen Spitzmueller wrote: Martin, you have (accidentally?) reverted my rowpainter fix belonging to the fix of bug 2185 in trunk (with your speed up inside insets patch). I gonna commit the attached fix again. If I did, it was accidental. Could well be. How does it show? - Martin pgpmmVWnxerzm.pgp Description: PGP signature
Re: qt4: remove (2nd) add dialog in add bib tex ref dialog
On Sat, Mar 18, 2006 at 06:19:05PM +0100, Leuven, E. wrote: it is just the 1st dialog in the qt3 version, but when you click add... it directly pops up the file dialog to add a bib file. Why is it more convenient to walk through the file system than have a list of your bibtex databases in front of you? regards john
Re: [patch] rowpainter.C
Also sprach Martin Vermeer: If I did, it was accidental. Could well be. How does it show? While using the DEL key in ct mode, the deletion of the last character in a paragraph is not painted (only after another action). Jürgen
Re: [patch] rowpainter.C
Juergen Spitzmueller wrote: If I did, it was accidental. Could well be. How does it show? While using the DEL key in ct mode, the deletion of the last character in a paragraph is not painted (only after another action). There's yet another similar problem BTW, for which I didn't find a solution. When you merge two (UNCHAGED) paragraphs in ct mode, the blue change bar is not immediately painted as well. Unrelated to my rowpainter change. Do you have an idea? Jürgen
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus One further question: unless something has changed recently, Angus LyX 1.3.x and LyX 1.4.x won't live together peacefully unless I Angus run configure --with-version-suffix when building LyX 1.4. Note that it is possible in windows to change the version-suffix code to let the binary names along (without -1.4.0). I did that for Mac already. Angus commented:to let the binary names along means to leave the binary names alone? Sure, that would be a good idea.I'd really like people to be able to use LyX 1.3.x alongside LyX 1.4.x.Should I hold off building the binary until you do that or should I just use --with-version-suffix now (with the 1.4.0 tarball)?AngusSH: Maybe this already works. I installed Lyx1.3.7 to C:\LyX137 whichcreates a LyX directory up in Application data. This LyX foldercan be renamed to LyX137. Enrico pointed out the following to me:C:\lyx137\bin\lyx.bat -userdir C:\Documents and Settings\Stephen\Application Data\LyX137That goes into your LyX shortcut on the Desktop, all on one linein the Target window that contains your lyx.bat command path.This will automatically generate \Application Data\LyX137 if youhaven't already created it. Next install LyX1.4.0 to C:\LyX140 for instance I have,C:\lyx140\bin\lyx.bat -userdir C:\Documents and Settings\Stephen\Application Data\LyX140All in one line for the LyX140 desktop shortcut. It will automatically create the \Application Data\Lyx140 folder.I tested this with your Lyx140pre win binary with 137v3 and withLyx137v2. They all work together. Enrico showed me how to usea win binary with all Cygwin apps. I have a Cygwin lyx-x11 anda Cyg lyx-winbin which use preferences located in a defined Homethat is not the same as the /Application data/Lyx which is whatthe win binary using cyg apps does use. That is why I manuallyrename it to LyXcyg before installing the windows 137/140 binaries since it isn't started from a Windows shortcut-Target.All this works together and does spellchecking.So a short summary. If a user already has Lyx (137) installed,he should rename his \UserName\Application Data\LyX toC:\Documents and Settings\UserName\Application Data\LyX137and add to the Desktop shortcut Target window:-userdir C:\Documents and Settings\UserName\Application Data\LyX137I don't think it matters that lyx.bat might be in Program files.Lyx1.4.0 should be installed to C:\LyX140The \Application data\Lyx should be renamed to LyX140or you can automatically generate it but the /App data/LyX is unused.Add the following line to the LyX140 Desktop shortcut Target window.-userdir C:\Documents and Settings\UserName\Application Data\LyX140This will generate an /Application data/LyX140 if it doesn't exist.They will share the spellchecking setup you've already established.Perhaps what I have mentioned is not what you really mean. In myControl Panel-Add/Remove programs, there isn't a separate entryfor each version of LyX installed. I'm not sure what that meansif you uninstall that one version listed. Is this what you questionpertains to? So far, this hasn't created a problem for me.Enrico figured out this convenient method,Stephen
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico Jean-Marc, LyX 1.4 has serious speed problems not only on the Enrico Mac. I tried to use 1.4.0pre4 for working on a big document Enrico (~60 pages) with lots of figures and equations, and went back Enrico to 1.3.7 in desperation. Is that in particular when adding/deleting paragraphs? JMarc
Re: qt4: remove (2nd) add dialog in add bib tex ref dialog
John == John Levon [EMAIL PROTECTED] writes: John On Sat, Mar 18, 2006 at 06:19:05PM +0100, Leuven, E. wrote: it is just the 1st dialog in the qt3 version, but when you click add... it directly pops up the file dialog to add a bib file. John Why is it more convenient to walk through the file system than John have a list of your bibtex databases in front of you? What about a combox with this list of databases (and maybe a browse button near the combox?) JMarc
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus to let the binary names along means to leave the binary Angus names alone? Sure, that would be a good idea. It is strange how you manage to grok what I write :) The change is as simple as removing line 594 of config/lyxinclude.m4: program_suffix=$version_suffix If it does what you want, I'll do it in svn on monday (or find someone to do it). Angus I'd really like people to be able to use LyX 1.3.x alongside Angus LyX 1.4.x. Yes. Angus Should I hold off building the binary until you do that or Angus should I just use --with-version-suffix now (with the 1.4.0 Angus tarball)? As you like. JMarc
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Build a snapshot of the 1.4.x tree rather than use the 1.4.0 Angus tarball. Use --with-version-suffix Call the resulting installer Angus 1.4.1_pre1 DO IT SOON! Great. JMarc
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak It would be an optimisation for the call in Abdelrazak BreakParagraph. But I have not worked on it at all yet. OK, I remember your message. JMarc
Re: qt4: remove (2nd) add dialog in add bib tex ref dialog
On Sat, Mar 18, 2006 at 07:10:12PM +0100, Jean-Marc Lasgouttes wrote: John On Sat, Mar 18, 2006 at 06:19:05PM +0100, Leuven, E. wrote: it is just the 1st dialog in the qt3 version, but when you click add... it directly pops up the file dialog to add a bib file. John Why is it more convenient to walk through the file system than John have a list of your bibtex databases in front of you? What about a combox with this list of databases (and maybe a browse button near the combox?) You mean in the first dialog? That would make the dialog pretty confusing IMO... john
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico Jean-Marc, LyX 1.4 has serious speed problems not only on the Enrico Mac. I tried to use 1.4.0pre4 for working on a big document Enrico (~60 pages) with lots of figures and equations, and went back Enrico to 1.3.7 in desperation. Is that in particular when adding/deleting paragraphs? No, I experience sluggishness when trying to move around the document. Sometimes I find myself rolling the wheel without seeing any movement at all. This is not related to Windows as I see it on Debian and Solaris, too. If I load the userguide and press the page down key, the window scrolls almost uniformly until the end. But if I load my document and hold down the PgDn key, the scrolling is rather not uniform. At certain points it even stops and I can count from 1 to 5 before it starts scrolling again. In part it is due to the fact that some figures must be rendered, but if I wait until all figures are rendered and repeat the experiment I see no great improvement (this time when it stops scrolling I can count from 1 to 3 before it restarts). The only difference with the userguide is that I have a lot of figures and equations. This doesn't happen in 1.3.7 where scrolling is still not uniform but never stops. It is really irritating when you roll the wheel or click on the arrows on the sidebar and nothing happens for some seconds... I repeat, this is with with my big document (about 60 pages) full of figures and equations, otherwise with other documents it is bearable. I also see that recently it is a little better than with the prelease versions. -- Enrico
Amazon emails?
I get one of these every time I post to this mailing list. Can someone check the sub list and remove it?? john
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes wrote: We could have a network installer and a full installer. I really think the two installers should merge. Exactly what I mean. There should be one standard and official installer that contains only LyX itself but downloads and installs all required components automatically (if they do not yet exist on the system). This installer will be completely free (GPL). For CD distribution or administrators there can be an alternative one with everything included. If we are going to wait a week or two for some important 1.4.1 fixes, I think there is time enough to make a good start with the 1.4 Windows series and provide an installer without license issues that just works out of the box, like a Windows user expects. But I'm only going to work on such a thing if there is absolute consensus. Joost
Re: [patch] rowpainter.C
On Sat, Mar 18, 2006 at 06:41:50PM +0100, Juergen Spitzmueller wrote:
Juergen Spitzmueller wrote:
...
There's yet another similar problem BTW, for which I didn't find a solution.
When you merge two (UNCHAGED) paragraphs in ct mode, the blue change bar is
not immediately painted as well. Unrelated to my rowpainter change.
Do you have an idea?
Yes, and I committed a patch to trunk:
* text.C
(LyXText::backspace): Fix changebar non-update (Juergen)
attached, trivial mistake.
- Martin
Index: text.C
===
--- text.C (revision 13408)
+++ text.C (working copy)
@@ -1689,7 +1689,7 @@ bool LyXText::backspace(LCursor cur)
if (par.lookupChange(par.size()) != Change::INSERTED) {
par.setChange(par.size(), Change::DELETED);
setCursorIntern(cur, cur.pit() - 1, par.size());
- return false;
+ return true;
}
}
pgpWrRcvTLu38.pgp
Description: PGP signature
Re: Unable to edit and save graphic in lyx-1.4.0 (Qt frontend)
Juergen Spitzmueller [EMAIL PROTECTED] writes: I see. The problem is the eps file. The bounding box values are not parsed correctly by LyX. If you click on the Clipping pane in the graphics dialog, you'll se that two values are missing (markes red). That's why the OK button is disabled. The line in the file reads %%BoundingBox:58 199 546 602 If you run your graphic through eps2eps, you'll get a working graphic (see attached), where the line has been changed to %BoundingBox: 58 199 547 603 Thanks. Running eps2eps fixes the problem. I'll make sure to run eps2eps on matlab generated eps files before inserting them into lyx. Anand Jürgen
Re: qt4: remove (2nd) add dialog in add bib tex ref dialog
Jean-Marc Lasgouttes a écrit : John == John Levon [EMAIL PROTECTED] writes: John On Sat, Mar 18, 2006 at 06:19:05PM +0100, Leuven, E. wrote: it is just the 1st dialog in the qt3 version, but when you click add... it directly pops up the file dialog to add a bib file. John Why is it more convenient to walk through the file system than John have a list of your bibtex databases in front of you? What about a combox with this list of databases (and maybe a browse button near the combox?) IMHO, the bibtex dialog should be accessible from the citation dialog. For the matter, I think everything related to citation should be accessible through the citation dialog. Question: Is it possible to make a reference to a bibtex element as well as a local bibliography element in the same document? I made a proposal for the citation dialog yesterday: I think a simple, case-insensitive, search-as-type is more than enough and more intuitive. A more powerful search tool dialog could be opened in need of advanced search (via Ctr+F and/or a search button). This advanced search button could allow searching bibtex database. I mean, is there a reason why a bibtex reference should not be cited in the same way as a local bibliography reference? I am not a Bibtex user myself because it just seems so complicated... Maybe that's the reason why I don't understand the reason behind this distinction. Or maybe it is a latex issue? I am just a dumb user here so please excuse me if my questions seem obvious to you. Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Enrico Forestieri a écrit : Abdelrazak Younes [EMAIL PROTECTED] writes: This is interesting. I'll try to compile for a mingw target without the -mms-bitfield switch and see what happens... I bet nothing I have tried that in the past but did not succeed (compiling from cygwin a mingw target). The resulting executable never worked. This was related to some ld problems IIRC. I hope you'll have more success. Strange, I do that all the time without any problem. Perhaps this is due to the fact that I also compile Qt using -mno-cygwin but following the exact procedure as if I was directly using the mingw compiler. This requires patching the Qt sources, but that should be done only for once. I am developing for Qt4 and for me patching it is out of the question. I will try again when I have some time. Abdel.
Re: Unable to edit and save graphic in lyx-1.4.0 (Qt frontend)
I still fail to reproduce that. Can you send an example file, inclusing the graphic? Jürgen Anand Rangarajan wrote: > I compiled and installed lyx-1.4.0 (Qt frontend) on a SUSE 10 x86_64 box. > > In lyx-1.4.0, I'm unable to edit and save a graphic. I wonder if I'm doing > something stupid. Anyway, here's the problem. > > 1. Open a new lyx file. > > 2. Insert a graphic using the "Insert graphic" button on the toolbar. > Browse and choose a file. > > 3. Set the width parameter to 4in. Click OK and the dialog vanishes. > > 4. Save the document. > > 5. Click on the graphic again. Change the width to 3in. > > 6. Try and click OK to save your changes to the graphic. > > 7. I cannot do this. The "OK" button on the dialog is grayed out and cannot > be clicked. Consequently, I cannot make any changes to the graphic. I have > to delete it and insert a new graphic with the properties that I want. > > Anand
Re: Ping! (Re: [Patch in parent] per-doc charstyles)
On Friday 17 March 2006 20:05, Martin Vermeer wrote: > > Has anybody looked at this? This message is one of the two/three messages in this folder marked as todo. ;-) FWIW I am interested. :-) Thinking aloud... what you are doing requires a file format change, right? > - Martin -- José Abílio
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
> Moving on to LyX/Win 1.4, what should I compile? The release tar ball or a > snapshot of the 1.4.x tree including the bug fixes that have gone in since 1.4.0 was announced? Personnally I'd prefer the plain 1.4.0 tarball, unless there are some very bad windows bugs. JMarc Mañana. Angus
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Angus Leeming wrote: Ok, I know that I'm a bit behind the times, but I've just uploaded LyX/Win 1.3.7-3 to http://wiki.lyx.org/Windows/LyX137. This thing uses the new Aspell dictionaries and seems to work well. Moving on to LyX/Win 1.4, what should I compile? The release tar ball or a snapshot of the 1.4.x tree including the bug fixes that have gone in since 1.4.0 was announced? Maybe it would be a good idea to provide both a 1.4.0 installer as well as a monthly development preview, so Windows will also be able to help testing. I reviewed the currently available installers (the official installer and the LyXWinInstaller) and their scripts. Both seem to have some flaws in the way their install and uninstall components and in the NSIS scripts. In my opinion, the best thing to do would be to combine the best parts of both installers into a new official installer. That's also less confusing for an end-user compared to having both official and unofficial versions. Joost
Re: Ping! (Re: [Patch in parent] per-doc charstyles)
On Sat, Mar 18, 2006 at 08:31:21AM +, Jose' Matos wrote: > On Friday 17 March 2006 20:05, Martin Vermeer wrote: > > > > Has anybody looked at this? > > This message is one of the two/three messages in this folder marked as > todo. ;-) > > FWIW I am interested. :-) > > Thinking aloud... what you are doing requires a file format change, right? Yes... user charstyle definitions in the header. Converting charstyle insets in the document back to ordinary font attributes on going back to an older LyX format would be nice to have ;-) - Martin pgpP7mHOjiSvX.pgp Description: PGP signature
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes a écrit : Moving on to LyX/Win 1.4, what should I compile? The release tar ball or a snapshot of the 1.4.x tree including the bug fixes that have gone in since 1.4.0 was announced? Personnally I'd prefer the plain 1.4.0 tarball, unless there are some very bad windows bugs. I think Angus fears that the time the installer is done and tested, 1.4.1 will be close to release. Jean-Marc you said that you want to shorten the delay between release. Why not make declare a 1.4.1 release candidate now and work from there. By the way, is there any performance improvement in current tree? IMHO the 1.4.0 performance on windows is quite bad and I don't think many people many people will switch from 1.3.7. Abdel.
qt4: remove (2nd) add dialog in add bib tex ref dialog
Title: qt4: remove (2nd) add dialog in add bib tex ref dialog
i personally think this is more convenient.
comments, opinions?
patch attached.
edwin
Index: Makefile.dialogs
===
--- Makefile.dialogs (revision 13415)
+++ Makefile.dialogs (working copy)
@@ -16,7 +16,6 @@
QAskForTextUi.ui \
QBibitemUi.ui \
QBibtexUi.ui \
- QBibtexAddUi.ui \
QBoxUi.ui \
QBranchUi.ui \
QChangesUi.ui \
Index: QBibtexDialog.C
===
--- QBibtexDialog.C (revision 13415)
+++ QBibtexDialog.C (working copy)
@@ -47,43 +47,14 @@
form, SLOT(slotOK()));
connect(closePB, SIGNAL(clicked()),
form, SLOT(slotClose()));
+ connect( addBibPB, SIGNAL( clicked() ), this, SLOT( browseBibPressed() ) );
+ connect( deletePB, SIGNAL( clicked() ), this, SLOT( deletePressed() ) );
+ connect( stylePB, SIGNAL( clicked() ), this, SLOT( browsePressed() ) );
+ connect( styleCB, SIGNAL( textChanged(const QString&) ), this, SLOT( change_adaptor() ) );
+ connect( databaseLW, SIGNAL( selectionChanged() ), this, SLOT( databaseChanged() ) );
+ connect( bibtocCB, SIGNAL( toggled(bool) ), this, SLOT( change_adaptor() ) );
+ connect( btPrintCO, SIGNAL( activated(int) ), this, SLOT( change_adaptor() ) );
-connect( stylePB, SIGNAL( clicked() ), this, SLOT( browsePressed() ) );
-connect( deletePB, SIGNAL( clicked() ), this, SLOT( deletePressed() ) );
-connect( styleCB, SIGNAL( textChanged(const QString&) ), this, SLOT( change_adaptor() ) );
-connect( databaseLB, SIGNAL( selectionChanged() ), this, SLOT( databaseChanged() ) );
-connect( bibtocCB, SIGNAL( toggled(bool) ), this, SLOT( change_adaptor() ) );
-connect( btPrintCO, SIGNAL( activated(int) ), this, SLOT( change_adaptor() ) );
-connect( addBibPB, SIGNAL( clicked() ), this, SLOT( addPressed() ) );
-
- add_ = new UiDialog(this, true);
-
- Qt2BC * bcview = new Qt2BC(add_bc_);
- add_bc_.view(bcview);
- add_bc_.bp(new OkCancelPolicy);
-
- bcview->setOK(add_->addPB);
- bcview->setCancel(add_->closePB);
-
- add_->bibED->setValidator(new PathValidator(false, add_->bibED));
- addCheckedLineEdit(add_bc_.view(), add_->bibED, 0);
-
- connect(add_->bibED, SIGNAL(textChanged(const QString&)),
- this, SLOT(bibEDChanged()));
- connect(add_->addPB, SIGNAL(clicked()),
- this, SLOT(addDatabase()));
- connect(add_->bibLB, SIGNAL(selected(Q3ListBoxItem *)),
- this, SLOT(addDatabase()));
- connect(add_->bibLB, SIGNAL(selected(Q3ListBoxItem *)),
- add_, SLOT(accept()));
- connect(add_->bibLB, SIGNAL(currentChanged(Q3ListBoxItem *)),
- this, SLOT(availableChanged()));
- connect(add_->browsePB, SIGNAL(clicked()),
- this, SLOT(browseBibPressed()));
-
-connect( add_->addPB, SIGNAL( clicked() ), this, SLOT( accept() ) );
-connect( add_->closePB, SIGNAL( clicked() ), this, SLOT( reject() ) );
-
}
@@ -91,15 +62,6 @@
{}
-void QBibtexDialog::bibEDChanged()
-{
- // Indicate to the button controller that the contents have
- // changed. The actual test of validity is carried out by
- // the checkedLineEdit.
- add_bc_.valid(true);
-}
-
-
void QBibtexDialog::change_adaptor()
{
form_->changed();
@@ -139,66 +101,29 @@
string const f = ChangeExtension(file, "");
bool present = false;
- for (unsigned int i = 0; i != add_->bibLB->count(); i++) {
- if (fromqstr(add_->bibLB->text(i)) == f)
+ for (unsigned int i = 0; i != databaseLW->count(); i++) {
+ if (fromqstr(databaseLW->item(i)->text()) == f)
present = true;
}
if (!present) {
- add_->bibLB->insertItem(toqstr(f));
+ databaseLW->addItem(toqstr(f));
form_->changed();
}
-
- add_->bibED->setText(toqstr(f));
}
}
-void QBibtexDialog::addPressed()
-{
- add_->exec();
- add_bc_.valid(false);
-}
-
-
-void QBibtexDialog::addDatabase()
-{
- int const sel = add_->bibLB->currentItem();
- string const file = trim(fromqstr(add_->bibED->text()));
-
- if (sel < 0 && file.empty())
- return;
-
- // Add the selected browser_bib keys to browser_database
- // multiple selections are possible
- for (unsigned int i = 0; i != add_->bibLB->count(); i++) {
- if (add_->bibLB->isSelected(i)) {
- // do not allow duplicates
- if ((databaseLB->findItem(add_->bibLB->text(i))) == 0)
-databaseLB->insertItem(add_->bibLB->text(i));
- }
- }
-
- if (!file.empty()) {
- QString const f = toqstr(ChangeExtension(file, ""));
- if ((databaseLB->findItem(f)) == 0)
- databaseLB->insertItem(f);
- }
-
- form_->changed();
-}
-
-
void QBibtexDialog::deletePressed()
{
- databaseLB->removeItem(databaseLB->currentItem());
+ delete databaseLW->takeItem(databaseLW->currentRow());
}
void QBibtexDialog::databaseChanged()
{
- deletePB->setEnabled(!form_->readOnly() && databaseLB->currentItem() != -1);
+ deletePB->setEnabled(!form_->readOnly() && databaseLW->currentRow() != -1);
}
Index: QBibtexDialog.h
===
---
Re: qt4: remove (2nd) add dialog in add bib tex ref dialog
Leuven, E. wrote: > i personally think this is more convenient. > comments, opinions? fine with me. Jürgen
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Am Freitag, 17. März 2006 22:14 schrieb Kayvan A. Sylvan:
> On Fri, Mar 17, 2006 at 08:29:28PM +0100, Georg Baum wrote:
> > Kayvan, are you listening? Why did you introduce this option also for
> > cygwin?
>
> I think this was related to trying to compile for QT/Cygwin. If we can
> compile for QT on Windows without this, then I am all for removing it.
This is the case according to Enrico and Abdel. I am going to commit the
attached patch to trunk unless somebody objects.
Georg
Log:
Remove unneeded test for gcc2 on cygwin
Don't set -mms-bitfields on cygwin
Index: config/cygwin.m4
===
--- config/cygwin.m4 (Revision 13415)
+++ config/cygwin.m4 (Arbeitskopie)
@@ -4,36 +4,19 @@
AC_DEFUN([CHECK_WITH_CYGWIN],
[
case $host_os in
- cygwin* | mingw* | pw32* )
+ mingw* | pw32* )
if test "$GCC" = yes; then
# Ensure MSVC-compatible struct packing convention.
# Depends on GCC version. gcc2 uses -fnative-struct while
# gcc3 uses -mms-bitfields.
- #
- msnative_struct=''
- AC_MSG_CHECKING([how to get MSVC-compatible struct packing])
- case `$CC --version | sed -e 's,\..*,.,' -e q` in
- 2.)
-if $CC -v --help 2>/dev/null | grep fnative-struct > /dev/null; then
-msnative_struct='-fnative-struct'
-fi
-;;
- *)
-if $CC -v --help 2>/dev/null | grep ms-bitfields > /dev/null; then
-msnative_struct='-mms-bitfields'
-fi
-;;
- esac
-
- if test x"$msnative_struct" = x; then
-AC_MSG_RESULT([no way])
-AC_MSG_WARN([produced libraries might be incompatible with MSVC libs])
- else
-CXXFLAGS="$CXXFLAGS $msnative_struct"
-AC_MSG_RESULT([${msnative_struct}])
- fi
+ # We support only gcc3.
+ CXXFLAGS="$CXXFLAGS -mms-bitfields"
fi
+;;
+ esac
+ case $host_os in
+ cygwin* | mingw* | pw32* )
# Export all symbols to Win32 DLL using MinGW 2.0 ld.
WIN32_LD_EXPORT_ALL_SYMBOLS=''
AC_MSG_CHECKING([whether ld accepts --export-all-symbols])
Re: LyX/Win 1.3.7 version 3 and a LyX/Win 1.4 question
Jean-Marc Lasgouttes a écrit : Moving on to LyX/Win 1.4, what should I compile? The release tar ball or a snapshot of the 1.4.x tree including the bug fixes that have gone in since 1.4.0 was announced? Personnally I'd prefer the plain 1.4.0 tarball, unless there are some very bad windows bugs. Abdel: I think Angus fears that the time the installer is done and tested, 1.4.1 will be close to release. Jean-Marc you said that you want to shorten the delay between release. Why not make declare a 1.4.1 release candidate now and work from there. By the way, is there any performance improvement in current tree? IMHO the 1.4.0 performance on windows is quite bad and I don't think many people many people will switch from 1.3.7. Abdel. SH: This post reflects my point of view. It is not that there are "very bad windows bugs" but that there are so many of them. If the release contains the bug fixes to date and is called 1.4.0, then it is not as easy to compare with the original unfixed 1.4.0 So the "declare a 1.4.1 release candidate" makes sense to me, a 1.4.1pre_1. The users will be happier and it provides testing to the newly added bug fixes. It is pretty easy though, to have both 1.3.7 and 1.4.0 versions coexist peacefully with Windows. The Linux and WinLyX versions could be synced at 1.4.0pre_2 Releasing 1.4.1pre1 assuages Win users feeling of being neglected. I also like Joost's suggestions particulary in regard to 1.4.0 which might have adequate developer resources to support it. However the 1.3.7 idea, which seems ideal, will likely encounter practical resistance, such as a lower priority, and general lack of agreement. Regards, Stephen
Re: [patch] remove qt2 support
Am Freitag, 17. März 2006 21:42 schrieb Leuven, E.:
> if qt2 goes, the attached should go (in) as well i think (i.e. remove
qgridview.[Ch])
You are right. I did not know that we had these classes! The full patch
would look like the attached. Dou you have commit privileges now, or
should I commit it for you?
Georg
Index: src/frontends/qt2/qgridview.h
===
--- src/frontends/qt2/qgridview.h (Revision 13415)
+++ src/frontends/qt2/qgridview.h (Arbeitskopie)
@@ -1,134 +0,0 @@
-/**
-** $Id: qgridview.h,v 1.3 2004/12/14 11:05:44 leeming Exp $
-**
-** Definition of QGridView class
-**
-** Created: 2001.05.23
-**
-** Copyright (C) 1992-2001 Trolltech AS. All rights reserved.
-**
-** This file is part of the widgets module of the Qt GUI Toolkit.
-**
-** This file may be distributed under the terms of the Q Public License
-** as defined by Trolltech AS of Norway and appearing in the file
-** LICENSE.QPL included in the packaging of this file.
-**
-** This file may be distributed and/or modified under the terms of the
-** GNU General Public License version 2 as published by the Free Software
-** Foundation and appearing in the file LICENSE.GPL included in the
-** packaging of this file.
-**
-** Licensees holding valid Qt Enterprise Edition or Qt Professional Edition
-** licenses may use this file in accordance with the Qt Commercial License
-** Agreement provided with the Software.
-**
-** This file is provided AS IS with NO WARRANTY OF ANY KIND, INCLUDING THE
-** WARRANTY OF DESIGN, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
-**
-** See http://www.trolltech.com/pricing.html or email [EMAIL PROTECTED] for
-** information about Qt Commercial License Agreements.
-** See http://www.trolltech.com/qpl/ for QPL licensing information.
-** See http://www.trolltech.com/gpl/ for GPL licensing information.
-**
-** Contact [EMAIL PROTECTED] if any conditions of this licensing are
-** not clear to you.
-**
-**/
-
-#ifndef QGRIDVIEW_H
-#define QGRIDVIEW_H
-
-#include
-
-#ifndef QT_NO_GRIDVIEW
-
-class QGridViewPrivate;
-
-class QGridView : public QScrollView
-{
-Q_OBJECT
-Q_PROPERTY( int numRows READ numRows WRITE setNumRows )
-Q_PROPERTY( int numCols READ numCols WRITE setNumCols )
-Q_PROPERTY( int cellWidth READ cellWidth WRITE setCellWidth )
-Q_PROPERTY( int cellHeight READ cellHeight WRITE setCellHeight )
-public:
-
-QGridView( QWidget *parent=0, const char *name=0, WFlags f=0 );
- ~QGridView();
-
-int numRows() const;
-virtual void setNumRows( int );
-int numCols() const;
-virtual void setNumCols( int );
-
-int cellWidth() const;
-virtual void setCellWidth( int );
-int cellHeight() const;
-virtual void setCellHeight( int );
-
-QRect cellRect() const;
-QRect cellGeometry( int row, int column );
-QSize gridSize() const;
-
-int rowAt( int y ) const;
-int columnAt( int x ) const;
-
-void repaintCell( int row, int column, bool erase=TRUE );
-void updateCell( int row, int column );
-void ensureCellVisible( int row, int column );
-
-protected:
-virtual void paintCell( QPainter *, int row, int col ) = 0;
-virtual void paintEmptyArea( QPainter *p, int cx, int cy, int cw, int ch );
-
-void drawContents( QPainter *p, int cx, int cy, int cw, int ch );
-
-virtual void dimensionChange( int, int );
-
-private:
-void drawContents( QPainter* );
-void updateGrid();
-
-int nrows;
-int ncols;
-int cellw;
-int cellh;
-QGridViewPrivate* d;
-
-private: // Disabled copy constructor and operator=
-#if defined(Q_DISABLE_COPY)
-QGridView( const QGridView & );
-QGridView =( const QGridView & );
-#endif
-};
-
-inline int QGridView::cellWidth() const
-{ return cellw; }
-
-inline int QGridView::cellHeight() const
-{ return cellh; }
-
-inline int QGridView::rowAt( int y ) const
-{ return y / cellh; }
-
-inline int QGridView::columnAt( int x ) const
-{ return x / cellw; }
-
-inline int QGridView::numRows() const
-{ return nrows; }
-
-inline int QGridView::numCols() const
-{return ncols; }
-
-inline QRect QGridView::cellRect() const
-{ return QRect( 0, 0, cellw, cellh ); }
-
-inline QSize QGridView::gridSize() const
-{ return QSize( ncols * cellw, nrows * cellh ); }
-
-
-
-#endif // QT_NO_GRIDVIEW
-
-
-#endif // QTABLEVIEW_H
Index: src/frontends/qt2/Makefile.dialogs
===
--- src/frontends/qt2/Makefile.dialogs (Revision 13415)
+++ src/frontends/qt2/Makefile.dialogs (Arbeitskopie)
@@ -97,7 +97,6 @@ MOCFILES = \
QExternalDialog.C QExternalDialog.h \
QFloatDialog.C QFloatDialog.h \
QGraphicsDialog.C QGraphicsDialog.h \
- qgridview.C qgridview.h \
QIncludeDialog.C QIncludeDialog.h \
QIndexDialog.C QIndexDialog.h \
QLogDialog.C
[patch] fix lib/configure.py invocation for builddir != srcdir
lib/configure.py cannot be run if you compile with a fresh builddir != srcdir. The reason is that the main configure script creates builddir/lib only after trying to run lib/configure.py. The attached patch fixes that. Does anybody know a better solution? If not I am going to put this in. Georg Index: configure.ac === --- configure.ac (Revision 13415) +++ configure.ac (Arbeitskopie) @@ -474,7 +474,7 @@ AC_CONFIG_FILES([Makefile m4/Makefile \ src/frontends/qt4/ui/Makefile \ ]) echo "Running $LYX_ABS_TOP_SRCDIR/lib/configure.py --with-version-suffix=\"$version_suffix\"" -(cd lib && python $LYX_ABS_TOP_SRCDIR/lib/configure.py --with-version-suffix="$version_suffix") +(test -d lib || mkdir lib && cd lib && python $LYX_ABS_TOP_SRCDIR/lib/configure.py --with-version-suffix="$version_suffix") AC_OUTPUT # show version information
Re: Qt4 frontend
On Fri, Mar 17, 2006 at 04:21:16PM +0200, Martin Vermeer wrote:
> On Fri, Mar 17, 2006 at 02:49:13PM +0100, Abdelrazak Younes wrote:
>
> ...
>
> > Actually with your first patch, if you open a document, type Ctrl+end,
> > then only half of of screen is redrawn :-)
> > And if you open a new document (ctrl+n), the bottom part of the area is
> > not drawn.
>
> Same with the second patch. The reason is that the grey areas that are
> correctly drawn in paintText, are never exposed. I know how to do it,
> it's easy... have to run now.
Here is the fix for the end-of-document problem.
What I would really like to know is if this helps when using LyX over a
slow line, i.e., does "expose" really send a rectangle of pixels from
the application to the server display, i.e., were all the earlier
painting operations to a local canvas only?
- Martin
Index: metricsinfo.h
===
--- metricsinfo.h (revision 13408)
+++ metricsinfo.h (working copy)
@@ -102,13 +102,14 @@ class ViewMetricsInfo
{
public:
ViewMetricsInfo(lyx::pit_type p1, lyx::pit_type p2, int y1, int y2,
- bool singlepar) : p1(p1), p2(p2), y1(y1), y2(y2),
- singlepar(singlepar) {}
+ bool singlepar, lyx::pit_type size) : p1(p1), p2(p2),
+ y1(y1), y2(y2), singlepar(singlepar), size(size) {}
lyx::pit_type p1;
lyx::pit_type p2;
int y1;
int y2;
bool singlepar;
+ lyx::pit_type size;
};
Index: BufferView_pimpl.C
===
--- BufferView_pimpl.C (revision 13408)
+++ BufferView_pimpl.C (working copy)
@@ -1348,6 +1348,8 @@ ViewMetricsInfo BufferView::Pimpl::metri
theCoords.clear();
BufferView & bv = *bv_;
LyXText * const text = bv.text();
+ lyx::pit_type size = int(text->paragraphs().size());
+
if (anchor_ref_ > int(text->paragraphs().size() - 1)) {
anchor_ref_ = int(text->paragraphs().size() - 1);
offset_ref_ = 0;
@@ -1434,7 +1436,8 @@ ViewMetricsInfo BufferView::Pimpl::metri
<< " pit2: " << pit2
<< " npit: " << npit
<< " singlepar: " << singlepar
+<< "size: " << size
<< endl;
- return ViewMetricsInfo(pit1, pit2, y1, y2, singlepar);
+ return ViewMetricsInfo(pit1, pit2, y1, y2, singlepar, size);
}
Index: frontends/screen.C
===
--- frontends/screen.C (revision 13408)
+++ frontends/screen.C (working copy)
@@ -219,7 +219,10 @@ void LyXScreen::redraw(BufferView & bv,
workarea().getPainter().start();
paintText(bv, vi);
lyxerr[Debug::DEBUG] << "Redraw screen" << endl;
- expose(0, 0, workarea().workWidth(), workarea().workHeight());
+ int const ymin = std::max(vi.y1, 0);
+ int const dymax = ( vi.p2 < vi.size - 1 ?
+ vi.y2 - ymin : workarea().workHeight() - ymin );
+ expose(0, ymin, workarea().workWidth(), dymax);
workarea().getPainter().end();
theCoords.doneUpdating();
}
pgp4g8C5q8BQQ.pgp
Description: PGP signature
