Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Jürgen Spitzmüller
Bo Peng wrote:
  OK for this one?

 OK.

I did some further cleanup and integrated Bo's patch for bug 3654.
See attached.

Jürgen
Index: src/frontends/qt4/QDocument.cpp
===
--- src/frontends/qt4/QDocument.cpp	(Revision 18428)
+++ src/frontends/qt4/QDocument.cpp	(Arbeitskopie)
@@ -214,7 +214,8 @@
 		this, SLOT(change_adaptor()));
 	connect(textLayoutModule-listingsED, SIGNAL(textChanged()),
 		this, SLOT(validate_listings_params()));
-	textLayoutModule-listingsTB-setPlainText(Input listings parameters below. Enter ? for a list of parameters.);
+	textLayoutModule-listingsTB-setPlainText(
+		qt_(Input listings parameters on the right. Enter ? for a list of parameters.));
 	textLayoutModule-lspacingLE-setValidator(new QDoubleValidator(
 		textLayoutModule-lspacingLE));
 	textLayoutModule-skipLE-setValidator(unsignedLengthValidator(
@@ -616,7 +617,8 @@
 		if (!isOK) {
 			isOK = true;
 			// listingsTB-setTextColor(black);
-			textLayoutModule-listingsTB-setPlainText(Input listings parameters below. Enter ? for a list of parameters.);
+			textLayoutModule-listingsTB-setPlainText(
+qt_(Input listings parameters on the right. Enter ? for a list of parameters.));
 			okPB-setEnabled(true);
 		}
 	} catch (invalidParam  e) {
Index: src/frontends/qt4/QInclude.cpp
===
--- src/frontends/qt4/QInclude.cpp	(Revision 18428)
+++ src/frontends/qt4/QInclude.cpp	(Arbeitskopie)
@@ -91,7 +91,8 @@
 		InsetListingsParams par(fromqstr(listingsED-toPlainText()));
 		if (!isOK) {
 			isOK = true;
-			listingsTB-setPlainText(Input listings parameters on the right. Enter ? for a list of parameters.);
+			listingsTB-setPlainText(
+qt_(Input listings parameters on the right. Enter ? for a list of parameters.));
 			okPB-setEnabled(true);
 		}
 	} catch (invalidParam  e) {
@@ -206,7 +207,8 @@
 	dialog_-captionLE-clear();
 	dialog_-labelLE-clear();
 	dialog_-listingsED-clear();
-	dialog_-listingsTB-setPlainText(Input listings parameters on the right. Enter ? for a list of parameters.);
+	dialog_-listingsTB-setPlainText(
+		qt_(Input listings parameters on the right. Enter ? for a list of parameters.));
 
 	string cmdname = controller().params().getCmdName();
 	if (cmdname != include 
@@ -246,6 +248,7 @@
 if (cap[0] == '{'  cap[cap.size()-1] == '}')
 	dialog_-captionLE-setText(toqstr(cap.substr(1, cap.size()-2)));
 else
+	// FIXME: make this translatable!
 	throw invalidParam(caption parameter is not quoted with braces);
 *it = ;
 			} else if (prefixIs(*it, label=)) {
@@ -253,6 +256,7 @@
 if (lbl[0] == '{'  lbl[lbl.size()-1] == '}')
 	dialog_-labelLE-setText(toqstr(lbl.substr(1, lbl.size()-2)));
 else
+	// FIXME: make this translatable!
 	throw invalidParam(label parameter is not quoted with braces);
 *it = ;
 			}
Index: src/frontends/qt4/QListings.h
===
--- src/frontends/qt4/QListings.h	(Revision 18428)
+++ src/frontends/qt4/QListings.h	(Arbeitskopie)
@@ -38,6 +38,8 @@
 	void on_floatCB_stateChanged(int state);
 	/// turn off float when inline is clicked
 	void on_inlineCB_stateChanged(int state);
+	/// turn off numbering options when none is selected
+	void on_numberSideCO_currentIndexChanged(int);
 protected:
 	virtual void closeEvent(QCloseEvent * e);
 private:
Index: src/frontends/qt4/ui/ListingsUi.ui
===
--- src/frontends/qt4/ui/ListingsUi.ui	(Revision 18428)
+++ src/frontends/qt4/ui/ListingsUi.ui	(Arbeitskopie)
@@ -258,7 +258,7 @@
  stringChoose the Font Size/string
 /property
 property name=editable 
- booltrue/bool
+ boolfalse/bool
 /property
 property name=autoCompletion 
  booltrue/bool
@@ -269,7 +269,23 @@
/widget
   /item
   item row=0 column=1 
-   widget class=QComboBox name=numberSideCO /
+   widget class=QComboBox name=numberSideCO 
+item
+ property name=text 
+  stringNone/string
+ /property
+/item
+item
+ property name=text 
+  stringLeft/string
+ /property
+/item
+item
+ property name=text 
+  stringRight/string
+ /property
+/item
+   /widget
   /item
  /layout
 /widget
@@ -424,7 +440,7 @@
stringChoose the Font Style/string
   /property
   property name=editable 
-   booltrue/bool
+   boolfalse/bool
   /property
   property name=autoCompletion 
  

Re: [PATCH-again] Bugs 643, 3047, and 3090

2007-05-20 Thread Georg Baum
Am Samstag, 19. Mai 2007 18:45 schrieb Richard Heck:
 Georg Baum wrote:
  A flag for the name of that directory does already exist: resultdir. 
Please 
  use that instead of /path/file.html.conversion/.

 I could be wrong, but this seems to do something else.
 /path/file.html.conversion/ is where the files end up if you're
 exporting, and the copying happens in Exporter.cpp. The resultdir flag
 operates in Converter.cpp and seems (though it's hard to tell, since
 it's not actually used in any of our converters) to inform us where the
 external converter will have put its output, and then things get moved
 in Converter.cpp, and then they get moved again in Exporter.cpp, if
 we're exporting. I also don't think we want to require resultdir to be
 set whenever usetempdir is. It may well be though (I haven't tried) that
 setting resultdir with usetempdir is possible and works as one would 
hope.

Yes, I mixed that up. So resultdir should be set if and only if the 
converter creates a directory by itself. Please make sure that this does 
work in combination with usetempdir, or make these two flags mutually 
exclusive (since usetempdir is not really needed if the converter creates 
a directory itself one could ignore usetempdir if resultdir is set).

  As a result, the originaldir flag does not need to be used by any of 
our
  converters, and it may be redundant, though there's no harm leaving 
it,
  so far as I can see.

  IMHO it should be removed. 
 Have done. When I looked more closely, it caused massive problems: The
 existing code copies all HTML files found in the original directory to
 the temporary directory, whether they were created by the converter or
 not! It's amazing there's no bug report for that.

There have been several bug reports about the originaldir flag, not only in 
bugzilla but also on the users list. It is sort of known that it does not 
really work, but until now nobody was interested to fix it.

 Here's an idea: Instead of Converter::convert() returning a boolean,
 have it return a the location of the converted file as a FileName. It
 can return an empty one (checkable with FileName::empty()) on error.
 I'll still need the used_temp_dir boolean as a flag, though, ...
  Then there is some error checking missing: If the caller can't deal 
with a 
  converted directory (e.g. for preview) then it should check that the 
  result is indeed a file and act appropriately if that is not the case.

 as I do NOT want to return a directory.

I missed that, I thought you were returning a directory. Since you return a 
file I believe that no check is needed indeed.

 The HTML converter, for example, 
 dumps about a billion files but there is going to be one that the viewer
 wants, and it's that FileName I want to return, since there's no general
 way in which to recover it. The temporary directory, on the other hand,
 can be recovered as the path portion of the file name. Then again, I
 suppose I could return a std::pairFileName, bool or a
 std::pairFileName, FileName, with the latter being the temporary
 directory if one was created, rather than have a bool  as an argument.
 Advice welcome. My intuitions aren't always great here. (I tend to think
 Perl. Just make it work.)

If you do that I think the FileName, bool would be better. But I also 
think that the simple bool as return value is expressive. What confused me 
was the fact that there were two signatures. If there is only one, and the 
name of the converted file is always set by the converter, then I think it 
is clear.

  BTW there is another problem in this area that I solved in my 
playground 
  branch: Some converters don't accept a commandline argument to set the 
  resulting file name, but determine it using their own rules. They only 
  work if these rules match the naming given by LyX, but will fail if a 
user 
  changes e.g. the extension of a format. I solved this by a new 
resultfile 
  flag.

 I think you might have committed this.

No, I only changed the semantics. Search for result_file in 
http://www.lyx.org/trac/browser/lyx-devel/branches/personal/baum/playground/src/converter.h
 
and 
http://www.lyx.org/trac/browser/lyx-devel/branches/personal/baum/playground/src/converter.C
 
to see the details.

 I see the resultfile flag in the 
 exiting code and was wondering exactly what it did.

It is documented in Converter.h.

 Again, there's no 
 converter that ships with LyX (i.e., that is configured by configure.py)
 that sets this.

Candidates for the flag with the new semantics are all converters without 
the $$o placeholder.
The old semantics is maybe needed for some HTML converters. One would have 
to check whether the guess of LyX for the main file name is correct.


Georg



[patch] some more beamer adjustments

2007-05-20 Thread Jürgen Spitzmüller
Adds optional arguments whereever this makes sense.

OK?
Jürgen
Index: lib/layouts/beamer.layout
===
--- lib/layouts/beamer.layout	(Revision 18428)
+++ lib/layouts/beamer.layout	(Arbeitskopie)
@@ -51,6 +51,7 @@
   Margin   Static
   LatexTypeItem_Environment
   LatexNameitemize
+  OptionalArgs 1
   NextNoIndent 1
   LeftMargin   MMN
   LabelSep xx
@@ -69,6 +70,7 @@
   Margin   Static
   LatexTypeItem_Environment
   LatexNameenumerate
+  OptionalArgs 2
   NextNoIndent 1
   LeftMargin   MMN
   LabelSep xx
@@ -87,6 +89,7 @@
   Margin   First_Dynamic
   LatexTypeItem_environment
   LatexNamedescription
+  OptionalArgs 2
   NextNoIndent 1
   LeftMargin   MM
   LabelSep xxx
@@ -112,6 +115,7 @@
   Margin   Dynamic
   LatexTypeCommand
   LatexNamepart
+  OptionalArgs 1
   NeedProtect  1
   NextNoIndent 1
   Labelsep xxx
@@ -224,6 +228,7 @@
   KeepEmpty1
   LatexTypeCommand
   LatexNamelyxframeend{}\lyxframe
+  OptionalArgs 1
   Margin   First_Dynamic
   NextNoIndent 1
   ParSkip  0
@@ -303,6 +308,7 @@
   KeepEmpty 0
   LatexType Command
   LatexName lyxframeend{}\lyxagainframe
+  OptionalArgs  2
   MarginFirst_Dynamic
   NextNoIndent  1
   ParSkip   0
@@ -509,6 +515,7 @@
   LatexType Command
   LatexName pause
   MarginFirst_Dynamic
+  OptionalArgs  1
   NextNoIndent  1
   ParSkip   0
   TopSep0


DIA diagram file with embedded (linked?) bitmap fails to convert

2007-05-20 Thread John Pye
Hi all

I have set up a file type and converter for DIA diagram files in LyX.

The first problem was that if the DIA file is compressed (settings in
the DIA File..Save As window) then LyX recognises it as a 'gzip' type
file, even though it has .dia file extension and is a value DIA file.

The next problem is that my DIA file has an embedded bitmap image in it.
When I open the file in DIA, it looks great. When I do the file
conversion on the commandline, it works great. But the preview in LyX
fails: the embedded bitmap shows up with DIA's 'broken image' icon in
place of the file.

I am guessing that the LyX conversion script is moving my file to a
temporary location in order to do the file conversion, and this is
causing it to break.

Surely DIA files are standard fare for regular LyX users, and should be
supported directly somehow, not with user 'custom settings' bizzo?

Cheers
JP




Re:[patch] some more beamer adjustments

2007-05-20 Thread Uwe Stöhr

 Adds optional arguments whereever this makes sense.

 OK?

Yes.

regarsd Uwe


Re: [Cvslog] r18419 - in /lyx-devel/trunk/src: frontends/qt4/QLPainter...

2007-05-20 Thread Jürgen Spitzmüller
Stefan Schimanski wrote:
 Will commit if nobody complains.

The current policy is not commit if nobody complains, but commit if you got 
two OK's or the OK from José.

Please stick to that.

Jürgen


Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Uwe Stöhr

 I did some further cleanup and integrated Bo's patch for bug 3654.
 See attached.

I tested it and Bo's patch for 3654 works fine. Looking into your code I find 
all reasonable.

So OK from me to commit.

regards UWe


Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Jürgen Spitzmüller
Uwe Stöhr wrote:
 I tested it and Bo's patch for 3654 works fine. Looking into your code I
 find all reasonable.

 So OK from me to commit.

Bo, I'll commit if I get your OK.

Jürgen


Re: [Cvslog] r18419 - in /lyx-devel/trunk/src: frontends/qt4/QLPainter...

2007-05-20 Thread Stefan Schimanski
Sorry, got a ok from Richard privately and Andre originally proposed  
exactly the same code just with a std::vector. Counted that as ok.


Stefan


Stefan Schimanski wrote:

Will commit if nobody complains.


The current policy is not commit if nobody complains, but commit  
if you got

two OK's or the OK from José.

Please stick to that.

Jürgen




PGP.sig
Description: Signierter Teil der Nachricht


Re: [Cvslog] r18419 - in /lyx-devel/trunk/src: frontends/qt4/QLPainter...

2007-05-20 Thread Jürgen Spitzmüller
Stefan Schimanski wrote:
 Sorry, got a ok from Richard privately and Andre originally proposed  
 exactly the same code just with a std::vector. Counted that as ok.

OK then.

Jürgen


Re: Scrolling lag in 1.5svn again, more details.

2007-05-20 Thread Abdelrazak Younes

Peter Kümmel wrote:

Abdelrazak Younes wrote:

Peter Kümmel wrote:

Next try. To see how it works change the event_delay_ms
variable in the constructor to 3000 and use -dbg 12.

This looks way too complicated Peter. There must be a simpler solution.

Abdel.



Is this your only comment?


Yes. Sorry, don't have the time to do much more. I thought I'd share my 
opinion ;-)




Anyway I don't think there is a simpler solution, at least I will
not look for it, this bug has cost me already too much time.


I can understand that. I was thinking of collecting the scroll events 
and cancelling them if a scroll operation is still on-going but maybe 
that's what your patch do. I only briefly looked at it and it _seems_ 
very complicated.




Dimitri from Trolltech wrote on a similar problem:

You'll need to maintain flags, QTimers waiting N milliseconds and other
data to achive that. There's no equivalent information maintained by Qt.

http://lists.trolltech.com/qt-interest/2006-02/thread00129-0.html


Hope this has convinced you. ;)


I trust you.

Abdel.



Re: [patch] adding powerdot layout was: Re: [announce] LyX 1.5beta3-18-05-2007 for Windows

2007-05-20 Thread Uwe Stöhr

 Attached is the patch. The powerdot.layout requires to check for three
 packages in the file chkconfig.ltx but this is unproblematic I think.

 Why are rotate-textures and listings required?

rotate-textures was there to assure that the genmisc-package was used which was once required by 
powerdot. Attached a better patch.


The listingins-package is required to be able to compile the 
powerdot-example.lyx file.

 The powerdot documentation does
 not list that in the dependencies table (but it does pstricks.sty, which
 should be added).

I added this now. We forgot btw. to check for the pfg-package that is required 
by beamer.
I corrected all issues in the attached better patch.

 There is one issue I don't know: The file is under the LPPL, is this
 license compatible with our?

 I think in general it would be good to have an agreement with the authors to
 ship it with LyX.

I have got it now:

 Original-Nachricht 
Betreff: Re: [powerdot] new powerdot.layout file for LyX and license question
Datum: Sun, 20 May 2007 10:40:07 +0200
Von: Hendri Adriaens [EMAIL PROTECTED]
An: Uwe Stöhr [EMAIL PROTECTED]
CC: Christopher Ellison [EMAIL PROTECTED]
Referenzen: [EMAIL PROTECTED]

Hi Uwe,

 attached is an updated layout file for LyX1.5beta3.
 I want to include the layout file to our LyX SVN repository and want to 
include it to the LyX
 windows installer bundle. Am I allowed to do so? The layout file is under the 
LPPL but LyX under the
 GPL version 2, is this a problem?

I have no idea regarding the license. If I can still also bundle it in
powerdot under lppl (I have no time to change it), you can bundle it
with LyX under gpl. Please let me know what your decision will be.

 - I will also include and maintain the powerdot-example.lyx to LyX, OK?

Ok.

Best regards,
-Hendri.

---

 Best would be that we take care of distribution, so that
 there arent't two separate layouts (the one that comes with LyX and the one
 that ships with powerdot itself).

I'll assured this:

Hendri wote:

 Yes, the layout file is for the new LyX-series LyX 1.5 that will be released 
in June and not
 compatible for LyX 1.4.x. For LyX 1.4.x I could release an updated layout 
version together with
 LyX 1.4.5.
 So I think we should left the layout file for some month on powerdot and 
when you bring out the
 next powerdot version it can go from powerdot. The people will the have some 
time to switch to
 LyX 1.5.

 Ok, sounds fine.

thanks and regards
Uwe
Index: development/scons/scons_manifest.py
===
--- development/scons/scons_manifest.py	(revision 18430)
+++ development/scons/scons_manifest.py	(working copy)
@@ -2423,6 +2423,7 @@
 modernCV.lyx
 multicol.lyx
 noweb2lyx.lyx
+powerdot-example.lyx
 script_form.lyx
 simplecv.lyx
 splash.lyx
@@ -2646,6 +2647,7 @@
 mwbk.layout
 mwrep.layout
 paper.layout
+powerdot.layout
 report.layout
 revtex.layout
 revtex4.layout
Index: lib/chkconfig.ltx
===
--- lib/chkconfig.ltx	(revision 18430)
+++ lib/chkconfig.ltx	(working copy)
@@ -227,6 +227,7 @@
 \TestPackage{booktabs}
 \TestPackage{color} % this one should be there if graphics.sty is there.
 \TestPackage{dvipost}
+\TestPackage{enumitem} % needed by powerdot
 \TestPackage{esint}
 \TestPackage{fancybox}
 \TestPackage{fancyhdr}
@@ -240,8 +241,10 @@
 \TestPackage{natbib}
 \TestPackage{nomencl}
 \TestPackage{pdfcolmk}
+\TestPackage{pgf} % needed by beamer
 \TestPackage{prettyref}
 \TestPackage{preview}
+\TestPackage{pstricks} % needed by powerdot
 \TestPackage{rotating}
 \TestPackage{setspace}
 \TestPackage{soul}
@@ -250,7 +253,9 @@
 \TestPackage{varioref}
 \TestPackage{url}
 \TestPackage{xcolor}
+\TestPackage{xkeyval} % needed by powerdot
 
+
 % The test for the graphics package is slightly more involved...
 \newcommand\groption{dvips}
 \TestItem{graphicx}{package}{sty}
Index: lib/Makefile.am
===
--- lib/Makefile.am	(revision 18430)
+++ lib/Makefile.am	(working copy)
@@ -210,6 +210,7 @@
 	examples/modernCV.lyx \
 	examples/multicol.lyx \
 	examples/noweb2lyx.lyx \
+	examples/powerdot-example.lyx \
 	examples/script_form.lyx \
 	examples/simplecv.lyx \
 	examples/splash.lyx
@@ -956,6 +957,7 @@
 	layouts/mwbk.layout \
 	layouts/mwrep.layout \
 	layouts/paper.layout \
+	layouts/powerdot.layout \
 	layouts/report.layout \
 	layouts/revtex.layout \
 	layouts/revtex4.layout \


Re: [patch] adding powerdot layout was: Re: [announce] LyX 1.5beta3-18-05-2007 for Windows

2007-05-20 Thread Jürgen Spitzmüller
Uwe Stöhr wrote:
 I corrected all issues in the attached better patch.

Good. However, wait for Jean-Marc's comment before committing.

Jürgen


Re: crash tex2lyx

2007-05-20 Thread Stefan Schimanski

So, got it :-) The problem is this neat trick:

 * This class is just a dummy version of that in the main LyX source  
tree

 * to enable tex2lyx to use LyX's textclass classes and not have to
 * re-invent the wheel.

in the Font.h of lyx2tex. Unfortunately the sizes of the objects are  
different. But as a member of TextClass this makes a difference if  
the inline functions of TextClass use the dummy Font from tex2lyx,  
but the implementation the real one from LyX. No patch yet... have to  
use the sun outside at the river first :-)


Stefan

Am 19.05.2007 um 23:16 schrieb Stefan Schimanski:

There is something really strange going on. I am trying to debug  
the problem for half an hour now as it also shows up on my machine.  
The layoutlist_ containter looks fine before the cit = begin()  
call in TextClass::read. But when I step into the begin() function  
suddenly the start value of the layoutlist_ container turns into  
0x0. More precisely in TextClass::read tells me that  
layoutlist_::P_impl is at 0xb0c8. In the begin() call though it  
is shown at 0xb0e8 where the 0x0 is. This either smells like a  
compiler error or some memory corruption.


Stefan

Am 16.05.2007 um 13:42 schrieb Leuven, E.:


with attached doc.

backtrace:

tex2lyx.exe!boost::assertion_failed(const char *  
expr=0x005b6c44, const char * function=0x005b6c50, const char *  
file=0x005b6cc0, long line=315)  Line 39 + 0x8 bytes   C++
tex2lyx.exe!boost::shared_ptrlyx::Layout::operator-()   
Line 315 + 0x23 bytes C++
   tex2lyx.exe!lyx::TextClass::read(const  
lyx::support::FileName  filename={...}, bool merge=false)  Line  
455 + 0x12 bytesC++
tex2lyx.exe!lyx::parse_preamble(lyx::Parser  p={...},  
std::basic_ostreamchar,std::char_traitschar   os={...}, const  
std::basic_stringchar,std::char_traitschar,std::allocatorchar  
  forceclass=)  Line 502   C++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx 
(std::basic_istreamchar,std::char_traitschar   is={...},  
std::basic_ostreamchar,std::char_traitschar   os={...})  Line  
428 + 0x3e bytesC++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx(const  
lyx::support::FileName  infilename={...},  
std::basic_ostreamchar,std::char_traitschar   os={...})  Line  
462 + 0x10 bytesC++
tex2lyx.exe!lyx::tex2lyx(const  
std::basic_stringchar,std::char_traitschar,std::allocatorchar  
  infilename=C:/_projects/profs3/internal.tex, const  
lyx::support::FileName  outfilename={...})  Line 494 + 0x38  
bytes   C++
tex2lyx.exe!main(int argc=2, char * * argv=0x003d52f8)   
Line 554 + 0x35 bytes   C++

tex2lyx.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes  C
tex2lyx.exe!mainCRTStartup()  Line 403  C
kernel32.dll!7c816fd7()

internal.tex






PGP.sig
Description: Signierter Teil der Nachricht


Re: crash tex2lyx

2007-05-20 Thread Stefan Schimanski

So, got it :-) The problem is this neat trick:

 * This class is just a dummy version of that in the main LyX source  
tree

 * to enable tex2lyx to use LyX's textclass classes and not have to
 * re-invent the wheel.

in the Font.h of lyx2tex. Unfortunately the sizes of the objects are  
different. But as a member of TextClass this makes a difference if  
the inline functions of TextClass use the dummy Font from tex2lyx,  
but the implementation the real one from LyX. No patch yet... have to  
use the sun outside at the river first :-)


Stefan

P.S.: Is this a duplicate of the mail? Again I cannot see my previous  
one, although it shows up in the archive at http://marc.info/?l=lyx- 
develm=117966063615447w=2 Are there any problems with the mailman?


Am 19.05.2007 um 23:16 schrieb Stefan Schimanski:

There is something really strange going on. I am trying to debug  
the problem for half an hour now as it also shows up on my machine.  
The layoutlist_ containter looks fine before the cit = begin()  
call in TextClass::read. But when I step into the begin() function  
suddenly the start value of the layoutlist_ container turns into  
0x0. More precisely in TextClass::read tells me that  
layoutlist_::P_impl is at 0xb0c8. In the begin() call though it  
is shown at 0xb0e8 where the 0x0 is. This either smells like a  
compiler error or some memory corruption.


Stefan

Am 16.05.2007 um 13:42 schrieb Leuven, E.:


with attached doc.

backtrace:

tex2lyx.exe!boost::assertion_failed(const char *  
expr=0x005b6c44, const char * function=0x005b6c50, const char *  
file=0x005b6cc0, long line=315)  Line 39 + 0x8 bytes   C++
tex2lyx.exe!boost::shared_ptrlyx::Layout::operator-()   
Line 315 + 0x23 bytes C++
   tex2lyx.exe!lyx::TextClass::read(const  
lyx::support::FileName  filename={...}, bool merge=false)  Line  
455 + 0x12 bytesC++
tex2lyx.exe!lyx::parse_preamble(lyx::Parser  p={...},  
std::basic_ostreamchar,std::char_traitschar   os={...}, const  
std::basic_stringchar,std::char_traitschar,std::allocatorchar  
  forceclass=)  Line 502   C++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx 
(std::basic_istreamchar,std::char_traitschar   is={...},  
std::basic_ostreamchar,std::char_traitschar   os={...})  Line  
428 + 0x3e bytesC++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx(const  
lyx::support::FileName  infilename={...},  
std::basic_ostreamchar,std::char_traitschar   os={...})  Line  
462 + 0x10 bytesC++
tex2lyx.exe!lyx::tex2lyx(const  
std::basic_stringchar,std::char_traitschar,std::allocatorchar  
  infilename=C:/_projects/profs3/internal.tex, const  
lyx::support::FileName  outfilename={...})  Line 494 + 0x38  
bytes   C++
tex2lyx.exe!main(int argc=2, char * * argv=0x003d52f8)   
Line 554 + 0x35 bytes   C++

tex2lyx.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes  C
tex2lyx.exe!mainCRTStartup()  Line 403  C
kernel32.dll!7c816fd7()

internal.tex






PGP.sig
Description: Signierter Teil der Nachricht


Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Bo Peng

On 5/20/07, Jürgen Spitzmüller [EMAIL PROTECTED] wrote:

Uwe Stöhr wrote:
 I tested it and Bo's patch for 3654 works fine. Looking into your code I
 find all reasonable.

 So OK from me to commit.

Bo, I'll commit if I get your OK.


Please commit.

Bo


Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Bo Peng

 Bo, I'll commit if I get your OK.

Please commit.


Hold on. Why do you removed all initialization (clear() ...) code in
update_content? I did this because when I jump back and forth between
insets, values from previous inset need to be removed.

Cheers,
Bo


Re: [patch] some more beamer adjustments

2007-05-20 Thread Bo Peng

On 5/20/07, Uwe Stöhr [EMAIL PROTECTED] wrote:

  Adds optional arguments whereever this makes sense.
 
  OK?


Still no fragile support?

Bo


Re: BUG 3622: Weird date external material.

2007-05-20 Thread Bo Peng

I propose the attached patch. Can I apply?


So no one knows this lyxsum stuff? My patch will do no harm on
platforms when my testcase return error for ifstream(/a/path) so if
should be safe to commit.

OK?

Bo


Re: [patch] some more beamer adjustments

2007-05-20 Thread Jürgen Spitzmüller
Bo Peng wrote:
 Still no fragile support?

No. Too difficult AFAICS.

Jürgen


Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Jürgen Spitzmüller
Bo Peng wrote:
 Hold on. Why do you removed all initialization (clear() ...) code in
 update_content? I did this because when I jump back and forth between
 insets, values from previous inset need to be removed.

I see. I moved them to the constructor, together with all the initialization 
stuff for the widgets, which really belong there (it does not make sense to 
refill each combo on every update).

I'll move the default settings back, see attached patch. 

OK?

Jürgen
Index: src/frontends/qt4/QDocument.cpp
===
--- src/frontends/qt4/QDocument.cpp	(Revision 18428)
+++ src/frontends/qt4/QDocument.cpp	(Arbeitskopie)
@@ -214,7 +214,8 @@
 		this, SLOT(change_adaptor()));
 	connect(textLayoutModule-listingsED, SIGNAL(textChanged()),
 		this, SLOT(validate_listings_params()));
-	textLayoutModule-listingsTB-setPlainText(Input listings parameters below. Enter ? for a list of parameters.);
+	textLayoutModule-listingsTB-setPlainText(
+		qt_(Input listings parameters on the right. Enter ? for a list of parameters.));
 	textLayoutModule-lspacingLE-setValidator(new QDoubleValidator(
 		textLayoutModule-lspacingLE));
 	textLayoutModule-skipLE-setValidator(unsignedLengthValidator(
@@ -616,7 +617,8 @@
 		if (!isOK) {
 			isOK = true;
 			// listingsTB-setTextColor(black);
-			textLayoutModule-listingsTB-setPlainText(Input listings parameters below. Enter ? for a list of parameters.);
+			textLayoutModule-listingsTB-setPlainText(
+qt_(Input listings parameters on the right. Enter ? for a list of parameters.));
 			okPB-setEnabled(true);
 		}
 	} catch (invalidParam  e) {
Index: src/frontends/qt4/QInclude.cpp
===
--- src/frontends/qt4/QInclude.cpp	(Revision 18428)
+++ src/frontends/qt4/QInclude.cpp	(Arbeitskopie)
@@ -91,7 +91,8 @@
 		InsetListingsParams par(fromqstr(listingsED-toPlainText()));
 		if (!isOK) {
 			isOK = true;
-			listingsTB-setPlainText(Input listings parameters on the right. Enter ? for a list of parameters.);
+			listingsTB-setPlainText(
+qt_(Input listings parameters on the right. Enter ? for a list of parameters.));
 			okPB-setEnabled(true);
 		}
 	} catch (invalidParam  e) {
@@ -206,7 +207,8 @@
 	dialog_-captionLE-clear();
 	dialog_-labelLE-clear();
 	dialog_-listingsED-clear();
-	dialog_-listingsTB-setPlainText(Input listings parameters on the right. Enter ? for a list of parameters.);
+	dialog_-listingsTB-setPlainText(
+		qt_(Input listings parameters on the right. Enter ? for a list of parameters.));
 
 	string cmdname = controller().params().getCmdName();
 	if (cmdname != include 
@@ -246,6 +248,7 @@
 if (cap[0] == '{'  cap[cap.size()-1] == '}')
 	dialog_-captionLE-setText(toqstr(cap.substr(1, cap.size()-2)));
 else
+	// FIXME: make this translatable!
 	throw invalidParam(caption parameter is not quoted with braces);
 *it = ;
 			} else if (prefixIs(*it, label=)) {
@@ -253,6 +256,7 @@
 if (lbl[0] == '{'  lbl[lbl.size()-1] == '}')
 	dialog_-labelLE-setText(toqstr(lbl.substr(1, lbl.size()-2)));
 else
+	// FIXME: make this translatable!
 	throw invalidParam(label parameter is not quoted with braces);
 *it = ;
 			}
Index: src/frontends/qt4/QListings.h
===
--- src/frontends/qt4/QListings.h	(Revision 18428)
+++ src/frontends/qt4/QListings.h	(Arbeitskopie)
@@ -38,6 +38,8 @@
 	void on_floatCB_stateChanged(int state);
 	/// turn off float when inline is clicked
 	void on_inlineCB_stateChanged(int state);
+	/// turn off numbering options when none is selected
+	void on_numberSideCO_currentIndexChanged(int);
 protected:
 	virtual void closeEvent(QCloseEvent * e);
 private:
Index: src/frontends/qt4/ui/ListingsUi.ui
===
--- src/frontends/qt4/ui/ListingsUi.ui	(Revision 18428)
+++ src/frontends/qt4/ui/ListingsUi.ui	(Arbeitskopie)
@@ -258,7 +258,7 @@
  stringChoose the Font Size/string
 /property
 property name=editable 
- booltrue/bool
+ boolfalse/bool
 /property
 property name=autoCompletion 
  booltrue/bool
@@ -269,7 +269,23 @@
/widget
   /item
   item row=0 column=1 
-   widget class=QComboBox name=numberSideCO /
+   widget class=QComboBox name=numberSideCO 
+item
+ property name=text 
+  stringNone/string
+ /property
+/item
+item
+ property name=text 
+  stringLeft/string
+ /property
+/item
+item
+ property name=text 
+  stringRight/string
+ /property
+/item
+   

Re: lyx-1.5.0beta3 build failure

2007-05-20 Thread Bennett Helm

On May 20, 2007, at 4:47 AM, Roger Mc Murtrie wrote:


Hi Bennet,
I've been trying to compile lyx-1.5.0beta3 but get the following in  
response to make:


Making all in config
make[1]: Nothing to be done for `all'.
Making all in development
Making all in MacOSX
Making all in spotlight
make[3]: *** No rule to make target `LyX-Metadata', needed by `all- 
am'.  Stop.

make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1


config command:
./configure --prefix=/Applications/LyX.app --with-version- 
suffix=-1.5 --without-x --with-frontend=qt4 --with-qt4-dir=/usr/ 
local/Trolltech/Qt-4.2.2 --with-included-gettext --enable- 
optimization=-Os --disable-stdlib-debug --disable-concept-checks -- 
enable-debug --enable-assertions


Setting prefix to /Applications/LyX.app seems to correctly  
produce  bundledir in the spotlight makefile.


I checked that spotlightbindir  is set to  /Applications/LyX.app/ 
Contents/Library/Spotlight/LyX-Metadata.mdimporter/Contents/MacOS

which does contain the file  LyX-Metadata

Have you any ideas on what might be going wrong?


This is a problem introduced in preparing the sources for beta 3;  
it's not a problem for svn. What should happen is that the LyX  
application bundle should get automatically created in the directory  
specified by the --prefix option; that won't happen because of the  
compile failure you're getting. The workaround is to take an existing  
version of LyX.app and copy it to the --prefix directory, and then do:


make -k
make -k install

(The -k tells make to continue after errors, such as the one you  
encountered. There shouldn't be any other errors.)


Bennett


Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Bo Peng

I'll move the default settings back, see attached patch.

OK?


Yes.

Thanks.

Bo


Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Jürgen Spitzmüller
Bo Peng wrote:
  OK?

 Yes.

Done.
Once you find some time, could you please add tooltips to the dialog? You now 
better than me what the specific widgets are supposed to do.

Jürgen


Re: Qt4 mac

2007-05-20 Thread Scott Lambert
I built Qt4.2.3 from source exactly as described in INSTALL.MacOSX.  
(I even literally used /path/to/QT4 as the destination.) Here are  
some lines from the configure script. It seems to find some things in  
the Qt4 tree but not others.


checking for QT4_CORE... checking for QT4_FRONTEND... checking for Qt  
4 library name... failed

checking for moc-qt4... no
checking for moc... /path/to/QT4//bin/moc
checking for uic-qt4... no
checking for uic... /path/to/QT4//bin/uic


Bob,
I tried using:
export PKG_CONFIG_PATH=/path/to/Qt4/lib/pkgconfig/

It didn't help. In fact my Qt4 tree contains not such directory!
I have attached a full listing of my Qt4 tree.
scott-lamberts-computer:/path/to/qt4 slambert$ ls -mR
bin, doc, include, lib, mkspecs, plugins, translations

./bin:
moc, qmake, rcc, uic, uic3

./doc: [I DELETED THIS PART OF THE OUTPUT]

./include:
Qt, Qt3Support, QtCore, QtGui, QtNetwork, QtOpenGL, QtSql, QtSvg, QtXml

./include/Qt:
Qt3Support, QtCore, QtGui, QtNetwork, QtOpenGL, QtSql, QtSvg, QtXml, 
q3accel.h, q3action.h, q3asciicache.h, q3asciidict.h, q3boxlayout.h, 
q3button.h, q3buttongroup.h, q3cache.h, q3canvas.h, q3cleanuphandler.h, 
q3combobox.h, q3cstring.h, q3databrowser.h, q3datatable.h, q3dataview.h, 
q3datetimeedit.h, q3deepcopy.h, q3dict.h, q3dns.h, q3dockarea.h, 
q3dockwindow.h, q3dragobject.h, q3dropsite.h, q3editorfactory.h, 
q3filedialog.h, q3frame.h, q3ftp.h, q3garray.h, q3gcache.h, q3gdict.h, 
q3glist.h, q3grid.h, q3gridlayout.h, q3gridview.h, q3groupbox.h, q3gvector.h, 
q3hbox.h, q3header.h, q3hgroupbox.h, q3http.h, q3iconview.h, q3intcache.h, 
q3intdict.h, q3listbox.h, q3listview.h, q3localfs.h, q3mainwindow.h, 
q3memarray.h, q3mimefactory.h, q3multilineedit.h, q3network.h, 
q3networkprotocol.h, q3objectdict.h, q3paintdevicemetrics.h, q3painter.h, 
q3picture.h, q3pointarray.h, q3polygonscanner.h, q3popupmenu.h, q3process.h, 
q3progressbar.h, q3progressdialog.h, q3ptrcollection.h, q3ptrdict.h, 
q3ptrlist.h, q3ptrqueue.h, q3ptrstack.h, q3ptrvector.h, q3rangecontrol.h, 
q3scrollview.h, q3semaphore.h, q3serversocket.h, q3shared.h, q3signal.h, 
q3simplerichtext.h, q3socket.h, q3socketdevice.h, q3sortedlist.h, 
q3sqlcursor.h, q3sqleditorfactory.h, q3sqlfieldinfo.h, q3sqlform.h, 
q3sqlpropertymap.h, q3sqlrecordinfo.h, q3sqlselectcursor.h, q3strlist.h, 
q3strvec.h, q3stylesheet.h, q3syntaxhighlighter.h, q3tabdialog.h, q3table.h, 
q3textbrowser.h, q3textedit.h, q3textstream.h, q3textview.h, q3tl.h, 
q3toolbar.h, q3url.h, q3urloperator.h, q3valuelist.h, q3valuestack.h, 
q3valuevector.h, q3vbox.h, q3vgroupbox.h, q3whatsthis.h, q3widgetstack.h, 
q3wizard.h, qabstractbutton.h, qabstracteventdispatcher.h, 
qabstractfileengine.h, qabstractitemdelegate.h, qabstractitemmodel.h, 
qabstractitemview.h, qabstractpagesetupdialog.h, qabstractprintdialog.h, 
qabstractproxymodel.h, qabstractscrollarea.h, qabstractslider.h, 
qabstractsocket.h, qabstractspinbox.h, qabstracttextdocumentlayout.h, 
qaccessible.h, qaccessiblebridge.h, qaccessibleobject.h, qaccessibleplugin.h, 
qaccessiblewidget.h, qaction.h, qactiongroup.h, qalgorithms.h, qapplication.h, 
qatomic.h, qatomic_alpha.h, qatomic_arch.h, qatomic_arm.h, 
qatomic_boundschecker.h, qatomic_generic.h, qatomic_i386.h, qatomic_ia64.h, 
qatomic_macosx.h, qatomic_mips.h, qatomic_parisc.h, qatomic_powerpc.h, 
qatomic_s390.h, qatomic_sparc.h, qatomic_x86_64.h, qbasictimer.h, qbitarray.h, 
qbitmap.h, qboxlayout.h, qbrush.h, qbuffer.h, qbuttongroup.h, qbytearray.h, 
qbytearraymatcher.h, qcache.h, qcalendarwidget.h, qcdestyle.h, qchar.h, 
qcheckbox.h, qcleanlooksstyle.h, qclipboard.h, qcolor.h, qcolordialog.h, 
qcolormap.h, qcombobox.h, qcommonstyle.h, qcompleter.h, qconfig-dist.h, 
qconfig-large.h, qconfig-medium.h, qconfig-minimal.h, qconfig-small.h, 
qconfig.h, qcontainerfwd.h, qcoreapplication.h, qcoreevent.h, qcursor.h, 
qdatastream.h, qdatawidgetmapper.h, qdatetime.h, qdatetimeedit.h, qdebug.h, 
qdesktopservices.h, qdesktopwidget.h, qdial.h, qdialog.h, qdialogbuttonbox.h, 
qdir.h, qdirmodel.h, qdockwidget.h, qdom.h, qdrag.h, qdrawutil.h, qendian.h, 
qerrormessage.h, qevent.h, qeventloop.h, qfactoryinterface.h, qfeatures.h, 
qfile.h, qfiledialog.h, qfileinfo.h, qfilesystemwatcher.h, qfocusframe.h, 
qfont.h, qfontcombobox.h, qfontdatabase.h, qfontdialog.h, qfontinfo.h, 
qfontmetrics.h, qframe.h, qfsfileengine.h, qftp.h, qgl.h, qglcolormap.h, 
qglframebufferobject.h, qglobal.h, qglpixelbuffer.h, qgraphicsitem.h, 
qgraphicsitemanimation.h, qgraphicsscene.h, qgraphicssceneevent.h, 
qgraphicssvgitem.h, qgraphicsview.h, qgridlayout.h, qgroupbox.h, qhash.h, 
qheaderview.h, qhostaddress.h, qhostinfo.h, qhttp.h, qicon.h, qiconengine.h, 
qiconengineplugin.h, qiconset.h, qimage.h, qimageiohandler.h, qimagereader.h, 
qimagewriter.h, qinputcontext.h, qinputcontextfactory.h, 
qinputcontextplugin.h, qinputdialog.h, qiodevice.h, qitemdelegate.h, 
qitemeditorfactory.h, qitemselectionmodel.h, qiterator.h, qkeysequence.h, 
qlabel.h, qlayout.h, qlayoutitem.h, qlcdnumber.h, 

Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Uwe Stöhr

Jürgen wrote:

 Index: src/frontends/qt4/QInclude.cpp
 ===
 --- src/frontends/qt4/QInclude.cpp (Revision 18428)
 +++ src/frontends/qt4/QInclude.cpp (Arbeitskopie)
 ...
 @@ -246,6 +248,7 @@
if (cap[0] == '{'  cap[cap.size()-1] == '}')

dialog_-captionLE-setText(toqstr(cap.substr(1,
 cap.size()-2)));
else
 +  // FIXME: make this translatable!
throw invalidParam(caption parameter is 
not quoted with
 braces);

Why does this not work?:

+ throw invalidParam(qt_(caption parameter is not quoted with braces));

The same here:

 @@ -253,6 +256,7 @@
if (lbl[0] == '{'  lbl[lbl.size()-1] == '}')

dialog_-labelLE-setText(toqstr(lbl.substr(1,
 lbl.size()-2)));
else
 +  // FIXME: make this translatable!
throw invalidParam(label parameter is not quoted 
with  braces);

regards Uwe


[patch] announce CJK language dialog support

2007-05-20 Thread Uwe Stöhr
I've seen that the support for the CJK languages in the dialogs was not announced. This change 
requires a warning as Georg stated in bug 3043.


So attached is my proposal to announce it in the NEWS and ANNOUNCE file. OK?

regards Uwe
Index: ANNOUNCE
===
--- ANNOUNCE	(revision 18430)
+++ ANNOUNCE	(working copy)
@@ -99,6 +99,10 @@
 
 The very first result of the Unicode transition is that we have finally
 merged in the externally maintained CJK-LyX branch.
+The languages Chinese, Japanese, and Korean are now supported in
+the document dialogs.
+Note that from now on, former encoding settings for these languages
+done via ERT or the document preamble will lead to LaTeX-errors!
 
 * Multiple views of the same buffer
 
Index: NEWS
===
--- NEWS	(revision 18430)
+++ NEWS	(working copy)
@@ -2,9 +2,14 @@
  
 
 Compared with the previous beta release we have fixed several bugs
-and added some improvements, namely a new inset to support code listings.
+and added some improvements:
 
-We have enabled the converter file cache by default.
+ * A new inset to support code listings.
+ * We have enabled the converter file cache by default.
+ * The languages Armenian, Chinese, Japanese, and Korean are now supported in
+   the document dialogs.
+   Note that from now on, former encoding settings for these languages
+   done via ERT or the document preamble will lead to LaTeX-errors!
 
 Internally we have renamed files to follow a consistent name pattern,
 this will allow an easier navigation of the source code thus simplifying


Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Jürgen Spitzmüller
Uwe Stöhr wrote:
 Why does this not work?:

 + throw invalidParam(qt_(caption parameter is not quoted with braces));

because invalidParam expects a std::string, qt_() is a QString. I think 
InsetListingsParams need to be rewritten to handle docstrings (that would be 
_(string)).

Jürgen


[Fwd: Re: superscript]

2007-05-20 Thread Richard Heck

Richard Heck wrote:
 Can you be more specific about the problem? What kind of keyboard are
 you using? What language encoding? etc?

 Gyorgy Pota wrote:
   
 Dear Users,

 It has already been raised that, for example, textdegree symbol did
 not work in the early Lyx 1.5 beta(s). Now I can report that for me
 there is a number of keyboard symbols, including carets, degree etc.
 that do not work. They do not appear on the screen either.  These are
 usually inserted using Altgr. I tried Lyx betas 2 and 3 for Windows.
 What should I do or is this still a bug?

 With  best wishes,

 Gyorgy Pota

 


   

I am using an IBM R50e laptop with Hungarian keyboard. The language of 
the article document is English, the Use language's default encoding 
option is on. The Use keyboard map option in the Preferences is off, 
as in the case of Lyx 1.4.4 where everything worked.

Many characters can be entered with the use of Altgr key. In the 
uppermost row of the keybard the key wave line ~ and the accent 
character ` appear with Altgrey but the others, including the carets up 
^ and down ˇ and the degree ° do not. These latters, of course, appear 
in other software as you perhaps see in this message too.

Let me draw your attention to the message lyx-1.5: textdegree 
http://www.mail-archive.com/[EMAIL PROTECTED]/msg55755.html 
Bernd Sellentin in the Lyx user's list.

Thank you very much for your help.

Gyorgy Pota

-- 

Dr. Gyorgy Pota
associate professor
Institute of Physical Chemistry
University of Debrecen
H-4010 Debrecen, P. O. Box 7,
Hungary
Tel.: (36) 52-512-90022383
Fax: (36) 52-512-915
homepage: http://dragon.unideb.hu/~wwwphch/potae.htm
private homepage: puma.unideb.hu/~potagy



-- 
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto



Re: Qt4 mac

2007-05-20 Thread Anders Ekberg

On 20 maj 2007, at 16.43, Scott Lambert wrote:

I built Qt4.2.3 from source exactly as described in INSTALL.MacOSX.  
(I even literally used /path/to/QT4 as the destination.) Here are  
some lines from the configure script. It seems to find some things  
in the Qt4 tree but not others.


checking for QT4_CORE... checking for QT4_FRONTEND... checking for  
Qt 4 library name... failed

checking for moc-qt4... no
checking for moc... /path/to/QT4//bin/moc
checking for uic-qt4... no
checking for uic... /path/to/QT4//bin/uic


OK, I think it may be a priviligies problem. Try to create an account  
directly under your user account that you call QT43. Either by open  
the Terminal and typing mkdir QT43 . Or in the Finder select your  
user home directory (If your user name is scott, it is named scott.  
You will be in that directory if you open a new Finder window.),  
create a new folder (File - New folder) and name it QT43.


Now replace /path/to/QT4 with /Users/scott/QT43
and run the compilation of QT (don't forget the make install command  
and to remove the .la-files) and of LyX again.




Bob,
I tried using:
export PKG_CONFIG_PATH=/path/to/Qt4/lib/pkgconfig/

It didn't help. In fact my Qt4 tree contains not such directory!
I have attached a full listing of my Qt4 tree.
QT4 tree.txt

It shouldn't be needed as Bennet pointed out.


Also the link (http://www.trolltech.com/download/qt/mac.html)
 given in INSTALL.MacOSX is not valid.

Right, it should be:
http://trolltech.com/developer/downloads/qt/mac
Bennett, can you update this?

/Anders



Re: Qt4 mac

2007-05-20 Thread Anders Ekberg


On 20 maj 2007, at 17.29, Anders Ekberg wrote:


On 20 maj 2007, at 16.43, Scott Lambert wrote:

I built Qt4.2.3 from source exactly as described in  
INSTALL.MacOSX. (I even literally used /path/to/QT4 as the  
destination.) Here are some lines from the configure script. It  
seems to find some things in the Qt4 tree but not others.


checking for QT4_CORE... checking for QT4_FRONTEND... checking for  
Qt 4 library name... failed

checking for moc-qt4... no
checking for moc... /path/to/QT4//bin/moc
checking for uic-qt4... no
checking for uic... /path/to/QT4//bin/uic


OK, I think it may be a priviligies problem. Try to create an account


that should of course be * a directory * (sorry Sunday tiredness...)

directly under your user account that you call QT43. Either by open  
the Terminal and typing mkdir QT43 . Or in the Finder select your  
user home directory (If your user name is scott, it is named scott.  
You will be in that directory if you open a new Finder window.),  
create a new folder (File - New folder) and name it QT43.


Now replace /path/to/QT4 with /Users/scott/QT43


and that is of course presuming your user name is scott

and run the compilation of QT (don't forget the make install  
command and to remove the .la-files) and of LyX again.




Bob,
I tried using:
export PKG_CONFIG_PATH=/path/to/Qt4/lib/pkgconfig/

It didn't help. In fact my Qt4 tree contains not such directory!
I have attached a full listing of my Qt4 tree.
QT4 tree.txt

It shouldn't be needed as Bennet pointed out.


Also the link (http://www.trolltech.com/download/qt/mac.html)
 given in INSTALL.MacOSX is not valid.

Right, it should be:
http://trolltech.com/developer/downloads/qt/mac
Bennett, can you update this?

/Anders





Re: [Bug 3561] Comments

2007-05-20 Thread Richard Heck
Jürgen Spitzmüller wrote:
 Richard Heck wrote:
   
 I've been studying this bug a bit and think I know where the problem is,
 more or less. The attached file is as minimal as I can get it. The
 change of font is crucial. Without it, there is no crash.
 
 I think the real problem is really just the view-source widget requesting an 
 invalid encoding change. This whole bug only occurs if that widget is open, 
 with some debug output, you can see that the encodings involved are bogus.
   
Yes, you're right. I'm trying to figure out then why the encoding change
is invalid then. This is happening on the update after
ControlDocument::dispatchParams() has called setLanguage() and before
the other stuff has happened. So there's something that hasnt' happened
then that needs to happen. What?

One thought, though this would be a pretty extensive change in some
ways. I wonder if kernel().dispatch() couldn't take an optional boolean
update that, if false, would prevent the updating from being done. It
seems as if there are various times when we get sequences of updates
right in a row that are pretty pointless. For example, in this very
function, there might be several calls to kernel().dispatch(), and every
one of them is going to trigger a complete update cycle. That's a waste
of time. Probably a lot of time in some cases.

Richard

-- 
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto



Re: [Bug 3561] Comments

2007-05-20 Thread Richard Heck
Jürgen Spitzmüller wrote:
 Richard Heck wrote:
   
 I've been studying this bug a bit and think I know where the problem is,
 more or less. The attached file is as minimal as I can get it. The
 change of font is crucial. Without it, there is no crash.
 
 I think the real problem is really just the view-source widget requesting an 
 invalid encoding change. This whole bug only occurs if that widget is open, 
 with some debug output, you can see that the encodings involved are bogus.
   
Yes, you're right. I'm trying to figure out then why the encoding change
is invalid then. This is happening on the update after
ControlDocument::dispatchParams() has called setLanguage() and before
the other stuff has happened. So there's something that hasnt' happened
then that needs to happen. What?

It seems that the problem is that, when the update happens and view
source is open oldEnc is Encoding::inputenc, whereas it is Encoding::CJK
when you do a normal LaTeX export later. This is ultimately coming from
Buffer::params(). So it looks like the answer to my question is that the
buffer params haven't been updated at this point, and that is what is
causing the invalid output.

Richard

-- 
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto


Re: Scrolling lag in 1.5svn again, more details.

2007-05-20 Thread Peter Kümmel
Abdelrazak Younes wrote:
 Is this your only comment?
 
 Yes. Sorry, don't have the time to do much more. I thought I'd share my
 opinion ;-)

Sorry, too - for my harsh reply.

 

 Anyway I don't think there is a simpler solution, at least I will
 not look for it, this bug has cost me already too much time.

OK, I've found a better solution ;)
I had to test if it was worth to upgrade to 1GB ram.

 
 I can understand that. I was thinking of collecting the scroll events
 and cancelling them if a scroll operation is still on-going but maybe
 that's what your patch do. I only briefly looked at it and it _seems_
 very complicated.

Yes this is what it does. An it _is_ complicated. ;)

But I've found a more Qt like and elegant solution.
See attached patch, which should be much more readably.

I've introduced two events which are only posted once
to the event queue until the event is not processed.

This also improves(?) the scrolling under Windows,
see the comment in generateLyxScrollEvent.

 

 Dimitri from Trolltech wrote on a similar problem:

 You'll need to maintain flags, QTimers waiting N milliseconds and other
 data to achive that. There's no equivalent information maintained by Qt.

 http://lists.trolltech.com/qt-interest/2006-02/thread00129-0.html


 Hope this has convinced you. ;)
 
 I trust you.

But the patch needs still more testing.

Peter
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp   (revision 18430)
+++ src/frontends/qt4/GuiWorkArea.cpp   (working copy)
@@ -190,8 +190,11 @@
 
// Initialize the vertical Scroll Bar
QObject::connect(verticalScrollBar(), SIGNAL(actionTriggered(int)),
-   this, SLOT(adjustViewWithScrollBar(int)));
+   this, SLOT(generateLyxScrollEvent()));
+   QObject::connect(verticalScrollBar(), SIGNAL(sliderReleased()),
+   this, SLOT(lyxScrollEvent()));
 
+
// disable context menu for the scrollbar
verticalScrollBar()-setContextMenuPolicy(Qt::NoContextMenu);
 
@@ -211,6 +214,53 @@
 }
 
 
+
+class LyxScrollEvent : public QEvent
+{
+public:
+   LyxScrollEvent() : QEvent(QEvent::Type(id)) 
+   {}
+   static int id;
+   static bool locked;
+};
+
+// Qt doc: user event type between 1000 and 65535
+int LyxScrollEvent::id = 31415;
+bool LyxScrollEvent::locked = false;
+
+
+class LyxKeyEvent : public QKeyEvent
+{
+public:
+   LyxKeyEvent(QKeyEvent * e) : 
+ QKeyEvent(QEvent::Type(id), e-key(), 
+   e-modifiers(), e-text(), e-isAutoRepeat(), 
e-count())
+   {}
+   static int id;
+   static bool locked;
+};
+
+int LyxKeyEvent::id = 27182;
+bool LyxKeyEvent::locked = false;
+
+
+
+bool GuiWorkArea::event(QEvent * event)
+{
+   if (event-type() == LyxKeyEvent::id) {
+   lyxKeyEvent(dynamic_castLyxKeyEvent*(event));
+   LyxKeyEvent::locked = false;
+   return true;
+   } else if (event-type() == LyxScrollEvent::id) {
+   lyxScrollEvent();
+   LyxScrollEvent::locked = false;
+   return true;
+   } else {
+   return QAbstractScrollArea::event(event);
+   }
+}
+
+
 void GuiWorkArea::setScrollbarParams(int h, int scroll_pos, int 
scroll_line_step)
 {
if (verticalScrollBarPolicy() != Qt::ScrollBarAlwaysOn)
@@ -231,12 +281,30 @@
 }
 
 
-void GuiWorkArea::adjustViewWithScrollBar(int)
+void GuiWorkArea::lyxScrollEvent()
 {
scrollBufferView(verticalScrollBar()-sliderPosition());
 }
 
 
+void GuiWorkArea::generateLyxScrollEvent()
+{
+   // This gives the old slow (the scroll bar couldn't follow the mouse)
+   // scrolling on Windows. Is it really better? 
+   // Windows/Qt is here not as fast as X11
+   //lyxScrollEvent();return;
+
+   // multiple scroll events are merged into one
+   if (!LyxScrollEvent::locked) {
+   LyxScrollEvent::locked = true;
+   LyxScrollEvent* scrollEvent = new LyxScrollEvent;
+   QCoreApplication::postEvent(this, scrollEvent);
+   LYXERR(Debug::GUI)  scrolling: one event posted  endl;
+   } else {
+   LYXERR(Debug::GUI)  scrolling: waiting for processing last 
scrolling event  endl;
+   }
+}
+
 void GuiWorkArea::dragEnterEvent(QDragEnterEvent * event)
 {
if (event-mimeData()-hasUrls())
@@ -389,13 +457,14 @@
int const lines = qApp-wheelScrollLines() * e-delta() / 120;
verticalScrollBar()-setValue(verticalScrollBar()-value() -
lines *  verticalScrollBar()-singleStep());
-   adjustViewWithScrollBar();
+   
+   generateLyxScrollEvent();
 }
 
 
 void GuiWorkArea::generateSyntheticMouseEvent()
 {
-// Set things off to generate the _next_ 'pseudo' event.
+   // Set things off to generate the _next_ 'pseudo' event.
if (synthetic_mouse_event_.restart_timeout)
 

Re: Scrolling lag in 1.5svn again, more details.

2007-05-20 Thread Peter Kümmel
Dov Feldstern wrote:
 Peter Kümmel wrote:

 On slow/loaded systems the last patch floods the
 event queue with timer events instead of key/scroll events.
 I hope attached patch will now really fix the problem.

 Peter

 
 This works for me (timer_scroll_4.patch) --- at least for what I'm
 testing, namely, cursor movement by holding down keys.
 

Thanks Dov, good to hear, then I assume that the
next patch will also work: event_1.patch.

Peter


Re: Qt4 mac

2007-05-20 Thread Andreas Neustifter

On 20.05.2007, at 17:45, Anders Ekberg wrote:



On 20 maj 2007, at 17.29, Anders Ekberg wrote:


On 20 maj 2007, at 16.43, Scott Lambert wrote:

I built Qt4.2.3 from source exactly as described in  
INSTALL.MacOSX. (I even literally used /path/to/QT4 as the  
destination.) Here are some lines from the configure script. It  
seems to find some things in the Qt4 tree but not others.


checking for QT4_CORE... checking for QT4_FRONTEND... checking  
for Qt 4 library name... failed

checking for moc-qt4... no
checking for moc... /path/to/QT4//bin/moc
checking for uic-qt4... no
checking for uic... /path/to/QT4//bin/uic


I found that (as mentioned in a mail called slow when editing  
paragraphs with math on 18.05.2007 on this list) that the configure  
step strangely enough doesn't find the libiconv when trying to  
configure Qt and thus the problems (if its the same problem I had.)  
config.log says:

configure:24304: checking for QT4_CORE
configure:24381: checking for QT4_FRONTEND
configure:24483: checking for Qt 4 library name
configure:24532: g++ -o conftest -g -Os -I/Users/astifter/qt-4.2.3// 
include -I/Users/astifter/qt-4.2.3//include/Qt -I/Users/astifter/ 
qt-4.2.3//include/QtCore -I/Users/astifter/qt-4.2.3//include/QtGui -L/ 
Users/astifter/qt-4.2.3//lib -Wextra -Wall   -framework Carbon - 
framework OpenGL -framework AGL -framework QuickTime -lz -framework  
Cocoa conftest.cpp -lc -lm  -lQtCore 5

/usr/bin/ld: Undefined symbols:
_libiconv
_libiconv_close
_libiconv_open
collect2: ld returned 1 exit status
configure:24538: $? = 1

I added -liconv to the LDPATH and it worked prefectly well, so  
command reads then:
$ export LDFLAGS=-framework Carbon -framework OpenGL -framework AGL  
-framework QuickTime -lz -framework Cocoa -liconv


@Scott: Hope that helps.
@all: any idea why that happens? I'm quite not familiar with automake  
and couldn't figure it out myself.


Greetings Astifter

PS: How are the correct citing and posting rules in this list?


Re: crash tex2lyx

2007-05-20 Thread Andre Poenitz
On Sat, May 19, 2007 at 11:16:42PM +0200, Stefan Schimanski wrote:
 There is something really strange going on. I am trying to debug the  
 problem for half an hour now as it also shows up on my machine. The  
 layoutlist_ containter looks fine before the cit = begin() call in  
 TextClass::read. But when I step into the begin() function suddenly  
 the start value of the layoutlist_ container turns into 0x0. More  
 precisely in TextClass::read tells me that layoutlist_::P_impl is at  
 0xb0c8. In the begin() call though it is shown at 0xb0e8  
 where the 0x0 is. This either smells like a compiler error or some  
 memory corruption.

Clearly a compiler error. The earth is flat, and pigs can fly...

Andre'


Re: BUG 3622: Weird date external material.

2007-05-20 Thread Andre Poenitz
On Sat, May 19, 2007 at 11:46:28PM -0500, Bo Peng wrote:
 I traced this bug a little bit and find some weird things going on.
 
 I am surprised that ifstream(.) returns OK, as shown in my test program.
 
 #include fstream
 #include iostream
 
 int main()
 {
std::ifstream ifs(.);

There is nothing wrong with opening a directory forreading in general.

Andre'


Re: crash tex2lyx

2007-05-20 Thread Stefan Schimanski

Which build system do you use? automake/conf? cmake?

Stefan

Am 16.05.2007 um 13:42 schrieb Leuven, E.:


with attached doc.

backtrace:

tex2lyx.exe!boost::assertion_failed(const char *  
expr=0x005b6c44, const char * function=0x005b6c50, const char *  
file=0x005b6cc0, long line=315)  Line 39 + 0x8 bytes   C++
tex2lyx.exe!boost::shared_ptrlyx::Layout::operator-()   
Line 315 + 0x23 bytes C++
   tex2lyx.exe!lyx::TextClass::read(const  
lyx::support::FileName  filename={...}, bool merge=false)  Line  
455 + 0x12 bytesC++
tex2lyx.exe!lyx::parse_preamble(lyx::Parser  p={...},  
std::basic_ostreamchar,std::char_traitschar   os={...}, const  
std::basic_stringchar,std::char_traitschar,std::allocatorchar  
  forceclass=)  Line 502   C++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx 
(std::basic_istreamchar,std::char_traitschar   is={...},  
std::basic_ostreamchar,std::char_traitschar   os={...})  Line  
428 + 0x3e bytesC++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx(const  
lyx::support::FileName  infilename={...},  
std::basic_ostreamchar,std::char_traitschar   os={...})  Line  
462 + 0x10 bytesC++
tex2lyx.exe!lyx::tex2lyx(const  
std::basic_stringchar,std::char_traitschar,std::allocatorchar  
  infilename=C:/_projects/profs3/internal.tex, const  
lyx::support::FileName  outfilename={...})  Line 494 + 0x38  
bytes   C++
tex2lyx.exe!main(int argc=2, char * * argv=0x003d52f8)   
Line 554 + 0x35 bytes   C++

tex2lyx.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes  C
tex2lyx.exe!mainCRTStartup()  Line 403  C
kernel32.dll!7c816fd7()

internal.tex




PGP.sig
Description: Signierter Teil der Nachricht


Re: Scrolling lag in 1.5svn again, more details.

2007-05-20 Thread Dov Feldstern

Peter Kümmel wrote:

Dov Feldstern wrote:

Peter Kümmel wrote:

On slow/loaded systems the last patch floods the
event queue with timer events instead of key/scroll events.
I hope attached patch will now really fix the problem.

Peter


This works for me (timer_scroll_4.patch) --- at least for what I'm
testing, namely, cursor movement by holding down keys.



Thanks Dov, good to hear, then I assume that the
next patch will also work: event_1.patch.

Peter

Yes, it does. :) It seems perhaps to respond even better than the 
previous patch, though that may only be my imagination ;) . I'll keep 
this in for now, I'll let you know if I run into any trouble.


Dov



Re: Qt4 binary

2007-05-20 Thread Andre Poenitz
On Sun, May 20, 2007 at 08:25:56PM +0200, Andreas Neustifter wrote:
 But since it's not quite uninteresting for new users to install the  
 binary Qt, here the list of files which are installed.

Next time please zip that. 170k is a bit too much to send to the list.

Andre'


Re: crash tex2lyx

2007-05-20 Thread Stefan Schimanski
The following patch fixes this problem for the cmake build system. I  
have not checked the other build systems, maybe similar fixes are  
needed there.


The problem basically is that in the inline functions a different  
Font class was used than in the .cpp files. This was leading to these  
very strange errors.


Stefan

@Peter: ok to commit? Any comment?




tex2lyxcmake.patch
Description: Binary data



with attached doc.

backtrace:

tex2lyx.exe!boost::assertion_failed(const char *  
expr=0x005b6c44, const char * function=0x005b6c50, const char *  
file=0x005b6cc0, long line=315)  Line 39 + 0x8 bytes   C++
tex2lyx.exe!boost::shared_ptrlyx::Layout::operator-()   
Line 315 + 0x23 bytes C++
   tex2lyx.exe!lyx::TextClass::read(const  
lyx::support::FileName  filename={...}, bool merge=false)  Line  
455 + 0x12 bytesC++
tex2lyx.exe!lyx::parse_preamble(lyx::Parser  p={...},  
std::basic_ostreamchar,std::char_traitschar   os={...}, const  
std::basic_stringchar,std::char_traitschar,std::allocatorchar  
  forceclass=)  Line 502   C++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx 
(std::basic_istreamchar,std::char_traitschar   is={...},  
std::basic_ostreamchar,std::char_traitschar   os={...})  Line  
428 + 0x3e bytesC++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx(const  
lyx::support::FileName  infilename={...},  
std::basic_ostreamchar,std::char_traitschar   os={...})  Line  
462 + 0x10 bytesC++
tex2lyx.exe!lyx::tex2lyx(const  
std::basic_stringchar,std::char_traitschar,std::allocatorchar  
  infilename=C:/_projects/profs3/internal.tex, const  
lyx::support::FileName  outfilename={...})  Line 494 + 0x38  
bytes   C++
tex2lyx.exe!main(int argc=2, char * * argv=0x003d52f8)   
Line 554 + 0x35 bytes   C++

tex2lyx.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes  C
tex2lyx.exe!mainCRTStartup()  Line 403  C
kernel32.dll!7c816fd7()

internal.tex




PGP.sig
Description: Signierter Teil der Nachricht


Re: Qt4 mac

2007-05-20 Thread Andre Poenitz
On Sun, May 20, 2007 at 08:21:56PM +0200, Andreas Neustifter wrote:
 PS: How are the correct citing and posting rules in this list?

Cut down any cited material to the bit you are responding to and write
your comments below.

Do not send binaries unless it's compressed plain text.

Avoid sending huge messages. There used to be a limit around 50 or
100k a while ago but I am not sure this is enforced by the list
software. Exemptions are officially allowed for really big but
useful patches.

Adjust your tone to the average you found on the list. This rule is
officially suspended on Friday.

Ignore rude comments on Fridays.

Send lots of good patches.

Andre'


Re: crash tex2lyx

2007-05-20 Thread Edwin Leuven

great detective work!!

this fixes the crash on my side, so this gets an ok from me.


Stefan Schimanski wrote:
The following patch fixes this problem for the cmake build system. I 
have not checked the other build systems, maybe similar fixes are needed 
there.


The problem basically is that in the inline functions a different Font 
class was used than in the .cpp files. This was leading to these very 
strange errors.


Stefan

@Peter: ok to commit? Any comment?




with attached doc.

backtrace:

tex2lyx.exe!boost::assertion_failed(const char * 
expr=0x005b6c44, const char * function=0x005b6c50, const char * 
file=0x005b6cc0, long line=315)  Line 39 + 0x8 bytes   C++
tex2lyx.exe!boost::shared_ptrlyx::Layout::operator-()  Line 
315 + 0x23 bytes C++
   tex2lyx.exe!lyx::TextClass::read(const lyx::support::FileName 
 filename={...}, bool merge=false)  Line 455 + 0x12 bytesC++
tex2lyx.exe!lyx::parse_preamble(lyx::Parser  p={...}, 
std::basic_ostreamchar,std::char_traitschar   os={...}, const 
std::basic_stringchar,std::char_traitschar,std::allocatorchar   
forceclass=)  Line 502   C++
tex2lyx.exe!lyx::`anonymous 
namespace'::tex2lyx(std::basic_istreamchar,std::char_traitschar   
is={...}, std::basic_ostreamchar,std::char_traitschar   
os={...})  Line 428 + 0x3e bytesC++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx(const 
lyx::support::FileName  infilename={...}, 
std::basic_ostreamchar,std::char_traitschar   os={...})  Line 462 
+ 0x10 bytesC++
tex2lyx.exe!lyx::tex2lyx(const 
std::basic_stringchar,std::char_traitschar,std::allocatorchar   
infilename=C:/_projects/profs3/internal.tex, const 
lyx::support::FileName  outfilename={...})  Line 494 + 0x38 bytes   C++
tex2lyx.exe!main(int argc=2, char * * argv=0x003d52f8)  Line 
554 + 0x35 bytes   C++

tex2lyx.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes  C
tex2lyx.exe!mainCRTStartup()  Line 403  C
kernel32.dll!7c816fd7()

internal.tex






Re: BUG 3622: Weird date external material.

2007-05-20 Thread Andre Poenitz
On Sun, May 20, 2007 at 08:46:35AM -0500, Bo Peng wrote:
 I propose the attached patch. Can I apply?
 
 So no one knows this lyxsum stuff? My patch will do no harm on
 platforms when my testcase return error for ifstream(/a/path) so if
 should be safe to commit.
 
 OK?

I already deleted the proposed pathc, but there were style issues.
'if' one one line or such IIRC.

Andre'


Re: Qt4 mac

2007-05-20 Thread Bennett Helm

On May 20, 2007, at 11:29 AM, Anders Ekberg wrote:


Also the link (http://www.trolltech.com/download/qt/mac.html)
 given in INSTALL.MacOSX is not valid.

Right, it should be:
http://trolltech.com/developer/downloads/qt/mac
Bennett, can you update this?


Actually, it looks like

http://trolltech.com/developer/downloads/qt/

is better. That's what I've done (though I'll wait a while to post  
the change to see what else comes down the pike).


Bennett


Re: BUG 3622: Weird date external material.

2007-05-20 Thread Bo Peng

I already deleted the proposed pathc, but there were style issues.
'if' one one line or such IIRC.


Are you talking about my patch?

Bo


No math dialog

2007-05-20 Thread John Levon

I see the Maths dialog has been removed. Am I right in thinking that the
only way to create things such as sum environments etc. without knowing
LaTeX is to turn on the math panel toolbar and use that?

This really needs to be available in the menus too for discoverability:
it's a basic principle of toolbars that they are a quicker form of
what's available in the menus, not a replacement, especially when
they're not available by default.

I noticed that right clicking on toolbar space no longer brings up the
menu of available toolbars. Is that a Qt4 thing, or intentional?

I see the toolbar on the right is still present :/

Current SVN is looking pretty nice!

cheers
john


Re: Scrolling lag in 1.5svn again, more details.

2007-05-20 Thread Martin Vermeer
On Sun, May 20, 2007 at 07:08:59PM +0200, Peter Kümmel wrote:
 Abdelrazak Younes wrote:

...
 
 OK, I've found a better solution ;)
 I had to test if it was worth to upgrade to 1GB ram.
 
  
  I can understand that. I was thinking of collecting the scroll events
  and cancelling them if a scroll operation is still on-going but maybe
  that's what your patch do. I only briefly looked at it and it _seems_
  very complicated.
 
 Yes this is what it does. An it _is_ complicated. ;)
 
 But I've found a more Qt like and elegant solution.
 See attached patch, which should be much more readably.
 
 I've introduced two events which are only posted once
 to the event queue until the event is not processed.
 
 This also improves(?) the scrolling under Windows,
 see the comment in generateLyxScrollEvent.

Yes, this looks _much_ better. Just as complicated, but very well designed ;-/

- Martin
 


Re: Qt4 binary

2007-05-20 Thread Andreas Neustifter


On 20.05.2007, at 22:52, Andre Poenitz wrote:


Next time please zip that. 170k is a bit too much to send to the list.

Sorry, I tend to get sloppy with this DSL lines.

A nice week to you all, Astifter


Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Jürgen Spitzmüller
Bo Peng wrote:
> > OK for this one?
>
> OK.

I did some further cleanup and integrated Bo's patch for bug 3654.
See attached.

Jürgen
Index: src/frontends/qt4/QDocument.cpp
===
--- src/frontends/qt4/QDocument.cpp	(Revision 18428)
+++ src/frontends/qt4/QDocument.cpp	(Arbeitskopie)
@@ -214,7 +214,8 @@
 		this, SLOT(change_adaptor()));
 	connect(textLayoutModule->listingsED, SIGNAL(textChanged()),
 		this, SLOT(validate_listings_params()));
-	textLayoutModule->listingsTB->setPlainText("Input listings parameters below. Enter ? for a list of parameters.");
+	textLayoutModule->listingsTB->setPlainText(
+		qt_("Input listings parameters on the right. Enter ? for a list of parameters."));
 	textLayoutModule->lspacingLE->setValidator(new QDoubleValidator(
 		textLayoutModule->lspacingLE));
 	textLayoutModule->skipLE->setValidator(unsignedLengthValidator(
@@ -616,7 +617,8 @@
 		if (!isOK) {
 			isOK = true;
 			// listingsTB->setTextColor("black");
-			textLayoutModule->listingsTB->setPlainText("Input listings parameters below. Enter ? for a list of parameters.");
+			textLayoutModule->listingsTB->setPlainText(
+qt_("Input listings parameters on the right. Enter ? for a list of parameters."));
 			okPB->setEnabled(true);
 		}
 	} catch (invalidParam & e) {
Index: src/frontends/qt4/QInclude.cpp
===
--- src/frontends/qt4/QInclude.cpp	(Revision 18428)
+++ src/frontends/qt4/QInclude.cpp	(Arbeitskopie)
@@ -91,7 +91,8 @@
 		InsetListingsParams par(fromqstr(listingsED->toPlainText()));
 		if (!isOK) {
 			isOK = true;
-			listingsTB->setPlainText("Input listings parameters on the right. Enter ? for a list of parameters.");
+			listingsTB->setPlainText(
+qt_("Input listings parameters on the right. Enter ? for a list of parameters."));
 			okPB->setEnabled(true);
 		}
 	} catch (invalidParam & e) {
@@ -206,7 +207,8 @@
 	dialog_->captionLE->clear();
 	dialog_->labelLE->clear();
 	dialog_->listingsED->clear();
-	dialog_->listingsTB->setPlainText("Input listings parameters on the right. Enter ? for a list of parameters.");
+	dialog_->listingsTB->setPlainText(
+		qt_("Input listings parameters on the right. Enter ? for a list of parameters."));
 
 	string cmdname = controller().params().getCmdName();
 	if (cmdname != "include" &&
@@ -246,6 +248,7 @@
 if (cap[0] == '{' && cap[cap.size()-1] == '}')
 	dialog_->captionLE->setText(toqstr(cap.substr(1, cap.size()-2)));
 else
+	// FIXME: make this translatable!
 	throw invalidParam("caption parameter is not quoted with braces");
 *it = "";
 			} else if (prefixIs(*it, "label=")) {
@@ -253,6 +256,7 @@
 if (lbl[0] == '{' && lbl[lbl.size()-1] == '}')
 	dialog_->labelLE->setText(toqstr(lbl.substr(1, lbl.size()-2)));
 else
+	// FIXME: make this translatable!
 	throw invalidParam("label parameter is not quoted with braces");
 *it = "";
 			}
Index: src/frontends/qt4/QListings.h
===
--- src/frontends/qt4/QListings.h	(Revision 18428)
+++ src/frontends/qt4/QListings.h	(Arbeitskopie)
@@ -38,6 +38,8 @@
 	void on_floatCB_stateChanged(int state);
 	/// turn off float when inline is clicked
 	void on_inlineCB_stateChanged(int state);
+	/// turn off numbering options when none is selected
+	void on_numberSideCO_currentIndexChanged(int);
 protected:
 	virtual void closeEvent(QCloseEvent * e);
 private:
Index: src/frontends/qt4/ui/ListingsUi.ui
===
--- src/frontends/qt4/ui/ListingsUi.ui	(Revision 18428)
+++ src/frontends/qt4/ui/ListingsUi.ui	(Arbeitskopie)
@@ -258,7 +258,7 @@
  Choose the Font Size
 
 
- true
+ false
 
 
  true
@@ -269,7 +269,23 @@

   
   
-   
+   
+
+ 
+  None
+ 
+
+
+ 
+  Left
+ 
+
+
+ 
+  Right
+ 
+
+   
   
  
 
@@ -424,7 +440,7 @@
Choose the Font Style
   
   
-   true
+   false
   
   
true
@@ -461,7 +477,7 @@
Choose the Font Size
   
   
-   true
+   false
   
   
true
Index: src/frontends/qt4/QListings.cpp
===
--- src/frontends/qt4/QListings.cpp	(Revision 18428)
+++ src/frontends/qt4/QListings.cpp	(Arbeitskopie)
@@ -30,6 +30,7 @@
 

Re: [PATCH-again] Bugs 643, 3047, and 3090

2007-05-20 Thread Georg Baum
Am Samstag, 19. Mai 2007 18:45 schrieb Richard Heck:
> Georg Baum wrote:
> > A flag for the name of that directory does already exist: resultdir. 
Please 
> > use that instead of /path/file.html.conversion/.
> >   
> I could be wrong, but this seems to do something else.
> /path/file.html.conversion/ is where the files end up if you're
> exporting, and the copying happens in Exporter.cpp. The resultdir flag
> operates in Converter.cpp and seems (though it's hard to tell, since
> it's not actually used in any of our converters) to inform us where the
> external converter will have put its output, and then things get moved
> in Converter.cpp, and then they get moved again in Exporter.cpp, if
> we're exporting. I also don't think we want to require resultdir to be
> set whenever usetempdir is. It may well be though (I haven't tried) that
> setting resultdir with usetempdir is possible and works as one would 
hope.

Yes, I mixed that up. So resultdir should be set if and only if the 
converter creates a directory by itself. Please make sure that this does 
work in combination with usetempdir, or make these two flags mutually 
exclusive (since usetempdir is not really needed if the converter creates 
a directory itself one could ignore usetempdir if resultdir is set).

> >>> As a result, the originaldir flag does not need to be used by any of 
our
> >>> converters, and it may be redundant, though there's no harm leaving 
it,
> >>> so far as I can see.
> >>>   
> > IMHO it should be removed. 
> Have done. When I looked more closely, it caused massive problems: The
> existing code copies all HTML files found in the original directory to
> the temporary directory, whether they were created by the converter or
> not! It's amazing there's no bug report for that.

There have been several bug reports about the originaldir flag, not only in 
bugzilla but also on the users list. It is sort of known that it does not 
really work, but until now nobody was interested to fix it.

> Here's an idea: Instead of Converter::convert() returning a boolean,
> have it return a the location of the converted file as a FileName. It
> can return an empty one (checkable with FileName::empty()) on error.
> I'll still need the used_temp_dir boolean as a flag, though, ...
> > Then there is some error checking missing: If the caller can't deal 
with a 
> > converted directory (e.g. for preview) then it should check that the 
> > result is indeed a file and act appropriately if that is not the case.
> >   
> as I do NOT want to return a directory.

I missed that, I thought you were returning a directory. Since you return a 
file I believe that no check is needed indeed.

> The HTML converter, for example, 
> dumps about a billion files but there is going to be one that the viewer
> wants, and it's that FileName I want to return, since there's no general
> way in which to recover it. The temporary directory, on the other hand,
> can be recovered as the path portion of the file name. Then again, I
> suppose I could return a std::pair or a
> std::pair, with the latter being the temporary
> directory if one was created, rather than have a bool & as an argument.
> Advice welcome. My intuitions aren't always great here. (I tend to think
> Perl. Just make it work.)

If you do that I think the  would be better. But I also 
think that the simple bool as return value is expressive. What confused me 
was the fact that there were two signatures. If there is only one, and the 
name of the converted file is always set by the converter, then I think it 
is clear.

> > BTW there is another problem in this area that I solved in my 
playground 
> > branch: Some converters don't accept a commandline argument to set the 
> > resulting file name, but determine it using their own rules. They only 
> > work if these rules match the naming given by LyX, but will fail if a 
user 
> > changes e.g. the extension of a format. I solved this by a new 
resultfile 
> > flag.
> >   
> I think you might have committed this.

No, I only changed the semantics. Search for result_file in 
http://www.lyx.org/trac/browser/lyx-devel/branches/personal/baum/playground/src/converter.h
 
and 
http://www.lyx.org/trac/browser/lyx-devel/branches/personal/baum/playground/src/converter.C
 
to see the details.

> I see the resultfile flag in the 
> exiting code and was wondering exactly what it did.

It is documented in Converter.h.

> Again, there's no 
> converter that ships with LyX (i.e., that is configured by configure.py)
> that sets this.

Candidates for the flag with the new semantics are all converters without 
the $$o placeholder.
The old semantics is maybe needed for some HTML converters. One would have 
to check whether the guess of LyX for the main file name is correct.


Georg



[patch] some more beamer adjustments

2007-05-20 Thread Jürgen Spitzmüller
Adds optional arguments whereever this makes sense.

OK?
Jürgen
Index: lib/layouts/beamer.layout
===
--- lib/layouts/beamer.layout	(Revision 18428)
+++ lib/layouts/beamer.layout	(Arbeitskopie)
@@ -51,6 +51,7 @@
   Margin   Static
   LatexTypeItem_Environment
   LatexNameitemize
+  OptionalArgs 1
   NextNoIndent 1
   LeftMargin   MMN
   LabelSep xx
@@ -69,6 +70,7 @@
   Margin   Static
   LatexTypeItem_Environment
   LatexNameenumerate
+  OptionalArgs 2
   NextNoIndent 1
   LeftMargin   MMN
   LabelSep xx
@@ -87,6 +89,7 @@
   Margin   First_Dynamic
   LatexTypeItem_environment
   LatexNamedescription
+  OptionalArgs 2
   NextNoIndent 1
   LeftMargin   MM
   LabelSep xxx
@@ -112,6 +115,7 @@
   Margin   Dynamic
   LatexTypeCommand
   LatexNamepart
+  OptionalArgs 1
   NeedProtect  1
   NextNoIndent 1
   Labelsep xxx
@@ -224,6 +228,7 @@
   KeepEmpty1
   LatexTypeCommand
   LatexNamelyxframeend{}\lyxframe
+  OptionalArgs 1
   Margin   First_Dynamic
   NextNoIndent 1
   ParSkip  0
@@ -303,6 +308,7 @@
   KeepEmpty 0
   LatexType Command
   LatexName lyxframeend{}\lyxagainframe
+  OptionalArgs  2
   MarginFirst_Dynamic
   NextNoIndent  1
   ParSkip   0
@@ -509,6 +515,7 @@
   LatexType Command
   LatexName pause
   MarginFirst_Dynamic
+  OptionalArgs  1
   NextNoIndent  1
   ParSkip   0
   TopSep0


DIA diagram file with embedded (linked?) bitmap fails to convert

2007-05-20 Thread John Pye
Hi all

I have set up a file type and converter for DIA diagram files in LyX.

The first problem was that if the DIA file is compressed (settings in
the DIA File..Save As window) then LyX recognises it as a 'gzip' type
file, even though it has .dia file extension and is a value DIA file.

The next problem is that my DIA file has an embedded bitmap image in it.
When I open the file in DIA, it looks great. When I do the file
conversion on the commandline, it works great. But the preview in LyX
fails: the embedded bitmap shows up with DIA's 'broken image' icon in
place of the file.

I am guessing that the LyX conversion script is moving my file to a
temporary location in order to do the file conversion, and this is
causing it to break.

Surely DIA files are standard fare for regular LyX users, and should be
supported directly somehow, not with user 'custom settings' bizzo?

Cheers
JP




Re:[patch] some more beamer adjustments

2007-05-20 Thread Uwe Stöhr

> Adds optional arguments whereever this makes sense.
>
> OK?

Yes.

regarsd Uwe


Re: [Cvslog] r18419 - in /lyx-devel/trunk/src: frontends/qt4/QLPainter...

2007-05-20 Thread Jürgen Spitzmüller
Stefan Schimanski wrote:
> Will commit if nobody complains.

The current policy is not "commit if nobody complains", but "commit if you got 
two OK's or the OK from José".

Please stick to that.

Jürgen


Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Uwe Stöhr

> I did some further cleanup and integrated Bo's patch for bug 3654.
> See attached.

I tested it and Bo's patch for 3654 works fine. Looking into your code I find 
all reasonable.

So OK from me to commit.

regards UWe


Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Jürgen Spitzmüller
Uwe Stöhr wrote:
> I tested it and Bo's patch for 3654 works fine. Looking into your code I
> find all reasonable.
>
> So OK from me to commit.

Bo, I'll commit if I get your OK.

Jürgen


Re: [Cvslog] r18419 - in /lyx-devel/trunk/src: frontends/qt4/QLPainter...

2007-05-20 Thread Stefan Schimanski
Sorry, got a ok from Richard privately and Andre originally proposed  
exactly the same code just with a std::vector. Counted that as ok.


Stefan


Stefan Schimanski wrote:

Will commit if nobody complains.


The current policy is not "commit if nobody complains", but "commit  
if you got

two OK's or the OK from José".

Please stick to that.

Jürgen




PGP.sig
Description: Signierter Teil der Nachricht


Re: [Cvslog] r18419 - in /lyx-devel/trunk/src: frontends/qt4/QLPainter...

2007-05-20 Thread Jürgen Spitzmüller
Stefan Schimanski wrote:
> Sorry, got a ok from Richard privately and Andre originally proposed  
> exactly the same code just with a std::vector. Counted that as ok.

OK then.

Jürgen


Re: Scrolling lag in 1.5svn again, more details.

2007-05-20 Thread Abdelrazak Younes

Peter Kümmel wrote:

Abdelrazak Younes wrote:

Peter Kümmel wrote:

Next try. To see how it works change the event_delay_ms
variable in the constructor to 3000 and use -dbg 12.

This looks way too complicated Peter. There must be a simpler solution.

Abdel.



Is this your only comment?


Yes. Sorry, don't have the time to do much more. I thought I'd share my 
opinion ;-)




Anyway I don't think there is a simpler solution, at least I will
not look for it, this bug has cost me already too much time.


I can understand that. I was thinking of collecting the scroll events 
and cancelling them if a scroll operation is still on-going but maybe 
that's what your patch do. I only briefly looked at it and it _seems_ 
very complicated.




Dimitri from Trolltech wrote on a similar problem:

"You'll need to maintain flags, QTimers waiting N milliseconds and other
data to achive that. There's no equivalent information maintained by Qt."

http://lists.trolltech.com/qt-interest/2006-02/thread00129-0.html


Hope this has convinced you. ;)


I trust you.

Abdel.



Re: [patch] adding powerdot layout was: Re: [announce] LyX 1.5beta3-18-05-2007 for Windows

2007-05-20 Thread Uwe Stöhr

>> Attached is the patch. The powerdot.layout requires to check for three
>> packages in the file "chkconfig.ltx" but this is unproblematic I think.
>
> Why are rotate-textures and listings required?

rotate-textures was there to assure that the genmisc-package was used which was once required by 
powerdot. Attached a better patch.


The listingins-package is required to be able to compile the 
powerdot-example.lyx file.

> The powerdot documentation does
> not list that in the dependencies table (but it does pstricks.sty, which
> should be added).

I added this now. We forgot btw. to check for the pfg-package that is required 
by beamer.
I corrected all issues in the attached better patch.

>> There is one issue I don't know: The file is under the LPPL, is this
>> license compatible with our?

> I think in general it would be good to have an agreement with the authors to
> ship it with LyX.

I have got it now:

 Original-Nachricht 
Betreff: Re: [powerdot] new powerdot.layout file for LyX and license question
Datum: Sun, 20 May 2007 10:40:07 +0200
Von: Hendri Adriaens <[EMAIL PROTECTED]>
An: Uwe Stöhr <[EMAIL PROTECTED]>
CC: Christopher Ellison <[EMAIL PROTECTED]>
Referenzen: <[EMAIL PROTECTED]>

Hi Uwe,

> attached is an updated layout file for LyX1.5beta3.
> I want to include the layout file to our LyX SVN repository and want to 
include it to the LyX
> windows installer bundle. Am I allowed to do so? The layout file is under the 
LPPL but LyX under the
> GPL version 2, is this a problem?

I have no idea regarding the license. If I can still also bundle it in
powerdot under lppl (I have no time to change it), you can bundle it
with LyX under gpl. Please let me know what your decision will be.

> - I will also include and maintain the powerdot-example.lyx to LyX, OK?

Ok.

Best regards,
-Hendri.

---

> Best would be that we take care of distribution, so that
> there arent't two separate layouts (the one that comes with LyX and the one
> that ships with powerdot itself).

I'll assured this:

Hendri wote:

>> Yes, the layout file is for the new LyX-series LyX 1.5 that will be released 
in June and not
>> compatible for LyX 1.4.x. For LyX 1.4.x I could release an updated layout 
version together with
>> LyX 1.4.5.
>> So I think we should left the layout file for some month on powerdot and 
when you bring out the
>> next powerdot version it can go from powerdot. The people will the have some 
time to switch to
>> LyX 1.5.

> Ok, sounds fine.

thanks and regards
Uwe
Index: development/scons/scons_manifest.py
===
--- development/scons/scons_manifest.py	(revision 18430)
+++ development/scons/scons_manifest.py	(working copy)
@@ -2423,6 +2423,7 @@
 modernCV.lyx
 multicol.lyx
 noweb2lyx.lyx
+powerdot-example.lyx
 script_form.lyx
 simplecv.lyx
 splash.lyx
@@ -2646,6 +2647,7 @@
 mwbk.layout
 mwrep.layout
 paper.layout
+powerdot.layout
 report.layout
 revtex.layout
 revtex4.layout
Index: lib/chkconfig.ltx
===
--- lib/chkconfig.ltx	(revision 18430)
+++ lib/chkconfig.ltx	(working copy)
@@ -227,6 +227,7 @@
 \TestPackage{booktabs}
 \TestPackage{color} % this one should be there if graphics.sty is there.
 \TestPackage{dvipost}
+\TestPackage{enumitem} % needed by powerdot
 \TestPackage{esint}
 \TestPackage{fancybox}
 \TestPackage{fancyhdr}
@@ -240,8 +241,10 @@
 \TestPackage{natbib}
 \TestPackage{nomencl}
 \TestPackage{pdfcolmk}
+\TestPackage{pgf} % needed by beamer
 \TestPackage{prettyref}
 \TestPackage{preview}
+\TestPackage{pstricks} % needed by powerdot
 \TestPackage{rotating}
 \TestPackage{setspace}
 \TestPackage{soul}
@@ -250,7 +253,9 @@
 \TestPackage{varioref}
 \TestPackage{url}
 \TestPackage{xcolor}
+\TestPackage{xkeyval} % needed by powerdot
 
+
 % The test for the graphics package is slightly more involved...
 \newcommand\groption{dvips}
 \TestItem{graphicx}{package}{sty}
Index: lib/Makefile.am
===
--- lib/Makefile.am	(revision 18430)
+++ lib/Makefile.am	(working copy)
@@ -210,6 +210,7 @@
 	examples/modernCV.lyx \
 	examples/multicol.lyx \
 	examples/noweb2lyx.lyx \
+	examples/powerdot-example.lyx \
 	examples/script_form.lyx \
 	examples/simplecv.lyx \
 	examples/splash.lyx
@@ -956,6 +957,7 @@
 	layouts/mwbk.layout \
 	layouts/mwrep.layout \
 	layouts/paper.layout \
+	layouts/powerdot.layout \
 	layouts/report.layout \
 	layouts/revtex.layout \
 	layouts/revtex4.layout \


Re: [patch] adding powerdot layout was: Re: [announce] LyX 1.5beta3-18-05-2007 for Windows

2007-05-20 Thread Jürgen Spitzmüller
Uwe Stöhr wrote:
> I corrected all issues in the attached better patch.

Good. However, wait for Jean-Marc's comment before committing.

Jürgen


Re: crash tex2lyx

2007-05-20 Thread Stefan Schimanski

So, got it :-) The problem is this neat trick:

 * This class is just a dummy version of that in the main LyX source  
tree

 * to enable tex2lyx to use LyX's textclass classes and not have to
 * re-invent the wheel.

in the Font.h of lyx2tex. Unfortunately the sizes of the objects are  
different. But as a member of TextClass this makes a difference if  
the inline functions of TextClass use the dummy Font from tex2lyx,  
but the implementation the real one from LyX. No patch yet... have to  
use the sun outside at the river first :-)


Stefan

Am 19.05.2007 um 23:16 schrieb Stefan Schimanski:

There is something really strange going on. I am trying to debug  
the problem for half an hour now as it also shows up on my machine.  
The layoutlist_ containter looks fine before the "cit = begin()"  
call in TextClass::read. But when I step into the begin() function  
suddenly the start value of the layoutlist_ container turns into  
0x0. More precisely in TextClass::read tells me that  
layoutlist_::P_impl is at 0xb0c8. In the begin() call though it  
is shown at 0xb0e8 where the 0x0 is. This either smells like a  
compiler error or some memory corruption.


Stefan

Am 16.05.2007 um 13:42 schrieb Leuven, E.:


with attached doc.

backtrace:

tex2lyx.exe!boost::assertion_failed(const char *  
expr=0x005b6c44, const char * function=0x005b6c50, const char *  
file=0x005b6cc0, long line=315)  Line 39 + 0x8 bytes   C++
tex2lyx.exe!boost::shared_ptr::operator->()   
Line 315 + 0x23 bytes C++
>   tex2lyx.exe!lyx::TextClass::read(const  
lyx::support::FileName & filename={...}, bool merge=false)  Line  
455 + 0x12 bytesC++
tex2lyx.exe!lyx::parse_preamble(lyx::Parser & p={...},  
std::basic_ostream & os={...}, const  
std::basic_string & forceclass="")  Line 502   C++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx 
(std::basic_istream & is={...},  
std::basic_ostream & os={...})  Line  
428 + 0x3e bytesC++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx(const  
lyx::support::FileName & infilename={...},  
std::basic_ostream & os={...})  Line  
462 + 0x10 bytesC++
tex2lyx.exe!lyx::tex2lyx(const  
std::basic_string & infilename="C:/_projects/profs3/internal.tex", const  
lyx::support::FileName & outfilename={...})  Line 494 + 0x38  
bytes   C++
tex2lyx.exe!main(int argc=2, char * * argv=0x003d52f8)   
Line 554 + 0x35 bytes   C++

tex2lyx.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes  C
tex2lyx.exe!mainCRTStartup()  Line 403  C
kernel32.dll!7c816fd7()








PGP.sig
Description: Signierter Teil der Nachricht


Re: crash tex2lyx

2007-05-20 Thread Stefan Schimanski

So, got it :-) The problem is this neat trick:

 * This class is just a dummy version of that in the main LyX source  
tree

 * to enable tex2lyx to use LyX's textclass classes and not have to
 * re-invent the wheel.

in the Font.h of lyx2tex. Unfortunately the sizes of the objects are  
different. But as a member of TextClass this makes a difference if  
the inline functions of TextClass use the dummy Font from tex2lyx,  
but the implementation the real one from LyX. No patch yet... have to  
use the sun outside at the river first :-)


Stefan

P.S.: Is this a duplicate of the mail? Again I cannot see my previous  
one, although it shows up in the archive at http://marc.info/?l=lyx- 
devel=117966063615447=2 Are there any problems with the mailman?


Am 19.05.2007 um 23:16 schrieb Stefan Schimanski:

There is something really strange going on. I am trying to debug  
the problem for half an hour now as it also shows up on my machine.  
The layoutlist_ containter looks fine before the "cit = begin()"  
call in TextClass::read. But when I step into the begin() function  
suddenly the start value of the layoutlist_ container turns into  
0x0. More precisely in TextClass::read tells me that  
layoutlist_::P_impl is at 0xb0c8. In the begin() call though it  
is shown at 0xb0e8 where the 0x0 is. This either smells like a  
compiler error or some memory corruption.


Stefan

Am 16.05.2007 um 13:42 schrieb Leuven, E.:


with attached doc.

backtrace:

tex2lyx.exe!boost::assertion_failed(const char *  
expr=0x005b6c44, const char * function=0x005b6c50, const char *  
file=0x005b6cc0, long line=315)  Line 39 + 0x8 bytes   C++
tex2lyx.exe!boost::shared_ptr::operator->()   
Line 315 + 0x23 bytes C++
>   tex2lyx.exe!lyx::TextClass::read(const  
lyx::support::FileName & filename={...}, bool merge=false)  Line  
455 + 0x12 bytesC++
tex2lyx.exe!lyx::parse_preamble(lyx::Parser & p={...},  
std::basic_ostream & os={...}, const  
std::basic_string & forceclass="")  Line 502   C++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx 
(std::basic_istream & is={...},  
std::basic_ostream & os={...})  Line  
428 + 0x3e bytesC++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx(const  
lyx::support::FileName & infilename={...},  
std::basic_ostream & os={...})  Line  
462 + 0x10 bytesC++
tex2lyx.exe!lyx::tex2lyx(const  
std::basic_string & infilename="C:/_projects/profs3/internal.tex", const  
lyx::support::FileName & outfilename={...})  Line 494 + 0x38  
bytes   C++
tex2lyx.exe!main(int argc=2, char * * argv=0x003d52f8)   
Line 554 + 0x35 bytes   C++

tex2lyx.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes  C
tex2lyx.exe!mainCRTStartup()  Line 403  C
kernel32.dll!7c816fd7()








PGP.sig
Description: Signierter Teil der Nachricht


Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Bo Peng

On 5/20/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:

Uwe Stöhr wrote:
> I tested it and Bo's patch for 3654 works fine. Looking into your code I
> find all reasonable.
>
> So OK from me to commit.

Bo, I'll commit if I get your OK.


Please commit.

Bo


Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Bo Peng

> Bo, I'll commit if I get your OK.

Please commit.


Hold on. Why do you removed all initialization (clear() ...) code in
update_content? I did this because when I jump back and forth between
insets, values from previous inset need to be removed.

Cheers,
Bo


Re: [patch] some more beamer adjustments

2007-05-20 Thread Bo Peng

On 5/20/07, Uwe Stöhr <[EMAIL PROTECTED]> wrote:

 > Adds optional arguments whereever this makes sense.
 >
 > OK?


Still no fragile support?

Bo


Re: BUG 3622: Weird date external material.

2007-05-20 Thread Bo Peng

I propose the attached patch. Can I apply?


So no one knows this lyxsum stuff? My patch will do no harm on
platforms when my testcase return error for ifstream("/a/path") so if
should be safe to commit.

OK?

Bo


Re: [patch] some more beamer adjustments

2007-05-20 Thread Jürgen Spitzmüller
Bo Peng wrote:
> Still no fragile support?

No. Too difficult AFAICS.

Jürgen


Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Jürgen Spitzmüller
Bo Peng wrote:
> Hold on. Why do you removed all initialization (clear() ...) code in
> update_content? I did this because when I jump back and forth between
> insets, values from previous inset need to be removed.

I see. I moved them to the constructor, together with all the initialization 
stuff for the widgets, which really belong there (it does not make sense to 
refill each combo on every update).

I'll move the default settings back, see attached patch. 

OK?

Jürgen
Index: src/frontends/qt4/QDocument.cpp
===
--- src/frontends/qt4/QDocument.cpp	(Revision 18428)
+++ src/frontends/qt4/QDocument.cpp	(Arbeitskopie)
@@ -214,7 +214,8 @@
 		this, SLOT(change_adaptor()));
 	connect(textLayoutModule->listingsED, SIGNAL(textChanged()),
 		this, SLOT(validate_listings_params()));
-	textLayoutModule->listingsTB->setPlainText("Input listings parameters below. Enter ? for a list of parameters.");
+	textLayoutModule->listingsTB->setPlainText(
+		qt_("Input listings parameters on the right. Enter ? for a list of parameters."));
 	textLayoutModule->lspacingLE->setValidator(new QDoubleValidator(
 		textLayoutModule->lspacingLE));
 	textLayoutModule->skipLE->setValidator(unsignedLengthValidator(
@@ -616,7 +617,8 @@
 		if (!isOK) {
 			isOK = true;
 			// listingsTB->setTextColor("black");
-			textLayoutModule->listingsTB->setPlainText("Input listings parameters below. Enter ? for a list of parameters.");
+			textLayoutModule->listingsTB->setPlainText(
+qt_("Input listings parameters on the right. Enter ? for a list of parameters."));
 			okPB->setEnabled(true);
 		}
 	} catch (invalidParam & e) {
Index: src/frontends/qt4/QInclude.cpp
===
--- src/frontends/qt4/QInclude.cpp	(Revision 18428)
+++ src/frontends/qt4/QInclude.cpp	(Arbeitskopie)
@@ -91,7 +91,8 @@
 		InsetListingsParams par(fromqstr(listingsED->toPlainText()));
 		if (!isOK) {
 			isOK = true;
-			listingsTB->setPlainText("Input listings parameters on the right. Enter ? for a list of parameters.");
+			listingsTB->setPlainText(
+qt_("Input listings parameters on the right. Enter ? for a list of parameters."));
 			okPB->setEnabled(true);
 		}
 	} catch (invalidParam & e) {
@@ -206,7 +207,8 @@
 	dialog_->captionLE->clear();
 	dialog_->labelLE->clear();
 	dialog_->listingsED->clear();
-	dialog_->listingsTB->setPlainText("Input listings parameters on the right. Enter ? for a list of parameters.");
+	dialog_->listingsTB->setPlainText(
+		qt_("Input listings parameters on the right. Enter ? for a list of parameters."));
 
 	string cmdname = controller().params().getCmdName();
 	if (cmdname != "include" &&
@@ -246,6 +248,7 @@
 if (cap[0] == '{' && cap[cap.size()-1] == '}')
 	dialog_->captionLE->setText(toqstr(cap.substr(1, cap.size()-2)));
 else
+	// FIXME: make this translatable!
 	throw invalidParam("caption parameter is not quoted with braces");
 *it = "";
 			} else if (prefixIs(*it, "label=")) {
@@ -253,6 +256,7 @@
 if (lbl[0] == '{' && lbl[lbl.size()-1] == '}')
 	dialog_->labelLE->setText(toqstr(lbl.substr(1, lbl.size()-2)));
 else
+	// FIXME: make this translatable!
 	throw invalidParam("label parameter is not quoted with braces");
 *it = "";
 			}
Index: src/frontends/qt4/QListings.h
===
--- src/frontends/qt4/QListings.h	(Revision 18428)
+++ src/frontends/qt4/QListings.h	(Arbeitskopie)
@@ -38,6 +38,8 @@
 	void on_floatCB_stateChanged(int state);
 	/// turn off float when inline is clicked
 	void on_inlineCB_stateChanged(int state);
+	/// turn off numbering options when none is selected
+	void on_numberSideCO_currentIndexChanged(int);
 protected:
 	virtual void closeEvent(QCloseEvent * e);
 private:
Index: src/frontends/qt4/ui/ListingsUi.ui
===
--- src/frontends/qt4/ui/ListingsUi.ui	(Revision 18428)
+++ src/frontends/qt4/ui/ListingsUi.ui	(Arbeitskopie)
@@ -258,7 +258,7 @@
  Choose the Font Size
 
 
- true
+ false
 
 
  true
@@ -269,7 +269,23 @@

   
   
-   
+   
+
+ 
+  None
+ 
+
+
+ 
+  Left
+ 
+
+
+ 
+  Right
+ 
+
+   
   
  
 
@@ -424,7 +440,7 @@
Choose the Font Style
   
   
-   true
+   false
   
   
true
@@ -461,7 +477,7 @@
Choose the Font Size
 

Re: lyx-1.5.0beta3 build failure

2007-05-20 Thread Bennett Helm

On May 20, 2007, at 4:47 AM, Roger Mc Murtrie wrote:


Hi Bennet,
I've been trying to compile lyx-1.5.0beta3 but get the following in  
response to make:


Making all in config
make[1]: Nothing to be done for `all'.
Making all in development
Making all in MacOSX
Making all in spotlight
make[3]: *** No rule to make target `LyX-Metadata', needed by `all- 
am'.  Stop.

make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1


config command:
./configure --prefix=/Applications/"LyX.app" --with-version- 
suffix=-1.5 --without-x --with-frontend=qt4 --with-qt4-dir=/usr/ 
local/Trolltech/Qt-4.2.2 --with-included-gettext --enable- 
optimization=-Os --disable-stdlib-debug --disable-concept-checks -- 
enable-debug --enable-assertions


Setting prefix to /Applications/"LyX.app" seems to correctly  
produce  bundledir in the spotlight makefile.


I checked that spotlightbindir  is set to  /Applications/LyX.app/ 
Contents/Library/Spotlight/LyX-Metadata.mdimporter/Contents/MacOS

which does contain the file  LyX-Metadata

Have you any ideas on what might be going wrong?


This is a problem introduced in preparing the sources for beta 3;  
it's not a problem for svn. What should happen is that the LyX  
application bundle should get automatically created in the directory  
specified by the --prefix option; that won't happen because of the  
compile failure you're getting. The workaround is to take an existing  
version of LyX.app and copy it to the --prefix directory, and then do:


make -k
make -k install

(The -k tells make to continue after errors, such as the one you  
encountered. There shouldn't be any other errors.)


Bennett


Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Bo Peng

I'll move the default settings back, see attached patch.

OK?


Yes.

Thanks.

Bo


Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Jürgen Spitzmüller
Bo Peng wrote:
> > OK?
>
> Yes.

Done.
Once you find some time, could you please add tooltips to the dialog? You now 
better than me what the specific widgets are supposed to do.

Jürgen


Re: Qt4 mac

2007-05-20 Thread Scott Lambert
I built Qt4.2.3 from source exactly as described in INSTALL.MacOSX.  
(I even literally used "/path/to/QT4" as the destination.) Here are  
some lines from the configure script. It seems to find some things in  
the Qt4 tree but not others.


checking for QT4_CORE... checking for QT4_FRONTEND... checking for Qt  
4 library name... failed

checking for moc-qt4... no
checking for moc... /path/to/QT4//bin/moc
checking for uic-qt4... no
checking for uic... /path/to/QT4//bin/uic


Bob,
I tried using:
export PKG_CONFIG_PATH=/path/to/Qt4/lib/pkgconfig/

It didn't help. In fact my Qt4 tree contains not such directory!
I have attached a full listing of my Qt4 tree.
scott-lamberts-computer:/path/to/qt4 slambert$ ls -mR
bin, doc, include, lib, mkspecs, plugins, translations

./bin:
moc, qmake, rcc, uic, uic3

./doc: [I DELETED THIS PART OF THE OUTPUT]

./include:
Qt, Qt3Support, QtCore, QtGui, QtNetwork, QtOpenGL, QtSql, QtSvg, QtXml

./include/Qt:
Qt3Support, QtCore, QtGui, QtNetwork, QtOpenGL, QtSql, QtSvg, QtXml, 
q3accel.h, q3action.h, q3asciicache.h, q3asciidict.h, q3boxlayout.h, 
q3button.h, q3buttongroup.h, q3cache.h, q3canvas.h, q3cleanuphandler.h, 
q3combobox.h, q3cstring.h, q3databrowser.h, q3datatable.h, q3dataview.h, 
q3datetimeedit.h, q3deepcopy.h, q3dict.h, q3dns.h, q3dockarea.h, 
q3dockwindow.h, q3dragobject.h, q3dropsite.h, q3editorfactory.h, 
q3filedialog.h, q3frame.h, q3ftp.h, q3garray.h, q3gcache.h, q3gdict.h, 
q3glist.h, q3grid.h, q3gridlayout.h, q3gridview.h, q3groupbox.h, q3gvector.h, 
q3hbox.h, q3header.h, q3hgroupbox.h, q3http.h, q3iconview.h, q3intcache.h, 
q3intdict.h, q3listbox.h, q3listview.h, q3localfs.h, q3mainwindow.h, 
q3memarray.h, q3mimefactory.h, q3multilineedit.h, q3network.h, 
q3networkprotocol.h, q3objectdict.h, q3paintdevicemetrics.h, q3painter.h, 
q3picture.h, q3pointarray.h, q3polygonscanner.h, q3popupmenu.h, q3process.h, 
q3progressbar.h, q3progressdialog.h, q3ptrcollection.h, q3ptrdict.h, 
q3ptrlist.h, q3ptrqueue.h, q3ptrstack.h, q3ptrvector.h, q3rangecontrol.h, 
q3scrollview.h, q3semaphore.h, q3serversocket.h, q3shared.h, q3signal.h, 
q3simplerichtext.h, q3socket.h, q3socketdevice.h, q3sortedlist.h, 
q3sqlcursor.h, q3sqleditorfactory.h, q3sqlfieldinfo.h, q3sqlform.h, 
q3sqlpropertymap.h, q3sqlrecordinfo.h, q3sqlselectcursor.h, q3strlist.h, 
q3strvec.h, q3stylesheet.h, q3syntaxhighlighter.h, q3tabdialog.h, q3table.h, 
q3textbrowser.h, q3textedit.h, q3textstream.h, q3textview.h, q3tl.h, 
q3toolbar.h, q3url.h, q3urloperator.h, q3valuelist.h, q3valuestack.h, 
q3valuevector.h, q3vbox.h, q3vgroupbox.h, q3whatsthis.h, q3widgetstack.h, 
q3wizard.h, qabstractbutton.h, qabstracteventdispatcher.h, 
qabstractfileengine.h, qabstractitemdelegate.h, qabstractitemmodel.h, 
qabstractitemview.h, qabstractpagesetupdialog.h, qabstractprintdialog.h, 
qabstractproxymodel.h, qabstractscrollarea.h, qabstractslider.h, 
qabstractsocket.h, qabstractspinbox.h, qabstracttextdocumentlayout.h, 
qaccessible.h, qaccessiblebridge.h, qaccessibleobject.h, qaccessibleplugin.h, 
qaccessiblewidget.h, qaction.h, qactiongroup.h, qalgorithms.h, qapplication.h, 
qatomic.h, qatomic_alpha.h, qatomic_arch.h, qatomic_arm.h, 
qatomic_boundschecker.h, qatomic_generic.h, qatomic_i386.h, qatomic_ia64.h, 
qatomic_macosx.h, qatomic_mips.h, qatomic_parisc.h, qatomic_powerpc.h, 
qatomic_s390.h, qatomic_sparc.h, qatomic_x86_64.h, qbasictimer.h, qbitarray.h, 
qbitmap.h, qboxlayout.h, qbrush.h, qbuffer.h, qbuttongroup.h, qbytearray.h, 
qbytearraymatcher.h, qcache.h, qcalendarwidget.h, qcdestyle.h, qchar.h, 
qcheckbox.h, qcleanlooksstyle.h, qclipboard.h, qcolor.h, qcolordialog.h, 
qcolormap.h, qcombobox.h, qcommonstyle.h, qcompleter.h, qconfig-dist.h, 
qconfig-large.h, qconfig-medium.h, qconfig-minimal.h, qconfig-small.h, 
qconfig.h, qcontainerfwd.h, qcoreapplication.h, qcoreevent.h, qcursor.h, 
qdatastream.h, qdatawidgetmapper.h, qdatetime.h, qdatetimeedit.h, qdebug.h, 
qdesktopservices.h, qdesktopwidget.h, qdial.h, qdialog.h, qdialogbuttonbox.h, 
qdir.h, qdirmodel.h, qdockwidget.h, qdom.h, qdrag.h, qdrawutil.h, qendian.h, 
qerrormessage.h, qevent.h, qeventloop.h, qfactoryinterface.h, qfeatures.h, 
qfile.h, qfiledialog.h, qfileinfo.h, qfilesystemwatcher.h, qfocusframe.h, 
qfont.h, qfontcombobox.h, qfontdatabase.h, qfontdialog.h, qfontinfo.h, 
qfontmetrics.h, qframe.h, qfsfileengine.h, qftp.h, qgl.h, qglcolormap.h, 
qglframebufferobject.h, qglobal.h, qglpixelbuffer.h, qgraphicsitem.h, 
qgraphicsitemanimation.h, qgraphicsscene.h, qgraphicssceneevent.h, 
qgraphicssvgitem.h, qgraphicsview.h, qgridlayout.h, qgroupbox.h, qhash.h, 
qheaderview.h, qhostaddress.h, qhostinfo.h, qhttp.h, qicon.h, qiconengine.h, 
qiconengineplugin.h, qiconset.h, qimage.h, qimageiohandler.h, qimagereader.h, 
qimagewriter.h, qinputcontext.h, qinputcontextfactory.h, 
qinputcontextplugin.h, qinputdialog.h, qiodevice.h, qitemdelegate.h, 
qitemeditorfactory.h, qitemselectionmodel.h, qiterator.h, qkeysequence.h, 
qlabel.h, qlayout.h, qlayoutitem.h, qlcdnumber.h, 

Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Uwe Stöhr

Jürgen wrote:

> Index: src/frontends/qt4/QInclude.cpp
> ===
> --- src/frontends/qt4/QInclude.cpp (Revision 18428)
> +++ src/frontends/qt4/QInclude.cpp (Arbeitskopie)
> ...
> @@ -246,6 +248,7 @@
>if (cap[0] == '{' && cap[cap.size()-1] == '}')
>
dialog_->captionLE->setText(toqstr(cap.substr(1,
> cap.size()-2)));
>else
> +  // FIXME: make this translatable!
>throw invalidParam("caption parameter is 
not quoted with
> braces");

Why does this not work?:

+ throw invalidParam(qt_("caption parameter is not quoted with braces"));

The same here:

> @@ -253,6 +256,7 @@
>if (lbl[0] == '{' && lbl[lbl.size()-1] == '}')
>
dialog_->labelLE->setText(toqstr(lbl.substr(1,
> lbl.size()-2)));
>else
> +  // FIXME: make this translatable!
>throw invalidParam("label parameter is not quoted 
with > braces");

regards Uwe


[patch] announce CJK language dialog support

2007-05-20 Thread Uwe Stöhr
I've seen that the support for the CJK languages in the dialogs was not announced. This change 
requires a warning as Georg stated in bug 3043.


So attached is my proposal to announce it in the NEWS and ANNOUNCE file. OK?

regards Uwe
Index: ANNOUNCE
===
--- ANNOUNCE	(revision 18430)
+++ ANNOUNCE	(working copy)
@@ -99,6 +99,10 @@
 
 The very first result of the Unicode transition is that we have finally
 merged in the externally maintained CJK-LyX branch.
+The languages Chinese, Japanese, and Korean are now supported in
+the document dialogs.
+Note that from now on, former encoding settings for these languages
+done via ERT or the document preamble will lead to LaTeX-errors!
 
 * Multiple views of the same buffer
 
Index: NEWS
===
--- NEWS	(revision 18430)
+++ NEWS	(working copy)
@@ -2,9 +2,14 @@
  
 
 Compared with the previous beta release we have fixed several bugs
-and added some improvements, namely a new inset to support code listings.
+and added some improvements:
 
-We have enabled the converter file cache by default.
+ * A new inset to support code listings.
+ * We have enabled the converter file cache by default.
+ * The languages Armenian, Chinese, Japanese, and Korean are now supported in
+   the document dialogs.
+   Note that from now on, former encoding settings for these languages
+   done via ERT or the document preamble will lead to LaTeX-errors!
 
 Internally we have renamed files to follow a consistent name pattern,
 this will allow an easier navigation of the source code thus simplifying


Re: [patch] bug 3645: make listings dialog translatable

2007-05-20 Thread Jürgen Spitzmüller
Uwe Stöhr wrote:
> Why does this not work?:
>
> + throw invalidParam(qt_("caption parameter is not quoted with braces"));

because invalidParam expects a std::string, qt_() is a QString. I think 
InsetListingsParams need to be rewritten to handle docstrings (that would be 
_("string")).

Jürgen


[Fwd: Re: superscript]

2007-05-20 Thread Richard Heck

Richard Heck wrote:
> Can you be more specific about the problem? What kind of keyboard are
> you using? What language encoding? etc?
>
> Gyorgy Pota wrote:
>   
>> Dear Users,
>>
>> It has already been raised that, for example, textdegree symbol did
>> not work in the early Lyx 1.5 beta(s). Now I can report that for me
>> there is a number of keyboard symbols, including carets, degree etc.
>> that do not work. They do not appear on the screen either.  These are
>> usually inserted using Altgr. I tried Lyx betas 2 and 3 for Windows.
>> What should I do or is this still a bug?
>>
>> With  best wishes,
>>
>> Gyorgy Pota
>>
>> 
>
>
>   

I am using an IBM R50e laptop with Hungarian keyboard. The language of 
the article document is English, the "Use language's default encoding" 
option is on. The "Use keyboard map" option in the Preferences is off, 
as in the case of Lyx 1.4.4 where everything worked.

Many characters can be entered with the use of Altgr key. In the 
uppermost row of the keybard the key wave line ~ and the accent 
character ` appear with Altgrey but the others, including the carets up 
^ and down ˇ and the degree ° do not. These latters, of course, appear 
in other software as you perhaps see in this message too.

Let me draw your attention to the message lyx-1.5: textdegree 
 
Bernd Sellentin in the Lyx user's list.

Thank you very much for your help.

Gyorgy Pota

-- 

Dr. Gyorgy Pota
associate professor
Institute of Physical Chemistry
University of Debrecen
H-4010 Debrecen, P. O. Box 7,
Hungary
Tel.: (36) 52-512-90022383
Fax: (36) 52-512-915
homepage: http://dragon.unideb.hu/~wwwphch/potae.htm
private homepage: puma.unideb.hu/~potagy



-- 
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto



Re: Qt4 mac

2007-05-20 Thread Anders Ekberg

On 20 maj 2007, at 16.43, Scott Lambert wrote:

I built Qt4.2.3 from source exactly as described in INSTALL.MacOSX.  
(I even literally used "/path/to/QT4" as the destination.) Here are  
some lines from the configure script. It seems to find some things  
in the Qt4 tree but not others.


checking for QT4_CORE... checking for QT4_FRONTEND... checking for  
Qt 4 library name... failed

checking for moc-qt4... no
checking for moc... /path/to/QT4//bin/moc
checking for uic-qt4... no
checking for uic... /path/to/QT4//bin/uic


OK, I think it may be a priviligies problem. Try to create an account  
directly under your user account that you call QT43. Either by open  
the Terminal and typing mkdir QT43 . Or in the Finder select your  
user home directory (If your user name is scott, it is named scott.  
You will be in that directory if you open a new Finder window.),  
create a new folder (File -> New folder) and name it QT43.


Now replace /path/to/QT4 with /Users/scott/QT43
and run the compilation of QT (don't forget the make install command  
and to remove the .la-files) and of LyX again.




Bob,
I tried using:
export PKG_CONFIG_PATH=/path/to/Qt4/lib/pkgconfig/

It didn't help. In fact my Qt4 tree contains not such directory!
I have attached a full listing of my Qt4 tree.


It shouldn't be needed as Bennet pointed out.


Also the link (http://www.trolltech.com/download/qt/mac.html)
 given in INSTALL.MacOSX is not valid.

Right, it should be:
http://trolltech.com/developer/downloads/qt/mac
Bennett, can you update this?

/Anders



Re: Qt4 mac

2007-05-20 Thread Anders Ekberg


On 20 maj 2007, at 17.29, Anders Ekberg wrote:


On 20 maj 2007, at 16.43, Scott Lambert wrote:

I built Qt4.2.3 from source exactly as described in  
INSTALL.MacOSX. (I even literally used "/path/to/QT4" as the  
destination.) Here are some lines from the configure script. It  
seems to find some things in the Qt4 tree but not others.


checking for QT4_CORE... checking for QT4_FRONTEND... checking for  
Qt 4 library name... failed

checking for moc-qt4... no
checking for moc... /path/to/QT4//bin/moc
checking for uic-qt4... no
checking for uic... /path/to/QT4//bin/uic


OK, I think it may be a priviligies problem. Try to create an account


that should of course be * a directory * (sorry Sunday tiredness...)

directly under your user account that you call QT43. Either by open  
the Terminal and typing mkdir QT43 . Or in the Finder select your  
user home directory (If your user name is scott, it is named scott.  
You will be in that directory if you open a new Finder window.),  
create a new folder (File -> New folder) and name it QT43.


Now replace /path/to/QT4 with /Users/scott/QT43


and that is of course presuming your user name is scott

and run the compilation of QT (don't forget the make install  
command and to remove the .la-files) and of LyX again.




Bob,
I tried using:
export PKG_CONFIG_PATH=/path/to/Qt4/lib/pkgconfig/

It didn't help. In fact my Qt4 tree contains not such directory!
I have attached a full listing of my Qt4 tree.


It shouldn't be needed as Bennet pointed out.


Also the link (http://www.trolltech.com/download/qt/mac.html)
 given in INSTALL.MacOSX is not valid.

Right, it should be:
http://trolltech.com/developer/downloads/qt/mac
Bennett, can you update this?

/Anders





Re: [Bug 3561] Comments

2007-05-20 Thread Richard Heck
Jürgen Spitzmüller wrote:
> Richard Heck wrote:
>   
>> I've been studying this bug a bit and think I know where the problem is,
>> more or less. The attached file is as minimal as I can get it. The
>> change of font is crucial. Without it, there is no crash.
>> 
> I think the real problem is really just the view-source widget requesting an 
> invalid encoding change. This whole bug only occurs if that widget is open, 
> with some debug output, you can see that the encodings involved are bogus.
>   
Yes, you're right. I'm trying to figure out then why the encoding change
is invalid then. This is happening on the update after
ControlDocument::dispatchParams() has called setLanguage() and before
the other stuff has happened. So there's something that hasnt' happened
then that needs to happen. What?

One thought, though this would be a pretty extensive change in some
ways. I wonder if kernel().dispatch() couldn't take an optional boolean
update that, if false, would prevent the updating from being done. It
seems as if there are various times when we get sequences of updates
right in a row that are pretty pointless. For example, in this very
function, there might be several calls to kernel().dispatch(), and every
one of them is going to trigger a complete update cycle. That's a waste
of time. Probably a lot of time in some cases.

Richard

-- 
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto



Re: [Bug 3561] Comments

2007-05-20 Thread Richard Heck
Jürgen Spitzmüller wrote:
> Richard Heck wrote:
>   
>> I've been studying this bug a bit and think I know where the problem is,
>> more or less. The attached file is as minimal as I can get it. The
>> change of font is crucial. Without it, there is no crash.
>> 
> I think the real problem is really just the view-source widget requesting an 
> invalid encoding change. This whole bug only occurs if that widget is open, 
> with some debug output, you can see that the encodings involved are bogus.
>   
Yes, you're right. I'm trying to figure out then why the encoding change
is invalid then. This is happening on the update after
ControlDocument::dispatchParams() has called setLanguage() and before
the other stuff has happened. So there's something that hasnt' happened
then that needs to happen. What?

It seems that the problem is that, when the update happens and view
source is open oldEnc is Encoding::inputenc, whereas it is Encoding::CJK
when you do a normal LaTeX export later. This is ultimately coming from
Buffer::params(). So it looks like the answer to my question is that the
buffer params haven't been updated at this point, and that is what is
causing the invalid output.

Richard

-- 
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto


Re: Scrolling lag in 1.5svn again, more details.

2007-05-20 Thread Peter Kümmel
Abdelrazak Younes wrote:
>> Is this your only comment?
> 
> Yes. Sorry, don't have the time to do much more. I thought I'd share my
> opinion ;-)

Sorry, too - for my harsh reply.

> 
>>
>> Anyway I don't think there is a simpler solution, at least I will
>> not look for it, this bug has cost me already too much time.

OK, I've found a better solution ;)
I had to test if it was worth to upgrade to 1GB ram.

> 
> I can understand that. I was thinking of collecting the scroll events
> and cancelling them if a scroll operation is still on-going but maybe
> that's what your patch do. I only briefly looked at it and it _seems_
> very complicated.

Yes this is what it does. An it _is_ complicated. ;)

But I've found a more Qt like and elegant solution.
See attached patch, which should be much more readably.

I've introduced two events which are only posted once
to the event queue until the event is not processed.

This also improves(?) the scrolling under Windows,
see the comment in generateLyxScrollEvent.

> 
>>
>> Dimitri from Trolltech wrote on a similar problem:
>>
>> "You'll need to maintain flags, QTimers waiting N milliseconds and other
>> data to achive that. There's no equivalent information maintained by Qt."
>>
>> http://lists.trolltech.com/qt-interest/2006-02/thread00129-0.html
>>
>>
>> Hope this has convinced you. ;)
> 
> I trust you.

But the patch needs still more testing.

Peter
Index: src/frontends/qt4/GuiWorkArea.cpp
===
--- src/frontends/qt4/GuiWorkArea.cpp   (revision 18430)
+++ src/frontends/qt4/GuiWorkArea.cpp   (working copy)
@@ -190,8 +190,11 @@
 
// Initialize the vertical Scroll Bar
QObject::connect(verticalScrollBar(), SIGNAL(actionTriggered(int)),
-   this, SLOT(adjustViewWithScrollBar(int)));
+   this, SLOT(generateLyxScrollEvent()));
+   QObject::connect(verticalScrollBar(), SIGNAL(sliderReleased()),
+   this, SLOT(lyxScrollEvent()));
 
+
// disable context menu for the scrollbar
verticalScrollBar()->setContextMenuPolicy(Qt::NoContextMenu);
 
@@ -211,6 +214,53 @@
 }
 
 
+
+class LyxScrollEvent : public QEvent
+{
+public:
+   LyxScrollEvent() : QEvent(QEvent::Type(id)) 
+   {}
+   static int id;
+   static bool locked;
+};
+
+// Qt doc: user event type between 1000 and 65535
+int LyxScrollEvent::id = 31415;
+bool LyxScrollEvent::locked = false;
+
+
+class LyxKeyEvent : public QKeyEvent
+{
+public:
+   LyxKeyEvent(QKeyEvent * e) : 
+ QKeyEvent(QEvent::Type(id), e->key(), 
+   e->modifiers(), e->text(), e->isAutoRepeat(), 
e->count())
+   {}
+   static int id;
+   static bool locked;
+};
+
+int LyxKeyEvent::id = 27182;
+bool LyxKeyEvent::locked = false;
+
+
+
+bool GuiWorkArea::event(QEvent * event)
+{
+   if (event->type() == LyxKeyEvent::id) {
+   lyxKeyEvent(dynamic_cast(event));
+   LyxKeyEvent::locked = false;
+   return true;
+   } else if (event->type() == LyxScrollEvent::id) {
+   lyxScrollEvent();
+   LyxScrollEvent::locked = false;
+   return true;
+   } else {
+   return QAbstractScrollArea::event(event);
+   }
+}
+
+
 void GuiWorkArea::setScrollbarParams(int h, int scroll_pos, int 
scroll_line_step)
 {
if (verticalScrollBarPolicy() != Qt::ScrollBarAlwaysOn)
@@ -231,12 +281,30 @@
 }
 
 
-void GuiWorkArea::adjustViewWithScrollBar(int)
+void GuiWorkArea::lyxScrollEvent()
 {
scrollBufferView(verticalScrollBar()->sliderPosition());
 }
 
 
+void GuiWorkArea::generateLyxScrollEvent()
+{
+   // This gives the old slow (the scroll bar couldn't follow the mouse)
+   // scrolling on Windows. Is it really better? 
+   // Windows/Qt is here not as fast as X11
+   //lyxScrollEvent();return;
+
+   // multiple scroll events are merged into one
+   if (!LyxScrollEvent::locked) {
+   LyxScrollEvent::locked = true;
+   LyxScrollEvent* scrollEvent = new LyxScrollEvent;
+   QCoreApplication::postEvent(this, scrollEvent);
+   LYXERR(Debug::GUI) << "scrolling: one event posted" << endl;
+   } else {
+   LYXERR(Debug::GUI) << "scrolling: waiting for processing last 
scrolling event" << endl;
+   }
+}
+
 void GuiWorkArea::dragEnterEvent(QDragEnterEvent * event)
 {
if (event->mimeData()->hasUrls())
@@ -389,13 +457,14 @@
int const lines = qApp->wheelScrollLines() * e->delta() / 120;
verticalScrollBar()->setValue(verticalScrollBar()->value() -
lines *  verticalScrollBar()->singleStep());
-   adjustViewWithScrollBar();
+   
+   generateLyxScrollEvent();
 }
 
 
 void GuiWorkArea::generateSyntheticMouseEvent()
 {
-// Set things off to generate the _next_ 'pseudo' event.
+   // Set things off to generate the _next_ 'pseudo' 

Re: Scrolling lag in 1.5svn again, more details.

2007-05-20 Thread Peter Kümmel
Dov Feldstern wrote:
> Peter Kümmel wrote:
>>
>> On slow/loaded systems the last patch floods the
>> event queue with timer events instead of key/scroll events.
>> I hope attached patch will now really fix the problem.
>>
>> Peter
>>
> 
> This works for me (timer_scroll_4.patch) --- at least for what I'm
> testing, namely, cursor movement by holding down keys.
> 

Thanks Dov, good to hear, then I assume that the
next patch will also work: event_1.patch.

Peter


Re: Qt4 mac

2007-05-20 Thread Andreas Neustifter

On 20.05.2007, at 17:45, Anders Ekberg wrote:



On 20 maj 2007, at 17.29, Anders Ekberg wrote:


On 20 maj 2007, at 16.43, Scott Lambert wrote:

I built Qt4.2.3 from source exactly as described in  
INSTALL.MacOSX. (I even literally used "/path/to/QT4" as the  
destination.) Here are some lines from the configure script. It  
seems to find some things in the Qt4 tree but not others.


checking for QT4_CORE... checking for QT4_FRONTEND... checking  
for Qt 4 library name... failed

checking for moc-qt4... no
checking for moc... /path/to/QT4//bin/moc
checking for uic-qt4... no
checking for uic... /path/to/QT4//bin/uic


I found that (as mentioned in a mail called "slow when editing  
paragraphs with math" on 18.05.2007 on this list) that the configure  
step strangely enough doesn't find the libiconv when trying to  
configure Qt and thus the problems (if its the same problem I had.)  
config.log says:

configure:24304: checking for QT4_CORE
configure:24381: checking for QT4_FRONTEND
configure:24483: checking for Qt 4 library name
configure:24532: g++ -o conftest -g -Os -I/Users/astifter/qt-4.2.3// 
include -I/Users/astifter/qt-4.2.3//include/Qt -I/Users/astifter/ 
qt-4.2.3//include/QtCore -I/Users/astifter/qt-4.2.3//include/QtGui -L/ 
Users/astifter/qt-4.2.3//lib -Wextra -Wall   -framework Carbon - 
framework OpenGL -framework AGL -framework QuickTime -lz -framework  
Cocoa conftest.cpp -lc -lm  -lQtCore >&5

/usr/bin/ld: Undefined symbols:
_libiconv
_libiconv_close
_libiconv_open
collect2: ld returned 1 exit status
configure:24538: $? = 1

I added -liconv to the LDPATH and it worked prefectly well, so  
command reads then:
$> export LDFLAGS="-framework Carbon -framework OpenGL -framework AGL  
-framework QuickTime -lz -framework Cocoa -liconv"


@Scott: Hope that helps.
@all: any idea why that happens? I'm quite not familiar with automake  
and couldn't figure it out myself.


Greetings Astifter

PS: How are the correct citing and posting rules in this list?


Re: crash tex2lyx

2007-05-20 Thread Andre Poenitz
On Sat, May 19, 2007 at 11:16:42PM +0200, Stefan Schimanski wrote:
> There is something really strange going on. I am trying to debug the  
> problem for half an hour now as it also shows up on my machine. The  
> layoutlist_ containter looks fine before the "cit = begin()" call in  
> TextClass::read. But when I step into the begin() function suddenly  
> the start value of the layoutlist_ container turns into 0x0. More  
> precisely in TextClass::read tells me that layoutlist_::P_impl is at  
> 0xb0c8. In the begin() call though it is shown at 0xb0e8  
> where the 0x0 is. This either smells like a compiler error or some  
> memory corruption.

Clearly a compiler error. The earth is flat, and pigs can fly...

Andre'


Re: BUG 3622: Weird date external material.

2007-05-20 Thread Andre Poenitz
On Sat, May 19, 2007 at 11:46:28PM -0500, Bo Peng wrote:
> >I traced this bug a little bit and find some weird things going on.
> 
> I am surprised that ifstream(".") returns OK, as shown in my test program.
> 
> #include 
> #include 
> 
> int main()
> {
>std::ifstream ifs(".");

There is nothing wrong with opening a directory forreading in general.

Andre'


Re: crash tex2lyx

2007-05-20 Thread Stefan Schimanski

Which build system do you use? automake/conf? cmake?

Stefan

Am 16.05.2007 um 13:42 schrieb Leuven, E.:


with attached doc.

backtrace:

tex2lyx.exe!boost::assertion_failed(const char *  
expr=0x005b6c44, const char * function=0x005b6c50, const char *  
file=0x005b6cc0, long line=315)  Line 39 + 0x8 bytes   C++
tex2lyx.exe!boost::shared_ptr::operator->()   
Line 315 + 0x23 bytes C++
>   tex2lyx.exe!lyx::TextClass::read(const  
lyx::support::FileName & filename={...}, bool merge=false)  Line  
455 + 0x12 bytesC++
tex2lyx.exe!lyx::parse_preamble(lyx::Parser & p={...},  
std::basic_ostream & os={...}, const  
std::basic_string & forceclass="")  Line 502   C++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx 
(std::basic_istream & is={...},  
std::basic_ostream & os={...})  Line  
428 + 0x3e bytesC++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx(const  
lyx::support::FileName & infilename={...},  
std::basic_ostream & os={...})  Line  
462 + 0x10 bytesC++
tex2lyx.exe!lyx::tex2lyx(const  
std::basic_string & infilename="C:/_projects/profs3/internal.tex", const  
lyx::support::FileName & outfilename={...})  Line 494 + 0x38  
bytes   C++
tex2lyx.exe!main(int argc=2, char * * argv=0x003d52f8)   
Line 554 + 0x35 bytes   C++

tex2lyx.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes  C
tex2lyx.exe!mainCRTStartup()  Line 403  C
kernel32.dll!7c816fd7()






PGP.sig
Description: Signierter Teil der Nachricht


Re: Scrolling lag in 1.5svn again, more details.

2007-05-20 Thread Dov Feldstern

Peter Kümmel wrote:

Dov Feldstern wrote:

Peter Kümmel wrote:

On slow/loaded systems the last patch floods the
event queue with timer events instead of key/scroll events.
I hope attached patch will now really fix the problem.

Peter


This works for me (timer_scroll_4.patch) --- at least for what I'm
testing, namely, cursor movement by holding down keys.



Thanks Dov, good to hear, then I assume that the
next patch will also work: event_1.patch.

Peter

Yes, it does. :) It seems perhaps to respond even better than the 
previous patch, though that may only be my imagination ;) . I'll keep 
this in for now, I'll let you know if I run into any trouble.


Dov



Re: Qt4 binary

2007-05-20 Thread Andre Poenitz
On Sun, May 20, 2007 at 08:25:56PM +0200, Andreas Neustifter wrote:
> But since it's not quite uninteresting for new users to install the  
> binary Qt, here the list of files which are installed.

Next time please zip that. 170k is a bit too much to send to the list.

Andre'


Re: crash tex2lyx

2007-05-20 Thread Stefan Schimanski
The following patch fixes this problem for the cmake build system. I  
have not checked the other build systems, maybe similar fixes are  
needed there.


The problem basically is that in the inline functions a different  
Font class was used than in the .cpp files. This was leading to these  
very strange errors.


Stefan

@Peter: ok to commit? Any comment?




tex2lyxcmake.patch
Description: Binary data



with attached doc.

backtrace:

tex2lyx.exe!boost::assertion_failed(const char *  
expr=0x005b6c44, const char * function=0x005b6c50, const char *  
file=0x005b6cc0, long line=315)  Line 39 + 0x8 bytes   C++
tex2lyx.exe!boost::shared_ptr::operator->()   
Line 315 + 0x23 bytes C++
>   tex2lyx.exe!lyx::TextClass::read(const  
lyx::support::FileName & filename={...}, bool merge=false)  Line  
455 + 0x12 bytesC++
tex2lyx.exe!lyx::parse_preamble(lyx::Parser & p={...},  
std::basic_ostream & os={...}, const  
std::basic_string & forceclass="")  Line 502   C++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx 
(std::basic_istream & is={...},  
std::basic_ostream & os={...})  Line  
428 + 0x3e bytesC++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx(const  
lyx::support::FileName & infilename={...},  
std::basic_ostream & os={...})  Line  
462 + 0x10 bytesC++
tex2lyx.exe!lyx::tex2lyx(const  
std::basic_string & infilename="C:/_projects/profs3/internal.tex", const  
lyx::support::FileName & outfilename={...})  Line 494 + 0x38  
bytes   C++
tex2lyx.exe!main(int argc=2, char * * argv=0x003d52f8)   
Line 554 + 0x35 bytes   C++

tex2lyx.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes  C
tex2lyx.exe!mainCRTStartup()  Line 403  C
kernel32.dll!7c816fd7()






PGP.sig
Description: Signierter Teil der Nachricht


Re: Qt4 mac

2007-05-20 Thread Andre Poenitz
On Sun, May 20, 2007 at 08:21:56PM +0200, Andreas Neustifter wrote:
> PS: How are the correct citing and posting rules in this list?

Cut down any cited material to the bit you are responding to and write
your comments below.

Do not send binaries unless it's compressed plain text.

Avoid sending huge messages. There used to be a limit around 50 or
100k a while ago but I am not sure this is enforced by the list
software. Exemptions are officially allowed for really big but
useful patches.

Adjust your tone to the average you found on the list. This rule is
officially suspended on Friday.

Ignore rude comments on Fridays.

Send lots of good patches.

Andre'


Re: crash tex2lyx

2007-05-20 Thread Edwin Leuven

great detective work!!

this fixes the crash on my side, so this gets an ok from me.


Stefan Schimanski wrote:
The following patch fixes this problem for the cmake build system. I 
have not checked the other build systems, maybe similar fixes are needed 
there.


The problem basically is that in the inline functions a different Font 
class was used than in the .cpp files. This was leading to these very 
strange errors.


Stefan

@Peter: ok to commit? Any comment?




with attached doc.

backtrace:

tex2lyx.exe!boost::assertion_failed(const char * 
expr=0x005b6c44, const char * function=0x005b6c50, const char * 
file=0x005b6cc0, long line=315)  Line 39 + 0x8 bytes   C++
tex2lyx.exe!boost::shared_ptr::operator->()  Line 
315 + 0x23 bytes C++
>   tex2lyx.exe!lyx::TextClass::read(const lyx::support::FileName 
& filename={...}, bool merge=false)  Line 455 + 0x12 bytesC++
tex2lyx.exe!lyx::parse_preamble(lyx::Parser & p={...}, 
std::basic_ostream & os={...}, const 
std::basic_string & 
forceclass="")  Line 502   C++
tex2lyx.exe!lyx::`anonymous 
namespace'::tex2lyx(std::basic_istream & 
is={...}, std::basic_ostream & 
os={...})  Line 428 + 0x3e bytesC++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx(const 
lyx::support::FileName & infilename={...}, 
std::basic_ostream & os={...})  Line 462 
+ 0x10 bytesC++
tex2lyx.exe!lyx::tex2lyx(const 
std::basic_string & 
infilename="C:/_projects/profs3/internal.tex", const 
lyx::support::FileName & outfilename={...})  Line 494 + 0x38 bytes   C++
tex2lyx.exe!main(int argc=2, char * * argv=0x003d52f8)  Line 
554 + 0x35 bytes   C++

tex2lyx.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes  C
tex2lyx.exe!mainCRTStartup()  Line 403  C
kernel32.dll!7c816fd7()








Re: BUG 3622: Weird date external material.

2007-05-20 Thread Andre Poenitz
On Sun, May 20, 2007 at 08:46:35AM -0500, Bo Peng wrote:
> >I propose the attached patch. Can I apply?
> 
> So no one knows this lyxsum stuff? My patch will do no harm on
> platforms when my testcase return error for ifstream("/a/path") so if
> should be safe to commit.
> 
> OK?

I already deleted the proposed pathc, but there were style issues.
'if' one one line or such IIRC.

Andre'


Re: Qt4 mac

2007-05-20 Thread Bennett Helm

On May 20, 2007, at 11:29 AM, Anders Ekberg wrote:


Also the link (http://www.trolltech.com/download/qt/mac.html)
 given in INSTALL.MacOSX is not valid.

Right, it should be:
http://trolltech.com/developer/downloads/qt/mac
Bennett, can you update this?


Actually, it looks like



is better. That's what I've done (though I'll wait a while to post  
the change to see what else comes down the pike).


Bennett


Re: BUG 3622: Weird date external material.

2007-05-20 Thread Bo Peng

I already deleted the proposed pathc, but there were style issues.
'if' one one line or such IIRC.


Are you talking about my patch?

Bo


No math dialog

2007-05-20 Thread John Levon

I see the Maths dialog has been removed. Am I right in thinking that the
only way to create things such as sum environments etc. without knowing
LaTeX is to turn on the math panel toolbar and use that?

This really needs to be available in the menus too for discoverability:
it's a basic principle of toolbars that they are a quicker form of
what's available in the menus, not a replacement, especially when
they're not available by default.

I noticed that right clicking on toolbar space no longer brings up the
menu of available toolbars. Is that a Qt4 thing, or intentional?

I see the toolbar on the right is still present :/

Current SVN is looking pretty nice!

cheers
john


Re: Scrolling lag in 1.5svn again, more details.

2007-05-20 Thread Martin Vermeer
On Sun, May 20, 2007 at 07:08:59PM +0200, Peter Kümmel wrote:
> Abdelrazak Younes wrote:

...
 
> OK, I've found a better solution ;)
> I had to test if it was worth to upgrade to 1GB ram.
> 
> > 
> > I can understand that. I was thinking of collecting the scroll events
> > and cancelling them if a scroll operation is still on-going but maybe
> > that's what your patch do. I only briefly looked at it and it _seems_
> > very complicated.
> 
> Yes this is what it does. An it _is_ complicated. ;)
> 
> But I've found a more Qt like and elegant solution.
> See attached patch, which should be much more readably.
> 
> I've introduced two events which are only posted once
> to the event queue until the event is not processed.
> 
> This also improves(?) the scrolling under Windows,
> see the comment in generateLyxScrollEvent.

Yes, this looks _much_ better. Just as complicated, but very well designed ;-/

- Martin
 


Re: Qt4 binary

2007-05-20 Thread Andreas Neustifter


On 20.05.2007, at 22:52, Andre Poenitz wrote:


Next time please zip that. 170k is a bit too much to send to the list.

Sorry, I tend to get sloppy with this DSL lines.

A nice week to you all, Astifter


  1   2   >