Re: LyX/Win 1.4.1 pre1
[EMAIL PROTECTED] wrote: On Mon, 20 Mar 2006, Jean-Marc Lasgouttes wrote: Jose' == Jose' Matos [EMAIL PROTECTED] writes: Jose' On Monday 20 March 2006 11:13, Jean-Marc Lasgouttes wrote: I have to admit I have never seen this word. Do people really use it in normal discussion? Jose' Don't you have this word (or similar) in French? Jose' This comes from Latin, we have it in Portuguese. Yes, from excalesco, is, ere A late latin verb meaning as you have guessed 'getting hot' I think we have a nickname for LyX 1.5.1 Cheers, Charles -- http://www.kde-france.org
Re: Qt-4, gcc-3.3, Mac OS X: link failure
Bennett Helm a écrit : On Mar 20, 2006, at 5:33 PM, Abdelrazak Younes wrote: Bennett Helm a écrit : I've been trying now to compile lyx with the Qt-4 frontend and gcc-3.3, and I get the following at the final link stage. Any suggestions? Hello Bennet, QUrl is defined in libQtCore or libQtCore4 depending on your Qt4 packaging. I think png* is defined in libpng. All the rest should be MacOS specific stuff. On Windows this kind of library are statically linked into QtCore, so curing the first problem might also cure this one. Please give me the final linking command as executed by make for Qt3 and Qt4 frontends so we cam compare. We must verify that -lQtCore or -lQtCore4 is there. Here's the beginning of the link stage for the Qt4 frontend: -lQtCore is there. (I'll try to get the one for Qt3 tomorrow) Hum, have you compiled Qt4 yourself or did you use a precompiled package? I remember you said you manage to get an executable once, didn't you? Could you please give me the output of : ls /Users/bennett/lyx/gcc-3.3/qt-mac-opensource-src-4.1.1/lib Thanks, Abdel.
Re: [Ãpatch] RandomAccessList take 4
Lars Gullik Bjønnes wrote: Georg Baum [EMAIL PROTECTED] writes: | The problem were missing conversions of | | pars.begin() + x | | to | | boost::next(pars.begin(), x) Where were they missing? In some cut and paste code that does no longer exist in 1.5. BTW my patch is missing the new file src/ParagraphList.h. Georg
Re: configure failure... (latest CVS) missing file?
Kayvan == Kayvan A Sylvan [EMAIL PROTECTED] writes: Kayvan[...] config.status: creating Kayvan src/frontends/controllers/Makefile config.status: creating Kayvan src/frontends/controllers/tests/Makefile config.status: error: Kayvan cannot find input file: Kayvan src/frontends/controllers/tests/Makefile.in Lars, you have to make up your mind, since it is you who added frontends/tests/ to configure.ac. One of these two fixes should work. The reason nobody noticed is that we already have tests/Makefile.in from earlier runs, I guess. JMarc Index: configure.ac === --- configure.ac (revision 13444) +++ configure.ac (working copy) @@ -457,7 +457,6 @@ src/support/tests/Makefile \ src/frontends/Makefile \ src/frontends/controllers/Makefile \ - src/frontends/controllers/tests/Makefile \ src/frontends/xforms/Makefile \ src/frontends/xforms/lyx_forms.h-tmp:src/frontends/xforms/lyx_forms.h.in \ src/frontends/xforms/lyx_xpm.h-tmp:src/frontends/xforms/lyx_xpm.h.in \ Index: src/frontends/controllers/Makefile.am === --- src/frontends/controllers/Makefile.am (revision 13444) +++ src/frontends/controllers/Makefile.am (working copy) @@ -1,5 +1,7 @@ include $(top_srcdir)/config/common.am +SUBDIRS = tests + EXTRA_DIST = pch.h BCView.tmpl BUILT_SOURCES = $(PCH_FILE)
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico Yes, I have to specify --with-packaging=windows, otherwise I Enrico would get posix. The packaging test in configure is quite Enrico simple. I don't know if it can be changed in the following way Enrico (using some sort of pseudo-code): Well, could you tell me again what cygwin-without-cygwin is good for? I am wary of adding fragile code for this special case. I think that specifying packaging=windows is OK is this case. JMarc
Re: [Qt4 bug] Branches dialog, small issue with alter color
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg While we are at it: Could you please add a 'fileformat' Georg keyword? I'd like to flag bugs that need a file format change, Georg so that they can be easily identified. I did that. JMarc
Re: [Qt4 bug] Branches dialog, small issue with alter color
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg Am Montag, 20. März 2006 14:30 schrieb Abdelrazak Younes: And here is the fix. The problems lies in that the QColor() constructor produces an invalid color (RGB 0,0,0). I am going to commit that for qt4. This bug is also present in qt2 but I am not sure the same fix applies. I have chosen lightskyblue as the default color for a branch. Is it OK? Georg Conceptually the default color should not be defined in the Georg frontend. I think that Branch::getColor() should always return Georg a valid color name. For example the default name could be set Georg in the constructor. If we need a default branch color, it should be a new member of LColor. JMarc
Re: [Qt4 bug] Branches dialog, small issue with alter color
Edwin == Leuven, E [EMAIL PROTECTED] writes: Edwin just wondering about the following (remotely related) issue: Edwin there is now special casing in the qt4 frontend for grey40 etc Edwin perhaps it is cleaner to define the default colors in rgb Edwin values? Yes, it is probably time to get rid of all those named defaults and use RGB instead. I thought xforms used it but it seems it is not true anymore. Also, would it be possible to set the default for things like text background, selection color and related things from the system? Once system_lcolor has been initialized with hardcoded values, we could call a lyx_gui::adapt_colortable(system_lcolor); that would change the defaults according to what the system says. These would just be the default colors. The user is free to customize them. JMarc
Re: LyX 1.4.0 on Windows
Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico my reading of it is that you need the three compilations only Enrico if you want an internationalized iconv program, i.e., if you Enrico want translated messages from iconv. I personally think that Enrico building libiconv with --disable-nls and then LyX with Enrico --with-included-gettext is sufficient. But I may be wrong ;-) That seems very reasonable indeed. JMarc
Re: [Qt4 bug] Branches dialog, small issue with alter color
Jean-Marc Lasgouttes wrote: Georg == Georg Baum [EMAIL PROTECTED] writes: Georg While we are at it: Could you please add a 'fileformat' Georg keyword? I'd like to flag bugs that need a file format change, Georg so that they can be easily identified. I did that. Thanks, I already used it. Georg
Re: LyX 1.4.0 on Windows
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Enrico my reading of it is that you need the three compilations only Enrico if you want an internationalized iconv program, i.e., if you Enrico want translated messages from iconv. I personally think that Enrico building libiconv with --disable-nls and then LyX with Enrico --with-included-gettext is sufficient. But I may be wrong That seems very reasonable indeed. It may seem reasonable, but that's what I did (apart from the --disable-nls bit) and, as I mention, I get garbage instead of Russian or Polish menus. Is the explicit --disable-nls important? Presumably not, since libiconv's configure will work out that it can't see a gettext. Angus
Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
Martin Vermeer wrote: On Fri, 2006-03-17 at 10:27 +, Angus Leeming wrote: Martin Vermeer [EMAIL PROTECTED] writes: you should not be able to accidentally change that file's date stamp (yes, that's the most hateful thing about re-saving unchanged documents -- and no way within the known laws of physics to revert it!) touch -t 200602291200 myfile.lyx ? Or is that a perpetual motion machine? Angus It might as well be if you don't remember what the time stamp was. Better solution would be to have your LyX docs in a version control system. I wonder how many people have. We have it on our site. We are using networking CVS and readonly checkouts. I have distributed locally a patched LyX with two changes: 1. checkOut (cvs edit) has a real implementation 2. checkIn (cvs commit) displays error messages in case of occurance With these modifications we're nearly pleased with LyX+Version Control. One issue is left open: you have to add a file to the repository manually (via cmdline) because of LyX using RCS as default for registrer. Regards, Stephan --
Re: [Qt4 bug] Branches dialog, small issue with alter color
Georg Baum a écrit :
Am Montag, 20. März 2006 14:30 schrieb Abdelrazak Younes:
And here is the fix. The problems lies in that the QColor() constructor
produces an invalid color (RGB 0,0,0). I am going to commit that for
qt4. This bug is also present in qt2 but I am not sure the same fix
applies. I have chosen lightskyblue as the default color for a branch.
Is it OK?
Conceptually the default color should not be defined in the frontend. I
think that Branch::getColor() should always return a valid color name.
For example the default name could be set in the constructor.
Reading BranchList.C, it seems that the default color is none. This
doesn't seems like a valid color reading LColor.C:
bool LColor::setColor(LColor::color col, string const x11name)
{
[...]
// inherit is returned for colors not in the database
// (and anyway should not be redefined)
if (col == none || col == inherit || col == ignore) {
lyxerr Color getLyXName(col)
may not be redefined endl;
return false;
}
By the way, is there a reason why Branch stores a string instead of a
LColor? Seems to me like there are a lot of unnecessary conversion.
Branch does not even have a default constructor... is that on purpose?
Abdel.
Re: [Qt4 bug] Branches dialog, small issue with alter color
Jean-Marc Lasgouttes a écrit : Georg == Georg Baum [EMAIL PROTECTED] writes: Georg Am Montag, 20. März 2006 14:30 schrieb Abdelrazak Younes: And here is the fix. The problems lies in that the QColor() constructor produces an invalid color (RGB 0,0,0). I am going to commit that for qt4. This bug is also present in qt2 but I am not sure the same fix applies. I have chosen lightskyblue as the default color for a branch. Is it OK? Georg Conceptually the default color should not be defined in the Georg frontend. I think that Branch::getColor() should always return Georg a valid color name. For example the default name could be set Georg in the constructor. If we need a default branch color, it should be a new member of LColor. IMHO, we need a minimum of ten different default colors and ten different default names for Branches so that the user only alter these default if he wants to. Something like: branch 1 blue branch 2 red ... Abdel.
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
John If LyX locked files which were open in a still running LyX John process, that would have saved me some confusion. Yes, but I am sure this can cause a lot of confusion too... I am not sure why this would cause confusion. You could have a dialog box warning that Another LyX window has this file open and offer some of the following alternatives: * Do not open. * Open read only. * Open anyway. * Attempt to kill other LyX window. -- John C. McCabe-Dansted Master's Student
Re: [Qt4 bug] Branches dialog, small issue with alter color
Abdelrazak Younes wrote: Reading BranchList.C, it seems that the default color is none. This doesn't seems like a valid color reading LColor.C: The branch color has nothing to do with LColor, AFAIK it is never converted to one. By the way, is there a reason why Branch stores a string instead of a LColor? Yes. It stores the string as #rrggbb in the .lyx file, because a user can choose arbitrary colors, not only the ones that have names in LColor. Seems to me like there are a lot of unnecessary conversion. I am not sure. Maybe it would be better to store it as a numerical rgb triplet? Branch does not even have a default constructor... is that on purpose? I don't know. Georg
Re: [Qt4 bug] Branches dialog, small issue with alter color
Jean-Marc Lasgouttes wrote: If we need a default branch color, it should be a new member of LColor. I had a look at the code, and LColor::background is used for display if a branch has no color. We should make that explicit and set it in the constructor IMHO, then all the checks for a valid color would not be needed anymore. One problem I see with using a LColor for branches is that it is currently possible to use an arbitrary color, specified by r, g, and b. How would we do that with LColor? Adding a new color everytime the user chooses a new branch color? How would we get the rgb values for the existing colors, e.g. LColor::background? Georg
Re: qt4: some colors messed up in preferences dialog
Leuven, E. a écrit : colornames grey40 etc are not recognized by qt4 and end up black in the preferences dialog. i need the attached patch Edwin, I noticed that you didn't commit your patch. I want to do some cleanup that include your patch so I am going to commit the attached patch. Thanks, Abdel. log: - QPrefsDialog::QPrefsDialog(): fix from Edwin Leuven. colorsModule did not recognize colornames grey40, etc. - delete unused variable. Index: QPrefsDialog.C === --- QPrefsDialog.C (revision 13441) +++ QPrefsDialog.C (working copy) @@ -44,6 +44,7 @@ #include gettext.h #include LColor.h +#include lcolorcache.h #include controllers/ControlPrefs.h @@ -168,9 +169,8 @@ || lc == LColor::ignore) continue; colors_.push_back(lc); - string const x11name(lcolor.getX11Name(lc)); string const guiname(lcolor.getGUIName(lc)); - QColorItem * ci(new QColorItem(QColor(toqstr(x11name)), + QColorItem * ci(new QColorItem(lcolorcache.get(lc), toqstr(guiname))); colorsModule-lyxObjectsLB-insertItem(ci); }
Re: Problem with line-breaking in Lyx-Wiki
On Tue, 21 Mar 2006, Ekkehart Schlicht wrote: I just observed that line breaking seems not to work, neither in Firefox nor in Internet Explorer (both under Windows XP). Ekkehart Problem is gone - maybe it was idiosyncratic on my machine (?) Ok... :-) Let me know if something happens again! /C -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: [Qt4 bug] Branches dialog, small issue with alter color
Georg Baum a écrit : Abdelrazak Younes wrote: You are right, it is not. But if the frontend tries to convert it to a QColor it will get an invalid color. That's the reason of my hack which set a default color in the frontend. I know. It's always better to clarify the matter for the archive, isn't it? ;-) Abdel.
Re: [Qt4 bug] Branches dialog, small issue with alter color
Georg Baum a écrit : Abdelrazak Younes wrote: Reading BranchList.C, it seems that the default color is none. This doesn't seems like a valid color reading LColor.C: The branch color has nothing to do with LColor, AFAIK it is never converted to one. You are right, it is not. But if the frontend tries to convert it to a QColor it will get an invalid color. That's the reason of my hack which set a default color in the frontend. By the way, is there a reason why Branch stores a string instead of a LColor? Yes. It stores the string as #rrggbb in the .lyx file, because a user can choose arbitrary colors, not only the ones that have names in LColor. Yes, this string is given by the frontend. I am not sure the other frontends have the same syntax. Seems to me like there are a lot of unnecessary conversion. I am not sure. Maybe it would be better to store it as a numerical rgb triplet? I agree. Abdel.
Re: [Qt4 bug] Branches dialog, small issue with alter color
Abdelrazak Younes [EMAIL PROTECTED] writes: I am not sure. Maybe it would be better to store it as a numerical rgb triplet? I agree. There's an RGBColor class (and an HSVColor one too) in the XForms frontend. Please move 'em someplace useful. Angus
Reproducible segmentation fault (LyX 1.4.0, Mac OS X)
Hello everybody. Thanks for the great work! I really like LyX and it's really feature rich for me at the moment (I really liked the children documents mechanism). Neverthless, I experience some instability and segmentation faults, often when working with math and array environments. I have a reproducible segmentation fault. My platform is Mac OS X and I'm running the latest release, with precompiled binaries. 1. open the attached file segfault.lyx 2. select the second cell of the array 3. delete column The others cells can be deleted without problems. (I'm not subscribed to the list, so please CC me when replying) -- Andrea Censi Web: http://www.dis.uniroma1.it/~censi PGP key #569106B2 available on keyservers. segfault.lyx Description: Binary data
RE: Re: qt4: some colors messed up in preferences dialog
Edwin, I noticed that you didn't commit your patch. I want to do some cleanup that include your patch so I am going to commit the attached patch. sorry for that, but i haven't had the opportunity to commit since my old password doesn't seem to work. (lars is going to reset it, i hope...) thanks for shoving it in. edwin
Re: [Qt4 bug] Branches dialog, small issue with alter color
Abdelrazak Younes wrote: You are right, it is not. But if the frontend tries to convert it to a QColor it will get an invalid color. That's the reason of my hack which set a default color in the frontend. I know. Yes, this string is given by the frontend. I am not sure the other frontends have the same syntax. They do have. It comes originally from X11. Georg
Re: LyX 1.4.0 on Windows
Angus Leeming [EMAIL PROTECTED] writes: Jean-Marc Lasgouttes Jean-Marc.Lasgouttes at ... writes: Enrico my reading of it is that you need the three compilations only Enrico if you want an internationalized iconv program, i.e., if you Enrico want translated messages from iconv. I personally think that Enrico building libiconv with --disable-nls and then LyX with Enrico --with-included-gettext is sufficient. But I may be wrong That seems very reasonable indeed. It may seem reasonable, but that's what I did (apart from the --disable-nls bit) and, as I mention, I get garbage instead of Russian or Polish menus. Is the explicit --disable-nls important? Presumably not, since libiconv's configure will work out that it can't see a gettext. Angus, this is what I do: $ cd libiconv-1.10 $ ./configure CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' CFLAGS='-O2' \ CXXFLAGS='-O2' --enable-static --disable-shared --disable-nls \ --prefix=C:/MinGW $ make $ make install and then I configure LyX with --with-included-gettext. Works for me and I don't get garbage. Please double check the other post where I was talking about LYX_ABS_INSTALLED_LOCALEDIR, this one maybe the culprit. -- Enrico
[Qt4 RFC] QPrefs/QPrefsDialog Reorganisation
Hello, I would like to cut QPrefsDialog into multiple modules. The first step is to transfer everything related to GUI in QPrefs.[Ch] into QPrefsDialog. IMHO, the controller should not know anything about what the Dialog is doing, it is here only to transfer request one way or the other. Second step would be to create one class per module. Each module will inherit a base class. This will make easy to add module in the future. This will make easy also to relocate or to duplicate the module elsewhere. I plan to do the same for QDocument/QDocumentDialog if no one beats me at this. Any strong opinion against this? Abdel.
Re: [Qt4 RFC] QPrefs/QPrefsDialog Reorganisation
Abdelrazak Younes [EMAIL PROTECTED] writes: I would like to cut QPrefsDialog into multiple modules. Second step would be to create one class per module. Sounds like a sane thing to do. Angus
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico Yes, I have to specify --with-packaging=windows, otherwise I Enrico would get posix. The packaging test in configure is quite Enrico simple. I don't know if it can be changed in the following way Enrico (using some sort of pseudo-code): Well, could you tell me again what cygwin-without-cygwin is good for? I am wary of adding fragile code for this special case. I think that specifying packaging=windows is OK is this case. It is good for building a native LyX (not dependent on cygwin) by using cygwin tools only. Jean-Marc, I am not asking to add anything. I thought I was answering a question by Georg. I am fine with the official way of building a native version of LyX. But, as I already have cygwin, I tried and succeeded in building a native LyX with cygwin tools. It can be done, but I do not endorse it because it is much more complicated. I am fine with whatever thing you will do (or not do). -- Enrico
Re: Qt-4, gcc-3.3, Mac OS X: link failure
Bennett Helm a écrit : On Mar 21, 2006, at 3:49 AM, Abdelrazak Younes wrote: Please give me the final linking command as executed by make for Qt3 and Qt4 frontends so we cam compare. We must verify that -lQtCore or -lQtCore4 is there. Here's the beginning of the link stage for the Qt4 frontend: -lQtCore is there. (I'll try to get the one for Qt3 tomorrow) Hum, have you compiled Qt4 yourself or did you use a precompiled package? I remember you said you manage to get an executable once, didn't you? Compiled myself, with ./configure -static. There might be some options as --with-included-libpng or something. I don't know enough about Mac, sorry. You should maybe try to use the precompiled package from TrollTech. (Do you mean a LyX executable? -- No, I've never gotten that far.) My mistake then. Could you please give me the output of : ls /Users/bennett/lyx/gcc-3.3/qt-mac-opensource-src-4.1.1/lib Here it is; I've copied *.la into the bak/ directory. AFAIS, everythings needed is there. Sorry I cannot help more here, Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico It is good for building a native LyX (not dependent on cygwin) Enrico by using cygwin tools only. Enrico Jean-Marc, I am not asking to add anything. I thought I was Enrico answering a question by Georg. I am fine with the official way Enrico of building a native version of LyX. But, as I already have Enrico cygwin, I tried and succeeded in building a native LyX with Enrico cygwin tools. It can be done, but I do not endorse it because Enrico it is much more complicated. I am fine with whatever thing you Enrico will do (or not do). Thanks for the precisions. I think we'll leave it as it it now. JMarc
Re: Qt-4, gcc-3.3, Mac OS X: link failure
On Mar 21, 2006, at 3:49 AM, Abdelrazak Younes wrote: Please give me the final linking command as executed by make for Qt3 and Qt4 frontends so we cam compare. We must verify that - lQtCore or -lQtCore4 is there. Here's the beginning of the link stage for the Qt4 frontend: - lQtCore is there. (I'll try to get the one for Qt3 tomorrow) Hum, have you compiled Qt4 yourself or did you use a precompiled package? I remember you said you manage to get an executable once, didn't you? Compiled myself, with ./configure -static. (Do you mean a LyX executable? -- No, I've never gotten that far.) Could you please give me the output of : ls /Users/bennett/lyx/gcc-3.3/qt-mac-opensource-src-4.1.1/lib Here it is; I've copied *.la into the bak/ directory. -rw-r--r--1 bennett staff 1118 Mar 21 00:13 Qt3Support.pc -rw-r--r--1 bennett staff 1158 Mar 21 00:13 Qt3Support_debug.pc -rw-r--r--1 bennett staff951 Mar 20 22:23 QtCore.pc -rw-r--r--1 bennett staff961 Mar 20 22:23 QtCore_debug.pc -rw-r--r--1 bennett staff 1066 Mar 20 22:24 QtGui.pc -rw-r--r--1 bennett staff 1082 Mar 20 22:24 QtGui_debug.pc -rw-r--r--1 bennett staff 1033 Mar 20 22:24 QtNetwork.pc -rw-r--r--1 bennett staff 1049 Mar 20 22:24 QtNetwork_debug.pc -rw-r--r--1 bennett staff 1122 Mar 20 22:24 QtOpenGL.pc -rw-r--r--1 bennett staff 1144 Mar 20 22:24 QtOpenGL_debug.pc -rw-r--r--1 bennett staff 1017 Mar 20 22:24 QtSql.pc -rw-r--r--1 bennett staff 1033 Mar 20 22:24 QtSql_debug.pc -rw-r--r--1 bennett staff 1078 Mar 21 00:09 QtSvg.pc -rw-r--r--1 bennett staff 1106 Mar 21 00:09 QtSvg_debug.pc -rw-r--r--1 bennett staff927 Mar 20 22:31 QtTest.pc -rw-r--r--1 bennett staff937 Mar 20 22:31 QtTest_debug.pc -rw-r--r--1 bennett staff 1017 Mar 20 22:24 QtXml.pc -rw-r--r--1 bennett staff 1033 Mar 20 22:24 QtXml_debug.pc drwxr-xr-x 20 bennett staff680 Mar 21 09:12 bak -rw-r--r--1 bennett staff6044616 Mar 21 00:38 libQt3Support.a -rw-r--r--1 bennett staff 1050 Mar 21 00:13 libQt3Support.prl -rw-r--r--1 bennett staff 59835040 Mar 21 00:24 libQt3Support_debug.a -rw-r--r--1 bennett staff 1078 Mar 21 00:13 libQt3Support_debug.prl -rw-r--r--1 bennett staff 33720 Mar 21 00:48 libQtAssistantClient.a -rw-r--r--1 bennett staff966 Mar 20 22:24 libQtAssistantClient.prl -rw-r--r--1 bennett staff 390920 Mar 21 00:48 libQtAssistantClient_debug.a -rw-r--r--1 bennett staff982 Mar 20 22:24 libQtAssistantClient_debug.prl -rw-r--r--1 bennett staff2893032 Mar 20 22:55 libQtCore.a -rw-r--r--1 bennett staff889 Mar 20 22:23 libQtCore.prl -rw-r--r--1 bennett staff 22206744 Mar 20 22:48 libQtCore_debug.a -rw-r--r--1 bennett staff887 Mar 20 22:23 libQtCore_debug.prl -rw-r--r--1 bennett staff3309072 Mar 21 01:19 libQtDesigner.a -rw-r--r--1 bennett staff948 Mar 20 22:31 libQtDesigner.prl -rw-r--r--1 bennett staff3136592 Mar 21 01:42 libQtDesignerComponents.a -rw-r--r--1 bennett staff980 Mar 20 22:24 libQtDesignerComponents.prl -rw-r--r--1 bennett staff 73744632 Mar 21 01:31 libQtDesignerComponents_debug.a -rw-r--r--1 bennett staff996 Mar 20 22:24 libQtDesignerComponents_debug.prl -rw-r--r--1 bennett staff 49661680 Mar 21 01:10 libQtDesigner_debug.a -rw-r--r--1 bennett staff964 Mar 20 22:31 libQtDesigner_debug.prl -rw-r--r--1 bennett staff 11243624 Mar 21 00:04 libQtGui.a -rw-r--r--1 bennett staff999 Mar 20 22:24 libQtGui.prl -rw-r--r--1 bennett staff 149992480 Mar 20 23:27 libQtGui_debug.a -rw-r--r--1 bennett staff 1003 Mar 20 22:24 libQtGui_debug.prl -rw-r--r--1 bennett staff 739648 Mar 21 00:09 libQtNetwork.a -rw-r--r--1 bennett staff962 Mar 20 22:24 libQtNetwork.prl -rw-r--r--1 bennett staff5260368 Mar 21 00:07 libQtNetwork_debug.a -rw-r--r--1 bennett staff966 Mar 20 22:24 libQtNetwork_debug.prl -rw-r--r--1 bennett staff 280752 Mar 21 00:13 libQtOpenGL.a -rw-r--r--1 bennett staff 1052 Mar 20 22:24 libQtOpenGL.prl -rw-r--r--1 bennett staff3663192 Mar 21 00:12 libQtOpenGL_debug.a -rw-r--r--1 bennett staff 1062 Mar 20 22:24 libQtOpenGL_debug.prl -rw-r--r--1 bennett staff 496320 Mar 21 00:06 libQtSql.a -rw-r--r--1 bennett staff950 Mar 20 22:24 libQtSql.prl -rw-r--r--1 bennett staff5029232 Mar 21 00:05 libQtSql_debug.a -rw-r--r--1 bennett staff954 Mar 20 22:24 libQtSql_debug.prl -rw-r--r--1 bennett staff 542408 Mar 21 00:11 libQtSvg.a -rw-r--r--1 bennett staff 1011 Mar 21 00:09 libQtSvg.prl -rw-r--r--1 bennett staff5284416 Mar 21
Re: [Qt4 RFC] QPrefs/QPrefsDialog Reorganisation
I aim at something like this yes (are you reading my mind? :-)). While we can minimize the job of creating a module, I don't think a simple configuration file will do for most of the modules. In the use case you are citing perhaps. But one step after the other... We talk about 2007 feature here. Abdel. Charles de Miramon a écrit : Abdelrazak Younes wrote: Maybe, you should take a look at http://www.icefox.net/programs/?program=KAutoConfig I would plead the case for an extensible configuration framework for changing preferences for packages. Ideally a non programmer like me who would want to add support for KomaScript should be able to create a widget in QtDesigner and a configuration file with indications that changing this option in the widget should insert this LateX code in the preamble. Cheers, Charles
Re: [Qt4 RFC] QPrefs/QPrefsDialog Reorganisation
Charles de Miramon [EMAIL PROTECTED] writes: Maybe, you should take a look at http://www.icefox.net/programs/?program=KAutoConfig Nice! Definitely something to investigate. Angus === Does KAutoConfig require KDE? Nope, KAutoConfig comes in two forms. The first form takes advantage of everything in KDE. KAutoConfig will automaticly recognize all of KDE's widgets, set the caption, icon, and uses the KConfig engine. The second form of KAutoConfig links only against Qt and uses QSettings on the back end. This is done by compiling in two replacement classes which extend QSettings and QDialog and provides the needed features that are in KDE while giving the developer source compatibility. Best of all the Qt only library can be used in Windows or Mac development. Compiling the library with or without KDE support is as simple as using the different Makefiles when compiling the library. ===
Re: [Qt4 RFC] QPrefs/QPrefsDialog Reorganisation
Abdelrazak Younes wrote: Maybe, you should take a look at http://www.icefox.net/programs/?program=KAutoConfig I would plead the case for an extensible configuration framework for changing preferences for packages. Ideally a non programmer like me who would want to add support for KomaScript should be able to create a widget in QtDesigner and a configuration file with indications that changing this option in the widget should insert this LateX code in the preamble. Cheers, Charles -- http://www.kde-france.org
Re: LyX 1.4.0 on Windows
Angus Leeming wrote: Do the autotools work for you, or are you just being thorough? I am just thorough :-) Michael
Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)
On Tue, 2006-03-21 at 16:41 +0100, Andrea Censi wrote: Hello everybody. Thanks for the great work! I really like LyX and it's really feature rich for me at the moment (I really liked the children documents mechanism). Neverthless, I experience some instability and segmentation faults, often when working with math and array environments. I have a reproducible segmentation fault. My platform is Mac OS X and I'm running the latest release, with precompiled binaries. 1. open the attached file segfault.lyx 2. select the second cell of the array 3. delete column The others cells can be deleted without problems. (I'm not subscribed to the list, so please CC me when replying) -- Andrea Censi Confirmed on Linux SVN. returning FINISHED_LEFT Assertion triggered in const MathAtom MathArray::operator[](size_t) const by failing check pos size() in file math_data.C:59 Aborted - Martin signature.asc Description: This is a digitally signed message part
Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)
On Tue, 2006-03-21 at 18:01 +0200, Martin Vermeer wrote: On Tue, 2006-03-21 at 16:41 +0100, Andrea Censi wrote: Hello everybody. Thanks for the great work! I really like LyX and it's really feature rich for me at the moment (I really liked the children documents mechanism). Neverthless, I experience some instability and segmentation faults, often when working with math and array environments. I have a reproducible segmentation fault. My platform is Mac OS X and I'm running the latest release, with precompiled binaries. 1. open the attached file segfault.lyx 2. select the second cell of the array 3. delete column The others cells can be deleted without problems. (I'm not subscribed to the list, so please CC me when replying) -- Andrea Censi Confirmed on Linux SVN. returning FINISHED_LEFT Assertion triggered in const MathAtom MathArray::operator[](size_t) const by failing check pos size() in file math_data.C:59 Aborted Okay, it's another case of cur.pos() remaining hanging in mid-air... If you delete the cell in column 2, column 3 becomes the new column 2. If cur.pos() == 4, say, and the cell in column 3 contains only 1 position (as in this case), then obviously pos size will assert. We have to reset cur.pos() to zero in this case. - Martin signature.asc Description: This is a digitally signed message part
Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)
On Tue, 2006-03-21 at 18:14 +0200, Martin Vermeer wrote:
On Tue, 2006-03-21 at 18:01 +0200, Martin Vermeer wrote:
On Tue, 2006-03-21 at 16:41 +0100, Andrea Censi wrote:
...
Confirmed on Linux SVN.
returning FINISHED_LEFT
Assertion triggered in const MathAtom MathArray::operator[](size_t)
const by failing check pos size() in file math_data.C:59
Aborted
Okay, it's another case of cur.pos() remaining hanging in mid-air...
If you delete the cell in column 2, column 3 becomes the new column 2.
If cur.pos() == 4, say, and the cell in column 3 contains only 1
position (as in this case), then obviously pos size will assert.
We have to reset cur.pos() to zero in this case.
Here's the patch. Trivial (Georg, how did we overlook this?)
OK to put into both trunk and 1.4?
- Martin
Index: math_gridinset.C
===
--- math_gridinset.C (revision 13408)
+++ math_gridinset.C (working copy)
@@ -1131,12 +1131,14 @@ void MathGridInset::doDispatch(LCursor
else if (s == append-row)
for (int i = 0, n = extractInt(is); i n; ++i)
addRow(cur.row());
- else if (s == delete-row)
+ else if (s == delete-row) {
for (int i = 0, n = extractInt(is); i n; ++i) {
delRow(cur.row());
if (cur.idx() nargs())
cur.idx() -= ncols();
}
+ cur.pos() = 0; // trick, see below
+ }
else if (s == copy-row) {
// Here (as later) we save the cursor col/row
// in order to restore it after operation.
@@ -1173,6 +1175,7 @@ void MathGridInset::doDispatch(LCursor
for (int i = 0, n = extractInt(is); i n; ++i)
delCol(col(cur.idx()));
cur.idx() = index(r, min(c, cur.ncols() - 1));
+ cur.pos() = 0; // trick, see above
}
else if (s == copy-column) {
row_type const r = cur.row();
signature.asc
Description: This is a digitally signed message part
Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)
Am Dienstag, 21. März 2006 17:29 schrieb Martin Vermeer: Here's the patch. Trivial (Georg, how did we overlook this?) We must have been sleeping :-( Georg
Re: [patch] remove qt2 support
Am Samstag, 18. März 2006 14:22 schrieb Georg Baum: Am Freitag, 17. März 2006 21:42 schrieb Leuven, E.: if qt2 goes, the attached should go (in) as well i think (i.e. remove qgridview.[Ch]) You are right. I did not know that we had these classes! The full patch would look like the attached. Dou you have commit privileges now, or should I commit it for you? I removed qgridview.[Ch] now. Georg
Re: line endings again
Am Montag, 20. März 2006 22:39 schrieb Lars Gullik Bjønnes: set svn:eol-style native on the files IMHO. I did this now. Georg
Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
On Tue, Mar 21, 2006 at 10:55:15AM +0100, Stephan Witt wrote: Better solution would be to have your LyX docs in a version control system. I wonder how many people have. We have it on our site. We are using networking CVS and readonly checkouts. I have distributed locally a patched LyX with two changes: 1. checkOut (cvs edit) has a real implementation 2. checkIn (cvs commit) displays error messages in case of occurance With these modifications we're nearly pleased with LyX+Version Control. One issue is left open: you have to add a file to the repository manually (via cmdline) because of LyX using RCS as default for registrer. I wonder whether the version control stuff should really be handled within LyX. Andre'
Re: qt4: some colors messed up in preferences dialog
On Mon, Mar 20, 2006 at 11:40:23AM +0100, Abdelrazak Younes wrote: -QColorItem * ci(new QColorItem(QColor(toqstr(x11name)), +QColorItem * ci(new QColorItem(lcolorcache.get(lc), toqstr(guiname))); QColorItem * ci = new QColorItem(lcolorcache.get(lc), toqstr(guiname)); Or maybe QColorItem * ci = new QColorItem(lcolorcache.get(lc), toqstr(guiname)); or maybe QColorItem * ci = new QColorItem(lcolorcache.get(lc), toqstr(guiname)); but no function style initializer if it's avoidable at no cost. Please. Andre' --
Re: LyX/Win 1.4.1 pre1
On Mon, Mar 20, 2006 at 11:03:52AM +, Angus Leeming wrote: Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Angus Anyway. Whatever. I find that the whole discussion is something Angus of a storm in a tea cup. Sorry for feeling a bit bruised. You should make sure you do not keep your tea cup too close to yourself. If a storm happens to start in there, there is indeed a big risk of getting burnt ;) Burnt and liquids just sounds wrong. You should use scalded. Ah... I was about to fetch my dictionary. Andre'
Re: line endings again
On Mon, Mar 20, 2006 at 05:41:09PM +, Angus Leeming wrote: Georg Baum [EMAIL PROTECTED] writes: Lars, what are we going to do? Currently Abdel keeps putting in more and more files with mixed line endings. This should be stopped as soon as possible. I can do the eol-style conversion if we are going to use that. Otherwise, please install the precommit-hook. Why not make the precommit-hook something like: sed 's/\r$//' orig.diff unix_line_endings.diff There's no real reason to beat the developers up over something that can be fixed automatically. Modifing committed data is frowned upon on the svn lists because it makes the client believe it has a 1:1 copy of the (afterwards modified) server data while it hasn't. However, my own experiments with such did not show exceptionally bad behaviour, so I personally would not mind such a measure. Andre'
Re: LyX/Win 1.4.1 pre1
On Mon, Mar 20, 2006 at 12:13:24PM +0100, Jean-Marc Lasgouttes wrote: Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Burnt and liquids just sounds wrong. You should use Angus scalded. I have to admit I have never seen this word. Do people really use it in normal discussion? I guess they abonded the habit of scalding people during normal discussions a few years ago. Andre'
Re: [Ãpatch ] RandomAccessList take 4
On Mon, Mar 20, 2006 at 09:25:09AM +0100, Abdelrazak Younes wrote: Funny that you are doing the exact same changes as my original patch fixing the code to use std::distance and std::advance (in this case boost::next). You rejected my patch exactly because of this... I am not upset but you could have told me at the beginning instead of letting me wasting my time. That's the so-called 'Not invented here' syndrom. It's pretty common in the industry. The best thing to cope with that is to make the decision makers believe that the idea you actually want to push was their idea from the beginning. Concerning the direct access if you want to continue this way, for sure, list::iterator must be replaced if you want speed. With direct access where it make sense, you would have gained much speed. Right now you still have a lot of direct access all over the code, are you going to fix that? I guess we'll end up with a beautiful version using latest technology which won't fix the original problem (speed) but would look much nicer than any pragmatic and working solution. Andre' PS: Things will get better as soon as people got used to the idea of you committing stuff without much asking. It could be even fun then.
INSTALL.Win32
Dear Angus, I give up! I spent the whole evening on building a shared qtwin library. No chance! Compilation always stopped with an internal compiler error! I tried various options (-no-exceptions -no-rtti -no-pch). Always the same result: Linking the shared library takes endlessly (really!) and then compilation aborts eventually (which is bad because we need the qt tools as well). Enclosed please find my latest version of INSTALL.Win32. Actually, I have no idea on how to proceed. If the shared qtwin lib works on your machine, I am tempted to commit the file (the current version is totally outdated). Note that Aspell 0.60.4 requires yet another patch to work with gettext 0.14.5! Unfortunately, it seems that I have to stick with static linking personally :-( Michael = INSTALL for Win32 = LyX can be built with either MinGW/MSYS or Microsoft Visual Studio. The instructions below describe the detailed steps needed to set up a MinGW/MSYS environment ready to compile LyX. Several of these steps (installation of the qtwin and aspell libraries) need to be performed for a MSVS build also but, of course, the details of how to do so are different. Nonetheless, we hope that the description below provides the MSVS developer with enough info to get started. Building LyX the first time can appear to be a daunting task but much of that is knowing which packages to download in the first place. Once you've set up the build environment, actually building LyX should be straightforward. The instructions below should guide you through the installation of the MinGW/MSYS build environment, together with details on how to grab and build gettext, libiconv, qtwin, and aspell. Once you've done all that, you should go read the README in development/Win32/packaging/ (MSVS users just open up development/Win32/lyx.sln and click Build) The two scripts in the same directory, build_lyxwin.sh and package_lyxwin.sh should automate the entire build process. If not and you really can't figure out what to do next, then please, please drop a mail to [EMAIL PROTECTED] Enjoy! The LyX Team = 1 MinGW MSYS 1.1 Download the following packages from http://www.mingw.org/download.shtml: binutils-2.16.91-...tar.gz gcc-core-3.4.5-...tar.gz gcc-g++-3.4.5-...tar.gz mingw32-make-3.80.0-3.tar.gz mingw-runtime-3.9.tar.gz mingw-utils-0.3.tar.gz MSYS-1.0.11-...exe msys-autoconf-2.59.tar.bz2 msys-automake-1.8.2.tar.bz2 msysDTK-1.0.1.exe msys-libtool-1.5.tar.bz2 w32api-3.6.tar.gz 1.2 Install in C:\MinGW binutils, gcc-core, gcc-g++, mingw32-make, mingw-runtime, mingw-utils, w32api 1.3 Install in C:\msys MSYS, msys-autoconf, msys-automake, msysDTK, msys-libtool 2 Gettext 2.1 Download the following package from http://www.gnu.org/software/gettext: gettext-0.14.5.tar.gz 2.2 Extract the package in your home directory and run ./configure --disable-shared --prefix=/mingw make make install 3 Libiconv 3.1 Download the following package from http://www.gnu.org/software/libiconv: libiconv-1.10.tar.gz 3.2 Extract the package in your home directory and run ./configure --prefix=/mingw make make install 4 QTWIN (see http://sourceforge.net/projects/qtwin) 4.1 Get the latest CVS version Using the cvs executable that is packaged with MSYS, from the MSYS command prompt: cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/qtwin login return (i.e., no password) cvs -z3 -d :pserver:[EMAIL PROTECTED]:/cvsroot/qtwin co \ -r QT_WIN32_3_3_BRANCH qt-3 4.2 Compile the qtwin library Open a Windows command line (run cmd.exe) and enter cd path_to_your_qtwin_dir set QMAKESPEC=win32-g++ setenv.bat configure.bat 5. Aspell 5.1 Download the following package from http://aspell.net/ aspell-0.60.4.tar.gz 5.2 Extract the package in your home directory. Use development/Win32/packaging/build_aspell.sh to build Aspell now. 5.3 You can download pre-compiled aspell dictionaries from http://wiki.lyx.org/Windows/Aspell6 6. LyX 6.1 As mentioned above, read the README in development/Win32/packaging. =
Re: [Qt4 bug] Branches dialog, small issue with alter color
Am Dienstag, 21. März 2006 14:12 schrieb Angus Leeming:
There's an RGBColor class (and an HSVColor one too) in the XForms
frontend.
Please move 'em someplace useful.
Nice, I stumbled about RGBColor but thought it was an xforms thing.
The attached patch moves these classes to the core, and changes Branch to
store a RGBColor instead of a string. The consequence is that a branch
cannot have a none color anymore, and therefore some checks in the
frontend are not necessary anymore. LColor::background is used now
instead of none. This is consistent with the current display of
branches with none color.
What do you think?
Georg
Index: src/BranchList.C
===
--- src/BranchList.C (Revision 13447)
+++ src/BranchList.C (Arbeitskopie)
@@ -11,11 +11,19 @@
#include config.h
#include BranchList.h
+#include LColor.h
+#include frontends/lyx_gui.h
#include algorithm
using std::string;
+Branch::Branch()
+{
+ lyx_gui::getRGBColor(LColor::background, color_);
+}
+
+
string const Branch::getBranch() const
{
return branch_;
@@ -43,18 +52,28 @@ bool Branch::setSelected(bool b)
}
-string const Branch::getColor() const
+lyx::RGBColor const Branch::getColor() const
{
return color_;
}
-void Branch::setColor(string const c)
+void Branch::setColor(lyx::RGBColor const c)
{
color_ = c;
}
+void Branch::setColor(string const c)
+{
+ if (c.size() == 7 c[0] == '#')
+ color_ = lyx::RGBColor(c);
+ else
+ // no color set or invalid color - use normal background
+ lyx_gui::getRGBColor(LColor::background, color_);
+}
+
+
Branch * BranchList::find(std::string const name)
{
List::iterator it =
@@ -91,7 +110,6 @@ bool BranchList::add(string const s)
Branch br;
br.setBranch(name);
br.setSelected(false);
- br.setColor(none);
list.push_back(br);
}
if (j == string::npos)
Index: src/BranchList.h
===
--- src/BranchList.h (Revision 13447)
+++ src/BranchList.h (Arbeitskopie)
@@ -30,6 +30,8 @@
#ifndef BRANCHES_H
#define BRANCHES_H
+#include Color.h
+
#include string
#include list
@@ -37,6 +39,8 @@
class Branch {
public:
///
+ Branch();
+ ///
std::string const getBranch() const;
///
void setBranch(std::string const );
@@ -47,8 +51,11 @@ public:
*/
bool setSelected(bool);
///
- std::string const getColor() const;
+ lyx::RGBColor const getColor() const;
///
+ void setColor(lyx::RGBColor const );
+ /// Set color from a string #rrggbb.
+ /// Use LColor:background if the string is no valid color.
void setColor(std::string const );
@@ -58,7 +65,7 @@ private:
///
bool selected_;
///
- std::string color_;
+ lyx::RGBColor color_;
};
Index: src/Color.C
===
--- src/Color.C (Revision 13447)
+++ src/Color.C (Arbeitskopie)
@@ -12,8 +12,6 @@
#include Color.h
-#include lyx_forms.h
-
#include LColor.h
#include cmath
@@ -33,7 +31,6 @@ using std::ostringstream;
using std::string;
namespace lyx {
-namespace frontend {
namespace {
@@ -51,28 +48,6 @@ int hexstrToInt(string const str)
-bool getRGBColor(LColor_color col,
- unsigned int r, unsigned int g, unsigned int b)
-{
- string const name = lcolor.getX11Name(col);
- Display * const display = fl_get_display();
- Colormap const cmap = fl_state[fl_get_vclass()].colormap;
- XColor xcol, ccol;
-
- if (XLookupColor(display, cmap, name.c_str(), xcol, ccol) == 0) {
- r = 0;
- g = 0;
- b = 0;
- return false;
- }
-
- r = xcol.red / 256;
- g = xcol.green / 256;
- b = xcol.blue / 256;
- return true;
-}
-
-
string const X11hexname(RGBColor const col)
{
ostringstream ostr;
@@ -199,5 +174,4 @@ HSVColor::HSVColor(RGBColor const rgb)
}
}
-} // namespace frontend
} // namespace lyx
Index: src/Color.h
===
--- src/Color.h (Revision 13447)
+++ src/Color.h (Arbeitskopie)
@@ -18,16 +18,7 @@
#include string
-class LColor_color;
-
namespace lyx {
-namespace frontend {
-
-/** Given col, fills r, g, b in the range 0-255.
-The function returns true if successful.
-It returns false on failure and sets r, g, b to 0. */
-bool getRGBColor(LColor_color col,
- unsigned int r, unsigned int g, unsigned int b);
struct RGBColor;
/// returns a string of form #rrggbb, given an RGBColor struct
@@ -78,7 +69,6 @@ bool operator!=(RGBColor const c1, RGB
return !(c1 == c2);
}
-} // namespace frontend
} // namespace lyx
#endif
Index: src/frontends/gtk/lyx_gui.C
===
--- src/frontends/gtk/lyx_gui.C (Revision 13447)
+++ src/frontends/gtk/lyx_gui.C (Arbeitskopie)
@@ -26,6 +26,7 @@
#include funcrequest.h
#include gettext.h
+#include Color.h
#include LColor.h
#include LyXAction.h
#include lyx_main.h
@@ -175,23 +176,44 @@ FuncStatus
Re: LyX/Win 1.4.1 pre1
Andre Poenitz [EMAIL PROTECTED] writes: I guess they abonded the habit of scalding people during normal discussions a few years ago. LOL! A
Re: [Qt4 bug] Branches dialog, small issue with alter color
Georg Baum [EMAIL PROTECTED] writes: Am Dienstag, 21. März 2006 14:12 schrieb Angus Leeming: There's an RGBColor class (and an HSVColor one too) in the XForms frontend. Please move 'em someplace useful. Nice, I stumbled about RGBColor but thought it was an xforms thing. The attached patch moves these classes to the core, ... What do you think? I think that you've been busy ;-) The patch looks good. One side effect of it is that you can now get rid of those lcolors for the top and bottom edges of the inset buttons. It's now trivial to define these as button background +- a HSV.hue of 10%. Regards, Angus
Re: qt4: some colors messed up in preferences dialog
Andre Poenitz a écrit : On Mon, Mar 20, 2006 at 11:40:23AM +0100, Abdelrazak Younes wrote: - QColorItem * ci(new QColorItem(QColor(toqstr(x11name)), + QColorItem * ci(new QColorItem(lcolorcache.get(lc), toqstr(guiname))); QColorItem * ci = new QColorItem(lcolorcache.get(lc), toqstr(guiname)); Or maybe QColorItem * ci = new QColorItem(lcolorcache.get(lc), toqstr(guiname)); or maybe QColorItem * ci = new QColorItem(lcolorcache.get(lc), toqstr(guiname)); but no function style initializer if it's avoidable at no cost. You're right but it's not my code, just kidding Edwin ;-). I will cleanup this once we decide what to do with Georg's patch. Abdel.
Re: [Qt4 bug] Branches dialog, small issue with alter color
Georg Baum a écrit : Am Dienstag, 21. März 2006 14:12 schrieb Angus Leeming: There's an RGBColor class (and an HSVColor one too) in the XForms frontend. Please move 'em someplace useful. Nice, I stumbled about RGBColor but thought it was an xforms thing. The attached patch moves these classes to the core, and changes Branch to store a RGBColor instead of a string. The consequence is that a branch cannot have a none color anymore, and therefore some checks in the frontend are not necessary anymore. LColor::background is used now instead of none. This is consistent with the current display of branches with none color. What do you think? The patch looks good but I am wondering if this solution is not a bit too complicated. Why not just define some const string in hexa and let the frontend take care of the rest? Abdel.
Re: line endings again
Georg Baum a écrit : Am Montag, 20. März 2006 22:39 schrieb Lars Gullik Bjønnes: set svn:eol-style native on the files IMHO. I did this now. What does this mean in practice? Now that I use Xemacs will I see ^M at each end-of-line because I checkout from windows? And why only the qt4 frontend? I have cleanup everything already and promised to use Xemacs, wasn't that enough? I would to continue working with Unix-style line ending. Abdel.
Re: [Cvslog] r13434 - in /lyx-devel/trunk/src: bufferlist.C client/cli...
[EMAIL PROTECTED] wrote: Log: replace hard-coded /tmp with package().temp_dir() Modified: lyx-devel/trunk/src/bufferlist.C lyx-devel/trunk/src/client/client.C lyx-devel/trunk/src/lyxrc.C Shouldn't this go into BRANCH_1_4_X as well? Michael
[Fwd: Your Amazon.com Inquiry]
Could someone please fix this? I often receive this kind of mail when I post to lyx-devel. Abdel. ---BeginMessage--- Greetings from Amazon.com. We're sorry. You've written to an address that cannot accept incoming e-mail. But that's OK--this automated response will direct you to the right place at Amazon.com to answer your question or help you contact customer service if you need further assistance. You will find the answers to the most common questions here: Where's My Stuff: http://www.amazon.com/help/wheres-my-stuff Canceling or Changing Orders: http://www.amazon.com/o/tg/browse/-/595034/ Problem with an Item: http://www.amazon.com/o/tg/browse/-/557204/ Marketplace Order Problems: http://www.amazon.com/o/tg/browse/-/537868/ Gift Certificates: http://www.amazon.com/o/tg/browse/-/518226 Returns Refunds: http://www.amazon.com/returns If you need to modify an unshipped order or make changes to your account or subscriptions, you may do so online at any time via Your Account: http://www.amazon.com/your-account If your question is not answered by the above links, we invite you to search our Help Desk at http://www.amazon.com/help We hope our online resources meet all your needs. If you've explored the above links but find you still need to get in touch with us, please click the Contact Customer Service link on our main Help page. Thanks for shopping at Amazon.com. Sincerely, Amazon.com Customer Service http://www.amazon.com P.S. You received this message because Amazon.com received the following message: Date: Tue, 21 Mar 2006 23:21:20 +0100 From: Abdelrazak Younes [EMAIL PROTECTED] To: lyx-devel@lists.lyx.org Subject: Re: qt4: some colors messed up in preferences dialog Andre Poenitz a crit : On Mon, Mar 20, 2006 at 11:40:23AM +0100, Abdelrazak Younes wrote: - QColorItem * ci(new QColorItem(QColor(toqstr(x11name)), + QColorItem * ci(new QColorItem(lcolorcache.get(lc), toqstr(guiname))); QColorItem * ci = new QColorItem(lcolorcache.get(lc), toqstr(guiname)); Or maybe QColorItem * ci = new QColorItem(lcolorcache.get(lc), toqstr(guiname)); or maybe QColorItem * ci = new QColorItem(lcolorcache.get(lc), toqstr(guiname)); but no function style initializer if it's avoidable at no cost. You're right but it's not my code, just kidding Edwin ;-). I will cleanup this once we decide what to do with Georg's patch. Abdel. ---End Message---
Re: [Qt4 bug] Branches dialog, small issue with alter color
Abdelrazak Younes a écrit :
Georg Baum a écrit :
Am Dienstag, 21. März 2006 14:12 schrieb Angus Leeming:
There's an RGBColor class (and an HSVColor one too) in the XForms
frontend.
Please move 'em someplace useful.
Nice, I stumbled about RGBColor but thought it was an xforms thing.
The attached patch moves these classes to the core, and changes Branch
to store a RGBColor instead of a string. The consequence is that a
branch cannot have a none color anymore, and therefore some checks
in the frontend are not necessary anymore. LColor::background is used
now instead of none. This is consistent with the current display of
branches with none color.
What do you think?
The patch looks good but I am wondering if this solution is not a bit
too complicated. Why not just define some const string in hexa and let
the frontend take care of the rest?
Just for clarification, this would mean replacing x11name by this RGB
value in ColorEntry:
class ColorEntry {
ColorEntry(
string rgb_hexa = #00,
string const guiname_ = ,
string const latexname_ = ,
string const lyxname_ = );
string const get_rbg() const;
void set_rbg(string const rgb_hexa);
private:
string rgb_;
string const guiname_;
string const latexname_;
string const lyxname_;
};
The LColor::color type could be used as an index for a
std::vectorColorEntry
Abdel.
Re: [Qt4 bug] Branches dialog, small issue with alter color
Abdelrazak Younes [EMAIL PROTECTED] writes:
The patch looks good but I am wondering if this solution is not a bit
too complicated. Why not just define some const string in hexa and let
the frontend take care of the rest?
Just for clarification, this would mean replacing x11name by this RGB
value in ColorEntry:
class ColorEntry {
ColorEntry(
string rgb_hexa = #00,
string const guiname_ = ,
string const latexname_ = ,
string const lyxname_ = );
Georg's solution may look complicated, but it's just a refactoring of existing,
working code. A real RGBColor class has real advantages, not least being type
safe. We (you :)) should strive to remove kludges, not add to them!
Further, a real Color lends itself to easy manipulation; the fact that we have
to separately define the colours of inset button and borders is a real ugliness!
À demain!
Angus
Re: LyX/Win 1.4.1 pre1
[EMAIL PROTECTED] wrote: > On Mon, 20 Mar 2006, Jean-Marc Lasgouttes wrote: > >> > "Jose'" == Jose' Matos <[EMAIL PROTECTED]> >> > writes: >> >> Jose'> On Monday 20 March 2006 11:13, Jean-Marc Lasgouttes wrote: >> >> I have to admit I have never seen this word. Do people really use >> >> it in normal discussion? >> >> Jose'> Don't you have this word (or similar) in French? >> >> Jose'> This comes from Latin, we have it in Portuguese. >> Yes, from excalesco, is, ere A late latin verb meaning as you have guessed 'getting hot' I think we have a nickname for LyX 1.5.1 Cheers, Charles -- http://www.kde-france.org
Re: Qt-4, gcc-3.3, Mac OS X: link failure
Bennett Helm a écrit : On Mar 20, 2006, at 5:33 PM, Abdelrazak Younes wrote: Bennett Helm a écrit : I've been trying now to compile lyx with the Qt-4 frontend and gcc-3.3, and I get the following at the final link stage. Any suggestions? Hello Bennet, QUrl is defined in libQtCore or libQtCore4 depending on your Qt4 packaging. I think png* is defined in libpng. All the rest should be MacOS specific stuff. On Windows this kind of library are statically linked into QtCore, so curing the first problem might also cure this one. Please give me the final linking command as executed by make for Qt3 and Qt4 frontends so we cam compare. We must verify that -lQtCore or -lQtCore4 is there. Here's the beginning of the link stage for the Qt4 frontend: -lQtCore is there. (I'll try to get the one for Qt3 tomorrow) Hum, have you compiled Qt4 yourself or did you use a precompiled package? I remember you said you manage to get an executable once, didn't you? Could you please give me the output of : ls /Users/bennett/lyx/gcc-3.3/qt-mac-opensource-src-4.1.1/lib Thanks, Abdel.
Re: [Ãpatch] RandomAccessList take 4
Lars Gullik Bjønnes wrote: > Georg Baum <[EMAIL PROTECTED]> > writes: > > | The problem were missing conversions of > | > | pars.begin() + x > | > | to > | > | boost::next(pars.begin(), x) > > Where were they missing? In some cut and paste code that does no longer exist in 1.5. BTW my patch is missing the new file src/ParagraphList.h. Georg
Re: configure failure... (latest CVS) missing file?
> "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes: Kayvan>[...] config.status: creating Kayvan> src/frontends/controllers/Makefile config.status: creating Kayvan> src/frontends/controllers/tests/Makefile config.status: error: Kayvan> cannot find input file: Kayvan> src/frontends/controllers/tests/Makefile.in Lars, you have to make up your mind, since it is you who added frontends/tests/ to configure.ac. One of these two fixes should work. The reason nobody noticed is that we already have tests/Makefile.in from earlier runs, I guess. JMarc Index: configure.ac === --- configure.ac (revision 13444) +++ configure.ac (working copy) @@ -457,7 +457,6 @@ src/support/tests/Makefile \ src/frontends/Makefile \ src/frontends/controllers/Makefile \ - src/frontends/controllers/tests/Makefile \ src/frontends/xforms/Makefile \ src/frontends/xforms/lyx_forms.h-tmp:src/frontends/xforms/lyx_forms.h.in \ src/frontends/xforms/lyx_xpm.h-tmp:src/frontends/xforms/lyx_xpm.h.in \ Index: src/frontends/controllers/Makefile.am === --- src/frontends/controllers/Makefile.am (revision 13444) +++ src/frontends/controllers/Makefile.am (working copy) @@ -1,5 +1,7 @@ include $(top_srcdir)/config/common.am +SUBDIRS = tests + EXTRA_DIST = pch.h BCView.tmpl BUILT_SOURCES = $(PCH_FILE)
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> Yes, I have to specify --with-packaging=windows, otherwise I Enrico> would get posix. The packaging test in configure is quite Enrico> simple. I don't know if it can be changed in the following way Enrico> (using some sort of pseudo-code): Well, could you tell me again what cygwin-without-cygwin is good for? I am wary of adding fragile code for this special case. I think that specifying packaging=windows is OK is this case. JMarc
Re: [Qt4 bug] Branches dialog, small issue with "alter color"
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> While we are at it: Could you please add a 'fileformat' Georg> keyword? I'd like to flag bugs that need a file format change, Georg> so that they can be easily identified. I did that. JMarc
Re: [Qt4 bug] Branches dialog, small issue with "alter color"
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> Am Montag, 20. März 2006 14:30 schrieb Abdelrazak Younes: >> And here is the fix. The problems lies in that the QColor() >> constructor produces an invalid color (RGB 0,0,0). I am going to >> commit that for qt4. This bug is also present in qt2 but I am not >> sure the same fix applies. I have chosen "lightskyblue" as the >> default color for a branch. Is it OK? Georg> Conceptually the default color should not be defined in the Georg> frontend. I think that Branch::getColor() should always return Georg> a valid color name. For example the default name could be set Georg> in the constructor. If we need a default branch color, it should be a new member of LColor. JMarc
Re: [Qt4 bug] Branches dialog, small issue with "alter color"
> "Edwin" == Leuven, E <[EMAIL PROTECTED]> writes: Edwin> just wondering about the following (remotely related) issue: Edwin> there is now special casing in the qt4 frontend for grey40 etc Edwin> perhaps it is cleaner to define the default colors in rgb Edwin> values? Yes, it is probably time to get rid of all those named defaults and use RGB instead. I thought xforms used it but it seems it is not true anymore. Also, would it be possible to set the default for things like text background, selection color and related things from the system? Once system_lcolor has been initialized with hardcoded values, we could call a lyx_gui::adapt_colortable(system_lcolor); that would change the defaults according to what the system says. These would just be the default colors. The user is free to customize them. JMarc
Re: LyX 1.4.0 on Windows
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> my reading of it is that you need the three compilations only Enrico> if you want an internationalized iconv program, i.e., if you Enrico> want translated messages from iconv. I personally think that Enrico> building libiconv with --disable-nls and then LyX with Enrico> --with-included-gettext is sufficient. But I may be wrong ;-) That seems very reasonable indeed. JMarc
Re: [Qt4 bug] Branches dialog, small issue with "alter color"
Jean-Marc Lasgouttes wrote: >> "Georg" == Georg Baum >> <[EMAIL PROTECTED]> >> writes: > > Georg> While we are at it: Could you please add a 'fileformat' > Georg> keyword? I'd like to flag bugs that need a file format change, > Georg> so that they can be easily identified. > > I did that. Thanks, I already used it. Georg
Re: LyX 1.4.0 on Windows
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > Enrico> my reading of it is that you need the three compilations only > Enrico> if you want an internationalized iconv program, i.e., if you > Enrico> want translated messages from iconv. I personally think that > Enrico> building libiconv with --disable-nls and then LyX with > Enrico> --with-included-gettext is sufficient. But I may be wrong > That seems very reasonable indeed. It may seem "reasonable", but that's what I did (apart from the --disable-nls bit) and, as I mention, I get garbage instead of Russian or Polish menus. Is the explicit --disable-nls important? Presumably not, since libiconv's configure will work out that it can't see a gettext. Angus
Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
Martin Vermeer wrote: On Fri, 2006-03-17 at 10:27 +, Angus Leeming wrote: Martin Vermeer <[EMAIL PROTECTED]> writes: you should not be able to accidentally change that file's date stamp (yes, that's the most hateful thing about re-saving "unchanged" documents -- and no way within the known laws of physics to revert it!) touch -t 200602291200 myfile.lyx ? Or is that a perpetual motion machine? Angus It might as well be if you don't remember what the time stamp was. Better solution would be to have your LyX docs in a version control system. I wonder how many people have. We have it on our site. We are using networking CVS and readonly checkouts. I have distributed locally a patched LyX with two changes: 1. checkOut (cvs edit) has a real implementation 2. checkIn (cvs commit) displays error messages in case of occurance With these modifications we're nearly pleased with LyX+Version Control. One issue is left open: you have to add a file to the repository manually (via cmdline) because of LyX using RCS as default for registrer. Regards, Stephan --
Re: [Qt4 bug] Branches dialog, small issue with "alter color"
Georg Baum a écrit :
Am Montag, 20. März 2006 14:30 schrieb Abdelrazak Younes:
And here is the fix. The problems lies in that the QColor() constructor
produces an invalid color (RGB 0,0,0). I am going to commit that for
qt4. This bug is also present in qt2 but I am not sure the same fix
applies. I have chosen "lightskyblue" as the default color for a branch.
Is it OK?
Conceptually the default color should not be defined in the frontend. I
think that Branch::getColor() should always return a valid color name.
For example the default name could be set in the constructor.
Reading BranchList.C, it seems that the default color is "none". This
doesn't seems like a valid color reading LColor.C:
bool LColor::setColor(LColor::color col, string const & x11name)
{
[...]
// "inherit" is returned for colors not in the database
// (and anyway should not be redefined)
if (col == none || col == inherit || col == ignore) {
lyxerr << "Color " << getLyXName(col)
<< " may not be redefined" << endl;
return false;
}
By the way, is there a reason why Branch stores a string instead of a
LColor? Seems to me like there are a lot of unnecessary conversion.
Branch does not even have a default constructor... is that on purpose?
Abdel.
Re: [Qt4 bug] Branches dialog, small issue with "alter color"
Jean-Marc Lasgouttes a écrit : "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> Am Montag, 20. März 2006 14:30 schrieb Abdelrazak Younes: And here is the fix. The problems lies in that the QColor() constructor produces an invalid color (RGB 0,0,0). I am going to commit that for qt4. This bug is also present in qt2 but I am not sure the same fix applies. I have chosen "lightskyblue" as the default color for a branch. Is it OK? Georg> Conceptually the default color should not be defined in the Georg> frontend. I think that Branch::getColor() should always return Georg> a valid color name. For example the default name could be set Georg> in the constructor. If we need a default branch color, it should be a new member of LColor. IMHO, we need a minimum of ten different default colors and ten different default names for Branches so that the user only alter these default if he wants to. Something like: branch 1 blue branch 2 red ... Abdel.
Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents
> John> If LyX locked files which were open in a still running LyX > John> process, that would have saved me some confusion. > > Yes, but I am sure this can cause a lot of confusion too... I am not sure why this would cause confusion. You could have a dialog box warning that "Another LyX window has this file open" and offer some of the following alternatives: * Do not open. * Open read only. * Open anyway. * Attempt to kill other LyX window. -- John C. McCabe-Dansted Master's Student
Re: [Qt4 bug] Branches dialog, small issue with "alter color"
Abdelrazak Younes wrote: > Reading BranchList.C, it seems that the default color is "none". This > doesn't seems like a valid color reading LColor.C: The branch color has nothing to do with LColor, AFAIK it is never converted to one. > By the way, is there a reason why Branch stores a string instead of a > LColor? Yes. It stores the string as "#rrggbb" in the .lyx file, because a user can choose arbitrary colors, not only the ones that have names in LColor. > Seems to me like there are a lot of unnecessary conversion. I am not sure. Maybe it would be better to store it as a numerical rgb triplet? > Branch does not even have a default constructor... is that on purpose? I don't know. Georg
Re: [Qt4 bug] Branches dialog, small issue with "alter color"
Jean-Marc Lasgouttes wrote: > If we need a default branch color, it should be a new member of > LColor. I had a look at the code, and LColor::background is used for display if a branch has no color. We should make that explicit and set it in the constructor IMHO, then all the checks for a valid color would not be needed anymore. One problem I see with using a LColor for branches is that it is currently possible to use an arbitrary color, specified by r, g, and b. How would we do that with LColor? Adding a new color everytime the user chooses a new branch color? How would we get the rgb values for the existing colors, e.g. LColor::background? Georg
Re: qt4: some colors messed up in preferences dialog
Leuven, E. a écrit : colornames grey40 etc are not recognized by qt4 and end up black in the preferences dialog. i need the attached patch Edwin, I noticed that you didn't commit your patch. I want to do some cleanup that include your patch so I am going to commit the attached patch. Thanks, Abdel. log: - QPrefsDialog::QPrefsDialog(): fix from Edwin Leuven. colorsModule did not recognize colornames grey40, etc. - delete unused variable. Index: QPrefsDialog.C === --- QPrefsDialog.C (revision 13441) +++ QPrefsDialog.C (working copy) @@ -44,6 +44,7 @@ #include "gettext.h" #include "LColor.h" +#include "lcolorcache.h" #include "controllers/ControlPrefs.h" @@ -168,9 +169,8 @@ || lc == LColor::ignore) continue; colors_.push_back(lc); - string const x11name(lcolor.getX11Name(lc)); string const guiname(lcolor.getGUIName(lc)); - QColorItem * ci(new QColorItem(QColor(toqstr(x11name)), + QColorItem * ci(new QColorItem(lcolorcache.get(lc), toqstr(guiname))); colorsModule->lyxObjectsLB->insertItem(ci); }
Re: Problem with line-breaking in Lyx-Wiki
On Tue, 21 Mar 2006, Ekkehart Schlicht wrote: > I just observed that line breaking seems not to work, neither in Firefox > nor in Internet Explorer (both under Windows XP). > > Ekkehart > > Problem is gone - maybe it was idiosyncratic on my machine (?) Ok... :-) Let me know if something happens again! /C -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: [Qt4 bug] Branches dialog, small issue with "alter color"
Georg Baum a écrit : Abdelrazak Younes wrote: You are right, it is not. But if the frontend tries to convert it to a QColor it will get an invalid color. That's the reason of my hack which set a default color in the frontend. I know. It's always better to clarify the matter for the archive, isn't it? ;-) Abdel.
Re: [Qt4 bug] Branches dialog, small issue with "alter color"
Georg Baum a écrit : Abdelrazak Younes wrote: Reading BranchList.C, it seems that the default color is "none". This doesn't seems like a valid color reading LColor.C: The branch color has nothing to do with LColor, AFAIK it is never converted to one. You are right, it is not. But if the frontend tries to convert it to a QColor it will get an invalid color. That's the reason of my hack which set a default color in the frontend. By the way, is there a reason why Branch stores a string instead of a LColor? Yes. It stores the string as "#rrggbb" in the .lyx file, because a user can choose arbitrary colors, not only the ones that have names in LColor. Yes, this string is given by the frontend. I am not sure the other frontends have the same syntax. Seems to me like there are a lot of unnecessary conversion. I am not sure. Maybe it would be better to store it as a numerical rgb triplet? I agree. Abdel.
Re: [Qt4 bug] Branches dialog, small issue with "alter color"
Abdelrazak Younes <[EMAIL PROTECTED]> writes: > > I am not sure. Maybe it would be better to store it as a numerical rgb > > triplet? > > I agree. There's an RGBColor class (and an HSVColor one too) in the XForms frontend. Please move 'em someplace useful. Angus
Reproducible segmentation fault (LyX 1.4.0, Mac OS X)
Hello everybody. Thanks for the great work! I really like LyX and it's really feature rich for me at the moment (I really liked the children documents mechanism). Neverthless, I experience some instability and segmentation faults, often when working with math and array environments. I have a reproducible segmentation fault. My platform is Mac OS X and I'm running the latest release, with precompiled binaries. 1. open the attached file segfault.lyx 2. select the second cell of the array 3. delete column The others cells can be deleted without problems. (I'm not subscribed to the list, so please CC me when replying) -- Andrea Censi Web: http://www.dis.uniroma1.it/~censi PGP key #569106B2 available on keyservers. segfault.lyx Description: Binary data
RE: Re: qt4: some colors messed up in preferences dialog
> Edwin, I noticed that you didn't commit your patch. I want to > do some cleanup that include your patch so I am going to commit > the attached patch. sorry for that, but i haven't had the opportunity to commit since my old password doesn't seem to work. (lars is going to reset it, i hope...) thanks for shoving it in. edwin
Re: [Qt4 bug] Branches dialog, small issue with "alter color"
Abdelrazak Younes wrote: > You are right, it is not. But if the frontend tries to convert it to a > QColor it will get an invalid color. That's the reason of my hack which > set a default color in the frontend. I know. > Yes, this string is given by the frontend. I am not sure the other > frontends have the same syntax. They do have. It comes originally from X11. Georg
Re: LyX 1.4.0 on Windows
Angus Leeming <[EMAIL PROTECTED]> writes: > > Jean-Marc Lasgouttes ...> writes: > > Enrico> my reading of it is that you need the three compilations only > > Enrico> if you want an internationalized iconv program, i.e., if you > > Enrico> want translated messages from iconv. I personally think that > > Enrico> building libiconv with --disable-nls and then LyX with > > Enrico> --with-included-gettext is sufficient. But I may be wrong > > > That seems very reasonable indeed. > > It may seem "reasonable", but that's what I did (apart from the > --disable-nls > bit) and, as I mention, I get garbage instead of Russian or Polish menus. Is > the > explicit --disable-nls important? Presumably not, since libiconv's configure > will work out that it can't see a gettext. Angus, this is what I do: $ cd libiconv-1.10 $ ./configure CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' CFLAGS='-O2' \ CXXFLAGS='-O2' --enable-static --disable-shared --disable-nls \ --prefix=C:/MinGW $ make $ make install and then I configure LyX with --with-included-gettext. Works for me and I don't get garbage. Please double check the other post where I was talking about LYX_ABS_INSTALLED_LOCALEDIR, this one maybe the culprit. -- Enrico
[Qt4 RFC] QPrefs/QPrefsDialog Reorganisation
Hello, I would like to cut QPrefsDialog into multiple modules. The first step is to transfer everything related to GUI in QPrefs.[Ch] into QPrefsDialog. IMHO, the controller should not know anything about what the Dialog is doing, it is here only to transfer request one way or the other. Second step would be to create one class per module. Each module will inherit a base class. This will make easy to add module in the future. This will make easy also to relocate or to duplicate the module elsewhere. I plan to do the same for QDocument/QDocumentDialog if no one beats me at this. Any strong opinion against this? Abdel.
Re: [Qt4 RFC] QPrefs/QPrefsDialog Reorganisation
Abdelrazak Younes <[EMAIL PROTECTED]> writes: > I would like to cut QPrefsDialog into multiple modules. > Second step would be to create one class per module. Sounds like a sane thing to do. Angus
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > > > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: > > Enrico> Yes, I have to specify --with-packaging=windows, otherwise I > Enrico> would get posix. The packaging test in configure is quite > Enrico> simple. I don't know if it can be changed in the following way > Enrico> (using some sort of pseudo-code): > > Well, could you tell me again what cygwin-without-cygwin is good for? > I am wary of adding fragile code for this special case. I think that > specifying packaging=windows is OK is this case. It is good for building a native LyX (not dependent on cygwin) by using cygwin tools only. Jean-Marc, I am not asking to add anything. I thought I was answering a question by Georg. I am fine with the official way of building a native version of LyX. But, as I already have cygwin, I tried and succeeded in building a native LyX with cygwin tools. It can be done, but I do not endorse it because it is much more complicated. I am fine with whatever thing you will do (or not do). -- Enrico
Re: Qt-4, gcc-3.3, Mac OS X: link failure
Bennett Helm a écrit : On Mar 21, 2006, at 3:49 AM, Abdelrazak Younes wrote: Please give me the final linking command as executed by make for Qt3 and Qt4 frontends so we cam compare. We must verify that -lQtCore or -lQtCore4 is there. Here's the beginning of the link stage for the Qt4 frontend: -lQtCore is there. (I'll try to get the one for Qt3 tomorrow) Hum, have you compiled Qt4 yourself or did you use a precompiled package? I remember you said you manage to get an executable once, didn't you? Compiled myself, with ./configure -static. There might be some options as "--with-included-libpng" or something. I don't know enough about Mac, sorry. You should maybe try to use the precompiled package from TrollTech. (Do you mean a LyX executable? -- No, I've never gotten that far.) My mistake then. Could you please give me the output of : ls /Users/bennett/lyx/gcc-3.3/qt-mac-opensource-src-4.1.1/lib Here it is; I've copied *.la into the bak/ directory. AFAIS, everythings needed is there. Sorry I cannot help more here, Abdel.
Re: Cygwin and Mingw incompatibility with -mms-bitfields gcc options
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> It is good for building a native LyX (not dependent on cygwin) Enrico> by using cygwin tools only. Enrico> Jean-Marc, I am not asking to add anything. I thought I was Enrico> answering a question by Georg. I am fine with the official way Enrico> of building a native version of LyX. But, as I already have Enrico> cygwin, I tried and succeeded in building a native LyX with Enrico> cygwin tools. It can be done, but I do not endorse it because Enrico> it is much more complicated. I am fine with whatever thing you Enrico> will do (or not do). Thanks for the precisions. I think we'll leave it as it it now. JMarc
Re: Qt-4, gcc-3.3, Mac OS X: link failure
On Mar 21, 2006, at 3:49 AM, Abdelrazak Younes wrote: Please give me the final linking command as executed by make for Qt3 and Qt4 frontends so we cam compare. We must verify that - lQtCore or -lQtCore4 is there. Here's the beginning of the link stage for the Qt4 frontend: - lQtCore is there. (I'll try to get the one for Qt3 tomorrow) Hum, have you compiled Qt4 yourself or did you use a precompiled package? I remember you said you manage to get an executable once, didn't you? Compiled myself, with ./configure -static. (Do you mean a LyX executable? -- No, I've never gotten that far.) Could you please give me the output of : ls /Users/bennett/lyx/gcc-3.3/qt-mac-opensource-src-4.1.1/lib Here it is; I've copied *.la into the bak/ directory. -rw-r--r--1 bennett staff 1118 Mar 21 00:13 Qt3Support.pc -rw-r--r--1 bennett staff 1158 Mar 21 00:13 Qt3Support_debug.pc -rw-r--r--1 bennett staff951 Mar 20 22:23 QtCore.pc -rw-r--r--1 bennett staff961 Mar 20 22:23 QtCore_debug.pc -rw-r--r--1 bennett staff 1066 Mar 20 22:24 QtGui.pc -rw-r--r--1 bennett staff 1082 Mar 20 22:24 QtGui_debug.pc -rw-r--r--1 bennett staff 1033 Mar 20 22:24 QtNetwork.pc -rw-r--r--1 bennett staff 1049 Mar 20 22:24 QtNetwork_debug.pc -rw-r--r--1 bennett staff 1122 Mar 20 22:24 QtOpenGL.pc -rw-r--r--1 bennett staff 1144 Mar 20 22:24 QtOpenGL_debug.pc -rw-r--r--1 bennett staff 1017 Mar 20 22:24 QtSql.pc -rw-r--r--1 bennett staff 1033 Mar 20 22:24 QtSql_debug.pc -rw-r--r--1 bennett staff 1078 Mar 21 00:09 QtSvg.pc -rw-r--r--1 bennett staff 1106 Mar 21 00:09 QtSvg_debug.pc -rw-r--r--1 bennett staff927 Mar 20 22:31 QtTest.pc -rw-r--r--1 bennett staff937 Mar 20 22:31 QtTest_debug.pc -rw-r--r--1 bennett staff 1017 Mar 20 22:24 QtXml.pc -rw-r--r--1 bennett staff 1033 Mar 20 22:24 QtXml_debug.pc drwxr-xr-x 20 bennett staff680 Mar 21 09:12 bak -rw-r--r--1 bennett staff6044616 Mar 21 00:38 libQt3Support.a -rw-r--r--1 bennett staff 1050 Mar 21 00:13 libQt3Support.prl -rw-r--r--1 bennett staff 59835040 Mar 21 00:24 libQt3Support_debug.a -rw-r--r--1 bennett staff 1078 Mar 21 00:13 libQt3Support_debug.prl -rw-r--r--1 bennett staff 33720 Mar 21 00:48 libQtAssistantClient.a -rw-r--r--1 bennett staff966 Mar 20 22:24 libQtAssistantClient.prl -rw-r--r--1 bennett staff 390920 Mar 21 00:48 libQtAssistantClient_debug.a -rw-r--r--1 bennett staff982 Mar 20 22:24 libQtAssistantClient_debug.prl -rw-r--r--1 bennett staff2893032 Mar 20 22:55 libQtCore.a -rw-r--r--1 bennett staff889 Mar 20 22:23 libQtCore.prl -rw-r--r--1 bennett staff 22206744 Mar 20 22:48 libQtCore_debug.a -rw-r--r--1 bennett staff887 Mar 20 22:23 libQtCore_debug.prl -rw-r--r--1 bennett staff3309072 Mar 21 01:19 libQtDesigner.a -rw-r--r--1 bennett staff948 Mar 20 22:31 libQtDesigner.prl -rw-r--r--1 bennett staff3136592 Mar 21 01:42 libQtDesignerComponents.a -rw-r--r--1 bennett staff980 Mar 20 22:24 libQtDesignerComponents.prl -rw-r--r--1 bennett staff 73744632 Mar 21 01:31 libQtDesignerComponents_debug.a -rw-r--r--1 bennett staff996 Mar 20 22:24 libQtDesignerComponents_debug.prl -rw-r--r--1 bennett staff 49661680 Mar 21 01:10 libQtDesigner_debug.a -rw-r--r--1 bennett staff964 Mar 20 22:31 libQtDesigner_debug.prl -rw-r--r--1 bennett staff 11243624 Mar 21 00:04 libQtGui.a -rw-r--r--1 bennett staff999 Mar 20 22:24 libQtGui.prl -rw-r--r--1 bennett staff 149992480 Mar 20 23:27 libQtGui_debug.a -rw-r--r--1 bennett staff 1003 Mar 20 22:24 libQtGui_debug.prl -rw-r--r--1 bennett staff 739648 Mar 21 00:09 libQtNetwork.a -rw-r--r--1 bennett staff962 Mar 20 22:24 libQtNetwork.prl -rw-r--r--1 bennett staff5260368 Mar 21 00:07 libQtNetwork_debug.a -rw-r--r--1 bennett staff966 Mar 20 22:24 libQtNetwork_debug.prl -rw-r--r--1 bennett staff 280752 Mar 21 00:13 libQtOpenGL.a -rw-r--r--1 bennett staff 1052 Mar 20 22:24 libQtOpenGL.prl -rw-r--r--1 bennett staff3663192 Mar 21 00:12 libQtOpenGL_debug.a -rw-r--r--1 bennett staff 1062 Mar 20 22:24 libQtOpenGL_debug.prl -rw-r--r--1 bennett staff 496320 Mar 21 00:06 libQtSql.a -rw-r--r--1 bennett staff950 Mar 20 22:24 libQtSql.prl -rw-r--r--1 bennett staff5029232 Mar 21 00:05 libQtSql_debug.a -rw-r--r--1 bennett staff954 Mar 20 22:24 libQtSql_debug.prl -rw-r--r--1 bennett staff 542408 Mar 21 00:11 libQtSvg.a -rw-r--r--1 bennett staff 1011 Mar 21 00:09 libQtSvg.prl -rw-r--r--1 bennett staff5284416 Mar 21
Re: [Qt4 RFC] QPrefs/QPrefsDialog Reorganisation
I aim at something like this yes (are you reading my mind? :-)). While we can minimize the job of creating a module, I don't think a simple configuration file will do for most of the modules. In the use case you are citing perhaps. But one step after the other... We talk about 2007 feature here. Abdel. Charles de Miramon a écrit : Abdelrazak Younes wrote: Maybe, you should take a look at http://www.icefox.net/programs/?program=KAutoConfig I would plead the case for an extensible configuration framework for changing preferences for packages. Ideally a non programmer like me who would want to add support for KomaScript should be able to create a widget in QtDesigner and a configuration file with indications that changing this option in the widget should insert this LateX code in the preamble. Cheers, Charles
Re: [Qt4 RFC] QPrefs/QPrefsDialog Reorganisation
Charles de Miramon <[EMAIL PROTECTED]> writes: > Maybe, you should take a look at > http://www.icefox.net/programs/?program=KAutoConfig Nice! Definitely something to investigate. Angus === Does KAutoConfig require KDE? Nope, KAutoConfig comes in two forms. The first form takes advantage of everything in KDE. KAutoConfig will automaticly recognize all of KDE's widgets, set the caption, icon, and uses the KConfig engine. The second form of KAutoConfig links only against Qt and uses QSettings on the back end. This is done by compiling in two replacement classes which extend QSettings and QDialog and provides the needed features that are in KDE while giving the developer source compatibility. Best of all the Qt only library can be used in Windows or Mac development. Compiling the library with or without KDE support is as simple as using the different Makefiles when compiling the library. ===
Re: [Qt4 RFC] QPrefs/QPrefsDialog Reorganisation
Abdelrazak Younes wrote: Maybe, you should take a look at http://www.icefox.net/programs/?program=KAutoConfig I would plead the case for an extensible configuration framework for changing preferences for packages. Ideally a non programmer like me who would want to add support for KomaScript should be able to create a widget in QtDesigner and a configuration file with indications that changing this option in the widget should insert this LateX code in the preamble. Cheers, Charles -- http://www.kde-france.org
Re: LyX 1.4.0 on Windows
Angus Leeming wrote: Do the autotools work for you, or are you just being thorough? I am just thorough :-) Michael
Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)
On Tue, 2006-03-21 at 16:41 +0100, Andrea Censi wrote: > Hello everybody. > > Thanks for the great work! I really like LyX and it's really feature > rich for me at the moment (I really liked the children documents > mechanism). Neverthless, I experience some instability and > segmentation faults, often when working with math and array > environments. > > I have a reproducible segmentation fault. My platform is Mac OS X and > I'm running the latest release, with precompiled binaries. > > 1. open the attached file segfault.lyx > 2. select the second cell of the array > 3. delete column > > The others cells can be deleted without problems. > > (I'm not subscribed to the list, so please CC me when replying) > > -- > Andrea Censi Confirmed on Linux SVN. returning FINISHED_LEFT Assertion triggered in const MathAtom& MathArray::operator[](size_t) const by failing check "pos < size()" in file math_data.C:59 Aborted - Martin signature.asc Description: This is a digitally signed message part
Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)
On Tue, 2006-03-21 at 18:01 +0200, Martin Vermeer wrote: > On Tue, 2006-03-21 at 16:41 +0100, Andrea Censi wrote: > > Hello everybody. > > > > Thanks for the great work! I really like LyX and it's really feature > > rich for me at the moment (I really liked the children documents > > mechanism). Neverthless, I experience some instability and > > segmentation faults, often when working with math and array > > environments. > > > > I have a reproducible segmentation fault. My platform is Mac OS X and > > I'm running the latest release, with precompiled binaries. > > > > 1. open the attached file segfault.lyx > > 2. select the second cell of the array > > 3. delete column > > > > The others cells can be deleted without problems. > > > > (I'm not subscribed to the list, so please CC me when replying) > > > > -- > > Andrea Censi > > Confirmed on Linux SVN. > > returning FINISHED_LEFT > Assertion triggered in const MathAtom& MathArray::operator[](size_t) > const by failing check "pos < size()" in file math_data.C:59 > Aborted Okay, it's another case of cur.pos() remaining hanging in mid-air... If you delete the cell in column 2, column 3 becomes the new column 2. If cur.pos() == 4, say, and the cell in column 3 contains only 1 position (as in this case), then obviously pos < size will assert. We have to reset cur.pos() to zero in this case. - Martin signature.asc Description: This is a digitally signed message part
Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)
On Tue, 2006-03-21 at 18:14 +0200, Martin Vermeer wrote:
> On Tue, 2006-03-21 at 18:01 +0200, Martin Vermeer wrote:
> > On Tue, 2006-03-21 at 16:41 +0100, Andrea Censi wrote:
...
> >
> > Confirmed on Linux SVN.
> >
> > returning FINISHED_LEFT
> > Assertion triggered in const MathAtom& MathArray::operator[](size_t)
> > const by failing check "pos < size()" in file math_data.C:59
> > Aborted
>
> Okay, it's another case of cur.pos() remaining hanging in mid-air...
>
> If you delete the cell in column 2, column 3 becomes the new column 2.
> If cur.pos() == 4, say, and the cell in column 3 contains only 1
> position (as in this case), then obviously pos < size will assert.
>
> We have to reset cur.pos() to zero in this case.
Here's the patch. Trivial (Georg, how did we overlook this?)
OK to put into both trunk and 1.4?
- Martin
Index: math_gridinset.C
===
--- math_gridinset.C (revision 13408)
+++ math_gridinset.C (working copy)
@@ -1131,12 +1131,14 @@ void MathGridInset::doDispatch(LCursor &
else if (s == "append-row")
for (int i = 0, n = extractInt(is); i < n; ++i)
addRow(cur.row());
- else if (s == "delete-row")
+ else if (s == "delete-row") {
for (int i = 0, n = extractInt(is); i < n; ++i) {
delRow(cur.row());
if (cur.idx() > nargs())
cur.idx() -= ncols();
}
+ cur.pos() = 0; // trick, see below
+ }
else if (s == "copy-row") {
// Here (as later) we save the cursor col/row
// in order to restore it after operation.
@@ -1173,6 +1175,7 @@ void MathGridInset::doDispatch(LCursor &
for (int i = 0, n = extractInt(is); i < n; ++i)
delCol(col(cur.idx()));
cur.idx() = index(r, min(c, cur.ncols() - 1));
+ cur.pos() = 0; // trick, see above
}
else if (s == "copy-column") {
row_type const r = cur.row();
signature.asc
Description: This is a digitally signed message part
Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)
Am Dienstag, 21. März 2006 17:29 schrieb Martin Vermeer: > Here's the patch. Trivial (Georg, how did we overlook this?) We must have been sleeping :-( Georg
Re: [patch] remove qt2 support
Am Samstag, 18. März 2006 14:22 schrieb Georg Baum: > Am Freitag, 17. März 2006 21:42 schrieb Leuven, E.: > > if qt2 goes, the attached should go (in) as well i think (i.e. remove > qgridview.[Ch]) > > You are right. I did not know that we had these classes! The full patch > would look like the attached. Dou you have commit privileges now, or > should I commit it for you? I removed qgridview.[Ch] now. Georg
