..
Ugras
On Tue, Nov 11, 2008 at 12:41 PM, Abdelrazak Younes [EMAIL PROTECTED] wrote:
On 11/11/2008 08:43, Ozgur Ugras BARAN wrote:
Hi Ibrahim,
I can help on Turkish translation, if you wish.. It's been a while I
didn't
participate lyx..
You are very welcome to contribute again to the code
..
Ugras
On Tue, Nov 11, 2008 at 12:41 PM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
> On 11/11/2008 08:43, Ozgur Ugras BARAN wrote:
>
>> Hi Ibrahim,
>> I can help on Turkish translation, if you wish.. It's been a while I
>> didn't
>> participate lyx..
>&g
Hi Ibrahim,
I can help on Turkish translation, if you wish.. It's been a while I didn't
participate lyx..
Ugras
On Thu, Nov 6, 2008 at 1:07 AM, H. İbrahim Güngör
[EMAIL PROTECTED] wrote:
On Thursday 06 November 2008 00:56:03 Pavel Sanda wrote:
H. ??brahim Güngör wrote:
Many fixes and
Hi Ibrahim,
I can help on Turkish translation, if you wish.. It's been a while I didn't
participate lyx..
Ugras
On Thu, Nov 6, 2008 at 1:07 AM, H. İbrahim Güngör <
[EMAIL PROTECTED]> wrote:
> On Thursday 06 November 2008 00:56:03 Pavel Sanda wrote:
> > H. ??brahim Güngör wrote:
> > > Many fixes
I'd love to join, but apparently it won't be possible for me. Do you plan
any means of online access for hacking/ conferencing etc?
regards,
Ugras
I'd love to join, but apparently it won't be possible for me. Do you plan
any means of online access for hacking/ conferencing etc?
regards,
Ugras
Attached patch corrects the buglet mentioned in the heading. I don't know
this quick hack has any consequences, so please somebody verify.
here is the svn log:
Fix unnumbered toc entries do not update automatically as you type.
regards,
Ugras
--- buffer_funcs.cpp-lyx-1.5.0rc1 2007-06-11
No, unfortunately not yet, Abdel. I guess I can get an access after the
release. So, I'll be glad if you can commit.
thanks,
Ugras
On 6/14/07, Abdelrazak Younes [EMAIL PROTECTED] wrote:
Juergen Spitzmueller wrote:
Ozgur Ugras BARAN wrote:
Attached patch corrects the buglet mentioned
Attached patch corrects the buglet mentioned in the heading. I don't know
this quick hack has any consequences, so please somebody verify.
here is the svn log:
Fix unnumbered toc entries do not update automatically as you type.
regards,
Ugras
--- buffer_funcs.cpp-lyx-1.5.0rc1 2007-06-11
No, unfortunately not yet, Abdel. I guess I can get an access after the
release. So, I'll be glad if you can commit.
thanks,
Ugras
On 6/14/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Juergen Spitzmueller wrote:
> Ozgur Ugras BARAN wrote:
>
>> Attached patch corrects th
On 5/30/07, Abdelrazak Younes [EMAIL PROTECTED] wrote:
Bo Peng wrote:
Sorry Bo, it is been a bit late, but I wait for all the changes for
the source file settles.
It can go in if you change .find() to contains(), and trim() suffix to
avoid problem with '?style ' etc (if it has not been
Otherwise, '?something ' will not match anything.
I guess, a trim is already applied. I updated the code for the situations '? something' and attached the patch. However, It does not cover the situations '?some thing'.
I used trim (), but since the string is already trimmed, rtrim() is
On 5/30/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Bo Peng wrote:
>> Sorry Bo, it is been a bit late, but I wait for all the changes for
>> the source file settles.
>
> It can go in if you change .find() to contains(), and trim() suffix to
> avoid problem with '?style ' etc (if it has not
Otherwise, '?something ' will not match anything.
I guess, a trim is already applied. I updated the code for the situations '? something' and attached the patch. However, It does not cover the situations '?some thing'.
I used trim (), but since the string is already trimmed, rtrim() is
Attached is a patch for a small feature that Bo asked for. It simply
filters InsetListingsParams when the text in the corresponding dialog
is entered as ?string .
Sorry Bo, it is been a bit late, but I wait for all the changes for
the source file settles.
cheers
Ugras
Index:
Attached is a patch for a small feature that Bo asked for. It simply
filters InsetListingsParams when the text in the corresponding dialog
is entered as ? .
Sorry Bo, it is been a bit late, but I wait for all the changes for
the source file settles.
cheers
Ugras
Index:
5. I would appreciate it you can also implement
?xx == all parameters that contains xx. That is to say, ?placement
would show floatplacement. style would show all style related
parameters. You can also consider xx == all parameters that
prefixIs(xx), and other parameters that contains(xx).
I
variable that we compare with empty string is of type const char, not
string.. A possible way of doing it would be:
!string(listings_param_table[idx].name).empty()
But it is more difficult to read, IMHO.
Ugras
Use string::empty() instead.
Abdel.
Ah... OK, I didn't get the thing.
Why don't you use string in the first place (in listings_param_table) ?
But it is more difficult to read, IMHO.
Yes. You could as well use:
if (listings_param_table[idx].name[0])
:D I guess, I remember this from hilarious web site how to write an
Ah, yes I forgot contains.. I'll fix it.
Shall I also make the conversion to docstring for every string and
char* I use in parValidator::parValidator?
ugras
On 5/26/07, Bo Peng [EMAIL PROTECTED] wrote:
Indeed, I am agree with Alfredo on this issue. Therefore I have
attached another patch
5. I would appreciate it you can also implement
?xx ==> all parameters that contains xx. That is to say, ?placement
would show floatplacement. style would show all style related
parameters. You can also consider xx ==> all parameters that
prefixIs(xx), and other parameters that contains(xx).
variable that we compare with empty string is of type const char, not
string.. A possible way of doing it would be:
!string(listings_param_table[idx].name).empty()
But it is more difficult to read, IMHO.
Ugras
Use string::empty() instead.
Abdel.
Ah... OK, I didn't get the thing.
Why don't you use string in the first place (in listings_param_table) ?
> But it is more difficult to read, IMHO.
Yes. You could as well use:
if (listings_param_table[idx].name[0])
:D I guess, I remember this from hilarious web site "how to write an
Ah, yes I forgot contains.. I'll fix it.
Shall I also make the conversion to docstring for every string and
char* I use in parValidator::parValidator?
ugras
On 5/26/07, Bo Peng <[EMAIL PROTECTED]> wrote:
> Indeed, I am agree with Alfredo on this issue. Therefore I have
> attached another
Attached patch sorts listings inset params, and hence solves bug 3639.
Please somebody review and apply the patch.
I could also sort the listings_param_table[] entries manually, but I find
this way easier (and more guaranteed).
regards,
ugras
Index: insets/InsetListingsParams.cpp
On 5/25/07, Bo Peng [EMAIL PROTECTED] wrote:
On 5/25/07, Ozgur Ugras BARAN [EMAIL PROTECTED] wrote:
Attached patch sorts listings inset params, and hence solves bug 3639.
Please somebody review and apply the patch.
1. table[idx].name is char * so != is better because no conversion
would
Attached patch sorts listings inset params, and hence solves bug 3639.
Please somebody review and apply the patch.
I could also sort the listings_param_table[] entries manually, but I find
this way easier (and more guaranteed).
regards,
ugras
Index: insets/InsetListingsParams.cpp
On 5/25/07, Bo Peng <[EMAIL PROTECTED]> wrote:
On 5/25/07, Ozgur Ugras BARAN <[EMAIL PROTECTED]> wrote:
> Attached patch sorts listings inset params, and hence solves bug 3639.
> Please somebody review and apply the patch.
1. table[idx].name is char * so != "" is
Compile and works fine here.
Looks pretty solid at the first glance. Thanks Jose (and everybody)
Ugras
On 5/18/07, José Matos [EMAIL PROTECTED] wrote:
On Thursday 17 May 2007 1:05:33 pm José Matos wrote:
Hi all,
I will be busy until tonight, when I intend to release beta 3.
I have
Compile and works fine here.
Looks pretty solid at the first glance. Thanks Jose (and everybody)
Ugras
On 5/18/07, José Matos <[EMAIL PROTECTED]> wrote:
On Thursday 17 May 2007 1:05:33 pm José Matos wrote:
> Hi all,
> I will be busy until tonight, when I intend to release beta 3.
I
For me, another candidate for multiple glossaries implementation in lyx.
Supporting all available package will not be as easy as it was in multiple
indices..
I really like to hear how would you rate it? Especially compared to gloss
and glossary.
Documentation is awful, though. For a standard
On 5/17/07, Jürgen Spitzmüller [EMAIL PROTECTED] wrote:
Ozgur Ugras BARAN wrote:
For me, another candidate for multiple glossaries implementation in lyx.
Supporting all available package will not be as easy as it was in
multiple
indices..
I really like to hear how would you rate it?
From
For me, another candidate for multiple glossaries implementation in lyx.
Supporting all available package will not be as easy as it was in multiple
indices..
I really like to hear how would you rate it? Especially compared to gloss
and glossary.
Documentation is awful, though. For a standard
On 5/17/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
Ozgur Ugras BARAN wrote:
> For me, another candidate for multiple glossaries implementation in lyx.
> Supporting all available package will not be as easy as it was in
multiple
> indices..
>
> I really like to he
There is no bugzilla entry. I found it from mailing list..
http://marc.info/?l=lyx-develm=117880601303849w=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 now.
Glossaries has. See Extended.lyx section 3.3.
On 5/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
On Tue, 15 May 2007, José Matos wrote:
On Sunday 13 May 2007 20:26:49 [EMAIL PROTECTED] wrote:
I would if I could - I have only used LyX once in the last year or so,
which means I have no
when selecting LOF/ LOT for User Guide assertion triggered. Here is debug info:
#0 0x40c7c327 in raise () from /lib/tls/libc.so.6
#1 0x40c7db75 in abort () from /lib/tls/libc.so.6
#2 0x085ffb47 in lyx::support::abort () at abort.cpp:25
#3 0x0807339a in boost::assertion_failed
No there were no assertion. Actually, assertion is triggered due to a
problem introduced by two previous patches (today?) that solves
LOF/LOT selection issue and solving this bug.
Abdel, if you will not have time to solve this, would you revert
LOT/LOF patch and apply my workaround? We are too
The patch works well for child documents. I should also report that,
it works for algorithms list.
On 5/16/07, Ozgur Ugras BARAN [EMAIL PROTECTED] wrote:
No there were no assertion. Actually, assertion is triggered due to a
problem introduced by two previous patches (today?) that solves
LOF/LOT
There is no bugzilla entry. I found it from mailing list..
http://marc.info/?l=lyx-devel=117880601303849=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
Glossaries has. See Extended.lyx section 3.3.
On 5/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
On Tue, 15 May 2007, José Matos wrote:
> On Sunday 13 May 2007 20:26:49 [EMAIL PROTECTED] wrote:
>> I would if I could - I have only used LyX once in the last year or so,
>> which means I
when selecting LOF/ LOT for User Guide assertion triggered. Here is debug info:
#0 0x40c7c327 in raise () from /lib/tls/libc.so.6
#1 0x40c7db75 in abort () from /lib/tls/libc.so.6
#2 0x085ffb47 in lyx::support::abort () at abort.cpp:25
#3 0x0807339a in boost::assertion_failed
No there were no assertion. Actually, assertion is triggered due to a
problem introduced by two previous patches (today?) that solves
LOF/LOT selection issue and solving this bug.
Abdel, if you will not have time to solve this, would you revert
LOT/LOF patch and apply my workaround? We are too
The patch works well for child documents. I should also report that,
it works for algorithms list.
On 5/16/07, Ozgur Ugras BARAN <[EMAIL PROTECTED]> wrote:
No there were no assertion. Actually, assertion is triggered due to a
problem introduced by two previous patches (today?) that solv
I can confirm that patch also works for qt 4.2.0.
On 5/14/07, Ozgur Ugras BARAN [EMAIL PROTECTED] wrote:
Attached patch solves TOC bug 3529 for Qt-4.3-pre. The problem was
blocked selectionchanged signal for selectionModel prevents correct
repainting. I have no idea whether this patch works
:
Ozgur Ugras BARAN wrote:
Attached patch solves TOC bug 3529 for Qt-4.3-pre. The problem was
blocked selectionchanged signal for selectionModel prevents correct
repainting. I have no idea whether this patch works for qt-4.2 or not.
Therefore, please somebody test it?
Works for me (qt 4.2.3
This one should be better in behaviour, but ugly as hell.
Would you please test it, again?
regards,
Ugras
On 5/15/07, Ozgur Ugras BARAN [EMAIL PROTECTED] wrote:
Oh, there is another problem, now. Please do not apply patch. When you
change the selection with mouse, cursor goes
-send the patch with your comments applied, after coding the
proposed solution of Abdel.
Ugras
On 5/15/07, Jürgen Spitzmüller [EMAIL PROTECTED] wrote:
Ozgur Ugras BARAN wrote:
strange.. nobody complained the code below..
+
moveInTB-setEnabled(form_-allowDemoteCurrentItem(typeCO-currentIndex
Correct bug 3529-(TOC widget does not select the current
part/section/subsection correctly) by replacing blockSignal()
directives for tocTV- selectionModel() with disconnect and reconnect
relevant signal.
Thanks Jurgen, Abdel.
ugras
On 5/15/07, Jürgen Spitzmüller [EMAIL PROTECTED] wrote:
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
place for this
IMHO.
regards,
Ugras
On 5/15/07, Helge Hafting [EMAIL PROTECTED] wrote:
Ozgur Ugras BARAN wrote:
It is strictly dialog related problem, therefore I should have put
some function in controller. The place for a flag like demotionEnabled
maybe in TocBackend, but this doesn't remove
This small patch prevents LOF, LOT always selects the last entry.
LOT/LOF still does not follow the cursor, yet, but for this, we need
serious update in TocBackend.
Do you think this solves bug 3183?
Hopefully, last patch for toc stuff.
here is svn log message:
*
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
I guess I'll leave implementation of this to others for the moment. If
nobody take care about this problem, then it would be a good point for
me to learn lyx internals.
thanks a lot for taking care of the patch, Abdel.
Ugras
On 5/15/07, Abdelrazak Younes [EMAIL PROTECTED] wrote:
Ozgur Ugras
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 sympathy
Is there a place that I can order the book lyx developer's handbook
vol:1 :101 ways o write svn logs :-)
On 5/15/07, Abdelrazak Younes [EMAIL PROTECTED] wrote:
Ozgur Ugras BARAN wrote:
This small patch prevents LOF, LOT always selects the last entry.
LOT/LOF still does not follow the cursor
I can confirm that patch also works for qt 4.2.0.
On 5/14/07, Ozgur Ugras BARAN <[EMAIL PROTECTED]> wrote:
Attached patch solves TOC bug 3529 for Qt-4.3-pre. The problem was
blocked selectionchanged signal for selectionModel prevents correct
repainting. I have no idea whether this patch
TED]> wrote:
Ozgur Ugras BARAN wrote:
> Attached patch solves TOC bug 3529 for Qt-4.3-pre. The problem was
> blocked selectionchanged signal for selectionModel prevents correct
> repainting. I have no idea whether this patch works for qt-4.2 or not.
> Therefore, please somebody test it?
This one should be better in behaviour, but ugly as hell.
Would you please test it, again?
regards,
Ugras
On 5/15/07, Ozgur Ugras BARAN <[EMAIL PROTECTED]> wrote:
Oh, there is another problem, now. Please do not apply patch. When you
change the selection with mouse, curso
-send the patch with your comments applied, after coding the
proposed solution of Abdel.
Ugras
On 5/15/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
Ozgur Ugras BARAN wrote:
> strange.. nobody complained the code below..
>
> +
>
moveInTB->setEnabled(form_->allow
Correct bug 3529-(TOC widget does not select the current
part/section/subsection correctly) by replacing blockSignal()
directives for tocTV- selectionModel() with disconnect and reconnect
relevant signal.
Thanks Jurgen, Abdel.
ugras
On 5/15/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
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 s
rect place for this
IMHO.
regards,
Ugras
On 5/15/07, Helge Hafting <[EMAIL PROTECTED]> wrote:
Ozgur Ugras BARAN wrote:
> It is strictly dialog related problem, therefore I should have put
> some function in controller. The place for a flag like demotionEnabled
> maybe in TocBacken
This small patch prevents LOF, LOT always selects the last entry.
LOT/LOF still does not follow the cursor, yet, but for this, we need
serious update in TocBackend.
Do you think this solves bug 3183?
Hopefully, last patch for toc stuff.
here is svn log message:
*
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
I guess I'll leave implementation of this to others for the moment. If
nobody take care about this problem, then it would be a good point for
me to learn lyx internals.
thanks a lot for taking care of the patch, Abdel.
Ugras
On 5/15/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Ozgur
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 there a place that I can order the book "lyx developer's handbook
vol:1 :101 ways o write svn logs" :-)
On 5/15/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Ozgur Ugras BARAN wrote:
> This small patch prevents LOF, LOT always selects the last entry.
> LOT/LOF
Don't worry about it. I will apply it later, if I can get svn access.
Ugras
On 5/14/07, Abdelrazak Younes [EMAIL PROTECTED] wrote:
Abdelrazak Younes wrote:
Ozgur Ugras BARAN wrote:
Thanks, sir. But I have one more patch. I had a look at the usage of
the browse function through lyx, and saw
Dear JMarc
I am in Lyx development for nine -ten months and wish to continue for
developing/ debugging for Lyx. I believe, I understood the development
practices of lyx community well and I wish to gain svn commit access in
order not to disturb other developers to commit in my place and also my
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
another idea?
Ugras
On 5/14/07, Edwin Leuven [EMAIL PROTECTED] wrote:
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
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
Attached patch solves TOC bug 3529 for Qt-4.3-pre. The problem was
blocked selectionchanged signal for selectionModel prevents correct
repainting. I have no idea whether this patch works for qt-4.2 or not.
Therefore, please somebody test it?
verify, commit, enjoy :)
Abdel, I have asked
Don't worry about it. I will apply it later, if I can get svn access.
Ugras
On 5/14/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Abdelrazak Younes wrote:
> Ozgur Ugras BARAN wrote:
>> Thanks, sir. But I have one more patch. I had a look at the usage of
>> the browse
Dear JMarc
I am in Lyx development for nine -ten months and wish to continue for
developing/ debugging for Lyx. I believe, I understood the development
practices of lyx community well and I wish to gain svn commit access in
order not to disturb other developers to commit in my place and also my
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
another idea?
Ugras
On 5/14/07, Edwin Leuven <[EMAIL PROTECTED]> wrote:
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 i
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))
Attached patch solves TOC bug 3529 for Qt-4.3-pre. The problem was
blocked selectionchanged signal for selectionModel prevents correct
repainting. I have no idea whether this patch works for qt-4.2 or not.
Therefore, please somebody test it?
verify, commit, enjoy :)
Abdel, I have asked
Thanks, Uwe.
On 5/12/07, Uwe Stöhr [EMAIL PROTECTED] wrote:
PS. I guess it is safe to close the bug 3377.
Done.
regards uwe
Thanks, Uwe.
On 5/12/07, Uwe Stöhr <[EMAIL PROTECTED]> wrote:
> PS. I guess it is safe to close the bug 3377.
Done.
regards uwe
Attached trivial patch solves Bug 3377 (In insert graphic window: canceling
open dialog erases entry in text box). This bug is not Mac specific, but
exist in Linux. (should exist in other OSes).
Please may somebody apply the patch?
regards,
ugras
--- QGraphicsDialog.cpp (revision 18067)
+++
Abdel, I am afraid your patch introduces a couple of problems:
In toc combo number of entries is multiplied when update button is pressed.
(typeCO has entries tables/figure/TOC/tables/figure/TOC/. depending
on how many times you pressed the button.)
eventually, when older TOC is chosen
for the compliments, sir :)
Ugras
PS. I guess it is safe to close the bug 3377. I couldn't find a bugzilla
entry for QExternal bug.
On 5/11/07, Abdelrazak Younes [EMAIL PROTECTED] wrote:
Ozgur Ugras BARAN wrote:
Attached trivial patch solves Bug 3377 (In insert graphic window:
canceling open dialog erases
Attached trivial patch solves Bug 3377 (In insert graphic window: canceling
open dialog erases entry in text box). This bug is not Mac specific, but
exist in Linux. (should exist in other OSes).
Please may somebody apply the patch?
regards,
ugras
--- QGraphicsDialog.cpp (revision 18067)
+++
Abdel, I am afraid your patch introduces a couple of problems:
In toc combo number of entries is multiplied when update button is pressed.
(typeCO has entries tables/figure/TOC/tables/figure/TOC/. depending
on how many times you pressed the button.)
eventually, when older TOC is chosen
for the compliments, sir :)
Ugras
PS. I guess it is safe to close the bug 3377. I couldn't find a bugzilla
entry for QExternal bug.
On 5/11/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Ozgur Ugras BARAN wrote:
> Attached trivial patch solves Bug 3377 (In insert graphic window:
> canceling
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
, Abdelrazak Younes [EMAIL PROTECTED] wrote:
Ozgur Ugras BARAN wrote:
Attached patch solves two TOC dialog bugs 3528 and 3534. Can smb
review (Abdel?, Juergen?, John?) and commit it (Jose?)
I need an explanation (which will go in the svn log).
Abdel.
On 5/10/07, Abdelrazak Younes [EMAIL PROTECTED] wrote:
Ozgur Ugras BARAN wrote:
This bug exists before the patch. lof and lot has never been updated
correctly.
Yes, I noticed that afterwards, sorry for accusing you :-)
I did not felt accused, sir.. :-)
The problem is TocBackend::item
it and inform you today. Maybe we need that labyrinth at the
end.. :-)
Ugras
On 5/10/07, Abdelrazak Younes [EMAIL PROTECTED] wrote:
Ozgur Ugras BARAN wrote:
Attached patch solves two TOC dialog bugs 3528 and 3534. Can smb
review (Abdel?, Juergen?, John?) and commit it (Jose?)
I took the time
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
, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Ozgur Ugras BARAN wrote:
> Attached patch solves two TOC dialog bugs 3528 and 3534. Can smb
> review (Abdel?, Juergen?, John?) and commit it (Jose?)
I need an explanation (which will go in the svn log).
Abdel.
On 5/10/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Ozgur Ugras BARAN wrote:
> This bug exists before the patch. lof and lot has never been updated
> correctly.
Yes, I noticed that afterwards, sorry for accusing you :-)
I did not felt accused, sir.. :-)
The problem is
it and inform you today. Maybe we need that labyrinth at the
end.. :-)
Ugras
On 5/10/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Ozgur Ugras BARAN wrote:
> Attached patch solves two TOC dialog bugs 3528 and 3534. Can smb
> review (Abdel?, Juergen?, John?) and commit it (Jose?)
I t
Attached patch solves two TOC dialog bugs 3528 and 3534. Can smb
review (Abdel?, Juergen?, John?) and commit it (Jose?)
ugras
Index: frontends/qt4/TocWidget.cpp
===
--- frontends/qt4/TocWidget.cpp (revision 18237)
+++
Attached patch solves two TOC dialog bugs 3528 and 3534. Can smb
review (Abdel?, Juergen?, John?) and commit it (Jose?)
ugras
Index: frontends/qt4/TocWidget.cpp
===
--- frontends/qt4/TocWidget.cpp (revision 18237)
+++
Listings is a really good package. I agree about not to insert new features
at this point but I will be sorry to postpone this feature for more than a
year. My suggestion is to put this feature in lyx 1.5.0, but not put it in
any user visible place. Doing, we keep backward compatibility between
ah, also I can help reviewing/maintaining the code for inset part (and QT
part if nobody volunteers).
On 5/4/07, Ozgur Ugras BARAN [EMAIL PROTECTED] wrote:
Listings is a really good package. I agree about not to insert new
features at this point but I will be sorry to postpone this feature
1 - 100 of 254 matches
Mail list logo
