Bo Peng wrote:
LyX doesn't seem to have a setting for this - I guess the font is
selected
by qt. Run "qtconfig" or "qtconfig-qt4" (whichever you actually have),
then select a font containing chinese characters. Make sure by
pasting chinese into the "sample text" field in qtconfig.
This is
But I know some further tests:
Add a bogus translation to zh_CN.po, using ascii characters.
If you don't see that bogus translation, then something else in LyX
is broken. If you see it - then it really is just a font issue.
I can see all English (non-translated) words.
Another test:
Try pasti
Bo Peng wrote:
Testing other languages isn't that hard, if you want to try.
Example for debian linux:
1. Ensure that the linux distribution itself has language support.
The reason for this is that LyX will not be allowed to select a
GUI language not also supported by the distribution.
Testing other languages isn't that hard, if you want to try.
Example for debian linux:
1. Ensure that the linux distribution itself has language support.
The reason for this is that LyX will not be allowed to select a
GUI language not also supported by the distribution.
a) "apt-get i
On Monday 04 June 2007 16:47:12 Bo Peng wrote:
> Thank you very much, Helge. I have created zh.po following your
> instructions.
>
> Jose, can I add zh.po to lyx? (I will certainly *not* have time to
> complete the translation before 1.5.0, but someone else may be able to
> do it.)
Yes.
> Bo
-
> What is the procedure of adding another language like simplified
> chinese? I do not see any entry like zh or ch.
I am not really an expert on this, I started with an existing language.
I had to move it to a different language code though.
First, decide if it is "zh" or "ch" you want to support
Testing other languages isn't that hard, if you want to try.
Example for debian linux:
My system does not have any of the lyx-supported languages (and I do
not know any of them).
What is the procedure of adding another language like simplified
chinese? I do not see any entry like zh or ch.
Bo
Bo Peng wrote:
File: lib/ui/stdtoolbars.inc
Line: 77
This line says:
TableInsert "Insert table"
Most other toolbar entries are of type "Item", this one is a
"TableInsert".
Perhaps the "TableInsert" have problems with internationalization?
You are right. TableInsert is not handled at
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> JMarc, I am going to make a call tonight or tomorrow morning.
Michael> Sorry, there are busy times these days...
No problem, I was not complaining.
JMarc
Bo Peng wrote:
Does this fixes the problem?
I use English so I can not test, but the string is in the po files
after 'scons update_po'
I will test this (just waiting for compilation of another test patch)
Testing other languages isn't that hard, if you want to try.
Example for debian linux:
JMarc,
I am going to make a call tonight or tomorrow morning. Sorry, there are
busy times these days...
Michael
Does this fixes the problem?
I use English so I can not test, but the string is in the po files
after 'scons update_po'
If yes then put it in.
It is in.
Bo
On Thursday 31 May 2007 15:09:24 Bo Peng wrote:
> Jose, can the attached patch go in?
Does this fixes the problem?
If yes then put it in.
--
José Abílio
File: lib/ui/stdtoolbars.inc
Line: 77
This line says:
TableInsert "Insert table"
Most other toolbar entries are of type "Item", this one is a "TableInsert".
Perhaps the "TableInsert" have problems with internationalization?
You are right. TableInsert is not handled at all. I am not sur
Bo Peng wrote:
No. I checked out the entire source fresh from SVN,
I applied your patch, compiled, remade lyx.pot and the po-files.
Still no go, for "Insert table" is still the tooltip help, and
the string still does not appear in any of the po files.
Maybe this is a lyx_pot.py problem. Please
No. I checked out the entire source fresh from SVN,
I applied your patch, compiled, remade lyx.pot and the po-files.
Still no go, for "Insert table" is still the tooltip help, and
the string still does not appear in any of the po files.
Maybe this is a lyx_pot.py problem. Please describe which
Helge Hafting wrote:
> The patch made no difference for this item, unless there is
> more I have to do to update the po-files?
Don't know. Maybe Michael can help.
> Do you perhaps have some uncommitted patches for the toolbars?
No.
Jürgen
Jürgen Spitzmüller wrote:
Helge Hafting wrote:
"Insert table" (just a table, no float) is a string that
don't exist in either nb.po or de.po.
Does the attached patch help?
No. I checked out the entire source fresh from SVN,
I applied your patch, compiled, remade lyx.pot and the p
Jürgen,
with a little luck, I will be able to do some translator work this
evening - right in time for pre1.
Michael
Jürgen Spitzmüller schrieb:
Jürgen Spitzmüller wrote:
"Insert table" (just a table, no float) is a string that
don't exist in either nb.po or de.po.
Does the attac
Jürgen Spitzmüller wrote:
> > "Insert table" (just a table, no float) is a string that
> > don't exist in either nb.po or de.po.
>
> Does the attached patch help?
Michael, could you check that please?
Jürgen
Helge Hafting wrote:
> "Insert table" (just a table, no float) is a string that
> don't exist in either nb.po or de.po.
Does the attached patch help?
Jürgen
Index: src/frontends/Toolbars.cpp
===
--- src/frontends/Toolbars.cpp (Revis
ert table float" which is translateable.
"Insert table" (just a table, no float) is a string that
don't exist in either nb.po or de.po. I just checked with grep.
This is the tooltip help for the button that inserts a table. (not table
float)
The words "Figure" and &qu
Helge Hafting wrote:
> > Strangely, it _is_ translated here (German l10n, latest svn).
> >
>
> Don't confuse it with "Insert table float" which is translateable.
See attached screenshot.
Jürgen
<>
On Friday 25 May 2007 09:09:20 Jean-Marc Lasgouttes wrote:
>
> Jürgen> Try the attached.
>
> Looks good.
OK.
> JMarc
--
José Abílio
> "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
>> The string "Preview source code for paragraph " that appear
>> in the source code window when viewing source for a single
>> paragraph. '
Jürgen> Try the attached.
Looks good.
JMarc
Helge Hafting wrote:
> Surprisingly, the tooltip "Insert table" for the upper toolbar
> isn't translateable. Every other toolbar tooltip is.
Strangely, it _is_ translated here (German l10n, latest svn).
> The words "Figure" and "Table" in the TOC d
> Surprisingly, the tooltip "Insert table" for the upper toolbar
> isn't translateable. Every other toolbar tooltip is.
do you use svn ?
http://bugzilla.lyx.org/show_bug.cgi?id=3508
pavel
Surprisingly, the tooltip "Insert table" for the upper toolbar
isn't translateable. Every other toolbar tooltip is.
The words "Figure" and "Table" in the TOC dialog, where
we choose whether to show TOC, LOF or LOT.
The string "Preview source code for pa
There is no bugzilla entry. I found it from mailing list..
http://marc.info/?l=lyx-devel&m=117880601303849&w=2
On 5/15/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
José Matos wrote:
> > I agree.
>
> +1
Committed. Was there a bugzilla entry about this? I thought so, but I
don't
find it
José Matos wrote:
> > I agree.
>
> +1
Committed. Was there a bugzilla entry about this? I thought so, but I don't
find it now.
Jürgen
> "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
Jürgen> Ozgur Ugras BARAN wrote:
>> So.. It seems there is a consensus on the second approach. (which
>> is also fine for me). Then, how about puttimg it in svn?
Jürgen> Jean-Marc? José?
I agree.
JMarc
On Tuesday 15 May 2007 15:53:53 Jean-Marc Lasgouttes wrote:
>
> I agree.
+1
> JMarc
--
José Abílio
Ozgur Ugras BARAN wrote:
> So.. It seems there is a consensus on the second approach. (which is
> also fine for me). Then, how about puttimg it in svn?
Jean-Marc? José?
Jürgen
On 5/15/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
Ozgur Ugras BARAN wrote:
> Gosh.. this takes hours to link..
>
> I have tested, but no crashes.. sorry. I will test it again tonight.
Maybe my system is pickier (64bit). Anyway, seems your other (TOC backend)
patch is getting more sympath
Ozgur Ugras BARAN wrote:
> Gosh.. this takes hours to link..
>
> I have tested, but no crashes.. sorry. I will test it again tonight.
Maybe my system is pickier (64bit). Anyway, seems your other (TOC backend)
patch is getting more sympathy anyway.
Jürgen
Abdelrazak Younes wrote:
> > In my opinion, numbered TOC entries are structural elemens of a
> > document. Non-numbered ones are used mostly for categorization
> > elements. Therefore I vote for the first patch.
>
> I vote for the second ;-)
+1
> > I don't think putting another slider in dialog a
Gosh.. this takes hours to link..
I have tested, but no crashes.. sorry. I will test it again tonight.
regards,
ugras
On 5/15/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
Ozgur Ugras BARAN wrote:
> How can I enable stdlib-debug ?
--enable-stdlib-debug
Jürgen
settings are made in
Document/Settings/Numbering & TOC, which is correct place for this
IMHO.
I disagree. The settings in "Numbering" decides what headings get printed
with a number, and what headings get in the printed TOC.
A third slider there, that don't affect the document (just
Ozgur Ugras BARAN wrote:
Well, I don't know. Please try yourself and let me know. Attached is
two patches: First patch (toc.diff) prevents over-demoting and second
one (TocBackend.diff), puts everything in TOC. (Abdel, This was what
you had asked, isn't it?)
Yes.
In my opinion, numbered TOC
> "Ozgur" == Ozgur Ugras BARAN <[EMAIL PROTECTED]> writes:
Ozgur> Well, I don't know. Please try yourself and let me know.
Ozgur> Attached is two patches: First patch (toc.diff) prevents
Ozgur> over-demoting and second one (TocBackend.diff), puts everything
Ozgur> in TOC. (Abdel, This was what
be in TocBackend, but this doesn't remove the necessity of a
> controller function. IMHO, the code is cleaner as it is now.
>
> My question was different, actually. What I am doing now is to prevent
> demotion from the dialog. Another option would be not to filter TOC
> entries in T
Ozgur Ugras BARAN wrote:
> How can I enable stdlib-debug ?
--enable-stdlib-debug
Jürgen
Umm. let me check, then. How can I enable stdlib-debug ?
Ugras
On 5/15/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
Ozgur Ugras BARAN wrote:
> I can't reproduce this. I even tried inline-in command from buffer.
>
> One point is, if you have older versions of toc stuff (pre 18265) and apply
Ozgur Ugras BARAN wrote:
> I can't reproduce this. I even tried inline-in command from buffer.
>
> One point is, if you have older versions of toc stuff (pre 18265) and apply
> this patch, it is possible to get such errors *I have tested and found
> some). Are you sure that you have cleanly updated
.
My question was different, actually. What I am doing now is to prevent
demotion from the dialog. Another option would be not to filter TOC
entries in TOC dialog, therefore, demotion will never be a problem.
The downside of this method is over-crowded TOC dialog.
Will that "crowding" be
I can't reproduce this. I even tried inline-in command from buffer.
One point is, if you have older versions of toc stuff (pre 18265) and apply
this patch, it is possible to get such errors *I have tested and found
some). Are you sure that you have cleanly updated to the current svn?
I will re-s
Jürgen Spitzmüller wrote:
Edwin Leuven wrote:
i was thinking that if you create an LFUN_OUTLINE_IN action that you
then associate with the demote button it would automatically be disabled
when demoting is not possible. this way it would not be possible to
click the button "too many times"...
I
Ozgur Ugras BARAN wrote:
When demote button is pressed too many times, TOC item dissapears from
the toc dialog, since it is no longer numbered. Hence, promoting back
to the original state from TOC dialog is not possible. Attached patch
is a way of correcting this behaviour. It simply prevents
Ozgur Ugras BARAN wrote:
> strange.. nobody complained the code below..
>
> +
> moveInTB->setEnabled(form_->allowDemoteCurrentItem(typeCO->currentIndex())
> &&
> + moveOutTB->isEnabled()); //means controls are
> enabled.
I do ;-) (comments above the code please). And pl
Edwin Leuven wrote:
> i was thinking that if you create an LFUN_OUTLINE_IN action that you
> then associate with the demote button it would automatically be disabled
> when demoting is not possible. this way it would not be possible to
> click the button "too many times"...
I think Ugras is correc
On Mon, May 14, 2007 at 09:47:11PM +0200, Ozgur Ugras BARAN wrote:
> On 5/14/07, Andre Poenitz <[EMAIL PROTECTED]> wrote:
> >On Mon, May 14, 2007 at 08:19:59PM +0200, Ozgur Ugras BARAN wrote:
> >> +bool const ControlToc::allowDemoteCurrentItem(size_t type) const
> >> +{
> >> + return ((kernel().bu
On 5/14/07, Andre Poenitz <[EMAIL PROTECTED]> wrote:
On Mon, May 14, 2007 at 08:19:59PM +0200, Ozgur Ugras BARAN wrote:
> +bool const ControlToc::allowDemoteCurrentItem(size_t type) const
> +{
> + return ((kernel().buffer().params().tocdepth -
(*getCurrentTocItem(type)).depth() + 1)>0);
> +}
On
remove the necessity of a
controller function. IMHO, the code is cleaner as it is now.
My question was different, actually. What I am doing now is to prevent
demotion from the dialog. Another option would be not to filter TOC
entries in TOC dialog, therefore, demotion will never be a problem.
The downsi
erent, actually. What I am doing now is to prevent
demotion from the dialog. Another option would be not to filter TOC
entries in TOC dialog, therefore, demotion will never be a problem.
The downside of this method is over-crowded TOC dialog.
I wonder what people think about current solution? Does anybody
On Mon, May 14, 2007 at 08:19:59PM +0200, Ozgur Ugras BARAN wrote:
> +bool const ControlToc::allowDemoteCurrentItem(size_t type) const
> +{
> + return ((kernel().buffer().params().tocdepth -
> (*getCurrentTocItem(type)).depth() + 1)>0);
> +}
On the formal side:
No need for the outer paranth
shouldn't the proper "enabled" flag be set in the kernel
(bufferview.cpp?) instead of putting this in the controller?
Ozgur Ugras BARAN wrote:
When demote button is pressed too many times, TOC item dissapears from
the toc dialog, since it is no longer numbered. Hence, promot
When demote button is pressed too many times, TOC item dissapears from
the toc dialog, since it is no longer numbered. Hence, promoting back
to the original state from TOC dialog is not possible. Attached patch
is a way of correcting this behaviour. It simply prevents demoting the
item more than
On Thu, May 10, 2007 at 02:00:59PM +0300, Ozgur Ugras BARAN wrote:
> I am trying to solve bug 3529 and things seems to be weird. I check if the
> modelItem for the TOC entry is passed correctly. For kernel/model to view
> side everything seems OK. Apparently the problem is in paint mechanism of
> t
Ozgur Ugras BARAN wrote:
I am trying to solve bug 3529 and things seems to be weird. I check if the
modelItem for the TOC entry is passed correctly. For kernel/model to view
side everything seems OK. Apparently the problem is in paint mechanism of
treeView. I did every possible trick to make the
I am trying to solve bug 3529 and things seems to be weird. I check if the
modelItem for the TOC entry is passed correctly. For kernel/model to view
side everything seems OK. Apparently the problem is in paint mechanism of
treeView. I did every possible trick to make the treeview repaint correctly
Helge Hafting wrote:
This has become a very nice tool! Still, I see a problem:
1. Select some heading in the userguide.
2. Demote it so much that it is no longer numbered.
3. Note that it is now no longer electible for promotion, so
no way to undo the effect manually.
It isn't supposed to b
This has become a very nice tool! Still, I see a problem:
1. Select some heading in the userguide.
2. Demote it so much that it is no longer numbered.
3. Note that it is now no longer electible for promotion, so
no way to undo the effect manually.
It isn't supposed to be like that, is it?
I
Andre Poenitz wrote:
On Sun, Apr 22, 2007 at 10:43:06AM +0200, Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Andre Poenitz wrote:
Right. It's a commonly used English acronym.
I dispute 'commonly used', especially in a context where we are supposed
to give explanations.
Shall I present f
On Sun, Apr 22, 2007 at 10:43:06AM +0200, Abdelrazak Younes wrote:
> Jürgen Spitzmüller wrote:
> >Andre Poenitz wrote:
> >>>Right. It's a commonly used English acronym.
> >>I dispute 'commonly used', especially in a context where we are supposed
> >>to give explanations.
> >
> >Shall I present freq
Jürgen Spitzmüller wrote:
Andre Poenitz wrote:
Right. It's a commonly used English acronym.
I dispute 'commonly used', especially in a context where we are supposed
to give explanations.
Shall I present frequencies based on a corpus research?
You know what: I don't care, so I simply changed i
Andre Poenitz wrote:
> > Right. It's a commonly used English acronym.
>
> I dispute 'commonly used', especially in a context where we are supposed
> to give explanations.
Shall I present frequencies based on a corpus research?
You know what: I don't care, so I simply changed it.
Jürgen
On Sat, Apr 21, 2007 at 06:21:08PM +0200, Jürgen Spitzmüller wrote:
> Andre Poenitz wrote:
> > TOC is by no means a commonly used English word.
>
> Right. It's a commonly used English acronym.
I dispute 'commonly used', especially in a context where we are supposed
to give explanations.
Andre'
Andre Poenitz wrote:
> TOC is by no means a commonly used English word.
Right. It's a commonly used English acronym.
Jürgen
On Sat, Apr 21, 2007 at 03:23:22PM +0200, Jürgen Spitzmüller wrote:
> Michael Gerz wrote:
> > I think all tooltips should start with a capital letter.
>
> fixed.
>
> > This is misleading. What is a "level"? Level != Nesting?
>
> I think it's pretty clear in this context. But I changed it.
>
> >
Michael Gerz wrote:
> I think all tooltips should start with a capital letter.
fixed.
> This is misleading. What is a "level"? Level != Nesting?
I think it's pretty clear in this context. But I changed it.
> TOC => table of contents (?)
Too long. I think TOC is common to English speaking users
Jürgen Spitzmüller schrieb:
Andre Poenitz wrote:
It would be nice to have tooltips in there.
Attached.
José, can such trivial things go in again?
I think all tooltips should start with a capital letter.
+
+move selected item one level down
+
This is mislead
On Saturday 21 April 2007 1:59:46 pm Jürgen Spitzmüller wrote:
> Andre Poenitz wrote:
> > It would be nice to have tooltips in there.
>
> Attached.
> José, can such trivial things go in again?
Sure.
> Jürgen
--
José Abílio
Andre Poenitz wrote:
> It would be nice to have tooltips in there.
Attached.
José, can such trivial things go in again?
Jürgen
Index: src/frontends/qt4/ui/QTocUi.ui
===
--- src/frontends/qt4/ui/QTocUi.ui (Revision 17881)
+++ src/fron
Andre Poenitz wrote:
> It is also unclear to me how the dock is supposed to (re-)appear. Right
> now, I have to insert a 'TOC' item in the main text and click on it.
Document->Table of Contents.
> It is also unclear to me what the reaon for the existance of the
> combobox 'Type' is. It contains a
On Sat, Apr 21, 2007 at 12:41:41PM +0200, Michael Gerz wrote:
> Andre Poenitz schrieb:
> >It would be nice to have tooltips in there. It took me a while to figure
> >out what this slider might be good for, especially if you have a very
> >short document only.
> >
> >It is also unclear to me how the
Andre Poenitz schrieb:
It would be nice to have tooltips in there. It took me a while to figure
out what this slider might be good for, especially if you have a very
short document only.
It is also unclear to me how the dock is supposed to (re-)appear. Right
now, I have to insert a 'TOC' item in
It would be nice to have tooltips in there. It took me a while to figure
out what this slider might be good for, especially if you have a very
short document only.
It is also unclear to me how the dock is supposed to (re-)appear. Right
now, I have to insert a 'TOC' item in the main text and click
the above bug is solved, commit the rest.
OK.
It's in.
Now we have to review the bugzilla entries related to the TOC dialog.
Abdel.
José Matos wrote:
On Tuesday 06 March 2007 5:49:50 pm Abdelrazak Younes wrote:
Dear Jose,
Here is the proposed patch. There's still one bug remaining in the
type's list but it should be easy to solve.
I propose to commit the safe part now (everything that is not in qt4)
and, when the above bug
On Tuesday 06 March 2007 5:49:50 pm Abdelrazak Younes wrote:
> Dear Jose,
>
> Here is the proposed patch. There's still one bug remaining in the
> type's list but it should be easy to solve.
>
> I propose to commit the safe part now (everything that is not in qt4)
> and, when the above bug is solve
Angus Leeming <[EMAIL PROTECTED]> writes:
> > Another feature request: update the toc on buffer-switch instead of
> > hiding it.
>
> Note that the infrastructure for this one is in place already. You just need
> to tell frontends\Dialogs.C that this is an updateable dialog rather than a
> hidea
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Another feature request: update the toc on buffer-switch instead of
> hiding it.
Note that the infrastructure for this one is in place already. You just need
to tell frontends\Dialogs.C that this is an updateable dialog rather than a
hideable one.
ng namespace lyx::frontend;
@@ -131,6 +132,7 @@
namespace lyx {
+
bool Dialogs::isValidName(string const & name) const
{
return std::find_if(dialognames, end_dialognames,
@@ -300,7 +302,9 @@
} else if (name == "toc") {
QToc * qtoc = new QToc(*dialog);
Leuven, E. wrote:
lyx crashes when openinc the toc with an empty doc
Sorry, I forgot to include the attached change in the former patch...
Abdel.
Index: lyxfunc.C
===
--- lyxfunc.C (revision 17409)
+++ lyxfunc.C (working copy)
lyx crashes when openinc the toc with an empty doc
-Original Message-
From: news on behalf of Abdelrazak Younes
Sent: Wed 3/7/07 16:26
To: lyx-devel@lists.lyx.org
Subject: [Updated Patch] Toc dialog cleanup and a few other things
Abdelrazak Younes wrote:
> Dear Jose,
>
> He
ool Dialogs::isValidName(string const & name) const
{
return std::find_if(dialognames, end_dialognames,
@@ -300,7 +302,9 @@
} else if (name == "toc") {
QToc * qtoc = new QToc(*dialog);
dialog->setController(qtoc);
-
Leuven, E. wrote:
it is very nice!
I think so too :-)
a couple of comments (using the user guide):
initially the level expansion of the tree does not match the slider
Known bug.
initially the type combo is empty
Known bug.
when switching to type = table i can switch to table 1 and
Younes
Sent: Tue 3/6/07 18:49
To: lyx-devel@lists.lyx.org
Subject: [Patch] Toc dialog cleanup
Dear Jose,
Here is the proposed patch. There's still one bug remaining in the
type's list but it should be easy to solve.
I propose to commit the safe part now (everything that is not in qt4)
// Nothing to do here... for now.
@@ -275,20 +51,19 @@
void QTocDialog::hide()
{
- accept();
+ QDockWidget::hide();
}
void QTocDialog::show()
{
- form_->update();
- QDialog::show();
+ QDockWidget::show();
}
bool QTocDialog::isVisible()
Leuven, E. wrote:
Excellent Edwin, you're a master!
what are u then?
:-)
I know, I should RTFM but what is the trick?
cast a magic spell i learned from harry potter himself.
some - second rate wizards - have claimed that selecting the base
widget (clicking on it) and then layout in a g
> Excellent Edwin, you're a master!
what are u then?
> I know, I should RTFM but what is the trick?
cast a magic spell i learned from harry potter himself.
some - second rate wizards - have claimed that selecting the base widget
(clicking on it) and then layout in a grid (ctrl+5) also works un
Leuven, E. wrote:
something like the attached?
Excellent Edwin, you're a master!
I know, I should RTFM but what is the trick?
Abdel.
> Edwin! I knew I forgot someone in my call for help ;-)
i am not much help these days, but i still manage to lurk ;-)
Leuven, E. wrote:
Edwin! I knew I forgot someone in my call for help ;-)
something like the attached?
I'll try that, thanks.
Abdel.
something like the attached?
-Original Message-
From: news on behalf of Abdelrazak Younes
Sent: Tue 3/6/07 16:11
To: lyx-devel@lists.lyx.org
Subject: Re: [Patch] TOC Dialog crashes with empty toc list
José Matos wrote:
> On Monday 05 March 2007 6:27:26 pm Abdelrazak Younes wr
Bernhard Roider wrote:
Abdelrazak Younes wrote:
Bernhard Roider wrote:
Hello,
i found a crash when one of the buttons in the TOC dialog is pressed
if the TOC is empty. The attached patch disables the buttons if there
are no entries in the TOC dialog. To be safe it also adds a test to
the
Abdelrazak Younes wrote:
Bernhard Roider wrote:
Hello,
i found a crash when one of the buttons in the TOC dialog is pressed
if the TOC is empty. The attached patch disables the buttons if there
are no entries in the TOC dialog. To be safe it also adds a test to
the button handler functions
On Monday 05 March 2007 6:27:26 pm Abdelrazak Younes wrote:
> > How much time do you need?
>
> A few days...
Granted. :-)
> > I suggested the freeze with a very small window of commit time
> > remaining. I am aware that it is not nice to change the rules in the
> > middle of the game, that
José Matos wrote:
On Monday 05 March 2007 4:47:31 pm Abdelrazak Younes wrote:
Hello Bernhard,
I don't know if you are planning to commit this one but I wanted to let
you know that I integrated your changes already in my local tree. I am
basically rewriting a good part of this code and I hope th
On Monday 05 March 2007 4:47:31 pm Abdelrazak Younes wrote:
> Hello Bernhard,
>
> I don't know if you are planning to commit this one but I wanted to let
> you know that I integrated your changes already in my local tree. I am
> basically rewriting a good part of this code and I hope that it will b
1 - 100 of 176 matches
Mail list logo
