Hello,
next patch:
the use of backspacePos0 is dangerous as it does not honour change tracking =>
make it a private method; clarify the description of backspacePos0 (it does not
always merge paragraphs)
As usual: committed!
Michael
Index: lyxtext.h
===
Hi,
this patch fixes a double-to-int conversion. (already committed)
Michael
Index: rowpainter.C
===
--- rowpainter.C (Revision 16028)
+++ rowpainter.C (Arbeitskopie)
@@ -48,7 +48,6 @@
using std::endl;
using std::max;
-using std
Hi,
this patch fixes two problems with end-of-par handling. I tested it
successfully and rigorously.
I already committed it to speed up development. If you think that
something is wrong, I will revert the patch instantly.
Michael
Index: text.C
===
Michael Gerz wrote:
Jean-Marc Lasgouttes wrote:
Does this look like something for 1.4 too?
Probably. However, CT in 1.5 works slightly different than in 1.4.
Frankly speaking, I gave up backporting patches. IMHO CT is uncureable
in 1.4 :-(
We need the same logic at other places, too
Jean-Marc Lasgouttes wrote:
Does this look like something for 1.4 too?
Probably. However, CT in 1.5 works slightly different than in 1.4.
Frankly speaking, I gave up backporting patches. IMHO CT is uncureable
in 1.4 :-(
Michael
Bjønnes
* \author Alfredo Braunstein
+ * \author Michael Gerz
*
* Full author contact details are available in file CREDITS.
*/
@@ -292,18 +293,23 @@
return PitPosPair(endpit, endpos);
}
- // A paragraph break has to be physically removed by merging, but
- // only if either (1) change
Michael Gerz wrote:
Since end-of-pars also show up in insets (which have almost no
margin), I was looking for a compact, non-intrusive representation.
I just committed the attached patch. Sorry guys, I had to increase
TEXT_TO_INSET_OFFSET by 2 pixels...
BTW: Thanks to the visual marker, it
José Matos wrote:
Some question to developer (in no particular order):
What are your plans?
- Fix at least some of the remaining CT problems;
- Add a visual mark for deleted/inserted end-of-pars (I will commit
this evening).
- Do some German translation; ask other translators to up
Hi,
for change tracking purposes, we definitely must visualize deleted and
inserted paragraph breaks. The attached patch makes it happen.
Non-CT'ed paragraph breaks are not shown (only deleted and inserted
ones) in order not to confuse the user.
Since end-of-pars also show up in insets (whi
Hi,
inset-dissolve seems to be CT-agnostic.
Michael
* new document; insert note; insert "hello" into note; place the cursor
at the beginning of the note;
activate change tracking; press backspace => seg fault
#0 0x08101348 in lyx::Paragraph::Pimpl::setChange (this=0x8a9e0a0,
pos=0, [EMA
* new document; insert note; place cursor in front of the note; activate
change tracking;
press delete =>
Assertion triggered in void
lyx::LyXText::setCursorIntern(lyx::LCursor&, int, int, bool, bool) by
failing check
"this == cur.text()" in file /home/software/lyx-trunk/src/text2.C:719
Andreas Karlsson wrote:
That's why I suggested to include "Footnote" and "Marginal note" in
"Insert > Note >", which would remove two entries from from the
"Insert" menu and make room for "Break" and "Space" as separate
submenus in the "Insert" menu.
Hmmm... what do others think about it?
T
Georg Baum wrote:
Why not
+ QString const text = lyx_version ? QString(lyx_version) :
qt_("version unknown");
and remove the toqstr() lateron?
Good idea!
Michael
Pavel Sanda wrote:
2. Not all menu entries in Toolbars cant be translated, as they are not listed
in .po.
Please send me a list of those entries and I will try to fix the problem
in the next couple of days.
Michael
Andreas Karlsson wrote:
Another suggestion is to have a new entry in the Insert menu: Insert >
Break and put all break commands there, i.e.,
Insert > Break> Newline
Insert > Break> Line break
Insert > Break> New page
Insert > Break> Page break
Insert > Break> Clear page
Insert > Break> Clear d
Andreas Karlsson wrote:
It is somewhat contradictory to have
Insert > Note > LyX Note
Insert > Note > Comment
Insert > Note > Grayed out
and at the same time have
Insert > Footnote
Insert > Marginal note
I think the separation makes sense. The first three entries are "real"
notes that are
Georg, all,
is this a proper use of to_ascii?
Michael
Index: qt4/GuiWorkArea.C
===
--- qt4/GuiWorkArea.C (Revision 15938)
+++ qt4/GuiWorkArea.C (Arbeitskopie)
@@ -18,6 +18,7 @@
#include "QLyXKeySym.h"
#include "qt_helpers.h"
Leuven, E. wrote:
i played a bit around and the results are here:
http://leuven.ecodip.net/lyx/changes.zip
opinions/suggestions?
The icons look nice but IMHO the current icon set is more intuitive.
For instance, the icons for all-changes-accept/all-changes-reject have a
pointer (arrow) wh
Edwin Leuven wrote:
is there a reason to have both M_TOGGLE_LINE_TOP and TOGGLE_LINE_TOP ?
couldn't we just have one TOGGLE_LINE_TOP and set the proper flags
depending whether we are in a multicolumn cell or not?
This is exactly what I proposed for 1.4 :-)
Michael
Dear Jose,
Nov 13th is getting closer (oops, it's already there) and, to my
greatest regret, I haven't managed to fix all CT problems.
AFAICS, the following things do not work presently:
- No change bar is given in LaTeX output if (only) the par break has changed
- No visual clue is presente
Pavel Sanda schrieb:
i dont think this explains/corrects everything. e.g. "Look and feel" are not
part
of the menu. even in new remerged .po i cant see the string for translation.
in the initial revision the string and the translation was there.
??? Hmmm I don't feel guilty. Where is "Lo
Hello, German users,
I have just committed some updates to de.po. The German localization
should be more or less useable now. There are still about 150 messages
to be translated but the most important ones (menu entries) are done.
(It took quite some time to get all the shortcuts right.)
I w
Hello,
are we going to maintain classic.ui for LyX 1.5.0?
I guess it is neither "feature complete" nor does it reflect the latest
bookmark changes. There may also be some problems with shortcuts.
I am tempted to remove it from the repository. What do you think?
Michael
Georg Baum wrote:
Because of the recent translation remerge the translations for this tstring
are lost. This is a reminder that a suffix [[]] of a message is a
translation hint for ambigous messages. It gets stripped if no translation
is provided, and it should not be removed!
FYI: I w
Enrico Forestieri wrote:
I have them. I see a change bar only if I make another change other
than deleting the end of paragraph.
I attach here the latex file exported from LyX. If this works for
you, I think I may have some other problem with wide streams on
cygwin.
I will have look - proba
Enrico Forestieri wrote:
Sorry, but I don't get a changebar in the output when using the
attached file.
IIRC you need pplatex and dvipost.
Michael
Georg Baum wrote:
I believe that a special end-of-paragraph inset will create other problems:
It must never be placed anywhere else than at the end of a paragraph. This
will probably require some code to ensure that. It cannot be selected by
the user, because it is not visible. There are proba
Enrico Forestieri wrote:
In LyX I see a changebar when I delete and end of paragraph, so I know
something changed even if I don't see what. Could the latex output be
adapted to at least show a changebar?
Yes, the LaTeX output shows a changebar if "Show changes in output" is
activated.
As
Pavel Sanda wrote:
* when opening already opened document(or document with newer backup), mouse
pointer
is switched into the clock, although it waits for confirmation dialog.
I added it to Status.15x.
* backuping works weirdly
A known issue.
* environments when using czech translat
Michael Gerz wrote:
int Paragraph::Pimpl::eraseChars(pos_type start, pos_type end, bool
trackChanges)
{
BOOST_ASSERT(start >= 0 && start <= size());
BOOST_ASSERT(end > start && end <= size() + 1);
I check for end > start, because the caller of er
Michael Gerz wrote:
Thus my question: Do you think that it is worth changing the current
approach? Or do you think that the restriction imposed by (2) is
acceptable from a user's perspective (After all, it may be a matter of
how this happens).
... how OFTEN this happens ...
Personal
Hello everybody,
I need your advice on a possibly critical issue:
Presently, LyX does not have an end-of-par character. However, for
change tracking purposes, it is essential to track the deletion and
insertion of paragraph breaks. Therefore, in the LyX 1.4 code (and also
in the current 1.5 i
Hello! (Jean-Marc, are you still awake?)
Recently, I added a couple of new assertions to Paragraph::Pimpl.
Among others, I added:
int Paragraph::Pimpl::eraseChars(pos_type start, pos_type end, bool
trackChanges)
{
BOOST_ASSERT(start >= 0 && start <= size());
BOOST_ASSERT(end >
Hi,
by accident, I came acress these lines of code.
PitPosPair eraseSelectionHelper(BufferParams const & params,
ParagraphList & pars,
pit_type startpit, pit_type endpit,
int startpos, int endpos, bool doclear)
{
// Start of selection is really invalid.
if (sta
Georg Baum wrote:
Yes, and we did until some time ago. I don't know who changed it and why,
thi should be changed back IMHO.
I guess something went wrong when we put everything in namespace lyx.
The attached patch fixed assertion handling. I will commit in a minute...
Michael
Index: boost
Jean-Marc Lasgouttes wrote:
We call support::abort(), don't we?
No, we don't. Shall I add this to function assertion_failed()?
Michael
Hi,
why don't we stop LyX, if an assertion failed? I though this was the
overall purpose of assertions...
void assertion_failed(char const* a, char const* b, char const* c, long d)
{
lyx::lyxerr << "Assertion failed: " << a << ' ' << b << ' ' << c
<< ' '
<< d << '\n';
}
Lars Gullik Bjønnes wrote:
And you now have to add comments to tell what the loop is doing
instead of having that implied by the name of the function for_each
calls...
C'mon Lars, there is a big fat comment inside of the loop!
Do you want me to explain what a loop is? How many loop does LyX
>On Wednesday 08 November 2006 8:54 am, Jean-Marc Lasgouttes wrote:
>>
>> Ha! The spellchecker is such a mess that these bugs are horrible to
>> fix. It needs at least a small facelift to be usable.
>
> I will shoot the first who disagrees with you about this. ;-)
>
>José Abílio
And who is going
Jean-Marc Lasgouttes wrote:
* text.C (backspacePos0): rewrite to make it simple and allow
deleting empty paragraphs even when keepempty is true. Do not rely
on dEPM, since this was silly (bugs 2587 and 2882)
(Delete): simplify also and avoid calling backspace.
John Levon wrote:
Whooo! Brain fart time. Sorry Michael.
:-)
I changed the toolbars, not the menus.
I think they are both quite consistent now. I guess the translators will
hate me. Ooops, I'm a translator, too :-)
Michael
Georg Baum wrote:
Because Ugras thought that nomenclature is not well known by non-native
speakers. I don't know Notation either. Should we replace it
with "Glossary and "Glossary Entry" instead?"
As you know, the term "Notation" is quite generic in German. I guess the
same holds in English
Hi,
why are the menu entries called "Notation"?
stdmenus.ui:Item "Notation Entry" "nomencl-insert"
stdmenus.ui:Item "Notation List" "nomencl-print"
stdtoolbars.ui: Item "Insert notation entry" "nomencl-insert"
Michael
Asger Ottar Alstrup wrote:
So, guys, this is your chance to be a hero.
Despite the virtual honour, there are also very concrete prizes to win
(see Status.15x)!
In the testing department, I don't think new showstoppers have
appeared for some time, as far as I can tell.
Pardon? You really
[EMAIL PROTECTED] wrote:
FontSetChanger dummy(pi.base, sym_->inset.c_str());
- // FIXME UNICODE
Hi Georg,
I have two questions:
- What are we going to do with all those unicode-related FIXMEs? Are
they ticking time-bombs or can they stay for 1.5.0?
- Do you have a list of p
Lars Gullik Bjønnes wrote:
Michael Gerz <[EMAIL PROTECTED]> writes:
| Hi,
|
| am I too stupid to see the brilliancy of the code
yes.
(oh where did the friday go...)
It is in the vein of "prefere algorithms to manual constructs"
Anyway, I am going to commit my simplificat
Georg Baum wrote:
Michael Gerz wrote:
Hi,
this patch makes Qt strings translateable again (at least when using
scons).
Can I commit?
No. Adding qt_helpers.h to all includes is wrong. The attached patch
contains an example how to do it correctly (and how it was done in qt3) and
>Jean-Marc Lasgouttes wrote:
>
>> Yes, I suspect that someone wanted to play with all the new toys he
>> read about in a C++ book.
>
>No. resetParagraph was used in two places (see 1.4), therefore it made sense
>to not duplicate the code.
I dropped the second call to resetParagraph because I think
Hi,
I would just like to let you know that I like the multi-windows feature
as it is!
It's really nice to see two windows with the same file.
IMHO Abdel's width adjustment workaround is a proper solution for 1.5.
Michael
Hi,
am I too stupid to see the brilliancy of the code or can cutandpaste.C
be simplified?
Please comment on the attached patch (ignore the CT part).
Michael
Index: CutAndPaste.C
===
--- CutAndPaste.C (Revision 15770)
+++ CutAndPa
Hi,
this patch makes Qt strings translateable again (at least when using scons).
Can I commit?
Michael
Index: src/frontends/qt4/QERTDialog.h
===
--- src/frontends/qt4/QERTDialog.h (Revision 15770)
+++ src/frontends/qt4/QERTDialog.h
Georg Baum wrote:
Because qt_() is the translation function that returns a QString (defined in
qt_helpers.C). _() would not work, since it returns a docstring. That is
not the reason for the untranslated messages, it was the same in qt3. Did
you look whether uic actually generates calls to qt_()
Hello,
why is it
[EMAIL PROTECTED]:~/lyx-trunk/src/frontends/qt4/ui> grep -2 tr Makefile.am
BUILT_SOURCES = $(UIFILES:.ui=.h)
# Use _() for localization instead of tr() or trUtf8()
UICFLAGS=-tr qt_
and not just
UICFLAGS=-tr _
???
Michael
Abdelrazak Younes wrote:
If you resize one window showing one document, then, if some other
window is also showing, the line breaks in the second window will be
automatically adjusted with the line breaks of the first window,
regardless of the geometry.
I understand this is annoying but mayb
Jean-Marc Lasgouttes wrote:
Asger> I guess he meant Redo, in which case I agree.
So we shall change it (unless we use Ctrl+Y already).
I think so, too. I can have a look later. If CTRL+Y is unbound
presently, I will add the binding.
Michael
Hi,
I am going to commit the following patch:
Index: frontends/qt4/QDelimiterDialog.C
===
--- frontends/qt4/QDelimiterDialog.C(Revision 15750)
+++ frontends/qt4/QDelimiterDialog.C(Arbeitskopie)
@@ -45,8 +45,8 @@
char const *
Alex wrote:
I have successfully resolved the problem with svn.
There was a conflict with my modification and the one coming from the
repository.
In the future, please do not "svn update" while changing your local po
file. I will remerge the po files from time to time such that such
conflict
[EMAIL PROTECTED] wrote:
+Prizes (donated by Michael):
+
+ #1: LyX-labeled Tick Tock Wall Clock
+ #2: LyX-labeled Coffee and Tea Mug
+ #3: LyX-labeled Mousepad
Watch this ^^
Michael
Peter Kümmel wrote:
I've fixed it:
Index: QPrefsDialog.C
===
--- QPrefsDialog.C (revision 15726)
+++ QPrefsDialog.C (working copy)
@@ -938,10 +938,13 @@
void PrefConverters::switch_converter(int nr)
{
- if (nr<0)
+
Hello,
just in case someone is interested in bug reports: please see the
attached file.
I think there is still a lot of work ahead of us...
Michael
Bugs (highest priority first):
- Spell checking cannot be invoked a second time!
- In the TOC dialog, switching between the different TOC
typ
Pavel Sanda wrote:
If appropriate, we took your translations from the 1.4.X stable branch
such that your prior work didn't get lost.
this was not good note ;)
Don't worry, Pavel. In case of cs.po, I kept the 1.5 translations which
were better than the 1.4 translations.
1. more menu it
Juergen Spitzmueller wrote:
I think we could just take some from the KDE classic iconset, where the
other icons are taken from IIRC. Like the attached, for instance.
I committed the icons as xpm files. There is still one icon missing for
"note-next".
Michael
Bo Peng wrote:
./MenuBackend.C:
docstring label = char_type(uppercase(cit->name[0])) +
_(cit->name.substr(1));
You apply _(...) to a substring that is not defined in the po files.
I guess the problem was:
tomenu.add(MenuItem(MenuItem::Command, label,
Michael Gerz wrote:
Ahhh... wait... there is a localization problem! If I switch from
German to English interface, everything works perfectly. I guess there
is one _(...) to much in the code!
Bo,
this will probably not work (not related to the problem above):
./MenuBackend.C
Bo,
if I start LyX 1.5, the "standard" toolbar and the "extra" toolbar are
shown. All other toolbars are invisible.
However, if I look at View>Toolbars, all toolbars seem to be deactivated.
If I click on View>Toolbars>Standard, nothing happens, no matter how
often I try.
Moreover, I cannot
Bo Peng wrote:
What is TabWidget? I will be satisfied with a split (vertical or
horizontal) window option, even if there are at most two windows, and
the split has to be half half.
I agree. A split window would be fine.
Michael
Helge Hafting wrote:
I am working slowly on them help would be appreciated.
I can look at it, like I did for 1.3. It should be simpler now, with
only one frontend.
Should I start with the nb.po that is in lyx1.5svn right now, or
should I wait
for some merge from 1.4?
I already merged wi
>I think we should really release a alpha version
>of LyX 1.5 until Monday, 6. November.
Veto! We agreed on Nov 13th and I need the time for CT.
And, after all, it is Jose who makes the decisions.
Michael
[EMAIL PROTECTED] wrote:
Author: schmitt
Date: Wed Nov 1 22:17:56 2006
New Revision: 15680
URL: http://www.lyx.org/trac/changeset/15680
Log:
* text.C: fix another change tracking FIXME
We are making progress... slowly but constantly.
I may not be able to do much LyX work in the n
Peter Kümmel wrote:
Now is the time to discuss. ;)
We have two possibilities:
1. default is context-sensitive but the manual change to show
when the CT toolbar is hidden will be rememberd forever
2. default is visible and hiding moves the toolbar to the context-sensitive
state
There are
Michael Gerz wrote:
How do the session settings and the default settings in default.ui
interact? Which overrules which?
And do we still need default settings in default.ui at all?
I assume they are obsolete after the first startup, because then the
session info overrule the default.ui
Bo Peng wrote:
1. if math is on when lyx exists, I assume it is always on
2. if math is off when lyx exists, I assume it is auto.
Will it be the same with "review"? Yesterday, I noticed that
context-sensitive toolbars can be a real pain. Just imagine two loaded
documents, one with CT on, the
Dear translators,
the LyX team is working hard on LyX 1.5.0. We intend to publish a first
alpha release by mid-November.
Today, we cleaned up the *.po files in the trunk of the SVN repository.
If appropriate, we took your translations from the 1.4.X stable branch
such that your prior work di
Lars Gullik Bjønnes wrote:
IMHO we should not merge translations from 1.4 at all. (or at most on
a case by case basis. And if translators want it (I don't want it for
NB f.ex.), msgmerge can be used for this.)
Lars, I am a careful man :-)
Right now, I am checking the state of the 1.4 and 1.
Jean-Marc,
I would like to do some translation work in the trunk and I guess others
would like to start as well.
Should we merge the 1.4.X translations with the trunk now or would you
like to wait a little bit longer?
I think we shouldn't wait until 1.4.4 is released even if that means
tha
John Levon wrote:
On Tue, Oct 31, 2006 at 08:12:26PM +0100, Michael Gerz wrote:
Why does the "Review" toolbar have to have the "review" flag? You can
BTW, one comment about the Review toolbar. It's very neat functionality
to have, but it's severely ham
Peter Kümmel wrote:
Anyway, all the toolbar stuff is a moving target so lets not argue
about it.
Yes. And I am not going to touch your code.
Michael
Helge Hafting wrote:
I was hoping to avoid the case where a "new change" happens
in the middle of something, just because a 5-minute border happened
in the middle of some typing. So, merging adjacent changes
(by the same author) that only differ by 5 minutes (or whatever the
granularity becomes
John Levon wrote:
That it just happened without discussion of whether it makes sense,
unlike when I disabled it, when I actually asked people?
Anyway, seems I've been overruled by the current devs, so it doesn't
really matter.
Peter, to tell the truth I am also not happy about your change to
José Matos wrote:
I get yet another type when playing with empty paragraph on both windows.
Assertion failed: pos <= size() const lyx::Change
lyx::Paragraph::lookupChange(lyx::pos_type) const paragraph.C 1420
Assertion failed: pos >= 0 && pos <= size() const lyx::Change
lyx::Paragraph::Pimpl:
Leuven, E. wrote:
i reorganized the first tab as follows:
http://leuven.ecodip.net/lyx/g1.png
http://leuven.ecodip.net/lyx/g2.png
what do you think?
Do "Display" and "Scale(%)" refer to output in LyX? It's not really clear.
If this is the case, I don't like the new tabs. If a user inserts
>Michael> Jean-Marc, I remerged the po files in the stable branch.
>
>Michael> There was a minor problem due to a faulty eol-style in two
>Michael> lib/ui/default-*.ui files. I fixed the svn property.
>
>Thanks.
I also tried to update the German translations. However, for some strange
reason, the
Asger Ottar Alstrup wrote:
An update on the status of 1.5.svn. Nice work, guys - we are down to
just 2 known show-stoppers for a test release:
I think you are a bit too optimistic.
What is the status on the change tracking? Except for icons, is that
work complete for now?
No, there are abo
Georg Baum wrote:
Am Montag, 30. Oktober 2006 19:53 schrieb Michael Gerz:
Index: src/frontends/qt4/QLPainter.C
===
--- src/frontends/qt4/QLPainter.C (Revision 15624)
+++ src/frontends/qt4/QLPainter.C (Arbeitskopie
Jean-Marc,
I remerged the po files in the stable branch.
There was a minor problem due to a faulty eol-style in two
lib/ui/default-*.ui files. I fixed the svn property.
Michael
Hi,
these are the remaining places at which QT3 and GTK are mentioned.
Can I commit?
Michael
Index: src/frontends/WorkArea.h
===
--- src/frontends/WorkArea.h(Revision 15624)
+++ src/frontends/WorkArea.h(Arbeitskopie)
@@ -22
Peter Kümmel wrote:
Ah, I've overlooked it, but it must be "review" "review,top"
if not the flag ToolbarBackend::REVIEW will not be set on the
CT toolbar.
No, it can stay "review" "off,top". Users are able to activate it at
run-time if they like it.
(Before we start another discussion on
Jean-Marc Lasgouttes wrote:
Michael> Bo, will your session management make the settings in
Michael> stdtoolbars.ui obsolete? Or do they co-exist?
Joost, BTW, do you plan to add the extra ui files to 1.5 too? If you
do not do it, people upgrading from 1.4 to 1.5 may have an
unfunctional LyX. So
[EMAIL PROTECTED] wrote:
Author: kuemmel
Date: Sun Oct 29 12:13:46 2006
New Revision: 15598
URL: http://www.lyx.org/trac/changeset/15598
Log:
Show Change Tracking toolbar, prepare hiding/positioning:
Peter, I really would have liked to get Bo's opinion first before you
commit your patch. I
[EMAIL PROTECTED] wrote:
Author: schmitt
Date: Sun Oct 29 22:48:23 2006
New Revision: 15608
URL: http://www.lyx.org/trac/changeset/15608
Log:
change tracking:
* changes.[Ch]: introduce isSimilarTo(...);
restore original operator==;
When merging two adjacent changes, the
Martin Vermeer wrote:
Using operator==() in that case is misleading as we suddenly have
situations with a == b, b == c, and a != c.
For fuzzy comparison, a named function should be used.
Agreed. I wasn't very happy with it, too.
I will fix it in the next commit.
But for adjacenc
Martin Vermeer wrote:
Is it still there? A leftover from the axed nullpainter. Should have
gone long ago...
Ok, I removed it. I remember Asger saying that more than just this
variable can be removed but I have no idea what is meant...
Michael
Michael Gerz wrote:
I changed the CT merge strategy according to the previous discussion.
This patch merges two adjacent changes if they were made by the same
author (the change time is not regarded).
OK to commit?
Michael
Here comes this patch :-(
Michael
Index: src/changes.C
Abdel,
I think this is for you :-)
Michael
/home/software/lyx-trunk/src/frontends/qt4/GuiView.C: In member function `
virtual void lyx::frontend::GuiView::setGeometry(unsigned int,
unsigned int,
int, int, bool)':
/home/software/lyx-trunk/src/frontends/qt4/GuiView.C:164: warning:
converti
I changed the CT merge strategy according to the previous discussion.
This patch merges two adjacent changes if they were made by the same
author (the change time is not regarded).
OK to commit?
Michael
Peter Kümmel wrote:
Why not add a "Show allways the CT toolbar"?
This maps to option "on" in stdtoolbar.ui.
I wonder whether we will have context-sensitive menus at all in 1.5.
Bo, will your session management make the settings in stdtoolbars.ui
obsolete? Or do they co-exist?
Michael
Peter Kümmel wrote:
Have you checked the kde icons? (someone mentioned them)
I had no time so far. Right now, I care for basic CT functionality.
Michael
Do we still need guiapi.[Ch]? Again, it seems like it is not linked to
the final LyX executable.
Michael
Peter Kümmel wrote:
Why should the toolbar be visible when tracking is disabled?
Because I want to switch CT on and off; because there may be changes in
a document even if CT is disabled.
At least we need better icons.
Indeed. Do you volunteer?
Michael
Hello,
what is MathAutoCorrect.[Ch] good for? AFAICS, it is not used in the LyX
executable. Is it obsolete?
Michael
701 - 800 of 1460 matches
Mail list logo
