Re: [PATCH] Add bypass validation checkboxes to dialogs that enter listings parameters
I like the approach in general. Some comments:
- In the Listings dialog, the Bypass validation checkbox should go to
the Avanced tab. Furthermore, it lacks an accelerator and a tooltip (in all
three dialogs).
- toggling this checkbox doesn't have an immediate effect (in alle three
dialogs). You have to type something first. You'll need to add a slot
on_bypassCB_stateChanged(int state) that does the necessary things.
+ if (msg.empty())
+ return msg;
+ else
+ return bformat(_(Parameter %1$s: ),
from_utf8(name)) + msg;
return bformat(_(Parameter %1$s: %2$s), from_utf8(name), msg);
+ // otherwise, produce a meaningful error message.
+ string matching_names;
+ ListingsParams::const_iterator end = all_params_.end();
+ for (it = all_params_.begin(); it != end; ++it) {
+ if (prefixIs(it-first, name)) {
+ if (!matching_names.empty())
+ matching_names += , ;
+ matching_names += it-first;
+ }
}
+ if (matching_names.empty())
+ return bformat(_(Unknown listing parameter name:
%1$s),
+ from_utf8(n
ame));
+ else
+ return bformat(_(Parameters starting with '%1$s':
%2$s),
+ from_utf8(n
ame), from_utf8(matching_names)); }
indendation and line length (in the original patch).
Index: src/frontends/qt4/QDocument.cpp
===
--- src/frontends/qt4/QDocument.cpp (revision 18733)
+++ src/frontends/qt4/QDocument.cpp (working copy)
[...]
+ qt_(Input listings parameters on the right. Enter
? for a list of parameters.));
I think we can ditch this message completely. The same message is given as
tooltip, where it makes more sense IMHO.
Index: lib/lyx2lyx/lyx_1_5.py
===
--- lib/lyx2lyx/lyx_1_5.py (revision 18733)
+++ lib/lyx2lyx/lyx_1_5.py (working copy)
@@ -1687,10 +1687,12 @@
[268, []],
[269, []],
[270, []],
- [271, [convert_ext_font_sizes]]
+ [271, [convert_ext_font_sizes]],
+ [272, []],
]
revert = [
+ [271, [revert_preamble_listings_params, revert_listings_inset,
revert_include_listings]], [270, [revert_ext_font_sizes]],
[269, [revert_beamer_alert, revert_beamer_structure]],
[268, [revert_preamble_listings_params, revert_listings_inset,
Hm, that's not exactly what I had in mind. But if you're too lazy and José is
fine with it, I can live with that.
Jürgen
Re: Suggested improvements for LyX macros
Stefan Schimanski wrote: http://www.youtube.com/watch?v=68Gys4rp3u4 This looks pretty impressing! Jürgen
Re: [PATCH] Add bypass validation checkboxes to dialogs that enter listings parameters
- In the Listings dialog, the Bypass validation checkbox should go to the Avanced tab. Furthermore, it lacks an accelerator and a tooltip (in all three dialogs). Sorry, I know they are supposed to be easy, but I do not know qt well enough to add accelerator and tooltips. I guess you can add them once the patch is committed. :-) - toggling this checkbox doesn't have an immediate effect (in alle three dialogs). You have to type something first. You'll need to add a slot on_bypassCB_stateChanged(int state) that does the necessary things. I will have a look. +if (msg.empty()) +return msg; +else +return bformat(_(Parameter %1$s: ), from_utf8(name)) + msg; return bformat(_(Parameter %1$s: %2$s), from_utf8(name), msg); OK. +qt_(Input listings parameters on the right. Enter ? for a list of parameters.)); I think we can ditch this message completely. The same message is given as tooltip, where it makes more sense IMHO. The box is empty so why not put the hint there? revert = [ + [271, [revert_preamble_listings_params, revert_listings_inset, revert_include_listings]], [270, [revert_ext_font_sizes]], [269, [revert_beamer_alert, revert_beamer_structure]], [268, [revert_preamble_listings_params, revert_listings_inset, Hm, that's not exactly what I had in mind. But if you're too lazy and José is fine with it, I can live with that. If you want to support RC1, this is the only method. Because there is no easy way (in lyx2lyx) to tell if a parameter string is valid, we have to assume that they are invalid and use ERT in 1.5.rc1. Cheers, Bo
Re: Road to rc2
On Fri, Jun 08, 2007 at 10:40:45PM +0200, [EMAIL PROTECTED] wrote: On Fri, 8 Jun 2007, José Matos wrote: On Friday 08 June 2007 16:59:35 [EMAIL PROTECTED] wrote: In Sweden, June 22nd would be a bad choice because it's a big holiday - everybody is off. I'll be in the archipelago for instance. I'm guessing Martin might be off as well? What is the problem? If you have one more reason to celebrate... ;-) Perhaps none. I was just thinking that if many of the developers celebrate midsommar, then maybe no one will be around that weekend in case you need help with something. I guess people will hide anyway ;-) Andre'
Re: [patch] fixing segfault because of empty coord cache
On Sat, Jun 09, 2007 at 09:37:31AM +0300, Martin Vermeer wrote: On Fri, Jun 08, 2007 at 08:22:42PM +0200, Jean-Marc Lasgouttes wrote: Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Stefan Critical bugs don't get less critical by ignorance. If anybody Stefan wants to know more: [snip] Great analysis! I would say that the fix is correct, but I'd wait for Andre's input. JMarc Hear, hear. This kind of analysis should be in the code, as comment. Do I understand correctly that this presupposes that 1) every mathinset must have an isActive method and 2) it should return true only if the inset has really accessible cells? It's even in InsetBase, and something like that was the intention. Andre'
Re: [patch] fixing segfault because of empty coord cache
I can't tell you. It is conceptionally sound, however, so close to
1.5.0
it might be more prudent to use something like
The old behavior is simpler than I thought. A search for isActive
basically shows that there is no math inset (other than the
InsetMathMBox, which just return true, and InsetMathNest with nargs()
0) which overwrite the method:
BufferView.cpp: if (inset inset-isActive()) {
Cursor.cpp: if (!t-isActive())
Cursor.cpp: if (t-isActive()) {
DocIterator.cpp:if (n n-isActive()) {
insets/Inset.h: virtual bool isActive() const { return nargs() 0; }
insets/Inset.h.orig:virtual bool isActive() const { return nargs
() 0; }
mathed/InsetMathMBox.h: bool isActive() const { return true; }
mathed/InsetMathNest.cpp:bool InsetMathNest::isActive() const
mathed/InsetMathNest.h: bool isActive() const;
So isActive() is just equivalent to nargs() 0 at the place
mentioned in the patch. Hence replacing the nargs() 0 as proposed
is safe.
... !atom-isMathRefInset()
and put a fat FIXME there to ask fopr investigation in quieter times.
don't think it's necessary because of the comment above.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Re: Road to rc2 - fixIfBroken
On Sat, Jun 09, 2007 at 12:49:09PM +0200, Stefan Schimanski wrote:
It works fine (as far as I can judge after 2 minutes testing). I
added some comments and pulled apart the loop to make the control
flow easier. Alfredo, can you check please? I would be happy if we
could get rid of the signals finally like this.
Stefan
Index: lyx-devel/src/CursorSlice.cpp
===
--- lyx-devel.orig/src/CursorSlice.cpp2007-06-02 11:24:26.0
+0200
+++ lyx-devel/src/CursorSlice.cpp 2007-06-09 12:11:13.0 +0200
@@ -42,10 +42,6 @@
: inset_(p), idx_(0), pit_(0), pos_(0)
{
BOOST_ASSERT(inset_);
- boost::signalvoid() * destroyed_signal = inset_-destroyedSignal();
- if (destroyed_signal)
- inset_connection_ = destroyed_signal-connect(
- boost::bind(CursorSlice::invalidate, this));
}
@@ -55,22 +51,12 @@
}
-CursorSlice::~CursorSlice()
-{
- inset_connection_.disconnect();
-}
-
-
CursorSlice CursorSlice::operator=(CursorSlice const cs)
{
inset_ = cs.inset_;
idx_ = cs.idx_;
pit_ = cs.pit_;
pos_ = cs.pos_;
- if (inset_ inset_-destroyedSignal()) {
- inset_connection_ = inset_-destroyedSignal()-connect(
- boost::bind(CursorSlice::invalidate, this));
- }
return *this;
}
Note that probably the whole operator=() can go.
Andre'
Re: Road to rc2 - fixIfBroken
CursorSlice CursorSlice::operator=(CursorSlice const cs)
{
inset_ = cs.inset_;
idx_ = cs.idx_;
pit_ = cs.pit_;
pos_ = cs.pos_;
- if (inset_ inset_-destroyedSignal()) {
- inset_connection_ = inset_-destroyedSignal()-connect(
- boost::bind(CursorSlice::invalidate, this));
- }
return *this;
}
Note that probably the whole operator=() can go.
It already did. Look in the svn logs by me and Abdel.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Re: Windows installer Bug 3813
On Sat, 9 Jun 2007, Joost Verburg wrote: ftp.lyx.org no longer accepts the SIZE command, on which the FTP plug-in relies. Who is the administrator of this server? Joost has identified the downloading problem with windows installer. It seems that our ftp server has some uncommon settings. He will try to fix NSIS but at the same time, maybe we can adjust ftp.lyx.org. Note that Uwe's installer does not use ftp.lyx.org. Cheers, Bo
Re: [PATCH] Add bypass validation checkboxes to dialogs that enter listings parameters
Bo Peng wrote: - In the Listings dialog, the Bypass validation checkbox should go to the Avanced tab. Furthermore, it lacks an accelerator and a tooltip (in all three dialogs). Sorry, I know they are supposed to be easy, but I do not know qt well enough to add accelerator and tooltips. I guess you can add them once the patch is committed. :-) Accelerators can be added just by putting and Ampersand in the name. Bypass validation, for instance. Tooltips can be added in the designer, in the tooltip field. But I can do it if necessary. +qt_(Input listings parameters on the right. Enter ? for a list of parameters.)); I think we can ditch this message completely. The same message is given as tooltip, where it makes more sense IMHO. The box is empty so why not put the hint there? Because it's rather unusual. This is information we usually give by means of tooltips. But I don't really care much. revert = [ + [271, [revert_preamble_listings_params, revert_listings_inset, revert_include_listings]], [270, [revert_ext_font_sizes]], [269, [revert_beamer_alert, revert_beamer_structure]], [268, [revert_preamble_listings_params, revert_listings_inset, Hm, that's not exactly what I had in mind. But if you're too lazy and José is fine with it, I can live with that. If you want to support RC1, this is the only method. Because there is no easy way (in lyx2lyx) to tell if a parameter string is valid, we have to assume that they are invalid and use ERT in 1.5.rc1. I see. I forgot there's no marker anymore. OK, fine then. Cheers, Bo Jürgen
Administrator of ftp.lyx.org? (Was: Windows installer Bug 3813)
On Sun, 10 Jun 2007, Joost Verburg wrote: [EMAIL PROTECTED] wrote: On Sat, 9 Jun 2007, Joost Verburg wrote: It looks like the FTP download plug-in doesn't like the update of the FTP server software. I've contacted the author of the plug-in and will try to resolve this as soon as possible. How did you figure this out? Or is it just a guess? ftp.lyx.org no longer accepts the SIZE command, on which the FTP plug-in relies. Who is the administrator of this server? I don't know... I've forwarded this to Jean-Marc and Lars. /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: LyX document-build process
John Pye wrote: More coffee will only heighten my paranoia! Seriously, LyX is a GUI application but it makes no effort at being GUI-friendly during the document build process. It wouldn't be that hard to add a 'progress' dialog box for this stuff? With current architecture yes, a bit hard. But I personally plan to add some more feedback (note that there is some feedback already in the status bar about LateX processing numbers). Run a separate thread for the build tools and update the screen as they go? A thread is an option. A detached process is cleaner though (IMO). Both options are very feasible and you are welcome to help us ;-) I personally plan to work on the second option and Peter K. has already worked on the first option IIRC. Helps to know when images are too large or too detailed, or if something is hung, etc? Everything's possible :-) I think that this is a bug in LyX. LyX *must* be able to do this type of dependency tracking 100% correctly if it is going to attempt it at all. It is no good that it outputs the wrong document in this case. Agreed. I think that good architecture going forward might be for LyX to divest all of the build tracking stuff to an external program that specialises in dependency tracking, caching, and parallel building, and to try to re-use what others have already done in this area. Thoughts? This makes sense IMO, but as usual nothing happens by magic. Abdel.
Re: [patch] fixing segfault because of empty coord cache
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Do I understand correctly that this presupposes that 1) every mathinset must have an isActive method and 2) it should return true only if the inset has really accessible cells? Andre It's even in InsetBase, and something like that was the Andre intention. What is the difference between this and editable() == HIGHLY_EDITABLE? Do we need to have both? JMarc
Re: Suggested improvements for LyX macros
Jürgen Spitzmüller wrote: Stefan Schimanski wrote: http://www.youtube.com/watch?v=68Gys4rp3u4 This looks pretty impressing! Yes, very nice. A/
Re: Administrator of ftp.lyx.org?
christian == christian ridderstrom [EMAIL PROTECTED] writes: christian On Sun, 10 Jun 2007, Joost Verburg wrote: [EMAIL PROTECTED] wrote: On Sat, 9 Jun 2007, Joost Verburg wrote: It looks like the FTP download plug-in doesn't like the update of the FTP server software. I've contacted the author of the plug-in and will try to resolve this as soon as possible. How did you figure this out? Or is it just a guess? ftp.lyx.org no longer accepts the SIZE command, on which the FTP plug-in relies. Who is the administrator of this server? christian I don't know... I've forwarded this to Jean-Marc and Lars. Last time I had contact with them it was Tanguy Ortolo [EMAIL PROTECTED] They also seem to have an address [EMAIL PROTECTED] which may be a better bet. JMarc
Re: bug in LyX at startup: reading of ~/.lyx/session
Julien == Tribulations Parallèles [EMAIL PROTECTED] writes: Julien Hi everybody, I have encountered a bug at startup, that I have Julien localized thanks to strace. It seems that at startup, LyX Julien tries to read the file ~/.lyx/session. LyX makes a stat64 on Julien the files of the [recent files] section, and then on the Julien files of the [cursor positions] section. The permissions Julien were not granted on one of the files of the [cursor Julien positions] section (/home/httpd/coucou/html/index.lyx), and Julien I obtain: Hello, I tried to reproduce this bug, but it did not crash here. Do you still see it? Could we have a backtrace? JMarc
Re: [PATCH-again] Bug 3821: Odd middle-click behavior
Bo Peng wrote: The issue here is that middle-click of external material pastes where the cursor WAS, not where one clicks. Really? If so, it is a bug that should be fixed. The patch looks OK to me. Note that: - lyx paste to where mouse is As do almost every other graphical app . . . - many other applicate paste to where cursor is (e.g. gvim) I believe gvim do this so it won't be too different from running vim in a xterm. And vim works this way because it is a text-only app with no concept of a mouse position. It is possible for a text-only app to know about mouse positioning, but few of them try because they might be running on a mouse-less terminal. Mouse cut/paste is then a function of the terminal, not the app itself. Helge Hafting
Re: Window-independent dialogs
Stefan Schimanski wrote: Hi! Is there a reason that the non-modal dialogs (like to edit tables, change text styles etc.) depend on the LyX window? With current architecture we cannot change that not. I suggest that we number the LyX windows and we put that number in the title bar of the LyX window itself and of any child window. We could do something in 1.6 though... Abdel.
Re: Spaces on RTL boundaries
Dov Feldstern wrote: *** I now see what the problem is! What we need is *exactly* the change of format 259; but in lyx2lyx, the \\lang property wasn't included for some reason! The attached patch fixes this, and the output is now OK (i.e., with this patch, a file created from before the change (also attached), and in which the problem occurs, is output correctly and displays correctly in the GUI even now!). But anyway, for the reasons outlined above, I still think it's more correct to do this is a separate, new file format, effective as of now. Yes. I guess that means duplicating normalize_font_whitespace(), but having it now act *only* on the lang property (Georg, you may want to make sure there aren't any other forgotten properties, once we're at it...), and applying the new function as the converter to a new file format... Instead of duplicating I would factor it out into a new function that takes the attributes to look for as a parameter and then use that in the conversion functions for both formats. So Georg, does all this make sense? And if so, could you please take care of it? I guess we also need Jose's OK for this... Yes, it makes sense. It looks like I and Jose are to be blamed for forgetting the \lang attribute in lyx2lyx. Unfortunetaly I have to meet a deadline soon and no time to work on this, so somebody else has to step in. Georg
Re: EndEnvironment layout entry.
Bo Peng wrote: It is currently non-trivial to write 1. item1 1. item1 2. item2 This will be very nice to have, also for those that need several theorems in a row. Whatever the final solution will be (inset, layout, or whatever) please make sure that it also allows nested cases like: 1. item1 a) item 1a a) item 1a b) item 1b 2. item2 If it is useful on the top level, then it is useful at the deeper levels too. Helge Hafting
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Stefan Schimanski wrote: Here is a fix for the grey-bar bug, i.e. randomly only the current paragraph is drawn and everything else is greyed out. I think it is related to synthetic mouse event. Somehow a redraw is triggered, but the ViewMetric.update_strategy is set to NoScreenUpdate. The two condition, that I change in the patch, evaluate to true and the grey bars are drawn. Here is a backtrace of the issue: #0 lyx::paintText ([EMAIL PROTECTED], [EMAIL PROTECTED]) at /Users/sts/Quellen/mac/lyx-devel/src/rowpainter.cpp:1065 #1 0x0023570a in lyx::frontend::GuiWorkArea::updateScreen (this=0x261a0e30) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:592 #2 0x0023574f in lyx::frontend::GuiWorkArea::expose (this=0x261a0e30, x=0, y=31, w=671, h=105) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:575 #3 0x0022295a in lyx::frontend::WorkArea::redraw (this=0x261a0e44) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/WorkArea.cpp:159 #4 0x00223212 in lyx::frontend::WorkArea::dispatch (this=0x261a0e44, [EMAIL PROTECTED], k=none) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/WorkArea.cpp:218 #5 0x00237432 in lyx::frontend::GuiWorkArea::mouseMoveEvent (this=0x261a0e30, e=0xbfffefe0) at /Users/sts/Quellen/mac/lyx-devel/src/frontends/qt4/GuiWorkArea.cpp:414 It happened with two footnote in the view, just moving the mouse around. So could it be related to the mouse hover maybe? Looks like a good analysis. I think though that the change in the patch is reasonable nevertheless. The comparison to SingleParUpdate is wrong. The drawText function must work with every update_strategy. I think you're right Stefan and the problem is most certainly caused by a combination of mouse hover and SinglePar when the focus comes back. Abdel.
Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE
Koji Yokota wrote:
Georg Baum wrote:
If you want to debug this fdurther it might be a good idea to write a
small standalone program that simply calls boost::format with the
problematic input.
boost::basic_format() itself seems working if it is called with
ordinary strings:
#include iostream
#include boost/format.hpp
using namespace std;
main()
{
cout boost::basic_formatchar (test %1$s \n) % OK;
}
which prints out
test OK
That is expected, but does boost::basic_formatwchar_tit also do that?
And what is the value of *start? And how does the whole format string
look like?
They are as follows:
(gdb) p *start
$38 = (const wchar_t ) @0x8b1e9c0: 49
49 is the ASCII value of the character '1'. That means that wrap_narrow() is
definitely wrong here, since it should simply return the input in this case
and not -65. It also means that boost::format is probably correct, since
the 1 is a part of the format string that the code we are lloking at needs
to parse.
That means that indeed something is wrong with your locale stuff, but I
don't understand at all why this does not change if you use the replacement
facets from Enrico that definitely work for ASCII input. The only way to
track this down is to step through the wrap_narrow() function with a
debugger. Then you will eventually see where the 49 is converted to -65.
Georg
Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE
Koji Yokota wrote: So, this may have to be modified too. (gdb) p *start $38 = (const wchar_t ) @0x8b1e9c0: 49 (gdb) x/5s 0x8b1e9c0 0x8b1e9c0: 1 0x8b1e9c2: 0x8b1e9c3: 0x8b1e9c4: $ 0x8b1e9c6: 0x8b1e9c7: 0x8b1e9c8: s 0x8b1e9ca: 0x8b1e9cb: 0x8b1e9cc: \r0 0x8b1e9cf: 0x8b1e9d0: \2220 0x8b1e9d3: 0x8b1e9d4: \\O 0x8b1e9d7: 0x8b1e9d8: \020b 0x8b1e9db: 0x8b1e9dc: W0 0x8b1e9df: 0x8b1e9e0: f0 0x8b1e9e3: 0x8b1e9e4: D0 0x8b1e9e7: 0x8b1e9e8: ~0 0x8b1e9eb: where string size is (gdb) p fstring_size $54 = 25 This looks a bit strange (can gdb not print wstrings?), but it seems to be a correct format string. Georg
Re: [patch] Up/down cursor in math-macro jumps out of the macro, #3830
Stefan Schimanski wrote: Bug: http://bugzilla.lyx.org/show_bug.cgi?id=3830 The patch should be obvious. I won't dispute the obviousness of it with our macro expert ;-) Abdel.
Re: Road to rc2
Stefan Schimanski wrote: - What are the patches submitted that you think deserve attention? I would like to give special attention to critical bugs and so on... I have posted several patches which are waiting to go in or a comment why not: * [patch] sometimes only paragraph of cursor is visible, #3231 * [patch] Up/down cursor in math-macro jumps out of the macro, #3830 * [patch] fixing segfault because of empty coord cache, #3715 * [patch] lyx crashes/mutilates document using math-delimiter ( ) in hebrew text, #2446 I am OK with all of them. Abdel.
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Stefan Schimanski wrote: Here is a fix for the grey-bar bug, i.e. randomly only the current paragraph is drawn and everything else is greyed out. It'd be great if this fixed this bug. It's very annoying. Is it an OK? Have you tried it? Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: lyx farsi support??
Dear Behzad, I am trying to add Farsi support based on LaTeX2e ARABI Package. What I have done until now is that I have added the Farsi presentation (writing or shaping) to LyX. Unfortunately we need more work on ARABI package rather than LyX. Currently we have two options for LaTeX2e and Farsi: 1) ARABI 2) TeX-e-Parsi I know that TeX-e-Parsi is really better, but it has many limitations, e.g. the O.S., the editor, and the TeX engine. We have another version of Omega named Omega2 in the near future (but who guarantees). However we should try not to make LyX much dependent on ARABI package. Mostafa - Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us.
Re: [patch] lyx crashes/mutilates document using math-delimiter ( ) in hebrew text
it looks like the cursor is very rapidly put inside the inset and back outside. If I have the math panel toolbar opened (in auto mode), it flashes up shortly and disappears again. Also, the math inset itself flashes and something (which I cannot identify) pops up shortly. This is when I move the cursor with the arrow keys. Note, however, that I'm totally RTL ignorant, so I have no idea about how the cursor movement should be naturally. Can you make a bug report about this flashing? Stefan PGP.sig Description: Signierter Teil der Nachricht
Python question
In order to fix bug 2520, I need to parse the external_templates files in
lyx_pot.py.
This works, except for the HelpText. Can any Pythonist tell me how to Parse
the content between
HelpText
content (multiline)
HelpTextEnd
in the function below?
def external_l10n(input_files, output, base):
'''Generate pot file from lib/external_templates'''
output = open(output, 'w')
Template = re.compile(r'^Template\s+(.*)')
GuiName = re.compile(r'\s*GuiName\s+(.*)')
i = -1
for src in input_files:
input = open(src)
for lineno, line in enumerate(input.readlines()):
if Template.match(line):
(string,) = Template.match(line).groups()
elif GuiName.match(line):
(string,) = GuiName.match(line).groups()
-- elif HelpText???
else:
continue
string = string.replace('', '')
if string != :
print output, '#: %s:%d\nmsgid %s\nmsgstr \n' % \
(relativePath(src, base), lineno+1, string)
input.close()
output.close()
Jürgen
Re: [patch] bug 2738: Wrong sorting of languages in Document dialog
Pavel Sanda wrote: Whatever you do to solve your bug, please make sure that you don't set any new locale (at least not permanently, temporarily is OK). this patch should not interfere with other locale code. it only creates locale object, which is set to current environment locale and then is this object used as comparator between two strings. Disclaimer: I know *nothing* about locales in general, so here are some random stupid questions ;-) 1) Is it correct to use a static object? In particular, there are no modifications of the locale in LyX initialization? 2) Would it make sense to have it as a non-static member of the class, or is it expensive to build? 3) We have a std::locale object in the Messages class, would it make sense to use that instead of building a new one? A/
Re: Suggested improvements for LyX macros
On Mon, 11 Jun 2007 09:46:30 +0200 Alfredo Braunstein [EMAIL PROTECTED] wrote: Jürgen Spitzmüller wrote: Stefan Schimanski wrote: http://www.youtube.com/watch?v=68Gys4rp3u4 This looks pretty impressing! Yes, very nice. A/ A soundtrack would be nice (no, I'm not volunteering) - Martin
Layout dropdown not updated when clicking on math
#3850 To reproduce: Load the userguide. With the cursor on the title (so the layout dropdown says 'Title') scroll down (wheel or scrollbar) to some math inset and click. The layout still says 'Title'. A/
Another crash with TOC dock widget after undo
FYI: http://bugzilla.lyx.org/show_bug.cgi?id=3851 Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Another crash with TOC dock widget after undo
Stefan Schimanski wrote: FYI: http://bugzilla.lyx.org/show_bug.cgi?id=3851 First guess: looking at Undo::undoText... updateLabels(*buf) will trigger a TOC update. The cursor of the bufferview is still broken then. It is only fixed after that call. But ControlToc::getCurrentTocItem(size_t type) finally (see backtrace) uses the bufferview cursor for something. It has been proposed in a different thread that all automatic updating of the TOC be disabled by removing this call so that the update would be done only on use or request. I don't remember if there was a resolution, and Abdel should obviously speak to this. But Bo and I found, as we tried to sort out some of these bugs, that it was proving very hard to get the update done at all the right times. 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: Another crash with TOC dock widget after undo
Am 11.06.2007 um 15:06 schrieb Richard Heck: Stefan Schimanski wrote: FYI: http://bugzilla.lyx.org/show_bug.cgi?id=3851 First guess: looking at Undo::undoText... updateLabels(*buf) will trigger a TOC update. The cursor of the bufferview is still broken then. It is only fixed after that call. But ControlToc::getCurrentTocItem(size_t type) finally (see backtrace) uses the bufferview cursor for something. It has been proposed in a different thread that all automatic updating of the TOC be disabled by removing this call so that the update would be done only on use or request. I don't remember if there was a resolution, and Abdel should obviously speak to this. But Bo and I found, as we tried to sort out some of these bugs, that it was proving very hard to get the update done at all the right times. What about updating the TOC asynchronously? Don't know how to do this with the current architecture. Are there asynchronous lfuns? I.e. they are only executed from the frontend's message loop after everything (like the cursor) is valid again. Stefan PGP.sig Description: Signierter Teil der Nachricht
[patch] Another crash with TOC dock widget after undo
The obvious naive fix:
--- src/Undo.cpp(Revision 18737)
+++ src/Undo.cpp(Arbeitskopie)
@@ -164,6 +164,7 @@
// This does the actual undo/redo.
//lyxerr undo, performing: undo std::endl;
+ bool labelsUpdateNeeded = false;
DocIterator dit = undo.cell.asDocIterator(buf-inset());
if (undo.isFullBuffer) {
BOOST_ASSERT(undo.pars);
@@ -209,7 +210,7 @@
plist.insert(first, undo.pars-begin(), undo.pars-end());
delete undo.pars;
undo.pars = 0;
- updateLabels(*buf);
+ labelsUpdateNeeded = true;
}
BOOST_ASSERT(undo.pars == 0);
BOOST_ASSERT(undo.array == 0);
@@ -220,8 +221,10 @@
cur.selection() = false;
cur.resetAnchor();
cur.fixIfBroken();
+
+ if (labelsUpdateNeeded)
+ updateLabels(*buf);
finishUndo();
-
return true;
}
PGP.sig
Description: Signierter Teil der Nachricht
Re: Window-independent dialogs
Stefan Schimanski wrote: Is there a reason that the non-modal dialogs (like to edit tables, change text styles etc.) depend on the LyX window? another question (for 1.6 or later) is whether these non-modal dialogs should go and be replaced by toolbars? (some are and some aren't, it is kinda messy and i don't know many other apps that use 'em)
Re: Another crash with TOC dock widget after undo
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Stefan What about updating the TOC asynchronously? Don't know how to Stefan do this with the current architecture. Are there asynchronous Stefan lfuns? I.e. they are only executed from the frontend's message Stefan loop after everything (like the cursor) is valid again. Since label update is a view thing (nothing to do in core undo code imo), we could have a new update flag that does the update (one entry or all entries) before the matrics update. JMarc
Re: Window-independent dialogs
Am 11.06.2007 um 15:17 schrieb Edwin Leuven: Stefan Schimanski wrote: Is there a reason that the non-modal dialogs (like to edit tables, change text styles etc.) depend on the LyX window? another question (for 1.6 or later) is whether these non-modal dialogs should go and be replaced by toolbars? Yes, please. Toolbars or tool windows. (some are and some aren't, it is kinda messy and i don't know many other apps that use 'em) Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: Another crash with TOC dock widget after undo
Richard Heck wrote: Stefan Schimanski wrote: FYI: http://bugzilla.lyx.org/show_bug.cgi?id=3851 First guess: looking at Undo::undoText... updateLabels(*buf) will trigger a TOC update. The cursor of the bufferview is still broken then. It is only fixed after that call. But ControlToc::getCurrentTocItem(size_t type) finally (see backtrace) uses the bufferview cursor for something. So the solution is to delay the updateLabels() call until everything is done. It has been proposed in a different thread that all automatic updating of the TOC be disabled by removing this call so that the update would be done only on use or request. I don't remember if there was a resolution, and Abdel should obviously speak to this. But Bo and I found, as we tried to sort out some of these bugs, that it was proving very hard to get the update done at all the right times. Not very hard, see further discussion with Bo. Abdel.
Re: Another crash with TOC dock widget after undo
Am 11.06.2007 um 15:16 schrieb Abdelrazak Younes: Richard Heck wrote: Stefan Schimanski wrote: FYI: http://bugzilla.lyx.org/show_bug.cgi?id=3851 First guess: looking at Undo::undoText... updateLabels(*buf) will trigger a TOC update. The cursor of the bufferview is still broken then. It is only fixed after that call. But ControlToc::getCurrentTocItem(size_t type) finally (see backtrace) uses the bufferview cursor for something. So the solution is to delay the updateLabels() call until everything is done. It has been proposed in a different thread that all automatic updating of the TOC be disabled by removing this call so that the update would be done only on use or request. I don't remember if there was a resolution, and Abdel should obviously speak to this. But Bo and I found, as we tried to sort out some of these bugs, that it was proving very hard to get the update done at all the right times. Not very hard, see further discussion with Bo. Ok, sounds good. Hopefully before RC2? Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
On Friday 08 June 2007 04:29:16 Bo Peng wrote: The validation mechanism of InsetListingsParams is great but is not flexible to handle unrecognized parameters introduced, e.g., by a new version of the listings. The attached patch allows users to input arbitrary parameters by prefixing it with a '@' sign. @ will be removed in latex output, but reserved in lyx files. Please test. Bo Just one note, could you document this behaviour somewhere (probably near the listing documentation)? Else this will be equivalent to black magic. :-) -- José Abílio
Re: Close tab button
On Friday 08 June 2007 20:51:28 Peter Kümmel wrote: Jose, please tell me when I could put it in. Go on. Peter -- José Abílio
Re: [patch] bug 3510: make IEEEtran template compilable
On Saturday 09 June 2007 07:41:52 Jürgen Spitzmüller wrote: OK to apply? OK. Jürgen -- José Abílio
Re: Another crash with TOC dock widget after undo
Jean-Marc Lasgouttes wrote: Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Stefan What about updating the TOC asynchronously? Don't know how to Stefan do this with the current architecture. Are there asynchronous Stefan lfuns? I.e. they are only executed from the frontend's message Stefan loop after everything (like the cursor) is valid again. Since label update is a view thing (nothing to do in core undo code imo), we could have a new update flag that does the update (one entry or all entries) before the matrics update. Yes but not now! I can't believe it's me who is saying this ;-) Abdel.
Re: [patch] Another crash with TOC dock widget after undo
Stefan Schimanski wrote: The obvious naive fix: Simple is beautiful and most of time correct. I'm sure it is this time ;-) Abdel.
Re: Window-independent dialogs
Edwin Leuven wrote: Stefan Schimanski wrote: Is there a reason that the non-modal dialogs (like to edit tables, change text styles etc.) depend on the LyX window? another question (for 1.6 or later) is whether these non-modal dialogs should go and be replaced by toolbars? We should definitely cleanup the dialogs in 1.6 (or 1.5.x). My opinion is that any dialog that aims to stay a dialog should be a modal dialog. All the others should be converted to DockWidget (so that those really preferring them as dialog can still use them this way by detaching them) or toolbars indeed. Abdel.
Re: Layout dropdown not updated when clicking on math
Alfredo Braunstein wrote:
#3850
To reproduce:
Load the userguide. With the cursor on the title (so the layout dropdown
says 'Title') scroll down (wheel or scrollbar) to some math inset and
click. The layout still says 'Title'.
Does this patch solves the problem?
This layout handling with the global current_layout variable is a *mess*.
Abdel.
Index: LyXView.cpp
===
--- LyXView.cpp (revision 18723)
+++ LyXView.cpp (working copy)
@@ -403,12 +403,9 @@
}
BOOST_ASSERT(work_area_);
- if (work_area_-bufferView().cursor().inMathed())
- return;
+ string const layout = work_area_-bufferView().cursor().
+ innerParagraph().layout()-name();
- string const layout =
- work_area_-bufferView().cursor().paragraph().layout()-name();
-
if (layout != current_layout) {
toolbars_-setLayout(layout);
current_layout = layout;
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
Just one note, could you document this behaviour somewhere (probably near the listing documentation)? Else this will be equivalent to black magic. :-) This approach has been ditched. Another patch, which adds 'pass validation' check boxes, is proposed. Cheers, Bo
Re: [PATCH] Allow parameters to bypass InsetListingsParams validation.
On Monday 11 June 2007 15:26:01 Bo Peng wrote: This approach has been ditched. Another patch, which adds 'pass validation' check boxes, is proposed. I only read this later and MUA does not have any function to recall sent messages. ;-) Cheers, Bo -- José Abílio
Re: Layout dropdown not updated when clicking on math
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Alfredo Braunstein wrote: #3850 To reproduce: Load the userguide. With the cursor on the title (so the layout dropdown says 'Title') scroll down (wheel or scrollbar) to some math inset and click. The layout still says 'Title'. Abdelrazak Does this patch solves the problem? Looks good. Abdelrazak This layout handling with the global current_layout Abdelrazak variable is a *mess*. I was not even aware of this 'feature' (which is not to blame in this particular case, right?). It should probably be just removed. BTW the bug is also in 1.4. JMarc
Re: Another crash with TOC dock widget after undo
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Since label update is a view thing (nothing to do in core undo code imo), we could have a new update flag that does the update (one entry or all entries) before the matrics update. Abdelrazak Yes but not now! Yes, sure. Abdelrazak I can't believe it's me who is saying this ;-) Especially since the other option is to disable this automatic renumbering for now... JMarc
Re: Layout dropdown not updated when clicking on math
Abdelrazak Younes wrote: Alfredo Braunstein wrote: #3850 To reproduce: Load the userguide. With the cursor on the title (so the layout dropdown says 'Title') scroll down (wheel or scrollbar) to some math inset and click. The layout still says 'Title'. Does this patch solves the problem? I've tested it in the mean time and it fixes the problem. OK? Abdel.
Re: Administrator of ftp.lyx.org?
On Mon, 11 Jun 2007, Jean-Marc Lasgouttes wrote: christian == christian ridderstrom [EMAIL PROTECTED] writes: christian On Sun, 10 Jun 2007, Joost Verburg wrote: [EMAIL PROTECTED] wrote: On Sat, 9 Jun 2007, Joost Verburg wrote: It looks like the FTP download plug-in doesn't like the update of the FTP server software. I've contacted the author of the plug-in and will try to resolve this as soon as possible. How did you figure this out? Or is it just a guess? ftp.lyx.org no longer accepts the SIZE command, on which the FTP plug-in relies. Who is the administrator of this server? christian I don't know... I've forwarded this to Jean-Marc and Lars. Last time I had contact with them it was Tanguy Ortolo [EMAIL PROTECTED] They also seem to have an address [EMAIL PROTECTED] which may be a better bet. Do you think it's koscher to place these names and e-mail adresses on the wiki for future reference? I could put them in a page that requires a password to read. (Not that I can read the addresses right now, gmane has encrypted them... :-) /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Layout dropdown not updated when clicking on math
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Alfredo Braunstein wrote: #3850 To reproduce: Load the userguide. With the cursor on the title (so the layout dropdown says 'Title') scroll down (wheel or scrollbar) to some math inset and click. The layout still says 'Title'. Abdelrazak Does this patch solves the problem? Looks good. Abdelrazak This layout handling with the global current_layout Abdelrazak variable is a *mess*. I was not even aware of this 'feature' (which is not to blame in this particular case, right?). Right. It should probably be just removed. I'll probably do that after I commit the above fix. BTW the bug is also in 1.4. I cannot help you there sorry. Abdel.
Re: Administrator of ftp.lyx.org?
christian == christian ridderstrom [EMAIL PROTECTED] writes: christian Do you think it's koscher to place these names and e-mail christian adresses on the wiki for future reference? I could put them christian in a page that requires a password to read. (Not that I can christian read the addresses right now, gmane has encrypted them... christian :-) Now that I sent them to the list, I guess they are ripe for spamming :( Note that I have no idea whether the address [EMAIL PROTECTED] is correct, I just saw it on a cc:. JMarc
Re: Layout dropdown not updated when clicking on math
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: It should probably be just removed. Abdelrazak I'll probably do that after I commit the above fix. I just checked that this variable was already there in the first version of the svn/cvs in 1999. BTW the bug is also in 1.4. Abdelrazak I cannot help you there sorry. I could do it, but I feel lazy for such a small thing. But it is good that you did it. JMarc
Re: Layout dropdown not updated when clicking on math
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: It should probably be just removed. Abdelrazak I'll probably do that after I commit the above fix. I just checked that this variable was already there in the first version of the svn/cvs in 1999. BTW the bug is also in 1.4. Abdelrazak I cannot help you there sorry. I could do it, but I feel lazy for such a small thing. But it is good that you did it. I said I _cannot_ help you with 1.4, so sorry, you'll have to do it :-) Abdel.
Re: Layout dropdown not updated when clicking on math
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: I could do it, but I feel lazy for such a small thing. But it is good that you did it. Abdelrazak I said I _cannot_ help you with 1.4, so sorry, you'll have Abdelrazak to do it :-) I understood what you said. I just said the problem is too small to worry about it in 1.4, but it is nevertheless good to see it fixed in 1.5. Actually I checked 1.4 just to have a feeling of whether it was a new thing or not. So all is well :) JMarc
Re: [patch] bug 3510: make IEEEtran template compilable
On Sat, Jun 09, 2007 at 08:41:52AM +0200, Jürgen Spitzmüller wrote:
http://bugzilla.lyx.org/show_bug.cgi?id=3510
The problem is an interference of newer babel bundles with the way \markboth
is defined (if \markboth is defined after babel, babel somehow gets the
language in uppercase and complains about an unknown language ENGLISH).
The only solution I know (besides not calling babel) is to define \markboth
before babel, i.e. do not use the MarkBoth paragraph style (which is somewhat
awkward anyway) but define \markboth in preamble.
I did this in the template, which compiles again here. Looks like the
IEEEtran layout would need some overhaul in general, but I won't do that.
Sorry for stepping in so late, but I think that it is useful to directly
see on screen the info provided by MarkBoth. I had already solved the
bug but forgot to share the solution. Shame on me.
I propose to add the following to the preamble:
% Note: the following fixes a bug with older versions of babel
% http://www.latex-project.org/cgi-bin/ltxbugs2html?pr=babel/3238
\DeclareRobustCommand{\FOREIGNLANGUAGE}[1]{\lowercase{\foreignlanguage{#1}}}
% More recent babel versions already have the above definition, but introduce
% yet another related bug. Using these versions, when you change the language,
% you have to accordingly substitute both 'ENGLISH' and 'english' below.
[EMAIL PROTECTED]@english
See the attached sample .lyx file. A drawback is that when changing the
document language to something else than english, say american, one
has to update the above line to read
[EMAIL PROTECTED]@american
but maybe it is better than having to write the \markboth command
in the preamble.
I didn't try hard to find an automatic solution along the lines of the
\DeclareRobustCommand above, but I really don't have time to go
through the babel code. Maybe someone else could do it.
Josè, let me know if you prefer the solution above to having \markboth
in the preamble.
--
Enrico
#LyX 1.4.4 created this file. For more info see http://www.lyx.org/
\lyxformat 245
\begin_document
\begin_header
\textclass IEEEtran
\begin_preamble
% Note: the following fixes a bug with older versions of babel
% http://www.latex-project.org/cgi-bin/ltxbugs2html?pr=babel/3238
\DeclareRobustCommand{\FOREIGNLANGUAGE}[1]{\lowercase{\foreignlanguage{#1}}}
% More recent babel versions already have the above definition, but introduce
% yet another related bug. Using these versions, when you change the language,
% you have to accordingly substitute both 'ENGLISH' and 'english' below.
[EMAIL PROTECTED]@english
\end_preamble
\language english
\inputencoding default
\fontscheme default
\graphics default
\float_placement tbh
\paperfontsize default
\spacing single
\papersize default
\use_geometry false
\use_amsmath 0
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\papercolumns 2
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\end_header
\begin_body
\begin_layout Title
Your Title: And maybe a bit extra
\end_layout
\begin_layout Author
\begin_inset Note Note
status collapsed
\begin_layout Standard
Remember that initial submissions don't show the authors
\end_layout
\begin_layout Standard
names so you'll need to make this a 'Comment'.
\end_layout
\end_inset
Your Name, Your Co-Author
\begin_inset Foot
status collapsed
\begin_layout Standard
Your name is with xyz Department\SpecialChar \ldots{}
\end_layout
\end_inset
\end_layout
\begin_layout Abstract
This paper presents a simple template for IEEEtran documents.
\end_layout
\begin_layout Keywords
simplicity, beauty, elegance
\end_layout
\begin_layout MarkBoth
This is for left pages
\begin_inset ERT
status collapsed
\begin_layout Standard
}{
\end_layout
\end_inset
and this is for right pages
\end_layout
\begin_layout Section
Introduction
\begin_inset Note Note
status collapsed
\begin_layout Standard
Don't panic the section numbering may look different in
\end_layout
\begin_layout Standard
LyX but LaTeX uses the correct Roman numerals and
\end_layout
\begin_layout Standard
Alpha for section counters.
\end_layout
\begin_layout Standard
It's just that LyX doesn't handle counters other than arabic
\end_layout
\begin_layout Standard
numerals.
\end_layout
\end_inset
\end_layout
\begin_layout Standard
\begin_inset ERT
status collapsed
\begin_layout Standard
\backslash
PARstart{T}{here}
\end_layout
\end_inset
is a need for a little Evil Red Text in the first paragraph.
Refer to the IEEEtran documentation (sample document) for more details.
\end_layout
\begin_layout Section
Previous Work
\end_layout
\begin_layout Standard
This is only a template remember.
\end_layout
\begin_layout Section
Methodology
\end_layout
\begin_layout Theorem
\begin_inset ERT
status collapsed
\begin_layout Standard
[
\end_layout
\end_inset
Theorem name
Re: Layout dropdown not updated when clicking on math
Abdelrazak Younes wrote: Alfredo Braunstein wrote: #3850 To reproduce: Load the userguide. With the cursor on the title (so the layout dropdown says 'Title') scroll down (wheel or scrollbar) to some math inset and click. The layout still says 'Title'. Does this patch solves the problem? This layout handling with the global current_layout variable is a *mess*. Yes it does, and the patch looks good. ;-) A/
Re: Layout dropdown not updated when clicking on math
Alfredo Braunstein wrote: Abdelrazak Younes wrote: Alfredo Braunstein wrote: #3850 To reproduce: Load the userguide. With the cursor on the title (so the layout dropdown says 'Title') scroll down (wheel or scrollbar) to some math inset and click. The layout still says 'Title'. Does this patch solves the problem? This layout handling with the global current_layout variable is a *mess*. Yes it does, and the patch looks good. ;-) OK, committed. Abdel.
Re: [PATCH] Change default mathbg and add mathhoverbg.
Bo == Bo Peng [EMAIL PROTECTED] writes: Yes, but if you have to move your mouse over all the document to find such places, it is kind of boring... Bo As I have said, I would not bother with this math hover business Bo if a non-background mathbg is acceptable. Bo This feature does help the $x^2$is case. But if people really want to know what is happening, they have instant preview. With this on, there is no confusion IMO. JMarc
Re: [PATCH] Change default mathbg and add mathhoverbg.
Bo This feature does help the $x^2$is case. But if people really want to know what is happening, they have instant preview. With this on, there is no confusion IMO. I agree with you here. There is no additional pixels around previewed formulas. BTW, mouse hovering does not work for previewed formulas so it can not help the $\ $ cases. I can draw lyx formulas (instead of previewed ones) for mathed under mouse, if people are positive about this. Bo
Re: [patch] bug 3510: make IEEEtran template compilable
Enrico Forestieri wrote:
Sorry for stepping in so late, but I think that it is useful to directly
see on screen the info provided by MarkBoth. I had already solved the
bug but forgot to share the solution. Shame on me.
No problem.
I propose to add the following to the preamble:
% Note: the following fixes a bug with older versions of babel
% http://www.latex-project.org/cgi-bin/ltxbugs2html?pr=babel/3238
\DeclareRobustCommand{\FOREIGNLANGUAGE}[1]{\lowercase{\foreignlanguage{#1}}
}
Of course, this lowercase solution fails for any language that has a capital
in the name (currently only USenglish and UKenglish, so maybe just a
theroretical problem).
% More recent babel versions already have the above definition, but
introduce % yet another related bug. Using these versions, when you change
the language, % you have to accordingly substitute both 'ENGLISH' and
'english' below. [EMAIL PROTECTED]@english
See the attached sample .lyx file. A drawback is that when changing the
document language to something else than english, say american, one
has to update the above line to read
[EMAIL PROTECTED]@american
but maybe it is better than having to write the \markboth command
in the preamble.
I didn't try hard to find an automatic solution along the lines of the
\DeclareRobustCommand above, but I really don't have time to go
through the babel code. Maybe someone else could do it.
Josè, let me know if you prefer the solution above to having \markboth
in the preamble.
A general problem I see is the following: I assume (but I'm not sure)
IEEETran.cls is mostly used by people who actually want to submit a LaTeX
file to an IEEE journal. In this case it might be relevant that your solution
produces a significantly uglier LaTeX file just for the sake of displaying
MakeBoth on screen. I'm not sure if this is worth it.
If you think it is, then I suggest to add the preamble definitions to the
MarkBoth definition in the layout file, so that it is only inserted if
MarkBoth is actually used. And then document the pros and cons of both
solutions, especially for people who want to submit their file to a journal.
Jürgen
Re: [PATCH] Change default mathbg and add mathhoverbg.
Bo Peng wrote: Bo This feature does help the $x^2$is case. But if people really want to know what is happening, they have instant preview. With this on, there is no confusion IMO. I agree with you here. There is no additional pixels around previewed formulas. BTW, mouse hovering does not work for previewed formulas so it can not help the $\ $ cases. I can draw lyx formulas (instead of previewed ones) for mathed under mouse, if people are positive about this. It would be nice if optional but please, could you wait until 1.5.1? Abdel.
Re: [PATCH] Change default mathbg and add mathhoverbg.
It would be nice if optional but please, could you wait until 1.5.1? You already see how many people dislike mathed mouse hovering so I am not motivated to do this any time soon. Cheers, Bo
Re: [PATCH] Change default mathbg and add mathhoverbg.
On Mon, Jun 11, 2007 at 11:56:42AM -0500, Bo Peng wrote: Bo This feature does help the $x^2$is case. But if people really want to know what is happening, they have instant preview. With this on, there is no confusion IMO. I agree with you here. There is no additional pixels around previewed formulas. BTW, mouse hovering does not work for previewed formulas so it can not help the $\ $ cases. I can draw lyx formulas (instead of previewed ones) for mathed under mouse, if people are positive about this. Yes, please. I would also like to have red Sections, blue Subsections and everything else rapidly flashing when hovering. -- Enrico
Re: [PATCH] Change default mathbg and add mathhoverbg.
Yes, please. I would also like to have red Sections, blue Subsections and everything else rapidly flashing when hovering. +1 -1 = 0, more input is need to start the engine. :-) Bo
Re: [PATCH] Change default mathbg and add mathhoverbg.
Enrico Forestieri wrote: On Mon, Jun 11, 2007 at 11:56:42AM -0500, Bo Peng wrote: Bo This feature does help the $x^2$is case. But if people really want to know what is happening, they have instant preview. With this on, there is no confusion IMO. I agree with you here. There is no additional pixels around previewed formulas. BTW, mouse hovering does not work for previewed formulas so it can not help the $\ $ cases. I can draw lyx formulas (instead of previewed ones) for mathed under mouse, if people are positive about this. Yes, please. I would also like to have red Sections, blue Subsections and everything else rapidly flashing when hovering. Patch? ;-) A/
Re: [PATCH] Change default mathbg and add mathhoverbg.
+1 -1 = 0, more input is need to start the engine. :-)
Actually, creating a patch is easier than putting it through, at least
in this case.
Index: src/mathed/InsetMathHull.cpp
===
--- src/mathed/InsetMathHull.cpp(revision 18740)
+++ src/mathed/InsetMathHull.cpp(working copy)
@@ -335,7 +335,7 @@
void InsetMathHull::draw(PainterInfo pi, int x, int y) const
{
- use_preview_ = previewState(pi.base.bv);
+ use_preview_ = previewState(pi.base.bv) !mouseHovered();
// background of mathed under focus is not painted because
// selection at the top level of nested inset is difficult to handle.
Cheers,
Bo
Re: [PATCH] Change default mathbg and add mathhoverbg.
Jean-Marc Lasgouttes wrote: Edwin == Leuven, E [EMAIL PROTECTED] writes: Edwin typically when ui elements highlight/change color on mouse Edwin focus suggests that a click will trigger an action. this is not Edwin the case here, so i am therefore not so happy with this commit: This is very true. Edwin i addition it gives confusing situation like the one where the Edwin cursor is in a math inset and the mouse pointer is over another Edwin one. then both seem to have focus! This too. btw, what has been decided here?
Re: Crashing when pressing enter...
using my windows machine instead. But that is not why I am writing. I am writing because I get a consistent crash when I try to press enter to insert a new line in a paragraph. I've kept the file. I don't want one crash-bug after enter was recently fixed. if it still persist after rc2 urge it here again :) pavel
Re: [PATCH] Change default mathbg and add mathhoverbg.
On 6/11/07, Edwin Leuven [EMAIL PROTECTED] wrote: Jean-Marc Lasgouttes wrote: Edwin == Leuven, E [EMAIL PROTECTED] writes: Edwin typically when ui elements highlight/change color on mouse Edwin focus suggests that a click will trigger an action. this is not Edwin the case here, so i am therefore not so happy with this commit: This is very true. Edwin i addition it gives confusing situation like the one where the Edwin cursor is in a math inset and the mouse pointer is over another Edwin one. then both seem to have focus! This too. btw, what has been decided here? Nothing. Jose has been busy. Bo
Re: [PATCH] Add bypass validation checkboxes to dialogs that enter listings parameters
Bo Peng wrote:
I think we only need to support official releases, but if you insist,
I will do something with lyx2lyx.
Attached please find an updated patch with lyx2lyx support for RC1.
OK to apply?
if there is going to be a fileformat change afterall, then it would be
nice to have cline support...
Index: src/frontends/controllers/ControlTabular.cpp
===
--- src/frontends/controllers/ControlTabular.cpp (revision 18739)
+++ src/frontends/controllers/ControlTabular.cpp (working copy)
@@ -83,24 +83,6 @@
}
-void ControlTabular::toggleTopLine()
-{
- if (tabular().isMultiColumn(getActiveCell()))
- set(Tabular::M_TOGGLE_LINE_TOP);
- else
- set(Tabular::TOGGLE_LINE_TOP);
-}
-
-
-void ControlTabular::toggleBottomLine()
-{
- if (tabular().isMultiColumn(getActiveCell()))
- set(Tabular::M_TOGGLE_LINE_BOTTOM);
- else
- set(Tabular::TOGGLE_LINE_BOTTOM);
-}
-
-
void ControlTabular::toggleLeftLine()
{
if (tabular().isMultiColumn(getActiveCell()))
Index: src/frontends/controllers/ControlTabular.h
===
--- src/frontends/controllers/ControlTabular.h (revision 18739)
+++ src/frontends/controllers/ControlTabular.h (working copy)
@@ -47,8 +47,6 @@
void set(Tabular::Feature, std::string const arg = std::string());
/// borders
- void toggleTopLine();
- void toggleBottomLine();
void toggleLeftLine();
void toggleRightLine();
Index: src/frontends/qt4/QTabular.cpp
===
--- src/frontends/qt4/QTabular.cpp (revision 18739)
+++ src/frontends/qt4/QTabular.cpp (working copy)
@@ -257,14 +257,14 @@
void QTabularDialog::topBorder_changed()
{
- form_-controller().toggleTopLine();
+ form_-controller().set(Tabular::TOGGLE_LINE_TOP);
form_-changed();
}
void QTabularDialog::bottomBorder_changed()
{
- form_-controller().toggleBottomLine();
+ form_-controller().set(Tabular::TOGGLE_LINE_BOTTOM);
form_-changed();
}
@@ -598,8 +598,8 @@
if (!isMulticolumnCell) {
dialog_-borders-setLeftEnabled(true);
dialog_-borders-setRightEnabled(true);
- dialog_-borders-setTop(tabular.topLine(cell, true));
- dialog_-borders-setBottom(tabular.bottomLine(cell, true));
+ dialog_-borders-setTop(tabular.topLine(cell));
+ dialog_-borders-setBottom(tabular.bottomLine(cell));
dialog_-borders-setLeft(tabular.leftLine(cell, true));
dialog_-borders-setRight(tabular.rightLine(cell, true));
// repaint the setborder widget
Index: src/insets/InsetTabular.cpp
===
--- src/insets/InsetTabular.cpp (revision 18739)
+++ src/insets/InsetTabular.cpp (working copy)
@@ -132,8 +132,6 @@
{ Tabular::VALIGN_TOP, valign-top },
{ Tabular::VALIGN_BOTTOM, valign-bottom },
{ Tabular::VALIGN_MIDDLE, valign-middle },
- { Tabular::M_TOGGLE_LINE_TOP, m-toggle-line-top },
- { Tabular::M_TOGGLE_LINE_BOTTOM, m-toggle-line-bottom },
{ Tabular::M_TOGGLE_LINE_LEFT, m-toggle-line-left },
{ Tabular::M_TOGGLE_LINE_RIGHT, m-toggle-line-right },
{ Tabular::M_ALIGN_LEFT, m-align-left },
@@ -490,9 +488,9 @@
multicolumn(Tabular::CELL_NORMAL),
alignment(LYX_ALIGN_CENTER),
valignment(LYX_VALIGN_TOP),
- top_line(true),
+ top_line(false),
bottom_line(false),
- left_line(true),
+ left_line(false),
right_line(false),
usebox(BOX_NONE),
rotate(false),
@@ -549,7 +547,7 @@
Tabular::rowstruct::rowstruct()
: ascent_of_row(0),
descent_of_row(0),
- top_line(true),
+ top_line(false),
bottom_line(false),
top_space_default(false),
bottom_space_default(false),
@@ -565,7 +563,7 @@
Tabular::columnstruct::columnstruct()
: alignment(LYX_ALIGN_CENTER),
valignment(LYX_VALIGN_TOP),
- left_line(true),
+ left_line(false),
right_line(false),
width_of_column(0)
{
@@ -599,14 +597,21 @@
column_info.reserve(10);
cell_info.reserve(100);
fixCellNums();
- for (row_type i = 0; i rows_; ++i)
- cell_info[i].back().right_line = true;
- row_info.back().bottom_line = true;
- row_info.front().bottom_line = true;
- column_info.back().right_line = true;
is_long_tabular = false;
rotate = false;
use_booktabs = false;
+ // set silly default lyx tabular lines
+ row_info.front().bottom_line = true;
+ row_info.back().bottom_line = true;
+ column_info.back().right_line = true;
+ for (row_type i = 0; i rows_; ++i) {
+ row_info[i].top_line = true;
+ for (col_type j = 0; j columns_; ++j) {
+ column_info[j].left_line = true;
+ cell_info[i][j].top_line = row_info[i].top_line;
+ cell_info[i][j].bottom_line = row_info[i].bottom_line;
+ }
+ }
}
@@ -620,7 +625,6 @@
cell_info[i][j].inset-setDrawFrame(false);
cell_info[i][j].cellno = cellno++;
}
- cell_info[i].back().right_line = true;
}
set_row_column_number_info();
@@ -813,21 +817,21 @@
}
-bool Tabular::topLine(idx_type const cell, bool const wholerow) const
+bool
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Alfredo Braunstein wrote: Abdelrazak Younes wrote: Stefan Schimanski wrote: It happened with two footnote in the view, just moving the mouse around. So could it be related to the mouse hover maybe? Looks like a good analysis. I think though that the change in the patch is reasonable nevertheless. The comparison to SingleParUpdate is wrong. The drawText function must work with every update_strategy. I think you're right Stefan and the problem is most certainly caused by a combination of mouse hover and SinglePar when the focus comes back. SingleParUpdate? I thought it was about NoUpdate. But shouldn't we just return when vi.update_strategy == NoUpdate? And why are we calling paintText in the first place? The problem is that, when mouse hovering, no text painting should be needed, only background. But, because of current architectur where text is drawn _after_ background, we are forced to do the text painting. Changing this (using text on transparent background painting) basically needs a rewrite of rowpainter hence a 1.6 business). Now, in case when mouse hovering hapens just after a SinglePar update and at the same screen location, grey areas are drawn before and after the current paragraph. I am not sure I am clear... Sorry if the questions don't make much sense, it's a long time I don't look at this part of the code... ;-) No surprise really because this part of the code has been rewritten since you left ;-) Abdel.
Re: [PATCH] Add bypass validation checkboxes to dialogs that enter listings parameters
Attached please find an updated patch with lyx2lyx support for RC1. OK to apply? if there is going to be a fileformat change afterall, then it would be nice to have cline support... Am I missing anything? I do not see any lyx2lyx part in your patch... BTW, I have no opinion on whether or not your patch should go in. I have wasted too much time in pushing my patches in and it seems wiser just let Jose make the decision. :-) Bo
Re: [patch] sometimes only paragraph of cursor is visible, #3231
The problem is that, when mouse hovering, no text painting should be needed, only background. But, because of current architectur where text is drawn _after_ background, we are forced to do the text painting. Changing this (using text on transparent background painting) basically needs a rewrite of rowpainter hence a 1.6 business). Now, in case when mouse hovering hapens just after a SinglePar update and at the same screen location, grey areas are drawn before and after the current paragraph. I am not sure I am clear... No. :-) But I have not experienced this bug for a day after I applied the patch, so I guess the patch (and your analysis) is correct. Bo
Re: [patch] fixing segfault because of empty coord cache
On Mon, Jun 11, 2007 at 08:56:45AM +0200, Stefan Schimanski wrote:
I can't tell you. It is conceptionally sound, however, so close to
1.5.0
it might be more prudent to use something like
The old behavior is simpler than I thought. A search for isActive
basically shows that there is no math inset (other than the
InsetMathMBox, which just return true, and InsetMathNest with nargs()
0) which overwrite the method:
BufferView.cpp: if (inset inset-isActive()) {
Cursor.cpp: if (!t-isActive())
Cursor.cpp: if (t-isActive()) {
DocIterator.cpp:if (n n-isActive()) {
insets/Inset.h: virtual bool isActive() const { return nargs() 0; }
insets/Inset.h.orig:virtual bool isActive() const { return nargs
() 0; }
mathed/InsetMathMBox.h: bool isActive() const { return true; }
mathed/InsetMathNest.cpp:bool InsetMathNest::isActive() const
mathed/InsetMathNest.h: bool isActive() const;
So isActive() is just equivalent to nargs() 0 at the place
mentioned in the patch. Hence replacing the nargs() 0 as proposed
is safe.
... !atom-isMathRefInset()
and put a fat FIXME there to ask fopr investigation in quieter times.
don't think it's necessary because of the comment above.
Ok then.
Andre'
Re: [PATCH] Add bypass validation checkboxes to dialogs that enter listings parameters
Bo Peng wrote: Attached please find an updated patch with lyx2lyx support for RC1. OK to apply? if there is going to be a fileformat change afterall, then it would be nice to have cline support... Am I missing anything? I do not see any lyx2lyx part in your patch... sharp as a razor (as always ;-) and unfortunately i don't speak a word of python, but it was decided that there wouldn't be a file format change before 1.5 anymore. since there now seems to be one afterall i was hoping that this could go in (with a little help from a python guru) since this is a glaring omission in our table support i have been using this for the last couple of weeks with no problems whatsoever BTW, I have no opinion on whether or not your patch should go in. I have wasted too much time in pushing my patches in and it seems wiser just let Jose make the decision. :-) the gladiator gave all he had to give. all eyes are fixed on caesar now...
Re: [patch] fixing segfault because of empty coord cache
On Mon, Jun 11, 2007 at 09:47:13AM +0200, Jean-Marc Lasgouttes wrote: Andre == Andre Poenitz [EMAIL PROTECTED] writes: Do I understand correctly that this presupposes that 1) every mathinset must have an isActive method and 2) it should return true only if the inset has really accessible cells? Andre It's even in InsetBase, and something like that was the Andre intention. What is the difference between this and editable() == HIGHLY_EDITABLE? Historically isActive() was math and HIGHLY_EDITABLE was text. Do we need to have both? Not very likely ;-) Andre'
Re: [patch] KeyMap bug (again)
Jean-Marc Lasgouttes wrote: Dov == Dov Feldstern [EMAIL PROTECTED] writes: Dov Ok, here's an attempt to do something similar to what you Dov suggested: Dov *) I added this new translateAndInsert to BufferView, not to Dov Intl. First of all, Intl seems to be very specific to only Dov manipulating the KeyMap; also, adding translateAndInsert would Dov have required adding some #includes to Intl (which, as Andre' Dov pointed out a few weeks ago, is an indication that perhaps this Dov is the wrong place to put the new function). Very good. Dov *) Someone should test that the accents really work, I don't even Dov know how to input the accents. Hebrew seems to be working fine, Dov however. I do not know either. Dov If this gets the OKs, could someone please commit (I don't have Dov access)? At least the structure looks fine to me. I think this patch is safe. JMarc It would be good if someone who knows how to use accents would check this patch (for http://bugzilla.lyx.org/show_bug.cgi?id=3811), but it should work... Jose, since this is slightly different than what you last OKed --- is this still OK to commit? Thanks! Dov
Re: [patch] bug 3510: make IEEEtran template compilable
On Mon, Jun 11, 2007 at 06:57:07PM +0200, Jürgen Spitzmüller wrote: A general problem I see is the following: I assume (but I'm not sure) IEEETran.cls is mostly used by people who actually want to submit a LaTeX file to an IEEE journal. In this case it might be relevant that your solution produces a significantly uglier LaTeX file just for the sake of displaying MakeBoth on screen. I'm not sure if this is worth it. On second thoughts, I think I agree with you, even if one have nonetheless to edit the latex file in order to trim other things lyx puts in the preamble. If you think it is, then I suggest to add the preamble definitions to the MarkBoth definition in the layout file, so that it is only inserted if MarkBoth is actually used. And then document the pros and cons of both solutions, especially for people who want to submit their file to a journal. Well, either we remove the MarkBoth environment or actually add code to the preamble in order to avoid a latex failure when someone uses MarkBoth in the document without disabling babel. Also take into account the fact that one may have old files using the IEEEtran class with MarkBoth, and it is a real nuisance having to disable babel. I don't think removing MarkBoth is feasible without breaking those old documents (without a format change?), so maybe your solution could be complemented with mine but modified as you suggest, i.e., adding the preamble stuff to the MarkBoth definition in the layout file. In this way, using \markboth in the preamble is encouraged, but MarkBoth in the document is still possible. -- Enrico
Re: [Cvslog] r18724 - in /lyx-devel/trunk/src: insets/Inset.h insets/I...
On Sat, Jun 09, 2007 at 01:08:46PM -, [EMAIL PROTECTED] wrote:
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/mathed/InsetMathNest.h?rev=18724
==
--- lyx-devel/trunk/src/mathed/InsetMathNest.h (original)
+++ lyx-devel/trunk/src/mathed/InsetMathNest.h Sat Jun 9 15:08:44 2007
@@ -28,7 +28,7 @@
/// nestinsets have a fixed size to start with
explicit InsetMathNest(idx_type ncells);
///
- virtual ~InsetMathNest() { destroyed(); }
+ virtual ~InsetMathNest() {}
Could go entirely, it's already virtual in InsetBase.
Andre'
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Abdelrazak Younes wrote: Alfredo Braunstein wrote: Abdelrazak Younes wrote: Stefan Schimanski wrote: It happened with two footnote in the view, just moving the mouse around. So could it be related to the mouse hover maybe? Looks like a good analysis. I think though that the change in the patch is reasonable nevertheless. The comparison to SingleParUpdate is wrong. The drawText function must work with every update_strategy. I think you're right Stefan and the problem is most certainly caused by a combination of mouse hover and SinglePar when the focus comes back. SingleParUpdate? I thought it was about NoUpdate. But shouldn't we just return when vi.update_strategy == NoUpdate? And why are we calling paintText in the first place? The problem is that, when mouse hovering, no text painting should be needed, only background. But, because of current architectur where text is drawn _after_ background, we are forced to do the text painting. Changing this (using text on transparent background painting) basically needs a rewrite of rowpainter hence a 1.6 business). Ok. Now, in case when mouse hovering hapens just after a SinglePar update and at the same screen location, grey areas are drawn before and after the current paragraph. I am not sure I am clear... Not completely, but thanks a lot anyway. So, why the NoUpdate flag if the background is to be repainted? And then, if NoUpdate still repaints the background, why do we have the grey areas bug, are vi.y1 and vi.y2 wrong for some reason? A/
Re: [patch] sometimes only paragraph of cursor is visible, #3231
The problem is that, when mouse hovering, no text painting should be needed, only background. But, because of current architectur where text is drawn _after_ background, we are forced to do the text painting. Changing this (using text on transparent background painting) basically needs a rewrite of rowpainter hence a 1.6 business). Ok. Now, in case when mouse hovering hapens just after a SinglePar update and at the same screen location, grey areas are drawn before and after the current paragraph. I am not sure I am clear... Not completely, but thanks a lot anyway. So, why the NoUpdate flag if the background is to be repainted? And then, if NoUpdate still repaints the background, why do we have the grey areas bug, are vi.y1 and vi.y2 wrong for some reason? You can issue redrawing from vi.y1 to vi.y2, e.g. the upper and lower line of a paragraph, with update_strategy set the NoUpdate. With the old behavior in this case the paragraph was redrawn correctly, but then _all the remaining part_ of the screen was painted grey. Hence the grey bars in certain cases. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [patch] Up/down cursor in math-macro jumps out of the macro, #3830
Need another OK. Anybody? José?
Stefan
Am 09.06.2007 um 18:29 schrieb Stefan Schimanski:
Bug: http://bugzilla.lyx.org/show_bug.cgi?id=3830
The patch should be obvious.
Stefan
Index: lyx-devel/src/mathed/MathMacro.cpp
===
--- lyx-devel.orig/src/mathed/MathMacro.cpp 2007-06-02
11:24:05.0 +0200
+++ lyx-devel/src/mathed/MathMacro.cpp 2007-06-09
18:24:35.0 +0200
@@ -254,6 +254,22 @@
}
+bool MathMacro::idxUpDown(Cursor cur, bool up) const
+{
+ if (up) {
+ if (cur.idx() == 0)
+ return false;
+ --cur.idx();
+ } else {
+ if (cur.idx() = nargs() - 1)
+ return false;
+ ++cur.idx();
+ }
+ cur.pos() = cell(cur.idx()).x2pos(cur.x_target());
+ return true;
+}
+
+
bool MathMacro::notifyCursorLeaves(Cursor cur)
{
cur.updateFlags(Update::Force);
Index: lyx-devel/src/mathed/MathMacro.h
===
--- lyx-devel.orig/src/mathed/MathMacro.h 2007-05-19
19:12:30.0 +0200
+++ lyx-devel/src/mathed/MathMacro.h 2007-06-09 18:14:31.0
+0200
@@ -48,6 +48,8 @@
/// target pos when we enter the inset from the right by pressing
Left
bool idxLast(Cursor ) const;
///
+ bool MathMacro::idxUpDown(Cursor cur, bool up) const;
+ ///
virtual bool notifyCursorLeaves(Cursor );
///
docstring name() const;
PGP.sig
Description: Signierter Teil der Nachricht
Re: [patch] sometimes only paragraph of cursor is visible, #3231
Stefan Schimanski wrote: The problem is that, when mouse hovering, no text painting should be needed, only background. But, because of current architectur where text is drawn _after_ background, we are forced to do the text painting. Changing this (using text on transparent background painting) basically needs a rewrite of rowpainter hence a 1.6 business). Ok. Now, in case when mouse hovering hapens just after a SinglePar update and at the same screen location, grey areas are drawn before and after the current paragraph. I am not sure I am clear... Not completely, but thanks a lot anyway. So, why the NoUpdate flag if the background is to be repainted? And then, if NoUpdate still repaints the background, why do we have the grey areas bug, are vi.y1 and vi.y2 wrong for some reason? You can issue redrawing from vi.y1 to vi.y2, e.g. the upper and lower line of a paragraph, with update_strategy set the NoUpdate. With the old behavior in this case the paragraph was redrawn correctly, but then _all the remaining part_ of the screen was painted grey. Hence the grey bars in certain cases. Seems like a stretch of the meaning of NoUpdate doesn't it. Why not just using SingleParUpdate in this case. Thanks, Alfredo
Re: [patch] fixing segfault because of empty coord cache
On Mon, Jun 11, 2007 at 08:06:31PM +0200, Andre Poenitz wrote: On Mon, Jun 11, 2007 at 09:47:13AM +0200, Jean-Marc Lasgouttes wrote: Andre == Andre Poenitz [EMAIL PROTECTED] writes: Do I understand correctly that this presupposes that 1) every mathinset must have an isActive method and 2) it should return true only if the inset has really accessible cells? Andre It's even in InsetBase, and something like that was the Andre intention. What is the difference between this and editable() == HIGHLY_EDITABLE? Historically isActive() was math and HIGHLY_EDITABLE was text. Do we need to have both? Not very likely ;-) There's a FIXME for that in Inset.h. BTW I find isActive() not very clear. isHighlyEditable() would be clearer. Is there the equivalent of IS_EDITABLE in math? - Martin
Re: [patch] bug 3510: make IEEEtran template compilable
On Mon, Jun 11, 2007 at 08:23:57PM +0200, Enrico Forestieri wrote: On Mon, Jun 11, 2007 at 06:57:07PM +0200, Jürgen Spitzmüller wrote: ... Well, either we remove the MarkBoth environment or actually add code to the preamble in order to avoid a latex failure when someone uses MarkBoth in the document without disabling babel. Also take into account the fact that one may have old files using the IEEEtran class with MarkBoth, and it is a real nuisance having to disable babel. Actually we should have Provides babel in the layout file, for precisely this kind of situation. If it is there, no babel statement should be added by LyX anymore. - Martin
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Hi, I am using lyx svn version 18738 from Monday night. I have found a few problems with the Bidi: 1. Cursor movement is not yet visual, i.e. the cursor goes opposite to the arrow key on foreign parts. I don't know if it was your intention to include that already. 2. I can't tell whether to use backspace or delete, since cursor isn't visual. 3. If I have a Hebrew paragraph with an English word like עברית English עברית עברית and I type continuously, the spaces are Hebrew. Now if I try to continue the Hebrew to the right of the English word, but after the Hebrew space, as to continue typing, I can't: If I am in English mode and I press F12 (bound to language hebrew), the cursor jumps to the left of the English word. If I was already in hebrew (if the cursor was resting on a hebrew word before and then I moved it to this position with the mouse), then it's ok. 4. Going backwards, when the cursor finishes the English word, it jumps to before the hebrew space, and stays in English mode, so that if I press a letter it comes out English even though I am in Hebrew. 5. Going forward, when the cursor moves one position after the hebrew space, the position jumps to one after the the first English character (i.e. to between E and n in English) and it is still in Hebrew mode, so the letter I enter is hebrew. 6. I cannot enter an inline equation to the right of the English word. It jumps to the left of it. I can trick lyx into doing this by entering the equation to the right of the boundary space, near the Hebrew part, and then adding the space between the hebrew word and the equation. The space between the word English and my equation is RTL. My equation is marked RTL, if that makes any sense. If I delete the space between the equation and the English word, I cannot put it back again. If I enter a LTR space, it gets deleted. I can't enter a RTL space (see paragraph 3). 7. Same for equation to the left of English text, If I enter it to the left of the word English, then it's OK (its LTR, but before the word English, i.e. to its left). If I enter it to the left of the Hebrew space (to the left of the word English), it is marked RTL, and if I delete the space between it and the English word, I can't put it back again. If I try a LTR space, it isn't entered. F12 jumps the cursor to the right of the English word. 8. I can't insert a cross reference to the right of English text. It jumps to the left of it. You can enter it to the left of Hebrew text, and then delete the space, and then add the Hebrew space. 9. Why do equations get marked LTR? 10. References which get added RTL are backward in output, i.e. instead of 12, 13, 14, etc. I get 21, 31, 41. Even if I try to switch the language to English, the reference gets marked RTL. I suspect it will be the same for figure numbers above 10. For equations it comes out fine for some reason even above 10. 11. If I try to enter an English word between two already typed Hebrew words, to the right of the space, and I type English with a space, the space gets deleted and I don't get a space between the word English and the hebrew word to its right. 12. If I try to enter an English word between two already typed Hebrew words, to the left of the space, I can't enter an LTR space to start with, and if I write English , I am left with two spaces, one LTR and to its right, the original RTL space. 13. Same as 11 and 12 but for Hebrew words between already typed English. I am sure there are more :) sorry to be picky. In my opinion, these problems are SERIOUS and really handicap lyx as a Hebrew typesetter at this point. They make serious work with Hebrew technical document (with lots of English terms in it, references and equations) in lyx very annoying and cumbersome. All of these can be fixed by voodoo such as starting a fresh paragraph, and then deleting the carriage return and such solutions, but I urge you to try and fix it before the release. Please? If anything isn't clear in my examples, don't hesitate to ask and I will clarify what I meant. Miki
Re: [patch] sometimes only paragraph of cursor is visible, #3231
On Mon, Jun 11, 2007 at 08:42:01PM +0200, Alfredo Braunstein wrote: Stefan Schimanski wrote: The problem is that, when mouse hovering, no text painting should be needed, only background. But, because of current architectur where text is drawn _after_ background, we are forced to do the text painting. Changing this (using text on transparent background painting) basically needs a rewrite of rowpainter hence a 1.6 business). Ok. Now, in case when mouse hovering hapens just after a SinglePar update and at the same screen location, grey areas are drawn before and after the current paragraph. I am not sure I am clear... Not completely, but thanks a lot anyway. So, why the NoUpdate flag if the background is to be repainted? And then, if NoUpdate still repaints the background, why do we have the grey areas bug, are vi.y1 and vi.y2 wrong for some reason? You can issue redrawing from vi.y1 to vi.y2, e.g. the upper and lower line of a paragraph, with update_strategy set the NoUpdate. With the old behavior in this case the paragraph was redrawn correctly, but then _all the remaining part_ of the screen was painted grey. Hence the grey bars in certain cases. Seems like a stretch of the meaning of NoUpdate doesn't it. Why not just using SingleParUpdate in this case. Actually the redraw of text is _always_ from vi.y1 to vi.y2. The SingleParUpdate is only meant to signal that there are still other paragraphs on the screen which _should not_ be greyed out. IIRC and nobody has overhauled this code since ;-/ - Martin
Re: [patch] sometimes only paragraph of cursor is visible, #3231
On Mon, Jun 11, 2007 at 10:04:28PM +0300, Martin Vermeer wrote: On Mon, Jun 11, 2007 at 08:42:01PM +0200, Alfredo Braunstein wrote: Stefan Schimanski wrote: The problem is that, when mouse hovering, no text painting should be needed, only background. But, because of current architectur where text is drawn _after_ background, we are forced to do the text painting. Changing this (using text on transparent background painting) basically needs a rewrite of rowpainter hence a 1.6 business). Ok. Now, in case when mouse hovering hapens just after a SinglePar update and at the same screen location, grey areas are drawn before and after the current paragraph. I am not sure I am clear... Not completely, but thanks a lot anyway. So, why the NoUpdate flag if the background is to be repainted? And then, if NoUpdate still repaints the background, why do we have the grey areas bug, are vi.y1 and vi.y2 wrong for some reason? You can issue redrawing from vi.y1 to vi.y2, e.g. the upper and lower line of a paragraph, with update_strategy set the NoUpdate. With the old behavior in this case the paragraph was redrawn correctly, but then _all the remaining part_ of the screen was painted grey. Hence the grey bars in certain cases. Seems like a stretch of the meaning of NoUpdate doesn't it. Why not just using SingleParUpdate in this case. Actually the redraw of text is _always_ from vi.y1 to vi.y2. The SingleParUpdate is only meant to signal that there are still other paragraphs on the screen which _should not_ be greyed out. IIRC and nobody has overhauled this code since ;-/ Actually something seems to have happened... there is a bitstring func_attrib containing NoUpdate and SingleParUpdate as bits, in LyXAction.h; and then there is an enum ScreenUpdateStrategy also containing SingleParUpdate in MetricsInfo.h. Why are there two, and what is their relationship if any? If one wanted to cause confusion, this would be the way to go about it :-( - Martin
Re: [patch] Up/down cursor in math-macro jumps out of the macro, #3830
Stefan Schimanski wrote: Need another OK. Anybody? José? Hi! 1. I have trouble applying the patches that you inline in the emails --- it's something with the whitespace, I think, but I always get malformed patch messages, and end up having to type them in by hand... 2. I got this error: MathMacro.h:51: error: extra qualification 'lyx::MathMacro::' on member 'idxUpDown' 3. After removing the MathMacro:: from idxUpDown, it's better --- down moves to the next parameter, and not out. However, when going down out of the last parameter, the macro still doesn't collapse -- I don't know if this is intentional or not... If that's right, then this is OK (and even if not, this is still better than the current behavior...) Dov Stefan Am 09.06.2007 um 18:29 schrieb Stefan Schimanski: Bug: http://bugzilla.lyx.org/show_bug.cgi?id=3830 The patch should be obvious. Stefan
Re: [patch] Up/down cursor in math-macro jumps out of the macro, #3830
Thanks for testing! 1. I have trouble applying the patches that you inline in the emails --- it's something with the whitespace, I think, but I always get malformed patch messages, and end up having to type them in by hand... Yes, in fact same for me with other people's inlined patches. Have to get my mailer to use the right mime type for patches 2. I got this error: MathMacro.h:51: error: extra qualification 'lyx::MathMacro::' on member 'idxUpDown' oops, sorry. MathMacro:: had to go. Had done that, updated the patch, compiled (so Xcode hadn't saved it yet. 3. After removing the MathMacro:: from idxUpDown, it's better --- down moves to the next parameter, and not out. However, when going down out of the last parameter, the macro still doesn't collapse -- I don't know if this is intentional or not... If that's right, then this is OK (and even if not, this is still better than the current behavior...) No, it's not intentional. It's a bug that notifyCursorLeaves is not called. Had noticed that before some time ago. Will look into it. Stefan P.S.: hope you got the mail from Miki. I think it was not sent to the list PGP.sig Description: Signierter Teil der Nachricht
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Miki Dovrat wrote: Hi, Hi, Miki! I am using lyx svn version 18738 from Monday night. Good! I have found a few problems with the Bidi: 1. Cursor movement is not yet visual, i.e. the cursor goes opposite to the arrow key on foreign parts. I don't know if it was your intention to include that already. No, Visual movement may not be done before 1.5.0. I hope that by 1.5.1 we'll have it... 2. I can't tell whether to use backspace or delete, since cursor isn't visual. Yes, this is a problem (and will be a problem in Visual mode, too, as backspace by convention is considered a logical action, and thus will *always* delete the *logically* previous character. That's what it should be doing now, too, if not --- it's a bug.) So: a. it's good that we have undo ;) b. what I sometimes do is SHIFT+RIGHT/LEFT to select what I want to delete, that way I see what's about to be deleted, and then delete... 3. If I have a Hebrew paragraph with an English word like עברית English עברית עברית and I type continuously, the spaces are Hebrew. Now if I try to continue the Hebrew to the right of the English word, but after the Hebrew space, as to continue typing, I can't: If I am in English mode and I press F12 (bound to language hebrew), the cursor jumps to the left of the English word. If I was already in hebrew (if the cursor was resting on a hebrew word before and then I moved it to this position with the mouse), then it's ok. This is correct. If you move to the right of the english through the english, then at the end you are still considered to be in English, at the end of the english; so switching to hebrew should move you to the left of the english. You can do what you want by moving to the beginning of the english, and then move back one more, that'll bring you to the space before the english; then if you move one Left, you'll be after the space, but still in hebrew. Typing in hebrew will then work as you want it to. In general, the idea is that on the borders between LTR and RTL, you stay in the language that you are coming from. I believe this is the way most applications deal with this, and now LyX does too. Again, this problem will probably be solved with visual mode, hopefully not too long from now... 4. Going backwards, when the cursor finishes the English word, it jumps to before the hebrew space, and stays in English mode, so that if I press a letter it comes out English even though I am in Hebrew. This is a different issue, it's a bug with the keymap, which I have a patch for waiting to be OKed. (see bug 3811) 5. Going forward, when the cursor moves one position after the hebrew space, the position jumps to one after the the first English character (i.e. to between E and n in English) and it is still in Hebrew mode, so the letter I enter is hebrew. Same as 4. 6. I cannot enter an inline equation to the right of the English word. This looks like a bug. If you're coming from the english, then I think that the equation should also be in english (see next comment), and then what you want to do would work. Can you open a bug for this in bugzilla (and see next comment)? Meanwhile, if you just select the entire inset, and switch it's language with F12, you'll get what you want. It jumps to the left of it. I can trick lyx into doing this by entering the equation to the right of the boundary space, near the Hebrew part, and then adding the space between the hebrew word and the equation. The space between the word English and my equation is RTL. My equation is marked RTL, if that makes any sense. Yes, the inset is marked as RTL, which is separate from what's inside it (try this with a footnote, where the text inside can also be RTL: you'll see that the language of the inset and the language of the text inside it are independent). I don't know if this is intentional or not, but I think that it does make a certain amount of sense. The problem above is just the the inset is not keeping the current language, but rather reverting to the paragraph's language... If I delete the space between the equation and the English word, I cannot put it back again. If I enter a LTR space, it gets deleted. I can't enter a RTL space (see paragraph 3). 7. Same for equation to the left of English text, If I enter it to the left of the word English, then it's OK (its LTR, but before the word English, i.e. to its left). If I enter it to the left of the Hebrew space (to the left of the word English), it is marked RTL, and if I delete the space between it and the English word, I can't put it back again. If I try a LTR space, it isn't entered. F12 jumps the cursor to the right of the English word. 8. I can't insert a cross reference to the right of English text. It jumps to the left of it. You can enter it to the left of Hebrew text, and then delete the space, and then add the Hebrew space. 7, 8 seem to be the same issue as in 6...?
Re: selection
Alfredo Braunstein wrote: Is it on purpose that insets are not painted blue when selecting? This is bug #3853 A/
Re: [patch] Up/down cursor in math-macro jumps out of the macro, #3830
No, it's not intentional. It's a bug that notifyCursorLeaves is not called. Had noticed that before some time ago. Will look into it. This whole updateflag business makes me crazy. The MathMacro get's the notifyCursorLeaves call. It then sets the Update::Force flag to trigger a redraw. But of course the MathMacro does not know what should happen on cursorDown from the last cell. So it marks the lfun as undispatched. But then the Update::Force flag is overwritten later by the cursor down handler of the text. As far as I see there is no way to trigger a complete redraw reliable from anywhere else than the inset which dispatches the lfun. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [patch] KeyMap bug (again)
On Monday 11 June 2007 19:13:11 Dov Feldstern wrote: Jose, since this is slightly different than what you last OKed --- is this still OK to commit? Yes. Thanks! Dov -- José Abílio
Re: Spaces on RTL boundaries
Georg Baum wrote:
Dov Feldstern wrote:
*** I now see what the problem is! What we need is *exactly* the change
of format 259; but in lyx2lyx, the \\lang property wasn't included for
some reason! The attached patch fixes this, and the output is now OK
(i.e., with this patch, a file created from before the change (also
attached), and in which the problem occurs, is output correctly and
displays correctly in the GUI even now!). But anyway, for the reasons
outlined above, I still think it's more correct to do this is a
separate, new file format, effective as of now.
Yes.
I guess that means
duplicating normalize_font_whitespace(), but having it now act *only* on
the lang property (Georg, you may want to make sure there aren't any
other forgotten properties, once we're at it...), and applying the new
function as the converter to a new file format...
Instead of duplicating I would factor it out into a new function that takes
the attributes to look for as a parameter and then use that in the
conversion functions for both formats.
So Georg, does all this make sense? And if so, could you please take
care of it? I guess we also need Jose's OK for this...
Yes, it makes sense. It looks like I and Jose are to be blamed for
forgetting the \lang attribute in lyx2lyx.
Unfortunetaly I have to meet a deadline soon and no time to work on this, so
somebody else has to step in.
Georg
Attached is a patch, using Georg's suggestion (refactoring). This is the
first time I'm doing a format change, so please make sure that I'm doing
everything which should be done in this case...
Jose -- OK?
Thanks!
Dov
Index: src/Buffer.cpp
===
--- src/Buffer.cpp (revision 18743)
+++ src/Buffer.cpp (working copy)
@@ -142,7 +142,7 @@
namespace {
-int const LYX_FORMAT = 271;
+int const LYX_FORMAT = 272;
} // namespace anon
Index: lib/lyx2lyx/LyX.py
===
--- lib/lyx2lyx/LyX.py (revision 18743)
+++ 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,272), generate_minor_versions(1.5 , 0))]
+ (1_5, range(246,273), generate_minor_versions(1.5 , 0))]
def formats_list():
Index: lib/lyx2lyx/lyx_1_5.py
===
--- lib/lyx2lyx/lyx_1_5.py (revision 18743)
+++ lib/lyx2lyx/lyx_1_5.py (working copy)
@@ -1099,22 +1099,41 @@
document.body[i] = unicodedata.normalize(NFKC, document.body[i])
-def normalize_font_whitespace(document):
+def normalize_font_whitespace_259(document):
Before format 259 the font changes were ignored if a
whitespace was the first or last character in the sequence, this function
transfers the whitespace outside.
+
+char_properties = {\\series: default,
+ \\emph: default,
+ \\color: none,
+ \\shape: default,
+ \\bar: default,
+ \\family: default}
+return normalize_font_whitespace(document, char_properties)
+def normalize_font_whitespace_272(document):
+ Before format 259 (sic) the font changes were ignored if a
+whitespace was the first or last character in the sequence. This was
+corrected for most font properties in format 259, but the language
+was forgotten then. This function applies the same conversion done
+there (namely, transfers the whitespace outside) for font language
+changes, as well.
+
+char_properties = {\\lang: default}
+return normalize_font_whitespace(document, char_properties)
+
+def normalize_font_whitespace(document, char_properties):
+ Before format 259 the font changes were ignored if a
+whitespace was the first or last character in the sequence, this function
+transfers the whitespace outside. Only a change in one of the properties
+ in the provided char_properties is handled by this function.
+
if document.backend != latex:
return
lines = document.body
-char_properties = {\\series: default,
- \\emph: default,
- \\color: none,
- \\shape: default,
- \\bar: default,
- \\family: default}
changes = {}
i = 0
@@ -1675,7 +1694,7 @@
[256, []],
[257, [convert_caption]],
[258, [convert_lyxline]],
- [259, [convert_accent, normalize_font_whitespace]],
+ [259, [convert_accent, normalize_font_whitespace_259]],
[260, []],
[261, [convert_changes]],
[262, []],
@@ -1687,10 +1706,12
