Re: [Patch] Allow insertion of spaces using the minibuffer
Andre Poenitz wrote: Pretty trivial patch attached. Ok? can you add a comment?
Re: [Patch] Allow insertion of spaces using the minibuffer
On Fri, Jun 22, 2007 at 08:00:04AM +0200, Edwin Leuven wrote: Andre Poenitz wrote: Pretty trivial patch attached. Ok? can you add a comment? The feature (inserting a space via lfun) was asked for twice during the last few weeks. Now that is possible using M-x unicode-insert 0x20. Andre'
Re: Is there an easy way to tell if an inset is modified?
Alfredo Braunstein wrote: Bo Peng wrote: I don't know Bo, I think that latex_code() is a reasonably efficient way of having a signature of the math inset (to check if it has changed). I would be surprised if this had a real performance impact (typically O(1) operations per user interaction, we do much worse elsewhere in the code) OK. Do you have any doubt in replacing notifyCursorLeaves with the standalone version? If not, I will submit Alfredo's patch. It looks safe enough to me. It seems safe also to me. But there's no real hurry, we can wait for another OK. I can commit tomorrow (I have now svn access). OK for me too :-) Good job! Abdel.
Re: [PATCH] Paragraph Setting UI Bugs
Edwin Leuven wrote: Richard Heck wrote: This patch addresses the usability bugs discussed in this thread: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg121160.html and largely implements Helge's suggestions. (Helge often seems to have good ideas on these things.) The main change is that the Default button is now a radio button like the rest, so you don't have to uncheck Default to be allowed to check something else. much better indeed The layout that happens to be the default isn't treated specially except insofar as it is italicized, so as to indicate which one it is. i don't like this fiddling with fonts to suggest to the user what is going on. why not be explicit? o Default (Justified) o Justified o Left o Center o Right I agree with Edwin personally. I would also agree with o Justified (Default) o Left o Center o Right But we can change that later if we reach consensus. Abdel.
Re: problems to show figures in LyX
On Wed, Jun 20, 2007 at 10:00:54PM +0200, Enrico Forestieri wrote: On Wed, Jun 20, 2007 at 09:44:12AM +0100, José Matos wrote: On Wednesday 20 June 2007 00:00:06 Enrico Forestieri wrote: The attached patch fixes it. José, OK to commit? The patch seems right. If you someone to test this and guarantee that it works (no need to be a developer) it can go in. Here is an updated patch that also cures the following startup error on *nix/cygwin: Error returned from iconv EILSEQ An invalid multibyte sequence has been encountered in the input. When converting from UTF-8 to UCS-4LE. Input: 0x2f 0x74 0x6d 0x70 0x2f 0x6f 0x6c 0xe0 0x2f 0x6c 0x79 0x78 0x5f 0x74 0x6d 0x70 0x64 0x69 0x72 0x32 0x30 0x30 0x30 0x63 0x77 0x73 0x63 0x54 0x6c 0x2f 0x6c 0x79 0x78 0x73 0x6f 0x63 0x6b 0x65 0x74 and this one on windows: Error returned from iconv EINVAL An incomplete multibyte sequence has been encountered in the input. When converting from UTF-8 to UCS-4LE. Input: 0x43 0x3a 0x2f 0x63 0x79 0x67 0x77 0x69 0x6e 0x2f 0x74 0x6d 0x70 0x2f 0x6f 0x6c 0xe0 when the temp dir has nonascii chars. These errors are triggered by the fact that setEnv() and addName() take utf8 strings as input and they are instead passed local 8bit encoded strings. I doubt that anyone will test it (see here: http://article.gmane.org/gmane.editors.lyx.general/39630) so, José, take your responsibility and make a decision ;-) I tested the patch and guarantee that it is correct ;-) This is now bug 3904. http://bugzilla.lyx.org/show_bug.cgi?id=3904 -- Enrico
Re: [patch] fix bug 1942
Am 22.06.2007 um 00:42 schrieb Uwe Stöhr: Attached is a patch from Georg that fixes the regression bug 1942: Inconsistent look of integral symbols. I tested it thoroughly will all combinations of the packages esint, wasysym, and amsmath. A Mac user has reported a perhaps related problem that I and Georg couldn't reproduce as consequence of bug 1942. So before this can go in, I need an OK from a Mac user that this patch does only fix the bug and not introduces the problem reported in http://bugzilla.lyx.org/show_bug.cgi?id=3902 Stefan, JMarc, could you please test this the following way: Before you apply the patch: Check if bug 3902 is not already there. With the double integral the math preview does not appear. What should I do now? Stefan PGP.sig Description: Signierter Teil der Nachricht
RE: [Patch] Allow insertion of spaces using the minibuffer
Andre Poenitz wrote: On Fri, Jun 22, 2007 at 08:00:04AM +0200, Edwin Leuven wrote: Andre Poenitz wrote: Pretty trivial patch attached. Ok? can you add a comment? The feature (inserting a space via lfun) was asked for twice during the last few weeks. Now that is possible using M-x unicode-insert 0x20. i guess i forgot to mention it was friday insert appropriate smiley
RE: Re: No paragraph alignment options
Alfredo Braunstein wrote: Specially with new document classes I normally don't know what the layouts really are so I switch back and forth several times... i agree that the only situation where this might reasonably occur is when switching document classes. so given that: - people don't switch document classes often (i for example never do) - switching document layouts often involve information loss because they do not define similar environments - case 1 2 are rare i really don't see the point of cluttering the user interface for these very small contingencies. i also think that o Justified (Default) o Left o Center o Right will be more understandable to users who don't know latex while at the same time it makes default explicit which is think was the starting point imo of course...
RE: Re: No paragraph alignment options
Leuven, E. wrote: - case 1 2 are rare No, they're not. Jürgen
RE: RE: Re: No paragraph alignment options
- case 1 2 are rare No, they're not. where do you get your stats from?
Re: [PATCH] Paragraph Setting UI Bugs
Abdelrazak Younes wrote: I agree with Edwin personally. I would also agree with o Justified (Default) o Left o Center o Right But we can change that later if we reach consensus. I think default should be an additional option. There may be good reasons to set the alignment to the setting that is also the default. Joost
RE: RE: Re: No paragraph alignment options
Leuven, E. wrote: No, they're not. where do you get your stats from? Where do you get your stats from? I just think it's wrong to assume that justified is the de facto standard alignment. This might be true for standard paragraphs in most book and article classes, for others it is not. I often redefine the alignment of several paragraph styles in the preamble (or of certain classes) due to the guidelines of the publishers. The approach you are proposing results in dataloss/wrong output, and this is a no-opt IMHO. Jürgen
Re: character pairs such as parenthesis in Farsi (a patch)
Mostafa Vahedi wrote: Currently (only) Unicode is used for Farsi as the input encoding. Moreover in Unicode the openning parenthesis is always the left one (independent of the language) I have modified the code to reverse the direction of the character-pairs when it wants to display the characters whenever the language is Arabic or Farsi. Maybe the direction should be changed only when the language is Farsi (not Arabic), but only one parameter, i.e. bool Arabic, is sent to the function). Mostafa Hi Mostafa! This patch looks good, but I'm not sure that it should be applied for Arabic. Currently (before applying your patch, but with what you previously put in already in place) I'm getting backwards parentheses in Arabic. As I see it, there are two ways to go about solving this: 1) If the parentheses really do need to be reversed when using Unicode input (I'm not set up for Unicode input, I don't think, so I can't test this), then the patch *should* be applied also for arabic. Then, however, when using the keymap, parentheses are backwards --- but we can just fix that in the keymap itself, by adding \kmap ( ) \kmap ) ( 2) If for Arabic Unicode the patch should not be applied, then it should be applied only for farsi. Either way, it probably wouldn't be a bad idea to add a separate bool variable for farsi --- there's no real reason why farsi and arabic should share the variable... (I haven't tried your patch, because I'm having trouble with the spacing copying it from the email. Could you attach it --- or one modified according to the above suggestions -- as an attachment next time, then I'll test it.) Dov Dear Dov, The problem is independent of the language, rather it depends on the encoding. In other words it does not depend on Arabic or Farsi but it depends on the encoding we would like to save our texts. First we should make it clear for ourselves what the internal encoding of the LyX file (not the LaTeX file) is. If it is Unicode then we should obey the unicode rules. In Unicode we always use the LATIN-left paranthesis as the opening one but during the representation or display we consider the context and display the correct one. Clearly there is some sort of encoding mapping during the generation of the LaTeX file. In my opinion there we should change the direction of the paranthesis in case it is needed. What is the internal encoding of a LyX file? Where is the point at which we can consider reversing the direction of the character pairs when converting a LyX file to a LaTeX file in case it is needed? - Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. rowpainter.diff Description: 990053006-rowpainter.diff
RE: RE: Re: No paragraph alignment options
Alfredo Braunstein wrote: Let me give you another case: I often write my titles first in Standard Layout and *then* switch the layout to Title. With your approach I would have to manually center it. Awful. no. reread what i wrote: i would be fine with having the default take precedence in both cases and have this in the interface: o Justified (default) o Left o Center o Right ... since default takes precedence things go fine in your example. i really don't see the point of cluttering the user interface for these very small contingencies. Clutter is a big word... CLUTTER is even bigger What happends if the user moves the cursor when the dialog is open, does it get updated? it should be (until we get rid of these modeless dialogs) In any case I prefer your other proposal with Default (Justified) and all the rest. i can live with that So I vote that or no change ;-) i should remind you that it is friday
RE: RE: RE: Re: No paragraph alignment options
Juergen Spitzmueller wrote: Where do you get your stats from? from a very reliable source I just think it's wrong to assume that justified is the de facto standard alignment. ? you are misunderstanding me. the inset/layout should tell us what the default is (and i think it does at the moment). so sometimes this will be justified, in other cases center, etc. I often redefine the alignment of several paragraph styles in the preamble (or of certain classes) due to the guidelines of the publishers. The approach you are proposing results in dataloss/wrong output, i don't think so
Re: issues with change tracking
Edwin Leuven wrote: if i creat a selection that spans more than one line and then type something (so that the selection gets replace with my new text), the selection before the line where cursor is isn't crossed out. there is a missing screen update here. Confirmed. second thing is when i delete a collapsed footnote. the collapse footnote gets crossed out in lyx but not the text inside. in the dvi the footnote isn't crossed out. Confirmed. Note that this has nothing to do with the collapsed status, same thing happends with open ones (just that there's no visual feedback about the inset being deleted/new). Seems that text insets are not change-tracked, only their content is. Is this on purpose or a known limitation? A/
RE: Re: No paragraph alignment options
Leuven, E. wrote: so given that: - people don't switch document classes often (i for example never do) - switching document layouts often involve information loss because they do not define similar environments - case 1 2 are rare Let me give you another case: I often write my titles first in Standard Layout and *then* switch the layout to Title. With your approach I would have to manually center it. Awful. i really don't see the point of cluttering the user interface for these very small contingencies. Clutter is a big word... i also think that o Justified (Default) o Left o Center o Right will be more understandable to users who don't know latex while at the same time it makes default explicit which is think was the starting point Is not about latex imo, is about document layouts. imo of course... What happends if the user moves the cursor when the dialog is open, does it get updated? In any case I prefer your other proposal with Default (Justified) and all the rest. So I vote that or no change ;-) A/
Re: [patch] bug 2520: Make InsetExternal translateable
Jürgen Spitzmüller wrote: http://bugzilla.lyx.org/show_bug.cgi?id=2520 The attached patch does this (I think it's the last remaining non-translatable ui part). Any opinions on this? Jürgen
RE: RE: Re: No paragraph alignment options
Leuven, E. wrote: Alfredo Braunstein wrote: Let me give you another case: I often write my titles first in Standard Layout and *then* switch the layout to Title. With your approach I would have to manually center it. Awful. no. reread what i wrote: That implies I've read it in the first place... since default takes precedence things go fine in your example. I see. WRT the current situation, your approach tends to make things default (on layout switching) against user will, which is sort of lyx philosophy: don't care what you want, no manual formatting allowed here! ... At the end, maybe it's not so terrible. Question: what do you do if the selection consists in paragraphs with different layouts (with different defaults) In any case I prefer your other proposal with Default (Justified) and all the rest. i can live with that So I vote that or no change ;-) Still prefer this I think. i should remind you that it is friday I've written that smile yesterday. I keep one or two around for precaution. A/
Re: [patch] fix bug 1942
Stefan Schimanski schrieb: Before you apply the patch: Check if bug 3902 is not already there. With the double integral the math preview does not appear. What should I do now? When this is the case without the patch is applied, - confirm the bug report 3902 - aplly the patch for bug 1942 and check that the situation has not changed. thanks and regards Uwe
Re: Arabic with Arabi / ArabTeX (take 2)
Dov Feldstern wrote: Hi! First of all, I just want to apologize to you, Uwe: I feel that we were getting very argumentative last night, and I'm not sure why... I'll blame it on the hour and on the fact that I was getting very frustrated with the fact that not all my messages were making it through for some reason. Anyhow, I just want to apologize, and start from scratch, this time with a more cooperative attitude. :) This whole paragraph is entirely inappropriate today. You'll lose your commit right if you continue on this path. A/
Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable
Dear Dov and Uwe, ARABI is a good package for Farsi that supports BABEL. But it has some (even many) limitations. About Arabic I believe that I am not the person who should decides at this moment. I need more time for that one. I would like to keep the possibility of using ArabTeX (NOT necessarily SUPPORTING) with LyX. Although ArabTeX is not based on BABEL but I think it can be used beside the BABEL. What I suggest is not to hurry for using ARABI for Arabic. Please give me some time so that I can figure out what is the best way to deal with ArabTeX and ARABI. It is just a matter of time. Please keep the current status of Arabic as it is. Maybe it is not possible (currently) to do all things automatically in writing Arabic and Farsi but at least we can make it easier for the users. Isn't it? Thanks for all your help and support, Mostafa - Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos more.
Arabic with Arabi / ArabTeX (take 2)
Hi! First of all, I just want to apologize to you, Uwe: I feel that we were getting very argumentative last night, and I'm not sure why... I'll blame it on the hour and on the fact that I was getting very frustrated with the fact that not all my messages were making it through for some reason. Anyhow, I just want to apologize, and start from scratch, this time with a more cooperative attitude. :) Just to sum up: my main concern is not to break ArabTeX support. Regardless of the details of how exactly it's done, the fact is that until very recently, the *only* way to use Arabic in LyX was through ArabTeX, and it actually works quite well, requiring only a one-time manual setup, not different from what's required for Hebrew, for example. And I can think of many reasons why a user currently working with ArabTeX would want to continue with it, rather than switching over to Arabi (prettier output; legacy documents; no need for any new setup --- e.g., I had to update my entire latex package in order to move to Arabi; and it still doesn't work correctly, there are bugs with it on Linux --- which have been reported, but not yet fixed; and my understanding from Mostafa is that there are other issues as well). ArabTeX is not perfect, though, by any means, so it's good that Arabi --- which is babel-based --- is also starting to be used. In the long term, I think that Arabi is the way to go, and will allow things which are not possible with ArabTeX (e.g., mixing multiple languages; AFAIK, ArabTeX only allows Arabic + the primary language to be mixed, although this works very well in ArabTeX). Therefore, I think it's important to be able to support both ArabTeX and Arabi. To that end, I separated Arabic into two languages --- see the patch attached to bug 2928. It is not a complete patch, only a foundation upon which we can correct both ArabTeX and Arabi support, without them interfering with each other. I will try to send in a more complete patch, hopefully later today; or, Uwe's patch can be easily modified to fit in on top of mine. Dov
RE: RE: RE: Re: No paragraph alignment options
Leuven, E. wrote: you are misunderstanding me. the inset/layout should tell us what the default is (and i think it does at the moment). so sometimes this will be justified, in other cases center, etc. I obviously did. Sorry. I'm still not entirely convinced. Jürgen
Re: [patch] bug 2520: Make InsetExternal translateable
On Friday 22 June 2007 09:48:02 Juergen Spitzmueller wrote: Jürgen Spitzmüller wrote: http://bugzilla.lyx.org/show_bug.cgi?id=2520 The attached patch does this (I think it's the last remaining non-translatable ui part). Any opinions on this? I like it, I was expecting for other opinions. Jürgen -- José Abílio
Re: Arabic with Arabi / ArabTeX (take 2)
Dov Feldstern schrieb:
First of all, I just want to apologize to you, Uwe: I feel that we were
getting very argumentative last night, and I'm not sure why...
No problem. I think such discussions are needed to get a decision.
So what about the following:
- I commit the Farsi related stuff that doesn't touch Arabic and keeps the
possibility to use arabTeX.
- We buld in your solution with the two different Arabic languages:
arabic_arabTeX and arabic_arabi
This solution requires much work, so I propose that I take care of the arabi part as I have this
already ready and you take care of the arabTex part. I think when we work hard, it should be
possible to get it ready before LyX 1.5.0 comes out. (For rc2 it is too late but doesn't matter.)
---
For the arabTeX support:
- I think the fontenc stuff should be added - is easy, can do this when you tell me what encoding is
needed.
- The manual set up of the input encoding stuff can be dropped, because we can take it from the
arabi-package (as you already tested).
- Do you have a better solution for the \begin{arabtex} environments. I think that we should change
the \selectlanguage{arabic} command to \begin{arabtex} when the user uses arabic_arabtex as document
language. Right? Could you try to implement this?
regards Uwe
p.s. why to you send your messages to the lyx-devel list via the newsgroup and not as cc? Perhaps
this is the reason for the problems with your messages yesterday. You must btw. not be subscribed to
the lyx-devel list to send emails to it.
Re: [Patch] Allow insertion of spaces using the minibuffer
On Friday 22 June 2007 06:55:01 Andre Poenitz wrote: Pretty trivial patch attached. Ok? Andre' OK. -- José Abílio
Re: Arabic with Arabi / ArabTeX (take 2)
Uwe Stöhr wrote:
Dov Feldstern schrieb:
First of all, I just want to apologize to you, Uwe: I feel that we
were getting very argumentative last night, and I'm not sure why...
No problem. I think such discussions are needed to get a decision.
So what about the following:
- I commit the Farsi related stuff that doesn't touch Arabic and keeps
the possibility to use arabTeX.
- We buld in your solution with the two different Arabic languages:
arabic_arabTeX and arabic_arabi
This solution requires much work, so I propose that I take care of the
arabi part as I have this already ready and you take care of the arabTex
part. I think when we work hard, it should be possible to get it ready
before LyX 1.5.0 comes out. (For rc2 it is too late but doesn't matter.)
Sounds good to me. I'll try to get my part done soon.
---
For the arabTeX support:
- I think the fontenc stuff should be added - is easy, can do this when
you tell me what encoding is needed.
I just don't know which is the correct encoding. I do know that for
ArabTeX, the encoding setting for the document, within LyX, should be
set to LaTeX default, but I'm not sure what that means in terms of the
generated LaTeX. It seems to be working as it is, so maybe we should
just leave it until someone who really knows ArabTeX comes along, or
until problems are reported.
- The manual set up of the input encoding stuff can be dropped, because
we can take it from the arabi-package (as you already tested).
What are you referring to? I'm not sure I follow...
- Do you have a better solution for the \begin{arabtex} environments. I
think that we should change the \selectlanguage{arabic} command to
\begin{arabtex} when the user uses arabic_arabtex as document language.
Right? Could you try to implement this?
I think this sounds right. I'll take a look at this. I don't know,
though, whether or not this should be hard-coded. Perhaps it would be
better to add another column to lib/languages? Note, also, that
currently there is a whole preferences infrastructure built around these
options, so we might as well use that. So it requires a little one-time
setup, but most people using ArabTeX are probably already set up for
that anyway. So maybe we're better of just leaving it as it is...
regards Uwe
p.s. why to you send your messages to the lyx-devel list via the
newsgroup and not as cc? Perhaps this is the reason for the problems
with your messages yesterday. You must btw. not be subscribed to the
lyx-devel list to send emails to it.
It usually works either way for me; but last night it didn't seem to be
working right, regardless of whether I sent to the newsgroup or to the
mailing list. Today there still seems to be a very long delay...
Re: Arabic with Arabi / ArabTeX (take 2)
Alfredo Braunstein wrote: Dov Feldstern wrote: Hi! First of all, I just want to apologize to you, Uwe: I feel that we were getting very argumentative last night, and I'm not sure why... I'll blame it on the hour and on the fact that I was getting very frustrated with the fact that not all my messages were making it through for some reason. Anyhow, I just want to apologize, and start from scratch, this time with a more cooperative attitude. :) This whole paragraph is entirely inappropriate today. You'll lose your commit right if you continue on this path. A/ Who do you think you are to tell me that --- so I forgot is was Friday, so?! ;)
Re: Arabic with Arabi / ArabTeX (take 2)
If we are going to support both ARABI and ArabTeX for Arabic then we should also see how we can combine them in LaTeX terms. I will do that and I will let you know the result. Therefore as I prepared an skeleton (how-to) for writing Farsi based on ARABI, I will prepare one for Arabic based on ArabTeX and also ARABI together. Mostafa - Shape Yahoo! in your own image. Join our Network Research Panel today!
Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable
Attached is a better patch where
everything is implemented:
- correct encoding for the fontenc
package. Mostafa tested this and
gave his OK for this issue.
This is exteremly OK.
- special quotation mark definitions
for Farsi. Mostafa tested this and
gave his OK for this issue.
This is OK. It should be removed later
as you have mentioned it.
BUT BUT BUT BUT
In fact there are three commands not
two commands. The command
[EMAIL PROTECTED]@R{#1}}
will make problems when we want the Arabic
based on ARABI as the main language.
Therefore remove this one from the
file languages and keep the other two.
We should use this command only if the
main language is not Arabic_ARABI.
- fix for bug 2929 - use \textAR
and not \R. Improved version of Dov's
patch. Mostafa also tested this
successfully.
No. I have not yet. In fact this is
not basically a bug.
- use the document language also for
the TOC. This is a special arabi-package
thing. Please test.
It needs more investigation. We should
find the correct point in the source
at which we could place the command
\TOCLanguage{farsi}.
- To make the TOC settings work and also
for other issues, arabic must be loaded
to babel too when farsi is the document
language. Please test.
This fix should be temporarily too and so
it should be removed later if the bug
is fixed later. I will test it.
Mostafa, when you give your OK I'll commit
it. When there are possible problems with
the two new things, I'll only commit the
uncritical and tested issues from above.
(With this patch now also your
example_lyxified.lyx you sent two days
ago to be added to LyX's examples compiles
for me.)
OK. I will prepare a clean patch for
all these topics except the issues that
are related to Arabic, because Dov
and Uwe are working on this topic too.
Mostafa
-
Get the free Yahoo! toolbar and rest assured with the added security of spyware
protection.
Re: farsi keyboard farsi.kmap
I have attached the Farsi keyboard based on Linux Farsi keymap which can be added to directory LYX_DEVEL/lib/kbd/. The only problem I have is the last line in which I tried to assign a letter to the double quote, i.e. \, and it did not work. couldn't be mapped because it's reserved for quotation So when you remove the last line or replace it by another, this can go in. regards Uwe Ok. Here you are! - Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. farsi.kmap Description: 1413757767-farsi.kmap
RE: RE: RE: RE: Re: No paragraph alignment options
I obviously did. Sorry. I'm still not entirely convinced.
i was thinking like the attached...
Index: src/frontends/qt4/QParagraph.cpp
===
--- src/frontends/qt4/QParagraph.cpp (revision 18850)
+++ src/frontends/qt4/QParagraph.cpp (working copy)
@@ -50,7 +50,6 @@
connect(applyPB, SIGNAL(clicked()), form_, SLOT(slotApply()));
connect(closePB, SIGNAL(clicked()), form_, SLOT(slotClose()));
connect(restorePB, SIGNAL(clicked()), form_, SLOT(slotRestore()));
- connect(alignDefaultCB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
connect(alignJustRB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
connect(alignLeftRB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
connect(alignRightRB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
@@ -77,9 +76,9 @@
items is used.
));
- radioMap[LYX_ALIGN_BLOCK] = alignJustRB;
- radioMap[LYX_ALIGN_LEFT] = alignLeftRB;
- radioMap[LYX_ALIGN_RIGHT] = alignRightRB;
+ radioMap[LYX_ALIGN_BLOCK] = alignJustRB;
+ radioMap[LYX_ALIGN_LEFT] = alignLeftRB;
+ radioMap[LYX_ALIGN_RIGHT] = alignRightRB;
radioMap[LYX_ALIGN_CENTER] = alignCenterRB;
}
@@ -105,35 +104,44 @@
void QParagraphDialog::checkAlignmentRadioButtons() {
- if (alignDefaultCB-isChecked()) {
- QPRadioMap::const_iterator it = radioMap.begin();
- for (; it != radioMap.end(); ++it)
- it-second-setDisabled(true);
- } else {
- LyXAlignment alignPossible = form_-controller().alignPossible();
- QPRadioMap::const_iterator it = radioMap.begin();
- for (; it != radioMap.end(); ++it)
- it-second-setEnabled(it-first alignPossible);
+ LyXAlignment const alignPossible = form_-controller().alignPossible();
+ LyXAlignment const defaultAlignment = form_-controller().alignDefault();
+ QPRadioMap::iterator it = radioMap.begin();
+ for (; it != radioMap.end(); ++it) {
+ it-second-setEnabled((it-first alignPossible) ||
+ (it-first == LYX_ALIGN_LAYOUT));
+ string label;
+ switch (it-first) {
+ case LYX_ALIGN_BLOCK:
+label = Justified;
+break;
+ case LYX_ALIGN_LEFT:
+label = Left;
+break;
+ case LYX_ALIGN_CENTER:
+label = Center;
+break;
+ case LYX_ALIGN_RIGHT:
+label = Right;
+break;
+ }
+
+ if (it-first == defaultAlignment)
+ label += (Default);
+
+ it-second-setText(qt_(label));
}
}
-void QParagraphDialog::on_alignDefaultCB_toggled(bool)
-{
- checkAlignmentRadioButtons();
- alignmentToRadioButtons();
-}
-
-
void QParagraphDialog::alignmentToRadioButtons(LyXAlignment align)
{
- if (align == LYX_ALIGN_LAYOUT)
- align = form_-controller().alignDefault();
-
QPRadioMap::const_iterator it = radioMap.begin();
for (;it != radioMap.end(); ++it) {
if (align == it-first) {
+ it-second-blockSignals(true);
it-second-setChecked(true);
+ it-second-blockSignals(false);
return;
}
}
@@ -145,18 +153,18 @@
LyXAlignment QParagraphDialog::getAlignmentFromDialog()
{
- if (alignDefaultCB-isChecked())
- return LYX_ALIGN_LAYOUT;
+ LyXAlignment const defaultAlignment = form_-controller().alignDefault();
LyXAlignment alignment = LYX_ALIGN_NONE;
QPRadioMap::const_iterator it = radioMap.begin();
for (; it != radioMap.end(); ++it) {
if (it-second-isChecked()) {
- alignment = it-first;
+ if (it-first == defaultAlignment)
+alignment = LYX_ALIGN_LAYOUT;
+ else
+alignment = it-first;
break;
}
}
- if (alignment == form_-controller().alignDefault())
- return LYX_ALIGN_LAYOUT;
return alignment;
}
@@ -243,15 +251,8 @@
}
// alignment
- LyXAlignment newAlignment = params.align();
- LyXAlignment defaultAlignment = controller().alignDefault();
- bool alignmentIsDefault =
- newAlignment == LYX_ALIGN_LAYOUT || newAlignment == defaultAlignment;
- dialog_-alignDefaultCB-blockSignals(true);
- dialog_-alignDefaultCB-setChecked(alignmentIsDefault);
- dialog_-alignDefaultCB-blockSignals(false);
dialog_-checkAlignmentRadioButtons();
- dialog_-alignmentToRadioButtons(newAlignment);
+ dialog_-alignmentToRadioButtons(params.align());
//indentation
bool const canindent = controller().canIndent();
Index: src/frontends/qt4/QParagraph.h
===
--- src/frontends/qt4/QParagraph.h (revision 18850)
+++ src/frontends/qt4/QParagraph.h (working copy)
@@ -49,8 +49,6 @@
void change_adaptor();
///
void enableLinespacingValue(int);
- ///
- void on_alignDefaultCB_toggled(bool);
};
Index: src/frontends/qt4/ui/ParagraphUi.ui
===
--- src/frontends/qt4/ui/ParagraphUi.ui (revision 18850)
+++ src/frontends/qt4/ui/ParagraphUi.ui (working copy)
@@ -8,8 +8,8 @@
rect
x0/x
y0/y
-width373/width
-height203/height
+width346/width
+height226/height
/rect
/property
property name=sizePolicy
@@ -36,76 +36,14 @@
property name=spacing
number6/number
/property
-
Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable
Mostafa Vahedi schrieb:
- use the document language also for
the TOC. This is a special arabi-package
thing. Please test.
It needs more investigation. We should
find the correct point in the source
at which we could place the command
\TOCLanguage{farsi}.
I think I have found it out: It must be called after babel. And futhermore to be able to use this,
also arabic has to be loaded for babel when \TOClanguage{farsi} is used.
Both is implemented in the patch.
OK. I will prepare a clean patch for
all these topics except the issues that
are related to Arabic
When you have tested the TOClanguage and the additional arabic call, I could also provide a clean
patch out of mine that don't touches Arabic.
thanks and regards
Uwe
Re: Arabic with Arabi / ArabTeX (take 2)
Mostafa Vahedi wrote: If we are going to support both ARABI and ArabTeX for Arabic then we should also see how we can combine them in LaTeX terms. I will do that and I will let you know the result. Therefore as I prepared an skeleton (how-to) for writing Farsi based on ARABI, I will prepare one for Arabic based on ArabTeX and also ARABI together. Mostafa Mostafa, I don't know if that's necessary. I mean, if you can get it working that would be great, but I don't think you should spend too much time on it: the main reason I think we should keep in arabtex support is for backwards compatibility, I'm not sure there's any reason to mix Arabi and ArabTeX (unless you want to mix ArabTeX Arabic with Arabi Farsi?).
Re: No paragraph alignment options
Alfredo Braunstein wrote: What happends if the user moves the cursor when the dialog is open, does it get updated? The dialog is presently modal, precisely because there's no reliable trigger right now to do the update. Making this work involves re-working the controller fairly extensively, or at least that was the conclusion Abdel and I reached when I was redoing this dialog a while ago. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [patch] bug 2520: Make InsetExternal translateable
José Matos wrote: Any opinions on this? I like it, I was expecting for other opinions. Som nanyone? Can I commit? Jürgen
[patch] fix to bug 3346
http://bugzilla.lyx.org/show_bug.cgi?id=3346
The fix is simply to clear the dirty flag of the tabular clipboard on normal
text copy.
Seeking 2 OKs.
A/
Index: CutAndPaste.cpp
===
--- CutAndPaste.cpp (revision 18850)
+++ CutAndPaste.cpp (working copy)
@@ -628,6 +628,7 @@
copySelectionHelper(cur.buffer(), pars, par, cur.selEnd().pit(),
pos, cur.selEnd().pos(), cur.buffer().params().textclass, cutstack);
+ dirtyTabularStack(false);
}
if (cur.inMathed()) {
[Patch Bug 3727] Environment combobox not updated when clicking bullet on toolbar
The attached onliner fixes the issue for me (and Uwe).
Explanation: if current_layout is updated here, the test in LyXView.cpp:462
returns false and the combo is not updated. Furthermore, current_layout will
be reset in LyXView.cpp (after the combo update).
OK?
Jürgen
Index: src/Text3.cpp
===
--- src/Text3.cpp (Revision 18821)
+++ src/Text3.cpp (Arbeitskopie)
@@ -947,7 +947,6 @@
}
if (change_layout) {
- current_layout = layout;
setLayout(cur, layout);
// inform the GUI that the layout has changed.
bv-layoutChanged(layout);
Re: No paragraph alignment options
Alfredo Braunstein wrote: Leuven, E. wrote: Alfredo Braunstein wrote: since default takes precedence things go fine in your example. I see. WRT the current situation, your approach tends to make things default (on layout switching) against user will, which is sort of lyx philosophy: don't care what you want, no manual formatting allowed here! My own view is more with Alfredo and, I think, Jurgen. Users do switch layouts, and there is a difference between saying, Use the default alignment, whatever that might be and Center this, come what may. If you collapse Default with whatever the default happens to be, it becomes impossible to say that. This was Helge's point a while ago, and Joost has made it, too. At the end, maybe it's not so terrible. Question: what do you do if the selection consists in paragraphs with different layouts (with different defaults) I take it the point of this question is: What counts as default in this case? There's no good answer if we're trying to collapse default with what the default is. Note, however, that it would make perfectly good sense to select a bunch of paragraphs you'd customized and then to choose Default, precisely so as to restore them all to default. You could even select the whole document and do this to undo all paragraph-level alignment customization. Note that this also means the Default (Justified) strategy won't work, since there's no such thing in multi-paragraph selections. It also means that the font-switching strategy I'd implemented doesn't work. Default is just default. A tooltip will help a bit, perhaps. That said, the issue is moot at present, because LyX itself (wrongly, in my view) collapses the default with what the default is. If the default is, in fact, Justified, and you choose Justified, then you get Default. That is, you get LYX_ALIGN_LAYOUT not LYX_ALIGN_BLOCK. This is in Text2.cpp, and fixing it would require more work than we want to do now, I suspect. A change may be needed in the LaTeX output routines (i.e., don't output alignment info if it's the default), and there are some other issues with how alignments are reported, via ParagraphParameters::align(), not to mention some general issues with mixing alignments and certain kinds of environments (bug 3434). A lot of this could be done right after 1.5.0, I think---though perhaps not 3434. It's not huge, just not now. I'll send an updated patch shortly. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [patch] fix to bug 3346
On Friday 22 June 2007 14:54:58 Alfredo Braunstein wrote: http://bugzilla.lyx.org/show_bug.cgi?id=3346 The fix is simply to clear the dirty flag of the tabular clipboard on normal text copy. Seeking 2 OKs. A/ OK. -- José Abílio
Re: [Patch Bug 3727] Environment combobox not updated when clicking bullet on toolbar
On Friday 22 June 2007 16:37:53 Jürgen Spitzmüller wrote: The attached onliner fixes the issue for me (and Uwe). Explanation: if current_layout is updated here, the test in LyXView.cpp:462 returns false and the combo is not updated. Furthermore, current_layout will be reset in LyXView.cpp (after the combo update). OK? Jürgen OK. -- José Abílio
Re: character pairs such as parenthesis in Farsi (a patch)
Mostafa Vahedi wrote: Mostafa Vahedi wrote: Currently (only) Unicode is used for Farsi as the input encoding. Moreover in Unicode the openning parenthesis is always the left one (independent of the language) I have modified the code to reverse the direction of the character-pairs when it wants to display the characters whenever the language is Arabic or Farsi. Maybe the direction should be changed only when the language is Farsi (not Arabic), but only one parameter, i.e. bool Arabic, is sent to the function). Mostafa Hi Mostafa! This patch looks good, but I'm not sure that it should be applied for Arabic. Currently (before applying your patch, but with what you previously put in already in place) I'm getting backwards parentheses in Arabic. As I see it, there are two ways to go about solving this: 1) If the parentheses really do need to be reversed when using Unicode input (I'm not set up for Unicode input, I don't th ink, so I can't test this), then the patch *should* be applied also for arabic. Then, however, when using the keymap, parentheses are backwards --- but we can just fix that in the keymap itself, by adding \kmap ( ) \kmap ) ( 2) If for Arabic Unicode the patch should not be applied, then it should be applied only for farsi. Either way, it probably wouldn't be a bad idea to add a separate bool variable for farsi --- there's no real reason why farsi and arabic should share the variable... (I haven't tried your patch, because I'm having trouble with the spacing copying it from the email. Could you attach it --- or one modified according to the above suggestions -- as an attachment next time, then I'll test it.) Dov Dear Dov, The problem is independent of the language, rather it depends on the encoding. In other words it does not depend on Arabic or Farsi but it depends on the encoding we would like to save our texts. First we should make it clear for ourselves what the internal encoding of the LyX file (not the LaTeX file) is. If it is Unicode then we should obey the unicode rules. In Unicode we always use the LATIN-left paranthesis as the opening one but during the representation or display we consider the context and display the correct one. Clearly there is some sort of encoding mapping during the generation of the LaTeX file. In my opinion there we should change the direction of the paranthesis in case it is needed. What is the internal encoding of a LyX file? Where is the point at which we can consider reversing the direction of the character pairs when converting a LyX file to a LaTeX file in case it is needed? Mostafa, your explanation sounds good. I don't really know enough about this to be helpful (as the whole ArabTeX business shows :( ). If you send in patches, I will test them and let you know if they are OK in terms of the user experience as it seems to me that it should be. Currently, the user experience in Hebrew is good, in Arabic (both ArabTeX and Arabi) it is not (in both cases, using *keymap* input). Your patch I like in terms of the code, but of course it doesn't change the user experience in Arabic. Hebrew remains untouched, which is good. If you are able to solve this for Arabic, then probably it should be applied to Hebrew as well. Again, I'll test patches. Dov
Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable
(Again, resending because it didn't arrive the first time; sorry if you
got it twice)
Uwe Stöhr wrote:
Dov Feldstern schrieb:
The question is, should we really go to all this trouble? (Well, not
so much, but (a) should we separate between ArabTeX and Arabi, and (b)
should we update lyx2lyx to deal with the language change, for
backwards compatibility with something which we don't know whether or
not it exists?) Or maybe you're right --- we should just stick with
Arabi, that will be the only Arabic support that LyX provides.
Sorry about all this mess :( .
What do you say?
Mostafa said he will investigate further and that he needs some time for
it. I propose we postpone this after LyX 1.5.0. When no fileformat
change is needed, this can be also implemented to Lyx 1.5.1. If not we
can so it in LyX 1.6.0.
regards Uwe
I am in favor of applying the attached patch, and then applying Uwe's
changes on top of the arabic_arabi language. The idea being that we
support ArabTeX as much as it is currently supported (but not full
support, by any means); and we're beginning to support Arabi for Arabic,
too, but there's still work to be done. Hopefully, this will be good
enough to draw some real Arabic users in, and they'll be able to help
out with how best to continue. And if not, then there's no point in
putting any more work into it. But the basis will be in.
I don't think that a format change is needed, because we're using new
languages, not changing the interpretation of existing ones. If there
are users out there who have existing documents in ArabTeX, they'll have
to replace all \lang arabic with \lang arabic_arabtex, but that's
all. I think this is reasonable.
BTW, there's one more stage that I left out of the ArabTeX instructions,
which may be why you were having trouble, Uwe. With this, it works,
including chapters, etc. (copied straight from Dekel's instructions):
4. Get the file http://cs.haifa.ac.il/~dekelts/lyx/arab-article.layout
and put it in ~/.lyx/layouts/
Run LyX and select the edit-reconfigure menu, and exit from LyX
5. Now you are ready to start writing Arabic documents:
Start a new document, open the document layout popup (layout-document
menu) Select article(Arabic) as the document class, default as the
encoding, and English as the language (not Arabic!), and press OK.
Use the F12 key to switch between Arabic and English.
Index: src/insets/InsetTabular.cpp
===
--- src/insets/InsetTabular.cpp (revision 18851)
+++ src/insets/InsetTabular.cpp (working copy)
@@ -2286,6 +2286,9 @@
if (par.getParLanguage(buf.params())-lang() ==
farsi)
os \\textFR{;
+ else if (par.getParLanguage(buf.params())-lang() ==
arabic_arabi)
+ os \\textAR{;
+ // currently, remaning RTL languages are arabic_arabtex
and hebrew
else
os \\R{;
}
Index: src/Font.cpp
===
--- src/Font.cpp(revision 18851)
+++ src/Font.cpp(working copy)
@@ -752,10 +752,18 @@
if (language()-lang() == farsi) {
os \\textFR{;
count += 8;
+ } else if (language()-lang() == arabic_arabi) {
+ os \\textAR{;
+ count += 8;
} else if (!isRightToLeft()
+ base.language()-lang() == arabic_arabi) {
+ os \\textLR{;
+ count += 8;
+ } else if (!isRightToLeft()
base.language()-lang() == farsi) {
os \\textLR{;
count += 8;
+ // currently the remaining RTL languages are arabic_arabtex and
hebrew
} else if (isRightToLeft() != prev.isRightToLeft()) {
if (isRightToLeft()) {
os \\R{;
Index: src/Text.cpp
===
--- src/Text.cpp(revision 18851)
+++ src/Text.cpp(working copy)
@@ -369,7 +369,8 @@
if (isPrintable(c)) {
Language const * language = font.language();
if (language-rightToLeft()) {
- if (language-lang() == arabic ||
+ if (language-lang() == arabic_arabtex ||
+ language-lang() == arabic_arabi ||
language-lang() == farsi) {
if (Encodings::isComposeChar_arabic(c))
return 0;
Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp (revision 18851)
+++
Re: [PATCH-updated] Paragraph Setting UI Bugs
José Matos wrote: OK. I think that the subject is important and I liked the discussion there, now let us move to other (critical) bugs. :-) Since I have to decide I opt for Richard's argument without any demerit for Edwin patch/solution. let me guess, you tossed a coin...?
Re: [patch] bug 2520: Make InsetExternal translateable
Jürgen == Jürgen Spitzmüller [EMAIL PROTECTED] writes: Jürgen http://bugzilla.lyx.org/show_bug.cgi?id=2520 Jürgen The attached patch does this (I think it's the last remaining Jürgen non-translatable ui part). I have no idea about the python part, but the rest looks sane. JMarc
Re: [PATCH-updated] Paragraph Setting UI Bugs
On Friday 22 June 2007 17:59:21 Richard Heck wrote: José Matos wrote: On Friday 22 June 2007 17:42:34 Edwin Leuven wrote: did you have a look at this one? I had both under my radar. :-) What are the (minor) differences between both patches? Edwin's patch attempts to treat the alignment that happens to be the default (say, Justified) differently from the rest, by adding (Default) after it and doing away with a special Default button. There are two problems with this, I think. Quoting from the previous OK. I think that the subject is important and I liked the discussion there, now let us move to other (critical) bugs. :-) Since I have to decide I opt for Richard's argument without any demerit for Edwin patch/solution. -- José Abílio
Re: [Patch Bug 3727] Environment combobox not updated when clicking bullet on toolbar
Jürgen Spitzmüller wrote: The attached onliner fixes the issue for me (and Uwe). Explanation: if current_layout is updated here, the test in LyXView.cpp:462 returns false and the combo is not updated. Furthermore, current_layout will be reset in LyXView.cpp (after the combo update). OK? Jürgen OK. This whole current_layout business smells bad though... A/
Re: [Patch Bug 3727] Environment combobox not updated when clicking bullet on toolbar
Explanation: if current_layout is updated here, the test in LyXView.cpp:462 returns false and the combo is not updated. Furthermore, current_layout will be reset in LyXView.cpp (after the combo update). Does this fix the issue of layout change with shortcut? Bo
[PATCH-updated] Paragraph Setting UI Bugs
This patch addresses the usability bugs discussed in this thread:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg121160.html
and largely implements Helge's suggestions. (Helge often seems to have
good ideas on these things.) The main change is that the Default
button is now a radio button like the rest, so you don't have to uncheck
Default to be allowed to check something else.
The layout that happens to be the default isn't treated specially at
all. The idea here is that saying, Align this as default, whatever that
is is different from saying Center this, come what may, even if, in
the current layout, centering happens to be the default. This seems the
right behavior, as the option certainly exists in LaTeX. At the moment,
however, LyX itself ignores this difference: if you choose Left, and
that is the default, it's effectively the same as choosing Default,
due to a bug in Text::setParagraph(). That will be fixed at a later
stage. It may involve more than should be done prior to 1.5.0, and I
don't have the time right now, anyway.
As Jurgen also pointed out, trying to treat what is in fact the default
alignment differently runs into problems with multi-paragraph
selections, since there may be no common default in such cases. But the
more compelling reason, I think, is the one just given, which was due to
Helge.
OK to apply?
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: src/frontends/qt4/QParagraph.cpp
===
--- src/frontends/qt4/QParagraph.cpp (revision 18853)
+++ src/frontends/qt4/QParagraph.cpp (working copy)
@@ -50,7 +50,7 @@
connect(applyPB, SIGNAL(clicked()), form_, SLOT(slotApply()));
connect(closePB, SIGNAL(clicked()), form_, SLOT(slotClose()));
connect(restorePB, SIGNAL(clicked()), form_, SLOT(slotRestore()));
- connect(alignDefaultCB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
+ connect(alignDefaultRB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
connect(alignJustRB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
connect(alignLeftRB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
connect(alignRightRB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
@@ -77,10 +77,17 @@
items is used.
));
- radioMap[LYX_ALIGN_BLOCK] = alignJustRB;
- radioMap[LYX_ALIGN_LEFT] = alignLeftRB;
- radioMap[LYX_ALIGN_RIGHT] = alignRightRB;
+ radioMap[LYX_ALIGN_LAYOUT] = alignDefaultRB;
+ radioMap[LYX_ALIGN_BLOCK] = alignJustRB;
+ radioMap[LYX_ALIGN_LEFT] = alignLeftRB;
+ radioMap[LYX_ALIGN_RIGHT] = alignRightRB;
radioMap[LYX_ALIGN_CENTER] = alignCenterRB;
+
+/* labelMap[LYX_ALIGN_LAYOUT] = Default;
+ labelMap[LYX_ALIGN_BLOCK] = Justified;
+ labelMap[LYX_ALIGN_LEFT] = Left;
+ labelMap[LYX_ALIGN_RIGHT] = Right;
+ labelMap[LYX_ALIGN_CENTER] = Center; */
}
@@ -105,35 +112,37 @@
void QParagraphDialog::checkAlignmentRadioButtons() {
- if (alignDefaultCB-isChecked()) {
- QPRadioMap::const_iterator it = radioMap.begin();
- for (; it != radioMap.end(); ++it)
- it-second-setDisabled(true);
- } else {
- LyXAlignment alignPossible = form_-controller().alignPossible();
- QPRadioMap::const_iterator it = radioMap.begin();
- for (; it != radioMap.end(); ++it)
- it-second-setEnabled(it-first alignPossible);
+ LyXAlignment const alignPossible = form_-controller().alignPossible();
+ //LyXAlignment const defaultAlignment = form_-controller().alignDefault();
+ QPRadioMap::iterator it = radioMap.begin();
+ for (; it != radioMap.end(); ++it) {
+ LyXAlignment const align = it-first;
+ it-second-setEnabled((align alignPossible) ||
+ (align == LYX_ALIGN_LAYOUT));
+/* string label = labelMap[align];
+ if (align == LYX_ALIGN_LAYOUT)
+ label += () + labelMap[defaultAlignment] + );
+ it-second-setText(qt_(label));*/
}
}
-void QParagraphDialog::on_alignDefaultCB_toggled(bool)
-{
- checkAlignmentRadioButtons();
- alignmentToRadioButtons();
-}
-
-
void QParagraphDialog::alignmentToRadioButtons(LyXAlignment align)
{
- if (align == LYX_ALIGN_LAYOUT)
- align = form_-controller().alignDefault();
+ LyXAlignment const defaultAlignment = form_-controller().alignDefault();
+ if (align == LYX_ALIGN_LAYOUT || align == defaultAlignment) {
+ alignDefaultRB-blockSignals(true);
+ alignDefaultRB-setChecked(true);
+ alignDefaultRB-blockSignals(false);
+ return;
+ }
QPRadioMap::const_iterator it = radioMap.begin();
for (;it != radioMap.end(); ++it) {
if (align == it-first) {
+ it-second-blockSignals(true);
it-second-setChecked(true);
+ it-second-blockSignals(false);
Re: [PATCH-updated] Paragraph Setting UI Bugs
On Friday 22 June 2007 17:28:06 Richard Heck wrote: OK to apply? OK. Richard -- José Abílio
Re: [PATCH-updated] Paragraph Setting UI Bugs
José Matos wrote:
On Friday 22 June 2007 17:28:06 Richard Heck wrote:
OK to apply?
did you have a look at this one?
Index: src/frontends/qt4/QParagraph.cpp
===
--- src/frontends/qt4/QParagraph.cpp (revision 18850)
+++ src/frontends/qt4/QParagraph.cpp (working copy)
@@ -50,7 +50,6 @@
connect(applyPB, SIGNAL(clicked()), form_, SLOT(slotApply()));
connect(closePB, SIGNAL(clicked()), form_, SLOT(slotClose()));
connect(restorePB, SIGNAL(clicked()), form_, SLOT(slotRestore()));
- connect(alignDefaultCB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
connect(alignJustRB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
connect(alignLeftRB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
connect(alignRightRB, SIGNAL(clicked()), this, SLOT(change_adaptor()));
@@ -77,9 +76,9 @@
items is used.
));
- radioMap[LYX_ALIGN_BLOCK] = alignJustRB;
- radioMap[LYX_ALIGN_LEFT] = alignLeftRB;
- radioMap[LYX_ALIGN_RIGHT] = alignRightRB;
+ radioMap[LYX_ALIGN_BLOCK] = alignJustRB;
+ radioMap[LYX_ALIGN_LEFT] = alignLeftRB;
+ radioMap[LYX_ALIGN_RIGHT] = alignRightRB;
radioMap[LYX_ALIGN_CENTER] = alignCenterRB;
}
@@ -105,35 +104,44 @@
void QParagraphDialog::checkAlignmentRadioButtons() {
- if (alignDefaultCB-isChecked()) {
- QPRadioMap::const_iterator it = radioMap.begin();
- for (; it != radioMap.end(); ++it)
- it-second-setDisabled(true);
- } else {
- LyXAlignment alignPossible = form_-controller().alignPossible();
- QPRadioMap::const_iterator it = radioMap.begin();
- for (; it != radioMap.end(); ++it)
- it-second-setEnabled(it-first alignPossible);
+ LyXAlignment const alignPossible = form_-controller().alignPossible();
+ LyXAlignment const defaultAlignment = form_-controller().alignDefault();
+ QPRadioMap::iterator it = radioMap.begin();
+ for (; it != radioMap.end(); ++it) {
+ it-second-setEnabled((it-first alignPossible) ||
+ (it-first == LYX_ALIGN_LAYOUT));
+ string label;
+ switch (it-first) {
+ case LYX_ALIGN_BLOCK:
+label = Justified;
+break;
+ case LYX_ALIGN_LEFT:
+label = Left;
+break;
+ case LYX_ALIGN_CENTER:
+label = Center;
+break;
+ case LYX_ALIGN_RIGHT:
+label = Right;
+break;
+ }
+
+ if (it-first == defaultAlignment)
+ label += (Default);
+
+ it-second-setText(qt_(label));
}
}
-void QParagraphDialog::on_alignDefaultCB_toggled(bool)
-{
- checkAlignmentRadioButtons();
- alignmentToRadioButtons();
-}
-
-
void QParagraphDialog::alignmentToRadioButtons(LyXAlignment align)
{
- if (align == LYX_ALIGN_LAYOUT)
- align = form_-controller().alignDefault();
-
QPRadioMap::const_iterator it = radioMap.begin();
for (;it != radioMap.end(); ++it) {
if (align == it-first) {
+ it-second-blockSignals(true);
it-second-setChecked(true);
+ it-second-blockSignals(false);
return;
}
}
@@ -145,18 +153,18 @@
LyXAlignment QParagraphDialog::getAlignmentFromDialog()
{
- if (alignDefaultCB-isChecked())
- return LYX_ALIGN_LAYOUT;
+ LyXAlignment const defaultAlignment = form_-controller().alignDefault();
LyXAlignment alignment = LYX_ALIGN_NONE;
QPRadioMap::const_iterator it = radioMap.begin();
for (; it != radioMap.end(); ++it) {
if (it-second-isChecked()) {
- alignment = it-first;
+ if (it-first == defaultAlignment)
+alignment = LYX_ALIGN_LAYOUT;
+ else
+alignment = it-first;
break;
}
}
- if (alignment == form_-controller().alignDefault())
- return LYX_ALIGN_LAYOUT;
return alignment;
}
@@ -243,15 +251,8 @@
}
// alignment
- LyXAlignment newAlignment = params.align();
- LyXAlignment defaultAlignment = controller().alignDefault();
- bool alignmentIsDefault =
- newAlignment == LYX_ALIGN_LAYOUT || newAlignment == defaultAlignment;
- dialog_-alignDefaultCB-blockSignals(true);
- dialog_-alignDefaultCB-setChecked(alignmentIsDefault);
- dialog_-alignDefaultCB-blockSignals(false);
dialog_-checkAlignmentRadioButtons();
- dialog_-alignmentToRadioButtons(newAlignment);
+ dialog_-alignmentToRadioButtons(params.align());
//indentation
bool const canindent = controller().canIndent();
Index: src/frontends/qt4/QParagraph.h
===
--- src/frontends/qt4/QParagraph.h (revision 18850)
+++ src/frontends/qt4/QParagraph.h (working copy)
@@ -49,8 +49,6 @@
void change_adaptor();
///
void enableLinespacingValue(int);
- ///
- void on_alignDefaultCB_toggled(bool);
};
Index: src/frontends/qt4/ui/ParagraphUi.ui
===
--- src/frontends/qt4/ui/ParagraphUi.ui (revision 18850)
+++ src/frontends/qt4/ui/ParagraphUi.ui (working copy)
@@ -8,8 +8,8 @@
rect
x0/x
y0/y
-width373/width
-height203/height
+width346/width
+height226/height
/rect
/property
property name=sizePolicy
@@ -36,76 +36,14 @@
property name=spacing
Re: [PATCH-updated] Paragraph Setting UI Bugs
José Matos wrote: On Friday 22 June 2007 17:42:34 Edwin Leuven wrote: did you have a look at this one? I had both under my radar. :-) What are the (minor) differences between both patches? Edwin's patch attempts to treat the alignment that happens to be the default (say, Justified) differently from the rest, by adding (Default) after it and doing away with a special Default button. There are two problems with this, I think. Quoting from the previous message: [In my patch] The layout that happens to be the default isn't treated specially at all. The idea here is that saying, Align this as default, whatever that is is different from saying Center this, come what may, even if, in the current layout, centering happens to be the default. This seems the right behavior, as the option certainly exists in LaTeX. At the moment, however, LyX itself ignores this difference: if you choose Left, and that is the default, it's effectively the same as choosing Default, due to a bug in Text::setParagraph(). That will be fixed at a later stage. It may involve more than should be done prior to 1.5.0, and I don't have the time right now, anyway. Second: As Jurgen also pointed out, trying to treat what is in fact the default alignment differently runs into problems with multi-paragraph selections, since there may be no common default in such cases. This could presumably be handled, but you'd need to modify the controller so that it would report whether we have a multi-paragraph selection. And, in any event, the best reason is the first., which was first raised by Helge and has since been endorsed by Joost, Jurgen, and (I think) Alfredo. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable
On Friday 22 June 2007 17:04:25 Dov Feldstern wrote: I don't think that a format change is needed, because we're using new languages, not changing the interpretation of existing ones. If there are users out there who have existing documents in ArabTeX, they'll have to replace all \lang arabic with \lang arabic_arabtex, but that's all. I think this is reasonable. I am sorry Dov, replacing \lang arabic by \lang arabic_arabtex is a file format change and an easy one to implement in lyx2lyx. Better yet, if I understood what you said it means that all the previous users of Arabic were using arabtex, right? If you, Mostafa and Uwe agree on a set of patches to be applied before rc2 this can proceed. -- José Abílio
Re: [PATCH-updated] Paragraph Setting UI Bugs
On Friday 22 June 2007 17:42:34 Edwin Leuven wrote: did you have a look at this one? I had both under my radar. :-) What are the (minor) differences between both patches? -- José Abílio
Re: [PATCH-updated] Paragraph Setting UI Bugs
Richard Heck wrote: What are the (minor) differences between both patches? there is a long thread on this but to summarize: the question is whether we want a separate default button for the rare situations in which we (1) change document layouts and (2) run into: 1 x is set and we change the default to x: 2 x (default) is set and the default changes: x in (just/left/center/right) ... i think adding ui for this is not necessary. the dialog would look as in attached. i makes explicit the default (and therefore allows to reset to the default) one needs to give it a serious try to figure out whether richards is to be preferred inline: par.png
A small patch for List of Algorithms
The List of algorithms label cannot be customized (translated) into
the output.
1. Create a new document
2. Choose a non english language
3. Insert a list of algorithms (Insert List / TOC List of
Algorithms)
4. View the source (View View Source)
The code corresponding to the List of Algorithms inset is '\listof
{algorithm}{List of Algorithms}', which AFAIK is not customizable.
It would then be more convenient to use the command
'\listofalgorithms' instead so that one could customize it...
Since this command isn't defined by default, adding \providecommand
{\listofalgorithms}{\listof{algorithm}{List of Algorithms}} in the
preamble does the job. This definition may now be overridden by the
user, by loading 'algorithm.sty'/'algorithmic.sty', or just with a
'\renewcommand' in the preamble.
The attached patch solves the problem. Please tell me if it's
sufficient as I'm note sure if things are done in the right way...
Mael.
listofalgorithms.patch
Description: Binary data
A small patch for List of Algorithms
The List of algorithms label cannot be customized (translated) into
the output.
1. Create a new document
2. Choose a non english language
3. Insert a list of algorithms (Insert List / TOC List of
Algorithms)
4. View the source (View View Source)
The code corresponding to the List of Algorithms inset is '\listof
{algorithm}{List of Algorithms}', which AFAIK is not customizable.
It would then be more convenient to use the command
'\listofalgorithms' instead so that one could customize it...
Since this command isn't defined by default, adding \providecommand
{\listofalgorithms}{\listof{algorithm}{List of Algorithms}} in the
preamble does the job. This definition may now be overridden by the
user, by loading 'algorithm.sty'/'algorithmic.sty', or just with a
'\renewcommand' in the preamble.
The attached patch solves the problem. Please tell me if it's
sufficient as I'm note sure if things are done in the right way...
Mael.
listofalgorithms.patch
Description: Binary data
A small patch for List of Algorithms
The List of algorithms label cannot be customized (translated) into the
output.
1. Create a new document
2. Choose a non english language
3. Insert a list of algorithms (Insert List / TOC List of Algorithms)
4. View the source (View View Source)
The code corresponding to the List of Algorithms inset is
'\listof{algorithm}{List of Algorithms}', which AFAIK is not customizable.
It would then be more convenient to use the command '\listofalgorithms' instead
so that one could customize it...
Since this command isn't defined by default, adding
\providecommand{\listofalgorithms}{\listof{algorithm}{List of Algorithms}} in
the preamble does the job. This definition may now be overridden by the user, by
loading 'algorithm.sty'/'algorithmic.sty', or just with a '\renewcommand' in the
preamble.
The attached patch solves the problem. Please tell me if it's sufficient as I'm
note sure if things are done in the right way...
Mael.
listofalgorithms.patch
Description: Binary data
Re: [PATCH-updated] Paragraph Setting UI Bugs
On Friday 22 June 2007 18:21:52 Edwin Leuven wrote: let me guess, you tossed a coin...? Not on Fridays. :-) In case it matters both solutions are better than what we have now, and I am closer from Richard's reasoning in this case. Also after some time if no consensus is reached it is better to decide and move on. -- José Abílio
Re: [patch] bug 2520: Make InsetExternal translateable
On Friday 22 June 2007 16:33:41 Jürgen Spitzmüller wrote: Som nanyone? Can I commit? Jürgen OK. -- José Abílio
Re: [PATCH-updated] Paragraph Setting UI Bugs
José Matos wrote: On Friday 22 June 2007 18:21:52 Edwin Leuven wrote: let me guess, you tossed a coin...? Not on Fridays. :-) observational equivalent though... In case it matters both solutions are better than what we have now, sure and I am closer from Richard's reasoning in this case. i think this needs another thought, but it doesn't really matter since we can always change this later... Also after some time if no consensus is reached it is better to decide and move on. suffice to say that i disagree ...
Re: A small patch for List of Algorithms
I apologize, I sent this mail twice. I had some problems with my SMTP
server...
Le 22 juin 07 à 20:48, Mael Hilléreau a écrit :
The List of algorithms label cannot be customized (translated)
into the
output.
1. Create a new document
2. Choose a non english language
3. Insert a list of algorithms (Insert List / TOC List of
Algorithms)
4. View the source (View View Source)
The code corresponding to the List of Algorithms inset is
'\listof{algorithm}{List of Algorithms}', which AFAIK is not
customizable.
It would then be more convenient to use the command
'\listofalgorithms' instead
so that one could customize it...
Since this command isn't defined by default, adding
\providecommand{\listofalgorithms}{\listof{algorithm}{List of
Algorithms}} in
the preamble does the job. This definition may now be overridden by
the user, by
loading 'algorithm.sty'/'algorithmic.sty', or just with a
'\renewcommand' in the
preamble.
The attached patch solves the problem. Please tell me if it's
sufficient as I'm
note sure if things are done in the right way...
Mael.listofalgorithms.patch
Re: [PATCH-updated] Paragraph Setting UI Bugs
On Fri, Jun 22, 2007 at 07:21:52PM +0200, Edwin Leuven wrote: José Matos wrote: OK. I think that the subject is important and I liked the discussion there, now let us move to other (critical) bugs. :-) Since I have to decide I opt for Richard's argument without any demerit for Edwin patch/solution. let me guess, you tossed a coin...? Even tossing coins makes sense from time to time. Andre'
Re: [patch] fix bug 1942
I don't think that bug 3902 should stop you committing your valuable solution to bug 1942 as, in the Mac case, it provides a considerable improvement. OK then I misunderstood you. I thought you meant that the patch introduces a new problem. I applied the patch. regards Uwe
Re: A small patch for List of Algorithms
Mael Hilléreau wrote: I apologize, I sent this mail twice. I had some problems with my SMTP server... No need to apologize. The list is terribly slow today, some messages had a delay of more than an hour. A/
Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable
I applied the following patch:
http://www.lyx.org/trac/changeset/18858
Mostafa Vahedi schrieb:
Attached is a better patch where
everything is implemented:
- correct encoding for the fontenc
package. Mostafa tested this and
gave his OK for this issue.
This is exteremly OK.
This is included in the committed patch.
- special quotation mark definitions
for Farsi. Mostafa tested this and
gave his OK for this issue.
This is OK. It should be removed later
as you have mentioned it.
I added a comment regarding this.
BUT BUT BUT BUT
In fact there are three commands not
two commands. The command
[EMAIL PROTECTED]@R{#1}}
will make problems when we want the Arabic
based on ARABI as the main language.
Therefore remove this one from the
file languages and keep the other two.
We should use this command only if the
main language is not Arabic_ARABI.
OK, done in the commited patch.
- fix for bug 2929 - use \textAR
and not \R. Improved version of Dov's
patch. Mostafa also tested this
successfully.
No. I have not yet. In fact this is
not basically a bug.
OK I droped it from the patch.
- use the document language also for
the TOC. This is a special arabi-package
thing. Please test.
It needs more investigation. We should
find the correct point in the source
at which we could place the command
\TOCLanguage{farsi}.
- To make the TOC settings work and also
for other issues, arabic must be loaded
to babel too when farsi is the document
language. Please test.
This fix should be temporarily too and so
it should be removed later if the bug
is fixed later. I will test it.
What is your result for these two? Only with them I can compile the example_lyxified.lyx you sent to
the list.
regards Uwe
Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable
Uwe Stöhr schrieb: I applied the following patch: http://www.lyx.org/trac/changeset/18858 I corrected it: http://www.lyx.org/trac/changeset/18859 Uwe
Re: [PATCH-updated] Paragraph Setting UI Bugs
I've committed this now, with a reference to this discussion. Richard Richard Heck wrote: José Matos wrote: On Friday 22 June 2007 17:42:34 Edwin Leuven wrote: did you have a look at this one? I had both under my radar. :-) What are the (minor) differences between both patches? Edwin's patch attempts to treat the alignment that happens to be the default (say, Justified) differently from the rest, by adding (Default) after it and doing away with a special Default button. There are two problems with this, I think. Quoting from the previous message: [In my patch] The layout that happens to be the default isn't treated specially at all. The idea here is that saying, Align this as default, whatever that is is different from saying Center this, come what may, even if, in the current layout, centering happens to be the default. This seems the right behavior, as the option certainly exists in LaTeX. At the moment, however, LyX itself ignores this difference: if you choose Left, and that is the default, it's effectively the same as choosing Default, due to a bug in Text::setParagraph(). That will be fixed at a later stage. It may involve more than should be done prior to 1.5.0, and I don't have the time right now, anyway. Second: As Jurgen also pointed out, trying to treat what is in fact the default alignment differently runs into problems with multi-paragraph selections, since there may be no common default in such cases. This could presumably be handled, but you'd need to modify the controller so that it would report whether we have a multi-paragraph selection. And, in any event, the best reason is the first., which was first raised by Helge and has since been endorsed by Joost, Jurgen, and (I think) Alfredo. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: farsi keyboard farsi.kmap
Mostafa Vahedi schrieb: Ok. Here you are! Done, I committed the keymap file. regards Uwe
Re: [Patch Bug 3727] Environment combobox not updated when clicking bullet on toolbar
Does this fix the issue of layout change with shortcut? Yes. Uwe
Re: A small patch for List of Algorithms
Le 22 juin 07 à 22:44, Alfredo Braunstein a écrit : Mael Hilléreau wrote: I apologize, I sent this mail twice. I had some problems with my SMTP server... No need to apologize. The list is terribly slow today, some messages had a delay of more than an hour. Ok, happy to know that it's not my fault ;) I thought that my mails were blocked again into my local network (I had SMTP problems since monday...). Mael.
Install Win32 Instructions
I had a bit of trouble with Step 7. of http://www.lyx.org/trac/ browser/lyx-devel/trunk/INSTALL.Win32 by following the instruction too literally. Preceding instructions excellent. I suggest the following would be an improvement: 7 Compile From MS Visual Studio command prompt (not the regular cmd.exe), cd lyx root directory\development\Win32\packaging\ build_msvc.bat This worked for me. Regards Roger
Re: Install Win32 Instructions
I suggest the following would be an improvement: 7 Compile From MS Visual Studio command prompt (not the regular cmd.exe), cd lyx root directory\development\Win32\packaging\ build_msvc.bat This worked for me. Thank you very much. The instruction has been updated. Cheers, Bo
Re: [patch] better fix for bug 2928: make Arabic and Farsi correctly usable
Attached is Dov's latest patch. I added the font encoding stuff and the fileformat change. It is
furthermore needed to load arabtex in the preamble when the language is arabic_arabtex, I added this
to the patch. Please test.
---
Dov wrote:
+arabic_arabtex arabic Arabic (ArabTeX) true cp1256 ar_SA
When arabtex is used, babel should not be loaded (because babel is not supported by arabtex and to
avaoid interferences with arabi), I therefore corrected this line.
All other parts of your patch are OK.
I tested the last hour all combinations of languages to be save that our patch does not have any
drawbacks and I think it is save to apply.
---
There is one thing that needs to be improved: As I told you arabtex must be loaded in the preamble,
but it must be loaded whenever arabic_arabtex is used in the document, also when arabic is not the
document language. I don't know how to implement this. Currently I hae this:
if (language-lang() == arabic_arabtex) {
os \\usepackage{arabtex}\n;
But this is only the document language. How can I test if one of the languages used in the document
is arabic?
thanks and regards
Uwe
Index: lib/languages
===
--- lib/languages (revision 18861)
+++ lib/languages (working copy)
@@ -1,7 +1,8 @@
# name babel name GUI name RTL? encoding code latex options
afrikaans afrikaans Afrikaans false iso8859-15 af_ZA
americanamerican American false iso8859-15 en_US
-arabic arabic Arabic true cp1256 ar_SA
+arabic_arabtex Arabic (ArabTeX) true cp1256 ar_SA
+arabic_arabi arabic Arabic (Arabi) true cp1256 ar_SA
armenian Armenian false armscii8 hy_AM
austrianaustrian Austrian false iso8859-15 de_AT
naustrian naustrian Austrian (new spelling) false iso8859-15 de_AT
Index: lib/lyx2lyx/LyX.py
===
--- lib/lyx2lyx/LyX.py (revision 18861)
+++ lib/lyx2lyx/LyX.py (working copy)
@@ -77,7 +77,7 @@
(1_2, [220], generate_minor_versions(1.2 , 4)),
(1_3, [221], generate_minor_versions(1.3 , 7)),
(1_4, range(222,246), generate_minor_versions(1.4 , 4)),
- (1_5, range(246,275), generate_minor_versions(1.5 , 0))]
+ (1_5, range(246,276), generate_minor_versions(1.5 , 0))]
def formats_list():
Index: lib/lyx2lyx/lyx_1_5.py
===
--- lib/lyx2lyx/lyx_1_5.py (revision 18861)
+++ lib/lyx2lyx/lyx_1_5.py (working copy)
@@ -1749,6 +1749,34 @@
r'\end_layout'
]
+def convert_arabic (document):
+if document.language == arabic:
+document.language = arabic_arabtex
+i = find_token(document.header, \\language, 0)
+if i != -1:
+document.header[i] = \\language arabic_arabtex
+i = 0
+while i len(document.body):
+h = document.body[i].find(\lang arabic, 0, len(document.body[i]))
+if (h != -1):
+# change the language name
+document.body[i] = '\lang arabic_arabtex'
+i = i + 1
+
+def revert_arabic (document):
+if document.language == arabic_arabtex:
+document.language = arabic
+i = find_token(document.header, \\language, 0)
+if i != -1:
+document.header[i] = \\language arabic
+i = 0
+while i len(document.body):
+h = document.body[i].find(\lang arabic_arabtex, 0, len(document.body[i]))
+if (h != -1):
+# change the language name
+document.body[i] = '\lang arabic'
+i = i + 1
+
##
# Conversion hub
#
@@ -1782,10 +1810,12 @@
[271, [convert_ext_font_sizes]],
[272, []],
[273, []],
- [274, [normalize_font_whitespace_274]]
+ [274, [normalize_font_whitespace_274]],
+ [275, [convert_arabic]]
]
revert = [
+ [274, [revert_arabic]],
[273, []],
[272, [revert_separator_layout]],
[271, [revert_preamble_listings_params, revert_listings_inset, revert_include_listings]],
Index: src/Buffer.cpp
===
--- src/Buffer.cpp (revision 18861)
+++ src/Buffer.cpp (working copy)
@@ -142,7 +142,7 @@
namespace {
-int const LYX_FORMAT = 274;
+int const LYX_FORMAT = 275;
} // namespace anon
Index: src/BufferParams.cpp
===
--- src/BufferParams.cpp (revision 18861)
+++ src/BufferParams.cpp (working copy)
@@ -895,9 +895,9 @@
// set font encoding
// this one is not per buffer
- // for Farsi we also need to load the LAE and LFE encoding
+ // for arabic_arabi and farsi we also need to load the LAE and LFE encoding
if (lyxrc.fontenc != default) {
- if
source code question about language check in LyX documents
Can anybody help me with this issue?:
Special lines should to be added to the preamble whenever e.g. Arabic is used
in the document.
I know how to do this in Bufferparams.cp when Arabic is the document language:
if (language-lang() == arabic_arabtex) {
os \\usepackage{arabtex}\n;
texrow.newline();
}
But \usepackage{arabtex} must be loaded whenever Arabic is used in a document, no matter if it is
the document language or not. How can this be done?
thanks and regards
Uwe
Re: Install Win32 Instructions
cd lyx root directory\development\Win32\packaging\ build_msvc.bat The best way is to add the following line at the begining of build_msvc.bat: cd /D %~dp0 and also for bebug build. In this way, you can drag the .bat and drop in any MSVC command console, then hit return to compile. I have a patch for this but I'm out of town now. But I think anyone can make a patch for this :-) Hangzai
Re: source code question about language check in LyX documents
Uwe Stöhr wrote:
Can anybody help me with this issue?:
Special lines should to be added to the preamble whenever e.g. Arabic
is used in the document.
I know how to do this in Bufferparams.cp when Arabic is the document
language:
if (language-lang() == arabic_arabtex) {
os \\usepackage{arabtex}\n;
texrow.newline();
}
But \usepackage{arabtex} must be loaded whenever Arabic is used in a
document, no matter if it is the document language or not. How can
this be done?
Someone else will have the complete answer, I expect, but you do this
kind of thing in the validate() routines of the various inset types,
setting the LaTeX Features, which are then applied in
LatexFeatures.cpp. I don't know how to check whether a language is used
in an inset.
Richard
[PATCH] Finish Reworking of Paragraph Settings Dialog
Contrary to what I said in a previous message, completing the reworking
of the Paragraph Settings dialog isn't terribly difficult. Here's the
issue: In this dialog---both before the most recent patch and since it,
though there was some disagreement about this---we distinguish between
the Default alignment and, say, Justified, even if Justified happens to
be the Default for that paragraph. The reason to make this distinction
is that it is one thing to say, Give this paragraph the default
alignment, whatever that is and another to say, Make this paragraph
fully justified, no matter what. The difference will only show up in
certain kinds of cases, such as when one is changing layouts, but it
seems to many of us, at least, that the difference should be respected,
and that the option of requiring a certain alignment, even if that is
currently the default, should be available.
The existing LyX code does not, however, respect the mentioned
difference, and the result is that the mentioned option isn't available,
in fact: If the default for a given paragraph is, as it happens,
Justified , then attempting to set the alignment to LYX_ALIGN_BLOCK will
fail: You'll actually get LYX_ALIGN_LAYOUT. The attached patch fixes
this. It's fairly simple: (i) In Text::setParagraph(), the code that
does what was just mentioned is removed; (ii) in
Paragraph::StartTeXParParams(), we ignore the alignment stuff if the
chosen alignment is the default for the paragraph; and (iii) in
QParagraph::alignmentToRadioButtons(), we remove similarly offending
code. (I've also removed some commented-out code I accidentally left in
a previous patch.)
This is safe, I think, and in the spirit of completing the previous UI
fix. Seeking two OKs.
Richard
Index: frontends/qt4/QParagraph.cpp
===
--- frontends/qt4/QParagraph.cpp (revision 18865)
+++ frontends/qt4/QParagraph.cpp (working copy)
@@ -113,30 +113,17 @@
void QParagraphDialog::checkAlignmentRadioButtons() {
LyXAlignment const alignPossible = form_-controller().alignPossible();
- //LyXAlignment const defaultAlignment = form_-controller().alignDefault();
QPRadioMap::iterator it = radioMap.begin();
for (; it != radioMap.end(); ++it) {
LyXAlignment const align = it-first;
it-second-setEnabled((align alignPossible) ||
(align == LYX_ALIGN_LAYOUT));
-/* string label = labelMap[align];
- if (align == LYX_ALIGN_LAYOUT)
- label += () + labelMap[defaultAlignment] + );
- it-second-setText(qt_(label));*/
}
}
void QParagraphDialog::alignmentToRadioButtons(LyXAlignment align)
{
- LyXAlignment const defaultAlignment = form_-controller().alignDefault();
- if (align == LYX_ALIGN_LAYOUT || align == defaultAlignment) {
- alignDefaultRB-blockSignals(true);
- alignDefaultRB-setChecked(true);
- alignDefaultRB-blockSignals(false);
- return;
- }
-
QPRadioMap::const_iterator it = radioMap.begin();
for (;it != radioMap.end(); ++it) {
if (align == it-first) {
Index: Paragraph.cpp
===
--- Paragraph.cpp (revision 18865)
+++ Paragraph.cpp (working copy)
@@ -1781,8 +1781,13 @@
os \\noindent ;
column += 10;
}
+
+ LyXAlignment const curAlign = params().align();
- switch (params().align()) {
+ if (curAlign == layout()-align)
+ return column;
+
+ switch (curAlign) {
case LYX_ALIGN_NONE:
case LYX_ALIGN_BLOCK:
case LYX_ALIGN_LAYOUT:
@@ -1798,7 +1803,7 @@
break;
}
- switch (params().align()) {
+ switch (curAlign) {
case LYX_ALIGN_NONE:
case LYX_ALIGN_BLOCK:
case LYX_ALIGN_LAYOUT:
Index: Text2.cpp
===
--- Text2.cpp (revision 18865)
+++ Text2.cpp (working copy)
@@ -649,16 +649,9 @@
params.spacing(spacing);
// does the layout allow the new alignment?
- Layout_ptr const layout = par.layout();
-
- if (align == LYX_ALIGN_LAYOUT)
- align = layout-align;
- if (align layout-alignpossible) {
- if (align == layout-align)
-params.align(LYX_ALIGN_LAYOUT);
- else
-params.align(align);
- }
+ if ((align == LYX_ALIGN_LAYOUT) ||
+ (align par.layout()-alignpossible))
+ params.align(align);
par.setLabelWidthString(labelwidthstring);
params.noindent(noindent);
}
LeftIndent Paragraph Setting??
In ParagraphParameters.cpp and elsewhere, there are references to a leftindent property. At present, however, I see no way to set this property. In particular, it isn't in the Paragraph Settings dialog, and isn't in 1.4.4, either. Anyone know the history of this? Richard
[PATCH-update] Finish Reworking of Paragraph Settings Dialog
Slight update...
Contrary to what I said in a previous message, completing the reworking
of the Paragraph Settings dialog isn't terribly difficult. Here's the
issue: In this dialog---both before the most recent patch and since it,
though there was some disagreement about this---we distinguish between
the Default alignment and, say, Justified, even if Justified happens to
be the Default for that paragraph. The reason to make this distinction
is that it is one thing to say, Give this paragraph the default
alignment, whatever that is and another to say, Make this paragraph
fully justified, no matter what. The difference will only show up in
certain kinds of cases, such as when one is changing layouts, but it
seems to many of us, at least, that the difference should be respected,
and that the option of requiring a certain alignment, even if that is
currently the default, should be available.
The existing LyX code does not, however, respect the mentioned
difference, and the result is that the mentioned option isn't available,
in fact: If the default for a given paragraph is, as it happens,
Justified , then attempting to set the alignment to LYX_ALIGN_BLOCK will
fail: You'll actually get LYX_ALIGN_LAYOUT. The attached patch fixes
this. It's fairly simple: (i) In Text::setParagraph(), the code that
does what was just mentioned is removed; (ii) in
Paragraph::StartTeXParParams(), we ignore the alignment stuff if the
chosen alignment is the default for the paragraph; (iii) in
QParagraph::alignmentToRadioButtons(), we remove similarly offending
code; and (iv) in ParagraphParameters::params2string(), a similar sort
of change. I've also removed some commented-out code I accidentally left in
a previous patch.
This is safe, I think, and in the spirit of completing the previous UI
fix. Seeking two OKs.
Richard
Index: Text2.cpp
===
--- Text2.cpp (revision 18865)
+++ Text2.cpp (working copy)
@@ -649,16 +649,12 @@
params.spacing(spacing);
// does the layout allow the new alignment?
- Layout_ptr const layout = par.layout();
-
- if (align == LYX_ALIGN_LAYOUT)
- align = layout-align;
- if (align layout-alignpossible) {
- if (align == layout-align)
-params.align(LYX_ALIGN_LAYOUT);
- else
-params.align(align);
- }
+ //FIXME The reason we need the first check is because
+ //LYX_ALIGN_LAYOUT isn't required to be possible. It
+ //should be...and will be.
+ if ((align == LYX_ALIGN_LAYOUT) ||
+ (align par.layout()-alignpossible))
+ params.align(align);
par.setLabelWidthString(labelwidthstring);
params.noindent(noindent);
}
Index: Paragraph.cpp
===
--- Paragraph.cpp (revision 18865)
+++ Paragraph.cpp (working copy)
@@ -1781,8 +1781,13 @@
os \\noindent ;
column += 10;
}
+
+ LyXAlignment const curAlign = params().align();
- switch (params().align()) {
+ if (curAlign == layout()-align)
+ return column;
+
+ switch (curAlign) {
case LYX_ALIGN_NONE:
case LYX_ALIGN_BLOCK:
case LYX_ALIGN_LAYOUT:
@@ -1798,7 +1803,7 @@
break;
}
- switch (params().align()) {
+ switch (curAlign) {
case LYX_ALIGN_NONE:
case LYX_ALIGN_BLOCK:
case LYX_ALIGN_LAYOUT:
Index: ParagraphParameters.cpp
===
--- ParagraphParameters.cpp (revision 18865)
+++ ParagraphParameters.cpp (working copy)
@@ -279,14 +279,11 @@
// This needs to be done separately
params.labelWidthString(par.getLabelWidthString());
- // Alignment
- Layout_ptr const layout = par.layout();
- if (params.align() == LYX_ALIGN_LAYOUT)
- params.align(layout-align);
-
ostringstream os;
params.write(os);
+ Layout_ptr const layout = par.layout();
+
// Is alignment possible
os \\alignpossible layout-alignpossible '\n';
Index: frontends/qt4/QParagraph.cpp
===
--- frontends/qt4/QParagraph.cpp (revision 18865)
+++ frontends/qt4/QParagraph.cpp (working copy)
@@ -83,11 +83,6 @@
radioMap[LYX_ALIGN_RIGHT] = alignRightRB;
radioMap[LYX_ALIGN_CENTER] = alignCenterRB;
-/* labelMap[LYX_ALIGN_LAYOUT] = Default;
- labelMap[LYX_ALIGN_BLOCK] = Justified;
- labelMap[LYX_ALIGN_LEFT] = Left;
- labelMap[LYX_ALIGN_RIGHT] = Right;
- labelMap[LYX_ALIGN_CENTER] = Center; */
}
@@ -113,30 +108,21 @@
void QParagraphDialog::checkAlignmentRadioButtons() {
LyXAlignment const alignPossible = form_-controller().alignPossible();
- //LyXAlignment const defaultAlignment = form_-controller().alignDefault();
QPRadioMap::iterator it = radioMap.begin();
for (; it != radioMap.end(); ++it) {
LyXAlignment const align = it-first;
+ //FIXME The reason we need the second check is because
+ //LYX_ALIGN_LAYOUT isn't required to be possible. It
+ //should be...and will be.
it-second-setEnabled((align alignPossible) ||
(align ==
Re: [Patch] Allow insertion of spaces using the minibuffer
Andre Poenitz wrote: Pretty trivial patch attached. Ok? can you add a comment?
Re: [Patch] Allow insertion of spaces using the minibuffer
On Fri, Jun 22, 2007 at 08:00:04AM +0200, Edwin Leuven wrote: > Andre Poenitz wrote: > >Pretty trivial patch attached. > > > >Ok? > > can you add a comment? The feature (inserting a space via lfun) was asked for twice during the last few weeks. Now that is possible using M-x unicode-insert 0x20. Andre'
Re: Is there an easy way to tell if an inset is modified?
Alfredo Braunstein wrote: Bo Peng wrote: I don't know Bo, I think that latex_code() is a reasonably efficient way of having a signature of the math inset (to check if it has changed). I would be surprised if this had a real performance impact (typically O(1) operations per user interaction, we do much worse elsewhere in the code) OK. Do you have any doubt in replacing notifyCursorLeaves with the standalone version? If not, I will submit Alfredo's patch. It looks safe enough to me. It seems safe also to me. But there's no real hurry, we can wait for another OK. I can commit tomorrow (I have now svn access). OK for me too :-) Good job! Abdel.
Re: [PATCH] Paragraph Setting UI Bugs
Edwin Leuven wrote: Richard Heck wrote: This patch addresses the usability bugs discussed in this thread: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg121160.html and largely implements Helge's suggestions. (Helge often seems to have good ideas on these things.) The main change is that the "Default" button is now a radio button like the rest, so you don't have to uncheck Default to be allowed to check something else. much better indeed The layout that happens to be the default isn't treated specially except insofar as it is italicized, so as to indicate which one it is. i don't like this fiddling with fonts to suggest to the user what is going on. why not be explicit? o Default (Justified) o Justified o Left o Center o Right I agree with Edwin personally. I would also agree with o Justified (Default) o Left o Center o Right But we can change that later if we reach consensus. Abdel.
Re: problems to show figures in LyX
On Wed, Jun 20, 2007 at 10:00:54PM +0200, Enrico Forestieri wrote: > On Wed, Jun 20, 2007 at 09:44:12AM +0100, José Matos wrote: > > On Wednesday 20 June 2007 00:00:06 Enrico Forestieri wrote: > > > The attached patch fixes it. José, OK to commit? > > > > The patch seems right. If you someone to test this and guarantee that it > > works (no need to be a developer) it can go in. > > Here is an updated patch that also cures the following startup error > on *nix/cygwin: > > Error returned from iconv > EILSEQ An invalid multibyte sequence has been encountered in the input. > When converting from UTF-8 to UCS-4LE. > Input: 0x2f 0x74 0x6d 0x70 0x2f 0x6f 0x6c 0xe0 0x2f 0x6c 0x79 0x78 0x5f 0x74 > 0x6d 0x70 0x64 0x69 0x72 0x32 0x30 0x30 0x30 0x63 0x77 0x73 0x63 0x54 0x6c > 0x2f 0x6c 0x79 0x78 0x73 0x6f 0x63 0x6b 0x65 0x74 > > and this one on windows: > > Error returned from iconv > EINVAL An incomplete multibyte sequence has been encountered in the input. > When converting from UTF-8 to UCS-4LE. > Input: 0x43 0x3a 0x2f 0x63 0x79 0x67 0x77 0x69 0x6e 0x2f 0x74 0x6d 0x70 0x2f > 0x6f 0x6c 0xe0 > > when the temp dir has nonascii chars. These errors are triggered by the > fact that setEnv() and addName() take utf8 strings as input and they are > instead passed local 8bit encoded strings. I doubt that anyone will test it > (see here: http://article.gmane.org/gmane.editors.lyx.general/39630) > so, José, take your responsibility and make a decision ;-) > I tested the patch and guarantee that it is correct ;-) This is now bug 3904. http://bugzilla.lyx.org/show_bug.cgi?id=3904 -- Enrico
Re: [patch] fix bug 1942
Am 22.06.2007 um 00:42 schrieb Uwe Stöhr: Attached is a patch from Georg that fixes the regression bug 1942: Inconsistent look of integral symbols. I tested it thoroughly will all combinations of the packages esint, wasysym, and amsmath. A Mac user has reported a perhaps related problem that I and Georg couldn't reproduce as consequence of bug 1942. So before this can go in, I need an OK from a Mac user that this patch does only fix the bug and not introduces the problem reported in http://bugzilla.lyx.org/show_bug.cgi?id=3902 Stefan, JMarc, could you please test this the following way: Before you apply the patch: Check if bug 3902 is not already there. With the double integral the math preview does not appear. What should I do now? Stefan PGP.sig Description: Signierter Teil der Nachricht
RE: [Patch] Allow insertion of spaces using the minibuffer
Andre Poenitz wrote: > On Fri, Jun 22, 2007 at 08:00:04AM +0200, Edwin Leuven wrote: >> Andre Poenitz wrote: >>> Pretty trivial patch attached. >>> >>> Ok? >> can you add a comment? > > The feature (inserting a space via lfun) was asked for twice during the > last few weeks. Now that is possible using M-x unicode-insert 0x20. i guess i forgot to mention it was friday
RE: Re: No paragraph alignment options
Alfredo Braunstein wrote: > Specially with new document classes I normally don't know what the layouts > really are so I switch back and forth several times... i agree that the only situation where this might reasonably occur is when switching document classes. so given that: - people don't switch document classes often (i for example never do) - switching document layouts often involve information loss because they do not define similar environments - case 1 & 2 are rare i really don't see the point of cluttering the user interface for these very small contingencies. i also think that o Justified (Default) o Left o Center o Right will be more understandable to users who don't know latex while at the same time it makes default explicit which is think was the starting point imo of course...
RE: Re: No paragraph alignment options
Leuven, E. wrote: > - case 1 & 2 are rare No, they're not. Jürgen
RE: RE: Re: No paragraph alignment options
>> - case 1 & 2 are rare > > No, they're not. where do you get your stats from?
Re: [PATCH] Paragraph Setting UI Bugs
Abdelrazak Younes wrote: I agree with Edwin personally. I would also agree with o Justified (Default) o Left o Center o Right But we can change that later if we reach consensus. I think default should be an additional option. There may be good reasons to set the alignment to the setting that is also the default. Joost
RE: RE: Re: No paragraph alignment options
Leuven, E. wrote: >> No, they're not. > > where do you get your stats from? Where do you get your stats from? I just think it's wrong to assume that justified is the de facto "standard" alignment. This might be true for standard paragraphs in most book and article classes, for others it is not. I often redefine the alignment of several paragraph styles in the preamble (or of certain classes) due to the guidelines of the publishers. The approach you are proposing results in dataloss/wrong output, and this is a no-opt IMHO. Jürgen
Re: character pairs such as parenthesis in Farsi (a patch)
Mostafa Vahedi wrote: >> Currently (only) Unicode is used for Farsi as the input >> encoding. Moreover in Unicode the openning parenthesis >> is always the left one (independent of the language) >> I have modified the code to reverse the direction of >> the character-pairs when it wants to display the >> characters whenever the language is Arabic or Farsi. >> Maybe the direction should be changed only when the >> language is Farsi (not Arabic), but only one parameter, >> i.e. bool Arabic, is sent to the function). > Mostafa > Hi Mostafa! > This patch looks good, but I'm not sure that it > should be applied for Arabic. Currently (before > applying your patch, but with what you previously > put in already in place) I'm getting backwards > parentheses in Arabic. As I see it, there are two > ways to go about solving this: > 1) If the parentheses really do need to be reversed > when using Unicode input (I'm not set up for Unicode > input, I don't think, so I can't test this), then > the patch *should* be applied also for arabic. Then, > however, when using the keymap, parentheses are > backwards --- but we can just fix that in the keymap > itself, by adding > \kmap ( ) > \kmap ) ( > 2) If for Arabic Unicode the patch should not be > applied, then it should be applied only for farsi. > Either way, it probably wouldn't be a bad idea to > add a separate bool variable for farsi --- there's > no real reason why farsi and arabic should share > the variable... > (I haven't tried your patch, because I'm having > trouble with the spacing copying it from the email. > Could you attach it --- or one modified according > to the above suggestions -- as an attachment next > time, then I'll test it.) > Dov Dear Dov, The problem is independent of the language, rather it depends on the encoding. In other words it does not depend on Arabic or Farsi but it depends on the encoding we would like to save our texts. First we should make it clear for ourselves what the internal encoding of the LyX file (not the LaTeX file) is. If it is Unicode then we should obey the unicode rules. In Unicode we always use the LATIN-left paranthesis as the opening one but during the representation or display we consider the context and display the correct one. Clearly there is some sort of encoding mapping during the generation of the LaTeX file. In my opinion there we should change the direction of the paranthesis in case it is needed. What is the internal encoding of a LyX file? Where is the point at which we can consider reversing the direction of the character pairs when converting a LyX file to a LaTeX file in case it is needed? - Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. rowpainter.diff Description: 990053006-rowpainter.diff
RE: RE: Re: No paragraph alignment options
Alfredo Braunstein wrote: > Let me give you another case: I often write my titles first in Standard > Layout and *then* switch the layout to Title. With your approach I would > have to manually center it. Awful. no. reread what i wrote: "i would be fine with having the default take precedence in both cases and have this in the interface: o Justified (default) o Left o Center o Right " ... since default takes precedence things go fine in your example. >> i really don't see the point of cluttering the user interface for these >> very small contingencies. > > Clutter is a big word... CLUTTER is even bigger > What happends if the user moves the cursor when the dialog is open, does it > get updated? it should be (until we get rid of these modeless dialogs) > In any case I prefer your other proposal with Default (Justified) and all > the rest. i can live with that > So I vote that or no change ;-) i should remind you that it is friday
RE: RE: RE: Re: No paragraph alignment options
Juergen Spitzmueller wrote: > Where do you get your stats from? from a very reliable source > I just think it's wrong to assume that justified is the de facto "standard" > alignment. ? you are misunderstanding me. the inset/layout should tell us what the default is (and i think it does at the moment). so sometimes this will be justified, in other cases center, etc. > I often redefine the alignment of several paragraph styles in the preamble > (or of certain classes) due to the guidelines of the publishers. The > approach you are proposing results in dataloss/wrong output, i don't think so
Re: issues with change tracking
Edwin Leuven wrote: > if i creat a selection that spans more than one line and then type > something (so that the selection gets replace with my new text), the > selection before the line where cursor is isn't crossed out. there is a > missing screen update here. Confirmed. > second thing is when i delete a collapsed footnote. the collapse > footnote gets crossed out in lyx but not the text inside. in the dvi the > footnote isn't crossed out. Confirmed. Note that this has nothing to do with the collapsed status, same thing happends with open ones (just that there's no visual feedback about the inset being deleted/new). Seems that text insets are not change-tracked, only their content is. Is this on purpose or a known limitation? A/
RE: Re: No paragraph alignment options
Leuven, E. wrote: > so given that: > > - people don't switch document classes often (i for example never do) > - switching document layouts often involve information loss because they > do not define similar environments - case 1 & 2 are rare Let me give you another case: I often write my titles first in Standard Layout and *then* switch the layout to Title. With your approach I would have to manually center it. Awful. > i really don't see the point of cluttering the user interface for these > very small contingencies. Clutter is a big word... > i also think that > > o Justified (Default) > o Left > o Center > o Right > > will be more understandable to users who don't know latex while at the > same time it makes default explicit which is think was the starting point Is not about latex imo, is about document layouts. > imo of course... What happends if the user moves the cursor when the dialog is open, does it get updated? In any case I prefer your other proposal with Default (Justified) and all the rest. So I vote that or no change ;-) A/
Re: [patch] bug 2520: Make InsetExternal translateable
Jürgen Spitzmüller wrote: > http://bugzilla.lyx.org/show_bug.cgi?id=2520 > > The attached patch does this (I think it's the last remaining > non-translatable ui part). Any opinions on this? Jürgen
RE: RE: Re: No paragraph alignment options
Leuven, E. wrote: > Alfredo Braunstein wrote: >> Let me give you another case: I often write my titles first in Standard >> Layout and *then* switch the layout to Title. With your approach I would >> have to manually center it. Awful. > > no. > > reread what i wrote: That implies I've read it in the first place... > since default takes precedence things go fine in your example. I see. WRT the current situation, your approach tends to make things default (on layout switching) against user will, which is sort of lyx philosophy: don't care what you want, no manual formatting allowed here! ... At the end, maybe it's not so terrible. Question: what do you do if the selection consists in paragraphs with different layouts (with different defaults) >> In any case I prefer your other proposal with Default (Justified) and all >> the rest. > > i can live with that > >> So I vote that or no change ;-) Still prefer this I think. > i should remind you that it is friday I've written that smile yesterday. I keep one or two around for precaution. A/
