Re: Fixed: toolbar management problem - another problem
Peter == Peter Kümmel [EMAIL PROTECTED] writes: Peter What about the rule to use on Windows the latest and greatest Peter Qt release and on Linux only an old one? It depends. If there is a _windows_ _only_ thing that cannot be done with qt 4.1 it is OK. If it just that you'd love to play with the new QRoundedGlowingWindow because it is there, the answer is probably no. We do not want to have two code bases just because we can. I do not think that the fact that LyX 1.4 can compile with qt 3.0 really hampered its development. JMarc
Re: Fixed: toolbar management problem - another problem
Peter == Peter Kümmel [EMAIL PROTECTED] writes: You expressed it very well, Georg. And I'll just reiterate that this is how linux works. So please be nice guys for poor old linux users. Peter Are #ifdefs ok then? Let me give you an example that is OK: currently there is some ugly code of mine to handle menus on Qt/Mac. Now in Qt 4.2 trolltech has finally done what they should have done for the first mac release and introduced the MenuRole concept. Since Qt is bundled with LyX/Mac, I think it may make sense to use this feature for the Mac and decide that LyX/Mac requires Qt 3.2. This will allow to remove ugly code that is difficult to make correctly work. However, if I manage to make the current code to work as I wish, I will probably say yes, it is the way to go, but we can do it later. Personally, I use Qt 4.1.something and have no intention to upgrade. I think it is good that developers do not use latest and greatest without a good reason, since that removes a silly temptation. JMarc
Re: Fixed: toolbar management problem - another problem
Peter == Peter Kümmel [EMAIL PROTECTED] writes: Peter Seems some peolple currently suffer a depression, but don't Peter forget: LyX is NOT the meaning of life ;-) I can live very well without LyX, thank you. The LyX developers' community has been a very nice place to stick around for a long time, and I hope it will remain so. JMarc
Re: the new sidebar
John Levon wrote: Whilst I appreciate the reasoning behind the new sidebar, it has an unfortunate side-effect: the scroll bar is now much harder to hit. Especially in full-screen mode, the scroll bar was of infinite width previously. If you're talking about the view/upgrade toolbar: I think Uwe just put it on the right because of a toolbar/session bug that is now fixed. I think that toolbar can go now where Uwe initiallly intended it to be. Uwe? Jürgen
Re: Fixed: toolbar management problem - another problem
Peter == Peter Kümmel [EMAIL PROTECTED] writes: Peter I assume because much has changed in the last year, more than Peter the years before, so some LyX-Veterans are a bit astonished. You know, we did not wait for young blood to go coding wildly and implement multi-windows and window splitting and many other fun things. This was at LyX 1.1 (the first incarnation) time. And then we saw that we coded so many nice things that the program was severely broken and we scraped everything to go back to 1.0.4 code base. And then we decided it might be a good idea to have some idea of were we are going and to enforce plans for releases and mundane things like that. That said, I am not very interested in this veterans vs. young blood pissing contests. This is not what we need now JMarc, who swears he's been forced to play the grumpy oldtimer and who'd prefer to release 1.4.4 instead.
[Patch] fix caption inset selection bug
It is this simple (I think).
(The inset API has its nice sides)
- Martin
Index: insetcaption.C
===
--- insetcaption.C (revision 17041)
+++ insetcaption.C (working copy)
@@ -167,6 +167,12 @@
}
+void InsetCaption::drawSelection(PainterInfo pi, int x, int y) const
+{
+ InsetText::drawSelection(pi, x + labelwidth_ , y);
+}
+
+
void InsetCaption::edit(LCursor cur, bool left)
{
cur.push(*this);
Index: insetcaption.h
===
--- insetcaption.h (revision 17041)
+++ insetcaption.h (working copy)
@@ -48,6 +48,8 @@
///
virtual void draw(PainterInfo pi, int x, int y) const;
///
+ void drawSelection(PainterInfo pi, int x, int y) const;
+ ///
virtual void edit(LCursor cur, bool left);
///
virtual InsetBase * editXY(LCursor cur, int x, int y);
pgpAlniywt4KX.pgp
Description: PGP signature
Re: [Cvslog] r17059 - /lyx-devel/trunk/src/insets/insetfloat.h
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin Jean-Marc, should this go into branch too? - Martin Well, it does not fit with the definition of Wide() in 1.4.x. Conerning the need for the fix, I think it just hides the bug in a particular case. The real fix would be to manage to get rid of this wide() thing :) It is possible to set paragraphs centered in almost all text insets, so blocking it in floats seems a bit vain. The bug remains for branches for example, and I do not think it would be a good idea to disable wide() in branches just for that. What is the correct behavior we would like to obtain for centered paragraphs in a wide inset, BTW? Would it be really difficult to change metrics computation so that a centered paragraph always tries to occupy the whole screen width (like with a hfill)? I think this would solve the problem in a better way. JMarc
Re: the new sidebar
John == John Levon [EMAIL PROTECTED] writes: John Whilst I appreciate the reasoning behind the new sidebar, it has John an unfortunate side-effect: the scroll bar is now much harder to John hit. Especially in full-screen mode, the scroll bar was of John infinite width previously. John I'd much, much, prefer it to be on the left. Agreed. I cannot think right now of other programs that set the icons to the right. JMarc
Re: Fixed: toolbar management problem - another problem
Martin Vermeer wrote: On Mon, Feb 05, 2007 at 08:59:19PM +0100, Peter Kümmel wrote: José Matos wrote: On Monday 05 February 2007 7:34:43 pm Peter Kümmel wrote: I assume because much has changed in the last year, more than the years before, so some LyX-Veterans are a bit astonished. Come on Peter, Jean-Marc certainly knows better. :-) Is it really so unrealistic? When he doesn't like most of the changes? It's not so much the changes as the civility of the process. We need a rough consensus before acting, and the closer to final release, the more we need to agree before doing anything. I really think that that's generally the case. Please gives example if otherwise. We agreed with Georg and Jose that the caption inset was to be in before the beta for example. As far as my metrics related activities, except for you and Denmark cowboys, nobody knows or is willing to know this field. As neither you or the Denmark cowboys are very active currently, I just commit without warning. Same with Michael and CT stuff for example Most of my changes are right anyway ;-) There have been some poorly considered changes perhaps, but that's OK -- it's a learning process. Right, and there's nothing dramatic in reverting something from SVN. This is not like we committed sacrilege on the sacro-saint LyX repository ;-) That being said, the LyX process has been much more structured and conversational than what I see in other projects. LyX is software with a philosophy. I like that. Exactly my feeling. I suppose so does Jean-Marc, and he doesn't want to see it erode. Sure, we all agree with that. Abdel.
Re: Fixed: toolbar management problem - another problem
Jean-Marc Lasgouttes wrote: Peter == Peter Kümmel [EMAIL PROTECTED] writes: Peter I assume because much has changed in the last year, more than Peter the years before, so some LyX-Veterans are a bit astonished. You know, we did not wait for young blood to go coding wildly and implement multi-windows and window splitting and many other fun things. This was at LyX 1.1 (the first incarnation) time. And then we saw that we coded so many nice things that the program was severely broken Is it broken now? and we scraped everything to go back to 1.0.4 code base. Maybe because it was too unstable and those feature were not implemented properly? And then we decided it might be a good idea to have some idea of were we are going and to enforce plans for releases and mundane things like that. Man, I achieved the multi-windows thing by first cleaning up thoroughly the core. I made sure that the separation between between the frontend and the core was clean before implementing any feature. The multi-window feature is just sugar, it came mostly for free after my hard-work. So, I repeat my question, what is the problem? Sorry but I really don't understand why you complain. If anything, I would expect acknowledgement of my hard work instead of complaint. It's my turn to feel depressed now :-( Abdel.
Re: [Cvslog] r17059 - /lyx-devel/trunk/src/insets/insetfloat.h
Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin Jean-Marc, should this go into branch too? - Martin Well, it does not fit with the definition of Wide() in 1.4.x. Conerning the need for the fix, I think it just hides the bug in a particular case. The real fix would be to manage to get rid of this wide() thing :) Indeed. AFAIU, the wide() property was introduced by Martin in order to be able to use the singlePar optimisation within insets. This was required because the rowpainter does not distinguish between text drawing and decoration drawing. So the correct fix is to cleanup the rowpainter. I won't do this for 1.5 but, if I am still active for 1.6, I will do it. It is possible to set paragraphs centered in almost all text insets, so blocking it in floats seems a bit vain. The bug remains for branches for example, and I do not think it would be a good idea to disable wide() in branches just for that. What is the correct behavior we would like to obtain for centered paragraphs in a wide inset, BTW? Would it be really difficult to change metrics computation so that a centered paragraph always tries to occupy the whole screen width (like with a hfill)? I think this would solve the problem in a better way. I don't think so. I don't wanted all my text to be completely re-organized when I enter the inset. Abdel.
Re: [Cvslog] r17059 - /lyx-devel/trunk/src/insets/insetfloat.h
On Tue, Feb 06, 2007 at 10:32:11AM +0100, Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin Jean-Marc, should this go into branch too? - Martin Well, it does not fit with the definition of Wide() in 1.4.x. Conerning the need for the fix, I think it just hides the bug in a particular case. The real fix would be to manage to get rid of this wide() thing :) Yes, if only... Abdel has been going around disabling it in places where one gets away with it -- good thinking. It is possible to set paragraphs centered in almost all text insets, so blocking it in floats seems a bit vain. The bug remains for branches for example, and I do not think it would be a good idea to disable wide() in branches just for that. No, because branches are precisely those insets that can contain large amounts of text, where having the wide() mechanism is needed most. It is true that you *can* center paragraphs in any inset. Captions are special in that they tend to be 1) always on a row of their own, so the wide() mechanism kicks in even for very short captions, and 2) by their nature centered very often. What is the correct behavior we would like to obtain for centered paragraphs in a wide inset, BTW? Would it be really difficult to change metrics computation so that a centered paragraph always tries to occupy the whole screen width (like with a hfill)? I think this would solve the problem in a better way. I expect it would be really difficult to get right. JMarc - Martin pgp1nyz62oNmL.pgp Description: PGP signature
Re: [Patch] fix caption inset selection bug
Martin Vermeer wrote: It is this simple (I think). (The inset API has its nice sides) Thanks for helping me at this. Abdel.
Re: [Cvslog] r17059 - /lyx-devel/trunk/src/insets/insetfloat.h
On Tue, Feb 06, 2007 at 10:56:26AM +0100, Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin Jean-Marc, should this go into branch too? - Martin Well, it does not fit with the definition of Wide() in 1.4.x. Conerning the need for the fix, I think it just hides the bug in a particular case. The real fix would be to manage to get rid of this wide() thing :) Indeed. AFAIU, the wide() property was introduced by Martin in order to be able to use the singlePar optimisation within insets. This was required because the rowpainter does not distinguish between text drawing and decoration drawing. Yes, I think that is correct. So the correct fix is to cleanup the rowpainter. I won't do this for 1.5 but, if I am still active for 1.6, I will do it. Sounds good. I looked at that possibility, and the current state of the code concerned, and became instantly depressed :-( ... What is the correct behavior we would like to obtain for centered paragraphs in a wide inset, BTW? Would it be really difficult to change metrics computation so that a centered paragraph always tries to occupy the whole screen width (like with a hfill)? I think this would solve the problem in a better way. I don't think so. I don't wanted all my text to be completely re-organized when I enter the inset. True! I didn't even consider that. And the cost of re-rendering all that text (if there's a lot). It would kill the advantage of having wide() in the first place. - Martin pgpVSP6EeVqcb.pgp Description: PGP signature
Re: [Cvslog] r17059 - /lyx-devel/trunk/src/insets/insetfloat.h
Martin == Martin Vermeer [EMAIL PROTECTED] writes: I don't think so. I don't wanted all my text to be completely re-organized when I enter the inset. Martin True! I didn't even consider that. And the cost of Martin re-rendering all that text (if there's a lot). It would kill Martin the advantage of having wide() in the first place. This is not what I proposed. I proposed that centered text always use the whole screen width, that is, that the inset be always wide when it contains centered text. JMarc
Re: Fixed: toolbar management problem - another problem
On Tuesday 06 February 2007 9:48:38 am Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: Peter == Peter Kümmel [EMAIL PROTECTED] writes: Peter I assume because much has changed in the last year, more than Peter the years before, so some LyX-Veterans are a bit astonished. You know, we did not wait for young blood to go coding wildly and implement multi-windows and window splitting and many other fun things. This was at LyX 1.1 (the first incarnation) time. And then we saw that we coded so many nice things that the program was severely broken Is it broken now? It could be better or else we would already have 1.5 out of door. ;-) Yes, I know, I am not answering this but I don't think that Jean-Marc meant that as well. and we scraped everything to go back to 1.0.4 code base. Maybe because it was too unstable and those feature were not implemented properly? Certainly, the point to note here is that sometimes it is necessary to turn to not so fun tasks in order to maintain the viability of the whole project. The other point frequently raised is the scarcity of human resources. And then we decided it might be a good idea to have some idea of were we are going and to enforce plans for releases and mundane things like that. Man, I achieved the multi-windows thing by first cleaning up thoroughly the core. I made sure that the separation between between the frontend and the core was clean before implementing any feature. The multi-window feature is just sugar, it came mostly for free after my hard-work. So, I repeat my question, what is the problem? Problem, what problem? :-) Sorry but I really don't understand why you complain. If anything, I would expect acknowledgement of my hard work instead of complaint. With all the due respect Abdel, I don't think you should get this as personal stance targeted to you. :-) It's my turn to feel depressed now :-( I am sorry but that is not an option. ;-) Abdel. PS: I don't know why people get annoyed with me when I say that to be depressed for more than 5 minutes is not an option. ;-) -- José Abílio
Re: Fixed: toolbar management problem - another problem
José Matos wrote: Is it broken now? It could be better or else we would already have 1.5 out of door. ;-) and what about a beta?
Re: Fixed: toolbar management problem - another problem
José Matos wrote: On Tuesday 06 February 2007 9:48:38 am Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: Peter == Peter Kümmel [EMAIL PROTECTED] writes: Peter I assume because much has changed in the last year, more than Peter the years before, so some LyX-Veterans are a bit astonished. You know, we did not wait for young blood to go coding wildly and implement multi-windows and window splitting and many other fun things. This was at LyX 1.1 (the first incarnation) time. And then we saw that we coded so many nice things that the program was severely broken Is it broken now? It could be better or else we would already have 1.5 out of door. ;-) Quite frankly, I think 1.5svn is in a _much_ better shape than 1.4.0 ever was. If we were to apply the same requirement, 1.5.0 should be released just right now. Yes, I know, I am not answering this but I don't think that Jean-Marc meant that as well. and we scraped everything to go back to 1.0.4 code base. Maybe because it was too unstable and those feature were not implemented properly? Certainly, the point to note here is that sometimes it is necessary to turn to not so fun tasks in order to maintain the viability of the whole project. And what do you think we're all doing right now? Look at bugzilla and counts how many bugs were killed recently... The other point frequently raised is the scarcity of human resources. Pointing the gun to new developers won't improve the situation there :-) And then we decided it might be a good idea to have some idea of were we are going and to enforce plans for releases and mundane things like that. Man, I achieved the multi-windows thing by first cleaning up thoroughly the core. I made sure that the separation between between the frontend and the core was clean before implementing any feature. The multi-window feature is just sugar, it came mostly for free after my hard-work. So, I repeat my question, what is the problem? Problem, what problem? :-) Exactly my question :-) Sorry but I really don't understand why you complain. If anything, I would expect acknowledgement of my hard work instead of complaint. With all the due respect Abdel, I don't think you should get this as personal stance targeted to you. :-) With all due respect to myself, I implemented the feature in question and a couple of others as well. So if not me, who do you think should be concerned? It's my turn to feel depressed now :-( I am sorry but that is not an option. ;-) LyX is just a side project :-) Abdel.
Re: Fixed: toolbar management problem - another problem
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Sorry but I really don't understand why you complain. If Abdelrazak anything, I would expect acknowledgement of my hard work Abdelrazak instead of complaint. Abdelrazak It's my turn to feel depressed now :-( This is definitely not a complaint about you work on multi-windows. While I am not sure it is ready, the steps you took to get there are all welcome and go in the right direction as far as I can see. So I hereby acknowledge your hard work in both qt4 and metrics computations (among other things) and want to thank you for it. Seriously. I am not kidding. My point was just to point out that coding lots of things fast has not always been a good metrics for quality in LyX' history (answering to Peter's assertion--I paraphrase--that we had not been used to see more than two commits a week before last year). It is not my fault that the feature that broke the original 1.1 branch was multi-windows support... Actually, the old CHANGES file hints that we did also completely rewrite the kernel data structure at the same time :) JMarc
Re: Fixed: toolbar management problem - another problem
José == José Matos [EMAIL PROTECTED] writes: José PS: I don't know why people get annoyed with me when I say that José to be depressed for more than 5 minutes is not an option. ;-) Maybe because they find it depressing? JMarc
Re: Fixed: toolbar management problem - another problem
On Tuesday 06 February 2007 10:36:43 am Edwin Leuven wrote: and what about a beta? There is one last step I want to take before that. That is related with the way we treated whitespaces in combination with font changes. This change is minimal but very subtle, the potential problem is that the typeset output of a lyx document would be different from previous lyx versions. This is serious for me to want to fix before the first beta is released. -- José Abílio
Re: CT is ready for LyX beta
On Thursday 01 February 2007 9:55:09 pm Michael Gerz wrote: José, for your enjoyment: I think I fixed all major change tracking bugs today. Hopefully, there should no crashes anymore. All open CT issues are documented in bugzilla and, personally, I can live with all of them ATM. In other words: CT is ready for the first LyX 1.5.0beta! Thanks Michael. Michael -- José Abílio
Re: Fixed: toolbar management problem - another problem
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Sorry but I really don't understand why you complain. If Abdelrazak anything, I would expect acknowledgement of my hard work Abdelrazak instead of complaint. Abdelrazak It's my turn to feel depressed now :-( This is definitely not a complaint about you work on multi-windows. While I am not sure it is ready, the steps you took to get there are all welcome and go in the right direction as far as I can see. So I hereby acknowledge your hard work in both qt4 and metrics computations (among other things) and want to thank you for it. Seriously. I am not kidding. OK, thanks :-) My point was just to point out that coding lots of things fast has not always been a good metrics for quality in LyX' history (answering to Peter's assertion--I paraphrase--that we had not been used to see more than two commits a week before last year). It is not my fault that the feature that broke the original 1.1 branch was multi-windows support... Actually, the old CHANGES file hints that we did also completely rewrite the kernel data structure at the same time :) I agree with Jose that we should not ignore history but you should also see that the situation is not the same at all right now. I am all for being cautious but please don't blame newcomers for past faults. Abdel.
Re: Fixed: toolbar management problem - another problem
Abdelrazak Younes wrote: I agree with Jose that we should not ignore history but you should also see that the situation is not the same at all right now. I am all for being cautious but please don't blame newcomers for past faults. I think you completely misunderstood what Jean-Marc wrote. This is not about blaming newcomers for past faults, this is about preventing to do the same faults again. And I see this danger, too. For example I consider your longtable caption changes from yesterday exactly that kind of hack that we tried to remove over the last years and that should at least have been discussed before it went in. I would like to add my views in more details (also to other statements made in this thread), but am swamped with work during the next couple of days, so this has to wait. Georg
Re: Fixed: toolbar management problem - another problem
Georg Baum wrote: Abdelrazak Younes wrote: I agree with Jose that we should not ignore history but you should also see that the situation is not the same at all right now. I am all for being cautious but please don't blame newcomers for past faults. I think you completely misunderstood what Jean-Marc wrote. This is not about blaming newcomers for past faults, this is about preventing to do the same faults again. And I see this danger, too. For example I consider your longtable caption changes from yesterday exactly that kind of hack that we tried to remove over the last years and that should at least have been discussed before it went in. OK, I quit the discussion. Revert the change if you want. Abdel.
Re: Embedded Objects
Uwe == Uwe Stöhr [EMAIL PROTECTED] writes:
Uwe - when using a prettyref inset \usepackage{prettyref} is set to
Uwe the preamble. What when the user needs to load this package with
Uwe an option?
A worse problem is that prettyref is not in teTeX 2 (at least) because
of unknown license:
http://www.mail-archive.com/tetex@dbs.uni-hannover.de/msg00342.html
So your EmbeddedObjects help file cannot be typeset. This is a blocker
for 1.4.4. As a temporary measure, shall we remove reference to
prettyref in the 1.4 version of the manual at least?
All in all, supporting prettyref in LyX was probably a bad idea, but I
do not know how to go out from this trap.
Another question Uwe: why is this discussion on references hidden in
the Float chapter? There are many entities besides floats the deserve
a reference.
JMarc
Re: Fixed: toolbar management problem - another problem
Bo Peng schrieb: We need someone who says no! or stop that!. I did something like this but I am not at a position to do that. I had hoped that Michael can show some management skills but he chose to be silent. As far as I am concerned, there is no good or bad decision because any decision is better than none. So, we can do either A or B: Hi, I am pretty busy these days, so I will not be able to contribute anything (including personal opinions) until next week :-( Michael, your reply needs only one letter. Excellent! Now I am the one to make a friend and an enemy :-) Maybe there is a third alternative: C: We declare both installers as non-official! C2: ... and someone develops a new official one by picking the best of both installers. Analogy: If two children cannot agree on some toy (here: official-ness), none of them gets it. (Before I get involved in a flame war: I don't consider Joost and Uwe as children or childish!!) Regards, Michael
Re: the new sidebar
If you're talking about the view/upgrade toolbar: I think Uwe just put it on the right because of a toolbar/session bug that is now fixed. I think that toolbar can go now where Uwe initially intended it to be. Yes this was the original reason. But now that I used it for a while in this position I like it there. Other programs also have toolbars on the left and/or right (Photoshop, AutoCAD, Illustrator, etc.). I cannot see why the position makes it difficult to access the scrollbar. My original intention was to place it behind the Standard toolbar but I don't know if there's enough space behind it for the different screen resolutions. I don't like to have it as third toolbar line on top because this consumes too much space, when it is at the side you see more of your text as the screen is always wider than it height. So if you really think it cannot be at the right side I propose to put it on the left side. Decide together with the others about the place. regards Uwe
Re: Embedded Objects
A worse problem is that prettyref is not in teTeX 2 (at least) because of unknown license: http://www.mail-archive.com/tetex@dbs.uni-hannover.de/msg00342.html So your EmbeddedObjects help file cannot be typeset. This is a blocker for 1.4.4. As a temporary measure, shall we remove reference to prettyref in the 1.4 version of the manual at least? I don't know, I only decribed what LyX supports, so when I should remove it in the doc, it should also be removed in LyX or better replaced by another command from a similar package to prettyref. Another question Uwe: why is this discussion on references hidden in the Float chapter? There are many entities besides floats the deserve a reference. It is not, there is also a description in the table section. The manual describes the floats and not referencing at all. For example references to formulas will be described in the math manual I'm working on. Referencing in general is explained in detail in the Userguide. regards Uwe
Re: the new sidebar
Uwe Stöhr wrote: Yes this was the original reason. But now that I used it for a while in this position I like it there. Other programs also have toolbars on the left and/or right (Photoshop, AutoCAD, Illustrator, etc.). I cannot see why the position makes it difficult to access the scrollbar. My original intention was to place it behind the Standard toolbar but I don't know if there's enough space behind it for the different screen resolutions. I don't like to have it as third toolbar line on top because this consumes too much space, when it is at the side you see more of your text as the screen is always wider than it height. So if you really think it cannot be at the right side I propose to put it on the left side. Decide together with the others about the place. I agree with John and Jean-Marc that the right side is irritating because of the scrollbar. Besides, this toolbar is so short that it looks like a huge waste of space to me if it uses a row of its own (left or right). Personally, I will put it on top anyway. So now that placing multiple toolbars on one row works (at least in the session file, i.e. _after_ the first startup), I'd vote for putting this toolbar on top. What do others think? Jürgen
Re: the new sidebar
Jürgen Spitzmüller wrote: What do others think? on top. if people want a toolbar elsewhere they can always drag it there i guess. talking about toolbars: i suggest to put the spellcheck button on the main toolbar
Re: Embedded Objects
Uwe == Uwe Stöhr [EMAIL PROTECTED] writes: So your EmbeddedObjects help file cannot be typeset. This is a blocker for 1.4.4. As a temporary measure, shall we remove reference to prettyref in the 1.4 version of the manual at least? Uwe I don't know, I only decribed what LyX supports, so when I should Uwe remove it in the doc, it should also be removed in LyX or better Uwe replaced by another command from a similar package to prettyref. The problem is that there is no drop-in replacement for prettyref.sty. And removing features from LyX 1.4 just so that its own docs work is not an option... Note that I did not mention 1.5 above. Another question Uwe: why is this discussion on references hidden in the Float chapter? There are many entities besides floats the deserve a reference. Uwe It is not, there is also a description in the table section. The Uwe manual describes the floats and not referencing at all. For Uwe example references to formulas will be described in the math Uwe manual I'm working on. Referencing in general is explained in Uwe detail in the Userguide. But the text I read did not have much information that was special to floats. Do you plan to repeat the same text over and over? JMarc
Re: Embedded Objects
Jean-Marc Lasgouttes wrote: Uwe I don't know, I only decribed what LyX supports, so when I should Uwe remove it in the doc, it should also be removed in LyX or better Uwe replaced by another command from a similar package to prettyref. The problem is that there is no drop-in replacement for prettyref.sty. Fancyref looked like a good successor once (particularly because it doesn't have the problems with active characters that prettyref has), but unfortunately, it's not maintained anymore (see bug 2295). And removing features from LyX 1.4 just so that its own docs work is not an option... Note that I did not mention 1.5 above. Agreed. I think the only thing we can do now is to describe prettyref without actually using it in the docs, like Formatted reference: prints a self defined cross-reference format including a prefix (depending on the paragraph type) and the number, e.g. Figure 1 (you need to have the package prettyref installed to use this feature; note that this package is not included in many recent LaTeX distributions) BTW, a description like reference on page page: prints the float number, the text on page, and the page number: strikes me highly tautological. Jürgen
Re: A status report on the current lyx-1.5.0svn support of CJK languages.
한창길 wrote: Hello, I have played around the current lyx-1.5.0svn for some time to test for the support of CJK languages, and here is my small report . 1. As I reported some time ago, lyx crashes whenever I try to input characters with text_size larger than 1 as recognized by lyx. For example, the text_size of all the Japanese characters is larger than 1 in my linux box, and in my windows box even korean characters are recognized as text_size 1. The cause of the crash seems to be due to this part of the code in src/qt4/QLyXKeySym.C, BOOST_ASSERT(text_.size() == 1); . As a workaround(most probably bad), I've removed this code from QLyXKeySym::getUCSEncoded(), and inputting any language characters becomes very smooth. Attached(multi3.png) is a screen shot of showing 4 language characters(English, Korean, Japanes, Chinese) on a lyx window. As I tried to explain last time you reported this, there is no such thing as multi-characters with unicode (well as far as CJK is concerned). I can input any CJK characters here (by copypaste from the web) without any problem (WinXP SP2, english edition). So I reckon that this is an encoding issue. I see that this mail uses the Korean EUC-KR encoding. Please try to set the encoding of your console to utf8 before launching LyX to see if there's any difference. But you are right that the assertion is false nevertheless as it does not take the full utf16 range. (It is possible to have two utf16 characters but not for CJK). I will put some debug statements instead of the assertion so that you can report back. Abdel.
Re: [Patch] fix caption inset selection bug
On Tue, Feb 06, 2007 at 10:57:23AM +0100, Abdelrazak Younes wrote: Martin Vermeer wrote: It is this simple (I think). (The inset API has its nice sides) Thanks for helping me at this. Abdel. OK. Could you commit it? - Martin pgpVeQfsUwWXL.pgp Description: PGP signature
Re: [Patch] fix caption inset selection bug
Martin Vermeer wrote: On Tue, Feb 06, 2007 at 10:57:23AM +0100, Abdelrazak Younes wrote: Martin Vermeer wrote: It is this simple (I think). (The inset API has its nice sides) Thanks for helping me at this. Abdel. OK. Could you commit it? I'll do it. Abdel.
Re: A status report on the current lyx-1.5.0svn support of CJK languages.
한창길 wrote: Hello, I have played around the current lyx-1.5.0svn for some time to test for the support of CJK languages, and here is my small report . 1. As I reported some time ago, lyx crashes whenever I try to input characters with text_size larger than 1 as recognized by lyx. For example, the text_size of all the Japanese characters is larger than 1 in my linux box, and in my windows box even korean characters are recognized as text_size 1. The cause of the crash seems to be due to this part of the code in src/qt4/QLyXKeySym.C, Please try again using -dbg key and report back. Abdel.
Re: Embedded Objects
Jürgen == Jürgen Spitzmüller [EMAIL PROTECTED] writes: Jürgen Agreed. I think the only thing we can do now is to describe Jürgen prettyref without actually using it in the docs, like Jürgen Formatted reference: prints a self defined cross-reference Jürgen format including a prefix (depending on the paragraph type) Jürgen and the number, e.g. Figure 1 (you need to have the package Jürgen prettyref installed to use this feature; note that this Jürgen package is not included in many recent LaTeX distributions) Jürgen BTW, a description like Jürgen reference on page : prints the float number, the text on Jürgen page, and the page number: strikes me highly tautological. I tried to work around prettyref problems to see how far I could get and the result is not very nice on my teTeX 2 setup. - caption.sty does not load (I do not know why). It is probably related to some package interaction. - my colortbl.sty does not have \cellcolor. At this point, I gave up. I can accept that teTeX 2 is too old and I guess I will be happy if we find some kind of fix for the prettyref situation. Also, the manual should state something like Since this manual uses many different packages, it may not be printable if you do not have a really up-to-date distribution. Uwe? JMarc
Re: [PATCH] Translating the LyX menu on the mac
Bennett == Bennett Helm [EMAIL PROTECTED] writes: Bennett I should also add: upon closing LyX (after sending the Bennett message), I noticed the following output in the Terminal Bennett window from which I had launched it. (I don't get this Bennett without the patch.) Bennett Menu warning: menu entries Ajouter Colonne|o and Copy Bennett Row|o share the same shortcut. I think this is related to the fact that you use the french locale. JMarc
Re: Embedded Objects
Jean-Marc Lasgouttes wrote: I tried to work around prettyref problems to see how far I could get and the result is not very nice on my teTeX 2 setup. - caption.sty does not load (I do not know why). It is probably related to some package interaction. You probably have caption.sty v1 and v2 (a.k.a. caption2.sty) on your box, but Uwe's manual requires a (fairly recent) version of caption.sty v. 3 (which is again called caption.sty for some odd reason). - my colortbl.sty does not have \cellcolor. This was introduced in colortbl 2001/02/13 v0.1j which is old enough, I'd say. At this point, I gave up. I can accept that teTeX 2 is too old and I guess I will be happy if we find some kind of fix for the prettyref situation. Also, the manual should state something like Since this manual uses many different packages, it may not be printable if you do not have a really up-to-date distribution. I guess it boils down to the decision whether we want to document all sorts of funky features or whether we care to not exclude users who don't have the most recent system available. It's not easy to find the golden mean here. I'd say that we probably could rely on teTeX 3 nowadays, but _not_ on the very latest version of MikTeX or TeXLive, for that matter. The circumstance that Uwe writes his (very good) manuals on a fairly recent MikTeX system that automatically downloads or updates missing packages probably entails such problems (nolens volens), in the same way as developping the frontend with the just-released Qt version might result in silent requirement bumps, if the developers are not over-cautious. Jürgen
Re: [PATCH] Translating the LyX menu on the mac
Bennett == Bennett Helm [EMAIL PROTECTED] writes:
Bennett This second version creates a new special menu between the
Bennett LyX and (in French) Fichier menus, and contains only one
Bennett item: Préférences (which has no keybinding, but properly
Bennett brings up the preferences dialog).
Bennett There is a Preferences item in the LyX menu, which is bound
Bennett to Cmd, (which is the default keybinding for Preferences).
Bennett This Preferences item was initially grayed out, but after I
Bennett opened a bunch of other menus it was no longer grayed out.
Bennett However, selecting it for some reason it opens
Bennett fr_Extended.lyx. (In the Aide menu, there is also a
Bennett Options Advancées item which does the same.)
Bennett Finally, in the LyX menu, there is an About LyX item that
Bennett brings up the correct dialog.
I do not know why this happens, to be frank. Could you try the
attached? I followed Abdel's code advice and made the translate method more
permissive.
If this does not work, we may have to use qt 4.2 support for mac menu.
Do you see a problem with requiring qt 4.2 on the mac? Or should we
keep 4.1 support as backup solution?
JMarc
Index: src/frontends/qt4/GuiApplication.C
===
--- src/frontends/qt4/GuiApplication.C (revision 17067)
+++ src/frontends/qt4/GuiApplication.C (working copy)
@@ -30,6 +30,7 @@
#include Color.h
#include debug.h
#include funcrequest.h
+#include gettext.h
#include lyx_main.h
#include lyxfunc.h
#include lyxrc.h
@@ -113,9 +114,9 @@ GuiApplication::GuiApplication(int arg
if (qt_trans_.load(language_name,
QLibraryInfo::location(QLibraryInfo::TranslationsPath)))
{
- qApp-installTranslator(qt_trans_);
+ installTranslator(qt_trans_);
// even if the language calls for RtL, don't do that
- qApp-setLayoutDirection(Qt::LeftToRight);
+ setLayoutDirection(Qt::LeftToRight);
lyxerr[Debug::GUI]
Successfully installed Qt translations for locale
fromqstr(language_name) std::endl;
@@ -124,6 +125,11 @@ GuiApplication::GuiApplication(int arg
Could not find Qt translations for locale
fromqstr(language_name) std::endl;
+#ifdef Q_WS_MAC
+ // This allows to translate the strings that appear in the LyX menu.
+ addMenuTranslator();
+#endif
+
using namespace lyx::graphics;
Image::newImage = boost::bind(QLImage::newImage);
@@ -305,6 +311,38 @@ bool GuiApplication::x11EventFilter(XEve
#endif
+
+// Mac specific stuff goes here...
+
+class MenuTranslator : public QTranslator {
+public:
+ virtual ~MenuTranslator() {};
+ virtual QString translate(const char * context,
+ const char * sourceText,
+ const char * comment = 0) const;
+};
+
+
+QString MenuTranslator::translate(const char * /*context*/,
+ const char * sourceText,
+ const char *) const
+{
+ string const s = sourceText;
+ if (s == N_(About LyX)
+ || s == N_(Preferences) || s == N_(Quit LyX))
+ return qt_(s);
+ else
+ return QString();
+}
+
+
+void GuiApplication::addMenuTranslator()
+{
+ menu_trans_.reset(new MenuTranslator());
+ installTranslator(menu_trans_.get());
+}
+
+
} // namespace frontend
} // namespace lyx
Index: src/frontends/qt4/GuiApplication.h
===
--- src/frontends/qt4/GuiApplication.h (revision 17067)
+++ src/frontends/qt4/GuiApplication.h (working copy)
@@ -21,6 +21,8 @@
#include frontends/Application.h
+#include boost/scoped_ptr.hpp
+
#include QApplication
#include QTranslator
@@ -32,6 +34,7 @@ class socket_callback;
namespace frontend {
class GuiWorkArea;
+class MenuTranslator;
/// The Qt main application class
/**
@@ -102,6 +105,11 @@ public:
bool x11EventFilter (XEvent * ev);
#endif
+ /// A translator suitable for the entries in the LyX menu.
+ /// Only needed with Qt/Mac.
+ void addMenuTranslator();
+ ///
+ boost::scoped_ptrMenuTranslator menu_trans_;
}; // GuiApplication
extern GuiApplication * guiApp;
Re: Embedded Objects
Jürgen == Jürgen Spitzmüller [EMAIL PROTECTED] writes: Jürgen You probably have caption.sty v1 and v2 (a.k.a. caption2.sty) Jürgen on your box, but Uwe's manual requires a (fairly recent) Jürgen version of caption.sty v. 3 (which is again called caption.sty Jürgen for some odd reason). I am not sure it is a good idea to require that. Why is it needed? - my colortbl.sty does not have \cellcolor. Jürgen This was introduced in colortbl 2001/02/13 v0.1j Jürgen which is old enough, I'd say. Indeed. Jürgen I guess it boils down to the decision whether we want to Jürgen document all sorts of funky features or whether we care to not Jürgen exclude users who don't have the most recent system available. Jürgen It's not easy to find the golden mean here. Also, a problem with recommending esoteric packages as if it was routine LyX usage is that we have to make sure that files using that will continue to work with future version of LyX and of the packages themselves. In the past, we tried to select packages known for being stable. Jürgen I'd say that we probably could rely on teTeX 3 nowadays, but Jürgen _not_ on the very latest version of MikTeX or TeXLive, for Jürgen that matter. Does the document print with teTeX3? JMarc
Re: the new sidebar
On Tue, Feb 06, 2007 at 02:15:19PM +0100, Edwin Leuven wrote: Jürgen Spitzmüller wrote: What do others think? on top. if people want a toolbar elsewhere they can always drag it there i guess. Is there some way to tell lyx to put it on the same line as another toolbar? john
Re: the new sidebar
John Levon wrote: Is there some way to tell lyx to put it on the same line as another toolbar? No. But session restores the toolbars on the line you dragged them to. Jürgen
Re: the new sidebar
Jürgen Spitzmüller wrote: John Levon wrote: Is there some way to tell lyx to put it on the same line as another toolbar? No. But session restores the toolbars on the line you dragged them to. Well, in a way, if he drags the line there he's telling LyX to put it there, isn't he? ;-) Abdel.
Re: Embedded Objects
Jean-Marc Lasgouttes wrote:
Jürgen == Jürgen Spitzmüller [EMAIL PROTECTED] writes:
Jürgen You probably have caption.sty v1 and v2 (a.k.a. caption2.sty)
Jürgen on your box, but Uwe's manual requires a (fairly recent)
Jürgen version of caption.sty v. 3 (which is again called caption.sty
Jürgen for some odd reason).
I am not sure it is a good idea to require that. Why is it needed?
caption3 indeed has some important enhancement compared to the previous
versions. But I'm not sure either we really have to rely on that (one reason
might be the tableposition param which is new).
But even if we do, I think we should load it as
\usepackage[labelfont={bf,sf}, tableposition=top]{caption}[2004/07/16]
to get a proper error message if the installed package is too old.
Jürgen I guess it boils down to the decision whether we want to
Jürgen document all sorts of funky features or whether we care to not
Jürgen exclude users who don't have the most recent system available.
Jürgen It's not easy to find the golden mean here.
Also, a problem with recommending esoteric packages as if it was
routine LyX usage is that we have to make sure that files using that
will continue to work with future version of LyX and of the packages
themselves. In the past, we tried to select packages known for being
stable.
what is esoteric? Can we define that as not in teTeX? But then, teTeX is
not maintained anymore.
Jürgen I'd say that we probably could rely on teTeX 3 nowadays, but
Jürgen _not_ on the very latest version of MikTeX or TeXLive, for
Jürgen that matter.
Does the document print with teTeX3?
With the exception of arydshln (or however it is called) and marginpar, which
we recently excluded: yes (on my openSuse 10.2 teTeX. I'm not sure whether it
is a stock teTeX 3 o whether they did some upgrades from CTAN).
JMarc
Jürgen
Re: the new sidebar
On Tue, Feb 06, 2007 at 04:32:45PM +0100, Jürgen Spitzmüller wrote: Is there some way to tell lyx to put it on the same line as another toolbar? No. But session restores the toolbars on the line you dragged them to. Well, I was thinking of how we make the dvi toolbar default to not using an entire new line... regards john
Re: the new sidebar
John Levon wrote: Well, I was thinking of how we make the dvi toolbar default to not using an entire new line... It's not possible. Initially, all toolbars get their own line. However, once you moved the dvi toolbar, say, bhing the main toolbar, it will be restored in that line by session. Jürgen
Re: Fixed: toolbar management problem - another problem
Georg Baum wrote: oddity. With qt42.2.2 fixing it I see no reason to spend more time on it - qt4.2.2 will come to debian too. But not very soon. Etch (the next stable release) is frozen and will be released with 4.2.1. Therefore many people (including me) will use 4.2.1 for a long time. It really frustrates me that there is so little will to support anything but the latest and greatest programs and libraries. It'd sure be nice if this can be fixed for 4.2.1 too. But the problem is very small - that's why I don't recommend spending time on it. There are enough much bigger problems - the scrollbar that keeps rolling for 2s after I release the mouse button, for example. Helge Hafting
Re: the new sidebar
On Tue, Feb 06, 2007 at 04:46:59PM +0100, Jürgen Spitzmüller wrote: Well, I was thinking of how we make the dvi toolbar default to not using an entire new line... It's not possible. Initially, all toolbars get their own line. However, once you moved the dvi toolbar, say, bhing the main toolbar, it will be restored in that line by session. Then have we considered making this small toolbar just added onto the first toolbar? regards john
Re: the new sidebar
John Levon wrote: Then have we considered making this small toolbar just added onto the first toolbar? You mean: include it in the main toolbar? Yes. But this has the disadvantage that it cannot be switched on/off in toto. What is your problem with the current approach? Jürgen
Re: the new sidebar
On Tue, Feb 06, 2007 at 05:22:42PM +0100, Jürgen Spitzmüller wrote: Then have we considered making this small toolbar just added onto the first toolbar? You mean: include it in the main toolbar? Yes. But this has the disadvantage that it cannot be switched on/off in toto. What is your problem with the current approach? You've confused me. My problem is that it's on the RHS ... was there a commit I missed? regards john
Re: the new sidebar
John Levon wrote: What is your problem with the current approach? You've confused me. My problem is that it's on the RHS ... was there a commit I missed? No. However, I proposed to put it on top initially. Uwe put it on the RHS because until recently, every toolbar got its own row on top, which meant 3 rows in any case (it was not possible to store the position) Now, it is possible to put multiple toolbars on the same row and the position is stored, but only on session level, i.e. after the user had dragged it on the first row, for instance. My proposal means: Initially, you would get the three toolbars on 3 rows. If you dragged the view toolbar on the first or third row, you would get two rows after that, because session restores that. Clearer now? Jürgen
Re: Fixed: toolbar management problem - another problem
Jean-Marc Lasgouttes wrote: Peter == Peter Kümmel [EMAIL PROTECTED] writes: Peter I assume because much has changed in the last year, more than Peter the years before, so some LyX-Veterans are a bit astonished. You know, we did not wait for young blood to go coding wildly and implement multi-windows and window splitting and many other fun things. This was at LyX 1.1 (the first incarnation) time. And then we saw that we coded so many nice things that the program was severely broken and we scraped everything to go back to 1.0.4 code base. And then we decided it might be a good idea to have some idea of were we are going and to enforce plans for releases and mundane things like that. That said, I am not very interested in this veterans vs. young blood pissing contests. This is not what we need now This was not my intention. JMarc, who swears he's been forced to play the grumpy oldtimer and who'd prefer to release 1.4.4 instead. Sorry, for forcing you into this role. Peter
Re: Fixed: toolbar management problem - another problem
Jean-Marc Lasgouttes wrote: Peter == Peter Kümmel [EMAIL PROTECTED] writes: Peter What about the rule to use on Windows the latest and greatest Peter Qt release and on Linux only an old one? It depends. If there is a _windows_ _only_ thing that cannot be done with qt 4.1 it is OK. If it just that you'd love to play with the new QRoundedGlowingWindow because it is there, the answer is probably no. Was there so much playing with new features? Most of them we've used to fix Qt bugs (currently only Bo's setting code comes up to my mind). We do not want to have two code bases just because we can. I do not think that the fact that LyX 1.4 can compile with qt 3.0 really hampered its development. JMarc -- Peter Kümmel
Re: Fixed: toolbar management problem - another problem
Jean-Marc Lasgouttes wrote: Peter == Peter Kümmel [EMAIL PROTECTED] writes: You expressed it very well, Georg. And I'll just reiterate that this is how linux works. So please be nice guys for poor old linux users. Peter Are #ifdefs ok then? Let me give you an example that is OK: currently there is some ugly code of mine to handle menus on Qt/Mac. Now in Qt 4.2 trolltech has finally done what they should have done for the first mac release and introduced the MenuRole concept. Since Qt is bundled with LyX/Mac, I think it may make sense to use this feature for the Mac and decide that LyX/Mac requires Qt 3.2. This will allow to remove ugly code that is difficult to make correctly work. OK, and what about this example: Qt 4.3 will have a new file dialog: http://qtdeveloper.net/archives/2007/02/05/new-qt-file-dialog/ and I could imagine that it is maybe possible to use the native dialog and to add buttons for the lyx directories. Is this playing with new features? Or makes it sens? However, if I manage to make the current code to work as I wish, I will probably say yes, it is the way to go, but we can do it later. Personally, I use Qt 4.1.something and have no intention to upgrade. I think it is good that developers do not use latest and greatest without a good reason, since that removes a silly temptation. JMarc -- Peter Kümmel
scrollbar context menu
Should we disable the context menu (right mouse click) of the scrollbar? Currently the functionality is not bug free? Peter Index: src/frontends/qt4/GuiWorkArea.C === --- src/frontends/qt4/GuiWorkArea.C (revision 17071) +++ src/frontends/qt4/GuiWorkArea.C (working copy) @@ -189,6 +189,9 @@ QObject::connect(verticalScrollBar(), SIGNAL(actionTriggered(int)), this, SLOT(adjustViewWithScrollBar(int))); + // disable context menu for the scrollbar + verticalScrollBar()-setContextMenuPolicy(Qt::NoContextMenu); + // PageStep only depends on the viewport height. verticalScrollBar()-setPageStep(viewport()-height());
Re: Embedded Objects
But the text I read did not have much information that was special to floats. Do you plan to repeat the same text over and over? In this manual are two contruct types that can bereferenced: Floats and Longtables. Reference handling for Longtable is quite different and decribed in the corresponding section. This manual is not about referencing bibliography, sections, numerations/itemizations, or math. regards Uwe
Re: [PATCH] Translating the LyX menu on the mac
On Mon, Feb 05, 2007 at 04:36:01PM +0100, Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
+
+// Mac specific stuff goes here...
+#ifdef Q_WS_MACX
+
+class MenuTranslator : public QTranslator {
+virtual QString translate(const char * context,
+ const char * sourceText,
+ const char * comment = 0) const;
I don't see where in your patch MenuTranslator::translate() is called.
If this is called internally by Qt, then I suggest to add a virtual
destructor to MenuTranslator.
Which would not be needed if the base class already has one.
Andre'
Re: Toolbar management problem
On Sun, Feb 04, 2007 at 11:20:20PM +0100, [EMAIL PROTECTED] wrote: On Sun, 4 Feb 2007, Abdelrazak Younes wrote: And could you do that for LyX? That would be very nice... Somewhat related (as we're already off-topic), it'd probably be a good idea testing the Windows installers in virtual machines. Then it'd be relatively easy to start from the same situation all the time. That's what we do, anyway. This is especially helpful in a world where uninstallers rarely uninstall everything they are supposed to. [Getting cleanish uninstalls is btw one of the few positive aspects of .msi] Andre'
Re: Mildly interesting...
On Sun, Feb 04, 2007 at 12:49:43AM +, John Levon wrote: On Sat, Feb 03, 2007 at 11:26:56PM +0100, Abdelrazak Younes wrote: Personally I would be interested to do some paid work for LyX. I am running out of contract in 6 month... maybe I'll do a reconversion in the software engineering :-). But something disturbs me a bit... is $55000 a correct year salary in the states? It sounds very low to me. Since we are at it: What would be 'average'? Andre'
Re: Fixed: toolbar management problem - another problem
On Sun, Feb 04, 2007 at 11:13:40AM -0800, Angus Leeming wrote: Uwe Stöhr wrote: Why this? The installer we currently have works also under Vista. We have a user who tested this: http://www.mail-archive.com/lyx-users@lists.lyx.org/msg53432.html (The problem he described there was only a bug from me (I delivered a wrong LyX.py version).) I also tested my installer in our institute on Vista RC1 and it worked. That's not the same thing at all as being certified: http://microsoft.mrmpslc.com/InnovateOnWindowsVista/getstartedcert.aspx Which reminds me of an open question: Is the set of certifiable software installing per-machine start menu shortcuts empty or not? Andre'
Re: [Cvslog] r17058 - /lyx-devel/trunk/src/insets/insetcollapsable.C
On Mon, Feb 05, 2007 at 05:07:48PM -, [EMAIL PROTECTED] wrote:
URL: http://www.lyx.org/trac/changeset/17058
Log:
* Fix bug 3202 (http://bugzilla.lyx.org/show_bug.cgi?id=3202)
* Augment a bit the space between nested insets.
Modified:
lyx-devel/trunk/src/insets/insetcollapsable.C
Modified: lyx-devel/trunk/src/insets/insetcollapsable.C
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/insets/insetcollapsable.C?rev=17058
==
--- lyx-devel/trunk/src/insets/insetcollapsable.C (original)
+++ lyx-devel/trunk/src/insets/insetcollapsable.C Mon Feb 5 18:07:44 2007
@@ -152,7 +152,7 @@
bool InsetCollapsable::metrics(MetricsInfo mi, Dimension dim) const
{
autoOpen_ = mi.base.bv-cursor().isInside(this);
- mi.base.textwidth -= 2 * TEXT_TO_INSET_OFFSET;
+ mi.base.textwidth -= (int) 1.5 * TEXT_TO_INSET_OFFSET;
This is equivalent to 1 * TEXT_TO_INSET_OFFSET.
Andre'
Re: Fixed: toolbar management problem - another problem
On Mon, Feb 05, 2007 at 09:07:41AM +0200, Martin Vermeer wrote: Is it too early to talk about a LyX 2007 meeting? Certainly not. Andre'
Re: Toolbar management problem
On Sun, Feb 04, 2007 at 11:02:07PM +0100, Abdelrazak Younes wrote: Andre Poenitz wrote: And how many full-time people do you have to provide these 15 versions for linux? Took me about two weeks full-time to set up all the virtual machines (i.e. install OS, install required development packages, work around installation quirks etc.) Now a full recompile of our stuff is a bit more than an hour per platform, and about double that time when I rebuild Qt as well (which is not really needed dayly as I don't build Qt snapshot, only real releases). Starting such a build is typing 'make nightly' on a certain console, i.e. including login less than 20 seconds of my own time. And could you do that for LyX? That would be very nice... In theory? Yes. In practise it would probably require even less than two weeks full time as LyX has less compile time dependencies than that project at work. However, I doubt that'd be significantly more than I spent on LyX work during the whole 1.5 cycle... [Things may improve a bit when we get DSL. It's on the way already...] However, I do not really think we need that. Distros are fairly good at pulling what they need... Andre'
Re: Fixed: toolbar management problem - another problem
On Mon, Feb 05, 2007 at 01:51:36AM +0100, Uwe Stöhr wrote: Now Andre mentioned that Vista certification would require an ^ ^ ! .msi-installer. Although I'm not sure we'd ever try for that, it probably would make sense to check out Vista requirements for the installer - which I have no clue whatsoever where to do. Why this? The installer we currently have works also under Vista. There is a difference between 'can be certified' and 'works'. The difference is not really interesting as long as one does not need certification. In Vista there are seemingly already a few areas that need certification one way or the other. Drivers for instance. I would not be surprised if in the next major release all software needs to have some kind of MS approval stamp on it - at least that's clearly the direction Vista is heading... I also tested my installer in our institute on Vista RC1 and it worked. Btw note that the 64 bit version is more agressive in general. Andre'
Re: Suggestions to the official windows installer
On Sun, Feb 04, 2007 at 11:11:12PM +0100, Jean-Marc Lasgouttes wrote: Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre Have you had the chance of having a look at the requirements Andre for an installer on Windows Vista? Andre At least for Vista certification this means .msi (or some Andre special kind of hit-and-run kind of installer that's not really Andre useful for much more that a couple of help files or such) and Andre sticking to a couple of rules that does not make overly much Andre sense to someone still in the posession of his brain. But do we plan to get certified? I doubt so. There are better ways to waste money for an OSS project. Andre'
Re: Mildly interesting...
It sounds very low to me. Since we are at it: What would be 'average'? I think I am 'above average'. :-) Bo
tooltips are back
The tooltips are back. Does anybody know why? Peter
Re: Embedded Objects
You probably have caption.sty v1 and v2 (a.k.a. caption2.sty) on your box, but Uwe's manual requires a (fairly recent) version of caption.sty v. 3 (which is again called caption.sty for some odd reason). The version 3 of caption.sty was not published as caption3.sty but again as caption.sty. This is a bit confusing but caption.sty could be caption v1 or caption v3. - my colortbl.sty does not have \cellcolor. That's the same problematic as with the Solaris ImageMagick problem. I don't understand why the Linux-distributions ship 5 years old stuff. Stability is one point but when it leads to incompatibilites. The distros for example always ship the latest Gnome and KDE, so why not also the other stuff. teTeX 3 is now 3 years old and I it is recommended not to use teTeX 2 anymore. There are many changes concerning pdftex, dvips, and teTeX 2 doesn't have the since a while required eTeX-extensions. So using teTeX 2 could also cause troubles with other programs. A bit off-topic: (teTeX is not user-friendly: We had the case here that Hartmut Haase needed some days until he was able to install the missing LaTeX-package to be able to translate all parts of the new manual. This is done automatically or only three clicks way here with MiKTeX, whose package manager is currently ported to Linux. I don't know how with this infrastructure users is able to install a LaTeX-font.) At this point, I gave up. I can accept that teTeX 2 is too old and I guess I will be happy if we find some kind of fix for the prettyref situation. Also, the manual should state something like Since this manual uses many different packages, it may not be printable if you do not have a really up-to-date distribution. I asked a collegue to test my document with teTeX 3 and he told me that it works when prettyref is installed he installed it manually). I'd say that we probably could rely on teTeX 3 nowadays, but _not_ on the very latest version of MikTeX or TeXLive, for that matter. The document doesn't require the latest MiKTeX or TeXLive. TeXLive 2005 compiles it fine. (I could not test TeXLive 2004 but I see no reason why this shouldn't work.) I'll remove the preetyref inset in the docs but cannot do this before the weekend. The removal require more work because I built in a hack because prettyref destroys some hyperref stuff. But I still dont see that this is a showstopper, see my point below. --- Concerning the general LaTeX-package support: You said that the prettyref support was a fault, why? Because it's not in a certain LaTeX-distro? This rule doesn't apply for MiKTeX, where many of the packages LyX supports are not in the basic installation and must be installed on demand. So where should be the border? For example we often have requests to support the listings package. I also would like to support it but as this is not in MiKTeX's default installation, it cannot be supported? Aren't the LaTeX-distros for Linux not also only basic installations and you have to install missing packages on demand? Btw. As teTeX is no longer developed the Linux distros have to switch to TeXLive the next times. With TeXLive you are always up to date because it has a build in update manager.
Re: Fixed: toolbar management problem - another problem
Andre Poenitz schrieb: In Vista there are seemingly already a few areas that need certification one way or the other. Drivers for instance. I would not be surprised if in the next major release all software needs to have some kind of MS approval stamp on it - at least that's clearly the direction Vista is heading... That's not your thruth. This will never happen, because this would be the end of free software. You could also speculate that they won't approve software that is OpenSource or something. Requiring approved drivers is another thing because only drivers can go so deep in Windows to produce blue-sreens and really corrupt the system. Btw note that the 64 bit version is more agressive in general. I'm developing the installer on a XP 64-bit Windows that still has the same new registry handling that's also in Vista. regards Uwe
Re: Embedded Objects
Uwe Stöhr wrote:
You probably have caption.sty v1 and v2 (a.k.a. caption2.sty) on your
box, but Uwe's manual requires a (fairly recent) version of caption.sty
v. 3 (which is again called caption.sty for some odd reason).
The version 3 of caption.sty was not published as caption3.sty but again as
caption.sty. This is a bit confusing but caption.sty could be caption v1 or
caption v3.
Yes, that's what I wrote above.
Nevertheless, please load it with the release date as optional argument
\usepackage[labelfont={bf,sf}, tableposition=top]{caption}[2004/07/16]
since the document will not compile with any version of caption3
(tableposition was not included in the first caption3 version).
- my colortbl.sty does not have \cellcolor.
That's the same problematic as with the Solaris ImageMagick problem. I
don't understand why the Linux-distributions ship 5 years old stuff.
Stability is one point but when it leads to incompatibilites. The distros
for example always ship the latest Gnome and KDE, so why not also the other
stuff.
Recent distros ship teTeX 3 AFAIK (and I think most will ship to some home
brewn, limited version of TeX Live, now that teTeX is dead, which will
certainly not decrease our problem).
Anyway, maybe Jean-Marc relies on a system where, for some reason, upgrading
is not an issue. I already stressed this several times, and I say it again:
Not everybody uses LyX on his own computer. If your admin refuses to upgrade
the LaTeX distro for some reason, you have to live with what's installed.
Period.
teTeX 3 is now 3 years old and I it is recommended not to use teTeX 2
anymore. There are many changes concerning pdftex, dvips, and teTeX 2
doesn't have the since a while required eTeX-extensions. So using teTeX 2
could also cause troubles with other programs.
I agree that teTeX 2 is not the measure anymore (and I think Jean-Marc agrees
as well).
A bit off-topic:
(teTeX is not user-friendly:
We had the case here that Hartmut Haase needed some days until he was able
to install the missing LaTeX-package to be able to translate all parts of
the new manual. This is done automatically or only three clicks way here
with MiKTeX, whose package manager is currently ported to Linux. I don't
know how with this infrastructure users is able to install a LaTeX-font.)
So what? teTeX has been the de facto LaTeX distribution for many years, most
other distributions were built on top of that (I'm pretty sure also MikTeX
was initially built on top of teTeX).
Also, user friendliness is in the eye of the beholder. A LaTeX package manager
is really nothing I miss on Linux.
The document doesn't require the latest MiKTeX or TeXLive. TeXLive 2005
compiles it fine. (I could not test TeXLive 2004 but I see no reason why
this shouldn't work.)
Good, then. If it compiles with teTeX 3, it's fine with me.
I'll remove the preetyref inset in the docs but cannot do this before the
weekend. The removal require more work because I built in a hack because
prettyref destroys some hyperref stuff. But I still dont see that this is a
showstopper, see my point below.
Hm, that's probably a bit late for 1.4.4. But Jean-Marc is to decide.
---
Concerning the general LaTeX-package support:
You said that the prettyref support was a fault, why? Because it's not in a
certain LaTeX-distro?
- It's not in teTeX and therefore not in most Linux distributions. Why?
Because it has some license issues.
- It's unmaintained since a long time.
- It is unusable for language where the colon is made active (like French)
This rule doesn't apply for MiKTeX, where many of the
packages LyX supports are not in the basic installation and must be
installed on demand. So where should be the border? For example we often
have requests to support the listings package. I also would like to support
it but as this is not in MiKTeX's default installation, it cannot be
supported?
It's not easy to get a clearly defined border. Of course you can support
packages that have to be added first (like dvipost, for instance). But
ideally, a.) these functionality should be disabled when the package is not
installed and b.) in a range of alternatives, the most widespread and stable
package should be used. The latter can change, as was the case for the font
packages, for instance.
Aren't the LaTeX-distros for Linux not also only basic
installations and you have to install missing packages on demand?
Certainly. But remember how many bug reports we had in the past: My User
Guide does not compile because it cannot find prettyref! What is that?
Btw. As teTeX is no longer developed the Linux distros have to switch to
TeXLive the next times. With TeXLive you are always up to date because it
has a build in update manager.
I believe that when I see it. Also, I doubt that any Linux distribution will
ship the complete TeXLive distro. They will rather ship smaller, home brewn
subsets (which will be again
Re: Fixed: toolbar management problem - another problem
Am Dienstag, 6. Februar 2007 12:12 schrieb Abdelrazak Younes: OK, I quit the discussion. Revert the change if you want. I don't want that. After all, it might be the right solution for the moment, or I might be the only one who considers that a hack. What I did not like was that it went in without discussion, but since I don't have the time right now to investigate this I am not in a position to remove it. And please note that my post was not intended at all as personal attack (which you might have thought it was, I am not sure). I took the longtable caption change as an example, simply because it was the last one I saw, but I could as well have taken any other change, for example the name of EmbeddedObjects.lyx ping pong by Michael and Uwe. Georg
Re: Caption: Inset or not Inset?
Am Sonntag, 4. Februar 2007 19:08 schrieb Michael Gerz: Hello, Jean-Marc recently raised the question whether an inset is really the proper solution for captions. I didn't come to a final conclusion on my own but I think we should come to an agreement and stick with it. I think that Jean-Marc's concern regarding the customization of captions is a valid point. When converting the layout files, I noticed that some document classes have extra styles like CenteredCaption, CaptionBelow, CaptionAbove. How do these layout styles relate to the caption inset? Probably not at all. No. Is this is problem? I don't know... This is not a problem now (because the old caption hacks did not work for these anyway), but of course in the future all captions should be handled alike. Having everything as an inset sounds very nice at first glance but meanwhile I am not so sure anymore. Where exactly do we draw the line? One rule would be: - If XXX is a general-purpose thing whose underlying concept does not vary among different document classes, make it an inset. - If XXX is specific to a particular doc class, make it a paragraph layout. In the case of captions, there is not definitive answer. Is there some text processing feature that can be implemented only if we know about all captions in a document? If the answer is true, then IMHO we should stick with the inset solution. In any case, I think we should discuss this very soon, because a lot of files have changed due to the layout=inset conversion. Indeed. When I was pushing the caption inset patch I did not see the problems we now see. To me it looked like it was a good way to get rid of some hacks with only minore drawbacks. Now I see that we need other hacks instead, or to rebuild a lot of layout functionality for the inset. At the moment I am really unsure what the best solution is, but tend a bit to the layout variant. If we decide to get rid of the inset I can do it when I have some more time, the lyx2lyx changes are trivial (just use convert_caption and revert_caption again, but in exchanged positions). Georg
Re: Fixed: toolbar management problem - another problem
Am Montag, 5. Februar 2007 20:26 schrieb Peter Kümmel: Are there really security updates of the distro versions of Qt? Yes. A quick search for the last known one resulted in this one: http://www.debian.org/security/2006/dsa-1200 I was only a question :) Sure, but I had the impression that this was considered seriously not only by you. Georg
Re: Mildly interesting...
Andre Poenitz [EMAIL PROTECTED] writes: Since we are at it: What would be 'average'? The 66th percentile for a competent new hire (meaning a certain company pays a base salary that matches or exceeds 66% of other US companies for the same kind of work) is about one and a half times that. Many of these companies will also pay employees with some kind of stock award/option. US tax comes in at about 20% of total salary. The likely downside if you're coming from abroad is that you'll go from being a two income household to a one income household. Of course, if your better half can also organize a company to sponsor them through the visa process, you're laughing... Anybody interested still? I can put names forward... Angus
Re: es_EmbeddedObjects
Original-Nachricht Betreff: Re: es_EmbeddedObjects Datum: Tue, 06 Feb 2007 10:05:14 +0100 Von: Ignacio García [EMAIL PROTECTED] Antwort an: [EMAIL PROTECTED] An: [EMAIL PROTECTED] CC: lyx-docs@lists.lyx.org Referenzen: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] On Tue, 06 Feb 2007 02:12:45 +0100 Uwe Stöhr [EMAIL PROTECTED] wrote: Hello Ignacio, I forgot to ask you officially to grant us permissions to include your translation work to LyX. If yes, then plese reply to this email in the following form: Hereby I grant permissions ... ... to put my work under the GPL v2 ... Please CC your reply to the lyx-devel list and /or the lyx-docs list. thanks and regards Uwe (I had it already, http://www.mail-archive.com/lyx-docs@lists.lyx.org/msg02249.html) Hereby I grant permission to license my contributions to LyX under the GNU General Public License, version 2 or later. Regards Ignacio Garcia
Re: Fixed: toolbar management problem - another problem
Am Sonntag, 4. Februar 2007 19:25 schrieb Bo Peng: We are supposed to manage a project, not just write code. For this particular problem, I have declared WONT FIX for qt 4.2.2. There are a lot more severer bugs there and it would be a waste of time to work on a fixed bug. People who believe saveState/restoreState can magically solve all problems are welcome to do so. AFAIK the current code positions the toolbars by hand, and the recommended way is to use saveState/restoreState. Therefore it is IMHO unlikely that a qt bug that is present in the rarely used positioning methods is also present in the more frequently used saveState/restoreState. But I am not going to prove you that, since I agree with you that there are more severe problems to fix. Georg
Re: [Bug 2418] LyX cannot correctly determine PDF image size
Am Sonntag, 4. Februar 2007 17:42 schrieb Jean-Marc Lasgouttes: Georg == Georg Baum [EMAIL PROTECTED] writes: Georg I finally believe that we always should output the extension. Georg See also http://bugzilla.lyx.org/show_bug.cgi?id=2764. Georg The original purpose of leaving out the extension (making the Georg file work with both pdflatex and latex) is not valid anymore, Georg since we have a separate export format for pdflatex that does Georg also take other differences into account. Georg Unless somebody complains I will make the graphics inset Georg unconditionally output the extension soon. It looks reasonable to me, but I am sure that there are people who depend on the current behavior (which may not be a problem). Another option would be to introduce a sort of raw latex export format. I remember getting flamed for adding the automatic image conversion to latex export, so this raw format would omit the image conversion and also the extension of images. It would be easy to implement, but do we want that? I don't know. Georg
Re: Fixed: toolbar management problem - another problem
Am Sonntag, 4. Februar 2007 16:57 schrieb Bo Peng: No, I think like André here: Not using basic qt 4.0 functionality means that 4.2.2 is required. I know why you do that, but I don't agree with the reasons. I do not understand what is the big fuss here. The problem is clearly caused by a qt bug that has been fixed in qt 4.2.2. It is not a big deal even without qt4.2.2. Why you prefer to take another totally different approach to fix a fixed bug is beyond me. Well, the bug is not fixed in qt 4.2.1, so I am not talking about fixing a fixed bug in a different way. But you are right, it is only a minor problem. Georg
Re: Fixed: toolbar management problem - another problem
Am Dienstag, 6. Februar 2007 20:47 schrieb Uwe Stöhr: Andre Poenitz schrieb: In Vista there are seemingly already a few areas that need certification one way or the other. Drivers for instance. I would not be surprised if in the next major release all software needs to have some kind of MS approval stamp on it - at least that's clearly the direction Vista is heading... That's not your thruth. This will never happen, because this would be the end of free software. Why do you think so? Microsoft is not forced to support free software. It is a company that wants to make profit. It will support free software if the management thinks it will help, it will tolerate it if the management thinks it does not hurt and it will fight it if the management thinks that that will help. I know examples for all three cases. Whether these decisions will be the right ones or not is a completely different question. Why should they not decide that a certification is needed? And there are many good reasons for enforcing a certification. In the past only few software vendors cared for the various guidelines set up by microsoft (e. g. about security and not requiring admin privileges). Since software vendors did not follow these guidelines voluntarily they might need to be enforced. Georg
Re: Embedded Objects
Jürgen Spitzmüller schrieb:
Nevertheless, please load it with the release date as optional argument
\usepackage[labelfont={bf,sf}, tableposition=top]{caption}[2004/07/16]
Done.
Also, user friendliness is in the eye of the beholder. A LaTeX package manager
is really nothing I miss on Linux.
OK, but I think Harmut is an experienced LyXer on Linux and should therefore be able to install
LaTeX-packages.
Good, then. If it compiles with teTeX 3, it's fine with me.
I've read that you also tested this with success, right?
I'll remove the preetyref inset in the docs but cannot do this before the
weekend. The removal require more work because I built in a hack because
prettyref destroys some hyperref stuff. But I still dont see that this is a
showstopper, see my point below.
Hm, that's probably a bit late for 1.4.4. But Jean-Marc is to decide.
He want to have it removed before LyX 1.4.4 comes out because he see this as
showstopper.
You said that the prettyref support was a fault, why? Because it's not in a
certain LaTeX-distro?
...
- It's unmaintained since a long time.
- It is unusable for language where the colon is made active (like French)
This is the point.
regards Uwe
Re: Embedded Objects
Am Dienstag, 6. Februar 2007 20:40 schrieb Uwe Stöhr: That's the same problematic as with the Solaris ImageMagick problem. I don't understand why the Linux-distributions ship 5 years old stuff. I don't know current distros that ship tetex 2, but at work I am forced to use tetex 2 unless I want to maintain a complete tex installation on my own. You simply have to accept that many users can not upgrade their OS at will for various reasons. Stability is one point but when it leads to incompatibilites. The distros for example always ship the latest Gnome and KDE, so why not also the other stuff. teTeX 3 is now 3 years old and I it is recommended not to use teTeX 2 anymore. There are many changes concerning pdftex, dvips, and teTeX 2 doesn't have the since a while required eTeX-extensions. So using teTeX 2 could also cause troubles with other programs. Sure, but OTH it works fine for everything I need at work. I did install a few extra packages (such as prettyref), but thats it. You said that the prettyref support was a fault, why? Because it's not in a certain LaTeX-distro? This rule doesn't apply for MiKTeX, where many of the packages LyX supports are not in the basic installation and must be installed on demand. So where should be the border? For example we often have requests to support the listings package. I also would like to support it but as this is not in MiKTeX's default installation, it cannot be supported? Aren't the LaTeX-distros for Linux not also only basic installations and you have to install missing packages on demand? That depends. Some distros have only basic tex support, others have very good one, for example debian even has a beamer packages since years that installs the layout file into the lyx folder. Btw. As teTeX is no longer developed the Linux distros have to switch to TeXLive the next times. With TeXLive you are always up to date because it has a build in update manager. I doubt that. I install what comes via apt-get update; apt-get upgrade, and I know many people who do the same. A latex package manager is simply a much less urgent issue on linux, and not needed at all if you use a distro with good tex support. In fact, based on my experience with application specific package managers (for perl and php) I would not be surprised if it would be much harder to use than manual installation from ctan. Georg
Re: Embedded Objects
Am Dienstag, 6. Februar 2007 22:43 schrieb Uwe Stöhr: Jürgen Spitzmüller schrieb: Also, user friendliness is in the eye of the beholder. A LaTeX package manager is really nothing I miss on Linux. Me neither. OK, but I think Harmut is an experienced LyXer on Linux and should therefore be able to install LaTeX-packages. Do you know why he had problems? I don't. For example, his tex installation could be severly screwed up (IIRC he mentioned something like this, but maybe on another occasion). Or he as an experienced LyX user, but never needed to install latex packages so far. Or he did not do it for a long time and forgot how it worked. Or he knew how it worked, but simply did not have the time. In all these cases a package manager would not help. Georg
Re: Embedded Objects
Do you know why he had problems? Yes, he didn't know that the packages are on CTAN and that the .sty-files are generated by LaTeX out of the .ins/dtx files Or he as an experienced LyX user, but never needed to install latex packages so far. Or he did not do it for a long time and forgot how it worked. In all these cases a package manager would not help. No, exactly in these cases a package manager would help: Open the manager, search for e.g. prettyref, double click on it and it will be downloaded and installed. So you don't need to know the LaTeX internals or the package repositories but are able to install packages. Maybe you misunderstood me, I don't mean a package manager for LyX but one that should be shipped by LaTeX-distributions. regards Uwe
LyX 1.4.3
Dear Sirs, I’m a first time user, finishing my PhD and looking at alternatives to replace Word. I ran the installer LyX-143-5 and managed to install LyX after a few problems which I think related with a faulty MikTeX 2.5 installation. But I’m still struggling to have it running smoothly. The problem is one that has been reported but for which I didn’t find a fix or workaround. The document uses a missing TeX class cv (and many others) LyX will not be able to produce output In my case the problem occurred when I tried to open the sample files that come with LyX. What shall I do to fix it? And what needs to be done to install new classes or styles? I would appreciate your help. Best regards, Jaime Remedios
Re: tooltips are back
On Tue, Feb 06, 2007 at 08:21:44PM +0100, Peter Kümmel wrote: The tooltips are back. Does anybody know why? Because Georg fixed it http://www.lyx.org/trac/changeset/16981 -- Enrico
Re: [Bug 2418] LyX cannot correctly determine PDF image size
On Mon, Feb 05, 2007 at 05:57:31PM +0100, Enrico Forestieri wrote: I also tested the attached patch with a native Windows python. I applied the patch to trunk. JMarc, do you want it for 1.4.4, too? -- Enrico
let new caption inset be a collapsable one
I'm now workig with the new caption inset while writing a paper with many floats. In my opinion it would be a bit better usable when it can be collapsed. Do others agree? If yes and if it's not too much work, it would be an impovement if this is implemented for LyX 1.5. regards Uwe
add missing changed signals to graphics float dialog
FYI I added two missing change signals: http://www.lyx.org/trac/changeset/17079 The patch is obvious so I commited it directly. regards Uwe
Re: Fixed: toolbar management problem - another problem
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes: Peter> What about the rule to use on Windows the latest and greatest Peter> Qt release and on Linux "only" an old one? It depends. If there is a _windows_ _only_ thing that cannot be done with qt 4.1 it is OK. If it just that you'd love to play with the new QRoundedGlowingWindow because it is there, the answer is probably "no". We do not want to have two code bases just because we can. I do not think that the fact that LyX 1.4 can compile with qt 3.0 really hampered its development. JMarc
Re: Fixed: toolbar management problem - another problem
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes: >> You expressed it very well, Georg. And I'll just reiterate that >> this is how linux works. So please be nice guys for poor old linux >> users. Peter> Are #ifdefs ok then? Let me give you an example that is OK: currently there is some ugly code of mine to handle menus on Qt/Mac. Now in Qt 4.2 trolltech has finally done what they should have done for the first mac release and introduced the MenuRole concept. Since Qt is bundled with LyX/Mac, I think it may make sense to use this feature for the Mac and decide that LyX/Mac requires Qt 3.2. This will allow to remove ugly code that is difficult to make correctly work. However, if I manage to make the current code to work as I wish, I will probably say "yes, it is the way to go, but we can do it later." Personally, I use Qt 4.1.something and have no intention to upgrade. I think it is good that developers do not use latest and greatest without a good reason, since that removes a silly temptation. JMarc
Re: Fixed: toolbar management problem - another problem
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes: Peter> Seems some peolple currently suffer a depression, but don't Peter> forget: LyX is NOT the meaning of life ;-) I can live very well without LyX, thank you. The LyX developers' community has been a very nice place to stick around for a long time, and I hope it will remain so. JMarc
Re: the new sidebar
John Levon wrote: > Whilst I appreciate the reasoning behind the new sidebar, it has an > unfortunate side-effect: the scroll bar is now much harder to hit. > Especially in full-screen mode, the scroll bar was of infinite width > previously. If you're talking about the view/upgrade toolbar: I think Uwe just put it on the right because of a toolbar/session bug that is now fixed. I think that toolbar can go now where Uwe initiallly intended it to be. Uwe? Jürgen
Re: Fixed: toolbar management problem - another problem
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes: Peter> I assume because much has changed in the last year, more than Peter> the years before, so some LyX-"Veterans" are a bit astonished. You know, we did not wait for young blood to go coding wildly and implement multi-windows and window splitting and many other fun things. This was at LyX 1.1 (the first incarnation) time. And then we saw that we coded so many nice things that the program was severely broken and we scraped everything to go back to 1.0.4 code base. And then we decided it might be a good idea to have some idea of were we are going and to enforce plans for releases and mundane things like that. That said, I am not very interested in this "veterans" vs. "young blood" pissing contests. This is not what we need now JMarc, who swears he's been forced to play the grumpy oldtimer and who'd prefer to release 1.4.4 instead.
[Patch] fix caption inset selection bug
It is this simple (I think).
(The inset API has its nice sides)
- Martin
Index: insetcaption.C
===
--- insetcaption.C (revision 17041)
+++ insetcaption.C (working copy)
@@ -167,6 +167,12 @@
}
+void InsetCaption::drawSelection(PainterInfo & pi, int x, int y) const
+{
+ InsetText::drawSelection(pi, x + labelwidth_ , y);
+}
+
+
void InsetCaption::edit(LCursor & cur, bool left)
{
cur.push(*this);
Index: insetcaption.h
===
--- insetcaption.h (revision 17041)
+++ insetcaption.h (working copy)
@@ -48,6 +48,8 @@
///
virtual void draw(PainterInfo & pi, int x, int y) const;
///
+ void drawSelection(PainterInfo & pi, int x, int y) const;
+ ///
virtual void edit(LCursor & cur, bool left);
///
virtual InsetBase * editXY(LCursor & cur, int x, int y);
pgpAlniywt4KX.pgp
Description: PGP signature
Re: [Cvslog] r17059 - /lyx-devel/trunk/src/insets/insetfloat.h
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> Jean-Marc, should this go into branch too? - Martin Well, it does not fit with the definition of Wide() in 1.4.x. Conerning the need for the fix, I think it just hides the bug in a particular case. The real fix would be to manage to get rid of this wide() thing :) It is possible to set paragraphs centered in almost all text insets, so blocking it in floats seems a bit vain. The bug remains for branches for example, and I do not think it would be a good idea to disable wide() in branches just for that. What is the correct behavior we would like to obtain for centered paragraphs in a wide inset, BTW? Would it be really difficult to change metrics computation so that a centered paragraph always tries to occupy the whole screen width (like with a hfill)? I think this would solve the problem in a better way. JMarc
Re: the new sidebar
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> Whilst I appreciate the reasoning behind the new sidebar, it has John> an unfortunate side-effect: the scroll bar is now much harder to John> hit. Especially in full-screen mode, the scroll bar was of John> infinite width previously. John> I'd much, much, prefer it to be on the left. Agreed. I cannot think right now of other programs that set the icons to the right. JMarc
Re: Fixed: toolbar management problem - another problem
Martin Vermeer wrote: On Mon, Feb 05, 2007 at 08:59:19PM +0100, Peter Kümmel wrote: José Matos wrote: On Monday 05 February 2007 7:34:43 pm Peter Kümmel wrote: I assume because much has changed in the last year, more than the years before, so some LyX-"Veterans" are a bit astonished. Come on Peter, Jean-Marc certainly knows better. :-) Is it really so unrealistic? When he doesn't like most of the changes? It's not so much the changes as the civility of the process. We need a rough consensus before acting, and the closer to final release, the more we need to agree before doing anything. I really think that that's generally the case. Please gives example if otherwise. We agreed with Georg and Jose that the caption inset was to be in before the beta for example. As far as my metrics related activities, except for you and Denmark cowboys, nobody knows or is willing to know this field. As neither you or the Denmark cowboys are very active currently, I just commit without warning. Same with Michael and CT stuff for example Most of my changes are right anyway ;-) There have been some poorly considered changes perhaps, but that's OK -- it's a learning process. Right, and there's nothing dramatic in reverting something from SVN. This is not like we committed sacrilege on the sacro-saint LyX repository ;-) That being said, the LyX process has been much more structured and conversational than what I see in other projects. LyX is software with a philosophy. I like that. Exactly my feeling. I suppose so does Jean-Marc, and he doesn't want to see it erode. Sure, we all agree with that. Abdel.
Re: Fixed: toolbar management problem - another problem
Jean-Marc Lasgouttes wrote: "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes: Peter> I assume because much has changed in the last year, more than Peter> the years before, so some LyX-"Veterans" are a bit astonished. You know, we did not wait for young blood to go coding wildly and implement multi-windows and window splitting and many other fun things. This was at LyX 1.1 (the first incarnation) time. And then we saw that we coded so many nice things that the program was severely broken Is it broken now? and we scraped everything to go back to 1.0.4 code base. Maybe because it was too unstable and those feature were not implemented properly? And then we decided it might be a good idea to have some idea of were we are going and to enforce plans for releases and mundane things like that. Man, I achieved the multi-windows thing by first cleaning up thoroughly the core. I made sure that the separation between between the frontend and the core was clean before implementing any feature. The multi-window feature is just sugar, it came mostly for free after my hard-work. So, I repeat my question, what is the problem? Sorry but I really don't understand why you complain. If anything, I would expect acknowledgement of my hard work instead of complaint. It's my turn to feel depressed now :-( Abdel.
