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
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?)
No need for a patch to test "everythi
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
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?)
In my opinion, numbered TOC entries are structural elemens of a
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
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 the necessity of a
controller function. IMHO, the code is cleaner as it is now.
My quest
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 dem
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
i probably don't understand you.
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"...
anyway, just
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 the necessity of a
controller function. IMHO, the code is cleaner as it is now.
My question was different, actuall
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, promoting back
to the orig
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 d
29 matches
Mail list logo
