Re: XPM images --- a thought
On Sat, Jun 16, 2007 at 09:43:50PM -0700, Angus Leeming wrote: LyX still uses XPM images in lib/images. The XPM format is plain text, so it still makes sense to store XPM files in the SVN repository because we get versioning history for free. Clearly, that's not the case if we were to store a binary image format like PNG. We get the same information with any other file format. And as most of the PNGs are tiny storing full diffs would not even be expensive either. However, in these days of a PNG-aware frontend, it does seem strange that we still ship these XPM files to our consumers. Here's a thought: why don't we make the XPM - PNG transformation part of the build process and ship the resulting PNGs? Because that is not needed either. We can just the frontend's resource system and would not need to ship individual files at all. Andre'
Re: XPM images --- a thought
Andre Poenitz wrote: However, in these days of a PNG-aware frontend, it does seem strange that we still ship these XPM files to our consumers. Here's a thought: why don't we make the XPM - PNG transformation part of the build process and ship the resulting PNGs? Because that is not needed either. We can just the frontend's resource system and would not need to ship individual files at all. Yes, I see you're a Qt convert ;-) Two questions (seriously): * How much work would it be to rip out the current scheme and make use of whatever Qt provides. * Who would maintain this resource tree? By which I mean that many of the images LyX uses are unique to LyX, so we won't be able to leverage someone else's database. Or do I misunderstand? Angus
Re: XPM images --- a thought
On Sat, Jun 16, 2007 at 11:43:13PM -0700, Angus Leeming wrote: Andre Poenitz wrote: However, in these days of a PNG-aware frontend, it does seem strange that we still ship these XPM files to our consumers. Here's a thought: why don't we make the XPM - PNG transformation part of the build process and ship the resulting PNGs? Because that is not needed either. We can just the frontend's resource system and would not need to ship individual files at all. Yes, I see you're a Qt convert ;-) Certainly not from this proposal as I proposed this already a while ago. But apart from that I have now an idea what it means in a 'use Qt where available, third party only when really needed' world. And yes, I like it. Two questions (seriously): * How much work would it be to rip out the current scheme and make use of whatever Qt provides. The changes in the source are straight forward. Maybe an hour or two. The 'problem' will be to incorporate the rcc run (see below) into our three build systems... * Who would maintain this resource tree? By which I mean that many of the images LyX uses are unique to LyX, so we won't be able to leverage someone else's database. Or do I misunderstand? Qt resources are 'managed' by an xml file, usually ending in .qrc. Something like rcc version=1.0 fileimages/1.png/file fileimages/2.png/file /rcc This is converted by a programm called 'rcc' into a .cpp file which pretty much looks like inlined .xpm. This need to be compiled and linked to the app as usual. Resources can be accessed from with the app at any place an ordinary file can be used, simply by using a ':' prefix and the name from the .qrc file. I.e. instead of QPixmap pm(images/1.png) which needs the image path set correctly and the image installed as separate file on the client, it would be QPixmap pm(:images/1.png) There are no external dependencies. Maintaining the 'resource tree' is the same work as maintaining an Makefile.am, i.e. add a line whenever a new pixmap is needed. Andre'
Re: Shaded note = Colored Note???
why is a shaded note called shaded? AFAICS, a shaded note is in
fact a colored note both on screen and in LaTeX output!
I suggest renaming the menu item and the underlying code. If you
agree, I will prepare a patch.
Here comes a first proposal that cleans up the code. Personally, I
think that we call too many things a note. At least, we are supposed to
be consistent (internally externally) with this patch.
What is missing is a lyx2lyx converter that converts the two former note
types (Note Shaded) to
\begin_inset Note LyXInternal
and
\begin_inset Note Colored
Any volunteer? Any comments?
Michael
Index: src/Color.h
===
--- src/Color.h (Revision 18810)
+++ src/Color.h (Arbeitskopie)
@@ -85,20 +85,20 @@
/// The color used for previews
preview,
- /// Text color for notes
- note,
- /// Background color of notes
- notebg,
- /// Text color for comments
- comment,
- /// Background color of comments
- commentbg,
- /// Text color for greyedout inset
- greyedout,
- /// Background color of greyedout inset
- greyedoutbg,
- /// Shaded box background
- shadedbg,
+ /// Text color for lyx-internal notes
+ notelyxinternal,
+ /// Background color of lyx-internal notes
+ notelyxinternalbg,
+ /// Text color for tex comments
+ notecomment,
+ /// Background color of tex comments
+ notecommentbg,
+ /// Text color for greyedout notes
+ notegreyedout,
+ /// Background color of greyedout notes
+ notegreyedoutbg,
+ /// Background color of colored notes
+ notecoloredbg,
/// Color for the depth bars in the margin
depthbar,
Index: src/insets/InsetNomencl.cpp
===
--- src/insets/InsetNomencl.cpp (Revision 18810)
+++ src/insets/InsetNomencl.cpp (Arbeitskopie)
@@ -97,7 +97,7 @@
newlines += static_castInsetNomencl const (*it).docbookGlossary(os);
++it;
} else if(it-lyxCode() == Inset::NOTE_CODE
- static_castInsetNote const (*it).params().type == InsetNoteParams::Note) {
+ static_castInsetNote const (*it).params().type == InsetNoteParams::LyXInternal) {
// Don't output anything nested in note insets
size_t const depth = it.depth();
++it;
Index: src/insets/InsetNote.cpp
===
--- src/insets/InsetNote.cpp (Revision 18810)
+++ src/insets/InsetNote.cpp (Arbeitskopie)
@@ -50,22 +50,22 @@
NoteTranslator const init_notetranslator()
{
- NoteTranslator translator(Note, InsetNoteParams::Note);
+ NoteTranslator translator(LyXInternal, InsetNoteParams::LyXInternal);
translator.addPair(Comment, InsetNoteParams::Comment);
translator.addPair(Greyedout, InsetNoteParams::Greyedout);
translator.addPair(Framed, InsetNoteParams::Framed);
- translator.addPair(Shaded, InsetNoteParams::Shaded);
+ translator.addPair(Colored, InsetNoteParams::Colored);
return translator;
}
NoteTranslatorLoc const init_notetranslator_loc()
{
- NoteTranslatorLoc translator(_(Note), InsetNoteParams::Note);
+ NoteTranslatorLoc translator(_(LyX-internal), InsetNoteParams::LyXInternal);
translator.addPair(_(Comment), InsetNoteParams::Comment);
translator.addPair(_(Greyed out), InsetNoteParams::Greyedout);
translator.addPair(_(Framed), InsetNoteParams::Framed);
- translator.addPair(_(Shaded), InsetNoteParams::Shaded);
+ translator.addPair(_(Colored), InsetNoteParams::Colored);
return translator;
}
@@ -89,7 +89,7 @@
InsetNoteParams::InsetNoteParams()
- : type(Note)
+ : type(LyXInternal)
{}
@@ -152,7 +152,7 @@
{
switch (params_.type) {
case InsetNoteParams::Framed:
- case InsetNoteParams::Shaded:
+ case InsetNoteParams::Colored:
return AlignLeft;
default:
return Inline;
@@ -186,20 +186,20 @@
Color_color c;
switch (params_.type) {
- case InsetNoteParams::Note:
- c = Color::note;
+ case InsetNoteParams::LyXInternal:
+ c = Color::notelyxinternal;
break;
case InsetNoteParams::Comment:
- c = Color::comment;
+ c = Color::notecomment;
break;
case InsetNoteParams::Greyedout:
- c = Color::greyedout;
+ c = Color::notegreyedout;
break;
case InsetNoteParams::Framed:
- c = Color::greyedout;
+ c = Color::notegreyedout;
break;
- case InsetNoteParams::Shaded:
- c = Color::greyedout;
+ case InsetNoteParams::Colored:
+ c = Color::notegreyedout;
break;
}
font.setColor(c);
@@ -211,20 +211,20 @@
{
Color_color c;
switch (params_.type) {
- case InsetNoteParams::Note:
- c = Color::notebg;
+ case InsetNoteParams::LyXInternal:
+ c = Color::notelyxinternalbg;
break;
case InsetNoteParams::Comment:
- c = Color::commentbg;
+ c = Color::notecommentbg;
break;
case InsetNoteParams::Greyedout:
- c = Color::greyedoutbg;
+ c = Color::notegreyedoutbg;
break;
case InsetNoteParams::Framed:
- c = Color::greyedoutbg;
+ c = Color::notegreyedoutbg;
break;
- case InsetNoteParams::Shaded:
- c = Color::shadedbg;
+ case
Re: RC2 coming soon
José Matos wrote: what about http://bugzilla.lyx.org/show_bug.cgi?id=3840 and http://bugzilla.lyx.org/show_bug.cgi?id=3839 If Jürgen gives an OK to these I give my OK as well. If it works as advertised, I think it should go in. Edwin, if you post the most recent patch again, I'll text it. Jürgen
Re: RC2 coming soon
Jürgen Spitzmüller wrote: José Matos wrote: what about http://bugzilla.lyx.org/show_bug.cgi?id=3840 and http://bugzilla.lyx.org/show_bug.cgi?id=3839 If Jürgen gives an OK to these I give my OK as well. If it works as advertised, I think it should go in. Edwin, if you post the most recent patch again, I'll text it. you'll find it here: http://article.gmane.org/gmane.editors.lyx.devel/87886
[patch] fix broken listings ui
OK? Jürgen Index: src/frontends/qt4/ui/ListingsUi.ui === --- src/frontends/qt4/ui/ListingsUi.ui (Revision 18810) +++ src/frontends/qt4/ui/ListingsUi.ui (Arbeitskopie) @@ -18,15 +18,23 @@ property name=sizeGripEnabled booltrue/bool /property - layout class=QVBoxLayout + layout class=QGridLayout property name=margin number9/number /property property name=spacing number6/number /property - item + item row=0 column=0 widget class=QTabWidget name=listingsTW + property name=sizePolicy + sizepolicy + hsizetype3/hsizetype + vsizetype3/vsizetype + horstretch0/horstretch + verstretch0/verstretch + /sizepolicy + /property property name=currentIndex number0/number /property @@ -185,10 +193,10 @@ /layout /widget /item - item row=1 column=1 -widget class=QGroupBox name=rangeGB + item row=0 column=0 +widget class=QGroupBox name=placementGB property name=title - stringRange/string + stringPlacement/string /property layout class=QGridLayout property name=margin @@ -197,110 +205,49 @@ property name=spacing number6/number /property - item row=1 column=0 - widget class=QLabel name=numberfontsizeL_2 -property name=text - stringamp;Last line:/string + item row=2 column=1 + widget class=QLineEdit name=placementLE +property name=toolTip + stringSpecify placement (htbp) for floating listings/string /property -property name=wordWrap - boolfalse/bool -/property -property name=buddy - cstringlastlineLE/cstring -/property /widget /item - item row=1 column=1 - widget class=QLineEdit name=lastlineLE + item row=1 column=0 colspan=2 + widget class=QCheckBox name=floatCB property name=toolTip - stringThe last line to be printed/string + stringCheck for floating listings/string /property property name=text - string/ + stringamp;Float/string /property -property name=alignment - setQt::AlignLeading/set -/property /widget /item - item row=0 column=1 - widget class=QLineEdit name=firstlineLE + item row=0 column=0 colspan=2 + widget class=QCheckBox name=inlineCB property name=toolTip - stringThe first line to be printed/string + stringCheck for inline listings/string /property property name=text - string/ + stringamp;Inline listing/string /property -property name=alignment - setQt::AlignLeading/set -/property /widget /item - item row=0 column=0 - widget class=QLabel name=numberfontsizeL_3 + item row=2 column=0 + widget class=QLabel name=captionL_5 property name=text - stringFiamp;rst line:/string + stringamp;Placement:/string /property property name=wordWrap boolfalse/bool /property property name=buddy - cstringfirstlineLE/cstring + cstringplacementLE/cstring /property /widget /item /layout /widget /item - item row=1 column=0 -widget class=QGroupBox name=languageGB - property name=title - stringLanguage/string - /property - layout class=QGridLayout - property name=margin - number9/number - /property - property name=spacing - number6/number - /property - item row=1 column=1 - widget class=QComboBox name=dialectCO -property name=toolTip - stringSelect the dialect of the programming language, if available/string -/property - /widget - /item - item row=1 column=0 - widget class=QLabel name=dialectLBL -property name=text - stringamp;Dialect:/string -/property -property name=buddy - cstringdialectCO/cstring -/property - /widget - /item - item row=0 column=0 - widget class=QLabel name=languageLBL -property name=text - stringLanamp;guage:/string -/property -property name=buddy - cstringlanguageCO/cstring -
Re: [patch] fix broken listings ui
On 6/17/07, Jürgen Spitzmüller [EMAIL PROTECTED] wrote: OK? What was broken? Bo
Re: Shaded note = Colored Note???
On Sun, Jun 17, 2007 at 11:19:37AM +0200, Michael Gerz wrote: Here comes a first proposal that cleans up the code. Personally, I think that we call too many things a note. At least, we are supposed to be consistent (internally externally) with this patch. What is missing is a lyx2lyx converter that converts the two former note types (Note Shaded) to \begin_inset Note LyXInternal and \begin_inset Note Colored Any volunteer? Any comments? Just a comment. With this patch you are going to break compatibility with existing preferences and lyxrc.dist files. Please, don't do that. -1 -- Enrico
Re: Shaded note = Colored Note???
Also, we are supposed to focus on critical bugs now. -1 Bo
Re: RC2 coming soon
We are also finding a second home for aspell dictionaries so that the windows installer will work even ftp.lyx.org is unusable. What about the berlios.de repository that I currently use in LyXWinInstaller as second home for the dictionaries?: http://developer.berlios.de/project/showfiles.php?group_id=5117release_id=9651 regards Uwe
Re: [patch] Space displayed after macro, #3705
On Fri, Jun 15, 2007 at 08:39:14AM +0200, Stefan Schimanski wrote:
Here is a patch for http://bugzilla.lyx.org/show_bug.cgi?id=3705. It
adds the kerning method to a macro to inherit the kerning from the
expanded form. Moreover the marker metrics calls are remove as they
are not drawn anyway.
Stefan
Index: src/mathed/MathMacro.h
===
--- src/mathed/MathMacro.h (Revision 18774)
+++ src/mathed/MathMacro.h (Arbeitskopie)
@@ -54,6 +54,8 @@
///
docstring name() const;
///
+ int kerning() const { return kerning_; }
Could that be
int kerning() const { return expanded_.kerning(); }
or is expanded_ smashed before we access its kerning?
The expanded_ only makes sense if not edited. Even if the value of it
might sense in edit mode as well I wouldn't depend on it. Those
implicit assumptions pay back if you change the code months later and
you don't remember about it. Here a few pixels have no consequences
of course... But also inlining has no effect here with a virtual method.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Re: RC2 coming soon
What about the berlios.de repository that I currently use in LyXWinInstaller as second home for the dictionaries?: http://developer.berlios.de/project/showfiles.php?group_id=5117release_id=9651 I am not sure because Joost said that these dictionaries are for an earlier version of aspell and can not be used for the one compiled for the official installer. Bo
Re: RC2 coming soon
Bo Peng schrieb: I am not sure because Joost said that these dictionaries are for an earlier version of aspell and can not be used for the one compiled for the official installer. I can upload the actual ones tomorrow, no problem. But also the current dictionaries work well together with the one compiled for the official installer. regards Uwe
Re: RC2 coming soon - math panels patch
If it works as advertised, I think it should go in. I tested the patch and there are some issues left: - It is still not possible to insert two consecutive symbols because the panel is closed after every selection, see also http://bugzilla.lyx.org/show_bug.cgi?id=3839#c1 - Bug 3840 is not fixed for me. Detaching a panel should be intuitive and the current implementation is not. I takes me 5 minutes until I get it. Besides this I miss than the tooltips aren't shown for the math panels. Tooltips work e.g. for roots, styles, fonts and its subentries are shown in the status bar but e.g. not for the subentries of the Greek, Arrows panels. regards Uwe
[patch] was: help needed for bug 3878
Attached a correct patch from Georg. As Bug 3878 http://bugzilla.lyx.org/show_bug.cgi?id=3878 prevents the Userguide from beeing compiled this should go in before RC2. Bug 1942 is still not fixed, but this can be done later as this is a cosmetic bug. Seeking for another OK to commit. regards Uwe
Re: RC2 coming soon - math panels patch
Uwe Stöhr wrote: If it works as advertised, I think it should go in. I tested the patch and there are some issues left: - It is still not possible to insert two consecutive symbols because the panel is closed after every selection, see also http://bugzilla.lyx.org/show_bug.cgi?id=3839#c1 this is intentional. - Bug 3840 is not fixed for me. Detaching a panel should be intuitive and the current implementation is not. shrugthis is how qt does it.../shrug I takes me 5 minutes until I get it. but the good thing is that once you get it you get it... ... to take a bit of perspective: the patch does not change behavior wrt the current situation but it *does* allow you to tear off the menu's (a so-called pareto improvement: someone benefits without making others worse off...) Besides this I miss than the tooltips aren't shown for the math panels. Tooltips work e.g. for roots, styles, fonts and its subentries are shown in the status bar but e.g. not for the subentries of the Greek, Arrows panels. i know. perhaps you could file a bug... thanks for testing
Re: Meaning of Outline
On Sat, 16 Jun 2007, Ramon Flores wrote:
Richard Heck wrote:
Alfredo Braunstein wrote:
07. A summary of a written work or speech, usually analyzed in headings
and subheadings.
7, 12, 15 (your dictionary is a bit redundant) ;-)
In this sense, an outline might look like this:
I. Introduction
A. First Topic
B. Second Topic
II. Section One
A. First Issue
i. First sub-issue
etc. I'm not sure any of the definitions, other than (7), quite get at this
meaning. But maybe one would call that a formal outline or something of the
sort.
And what is the difference between Outline and TOC ?
Outline is more general than TOC, and can contain more that just the
headings. In fact, it doesn't really have to contain the headings at all.
I've used outlines ('disposition' in Swedish) as a tool that helps me to
structure and plan the work before, and during, the writing process.
An outline for a scientific paper could go like this (in a bullet form):
* Introduction - introduce the problem area to the reader, make it
interesting so that he'll continue reading.
** Describe application 'X' as suitable for this solution.
** General background - give more general background and describe related
work
** Theoretical background - go throuh related theory to prepare reader
for the new stuff
* Theory/hypothesis - introduce my new cool theory
* Experiments - describe an experiment I've done to support my theory.
* Results - describe the results.
** Remember to emphasize aspect 'Z' of experiment one.
* Conclusion and discussions
It doesn't have to contain the exact section headings of the final paper,
for me it's a help to _outline_ the flow of the paper.
Hope this helps
/Christian
--
Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: [patch] Space displayed after macro, #3705
On Sun, Jun 17, 2007 at 06:02:19PM +0200, Stefan Schimanski wrote:
On Fri, Jun 15, 2007 at 08:39:14AM +0200, Stefan Schimanski wrote:
Here is a patch for http://bugzilla.lyx.org/show_bug.cgi?id=3705. It
adds the kerning method to a macro to inherit the kerning from the
expanded form. Moreover the marker metrics calls are remove as they
are not drawn anyway.
Stefan
Index: src/mathed/MathMacro.h
===
--- src/mathed/MathMacro.h (Revision 18774)
+++ src/mathed/MathMacro.h (Arbeitskopie)
@@ -54,6 +54,8 @@
///
docstring name() const;
///
+ int kerning() const { return kerning_; }
Could that be
int kerning() const { return expanded_.kerning(); }
or is expanded_ smashed before we access its kerning?
The expanded_ only makes sense if not edited. Even if the value of it
might sense in edit mode as well I wouldn't depend on it. Those
implicit assumptions pay back if you change the code months later and
you don't remember about it. Here a few pixels have no consequences
of course... But also inlining has no effect here with a virtual method.
It's not about inlining, it's about that extra kerning_ member that
needs to be kept in sync with expanded_.kerning()
Andre'
Re: [patch] fix broken listings ui
Bo Peng wrote: What was broken? The layout on the Advanced tab. Jürgen
Location of supporting files for the windows installers (Was: RC2 coming soon)
On Sun, 17 Jun 2007, Uwe Stöhr wrote: Bo Peng schrieb: I am not sure because Joost said that these dictionaries are for an earlier version of aspell and can not be used for the one compiled for the official installer. I can upload the actual ones tomorrow, no problem. But also the current dictionaries work well together with the one compiled for the official installer. Hi guys, real life intervened when a friend asked for help so I've been offline for a few days. Here's a suggestion for locations for the installer to try and download supporting files for the LyX installation. 1. ftp.lyx.org (I don't know which machine this is, probably french) 2. aussie.lyx.org (aka www.lyx.org, wiki.lyx.org and ftp.devel.lyx.org) 3. berlios.de Here's my reasoning: ftp.lyx.org is the offical source of downloading lyx Only one or two of the developers have write access to this machine, but AFAIK it is generally stable host and has good capacity. This machine is very different from aussie.lyx.org in this sense. As for aussie, most of the developers have write permission there, so we could set up the files on aussie and then ask e.g. Jean-Marc to mirror them to ftp.lyx.org. I think mirroring to a third place (berlios.de) could be a good idea. Does this make sense in general? I browsed ftp.lyx.org and the aspell files currently seem to be located at ftp://ftp.lyx.org/pub/lyx/contrib/aspell6-windows/ Are aspell dictionaries the only thing that we should provide? Are there and components used by the downloading installers that we should provide a (backup) location for? If it's more then aspell dictionaries, how about a directory tree that looks something like this: * contrib/ ** windows/ *** aspell/ 6.0/ (dictionaries for aspell6.0) *** ? what else might there be? I don't know if we'll need to support dictionaries for more than one version of aspell at a time, but better be prepared IMO. Thoughts? /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: RC2 coming soon
Uwe Stöhr wrote: I can upload the actual ones tomorrow, no problem. But also the current dictionaries work well together with the one compiled for the official installer. There have been changes in the dictionary installers for multi-user installations and some other things. The outdated dictionaries on berlios.de don't work in all situations. The files on wiki.lyx.org are even older. Joost
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
[EMAIL PROTECTED] wrote: Are aspell dictionaries the only thing that we should provide? Are there and components used by the downloading installers that we should provide a (backup) location for? Only Aspell is used on Windows. If it's more then aspell dictionaries, how about a directory tree that looks something like this: * contrib/ ** windows/ *** aspell/ 6.0/(dictionaries for aspell6.0) *** ? what else might there be? The version number of the dictionary format (6) is already in the name. If there would ever be a new Aspell version with a different dictionary format (which is very unlikely), the dictionaries will be uploaded to ftp://ftp.lyx.org/pub/lyx/contrib/aspell7-windows/ Joost
Re: RC2 coming soon
Edwin Leuven wrote: you'll find it here: http://article.gmane.org/gmane.editors.lyx.devel/87886 Works for me. Put it in. Jürgen
Re: RC2 coming soon - math panels patch
Edwin Leuven schrieb: - It is still not possible to insert two consecutive symbols because the panel is closed after every selection, see also http://bugzilla.lyx.org/show_bug.cgi?id=3839#c1 this is intentional. But this is no excuse ;-). I also have often the case that I want to insert some symbols from the same panel and it is annoying that I always have to reopen the panel. I takes me 5 minutes until I get it. but the good thing is that once you get it you get it... OK, but please document this in the Userguide. Besides this I miss than the tooltips aren't shown for the math panels. Tooltips work e.g. for roots, styles, fonts and its subentries are shown in the status bar but e.g. not for the subentries of the Greek, Arrows panels. i know. perhaps you could file a bug... This is now bug 3883: http://bugzilla.lyx.org/show_bug.cgi?id=3883 Do you have an idea why this doesn't work? regards Uwe
Re: 2007 LyX Meeting: Invitation
On Sat, 16 Jun 2007, Martin Vermeer wrote: Martin Hereby I invite everyone interested to participate in the ?th Martin International LyX Developers' Meeting in Bromarv, Western Martin Uusimaa, municipality of Ekenäs. What is the status? Who is coming and when? There are some convenient Air France Flights, but I need to know more about when to come. Also, is 1 hour enough to go to city center and catch the bus? The bus takes half an hour and goes at intervals of 20-30 minutes, also walking to the bus statin takes 10 min. So an hour is a bit tight. Take two hours at least. A taxi would be a backup option. I plan to come. I got tired of keeping all these posts around, so I copied some of them to a wiki page: http://wiki.lyx.org/Devel/LyXMeeting2007 /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: RC2 coming soon - math panels patch
Uwe Stöhr wrote: this is intentional. But this is no excuse ;-). I also have often the case that I want to insert some symbols from the same panel and it is annoying that I always have to reopen the panel. IMHO Edwin's proposal is just perfect: whenever you want to insert multiple sybols, tear off the panel. Menus should behave like menues, dialogs like dialogs. Jürgen
Re: RC2 coming soon - math panels patch
Uwe Stöhr wrote: Edwin Leuven schrieb: - It is still not possible to insert two consecutive symbols because the panel is closed after every selection, see also http://bugzilla.lyx.org/show_bug.cgi?id=3839#c1 this is intentional. But this is no excuse ;-) it isn't?! I also have often the case that I want to insert some symbols from the same panel and it is annoying that I always have to reopen the panel. but that's why you can tear 'em off now I takes me 5 minutes until I get it. but the good thing is that once you get it you get it... OK, but please document this in the Userguide. will try to write something up before final This is now bug 3883: http://bugzilla.lyx.org/show_bug.cgi?id=3883 thanks Do you have an idea why this doesn't work? not a clue. i looked into this for a while but didn't get anywhere so i gave up...
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
On Sun, 17 Jun 2007, Joost Verburg wrote: [EMAIL PROTECTED] wrote: Are aspell dictionaries the only thing that we should provide? Are there and components used by the downloading installers that we should provide a (backup) location for? Only Aspell is used on Windows. What about some of the components themselves? I have some (vague) memory of this being discussed. (The original location of the components should probably the primary place to look for them, but we could supply a backup location for the installer. Not necessarily for all components, but for some of them). If it's more then aspell dictionaries, how about a directory tree that looks something like this: * contrib/ ** windows/ *** aspell/ 6.0/(dictionaries for aspell6.0) *** ? what else might there be? The version number of the dictionary format (6) is already in the name. If there would ever be a new Aspell version with a different dictionary format (which is very unlikely), the dictionaries will be uploaded to ftp://ftp.lyx.org/pub/lyx/contrib/aspell7-windows/ The purpose with a tree was to make it easy to synchronize the entire tree between different locations. So I'd still suggest something like: * contrib/ ** windows/ - the directory that will be synchronized *** aspell6 A better name than 'windows' could be used of course. Perhaps something like 'windows-installer-support'. It doesn't really have to be a short URI. /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: RC2 coming soon
On Sun, 17 Jun 2007, Joost Verburg wrote: Uwe Stöhr wrote: I can upload the actual ones tomorrow, no problem. But also the current dictionaries work well together with the one compiled for the official installer. There have been changes in the dictionary installers for multi-user installations and some other things. The outdated dictionaries on berlios.de don't work in all situations. The files on wiki.lyx.org are even older. Did the file format change? (Just curious) /C -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
On Sun, 17 Jun 2007, [EMAIL PROTECTED] wrote: The version number of the dictionary format (6) is already in the name. If there would ever be a new Aspell version with a different dictionary format (which is very unlikely), the dictionaries will be uploaded to ftp://ftp.lyx.org/pub/lyx/contrib/aspell7-windows/ Btw, it's not all clear to me that this directory only contains dictionaries. I think the name should say this, so I'm modifying my suggestion to the following: The purpose with a tree was to make it easy to synchronize the entire tree between different locations. So I'd still suggest something like: contrib/ windows-installer-support/ dictionaries-aspell6/ A better name than 'windows' could be used of course. Perhaps something like 'windows-installer-support'. It doesn't really have to be a short URI. /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
[EMAIL PROTECTED] wrote: What about some of the components themselves? I have some (vague) memory of this being discussed. (The original location of the components should probably the primary place to look for them, but we could supply a backup location for the installer. Not necessarily for all components, but for some of them). The other components are hosted on SourceForge. The download servers of SF are reliable and they have the policy never to delete any file (even the project administrators cannot delete files). They also have a dozen of mirror servers that can be used when we add alternative download locations to the installer. If it's more then aspell dictionaries, how about a directory tree that looks something like this: The purpose with a tree was to make it easy to synchronize the entire tree between different locations. So I'd still suggest something like: We only need to host Aspell dictionaries because no Windows dictionaries are provided on the official site. Joost
Re: RC2 coming soon
[EMAIL PROTECTED] wrote: There have been changes in the dictionary installers for multi-user installations and some other things. The outdated dictionaries on berlios.de don't work in all situations. The files on wiki.lyx.org are even older. Did the file format change? (Just curious) There have been no changes to the dictionary file format. Aspell development has almost stalled, so I don't expect a format change anytime soon. The big open-source projects currently use Hunspell. Joost
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
[EMAIL PROTECTED] wrote: Btw, it's not all clear to me that this directory only contains dictionaries. I think the name should say this, so I'm modifying my suggestion to the following: Why create a whole directory structure if we only need to host dictionaries? If you change the name there should already be a redirect so older installers keep working. Joost
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
On Sun, 17 Jun 2007, Joost Verburg wrote: [EMAIL PROTECTED] wrote: What about some of the components themselves? I have some (vague) memory of this being discussed. (The original location of the components should probably the primary place to look for them, but we could supply a backup location for the installer. Not necessarily for all components, but for some of them). The other components are hosted on SourceForge. Uwe, are all components your installer need hosted on sf? The download servers of SF are reliable and they have the policy never to delete any file (even the project administrators cannot delete files). Not sure I agree 100% with that, but it's good enough I think. They also have a dozen of mirror servers that can be used when we add alternative download locations to the installer. Maybe it's some of the mirrors I've had problems with. If it's more then aspell dictionaries, how about a directory tree that looks something like this: The purpose with a tree was to make it easy to synchronize the entire tree between different locations. So I'd still suggest something like: We only need to host Aspell dictionaries because no Windows dictionaries are provided on the official site. Uwe, do you concur? I have an alternative suggestion if we are really only talking about dictionaries for Aspell. Why should we host them? Let's put them on sourceforge instead. Either get them in with the Aspell project, or start a separate project for the Aspell dictionaries. What do you think of this? /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
[EMAIL PROTECTED] wrote: I have an alternative suggestion if we are really only talking about dictionaries for Aspell. Why should we host them? Let's put them on sourceforge instead. Either get them in with the Aspell project, or start a separate project for the Aspell dictionaries. Creating a SF project is fine with me, but I don't really think it is necessary. I tried to contact the Aspell developer before, but he is not really interested in a Windows version. I'd also like to be able to update the files within a reasonable time. Joost
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
On Sun, 17 Jun 2007, Joost Verburg wrote: [EMAIL PROTECTED] wrote: I have an alternative suggestion if we are really only talking about dictionaries for Aspell. Why should we host them? Let's put them on sourceforge instead. Either get them in with the Aspell project, or start a separate project for the Aspell dictionaries. Creating a SF project is fine with me, but I don't really think it is necessary. I tried to contact the Aspell developer before, but he is not really interested in a Windows version. I'd also like to be able to update the files within a reasonable time. It feels like I'm missing something here. You say you'd like to be able to update the files now and then. However, the format is not going to change. Reading what you wrote earlier, I wonder: Is this about updating the dictionary _installers_? (E.g. because there's an improved dictionary, _or_ because there is a better installer part available?) Do we ever need to support old versions of a dictionary? (For instance if a new version of a dictionary contains a spelling of a word that someone thinks is incorrect). /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: RC2 coming soon - math panels patch
Edwin Leuven schrieb: I also have often the case that I want to insert some symbols from the same panel and it is annoying that I always have to reopen the panel. but that's why you can tear 'em off now OK, I understand. So what is only missing is the documentation how to detach a panel in the Userguide. regards Uwe
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
On Sun, 17 Jun 2007, Joost Verburg wrote: [EMAIL PROTECTED] wrote: Btw, it's not all clear to me that this directory only contains dictionaries. I think the name should say this, so I'm modifying my suggestion to the following: Why create a whole directory structure if we only need to host dictionaries? In case we need to store something else in the future? If we are reasonably sure it'll only ever be the dictionaries, I agree with you. If you change the name there should already be a redirect so older installers keep working. True. Or just leave the old copy where it is... (it only seems to be about 30-60MB). And add a 'README' saying where more up-to-date stuff can be found. I looked in the directory again, and I think I understand it better now. For an installer of a dictionary, e.g. .../aspell6-windows/aspell6-af-0.50-0.exe * The '6' in 'aspell6' stands for dictonary format '6'. * The '-af-' stands for the language * The '0.50-0' stands for the version of the dictionary. Correct? How will we deal with old versions of dictionary (installers)? When a new dictionary comes along, we'll eventually catch up and produce a corresponding dictonary installer. Then we'll eventually make an updated LyX installer, that'll refer to the new dictionary installer. However, the old LyX installers will still refer to the old dictionary installer, so in order to not break those we need keep the old dictionary installers around. Correct? We could, some time in the future, make the LyX installer be smarter about which version of the LyX installer it should install. Or is it already so smart that it downloads a list of the available dictionaries to install? /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
[EMAIL PROTECTED] wrote: It feels like I'm missing something here. You say you'd like to be able to update the files now and then. However, the format is not going to change. The dictionary file format is not going to change anytime soon. Reading what you wrote earlier, I wonder: Is this about updating the dictionary _installers_? (E.g. because there's an improved dictionary, _or_ because there is a better installer part available?) The dictionary installers will have to be updated every now and then when new dictionaries are released (both new languages as well as updated dictionaries) or when the installers needs a bugfix or new feature. Do we ever need to support old versions of a dictionary? (For instance if a new version of a dictionary contains a spelling of a word that someone thinks is incorrect). I keep the old versions for older installers. If you want the installers to always download the most recent versions some softlinks need to be created on the FTP server. Joost
help needed from BiDi people
This bug prevents LyX from beeing used to typeset Arabic and Farsi:
http://bugzilla.lyx.org/show_bug.cgi?id=2928
The reason for this is that LyX currently use \R{} instaed of \AR{} for Arabic
and \FR{} for Farsi.
I'm not familiar with the Bidi/language code and assume that there are special BiDi things to take
care of, but perhaps one of you is able to fix this without big effort.
thanks and regards
Uwe
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
[EMAIL PROTECTED] wrote: I looked in the directory again, and I think I understand it better now. For an installer of a dictionary, e.g. .../aspell6-windows/aspell6-af-0.50-0.exe * The '6' in 'aspell6' stands for dictonary format '6'. * The '-af-' stands for the language * The '0.50-0' stands for the version of the dictionary. Correct? Correct. How will we deal with old versions of dictionary (installers)? When a new dictionary comes along, we'll eventually catch up and produce a corresponding dictonary installer. Then we'll eventually make an updated LyX installer, that'll refer to the new dictionary installer. However, the old LyX installers will still refer to the old dictionary installer, so in order to not break those we need keep the old dictionary installers around. Correct? Correct. We could, some time in the future, make the LyX installer be smarter about which version of the LyX installer it should install. Or is it already so smart that it downloads a list of the available dictionaries to install? Softlinks on the FTP server to the most recent versions will do. Like aspell6-en-latest.exe. Joost
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
On Sun, 17 Jun 2007, Joost Verburg wrote: Do we ever need to support old versions of a dictionary? (For instance if a new version of a dictionary contains a spelling of a word that someone thinks is incorrect). I keep the old versions for older installers. If you want the installers to always download the most recent versions some softlinks need to be created on the FTP server. I looked, and now looked again, but I could only see a single version of the dictionary installer for each language at ftp://ftp.lyx.org/pub/lyx/contrib/aspell6-windows/ Are older versions kept somewhere else? Or have the dictionary installers newer been updated? Will old LyX installers still work, i.e. be able to install Aspell properly? /Christian PS. I'm starting a wiki page for all these notes regarding Aspell for the future: http://wiki.lyx.org/Devel/Aspell -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Fwd from users' list: Importance of Mathed seems to be underestimated (fwd)
Abdelrazak Younes wrote: I fully agree with Heiko that the insertion of math symbol and function should be authorised from texted. I don't understand why this has been removed. Anyone cares to explain the rationale behind that decision? I have the same problem. In LyX 1.4 I could insert symbols by simply clicking the right button on the math panel. Now I have to go into math mode first. I like the new math toolbars, but this needs to be fixed. Joost
Re: [Cvslog] r18812 - in /lyx-devel/trunk/src/frontends/qt4: IconPalet...
On Sun, Jun 17, 2007 at 05:55:37PM -, [EMAIL PROTECTED] wrote: +#if QT_VERSION = 0x040200 +// FIXME: this can go when we move to Qt 4.3 +#define QT_VERSION_CHECK(major, minor, patch) ((major16)|(minor8)|(patch)) + +#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0) Are you listening? I think I complained at least twice about the unsymmetry and still got no explanation how this would work without warnign with an already defined macro. Andre'
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
[EMAIL PROTECTED] wrote: Are older versions kept somewhere else? Or have the dictionary installers newer been updated? The old versions are somewhere in the wiki uploads directory. Joost
Re: [Cvslog] r18812 - in /lyx-devel/trunk/src/frontends/qt4: IconPalet...
Andre Poenitz wrote: On Sun, Jun 17, 2007 at 05:55:37PM -, [EMAIL PROTECTED] wrote: +#if QT_VERSION = 0x040200 +// FIXME: this can go when we move to Qt 4.3 +#define QT_VERSION_CHECK(major, minor, patch) ((major16)|(minor8)|(patch)) + +#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0) Are you listening? always dearest I think I complained at least twice about the unsymmetry and still got no explanation how this would work without warnign with an already defined macro. i think i also told you twice that #if QT_VERSION = 0x040200 in the header doesn't compile for me. i don't remember you having a solution. if you know the solution now, then you are of course welcome to provide a patch. if you want to change this all over the qt4 dir, just to be consistent with one header file: be my guest again. thanks for listening. regards, edwin
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
On Sun, 17 Jun 2007, Joost Verburg wrote: Softlinks on the FTP server to the most recent versions will do. Like aspell6-en-latest.exe. Hmm.. that's not necessarily so easy to synchronize between different servers. We don't want to create a lot of work for Jean-Marc. (Or whoever it is that can write to ftp.lyx.org) Below I've outlined one process that cold be used to update/synchronize when even a single new dictionary (installer) is introduced. To begin with, we have a 'master' directory somewhere that we can write to, e.g. under http://www.lyx.org/.../aspell6. Then, when we create a new version of a dictionary installer, we write it to that directory. And update/change the soft link in that directory. Finally we create a .tar.gz file with everything in that directory and ask Jean-Marc to replace the content on ftp.lyx.org/.../aspell6 with that tar-file. It'd work, but it's not so elegant. I know there are better synchronizing softwares, but we don't know if Jean-Marc has enough access to use them. The soft links might be a problem for instance. Maybe a straight copy is simpler... I'm sending this to Jean-Marc as well for his comments. Jean-Marc? /Christian PS. Having the LyX installer be able to select among the dictionaries, or simply list everything that's on the FTP server, would be more elegant but I'm doubtful it's worth the trouble to write. -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: help needed from BiDi people
It doesn't seem to be a bug. Because when some words in ARABIC are written
inside a LATIN paragraph the command \R{arabic phrase} is used to indicate
that. The command \R{arabic phrase} is supposed to change the language to
ARABIC too. But when a new paragraph begins such that the previous paragraph is
LATIN, then it uses '\selectlanguage{ARABIC} command before the new paragraph
for just one time for all the next ARABIC paragraphs.
Moreover the default language of the attached document is ARABIC. Therefore
you see the command \selectlanguage{arabic} as the last command of the LATIN
paragraph. It indicates that if you start a new paragraph the language of that
paragraph is ARABIC.
Mostafa
-
Park yourself in front of a world of choices in alternative vehicles.
Visit the Yahoo! Auto Green Center.
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
On Sun, 17 Jun 2007, Joost Verburg wrote: [EMAIL PROTECTED] wrote: Are older versions kept somewhere else? Or have the dictionary installers newer been updated? The old versions are somewhere in the wiki uploads directory. Ok. Is that where old LyX installers look for them? /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: [Cvslog] r18812 - in /lyx-devel/trunk/src/frontends/qt4: IconPalet...
On Sun, Jun 17, 2007 at 09:55:59PM +0200, Edwin Leuven wrote: Andre Poenitz wrote: On Sun, Jun 17, 2007 at 05:55:37PM -, [EMAIL PROTECTED] wrote: +#if QT_VERSION = 0x040200 +// FIXME: this can go when we move to Qt 4.3 +#define QT_VERSION_CHECK(major, minor, patch) ((major16)|(minor8)|(patch)) + +#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0) Are you listening? always dearest I think I complained at least twice about the unsymmetry and still got no explanation how this would work without warnign with an already defined macro. i think i also told you twice that #if QT_VERSION = 0x040200 in the header doesn't compile for me. So you are saying #if QT_VERSION = 0x040200 does not compile in a .h but it does in a .cpp? Andre'
Re: help needed from BiDi people
Mostafa, you're able to generate Farsi dvi documents, right?
Mostafa Vahedi wrote:
It doesn't seem to be a bug. Because when some words in ARABIC are
written inside a LATIN paragraph the command \R{arabic phrase} is used
to indicate that. The command \R{arabic phrase} is supposed to change
the language to ARABIC too. But when a new paragraph begins such that
the previous paragraph is LATIN, then it uses '\selectlanguage{ARABIC}
command before the new paragraph for just one time for all the next
ARABIC paragraphs.
Moreover the default language of the attached document is ARABIC.
Therefore you see the command \selectlanguage{arabic} as the last
command of the LATIN paragraph. It indicates that if you start a new
paragraph the language of that paragraph is ARABIC.
Mostafa
Park yourself in front of a world of choices in alternative vehicles.
Visit the Yahoo! Auto Green Center.
http://us.rd.yahoo.com/evt=48246/*http://autos.yahoo.com/green_center/;_ylc=X3oDMTE5cDF2bXZzBF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDZ3JlZW4tY2VudGVy
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
[EMAIL PROTECTED] wrote: On Sun, 17 Jun 2007, Joost Verburg wrote: [EMAIL PROTECTED] wrote: Are older versions kept somewhere else? Or have the dictionary installers newer been updated? The old versions are somewhere in the wiki uploads directory. Ok. Is that where old LyX installers look for them? Yes. Joost
Re: [Cvslog] r18812 - in /lyx-devel/trunk/src/frontends/qt4: IconPalet...
Andre Poenitz wrote: So you are saying #if QT_VERSION = 0x040200 does not compile in a .h but it does in a .cpp? yes. i've said this many times: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg120474.html
Re: Toolbar status - Translation Problem
Michael Gerz wrote:
Hi,
this patch fixes a problem with an untranslated toolbar name.
OK?
why not simply:
ToolbarInfo const Toolbars::getToolbarInfo(string const name)
{
return toolbarbackend.getToolbar(name);
}
Re: help needed from BiDi people
Mostafa Vahedi schrieb:
It doesn't seem to be a bug.
Because when some words in ARABIC are written inside a LATIN paragraph
the command \R{arabic phrase} is used to indicate that. The command
\R{arabic phrase} is supposed to change the language to ARABIC too.
It is a bug because the command \R is only defined when the document uses also Hebrew. So instead of
\R the command \AR has to be used.
regards Uwe
Re: help needed from BiDi people
Dov Feldstern schrieb: Mostafa, you're able to generate Farsi dvi documents, right? The problem occurs when you use another language or latin characters in your document, see the LyX-testfile I attached to the bug report. regards Uwe
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
Hi Joost, I wanted to update the Aspell dictionaries at berlios.de but see now that at ftp.lyx.org many dictionaries are missing. You can see from the download statistics here http://developer.berlios.de/project/showfiles.php?group_id=5117release_id=9651 that every Aspell dictionary was downloaded by users. So could you also provide the now missing Aspell dictionaries at ftp.lyx.org or was there a reason why you don't build the dictionaries for all languages? thanks and regards Uwe
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
Uwe Stöhr wrote: So could you also provide the now missing Aspell dictionaries at ftp.lyx.org or was there a reason why you don't build the dictionaries for all languages? The other languages are not supported by LyX, so I don't see any reason to make dictionaries available for these languages. Joost
Re: [Cvslog] r18812 - in /lyx-devel/trunk/src/frontends/qt4: IconPalet...
On Sun, Jun 17, 2007 at 09:55:59PM +0200, Edwin Leuven wrote: Andre Poenitz wrote: On Sun, Jun 17, 2007 at 05:55:37PM -, [EMAIL PROTECTED] wrote: +#if QT_VERSION = 0x040200 +// FIXME: this can go when we move to Qt 4.3 +#define QT_VERSION_CHECK(major, minor, patch) ((major16)|(minor8)|(patch)) + +#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0) Are you listening? always dearest I think I complained at least twice about the unsymmetry and still got no explanation how this would work without warnign with an already defined macro. i think i also told you twice that #if QT_VERSION = 0x040200 in the header doesn't compile for me. i don't remember you having a solution. Looks like a moc bug. Or 'missing feature' at least. Sorry for not taking your response seriously enough. Andre'
Re: help needed from BiDi people
Uwe Stöhr wrote:
Mostafa Vahedi schrieb:
It doesn't seem to be a bug.
Because when some words in ARABIC are written inside a LATIN paragraph
the command \R{arabic phrase} is used to indicate that. The command
\R{arabic phrase} is supposed to change the language to ARABIC too.
It is a bug because the command \R is only defined when the document
uses also Hebrew. So instead of \R the command \AR has to be used.
regards Uwe
Uwe, what are you basing this claim on? And how do you know that it
doesn't really work? The example file certainly won't work, because it's
not in real arabic (attachment 1308)...
I'm trying this out right now (with real arabic), and my main problem
ATM is with loading the appropriate fonts. Also, the line
\usepackage[T1]{fontenc} in the generated latex file seems a little
suspect to me, but I'm not sure. Anyhow, I'm working on getting arabic
latex set up here now, and I'll try this out. I'll let you know what's
doing.
Do you know of anyone who used to be able to use arabic in LyX, but
can't anymore?
Dov
[patch] for ANNOUNCE file
José, I think that we should announce everything new we have. I added the missing bits that came into my mind in the attached patch. OK? regards Uwe Index: ANNOUNCE === --- ANNOUNCE (revision 18813) +++ ANNOUNCE (working copy) @@ -111,6 +111,11 @@ Note that from now on, former encoding settings for these languages done via ERT or the document preamble will lead to LaTeX-errors! +* Language support + +Besides the CJK languages, the languages Armenian and Farsi are now +supported in the user interface. + * Multiple views of the same buffer LyX can now display multiple views of the same buffer. I.e., you can @@ -151,7 +156,6 @@ LaTeX. support for the booktabs package was implemented, which provides beautiful and elegant tabulars. - * Nomenclatures Native LyX support for the nomencl package was implemented. With this, @@ -216,6 +220,15 @@ Using the listings latex package as the backend a new inset was added that supports all these three ways of listing computer programs. +* LaTeX-package support + +LyX provides the following new document classes: + - article(IOP) - for scientific papers published by the IOP group + - presentation(powerdot) - for presentations using the powerdot package + - curriculum vitae(Europe) - for CVs following the guidelines of the EU + - curriculum vitae(modern) - for CVs using the moderncv package + - curriculum vitae(simple) - for simple CVs + * Minor user interface improvements Apart from the described major changes, several minor improvements of @@ -234,7 +247,6 @@ you can paste the selected text using middle button multiple times, even after the selection has been cleared. - * Under the hood As usual, one big task has been the ongoing code cleanup of the LyX
Re: [Cvslog] r18812 - in /lyx-devel/trunk/src/frontends/qt4: IconPalet...
Andre Poenitz wrote: Looks like a moc bug. Or 'missing feature' at least. Sorry for not taking your response seriously enough. you can buy me that beer another time... ;-)
Re: help needed from BiDi people
Dov Feldstern schrieb:
Uwe, what are you basing this claim on?
And how do you know that it
doesn't really work?
Test out the small TeX-file in
http://bugzilla.lyx.org/show_bug.cgi?id=2928#c9
When you use Hebrew additionally it works.
I also looked at the source code of babel and the command \R is only defined
when Hebrew is used.
(I reported this also to the babel maintainer.)
The LaTeX companion also only mention \R for Hebrew.
The package arabi that is used for Farsi and Arabic states that one has to use \AR and \FR, so I'm
absolutely sure that I'm correct.
The example file certainly won't work, because it's
not in real arabic (attachment 1308)...
But its language is set to Arabic so what do you mean?
I'm trying this out right now (with real arabic), and my main problem
ATM is with loading the appropriate fonts.
Follow this guideline:
http://wiki.lyx.org/Windows/Arabic
(ignore MiKTeX)
Also, the line \usepackage[T1]{fontenc} in the generated latex file seems a little
suspect to me, but I'm not sure.
You are right, the correct call according to the documentation of the arabi
package is
\usepackage[LAE,LFE]{fontenc}
and when also other languages than Arabic and Farsi are used it is
\usepackage[T1,LAE,LFE]{fontenc}
Do you know of anyone who used to be able to use arabic in LyX, but
can't anymore?
The problem is that Arabic could never be used due to this bug and the now
fixed bug 2927.
regards Uwe
State of outline panel not saved
Hi, LyX 1.5 remembers the state and position of all toolbars, but this doesn't seem to work for the outline panel. I like to have it docked to the right size of the screen, but now I have to enable and move it every time I start LyX. The panel uses the same positioning system as the toolbars, so it should be easy to include it too, right? Regards, Joost
Re: State of outline panel not saved
Le 17 juin 07 à 23:12, Joost Verburg a écrit : Hi, LyX 1.5 remembers the state and position of all toolbars, but this doesn't seem to work for the outline panel. I like to have it docked to the right size of the screen, but now I have to enable and move it every time I start LyX. There's already a bug for its status: #3842. Its position (or width under Mac OS) may also be usefull to save, however... I added this info to the bug. Mael.
Re: help needed from BiDi people
Okay, I finally got arabic sort of working in latex, but the debian
packages don't seem to be in such great shape yet. First of all, it was
looking for Arabicore.sty, when in fact I have arabicore.sty (a legacy
from non-case-sensitive OSes...?); and I'm getting a conflict between
arabi and arabtex, so at the moment I only have arabi installed.
Anyhow, at least I can try some of these things out now, see below...
Uwe Stöhr wrote:
Dov Feldstern schrieb:
Uwe, what are you basing this claim on?
And how do you know that it
doesn't really work?
Test out the small TeX-file in
http://bugzilla.lyx.org/show_bug.cgi?id=2928#c9
When you use Hebrew additionally it works.
The file as it is doesn't compile. I believe the babel line should read:
\usepackage[english,arabic]{babel}
Then it works (with the beginR, endR stuff). But no need to define
hebrew anywhere...
I also looked at the source code of babel and the command \R is only
defined when Hebrew is used.
(I reported this also to the babel maintainer.)
The LaTeX companion also only mention \R for Hebrew.
The package arabi that is used for Farsi and Arabic states that one has
to use \AR and \FR, so I'm absolutely sure that I'm correct.
Regarding the \R vs. \AR --- I believe that is Arabi-specific. It
certainly makes sense to have the different \AR, \FR, and there should
be \HR, too. But AFAIU, babel defines just plain \R. Most of what I know
about this is from Mostafa's explanations...
The example file certainly won't work, because it's not in real arabic
(attachment 1308)...
But its language is set to Arabic so what do you mean?
Well, the encoding of the letters is not really correct, but I see that
it is generating something (gibberish, but that's something), so I guess
it handles different encodings. The standard encoding that I know of is
cp1256 for Arabic, and that's what LyX writes when you type in Arabic
through the GUI, using the arabic keymap. This seems to be working fine,
BTW: I can type real Arabic in the GUI, and it outputs correctly to the DVI.
I'm trying this out right now (with real arabic), and my main problem
ATM is with loading the appropriate fonts.
Follow this guideline:
http://wiki.lyx.org/Windows/Arabic
(ignore MiKTeX)
Yeah, as I said, I had some debian-specific problems here...
Also, the line \usepackage[T1]{fontenc} in the generated latex file
seems a little suspect to me, but I'm not sure.
You are right, the correct call according to the documentation of the
arabi package is
\usepackage[LAE,LFE]{fontenc}
and when also other languages than Arabic and Farsi are used it is
\usepackage[T1,LAE,LFE]{fontenc}
I think you're right, but it doesn't seem to be making a difference
either way...
Do you know of anyone who used to be able to use arabic in LyX, but
can't anymore?
The problem is that Arabic could never be used due to this bug and the
now fixed bug 2927.
regards Uwe
Anyhow, to sum this up: before going and fixing LyX, we need to make
sure we know exactly how the underlying latex packages work, and the
impression that I'm getting is that we're not totally clear about that
yet --- I certainly don't really understand this...
I really wish we had people who really use Arabic and latex, who could
tell us which packages are usually used, whether they ever mix
languages, etc. We're just playing around, but we don't know how things
are really done...
Dov
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
On Sun, 17 Jun 2007, Joost Verburg wrote: Uwe Stöhr wrote: So could you also provide the now missing Aspell dictionaries at ftp.lyx.org or was there a reason why you don't build the dictionaries for all languages? The other languages are not supported by LyX, so I don't see any reason to make dictionaries available for these languages. Hmm.. So if LyX starts supporting another language we'll have to remember to add the dictionary? I think it makes sense create all the dictionaries now and be done with it. Or does that require a lot of resources of some form? /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Insets Data Structure (was: Re: 20% speedup of paragraph redraw with simple patch)
Jean-Marc Lasgouttes wrote: Dov == Dov Feldstern [EMAIL PROTECTED] writes: Dov Hmm, I just came across this yesterday when trying to figure out Dov what was going on with bug 3011, and wondered about it. I'm not Dov sure if this is what you mean or not, but it might be relevant... Dov http://www.lyx.org/trac/browser/lyx-devel/trunk/src/Paragraph.cpp?rev=18599#L446 Yes, what I mean is that in this case we would have to recreate the structure instead of update it. I do not know how costly it is but Abdel is confident that it is not a problem. JMarc Why do we need that structure at all? Given that our char_type is 32-bits, and we don't use all 32, we could do something like the following: the insets themselves could be stored in a hash table, without storing their positions in that structure. At each position in the paragraph where an inset appears, instead of just the META_INSET character, we store an actual key into the hash table. (From the comment on META_INSET I understand that we don't use any values above 0x20001 --- which means that we have more than enough room for keys to as many insets as we'd like in a single paragraph...). Then, there's no need of keeping the insets structure in sync with the paragraph itself after every insertion...
Re: help needed from BiDi people
Dov Feldstern schrieb:
Test out the small TeX-file in
http://bugzilla.lyx.org/show_bug.cgi?id=2928#c9
When you use Hebrew additionally it works.
The file as it is doesn't compile. I believe the babel line should read:
\usepackage[english,arabic]{babel}
It doesn't matter where you define the package options. LyX defines the languages options in the
docmentclass call.
Then it works (with the beginR, endR stuff). But no need to define
hebrew anywhere...
That's what I wrote in the bug report, \beginR works but this is no solution as babel defines for
many reasons the \R command instead and also provides some other internal methods to balance out the
\beginR \endR commands internally.
Regarding the \R vs. \AR --- I believe that is Arabi-specific.
Yes but without arabi you can't typeset Arabic and Farsi. Arabic is not officially full supported by
babel and Farsi is in general not supported by babel. The arabi-package adds the babel support for
the two languages
It certainly makes sense to have the different \AR, \FR, and there should
be \HR, too.
No need because for Hebrew we have already the \R command.
The example file certainly won't work, because it's not in real
arabic (attachment 1308)...
But its language is set to Arabic so what do you mean?
Well, the encoding of the letters is not really correct, but I see that
it is generating something (gibberish, but that's something), so I guess
it handles different encodings.
What is the problem? The file uses the correct cp1256 encoding. And that I used latin letters there
as example doesn't matter as the problem is the \R command.
You are right, the correct call according to the documentation of the
arabi package is
\usepackage[LAE,LFE]{fontenc}
and when also other languages than Arabic and Farsi are used it is
\usepackage[T1,LAE,LFE]{fontenc}
I think you're right, but it doesn't seem to be making a difference
either way...
I'm sure there is a good reason why the documentation of arabi requires this.
Anyhow, to sum this up: before going and fixing LyX, we need to make
sure we know exactly how the underlying latex packages work,
I spent today some time to dive into the babel code and think I understood what it does concerning
te \R command.
But in general the easiest and safest way is to follow the guidelines of the used package. When the
different fontenc call and \AR instead of \R is required by the language support package we should
of course do it.
yet --- I certainly don't really understand this...
Please ask me and I try to explain it as I understood it.
I really wish we had people who really use Arabic and latex, who could tell us which packages are
usually used, whether they ever mix languages, etc.
The problem is that people start using a feature after it has been implemented and they see that it
works. Then they come up telling us remaining problems. That's the normal way.
(Concerning Arabic, I find it astonishing that so many people speak Arabic but don't work with it in
the Computer world. Take for example the Wikipedia: Arabic: 240 million speakers, but only 32.000
entries, Nederlands: 25 million speakers and 310.000 entries
The same is when you look at the translations of such big projects like Gnome and KDE and especially
for translations you only need 3-5 enthusiasts. Just a thought.)
regards Uwe
Re: Location of supporting files for the windows installers (Was: RC2 coming soon)
On Sun, 17 Jun 2007, Joost Verburg wrote: The other languages are not supported by LyX, so I don't see any reason to make dictionaries available for these languages. LyX supports now for example Farsi (fa) and Armenian (hy). But anyway ,as people downloaded the other dictionaries, they have a reason for this. We should not impose their will. regards Uwe
Re: RC2 coming soon - math panels patch
On 18/06/2007, at 4:53 AM, [EMAIL PROTECTED] wrote: Re: RC2 coming soon - math panels patch I tested the patch and there are some issues left: - It is still not possible to insert two consecutive symbols because the panel is closed after every selection, see also http://bugzilla.lyx.org/show_bug.cgi?id=3839#c1 - Bug 3840 is not fixed for me. Detaching a panel should be intuitive and the current implementation is not. I takes me 5 minutes until I get it. Besides this I miss than the tooltips aren't shown for the math panels. Tooltips work e.g. for roots, styles, fonts and its subentries are shown in the status bar but e.g. not for the subentries of the Greek, Arrows panels. regards Uwe From my point of view, as a user who really needs it, it works perfectly. Admittedly, Detaching a panel should be intuitive , however, once you find out that to detach a palette you single click once above dashed the line, a palette easily detaches every time (until I accidently discovered this, I spent much time trying to detach by tearing that is, dragging, which I think is probably the intuitive method). Once detached it is certainly possible to insert two consecutive symbols. In fact, you can have as many math palettes open as you like and successfully select symbols from each one into your math box. My understanding of the implementation philosophy, is that when a math palette is attached it should close on selection of a single symbol but if it is detached it should stay open. I don't necessarily agree with this functionality decision, but this is what was decided should happen so from that point of view it works as advertised. Not sure what tooltips are meant? How to use the palette, or what a symbol is for? Whatever, the RC2 decision, I will certainly include in my RC2 build as, for my purposes, it is a tremendous improvement in usability. Irrespective, LyX 1.5 is great, congratulations to the developers on a great and well appreciated effort, Roger
Re: RC2 coming soon - math panels patch
Oops, disregard my last comment regarding tooltips, I just checked bug 3883 and now comprehend! Roger
Can't enter extra whitespace when editing.
Hi all, once upon a time, I could type extra whitespace between words and then it would magically go away when I left that region of text. Now, extra space keypresses have no effect and I feel like I'm in a straight-jacket. I can still insert a space *before* an existing space, because I might be about to type a word between them, just not after one. Anybody else get that feeling or prefer the old behaviour? Also I point out that LyX still allows a permanent dangling space at the end of a paragraph which is even less consistent with the current gestapo behaviour. Have fun, Darren
Possible to lose track of emphasis + shape
Hi all, Select some text, open Edit-Text Style-Customized, set the text Shape to Italic. Now make it Emphasized. This combination makes sense if it appears in a block of text with that Shape but not Emphasized. On the LyX screen it appears to be back to normal. This is going to trap people however. Can we add a visual cue when text is displayed upright but has non-standard styles applied? Such as a light shading behind it? Then you could select a bunch of text to make Italic, select a few words to make Emphasized, and you would see them as normal but with shading. If you now delete all the Italic you won't accidentally lose track of the state of the remaining Italic + Emphasised words. Have fun, Darren
Re: RC2 coming soon - math panels patch
Besides this I miss than the tooltips aren't shown for the math panels. Tooltips work e.g. for roots, styles, fonts and its subentries are shown in the status bar but e.g. not for the subentries of the Greek, Arrows panels. With respect to the tool tips comments. I've just checked the current status bar tool tips but can't see their advantage as the status bar tool tips for roots etc simply repeat what's on the root menu e.g Square root \sqrt. Am I missing something?? Of course, for consistency the tooltips for the math panels should be shown in the status bar. I also noticed a small problem with the root menu; it displays downwards , obscuring the tool tip in the status bar (unless, of course, if its torn off and moved away from the status bar). Is it worth raising a bug on this? The Styles menu, on the other hand, displays upwards thereby not obscuring the status bar. Roger
Re: tear-off math panels
On Tue, Jun 12, 2007 at 11:28:37PM +0200, Edwin Leuven wrote:
+// FIXME: this can go when we move to Qt 4.3
+#define QT_VERSION_CHECK(major, minor, patch)
((major16)|(minor8)|(patch))
+
+#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0)
Wouldn't that give a 'redefine macro' ith 4.3?
Why not simply using 0x40200?
because my compiler doesn't like it?
Erm... seems that the Qt4.1 moc wants 0x040200 and don't understand
QT_VERSION_CHECK(4, 2, 0). I have to use the attached patch in order
to avoid the following compile error:
g++ -DHAVE_CONFIG_H -I. -I../../../../src/frontends/qt4 -I../../../src
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS
-DQ_CYGWIN_WIN -I../../../../src -I../../../../src/frontends
-I../../../../images -I/usr/local/qt4-cygwin/include
-I/usr/local/qt4-cygwin/include/QtCore -I/usr/local/qt4-cygwin/include/QtGui
-I../../../../boost -I../../../../src/frontends/controllers -Wno-uninitialized
-O2 -MT IconPalette.lo -MD -MP -MF .deps/IconPalette.Tpo -c
../../../../src/frontends/qt4/IconPalette.cpp -o IconPalette.o
In file included from ../../../../src/frontends/qt4/IconPalette.cpp:269:
./IconPalette_moc.cpp:46: error: `QWidgetAction' has not been declared
./IconPalette_moc.cpp: In member function `virtual void*
lyx::frontend::IconPalette::qt_metacast(const char*)':
./IconPalette_moc.cpp:60: error: `QWidgetAction' has not been declared
./IconPalette_moc.cpp: In member function `virtual int
lyx::frontend::IconPalette::qt_metacall(QMetaObject::Call, int, void**)':
./IconPalette_moc.cpp:65: error: `QWidgetAction' has not been declared
./IconPalette_moc.cpp:70: error: `enabled' undeclared (first use this function)
./IconPalette_moc.cpp:70: error: (Each undeclared identifier is reported only
once for each function it appears in.)
./IconPalette_moc.cpp:71: error: `iconSizeChanged' undeclared (first use this
function)
./IconPalette_moc.cpp:73: error: `setIconSize' undeclared (first use this
function)
./IconPalette_moc.cpp: At global scope:
./IconPalette_moc.cpp:82: error: no `void
lyx::frontend::IconPalette::enabled(bool)' member function declared in class
`lyx::frontend::IconPalette'
./IconPalette_moc.cpp:89: error: no `void
lyx::frontend::IconPalette::iconSizeChanged(const QSize)' member function
declared in class `lyx::frontend::IconPalette'
make[7]: *** [IconPalette.lo] Error 1
--
Enrico
Index: src/frontends/qt4/IconPalette.h
===
--- src/frontends/qt4/IconPalette.h (revision 18815)
+++ src/frontends/qt4/IconPalette.h (working copy)
@@ -20,7 +20,7 @@
// FIXME: this can go when we move to Qt 4.3
#define QT_VERSION_CHECK(major, minor, patch) ((major16)|(minor8)|(patch))
-#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0)
+#if QT_VERSION = 0x040200
#include QWidgetAction
#endif
@@ -30,7 +30,7 @@ namespace frontend {
/**
* For holding an arbitrary set of icons.
*/
-#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0)
+#if QT_VERSION = 0x040200
class IconPalette : public QWidgetAction {
Q_OBJECT
Re: Updating index file
Steve Litt wrote: On Sunday 17 June 2007 14:26, Frederick Noronha [फ्रेडरिक नोरोन्या] wrote: Hi all, I created an index, and then reworked my book. To my surprise I found the index hadn't been updated. Did I do something wrong? How do I get all the index entries to reflect the latest corrections? Thanks in advance, FN Here's my sure fire way to update the index. Note that I run latex several times to make sure the index gets updated. The actual index updating is done by makeindex, which I believe comes with my LaTeX distribution (tetex). Here's the script I use: Guys, do we do this within LyX? If not, should we? Angus rm -f $1.aux rm -f $1.dvi rm -f $1.ps rm -f $1.pdf rm -f $1.idx rm -f $1.ilg rm -f $1.ind rm -f $1.log rm -f $1.tex rm -f $1.toc lyx --export latex $1.lyx latex $1.tex makeindex $1.idx ilglines=`wc -l $1.ilg | cut -d -f 1` if test $ilglines = 6; then latex $1.tex latex $1.tex # Two commands below DO NOT ensure embedded fonts. # dvips -o $1.ps $1.dvi # ps2pdf $1.ps # Two commands below ensure all fonts embedded! dvips -t letter -Pdownload35 -o $1.ps $1.dvi ps2pdf -dEmbedAllFonts=true $1.ps #nohup gv $1.pdf #exit 0 else echo ERROR: Inspect $1.ilg and $1.ind! gvim $1.ilg $1.ind echo ERROR: Inspect $1.ilg and $1.ind! exit 1 fi SteveT Steve Litt Author: Universal Troubleshooting Process books and courseware http://www.troubleshooters.com/
Chapter* left out of Outline?
Hi all, I just added a heading Appendix in Chaper* environment to the end of my Book class document. It didn't appear in the Outline, whereas all Chapter environments do. Is this on purpose? Wouldn't it make sense to include these too? What if I really want to navigate to the appendix? Have fun, Darren
Spacing around and
Hi all, does anybody else think the spacing around the '' and '' symbols in mathed is excessive? Have fun, Darren
Feature Req: Auto-manage Figures
Hi Everyone, This would be a nice optional feature. It would be nice to automatically manage the connection between external figure files (images etc) and their place in the document. At the most basic level, it would be nice to have an option for lyx to automatically copy any referenced file to a subfolder, e.g. figures/ of where the .lyx file is. At a more advanced level, it would be nice if the external file could be linked to the nearest label entry, such as renaming it to use the nearest label in the filename (plus some unique characters/numbers where more than one external file share the same label). That way I wouldn't have to worry about figures again. I keep thinking of this because when I cut and paste documents together from many sources, the figures end up spread out across my file system. -alex A very happy LyX user.
Re: XPM images --- a thought
On Sat, Jun 16, 2007 at 09:43:50PM -0700, Angus Leeming wrote: > LyX still uses XPM images in lib/images. The XPM format is plain text, > so it still makes sense to store XPM files in the SVN repository > because we get versioning history for free. Clearly, that's not the > case if we were to store a binary image format like PNG. We get the same information with any other file format. And as most of the PNGs are tiny storing full diffs would not even be expensive either. > However, in these days of a PNG-aware frontend, it does seem strange > that we still ship these XPM files to our consumers. Here's a thought: > why don't we make the XPM -> PNG transformation part of the build > process and ship the resulting PNGs? Because that is not needed either. We can just the frontend's resource system and would not need to ship individual files at all. Andre'
Re: XPM images --- a thought
Andre Poenitz wrote: However, in these days of a PNG-aware frontend, it does seem strange that we still ship these XPM files to our consumers. Here's a thought: why don't we make the XPM -> PNG transformation part of the build process and ship the resulting PNGs? Because that is not needed either. We can just the frontend's resource system and would not need to ship individual files at all. Yes, I see you're a Qt convert ;-) Two questions (seriously): * How much work would it be to rip out the current scheme and make use of whatever Qt provides. * Who would maintain this "resource tree"? By which I mean that many of the images LyX uses are unique to LyX, so we won't be able to leverage someone else's database. Or do I misunderstand? Angus
Re: XPM images --- a thought
On Sat, Jun 16, 2007 at 11:43:13PM -0700, Angus Leeming wrote:
> Andre Poenitz wrote:
> >>However, in these days of a PNG-aware frontend, it does seem strange
> >>that we still ship these XPM files to our consumers. Here's a thought:
> >>why don't we make the XPM -> PNG transformation part of the build
> >>process and ship the resulting PNGs?
>
> >Because that is not needed either. We can just the frontend's resource
> >system and would not need to ship individual files at all.
>
> Yes, I see you're a Qt convert ;-)
Certainly not from this proposal as I proposed this already a while ago.
But apart from that I have now an idea what it means in a 'use Qt where
available, third party only when really needed' world. And yes, I like it.
> Two questions (seriously):
> * How much work would it be to rip out the current scheme and make use
> of whatever Qt provides.
The changes in the source are straight forward. Maybe an hour or two.
The 'problem' will be to incorporate the rcc run (see below) into
our three build systems...
> * Who would maintain this "resource tree"? By which I mean that many
> of the images LyX uses are unique to LyX, so we won't be able to
> leverage someone else's database.
>
> Or do I misunderstand?
Qt resources are 'managed' by an xml file, usually ending in .qrc.
Something like
images/1.png
images/2.png
This is converted by a programm called 'rcc' into a .cpp file which
pretty much looks like inlined .xpm. This need to be compiled and
linked to the app as usual.
Resources can be accessed from with the app at any place an ordinary
file can be used, simply by using a ':' prefix and the name from the
.qrc file.
I.e. instead of
QPixmap pm("images/1.png") which needs the image path set correctly
and the image installed as separate file on the client, it would be
QPixmap pm(":images/1.png")
There are no external dependencies.
Maintaining the 'resource tree' is the same work as maintaining an
Makefile.am, i.e. add a line whenever a new pixmap is needed.
Andre'
Re: Shaded note => Colored Note???
why is a "shaded note" called "shaded"? AFAICS, a shaded note is in
fact a colored note both on screen and in LaTeX output!
I suggest renaming the menu item and the underlying code. If you
agree, I will prepare a patch.
Here comes a first proposal that cleans up the code. Personally, I
think that we call too many things a note. At least, we are supposed to
be consistent (internally & externally) with this patch.
What is missing is a lyx2lyx converter that converts the two former note
types (Note & Shaded) to
\begin_inset Note LyXInternal
and
\begin_inset Note Colored
Any volunteer? Any comments?
Michael
Index: src/Color.h
===
--- src/Color.h (Revision 18810)
+++ src/Color.h (Arbeitskopie)
@@ -85,20 +85,20 @@
/// The color used for previews
preview,
- /// Text color for notes
- note,
- /// Background color of notes
- notebg,
- /// Text color for comments
- comment,
- /// Background color of comments
- commentbg,
- /// Text color for greyedout inset
- greyedout,
- /// Background color of greyedout inset
- greyedoutbg,
- /// Shaded box background
- shadedbg,
+ /// Text color for lyx-internal notes
+ notelyxinternal,
+ /// Background color of lyx-internal notes
+ notelyxinternalbg,
+ /// Text color for tex comments
+ notecomment,
+ /// Background color of tex comments
+ notecommentbg,
+ /// Text color for greyedout notes
+ notegreyedout,
+ /// Background color of greyedout notes
+ notegreyedoutbg,
+ /// Background color of colored notes
+ notecoloredbg,
/// Color for the depth bars in the margin
depthbar,
Index: src/insets/InsetNomencl.cpp
===
--- src/insets/InsetNomencl.cpp (Revision 18810)
+++ src/insets/InsetNomencl.cpp (Arbeitskopie)
@@ -97,7 +97,7 @@
newlines += static_cast(*it).docbookGlossary(os);
++it;
} else if(it->lyxCode() == Inset::NOTE_CODE &&
- static_cast(*it).params().type == InsetNoteParams::Note) {
+ static_cast(*it).params().type == InsetNoteParams::LyXInternal) {
// Don't output anything nested in note insets
size_t const depth = it.depth();
++it;
Index: src/insets/InsetNote.cpp
===
--- src/insets/InsetNote.cpp (Revision 18810)
+++ src/insets/InsetNote.cpp (Arbeitskopie)
@@ -50,22 +50,22 @@
NoteTranslator const init_notetranslator()
{
- NoteTranslator translator("Note", InsetNoteParams::Note);
+ NoteTranslator translator("LyXInternal", InsetNoteParams::LyXInternal);
translator.addPair("Comment", InsetNoteParams::Comment);
translator.addPair("Greyedout", InsetNoteParams::Greyedout);
translator.addPair("Framed", InsetNoteParams::Framed);
- translator.addPair("Shaded", InsetNoteParams::Shaded);
+ translator.addPair("Colored", InsetNoteParams::Colored);
return translator;
}
NoteTranslatorLoc const init_notetranslator_loc()
{
- NoteTranslatorLoc translator(_("Note"), InsetNoteParams::Note);
+ NoteTranslatorLoc translator(_("LyX-internal"), InsetNoteParams::LyXInternal);
translator.addPair(_("Comment"), InsetNoteParams::Comment);
translator.addPair(_("Greyed out"), InsetNoteParams::Greyedout);
translator.addPair(_("Framed"), InsetNoteParams::Framed);
- translator.addPair(_("Shaded"), InsetNoteParams::Shaded);
+ translator.addPair(_("Colored"), InsetNoteParams::Colored);
return translator;
}
@@ -89,7 +89,7 @@
InsetNoteParams::InsetNoteParams()
- : type(Note)
+ : type(LyXInternal)
{}
@@ -152,7 +152,7 @@
{
switch (params_.type) {
case InsetNoteParams::Framed:
- case InsetNoteParams::Shaded:
+ case InsetNoteParams::Colored:
return AlignLeft;
default:
return Inline;
@@ -186,20 +186,20 @@
Color_color c;
switch (params_.type) {
- case InsetNoteParams::Note:
- c = Color::note;
+ case InsetNoteParams::LyXInternal:
+ c = Color::notelyxinternal;
break;
case InsetNoteParams::Comment:
- c = Color::comment;
+ c = Color::notecomment;
break;
case InsetNoteParams::Greyedout:
- c = Color::greyedout;
+ c = Color::notegreyedout;
break;
case InsetNoteParams::Framed:
- c = Color::greyedout;
+ c = Color::notegreyedout;
break;
- case InsetNoteParams::Shaded:
- c = Color::greyedout;
+ case InsetNoteParams::Colored:
+ c = Color::notegreyedout;
break;
}
font.setColor(c);
@@ -211,20 +211,20 @@
{
Color_color c;
switch (params_.type) {
- case InsetNoteParams::Note:
- c = Color::notebg;
+ case InsetNoteParams::LyXInternal:
+ c = Color::notelyxinternalbg;
break;
case InsetNoteParams::Comment:
- c = Color::commentbg;
+ c = Color::notecommentbg;
break;
case InsetNoteParams::Greyedout:
- c = Color::greyedoutbg;
+ c = Color::notegreyedoutbg;
break;
case InsetNoteParams::Framed:
- c = Color::greyedoutbg;
+ c = Color::notegreyedoutbg;
break;
- case InsetNoteParams::Shaded:
- c = Color::shadedbg;
+ case
Re: RC2 coming soon
José Matos wrote: > > what about > > > > http://bugzilla.lyx.org/show_bug.cgi?id=3840 > > and > > http://bugzilla.lyx.org/show_bug.cgi?id=3839 > > If Jürgen gives an OK to these I give my OK as well. If it works as advertised, I think it should go in. Edwin, if you post the most recent patch again, I'll text it. Jürgen
Re: RC2 coming soon
Jürgen Spitzmüller wrote: José Matos wrote: what about http://bugzilla.lyx.org/show_bug.cgi?id=3840 and http://bugzilla.lyx.org/show_bug.cgi?id=3839 If Jürgen gives an OK to these I give my OK as well. If it works as advertised, I think it should go in. Edwin, if you post the most recent patch again, I'll text it. you'll find it here: http://article.gmane.org/gmane.editors.lyx.devel/87886
[patch] fix broken listings ui
OK? Jürgen Index: src/frontends/qt4/ui/ListingsUi.ui === --- src/frontends/qt4/ui/ListingsUi.ui (Revision 18810) +++ src/frontends/qt4/ui/ListingsUi.ui (Arbeitskopie) @@ -18,15 +18,23 @@ true - + 9 6 - + + + + 3 + 3 + 0 + 0 + + 0 @@ -185,10 +193,10 @@ - - + + - Range + Placement @@ -197,110 +205,49 @@ 6 - - - - Last line: + + + + Specify placement (htbp) for floating listings - - false - - - lastlineLE - - - + + - The last line to be printed + Check for floating listings - + Float - - Qt::AlignLeading - - - + + - The first line to be printed + Check for inline listings - + Inline listing - - Qt::AlignLeading - - - + + - First line: + Placement: false - firstlineLE + placementLE - - - - Language - - - - 9 - - - 6 - - - - - Select the dialect of the programming language, if available - - - - - - - Dialect: - - - dialectCO - - - - - - - Language: - - - languageCO - - - - - - - Select the programming language - - - - - - @@ -417,10 +364,10 @@ - - + + - Placement + Language @@ -429,43 +376,104 @@ 6 - - + + - Specify placement (htbp) for floating listings + Select the dialect of the programming language, if available - - + + + + Dialect: + + + dialectCO + + + + + + + Language: + + + languageCO + + + + + - Check for floating listings + Select the programming language + + + + + + + + + Range + + + + 9 + + + 6 + + + - Float + Last line: + + false + + + lastlineLE + - - + + - Check for inline listings + The last line to be printed - Inline listing + + + Qt::AlignLeading + - - + + + + The first line to be printed + - Placement: + + + Qt::AlignLeading + + + + + + + First line: + false - placementLE + firstlineLE @@ -478,90 +486,100 @@ Advanced - - - - 9 - 9 -
Re: [patch] fix broken listings ui
On 6/17/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote: OK? What was broken? Bo
Re: Shaded note => Colored Note???
On Sun, Jun 17, 2007 at 11:19:37AM +0200, Michael Gerz wrote: > Here comes a first proposal that cleans up the code. Personally, I > think that we call too many things a note. At least, we are supposed to > be consistent (internally & externally) with this patch. > > What is missing is a lyx2lyx converter that converts the two former note > types (Note & Shaded) to > >\begin_inset Note LyXInternal > > and > >\begin_inset Note Colored > > Any volunteer? Any comments? Just a comment. With this patch you are going to break compatibility with existing preferences and lyxrc.dist files. Please, don't do that. -1 -- Enrico
Re: Shaded note => Colored Note???
Also, we are supposed to focus on critical bugs now. -1 Bo
Re: RC2 coming soon
> We are also finding a second home for aspell dictionaries so that the > windows installer will work even ftp.lyx.org is unusable. What about the berlios.de repository that I currently use in LyXWinInstaller as second home for the dictionaries?: http://developer.berlios.de/project/showfiles.php?group_id=5117_id=9651 regards Uwe
Re: [patch] Space displayed after macro, #3705
On Fri, Jun 15, 2007 at 08:39:14AM +0200, Stefan Schimanski wrote:
Here is a patch for http://bugzilla.lyx.org/show_bug.cgi?id=3705. It
adds the kerning method to a macro to inherit the kerning from the
expanded form. Moreover the marker metrics calls are remove as they
are not drawn anyway.
Stefan
Index: src/mathed/MathMacro.h
===
--- src/mathed/MathMacro.h (Revision 18774)
+++ src/mathed/MathMacro.h (Arbeitskopie)
@@ -54,6 +54,8 @@
///
docstring name() const;
///
+ int kerning() const { return kerning_; }
Could that be
int kerning() const { return expanded_.kerning(); }
or is expanded_ smashed before we access its kerning?
The expanded_ only makes sense if not edited. Even if the value of it
might sense in edit mode as well I wouldn't depend on it. Those
implicit assumptions pay back if you change the code months later and
you don't remember about it. Here a few pixels have no consequences
of course... But also inlining has no effect here with a virtual method.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Re: RC2 coming soon
What about the berlios.de repository that I currently use in LyXWinInstaller as second home for the dictionaries?: http://developer.berlios.de/project/showfiles.php?group_id=5117_id=9651 I am not sure because Joost said that these dictionaries are for an earlier version of aspell and can not be used for the one compiled for the official installer. Bo
Re: RC2 coming soon
Bo Peng schrieb: I am not sure because Joost said that these dictionaries are for an earlier version of aspell and can not be used for the one compiled for the official installer. I can upload the actual ones tomorrow, no problem. But also the current dictionaries work well together with the one compiled for the official installer. regards Uwe
Re: RC2 coming soon - math panels patch
> If it works as advertised, I think it should go in. I tested the patch and there are some issues left: - It is still not possible to insert two consecutive symbols because the panel is closed after every selection, see also http://bugzilla.lyx.org/show_bug.cgi?id=3839#c1 - Bug 3840 is not fixed for me. Detaching a panel should be intuitive and the current implementation is not. I takes me 5 minutes until I get it. Besides this I miss than the tooltips aren't shown for the math panels. Tooltips work e.g. for roots, styles, fonts and its subentries are shown in the status bar but e.g. not for the subentries of the Greek, Arrows panels. regards Uwe
[patch] was: help needed for bug 3878
Attached a correct patch from Georg. As > Bug 3878 http://bugzilla.lyx.org/show_bug.cgi?id=3878 prevents the Userguide from beeing compiled this should go in before RC2. Bug 1942 is still not fixed, but this can be done later as this is a cosmetic bug. Seeking for another OK to commit. regards Uwe
Re: RC2 coming soon - math panels patch
Uwe Stöhr wrote: > If it works as advertised, I think it should go in. I tested the patch and there are some issues left: - It is still not possible to insert two consecutive symbols because the panel is closed after every selection, see also http://bugzilla.lyx.org/show_bug.cgi?id=3839#c1 this is intentional. - Bug 3840 is not fixed for me. Detaching a panel should be intuitive and the current implementation is not. this is how qt does it... I takes me 5 minutes until I get it. but the good thing is that once you get it you get it... ... to take a bit of perspective: the patch does not change behavior wrt the current situation but it *does* allow you to tear off the menu's (a so-called pareto improvement: someone benefits without making others worse off...) Besides this I miss than the tooltips aren't shown for the math panels. Tooltips work e.g. for roots, styles, fonts and its subentries are shown in the status bar but e.g. not for the subentries of the Greek, Arrows panels. i know. perhaps you could file a bug... thanks for testing
Re: Meaning of Outline
On Sat, 16 Jun 2007, Ramon Flores wrote:
Richard Heck wrote:
Alfredo Braunstein wrote:
07. A summary of a written work or speech, usually analyzed in headings
and subheadings.
7, 12, 15 (your dictionary is a bit redundant) ;-)
In this sense, an outline might look like this:
I. Introduction
A. First Topic
B. Second Topic
II. Section One
A. First Issue
i. First sub-issue
etc. I'm not sure any of the definitions, other than (7), quite get at this
meaning. But maybe one would call that a "formal outline" or something of the
sort.
And what is the difference between "Outline" and "TOC" ?
Outline is more general than TOC, and can contain more that just the
headings. In fact, it doesn't really have to contain the headings at all.
I've used outlines ('disposition' in Swedish) as a tool that helps me to
structure and plan the work before, and during, the writing process.
An outline for a scientific paper could go like this (in a bullet form):
* Introduction - introduce the problem area to the reader, make it
interesting so that he'll continue reading.
** Describe application 'X' as suitable for this solution.
** General background - give more general background and describe related
work
** Theoretical background - go throuh related theory to prepare reader
for the new stuff
* Theory/hypothesis - introduce my new cool theory
* Experiments - describe an experiment I've done to support my theory.
* Results - describe the results.
** Remember to emphasize aspect 'Z' of experiment one.
* Conclusion and discussions
It doesn't have to contain the exact section headings of the final paper,
for me it's a help to _outline_ the flow of the paper.
Hope this helps
/Christian
--
Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: [patch] Space displayed after macro, #3705
On Sun, Jun 17, 2007 at 06:02:19PM +0200, Stefan Schimanski wrote:
> >On Fri, Jun 15, 2007 at 08:39:14AM +0200, Stefan Schimanski wrote:
> >>Here is a patch for http://bugzilla.lyx.org/show_bug.cgi?id=3705. It
> >>adds the kerning method to a macro to inherit the kerning from the
> >>expanded form. Moreover the marker metrics calls are remove as they
> >>are not drawn anyway.
> >>
> >>Stefan
> >>
> >>Index: src/mathed/MathMacro.h
> >>===
> >>--- src/mathed/MathMacro.h (Revision 18774)
> >>+++ src/mathed/MathMacro.h (Arbeitskopie)
> >>@@ -54,6 +54,8 @@
> >>///
> >>docstring name() const;
> >>///
> >>+ int kerning() const { return kerning_; }
> >
> >Could that be
> >
> > int kerning() const { return expanded_.kerning(); }
> >
> >or is expanded_ smashed before we access its kerning?
>
> The expanded_ only makes sense if not edited. Even if the value of it
> might sense in edit mode as well I wouldn't depend on it. Those
> implicit assumptions pay back if you change the code months later and
> you don't remember about it. Here a few pixels have no consequences
> of course... But also inlining has no effect here with a virtual method.
It's not about inlining, it's about that extra kerning_ member that
needs to be kept in sync with expanded_.kerning()
Andre'
