Re: LyX meeting in Paris. When?
On Wed, May 11, 2005 at 04:18:19PM +0200, Jean-Marc Lasgouttes wrote: Asger == Asger Alstrup [EMAIL PROTECTED] writes: Asger I agree with Lars that it is due time to decide the date, and Asger the 16th looks like the clear winner. Jean-Marc, what do you Asger say? The 16th looks good. I suspect that there will be too many people present to be able to work in decent condition in my Paris flat, so I have to check that we will be able to use my parent's house. I'll tell you more tomorrow, I guess. ...and the result...? So, what could be the 4-5 day core time that we should all try to be there? Th 14 - Mo 18 July? I have to start ordering tickets... BTW I will be out of circulation (field work) the coming two weeks. To add to the fun, my ssh tunnel to the job machine (where I have the LyX tree) crashed last night (as did the backup tunnel on this university machine, so probably a power cut at our department), and I am writing this on old, hateful Bill Joy's vi rather than vim. That's where those funny characters come from :-) - Martin A A A A
Re: [Patch] Re: Timing experiments
Martin Vermeer wrote: On Fri, May 13, 2005 at 09:48:45PM +0200, Alfredo Braunstein wrote: Martin Vermeer wrote: // real_current_font.number can change so we need to // update the minibuffer if (old_font != real_current_font) -bv-updateScrollbar(); +bv-updateScrollbar(); break; } Btw it seems that the last +- correction chunk is not an error in tabulation, rather that the block inside the if above was inadvertently deleted. There was no block. The diff of versions 2.32 - 2.31 looks like This is what I meant. @@ -1229,7 +1221,6 @@ // real_current_font.number can change so we need to // update the minibuffer if (old_font != real_current_font) - bv-owner()-view_state_changed(); bv-updateScrollbar(); break; } and Andre deleted lots of other bv-owner()-view_state_changed(); in that same patch. I suspect the if should go. Andre should know. That's my suspicion. Alfredo
Re: LyX meeting in Paris. When?
Martin Vermeer wrote: So, what could be the 4-5 day core time that we should all try to be there? Th 14 - Mo 18 July? I have to start ordering tickets... BTW: I intend to go by train. How difficult is it to get to your apartment from Paris railway station? (In particular, if you do not speak French :-)) Michael
Re: [patch] key event queue
Andre Poenitz wrote: Could you just comment out the whole body of LengthCombo::noPercents() in src/frontend/qt2/lengthcombo.C (this is lines 62-69 or so) and try again? It would certainly be a big surprise if that function would be called while typing. Jürgen
Bug report: Qt Citations BibTeX
Hi, a couple of small bug reports regarding the Qt frontend: 1. Insert List TOC BibTeX Bibliography Add Browse = Bang! 2. (a) Add some BibTeX bibliography (b) Insert Cross-reference (c) search entry e (d) Find Previous = Bang! 3. (a) Add some BibTeX bibliography (b) Insert Cross-reference (c) search entry e (d) Find Next (multiple times) = does not work 4. Tools TeX Information = There is an empty entry at the top of each file list 5. Insert List TOC BibTeX Bibliography Add = There is an empty entry at the top Michael
LyX frontends
Hi, I am wondering about the role of the various frontends with regard to LyX 1.4. At least gnome and gtk are not usable right now and I would like to propose to 1. remove gnome from the CVS because it is no longer used 2. remove all gtk files from POTFILES so that gtk messages will not show up in the po files. My initial tests of the Qt frontend told me that it is far away from being stable. Actually, it seems like some stuff is broken that worked very well in 1.3 before. Once again, I would like to raise the question on whether we can really afford to maintain more than one frontend. Wouldn't it make sense to remove even the xforms frontend for 1.4? Who is actually using/testing it? I think one really good frontend is better than two half-heartedly tested frontends. Regards, Michael
Re: LyX frontends
Michael Schmitt wrote: Once again, I would like to raise the question on whether we can really afford to maintain more than one frontend. Wouldn't it make sense to remove even the xforms frontend for 1.4? Who is actually using/testing it? I think one really good frontend is better than two half-heartedly tested frontends. My take on this is that we should * have one *official* frontend, Qt, after 1.4 is out. * ditch XForms after 1.4 is out. * send the gnome port to the Attic now. * leave the gtk port alone. Nobody is *required* to work on it. If John Spray wants to work on it, then who am I to tell him not to? Basically, maintaining a working frontend is minimal effort, so I don't think that it matters if someone wants to have a pet project porting to his/her favourite toolkit. -- Angus
[Patch] Re: Timing experiments
On Fri, May 13, 2005 at 10:43:52PM +0200, Andre Poenitz wrote:
Does that look like a plan?
Yes.
Here is the latest state of the patch. Have your pleasure with it :-)
I'll be out for two weeks starting Monday.
- Martin
Index: BufferView.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.C,v
retrieving revision 1.260
diff -u -p -r1.260 BufferView.C
--- BufferView.C22 Feb 2005 11:41:19 - 1.260
+++ BufferView.C14 May 2005 11:02:58 -
@@ -142,9 +142,9 @@ bool BufferView::fitCursor()
}
-void BufferView::update(bool fitcursor, bool forceupdate)
+void BufferView::update(bool fitcursor, bool forceupdate, bool singlepar)
{
- pimpl_-update(fitcursor, forceupdate);
+ pimpl_-update(fitcursor, forceupdate, singlepar);
}
Index: BufferView.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.h,v
retrieving revision 1.186
diff -u -p -r1.186 BufferView.h
--- BufferView.h26 Apr 2005 11:12:09 - 1.186
+++ BufferView.h14 May 2005 11:02:58 -
@@ -81,7 +81,8 @@ public:
* position changes. \c forceupdate means to force an update
* in any case.
*/
- void update(bool fitcursor = true, bool forceupdate = true);
+ void update(bool fitcursor = true, bool forceupdate = true,
+ bool singlepar = false);
/// move the screen to fit the cursor. Only to be called with
/// good y coordinates (after a bv::metrics)
bool fitCursor();
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.583
diff -u -p -r1.583 BufferView_pimpl.C
--- BufferView_pimpl.C 11 May 2005 07:44:18 - 1.583
+++ BufferView_pimpl.C 14 May 2005 11:02:58 -
@@ -606,7 +606,8 @@ bool BufferView::Pimpl::fitCursor()
}
-void BufferView::Pimpl::update(bool fitcursor, bool forceupdate)
+void BufferView::Pimpl::update(bool fitcursor, bool forceupdate,
+ bool singlepar)
{
lyxerr BOOST_CURRENT_FUNCTION
[fitcursor = fitcursor ','
@@ -635,7 +636,7 @@ void BufferView::Pimpl::update(bool fitc
if (fitcursor fitCursor()) {
forceupdate = true;
- vi = metrics();
+ vi = metrics(singlepar);
}
if (forceupdate) {
// Second drawing step
@@ -1246,7 +1247,7 @@ bool BufferView::Pimpl::dispatch(FuncReq
}
-ViewMetricsInfo BufferView::Pimpl::metrics()
+ViewMetricsInfo BufferView::Pimpl::metrics(bool singlepar)
{
// Remove old position cache
theCoords.clear();
@@ -1274,7 +1275,7 @@ ViewMetricsInfo BufferView::Pimpl::metri
// Redo paragraphs above cursor if necessary
int y1 = y0;
- while (y1 0 pit1 0) {
+ while (!singlepar y1 0 pit1 0) {
y1 -= text-getPar(pit1).ascent();
--pit1;
text-redoParagraph(pit1);
@@ -1298,7 +1299,7 @@ ViewMetricsInfo BufferView::Pimpl::metri
// Redo paragraphs below cursor if necessary
int y2 = y0;
- while (y2 bv.workHeight() pit2 int(npit) - 1) {
+ while (!singlepar y2 bv.workHeight() pit2 int(npit) - 1) {
y2 += text-getPar(pit2).descent();
++pit2;
text-redoParagraph(pit2);
@@ -1321,5 +1322,5 @@ ViewMetricsInfo BufferView::Pimpl::metri
y2: y2
endl;
- return ViewMetricsInfo(pit1, pit2, y1, y2);
+ return ViewMetricsInfo(pit1, pit2, y1, y2, singlepar);
}
Index: BufferView_pimpl.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.h,v
retrieving revision 1.127
diff -u -p -r1.127 BufferView_pimpl.h
--- BufferView_pimpl.h 19 Jan 2005 15:03:26 - 1.127
+++ BufferView_pimpl.h 14 May 2005 11:02:58 -
@@ -60,7 +60,8 @@ public:
//
bool fitCursor();
///
- void update(bool fitcursor = false, bool forceupdate = true);
+ void update(bool fitcursor = false, bool forceupdate = true,
+ bool singlepar = false);
///
void newFile(std::string const , std::string const , bool);
///
@@ -186,7 +187,7 @@ private:
///
int offset_ref_;
///
- ViewMetricsInfo metrics();
+ ViewMetricsInfo metrics(bool singlepar = false);
};
Index: dimension.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/dimension.h,v
retrieving revision 1.6
diff -u -p -r1.6 dimension.h
--- dimension.h 18 Jan 2005 14:15:55 - 1.6
+++
Re: LyX frontends
On Sat, 2005-05-14 at 12:08 +0100, Angus Leeming wrote: My take on this is that we should * have one *official* frontend, Qt, after 1.4 is out. Makes sense, although whether distributors package it like that is up to them. * send the gnome port to the Attic now. Yes. If one ever wants to refer to it it will still be findable. Right now it's just confusing to anyone who is new to the repository. * leave the gtk port alone. Nobody is *required* to work on it. If John Spray wants to work on it, then who am I to tell him not to? Indeed :-) I think that Michael was saying that the gtk frontend was causing extra work for translators. If that is causing a problem, I would accept leaving the gtk frontend untranslated until it reaches a state of usability. Basically, maintaining a working frontend is minimal effort, so I don't think that it matters if someone wants to have a pet project porting to his/her favourite toolkit. I would agree with this: getting rid of the GUI independent stuff would be a lot of work, for no massive gain. Since it's there, it might as well stay to make LyX agile in the future as deployed desktop environments come and go. John
Re: Profiling LyX-140 on Mac
On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote: So why not solve that he other way round: Do not blink the cursor unless all draws have been finished? I thought that's what Martin was planning (and it certainly sounds right) regards john
Re: LyX frontends
On Sat, May 14, 2005 at 12:19:38PM +0100, John Spray wrote: On Sat, 2005-05-14 at 12:08 +0100, Angus Leeming wrote: * send the gnome port to the Attic now. Yes. If one ever wants to refer to it it will still be findable. Right now it's just confusing to anyone who is new to the repository. * leave the gtk port alone. Nobody is *required* to work on it. If John Spray wants to work on it, then who am I to tell him not to? Indeed :-) I think that Michael was saying that the gtk frontend was causing extra work for translators. If that is causing a problem, I would accept leaving the gtk frontend untranslated until it reaches a state of usability. OK, but that tells us also something about the current state of incompleteness of GUI-I. Ideally, the front ends should only define a set of primitives that the rest of LyX then uses. I am thinking of a termcap type parametrization thingy, but graphically. I doubt that we will ever get quite that far (if even possible), but we can certainly get farther than we are now. In my understanding there is _no reason at all_ why _any_ translatable strings should be front end specific / part of the front-end code. Unfortunately many today are. You know that, John: you've been duplicating Qt strings rather than re-using them as you would under a sane architecture... Other than that, the proposal is OK if it is easily reversible later. Basically, maintaining a working frontend is minimal effort, so I don't think that it matters if someone wants to have a pet project porting to his/her favourite toolkit. Ideally, the maintenance should be _zero_ work, see above. The primitives shouldn't change. We should get closer to that. I would agree with this: getting rid of the GUI independent stuff would be a lot of work, for no massive gain. Since it's there, it might as well stay to make LyX agile in the future as deployed desktop environments come and go. Hear, hear. - Martin pgpaLj8gLHHUQ.pgp Description: PGP signature
Re: Profiling LyX-140 on Mac
On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote: On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote: So why not solve that he other way round: Do not blink the cursor unless all draws have been finished? I thought that's what Martin was planning (and it certainly sounds right) I'm note sure we are talking about the same thing now. Anyway I am happy the way things have turned out with Lars' cache (though I still don't grok it). - Martin pgpMcwK4CjNos.pgp Description: PGP signature
Re: 2 questions regarding qt2 frontend
Hi Jean-Marc, Hammer On MacOsX the options doens'nt seems active. I got an unknown Hammer option error. Forget about it, this is done by qt/x11. Hammer QSessions seems quite easy. I will give it try. But It seems to me that they do not provide much that cannot be done by hand... It seems that I miss their point. I think I know what you mean. After digging in the code, perhaps the lyx preferences file would be a better place to store and retrieve the geometry settings. We could add 4 new settings in the Screen Font Section \screen_geometry_xpos \screen_geometry_ypos \screen_geometry_width \screen_geometry_height As far as i can see, the preferences file will only be written if the settings has been changed using a gui dialog. Which procedure would be better? automatically store on exit or add some gui elements to store it manually? mit freundlichen Gruessen / Yours Armin Hammer === http://www.ahammer.ch -- PGP public key on request
Re: LyX frontends
On Sat, May 14, 2005 at 03:57:23PM +0300, Martin Vermeer wrote: OK, but that tells us also something about the current state of incompleteness of GUI-I. Ideally, the front ends should only define a set of primitives that the rest of LyX then uses. I am thinking of a termcap type parametrization thingy, but graphically. I sincerely hope you're not bringing up the idea I think you might be. No, 'frontends provide method for drawing combos, everything else is GUII' is not where we want to be. can certainly get farther than we are now. In my understanding there is _no reason at all_ why _any_ translatable strings should be front end This is not true, actually. Different platforms have all sorts of different rules on how we present data. Historically, the biggest difference has been that xforms remains close to 'classic' LyX, whereas in Qt we were free to use higher-order views, and experiment with the UI. One example is that we still differ on the rules used for tooltips between the two frontends. Gnome will again have different rules. I'm all for Michael's work in reducing translator load (so far), but this will not extend to the point where lowest-common-denominator UIs are the only option. I don't see an architectural approach to reducing this load; what do you have in mind? Multiple frontends has never been a serious portion of the maintainer load; it's generally been (originally) the hulking mass of old kernel code; currently it's the serious stability problems of the new code. regards, john
Re: 2 questions regarding qt2 frontend
On Sat, May 14, 2005 at 03:08:12PM +0200, Hammer Armin wrote: I think I know what you mean. After digging in the code, perhaps the lyx preferences file would be a better place to store and retrieve the geometry settings. We'd need to implement the session saving code that happens when e.g. the window manager shuts down. regards, john
Re: LyX frontends
On Sat, May 14, 2005 at 02:11:21PM +0100, John Levon wrote: On Sat, May 14, 2005 at 03:57:23PM +0300, Martin Vermeer wrote: OK, but that tells us also something about the current state of incompleteness of GUI-I. Ideally, the front ends should only define a set of primitives that the rest of LyX then uses. I am thinking of a termcap type parametrization thingy, but graphically. I sincerely hope you're not bringing up the idea I think you might be. No, 'frontends provide method for drawing combos, everything else is GUII' is not where we want to be. No, that is out. Too late now, if it were ever possible. can certainly get farther than we are now. In my understanding there is _no reason at all_ why _any_ translatable strings should be front end This is not true, actually. Different platforms have all sorts of different rules on how we present data. Historically, the biggest difference has been that xforms remains close to 'classic' LyX, whereas in Qt we were free to use higher-order views, and experiment with the UI. One example is that we still differ on the rules used for tooltips between the two frontends. Yes... but then we should try to move them closer together again. Yes, some differences will remain. We should certainly have only one translatable string copy -- located in the common part outside the front ends -- for every message we send out, with few motivated exceptions. For some of the dialogs this has been done. Gnome will again have different rules. I'm all for Michael's work in reducing translator load (so far), but this will not extend to the point where lowest-common-denominator UIs are the only option. I don't see an architectural approach to reducing this load; what do you have in mind? The above. I believe the _translator_ load per front end can be brought down to close to zero; as for the _coding_ load caused by the ongoing evolution of the LyX core code, that of course will never be zero short of a pure termcap-style primitives architecture. Multiple frontends has never been a serious portion of the maintainer load; it's generally been (originally) the hulking mass of old kernel code; currently it's the serious stability problems of the new code. Now there I agree. Which is why I think we should not just drop any front ends. We need at least two more or less useable ones to keep GUI-I alive, now that we have it. I expect that in 1.5, we can combine much of the work of getting xforms to behave more similarly to qt (i.e., more modern) with moving stuff out of front-end specific code into common code. regards, john Regards Martin pgp93EfhbYpBs.pgp Description: PGP signature
Re: LyX frontends
Martin Vermeer wrote: Now there I agree. Which is why I think we should not just drop any front ends. We need at least two more or less useable ones to keep GUI-I alive, now that we have it. It keeps us 'honest' you mean? Fine. I expect that in 1.5, we can combine much of the work of getting xforms to behave more similarly to qt (i.e., more modern) with moving stuff out of front-end specific code into common code. Code refactoring should be on-going, yes. However, we should drop XForms. Why? Because in 1.5 we're going to move to unicode strings and whilst it is possible to patch the underlying XForms library to understand multibyte strings, it is horrible and klunky and not something we should be wasting our time on. I know. I put a huge investment of time and effort into getting CJK-LyX/XForms up and running. Only to see ChangGil Han go on to create a CJK-LyX/Qt port in about 5 minutes. IMO, XForms is a dead project. Let's let it rest in peace. -- Angus
Re: LyX frontends
On Sat, May 14, 2005 at 05:19:54PM +0300, Martin Vermeer wrote: Yes... but then we should try to move them closer together again. Yes, some differences will remain. We should certainly have only one translatable string copy -- located in the common part outside the front ends -- for every message we send out, with few motivated exceptions. For some of the dialogs this has been done. Outside of the dialog titles (which can likely be placed in the dialog controller) I don't see how this can be trivially done. There's a few places where we can have getGUIName() for enumerations that become combo boxes, of course. regards, john
Re: LyX frontends
On Sat, May 14, 2005 at 03:33:41PM +0100, Angus Leeming wrote: Martin Vermeer wrote: Now there I agree. Which is why I think we should not just drop any front ends. We need at least two more or less useable ones to keep GUI-I alive, now that we have it. It keeps us 'honest' you mean? Fine. Precisely. I expect that in 1.5, we can combine much of the work of getting xforms to behave more similarly to qt (i.e., more modern) with moving stuff out of front-end specific code into common code. Code refactoring should be on-going, yes. However, we should drop XForms. Why? Because in 1.5 we're going to move to unicode strings and whilst it is possible to patch the underlying XForms library to understand multibyte strings, it is horrible and klunky and not something we should be wasting our time on. I know. I put a huge investment of time and effort into getting CJK-LyX/XForms up and running. Only to see ChangGil Han go on to create a CJK-LyX/Qt port in about 5 minutes. IMO, XForms is a dead project. Let's let it rest in peace. OK, but let's then make sure gtk is minimally useable before that. We shouldn't lose this investment (in GUI-I, I mean). - Martin pgpgHlFLPNUYt.pgp Description: PGP signature
Re: [PATCH 14x] spaces in file names, part I
John Levon wrote: On Thu, May 12, 2005 at 07:22:31PM +0100, Angus Leeming wrote: This patch, part I, changes nothing in LyX's operation. Well actually, that's not quite true; it enables the Qt Alert dialogs to know who their parent is so that dialogs are stacked in the correct order. Alarm bells are ringing. Gotta go now, remind me to come back to this one Ping! -- Angus
Re: LyX frontends
Martin Vermeer wrote: OK, but let's then make sure gtk is minimally useable before that. We shouldn't lose this investment (in GUI-I, I mean). What is the important legacy of the GUII project? IMO it is the clean and understandable code that has, eventually, been written. It will be trivial to maintain the LyX frontend code because it's easy to see what it does. That's not the case with the 13x dialogs, f.ex. The code in frontends/controllers baffled everybody except me :) Things are much clearer now. Transparent, even. So, whilst multiple possible frontends is somehow nice, it's not very important IMO. I'm actually quite hopeful about the ongoing health of this project. Not because it has a vibrant community of active developers; it doesn't. However, the vibrant community of semi-retired developers that it does have have, over the years, turned obfuscated line noise into coherent code. The fact that you yourself have squashed so many bugs recently is actually testement to the soundness of André's inset-unification design. I wonder if we'll ever see it completed? -- Angus
Re: [PATCH 14x] spaces in file names, part I
On Sat, May 14, 2005 at 03:52:00PM +0100, Angus Leeming wrote: This patch, part I, changes nothing in LyX's operation. Well actually, that's not quite true; it enables the Qt Alert dialogs to know who their parent is so that dialogs are stacked in the correct order. Alarm bells are ringing. Gotta go now, remind me to come back to this one Ping! Hmm, the bells may have been a little over the top. I wonder why this already works (i.e. you get modality for e.g. Load emergency save alert). Did you make sure to check that adding a parent doesn't mean that the parent GC's the widget? (I don't think so) regards john
Re: Bug report: Qt Citations BibTeX
Michael Schmitt wrote: 1. Insert List TOC BibTeX Bibliography Add Browse = Bang! Hmm, not here. Do you have a backtrace? 2. (a) Add some BibTeX bibliography (b) Insert Cross-reference (c) search entry e (d) Find Previous = Bang! I take it that (b) means Insert-Citation. I get no crash, but it's not working correctly either. I'll have a look. 3. (a) Add some BibTeX bibliography (b) Insert Cross-reference (c) search entry e (d) Find Next (multiple times) = does not work see above 4. Tools TeX Information = There is an empty entry at the top of each file list 5. Insert List TOC BibTeX Bibliography Add = There is an empty entry at the top I'll have a look. Thanks, Jürgen
Re: LyX frontends
On Sat, May 14, 2005 at 03:41:50PM +0100, John Levon wrote: On Sat, May 14, 2005 at 05:19:54PM +0300, Martin Vermeer wrote: Yes... but then we should try to move them closer together again. Yes, some differences will remain. We should certainly have only one translatable string copy -- located in the common part outside the front ends -- for every message we send out, with few motivated exceptions. For some of the dialogs this has been done. Outside of the dialog titles (which can likely be placed in the dialog controller) I don't see how this can be trivially done. There's a few places where we can have getGUIName() for enumerations that become combo boxes, of course. Trivially perhaps not... but I count 229 translatable strings in qt, 387 in xforms (OK, guilty to some of them myself) and only 119 in controllers. Surely we should have another look at those. Regards Martin pgpA40pRZCffs.pgp Description: PGP signature
Re: LyX frontends
On Sat, May 14, 2005 at 04:01:53PM +0100, Angus Leeming wrote: Martin Vermeer wrote: OK, but let's then make sure gtk is minimally useable before that. We shouldn't lose this investment (in GUI-I, I mean). What is the important legacy of the GUII project? IMO it is the clean and understandable code that has, eventually, been written. It will be trivial to maintain the LyX frontend code because it's easy to see what it does. That's not the case with the 13x dialogs, f.ex. The code in frontends/controllers baffled everybody except me :) Things are much clearer now. Transparent, even. So, whilst multiple possible frontends is somehow nice, it's not very important IMO. Entropy, Angus. That, and human nature. It's like with platform or achitecture independence: if actually using multiple platforms isn't forcing you, it _will_ slowly decay. I'm actually quite hopeful about the ongoing health of this project. Not because it has a vibrant community of active developers; it doesn't. However, the vibrant community of semi-retired developers that it does have have, over the years, turned obfuscated line noise into coherent code. The fact that you yourself have squashed so many bugs recently is actually testement to the soundness of André's inset-unification design. I wonder if we'll ever see it completed? Ask again after 1.4.0 is out :-) As for 1.4.0cvs being unstable as Michael reports, let us understand that this is still heavily instrumented code. The crash due to recursive update was in reality an assert put there precisely to find such deep problems. And we shouldn't _yet_ remove them... as we will in the production version. So we're getting a bit too pessimistic picture now, I think. Like with the speed too. - Martin pgpFQYLHe2Zf5.pgp Description: PGP signature
Re: LyX frontends
Martin Vermeer wrote: So, whilst multiple possible frontends is somehow nice, it's not very important IMO. Entropy, Angus. That, and human nature. It's like with platform or achitecture independence: if actually using multiple platforms isn't forcing you, it _will_ slowly decay. Oh, sure. That's why you'll note I was not advocating killing the gtk port. The XForms port should go, IMO, because it will become too much effort to maintain in a unicoded LyX. Personally, I'm not going to invest effort in a gtk port, but I'm not going to stand in anybody's way if that's what they want to do. The fact that you yourself have squashed so many bugs recently is actually testement to the soundness of André's inset-unification design. I wonder if we'll ever see it completed? Ask again after 1.4.0 is out :-) As for 1.4.0cvs being unstable as Michael reports, let us understand that this is still heavily instrumented code. The crash due to recursive update was in reality an assert put there precisely to find such deep problems. And we shouldn't _yet_ remove them... as we will in the production version. So we're getting a bit too pessimistic picture now, I think. Like with the speed too. As I said, I'm optimistic about LyX's future. Good code and responsible coders. -- Angus
Re: Bug report: Qt Citations BibTeX
Jürgen Spitzmüller wrote: 5. Insert List TOC BibTeX Bibliography Add = There is an empty entry at the top I'll have a look. I tried to fix that myself when adding the code to prevent a user from adding a file name with spaces if LaTeX didn't support it, (see the patch at http://article.gmane.org/gmane.editors.lyx.devel:44738) but failed. Not that I tried too hard. I'll be interested to see what the problem is. -- Angus
Re: [PATCH 14x] spaces in file names, part I
John Levon wrote:
On Sat, May 14, 2005 at 03:52:00PM +0100, Angus Leeming wrote:
This patch, part I, changes nothing in LyX's operation. Well
actually, that's not quite true; it enables the Qt Alert dialogs to
know who their parent is so that dialogs are stacked in the correct
order.
Alarm bells are ringing. Gotta go now, remind me to come back to this
one
Ping!
Hmm, the bells may have been a little over the top. I wonder why this
already works (i.e. you get modality for e.g. Load emergency save
alert). Did you make sure to check that adding a parent doesn't mean
that the parent GC's the widget? (I don't think so)
GC == GarbageCollect? No, I didn't check that. I'll do some reading...
done. We're OK. See below.
To recap, all I have done is:
QWidget * const parent =
- 0;
+ qApp-focusWidget() ? qApp-focusWidget() : qApp-mainWidget();
int res = QMessageBox::information(parent,
toqstr(title),
toqstr(formatted(question)),
toqstr(b1),
toqstr(b2),
b3.empty() ? QString::null : toqstr(b3),
default_button,
cancel_button);
If we look at the QMessageBox code, we see that the parent is passed to
the underlying QDialog together with a modal==TRUE flag.
int QMessageBox::information( QWidget *parent,
const QString caption, const QString text,
int button0, int button1, int button2 )
{
QMessageBox *mb = new QMessageBox( caption, text, Information,
button0, button1, button2,
parent, qt_msgbox_information,
TRUE, WDestructiveClose);
Q_CHECK_PTR( mb );
return mb-exec();
}
QMessageBox::QMessageBox( const QString caption,
const QString text, Icon icon,
int button0, int button1, int button2,
QWidget *parent, const char *name,
bool modal, WFlags f )
: QDialog( parent, name, modal, f | WStyle_Customize |
WStyle_DialogBorder | WStyle_Title | WStyle_SysMenu )
{
init( button0, button1, button2 );
#ifndef QT_NO_WIDGET_TOPEXTRA
setCaption( caption );
#endif
setText( text );
setIcon( icon );
}
From qdialog.cpp:
Note that QDialog uses the parent widget slightly differently from
other classes in Qt. A dialog is always a top-level widget, but if
it has a parent, its default location is centered on top of the
parent's top-level widget (if it is not top-level itself). It will
also share the parent's taskbar entry.
\target modal
\section1 Modal Dialogs
A bmodal/b dialog is a dialog that blocks input to other
visible windows in the same application. Users must finish
interacting with the dialog and close it before they can access
any other window in the application. Dialogs that are used to
request a file name from the user or that are used to set
application preferences are usually modal.
Given that the QDialog destroys itself (the WDestructiveClose flag is set)
before leaving the exec() function, I don't think that we have anything to
worry about.
Now are you happier?
--
Angus
Re: Bug report: Qt Citations BibTeX
Angus Leeming wrote:
I tried to fix that myself when adding the code to prevent a user from
adding a file name with spaces if LaTeX didn't support it, (see the
patch at http://article.gmane.org/gmane.editors.lyx.devel:44738) but
failed. Not that I tried too hard. I'll be interested to see what the
problem is.
The following fixes it for me on a general level. I have also added some code
to sort the items correctly (they have not because the vector is sorted with
the path, which is not displayed).
Does it look sensible?
Jürgen
Index: frontends/controllers/ControlBibtex.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ControlBibtex.C,v
retrieving revision 1.46
diff -u -r1.46 ControlBibtex.C
--- frontends/controllers/ControlBibtex.C 25 Nov 2004 11:08:30 - 1.46
+++ frontends/controllers/ControlBibtex.C 14 May 2005 16:55:44 -
@@ -79,6 +79,8 @@
for (; it != end; ++it) {
*it = OnlyFilename(*it);
}
+ // sort on filename only (no path)
+ std::sort(data.begin(), data.end());
}
@@ -97,6 +99,8 @@
for (; it != end; ++it) {
*it = OnlyFilename(*it);
}
+ // sort on filename only (no path)
+ std::sort(data.begin(), data.end());
}
Index: frontends/controllers/tex_helpers.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/tex_helpers.C,v
retrieving revision 1.24
diff -u -r1.24 tex_helpers.C
--- frontends/controllers/tex_helpers.C 17 Jan 2005 18:54:01 - 1.24
+++ frontends/controllers/tex_helpers.C 14 May 2005 16:55:45 -
@@ -79,7 +79,12 @@
std::vectorstring::iterator it = list.begin();
std::vectorstring::iterator end = list.end();
for (; it != end; ++it) {
- *it = regex.Merge((*it), /);
+ string const item = regex.Merge((*it), /);
+ // don't add empty items.
+ if (!item.empty())
+ *it = item;
+ else
+ list.erase(it, end);
}
eliminate_duplicates(list);
Index: frontends/qt2/QTexinfo.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QTexinfo.C,v
retrieving revision 1.27
diff -u -r1.27 QTexinfo.C
--- frontends/qt2/QTexinfo.C 12 May 2005 23:12:43 - 1.27
+++ frontends/qt2/QTexinfo.C 14 May 2005 16:55:47 -
@@ -62,6 +62,10 @@
dialog_-fileList-insertItem(toqstr(line));
}
+ // resort if filename only (because of missing path)
+ if (!withFullPath)
+ dialog_-fileList-sort();
+
activeStyle = whichStyle;
}
Re: Bug report: Qt Citations BibTeX
Juergen Spitzmueller wrote: 2. (a) Add some BibTeX bibliography (b) Insert Cross-reference (c) search entry e (d) Find Previous = Bang! I take it that (b) means Insert-Citation. I get no crash, but it's not working correctly either. I'll have a look. 3. (a) Add some BibTeX bibliography (b) Insert Cross-reference (c) search entry e (d) Find Next (multiple times) = does not work see above The attached fixes it for me. Both setSelected and setCurrentItem are necessary, probably because we now have multi selection mode in that browser (i.e. you can select multiple citation entries at once). Please test. Jürgen Index: QCitationDialog.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QCitationDialog.C,v retrieving revision 1.33 diff -u -r1.33 QCitationDialog.C --- QCitationDialog.C 2 Jun 2004 20:13:18 - 1.33 +++ QCitationDialog.C 14 May 2005 17:42:05 - @@ -283,6 +283,7 @@ // Update the display add_-availableLB-setSelected(found, true); + add_-availableLB-setCurrentItem(found); add_-availableLB-ensureCurrentVisible(); }
Re: [PATCH 14x] spaces in file names, part I
On Sat, May 14, 2005 at 04:28:52PM +0100, Angus Leeming wrote: Given that the QDialog destroys itself (the WDestructiveClose flag is set) Yes, that's the ticket. john
Re: Bug report: Qt Citations BibTeX
Juergen Spitzmueller wrote: Index: frontends/qt2/QTexinfo.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QTexinfo.C,v retrieving revision 1.27 diff -u -r1.27 QTexinfo.C --- frontends/qt2/QTexinfo.C12 May 2005 23:12:43 - 1.27 +++ frontends/qt2/QTexinfo.C14 May 2005 16:55:47 - @@ -62,6 +62,10 @@ dialog_-fileList-insertItem(toqstr(line)); } + // resort if filename only (because of missing path) + if (!withFullPath) + dialog_-fileList-sort(); This does not work (the vector itself has to be reordered). I send a better patch tomorrow. Jürgen
math panel symbol
Hello LyXers, what is the name of the xpm for the QT math panel symbol Sets limits style? Thanks and regards Uwe
Re: [Patch] Re: Timing experiments
On Fri, May 13, 2005 at 09:46:29PM +0300, Martin Vermeer wrote:
Actually it should be noted that paintText called from LyXScreen::redraw
still draws _three_ paragraphs: the one containing the cursor, and the
ones above and below, see rowpainter.C. I'm sure there is a good reason
for this when redrawing the whole screen...
We need up-to-date metrics in the paragraph below to handle e.g. Down
when the cursor is in the last line of a paragraph.
I think this was the reason before the null painter was invented...
we could easily propagate the bool onlypar (by adding it to
ViewMetricsInfo?) to prevent also this, giving a further speed-up.
Is this a sensible direction?
I think so.
-void BufferView::update(bool fitcursor, bool forceupdate)
+void BufferView::update(bool fitcursor, bool forceupdate, bool onlypar)
{
- pimpl_-update(fitcursor, forceupdate);
+ pimpl_-update(fitcursor, forceupdate, onlypar);
}
Pretty much looks like the old update flags now. I knew there must have
been a reason...
enum UpdateFlags { UpdateFitCursor = 1, UpdateForce = 2, UpdateOnlyPar =
4 };
+ void update(UpdateFlags = UpdateFitCursor | UpdateForce);
This makes things like
+ cur.bv().update(false, true, true);
a bit mmore readble:
cur.bv().update(UpdateForce | UpdateOnlyPar);
Andre'
Re: LyX frontends
On Sat, May 14, 2005 at 12:42:21PM +0200, Michael Schmitt wrote: My initial tests of the Qt frontend told me that it is far away from being stable. Actually, it seems like some stuff is broken that worked very well in 1.3 before. Once again, I would like to raise the question on whether we can really afford to maintain more than one frontend. I think the question is answered: we can't. Wouldn't it make sense to remove even the xforms frontend for 1.4? Who is actually using/testing it? I think one really good frontend is better than two half-heartedly tested frontends. I am using xforms, Konni is using xforms, but xforms has to go the way of the dodo... Andre'
Re: [Patch] Re: Timing experiments
On Fri, May 13, 2005 at 11:15:02PM +0300, Martin Vermeer wrote: @@ -1229,7 +1221,6 @@ // real_current_font.number can change so we need to // update the minibuffer if (old_font != real_current_font) - bv-owner()-view_state_changed(); bv-updateScrollbar(); break; } and Andre deleted lots of other bv-owner()-view_state_changed(); in that same patch. I suspect the if should go. Andre should know. Aehm... yes. Drop the if. Andre'
Re: Profiling LyX-140 on Mac
On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote: On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote: So why not solve that he other way round: Do not blink the cursor unless all draws have been finished? I thought that's what Martin was planning (and it certainly sounds right) Oh I see. I was swamped with messages suggesting that we try to hide the problem using some well-tuned timer Andre'
Re: LyX frontends
On Sat, May 14, 2005 at 05:45:55PM +0300, Martin Vermeer wrote: OK, but let's then make sure gtk is minimally useable before that. We shouldn't lose this investment (in GUI-I, I mean). The GUI-I investment has already payed off by separating GUI and core. Right now and in a foreseeable future, it will be a burden. A big one. Andre'
Re: LyX frontends
On Sat, May 14, 2005 at 03:57:23PM +0300, Martin Vermeer wrote: OK, but that tells us also something about the current state of incompleteness of GUI-I. Ideally, the front ends should only define a set of primitives that the rest of LyX then uses. I am thinking of a termcap type parametrization thingy, but graphically. I doubt that we will ever get quite that far (if even possible), but we can certainly get farther than we are now. In my understanding there is _no reason at all_ why _any_ translatable strings should be front end specific / part of the front-end code. Unfortunately many today are. You know that, John: you've been duplicating Qt strings rather than re-using them as you would under a sane architecture... Other than that, the proposal is OK if it is easily reversible later. Putting in an extra abstraction layer between LyX core and Qt is quite some work to set up and to maintain for no good reason if Qt is the only supported frontend. We simply don't have the capacities to do that. GUI-I was a very big step for LyX in the light of dividing-and- conquering the pile of LyX was structurally at some point of time. Basically, maintaining a working frontend is minimal effort, so I don't think that it matters if someone wants to have a pet project porting to his/her favourite toolkit. Ideally, the maintenance should be _zero_ work, see above. Not true. You need to maintain a separate astraction layer. And by not committing to a single frontend you loose all the goodies. Just think about all the work Angus put in to come up something resembling QProcess, or QSettings. Andre' PS: I don't think Qt is perfect. But it seems to be the best option we have.
Re: LyX frontends
On Sat, May 14, 2005 at 05:19:54PM +0300, Martin Vermeer wrote: Now there I agree. Which is why I think we should not just drop any front ends. We need at least two more or less useable ones to keep GUI-I alive, now that we have it. GUI-I has done its duty, let it die. What do we _really_ gain by maintaining separate frontends and what do we lose by not committing to a single one? If you weigh both sides, the result should be obvious. Andre'
Re: Profiling LyX-140 on Mac
On Sat, May 14, 2005 at 04:02:10PM +0300, Martin Vermeer wrote: On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote: On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote: So why not solve that he other way round: Do not blink the cursor unless all draws have been finished? I thought that's what Martin was planning (and it certainly sounds right) I'm note sure we are talking about the same thing now. Anyway I am happy the way things have turned out with Lars' cache (though I still don't grok it). I don't thing anything based on tweaking timers is a conceptionally sound solution. It miht work, and this might all we need to get 1.4 out of the door, but it does not sound right. Andre'
Re: LyX frontends
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Code refactoring should be on-going, yes. However, we should Angus drop XForms. Note that we can't drop xforms until gtk stops depending on it. JMarc
Re: Profiling LyX-140 on Mac
On Sat, May 14, 2005 at 08:42:08PM +0200, Andre Poenitz wrote: On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote: On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote: So why not solve that he other way round: Do not blink the cursor unless all draws have been finished? I thought that's what Martin was planning (and it certainly sounds right) Oh I see. I was swamped with messages suggesting that we try to hide the problem using some well-tuned timer ...and I have a nagging suspicion that that is what Lars' solution amounts to, but he tells me no... - Martin pgpAS7VKCh0a1.pgp Description: PGP signature
Re: LyX frontends
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin The above. I believe the _translator_ load per front end can Martin be brought down to close to zero; as for the _coding_ load Martin caused by the ongoing evolution of the LyX core code, that of Martin course will never be zero short of a pure termcap-style Martin primitives architecture. If the xforms frontend was changed to denote shortcuts the Qt wat instaed of the LyX way|w, we would already gain a lot on translations, since most frontends strings have no reason to be different. This does not need a monstruous frontend. Of course, a different solution is to build a wxWindows frontend, but I do not see who is going to do that... JMarc
Re: LyX meeting in Paris. When?
Michael == Michael Schmitt [EMAIL PROTECTED] writes: Michael Martin Vermeer wrote: So, what could be the 4-5 day core time that we should all try to be there? Th 14 - Mo 18 July? I have to start ordering tickets... Michael BTW: I intend to go by train. How difficult is it to get to Michael your apartment from Paris railway station? (In particular, if Michael you do not speak French :-)) Depending on where you come from in Germany, you will arrive at Gare de l'Est (East station) or Gare du Nord (North Station), which are in the same area (~500m distance). From there you will be able to go directly to either my appartment or my parent's house (depending on where we choose the HQ). JMarc
Re: LyX meeting in Paris. When?
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin So, what could be the 4-5 day core time that we should all Martin try to be there? Th 14 - Mo 18 July? I have to start ordering Martin tickets... It seems that this particular week-end is indeed the one that interests the most people. The only problem I have is that, considering the number of people who are going to come, my 90m2 apartment will be a bit small to provide accommodation (6 people is OK, more means less comfort). I have a plan B, which is to ask my sister whether we can sleep in her home, but I have not been able yet to know when she will be away (probably only for the second week-end, Jul 23-24). Other than that we have plan C, in my parents' house with a nice garden and plenty of space. I have confirmed with them that I can kick them out whenever we want :) The place is nicer, but the city is in a (nice but) boring suburb. So it depends on whether you prefer to be in Paris. Less space, but probably more fun, and much more places where we can go by foot (Montmartre can be really nice at night). Finally, if we decide to keep Jul 14-18, I have to warn you that Jul 14 is our national holiday [*], but I do not know the kind of effect it can have on traffic. So, what day do you all prefer? JMarc [*] which is not called ``Bastille Day'', as some would want you to think, but boringly enough ``14-Juillet''
Re: LyX meeting in Paris. When?
On Sat, May 14, 2005 at 11:54:35PM +0200, Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin So, what could be the 4-5 day core time that we should all Martin try to be there? Th 14 - Mo 18 July? I have to start ordering Martin tickets... It seems that this particular week-end is indeed the one that interests the most people. The only problem I have is that, considering the number of people who are going to come, my 90m2 apartment will be a bit small to provide accommodation (6 people is OK, more means less comfort). I have a plan B, which is to ask my sister whether we can sleep in her home, but I have not been able yet to know when she will be away (probably only for the second week-end, Jul 23-24). Other than that we have plan C, in my parents' house with a nice garden and plenty of space. I have confirmed with them that I can kick them out whenever we want :) The place is nicer, but the city is in a (nice but) boring suburb. Is it close to a metro station? So it depends on whether you prefer to be in Paris. Less space, but probably more fun, and much more places where we can go by foot (Montmartre can be really nice at night). Finally, if we decide to keep Jul 14-18, I have to warn you that Jul 14 is our national holiday [*], but I do not know the kind of effect it can have on traffic. Would 15-19 July then be better? The guided tour at INRIA could then be on 18 July :-) So, what day do you all prefer? JMarc [*] which is not called ``Bastille Day'', as some would want you to think, but boringly enough ``14-Juillet'' - Martin pgp4YiBkS043B.pgp Description: PGP signature
Re: LyX meeting in Paris. When?
On Wed, May 11, 2005 at 04:18:19PM +0200, Jean-Marc Lasgouttes wrote: > > "Asger" == Asger Alstrup <[EMAIL PROTECTED]> writes: > > Asger> I agree with Lars that it is due time to decide the date, and > Asger> the 16th looks like the clear winner. Jean-Marc, what do you > Asger> say? > > The 16th looks good. I suspect that there will be too many people > present to be able to work in decent condition in my Paris flat, so I > have to check that we will be able to use my parent's house. I'll tell > you more tomorrow, I guess. ...and the result...? So, what could be the 4-5 day "core" time that we should all try to be there? Th 14 - Mo 18 July? I have to start ordering tickets... BTW I will be out of circulation (field work) the coming two weeks. To add to the fun, my ssh tunnel to the job machine (where I have the LyX tree) crashed last night (as did the backup tunnel on this university machine, so probably a power cut at our department), and I am writing this on old, hateful Bill Joy's vi rather than vim. That's where those funny characters come from :-) - Martin A A A A
Re: [Patch] Re: Timing experiments
Martin Vermeer wrote: > On Fri, May 13, 2005 at 09:48:45PM +0200, Alfredo Braunstein wrote: >> Martin Vermeer wrote: >> >> > // real_current_font.number can change so we need to >> > // update the minibuffer >> > if (old_font != real_current_font) >> > -bv->updateScrollbar(); >> > +bv->updateScrollbar(); >> > break; >> > } >> > >> >> Btw it seems that the last +- correction chunk is not an error in >> tabulation, rather that the block inside the if above was inadvertently >> deleted. > > There was no block. The diff of versions 2.32 - 2.31 looks like This is what I meant. > @@ -1229,7 +1221,6 @@ > // real_current_font.number can change so we need to > // update the minibuffer > if (old_font != real_current_font) > - bv->owner()->view_state_changed(); > bv->updateScrollbar(); > break; > } > > and Andre deleted lots of other bv->owner()->view_state_changed(); > in that same patch. > > I suspect the if should go. Andre should know. That's my suspicion. Alfredo
Re: LyX meeting in Paris. When?
Martin Vermeer wrote: So, what could be the 4-5 day "core" time that we should all try to be there? Th 14 - Mo 18 July? I have to start ordering tickets... BTW: I intend to go by train. How difficult is it to get to your apartment from Paris railway station? (In particular, if you do not speak French :-)) Michael
Re: [patch] key event queue
Andre Poenitz wrote: > Could you just comment out the whole body of LengthCombo::noPercents() > in src/frontend/qt2/lengthcombo.C (this is lines 62-69 or so) > and try again? It would certainly be a big surprise if that function would be called while typing. Jürgen
Bug report: Qt Citations & BibTeX
Hi, a couple of small bug reports regarding the Qt frontend: 1. Insert > List & TOC > BibTeX Bibliography > Add > Browse => Bang! 2. (a) Add some BibTeX bibliography (b) Insert > Cross-reference (c) search entry "e" (d) Find Previous => Bang! 3. (a) Add some BibTeX bibliography (b) Insert > Cross-reference (c) search entry "e" (d) Find Next (multiple times) => does not work 4. Tools > TeX Information => There is an empty entry at the top of each file list 5. Insert > List & TOC > BibTeX Bibliography > Add => There is an empty entry at the top Michael
LyX frontends
Hi, I am wondering about the role of the various frontends with regard to LyX 1.4. At least "gnome" and "gtk" are not usable right now and I would like to propose to 1. remove "gnome" from the CVS because it is no longer used 2. remove all "gtk" files from POTFILES so that gtk messages will not show up in the po files. My initial tests of the Qt frontend told me that it is far away from being stable. Actually, it seems like some stuff is broken that worked very well in 1.3 before. Once again, I would like to raise the question on whether we can really afford to maintain more than one frontend. Wouldn't it make sense to remove even the xforms frontend for 1.4? Who is actually using/testing it? I think one really good frontend is better than two half-heartedly tested frontends. Regards, Michael
Re: LyX frontends
Michael Schmitt wrote: > Once again, I would like to raise the question > on whether we can really afford to maintain more than one frontend. > Wouldn't it make sense to remove even the xforms frontend for 1.4? Who > is actually using/testing it? I think one really good frontend is better > than two half-heartedly tested frontends. My take on this is that we should * have one *official* frontend, Qt, after 1.4 is out. * ditch XForms after 1.4 is out. * send the gnome port to the Attic now. * leave the gtk port alone. Nobody is *required* to work on it. If John Spray wants to work on it, then who am I to tell him not to? Basically, maintaining a working frontend is minimal effort, so I don't think that it matters if someone wants to have a pet project porting to his/her favourite toolkit. -- Angus
[Patch] Re: Timing experiments
On Fri, May 13, 2005 at 10:43:52PM +0200, Andre Poenitz wrote:
> > Does that look like a plan?
>
> Yes.
Here is the latest state of the patch. Have your pleasure with it :-)
I'll be out for two weeks starting Monday.
- Martin
Index: BufferView.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.C,v
retrieving revision 1.260
diff -u -p -r1.260 BufferView.C
--- BufferView.C22 Feb 2005 11:41:19 - 1.260
+++ BufferView.C14 May 2005 11:02:58 -
@@ -142,9 +142,9 @@ bool BufferView::fitCursor()
}
-void BufferView::update(bool fitcursor, bool forceupdate)
+void BufferView::update(bool fitcursor, bool forceupdate, bool singlepar)
{
- pimpl_->update(fitcursor, forceupdate);
+ pimpl_->update(fitcursor, forceupdate, singlepar);
}
Index: BufferView.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.h,v
retrieving revision 1.186
diff -u -p -r1.186 BufferView.h
--- BufferView.h26 Apr 2005 11:12:09 - 1.186
+++ BufferView.h14 May 2005 11:02:58 -
@@ -81,7 +81,8 @@ public:
* position changes. \c forceupdate means to force an update
* in any case.
*/
- void update(bool fitcursor = true, bool forceupdate = true);
+ void update(bool fitcursor = true, bool forceupdate = true,
+ bool singlepar = false);
/// move the screen to fit the cursor. Only to be called with
/// good y coordinates (after a bv::metrics)
bool fitCursor();
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.583
diff -u -p -r1.583 BufferView_pimpl.C
--- BufferView_pimpl.C 11 May 2005 07:44:18 - 1.583
+++ BufferView_pimpl.C 14 May 2005 11:02:58 -
@@ -606,7 +606,8 @@ bool BufferView::Pimpl::fitCursor()
}
-void BufferView::Pimpl::update(bool fitcursor, bool forceupdate)
+void BufferView::Pimpl::update(bool fitcursor, bool forceupdate,
+ bool singlepar)
{
lyxerr << BOOST_CURRENT_FUNCTION
<< "[fitcursor = " << fitcursor << ','
@@ -635,7 +636,7 @@ void BufferView::Pimpl::update(bool fitc
if (fitcursor && fitCursor()) {
forceupdate = true;
- vi = metrics();
+ vi = metrics(singlepar);
}
if (forceupdate) {
// Second drawing step
@@ -1246,7 +1247,7 @@ bool BufferView::Pimpl::dispatch(FuncReq
}
-ViewMetricsInfo BufferView::Pimpl::metrics()
+ViewMetricsInfo BufferView::Pimpl::metrics(bool singlepar)
{
// Remove old position cache
theCoords.clear();
@@ -1274,7 +1275,7 @@ ViewMetricsInfo BufferView::Pimpl::metri
// Redo paragraphs above cursor if necessary
int y1 = y0;
- while (y1 > 0 && pit1 > 0) {
+ while (!singlepar && y1 > 0 && pit1 > 0) {
y1 -= text->getPar(pit1).ascent();
--pit1;
text->redoParagraph(pit1);
@@ -1298,7 +1299,7 @@ ViewMetricsInfo BufferView::Pimpl::metri
// Redo paragraphs below cursor if necessary
int y2 = y0;
- while (y2 < bv.workHeight() && pit2 < int(npit) - 1) {
+ while (!singlepar && y2 < bv.workHeight() && pit2 < int(npit) - 1) {
y2 += text->getPar(pit2).descent();
++pit2;
text->redoParagraph(pit2);
@@ -1321,5 +1322,5 @@ ViewMetricsInfo BufferView::Pimpl::metri
<< " y2: " << y2
<< endl;
- return ViewMetricsInfo(pit1, pit2, y1, y2);
+ return ViewMetricsInfo(pit1, pit2, y1, y2, singlepar);
}
Index: BufferView_pimpl.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.h,v
retrieving revision 1.127
diff -u -p -r1.127 BufferView_pimpl.h
--- BufferView_pimpl.h 19 Jan 2005 15:03:26 - 1.127
+++ BufferView_pimpl.h 14 May 2005 11:02:58 -
@@ -60,7 +60,8 @@ public:
//
bool fitCursor();
///
- void update(bool fitcursor = false, bool forceupdate = true);
+ void update(bool fitcursor = false, bool forceupdate = true,
+ bool singlepar = false);
///
void newFile(std::string const &, std::string const &, bool);
///
@@ -186,7 +187,7 @@ private:
///
int offset_ref_;
///
- ViewMetricsInfo metrics();
+ ViewMetricsInfo metrics(bool singlepar = false);
};
Index: dimension.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/dimension.h,v
retrieving revision 1.6
diff -u -p -r1.6 dimension.h
---
Re: LyX frontends
On Sat, 2005-05-14 at 12:08 +0100, Angus Leeming wrote: > My take on this is that we should > * have one *official* frontend, Qt, after 1.4 is out. Makes sense, although whether distributors package it like that is up to them. > * send the gnome port to the Attic now. Yes. If one ever wants to refer to it it will still be findable. Right now it's just confusing to anyone who is new to the repository. > * leave the gtk port alone. Nobody is *required* to work on it. If John > Spray wants to work on it, then who am I to tell him not to? Indeed :-) I think that Michael was saying that the gtk frontend was causing extra work for translators. If that is causing a problem, I would accept leaving the gtk frontend untranslated until it reaches a state of usability. > Basically, maintaining a working frontend is minimal effort, so I don't > think that it matters if someone wants to have a pet project porting to > his/her favourite toolkit. I would agree with this: getting rid of the GUI independent stuff would be a lot of work, for no massive gain. Since it's there, it might as well stay to make LyX agile in the future as deployed desktop environments come and go. John
Re: Profiling LyX-140 on Mac
On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote: > So why not solve that he other way round: Do not blink the cursor unless > all draws have been finished? I thought that's what Martin was planning (and it certainly sounds right) regards john
Re: LyX frontends
On Sat, May 14, 2005 at 12:19:38PM +0100, John Spray wrote: > On Sat, 2005-05-14 at 12:08 +0100, Angus Leeming wrote: > > * send the gnome port to the Attic now. > Yes. If one ever wants to refer to it it will still be findable. Right > now it's just confusing to anyone who is new to the repository. > > > * leave the gtk port alone. Nobody is *required* to work on it. If John > > Spray wants to work on it, then who am I to tell him not to? > Indeed :-) > I think that Michael was saying that the gtk frontend was causing extra > work for translators. If that is causing a problem, I would accept > leaving the gtk frontend untranslated until it reaches a state of > usability. OK, but that tells us also something about the current state of incompleteness of GUI-I. Ideally, the front ends should only define a set of primitives that the rest of LyX then uses. I am thinking of a termcap type parametrization thingy, but graphically. I doubt that we will ever get quite that far (if even possible), but we can certainly get farther than we are now. In my understanding there is _no reason at all_ why _any_ translatable strings should be front end specific / part of the front-end code. Unfortunately many today are. You know that, John: you've been duplicating Qt strings rather than re-using them as you would under a sane architecture... Other than that, the proposal is OK if it is easily reversible later. > > Basically, maintaining a working frontend is minimal effort, so I don't > > think that it matters if someone wants to have a pet project porting to > > his/her favourite toolkit. Ideally, the maintenance should be _zero_ work, see above. The primitives shouldn't change. We should get closer to that. > I would agree with this: getting rid of the GUI independent stuff would > be a lot of work, for no massive gain. Since it's there, it might as > well stay to make LyX agile in the future as deployed desktop > environments come and go. Hear, hear. - Martin pgpaLj8gLHHUQ.pgp Description: PGP signature
Re: Profiling LyX-140 on Mac
On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote: > On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote: > > > So why not solve that he other way round: Do not blink the cursor unless > > all draws have been finished? > > I thought that's what Martin was planning (and it certainly sounds > right) I'm note sure we are talking about the same thing now. Anyway I am happy the way things have turned out with Lars' cache (though I still don't grok it). - Martin pgpMcwK4CjNos.pgp Description: PGP signature
Re: 2 questions regarding qt2 frontend
Hi Jean-Marc, > Hammer> On MacOsX the options doens'nt seems active. I got an "unknown > Hammer> option" error. > > Forget about it, this is done by qt/x11. > > Hammer> QSessions seems quite easy. I will give it try. > > But It seems to me that they do not provide much that cannot be done > by hand... It seems that I miss their point. I think I know what you mean. After digging in the code, perhaps the lyx "preferences" file would be a better place to store and retrieve the geometry settings. We could add 4 new settings in the "Screen & Font Section" \screen_geometry_xpos \screen_geometry_ypos \screen_geometry_width \screen_geometry_height As far as i can see, the preferences file will only be written if the settings has been changed using a gui dialog. Which procedure would be better? automatically store on exit or add some gui elements to store it manually? mit freundlichen Gruessen / Yours Armin Hammer === http://www.ahammer.ch -- PGP public key on request
Re: LyX frontends
On Sat, May 14, 2005 at 03:57:23PM +0300, Martin Vermeer wrote: > OK, but that tells us also something about the current state of > incompleteness of GUI-I. Ideally, the front ends should only define a > set of primitives that the rest of LyX then uses. I am thinking of a > termcap type parametrization thingy, but graphically. I sincerely hope you're not bringing up the idea I think you might be. No, 'frontends provide method for drawing combos, everything else is GUII' is not where we want to be. > can certainly get farther than we are now. In my understanding there is > _no reason at all_ why _any_ translatable strings should be front end This is not true, actually. Different platforms have all sorts of different rules on how we present data. Historically, the biggest difference has been that xforms remains close to 'classic' LyX, whereas in Qt we were free to use higher-order views, and experiment with the UI. One example is that we still differ on the rules used for tooltips between the two frontends. Gnome will again have different rules. I'm all for Michael's work in reducing translator load (so far), but this will not extend to the point where lowest-common-denominator UIs are the only option. I don't see an architectural approach to reducing this load; what do you have in mind? Multiple frontends has never been a serious portion of the maintainer load; it's generally been (originally) the hulking mass of old kernel code; currently it's the serious stability problems of the new code. regards, john
Re: 2 questions regarding qt2 frontend
On Sat, May 14, 2005 at 03:08:12PM +0200, Hammer Armin wrote: > I think I know what you mean. After digging in the code, perhaps > the lyx "preferences" file would be a better place to store and retrieve > the geometry settings. We'd need to implement the session saving code that happens when e.g. the window manager shuts down. regards, john
Re: LyX frontends
On Sat, May 14, 2005 at 02:11:21PM +0100, John Levon wrote: > On Sat, May 14, 2005 at 03:57:23PM +0300, Martin Vermeer wrote: > > > OK, but that tells us also something about the current state of > > incompleteness of GUI-I. Ideally, the front ends should only define a > > set of primitives that the rest of LyX then uses. I am thinking of a > > termcap type parametrization thingy, but graphically. > > I sincerely hope you're not bringing up the idea I think you might be. > No, 'frontends provide method for drawing combos, everything else is > GUII' is not where we want to be. No, that is out. Too late now, if it were ever possible. > > can certainly get farther than we are now. In my understanding there is > > _no reason at all_ why _any_ translatable strings should be front end > > This is not true, actually. Different platforms have all sorts of > different rules on how we present data. Historically, the biggest > difference has been that xforms remains close to 'classic' LyX, whereas > in Qt we were free to use higher-order views, and experiment with the > UI. One example is that we still differ on the rules used for tooltips > between the two frontends. Yes... but then we should try to move them closer together again. Yes, some differences will remain. We should certainly have only one translatable string copy -- located in the common part outside the front ends -- for every message we send out, with few motivated exceptions. For some of the dialogs this has been done. > Gnome will again have different rules. I'm all for Michael's work in > reducing translator load (so far), but this will not extend to > the point where lowest-common-denominator UIs are the only option. > > I don't see an architectural approach to reducing this load; what do you > have in mind? The above. I believe the _translator_ load per front end can be brought down to close to zero; as for the _coding_ load caused by the ongoing evolution of the LyX core code, that of course will never be zero short of a pure termcap-style primitives architecture. > Multiple frontends has never been a serious portion of the maintainer > load; it's generally been (originally) the hulking mass of old kernel > code; currently it's the serious stability problems of the new code. Now there I agree. Which is why I think we should not just "drop" any front ends. We need at least two more or less useable ones to keep GUI-I alive, now that we have it. I expect that in 1.5, we can combine much of the work of getting xforms to behave more similarly to qt (i.e., more modern) with moving stuff out of front-end specific code into common code. > regards, > john Regards Martin pgp93EfhbYpBs.pgp Description: PGP signature
Re: LyX frontends
Martin Vermeer wrote: > Now there I agree. Which is why I think we should not just "drop" any > front ends. We need at least two more or less useable ones to keep GUI-I > alive, now that we have it. It keeps us 'honest' you mean? Fine. > I expect that in 1.5, we can combine much of the work of getting xforms > to behave more similarly to qt (i.e., more modern) with moving stuff out > of front-end specific code into common code. Code refactoring should be on-going, yes. However, we should drop XForms. Why? Because in 1.5 we're going to move to unicode strings and whilst it is possible to patch the underlying XForms library to understand multibyte strings, it is horrible and klunky and not something we should be wasting our time on. I know. I put a huge investment of time and effort into getting CJK-LyX/XForms up and running. Only to see ChangGil Han go on to create a CJK-LyX/Qt port in about 5 minutes. IMO, XForms is a dead project. Let's let it rest in peace. -- Angus
Re: LyX frontends
On Sat, May 14, 2005 at 05:19:54PM +0300, Martin Vermeer wrote: > Yes... but then we should try to move them closer together again. Yes, > some differences will remain. We should certainly have only one > translatable string copy -- located in the common part outside the front > ends -- for every message we send out, with few motivated exceptions. > For some of the dialogs this has been done. Outside of the dialog titles (which can likely be placed in the dialog controller) I don't see how this can be trivially done. There's a few places where we can have getGUIName() for enumerations that become combo boxes, of course. regards, john
Re: LyX frontends
On Sat, May 14, 2005 at 03:33:41PM +0100, Angus Leeming wrote: > Martin Vermeer wrote: > > Now there I agree. Which is why I think we should not just "drop" any > > front ends. We need at least two more or less useable ones to keep GUI-I > > alive, now that we have it. > > It keeps us 'honest' you mean? Fine. Precisely. > > I expect that in 1.5, we can combine much of the work of getting xforms > > to behave more similarly to qt (i.e., more modern) with moving stuff out > > of front-end specific code into common code. > > Code refactoring should be on-going, yes. However, we should drop XForms. > Why? Because in 1.5 we're going to move to unicode strings and whilst it > is possible to patch the underlying XForms library to understand multibyte > strings, it is horrible and klunky and not something we should be wasting > our time on. > > I know. I put a huge investment of time and effort into getting > CJK-LyX/XForms up and running. Only to see ChangGil Han go on to create a > CJK-LyX/Qt port in about 5 minutes. > > IMO, XForms is a dead project. Let's let it rest in peace. OK, but let's then make sure gtk is minimally useable before that. We shouldn't lose this investment (in GUI-I, I mean). - Martin pgpgHlFLPNUYt.pgp Description: PGP signature
Re: [PATCH 14x] spaces in file names, part I
John Levon wrote: > On Thu, May 12, 2005 at 07:22:31PM +0100, Angus Leeming wrote: > >> This patch, part I, changes nothing in LyX's operation. Well actually, >> that's not quite true; it enables the Qt Alert dialogs to know who their >> parent is so that dialogs are stacked in the correct order. > > Alarm bells are ringing. Gotta go now, remind me to come back to this > one Ping! -- Angus
Re: LyX frontends
Martin Vermeer wrote: > OK, but let's then make sure gtk is minimally useable before that. We > shouldn't lose this investment (in GUI-I, I mean). What is the important legacy of the GUII project? IMO it is the clean and understandable code that has, eventually, been written. It will be trivial to maintain the LyX frontend code because it's easy to see what it does. That's not the case with the 13x dialogs, f.ex. The code in frontends/controllers baffled everybody except me :) Things are much clearer now. Transparent, even. So, whilst multiple possible frontends is somehow "nice", it's not very important IMO. I'm actually quite hopeful about the ongoing health of this project. Not because it has a vibrant community of active developers; it doesn't. However, the vibrant community of semi-retired developers that it does have have, over the years, turned obfuscated line noise into coherent code. The fact that you yourself have squashed so many bugs recently is actually testement to the soundness of André's inset-unification design. I wonder if we'll ever see it completed? -- Angus
Re: [PATCH 14x] spaces in file names, part I
On Sat, May 14, 2005 at 03:52:00PM +0100, Angus Leeming wrote: > >> This patch, part I, changes nothing in LyX's operation. Well actually, > >> that's not quite true; it enables the Qt Alert dialogs to know who their > >> parent is so that dialogs are stacked in the correct order. > > > > Alarm bells are ringing. Gotta go now, remind me to come back to this > > one > > Ping! Hmm, the bells may have been a little over the top. I wonder why this already works (i.e. you get modality for e.g. Load emergency save alert). Did you make sure to check that adding a parent doesn't mean that the parent GC's the widget? (I don't think so) regards john
Re: Bug report: Qt Citations & BibTeX
Michael Schmitt wrote: > 1. Insert > List & TOC > BibTeX Bibliography > Add > Browse => Bang! Hmm, not here. Do you have a backtrace? > 2. (a) Add some BibTeX bibliography (b) Insert > Cross-reference (c) > search entry "e" (d) Find Previous => Bang! I take it that (b) means Insert->Citation. I get no crash, but it's not working correctly either. I'll have a look. > 3. (a) Add some BibTeX bibliography (b) Insert > Cross-reference (c) > search entry "e" (d) Find Next (multiple times) => does not work see above > 4. Tools > TeX Information => There is an empty entry at the top of each > file list > > 5. Insert > List & TOC > BibTeX Bibliography > Add => There is an empty > entry at the top I'll have a look. Thanks, Jürgen
Re: LyX frontends
On Sat, May 14, 2005 at 03:41:50PM +0100, John Levon wrote: > On Sat, May 14, 2005 at 05:19:54PM +0300, Martin Vermeer wrote: > > > Yes... but then we should try to move them closer together again. Yes, > > some differences will remain. We should certainly have only one > > translatable string copy -- located in the common part outside the front > > ends -- for every message we send out, with few motivated exceptions. > > For some of the dialogs this has been done. > > Outside of the dialog titles (which can likely be placed in the dialog > controller) I don't see how this can be trivially done. There's a few > places where we can have getGUIName() for enumerations that become combo > boxes, of course. Trivially perhaps not... but I count 229 translatable strings in qt, 387 in xforms (OK, guilty to some of them myself) and only 119 in controllers. Surely we should have another look at those. Regards Martin pgpA40pRZCffs.pgp Description: PGP signature
Re: LyX frontends
On Sat, May 14, 2005 at 04:01:53PM +0100, Angus Leeming wrote: > Martin Vermeer wrote: > > OK, but let's then make sure gtk is minimally useable before that. We > > shouldn't lose this investment (in GUI-I, I mean). > > What is the important legacy of the GUII project? IMO it is the clean and > understandable code that has, eventually, been written. It will be trivial > to maintain the LyX frontend code because it's easy to see what it does. > > That's not the case with the 13x dialogs, f.ex. The code in > frontends/controllers baffled everybody except me :) Things are much > clearer now. Transparent, even. > > So, whilst multiple possible frontends is somehow "nice", it's not very > important IMO. Entropy, Angus. That, and human nature. It's like with platform or achitecture independence: if actually using multiple platforms isn't forcing you, it _will_ slowly decay. > I'm actually quite hopeful about the ongoing health of this project. Not > because it has a vibrant community of active developers; it doesn't. > However, the vibrant community of semi-retired developers that it does > have have, over the years, turned obfuscated line noise into coherent > code. > > The fact that you yourself have squashed so many bugs recently is actually > testement to the soundness of André's inset-unification design. I wonder > if we'll ever see it completed? Ask again after 1.4.0 is out :-) As for 1.4.0cvs being unstable as Michael reports, let us understand that this is still heavily instrumented code. The "crash" due to recursive update was in reality an assert put there precisely to find such "deep" problems. And we shouldn't _yet_ remove them... as we will in the production version. So we're getting a bit too pessimistic picture now, I think. Like with the speed too. - Martin pgpFQYLHe2Zf5.pgp Description: PGP signature
Re: LyX frontends
Martin Vermeer wrote: >> So, whilst multiple possible frontends is somehow "nice", it's not very >> important IMO. > > Entropy, Angus. That, and human nature. It's like with platform or > achitecture independence: if actually using multiple platforms isn't > forcing you, it _will_ slowly decay. Oh, sure. That's why you'll note I was not advocating killing the gtk port. The XForms port should go, IMO, because it will become too much effort to maintain in a unicoded LyX. Personally, I'm not going to invest effort in a gtk port, but I'm not going to stand in anybody's way if that's what they want to do. >> The fact that you yourself have squashed so many bugs recently is >> actually testement to the soundness of André's inset-unification design. >> I wonder if we'll ever see it completed? > > Ask again after 1.4.0 is out :-) > > As for 1.4.0cvs being unstable as Michael reports, let us understand > that this is still heavily instrumented code. The "crash" due to > recursive update was in reality an assert put there precisely to find > such "deep" problems. And we shouldn't _yet_ remove them... as we will > in the production version. So we're getting a bit too pessimistic > picture now, I think. Like with the speed too. As I said, I'm optimistic about LyX's future. Good code and responsible coders. -- Angus
Re: Bug report: Qt Citations & BibTeX
Jürgen Spitzmüller wrote: >> 5. Insert > List & TOC > BibTeX Bibliography > Add => There is an empty >> entry at the top > > I'll have a look. I tried to fix that myself when adding the code to prevent a user from adding a "file name with spaces" if LaTeX didn't support it, (see the patch at http://article.gmane.org/gmane.editors.lyx.devel:44738) but failed. Not that I tried too hard. I'll be interested to see what the problem is. -- Angus
Re: [PATCH 14x] spaces in file names, part I
John Levon wrote:
> On Sat, May 14, 2005 at 03:52:00PM +0100, Angus Leeming wrote:
>
>> >> This patch, part I, changes nothing in LyX's operation. Well
>> >> actually, that's not quite true; it enables the Qt Alert dialogs to
>> >> know who their parent is so that dialogs are stacked in the correct
>> >> order.
>> >
>> > Alarm bells are ringing. Gotta go now, remind me to come back to this
>> > one
>>
>> Ping!
>
> Hmm, the bells may have been a little over the top. I wonder why this
> already works (i.e. you get modality for e.g. Load emergency save
> alert). Did you make sure to check that adding a parent doesn't mean
> that the parent GC's the widget? (I don't think so)
GC == GarbageCollect? No, I didn't check that. I'll do some reading...
done. We're OK. See below.
To recap, all I have done is:
QWidget * const parent =
- 0;
+ qApp->focusWidget() ? qApp->focusWidget() : qApp->mainWidget();
int res = QMessageBox::information(parent,
toqstr(title),
toqstr(formatted(question)),
toqstr(b1),
toqstr(b2),
b3.empty() ? QString::null : toqstr(b3),
default_button,
cancel_button);
If we look at the QMessageBox code, we see that the "parent" is passed to
the underlying QDialog together with a modal==TRUE flag.
int QMessageBox::information( QWidget *parent,
const QString& caption, const QString& text,
int button0, int button1, int button2 )
{
QMessageBox *mb = new QMessageBox( caption, text, Information,
button0, button1, button2,
parent, "qt_msgbox_information",
TRUE, WDestructiveClose);
Q_CHECK_PTR( mb );
return mb->exec();
}
QMessageBox::QMessageBox( const QString& caption,
const QString , Icon icon,
int button0, int button1, int button2,
QWidget *parent, const char *name,
bool modal, WFlags f )
: QDialog( parent, name, modal, f | WStyle_Customize |
WStyle_DialogBorder | WStyle_Title | WStyle_SysMenu )
{
init( button0, button1, button2 );
#ifndef QT_NO_WIDGET_TOPEXTRA
setCaption( caption );
#endif
setText( text );
setIcon( icon );
}
>From qdialog.cpp:
Note that QDialog uses the parent widget slightly differently from
other classes in Qt. A dialog is always a top-level widget, but if
it has a parent, its default location is centered on top of the
parent's top-level widget (if it is not top-level itself). It will
also share the parent's taskbar entry.
\target modal
\section1 Modal Dialogs
A modal dialog is a dialog that blocks input to other
visible windows in the same application. Users must finish
interacting with the dialog and close it before they can access
any other window in the application. Dialogs that are used to
request a file name from the user or that are used to set
application preferences are usually modal.
Given that the QDialog destroys itself (the WDestructiveClose flag is set)
before leaving the exec() function, I don't think that we have anything to
worry about.
Now are you happier?
--
Angus
Re: Bug report: Qt Citations & BibTeX
Angus Leeming wrote:
> I tried to fix that myself when adding the code to prevent a user from
> adding a "file name with spaces" if LaTeX didn't support it, (see the
> patch at http://article.gmane.org/gmane.editors.lyx.devel:44738) but
> failed. Not that I tried too hard. I'll be interested to see what the
> problem is.
The following fixes it for me on a general level. I have also added some code
to sort the items correctly (they have not because the vector is sorted with
the path, which is not displayed).
Does it look sensible?
Jürgen
Index: frontends/controllers/ControlBibtex.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ControlBibtex.C,v
retrieving revision 1.46
diff -u -r1.46 ControlBibtex.C
--- frontends/controllers/ControlBibtex.C 25 Nov 2004 11:08:30 - 1.46
+++ frontends/controllers/ControlBibtex.C 14 May 2005 16:55:44 -
@@ -79,6 +79,8 @@
for (; it != end; ++it) {
*it = OnlyFilename(*it);
}
+ // sort on filename only (no path)
+ std::sort(data.begin(), data.end());
}
@@ -97,6 +99,8 @@
for (; it != end; ++it) {
*it = OnlyFilename(*it);
}
+ // sort on filename only (no path)
+ std::sort(data.begin(), data.end());
}
Index: frontends/controllers/tex_helpers.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/tex_helpers.C,v
retrieving revision 1.24
diff -u -r1.24 tex_helpers.C
--- frontends/controllers/tex_helpers.C 17 Jan 2005 18:54:01 - 1.24
+++ frontends/controllers/tex_helpers.C 14 May 2005 16:55:45 -
@@ -79,7 +79,12 @@
std::vector::iterator it = list.begin();
std::vector::iterator end = list.end();
for (; it != end; ++it) {
- *it = regex.Merge((*it), "/");
+ string const item = regex.Merge((*it), "/");
+ // don't add empty items.
+ if (!item.empty())
+ *it = item;
+ else
+ list.erase(it, end);
}
eliminate_duplicates(list);
Index: frontends/qt2/QTexinfo.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QTexinfo.C,v
retrieving revision 1.27
diff -u -r1.27 QTexinfo.C
--- frontends/qt2/QTexinfo.C 12 May 2005 23:12:43 - 1.27
+++ frontends/qt2/QTexinfo.C 14 May 2005 16:55:47 -
@@ -62,6 +62,10 @@
dialog_->fileList->insertItem(toqstr(line));
}
+ // resort if filename only (because of missing path)
+ if (!withFullPath)
+ dialog_->fileList->sort();
+
activeStyle = whichStyle;
}
Re: Bug report: Qt Citations & BibTeX
Juergen Spitzmueller wrote: > > 2. (a) Add some BibTeX bibliography (b) Insert > Cross-reference (c) > > search entry "e" (d) Find Previous => Bang! > > I take it that (b) means Insert->Citation. I get no crash, but it's not > working correctly either. I'll have a look. > > > 3. (a) Add some BibTeX bibliography (b) Insert > Cross-reference (c) > > search entry "e" (d) Find Next (multiple times) => does not work > > see above The attached fixes it for me. Both setSelected and setCurrentItem are necessary, probably because we now have multi selection mode in that browser (i.e. you can select multiple citation entries at once). Please test. Jürgen Index: QCitationDialog.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QCitationDialog.C,v retrieving revision 1.33 diff -u -r1.33 QCitationDialog.C --- QCitationDialog.C 2 Jun 2004 20:13:18 - 1.33 +++ QCitationDialog.C 14 May 2005 17:42:05 - @@ -283,6 +283,7 @@ // Update the display add_->availableLB->setSelected(found, true); + add_->availableLB->setCurrentItem(found); add_->availableLB->ensureCurrentVisible(); }
Re: [PATCH 14x] spaces in file names, part I
On Sat, May 14, 2005 at 04:28:52PM +0100, Angus Leeming wrote: > Given that the QDialog destroys itself (the WDestructiveClose flag is set) Yes, that's the ticket. john
Re: Bug report: Qt Citations & BibTeX
Juergen Spitzmueller wrote: > Index: frontends/qt2/QTexinfo.C > === > RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QTexinfo.C,v > retrieving revision 1.27 > diff -u -r1.27 QTexinfo.C > --- frontends/qt2/QTexinfo.C12 May 2005 23:12:43 - 1.27 > +++ frontends/qt2/QTexinfo.C14 May 2005 16:55:47 - > @@ -62,6 +62,10 @@ > dialog_->fileList->insertItem(toqstr(line)); > } > > + // resort if filename only (because of missing path) > + if (!withFullPath) > + dialog_->fileList->sort(); This does not work (the vector itself has to be reordered). I send a better patch tomorrow. Jürgen
math panel symbol
Hello LyXers, what is the name of the xpm for the QT math panel symbol "Sets limits style"? Thanks and regards Uwe
Re: [Patch] Re: Timing experiments
On Fri, May 13, 2005 at 09:46:29PM +0300, Martin Vermeer wrote:
> Actually it should be noted that paintText called from LyXScreen::redraw
> still draws _three_ paragraphs: the one containing the cursor, and the
> ones above and below, see rowpainter.C. I'm sure there is a good reason
> for this when redrawing the whole screen...
We need up-to-date metrics in the paragraph below to handle e.g.
when the cursor is in the last line of a paragraph.
I think this was the reason before the null painter was invented...
> we could easily propagate the bool onlypar (by adding it to
> ViewMetricsInfo?) to prevent also this, giving a further speed-up.
>
> Is this a sensible direction?
I think so.
> -void BufferView::update(bool fitcursor, bool forceupdate)
> +void BufferView::update(bool fitcursor, bool forceupdate, bool onlypar)
> {
> - pimpl_->update(fitcursor, forceupdate);
> + pimpl_->update(fitcursor, forceupdate, onlypar);
> }
Pretty much looks like the old update flags now. I knew there must have
been a reason...
enum UpdateFlags { UpdateFitCursor = 1, UpdateForce = 2, UpdateOnlyPar =
4 };
+ void update(UpdateFlags = UpdateFitCursor | UpdateForce);
This makes things like
> + cur.bv().update(false, true, true);
a bit mmore readble:
cur.bv().update(UpdateForce | UpdateOnlyPar);
Andre'
Re: LyX frontends
On Sat, May 14, 2005 at 12:42:21PM +0200, Michael Schmitt wrote: > My initial tests of the Qt frontend told me that it is far away from > being stable. Actually, it seems like some stuff is broken that worked > very well in 1.3 before. Once again, I would like to raise the question > on whether we can really afford to maintain more than one frontend. I think the question is answered: we can't. > Wouldn't it make sense to remove even the xforms frontend for 1.4? Who > is actually using/testing it? I think one really good frontend is better > than two half-heartedly tested frontends. I am using xforms, Konni is using xforms, but xforms has to go the way of the dodo... Andre'
Re: [Patch] Re: Timing experiments
On Fri, May 13, 2005 at 11:15:02PM +0300, Martin Vermeer wrote: > @@ -1229,7 +1221,6 @@ > // real_current_font.number can change so we need to > // update the minibuffer > if (old_font != real_current_font) > - bv->owner()->view_state_changed(); > bv->updateScrollbar(); > break; > } > > and Andre deleted lots of other bv->owner()->view_state_changed(); > in that same patch. > > I suspect the if should go. Andre should know. Aehm... yes. Drop the if. Andre'
Re: Profiling LyX-140 on Mac
On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote: > On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote: > > > So why not solve that he other way round: Do not blink the cursor unless > > all draws have been finished? > > I thought that's what Martin was planning (and it certainly sounds > right) Oh I see. I was swamped with messages suggesting that we try to hide the problem using some well-tuned timer Andre'
Re: LyX frontends
On Sat, May 14, 2005 at 05:45:55PM +0300, Martin Vermeer wrote: > OK, but let's then make sure gtk is minimally useable before that. We > shouldn't lose this investment (in GUI-I, I mean). The GUI-I investment has already payed off by separating GUI and core. Right now and in a foreseeable future, it will be a burden. A big one. Andre'
Re: LyX frontends
On Sat, May 14, 2005 at 03:57:23PM +0300, Martin Vermeer wrote: > OK, but that tells us also something about the current state of > incompleteness of GUI-I. Ideally, the front ends should only define a > set of primitives that the rest of LyX then uses. I am thinking of a > termcap type parametrization thingy, but graphically. > > I doubt that we will ever get quite that far (if even possible), but we > can certainly get farther than we are now. In my understanding there is > _no reason at all_ why _any_ translatable strings should be front end > specific / part of the front-end code. Unfortunately many today are. > You know that, John: you've been duplicating Qt strings rather than > re-using them as you would under a sane architecture... > > Other than that, the proposal is OK if it is easily reversible later. Putting in an extra abstraction layer between LyX core and Qt is quite some work to set up and to maintain for no good reason if Qt is the only supported frontend. We simply don't have the capacities to do that. GUI-I was a very big step for LyX in the light of dividing-and- conquering the pile of LyX was structurally at some point of time. > > > Basically, maintaining a working frontend is minimal effort, so I don't > > > think that it matters if someone wants to have a pet project porting to > > > his/her favourite toolkit. > > Ideally, the maintenance should be _zero_ work, see above. Not true. You need to maintain a separate astraction layer. And by not committing to a single frontend you loose all the goodies. Just think about all the work Angus put in to come up something resembling QProcess, or QSettings. Andre' PS: I don't think Qt is perfect. But it seems to be the best option we have.
Re: LyX frontends
On Sat, May 14, 2005 at 05:19:54PM +0300, Martin Vermeer wrote: > Now there I agree. Which is why I think we should not just "drop" any > front ends. We need at least two more or less useable ones to keep GUI-I > alive, now that we have it. GUI-I has done its duty, let it die. What do we _really_ gain by maintaining separate frontends and what do we lose by not committing to a single one? If you weigh both sides, the result should be obvious. Andre'
Re: Profiling LyX-140 on Mac
On Sat, May 14, 2005 at 04:02:10PM +0300, Martin Vermeer wrote: > On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote: > > On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote: > > > > > So why not solve that he other way round: Do not blink the cursor unless > > > all draws have been finished? > > > > I thought that's what Martin was planning (and it certainly sounds > > right) > > I'm note sure we are talking about the same thing now. Anyway I am happy > the way things have turned out with Lars' cache (though I still don't > grok it). I don't thing anything based on tweaking timers is a conceptionally sound solution. It miht work, and this might all we need to get 1.4 out of the door, but it does not sound right. Andre'
Re: LyX frontends
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Code refactoring should be on-going, yes. However, we should Angus> drop XForms. Note that we can't drop xforms until gtk stops depending on it. JMarc
Re: Profiling LyX-140 on Mac
On Sat, May 14, 2005 at 08:42:08PM +0200, Andre Poenitz wrote: > On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote: > > On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote: > > > > > So why not solve that he other way round: Do not blink the cursor unless > > > all draws have been finished? > > > > I thought that's what Martin was planning (and it certainly sounds > > right) > > Oh I see. I was swamped with messages suggesting that we try to hide > the problem using some well-tuned timer ...and I have a nagging suspicion that that is what Lars' solution amounts to, but he tells me no... - Martin pgpAS7VKCh0a1.pgp Description: PGP signature
Re: LyX frontends
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> The above. I believe the _translator_ load per front end can Martin> be brought down to close to zero; as for the _coding_ load Martin> caused by the ongoing evolution of the LyX core code, that of Martin> course will never be zero short of a pure termcap-style Martin> primitives architecture. If the xforms frontend was changed to denote short the Qt wat instaed of the LyX way|w, we would already gain a lot on translations, since most frontends strings have no reason to be different. This does not need a monstruous frontend. Of course, a different solution is to build a wxWindows frontend, but I do not see who is going to do that... JMarc
Re: LyX meeting in Paris. When?
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes: Michael> Martin Vermeer wrote: >> So, what could be the 4-5 day "core" time that we should all try to >> be there? Th 14 - Mo 18 July? I have to start ordering tickets... >> >> Michael> BTW: I intend to go by train. How difficult is it to get to Michael> your apartment from Paris railway station? (In particular, if Michael> you do not speak French :-)) Depending on where you come from in Germany, you will arrive at Gare de l'Est (East station) or Gare du Nord (North Station), which are in the same area (~500m distance). From there you will be able to go directly to either my appartment or my parent's house (depending on where we choose the HQ). JMarc
Re: LyX meeting in Paris. When?
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> So, what could be the 4-5 day "core" time that we should all Martin> try to be there? Th 14 - Mo 18 July? I have to start ordering Martin> tickets... It seems that this particular week-end is indeed the one that interests the most people. The only problem I have is that, considering the number of people who are going to come, my 90m2 apartment will be a bit small to provide accommodation (6 people is OK, more means less comfort). I have a plan B, which is to ask my sister whether we can sleep in her home, but I have not been able yet to know when she will be away (probably only for the second week-end, Jul 23-24). Other than that we have plan C, in my parents' house with a nice garden and plenty of space. I have confirmed with them that I can kick them out whenever we want :) The place is nicer, but the city is in a (nice but) boring suburb. So it depends on whether you prefer to be in Paris. Less space, but probably more fun, and much more places where we can go by foot (Montmartre can be really nice at night). Finally, if we decide to keep Jul 14-18, I have to warn you that Jul 14 is our national holiday [*], but I do not know the kind of effect it can have on traffic. So, what day do you all prefer? JMarc [*] which is not called ``Bastille Day'', as some would want you to think, but boringly enough ``14-Juillet''
Re: LyX meeting in Paris. When?
On Sat, May 14, 2005 at 11:54:35PM +0200, Jean-Marc Lasgouttes wrote: > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > Martin> So, what could be the 4-5 day "core" time that we should all > Martin> try to be there? Th 14 - Mo 18 July? I have to start ordering > Martin> tickets... > > It seems that this particular week-end is indeed the one that > interests the most people. The only problem I have is that, > considering the number of people who are going to come, my 90m2 > apartment will be a bit small to provide accommodation (6 people is > OK, more means less comfort). I have a plan B, which is to ask my sister > whether we can sleep in her home, but I have not been able yet to know > when she will be away (probably only for the second week-end, Jul 23-24). > > Other than that we have plan C, in my parents' house with a nice > garden and plenty of space. I have confirmed with them that I can kick > them out whenever we want :) The place is nicer, but the city is in a > (nice but) boring suburb. Is it close to a metro station? > So it depends on whether you prefer to be in Paris. Less space, but > probably more fun, and much more places where we can go by foot > (Montmartre can be really nice at night). > > Finally, if we decide to keep Jul 14-18, I have to warn you that Jul > 14 is our national holiday [*], but I do not know the kind of effect > it can have on traffic. Would 15-19 July then be better? The guided tour at INRIA could then be on 18 July :-) > So, what day do you all prefer? > > JMarc > > [*] which is not called ``Bastille Day'', as some would want you to > think, but boringly enough ``14-Juillet'' - Martin pgp4YiBkS043B.pgp Description: PGP signature
