leuven edwin wrote:
> > i don't think so since:
> > 1) slider can be still used
> > 2) the point of this check box has nothing to do with slider
>
> maybe i will understand it when i see it...
i put it in.
i dont claim 'keep' is the best label, 'persistent' is another possibility
how to call it.
> i don't think so since:
> 1) slider can be still used
> 2) the point of this check box has nothing to do with slider
maybe i will understand it when i see it...
leuven edwin wrote:
> >> so in the second use case you basically want to ignore/disable the slider?
> >
> > _basically_ i want persistent tree view in the way i
> > uncollapsed it even if some changes to the paragraphs of
> > document happen.
>
> this is a "yes" i suppose.
>
> so wouldn't adding a
>> so in the second use case you basically want to ignore/disable the slider?
>
> _basically_ i want persistent tree view in the way i
> uncollapsed it even if some changes to the paragraphs of
> document happen.
this is a "yes" i suppose.
so wouldn't adding a toggle button which disables the sli
leuven edwin wrote:
> > when you want to hold the current toc behaviour. Typical
> > example is normal writing or quick moving through the text -
> > outliner gives you the info about the context around, when
> > you move out of the current section it gets collapsed and new
> > section structure i
> when you want to hold the current toc behaviour. Typical
> example is normal writing or quick moving through the text -
> outliner gives you the info about the context around, when
> you move out of the current section it gets collapsed and new
> section structure is uncollapsed. this keeps the
leuven edwin wrote:
> > > > my proposal is to add checkbox just below sort and it
> > would be good
> > > > to have short naming. what about 'Keep' with 'Keep
> > uncollapsed state'
> > > > tooltip?
>
> just a last clarifying question: when would one like to uncheck this checkbox?
when you want t
> > > my proposal is to add checkbox just below sort and it
> would be good
> > > to have short naming. what about 'Keep' with 'Keep
> uncollapsed state'
> > > tooltip?
just a last clarifying question: when would one like to uncheck this checkbox?
Pavel Sanda wrote:
> Pavel Sanda wrote:
> > Abdelrazak Younes wrote:
> > >>> So, the checkbox you are proposing will govern the call to
> > >>> setTreeDetph()?
> > >>>
> > >>
> > >> strictly speaking i would like to have ui switch between those two modes
> > >> distinguished here:
> > >> htt
Pavel Sanda wrote:
> Abdelrazak Younes wrote:
> >>> So, the checkbox you are proposing will govern the call to
> >>> setTreeDetph()?
> >>>
> >>
> >> strictly speaking i would like to have ui switch between those two modes
> >> distinguished here:
> >> http://www.lyx.org/trac/changeset/26637
leuven edwin wrote:
> Abdel wrote:
> > I am not very keen on adding this check box
>
> if i understand things correctly this checkbox is supposed to hide the
> symptom without solving the underlying problem. am i right?
no these are two different workflow modes how to use outliner.
> > but if t
Abdel wrote:
> I am not very keen on adding this check box
if i understand things correctly this checkbox is supposed to hide the symptom
without solving the underlying problem. am i right?
> but if this is the only solution to keep each type of user happy, why not...
because it leads to ui-blo
Abdelrazak Younes wrote:
>>> So, the checkbox you are proposing will govern the call to
>>> setTreeDetph()?
>>>
>>
>> strictly speaking i would like to have ui switch between those two modes
>> distinguished here:
>> http://www.lyx.org/trac/changeset/26637
>>
>
> OK, that was my understa
On Tue, Sep 30, 2008 at 12:11:52AM +0200, Pavel Sanda wrote:
> Richard Heck wrote:
> >>> i tend for 3. solution but would like to hear your opinions.
> >>>
> >> I prefer 2, kind off. This can be done completely in the frontend using
> >> simple string comparison techniques and session manageme
On 30/09/2008 16:01, Pavel Sanda wrote:
Abdelrazak Younes wrote:
Yes, well, that's a compromise...
i think this should be governed by some additional checkbox, but as you
don't
like it maybe the context menu is the solution?
So, the checkbox you are proposing will govern th
Abdelrazak Younes wrote:
> Yes, well, that's a compromise...
>
>> i think this should be governed by some additional checkbox, but as you
>> don't
>> like it maybe the context menu is the solution?
>>
>
> So, the checkbox you are proposing will govern the call to setTreeDetph()?
strictly spea
On 30/09/2008 14:24, Pavel Sanda wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
OK I can reproduce a slowdown in debug mode when the slide is set to the
maximum.
moving with cursor in maximum slider position is a typical case when this
happens. in fact the m
On 30/09/2008 14:28, Pavel Sanda wrote:
Abdelrazak Younes wrote:
I just checked and there is only one reset of TocModels. I guess you are
talking about the individual TocModel reset? Of course, there is as much
reset as there are models.
which triggers one more question - is it neede
Abdelrazak Younes wrote:
> I just checked and there is only one reset of TocModels. I guess you are
> talking about the individual TocModel reset? Of course, there is as much
> reset as there are models.
which triggers one more question - is it needed to rebuild all individual
tocmodel when onl
Abdelrazak Younes wrote:
>>> Abdelrazak Younes wrote:
OK I can reproduce a slowdown in debug mode when the slide is set to the
maximum.
>>>
>>> moving with cursor in maximum slider position is a typical case when this
>>> happens. in fact the maximum slider is for me just the consequence
On 30/09/2008 11:01, Abdelrazak Younes wrote:
On 30/09/2008 10:54, Pavel Sanda wrote:
Abdelrazak Younes wrote:
OK I can reproduce a slowdown in debug mode when the slide is set to
the
maximum.
moving with cursor in maximum slider position is a typical case when
this
happens. in fact the max
On 30/09/2008 10:54, Pavel Sanda wrote:
Abdelrazak Younes wrote:
OK I can reproduce a slowdown in debug mode when the slide is set to the
maximum.
moving with cursor in maximum slider position is a typical case when this
happens. in fact the maximum slider is for me just the conseque
Abdelrazak Younes wrote:
> OK I can reproduce a slowdown in debug mode when the slide is set to the
> maximum.
moving with cursor in maximum slider position is a typical case when this
happens. in fact the maximum slider is for me just the consequence of not
having persistency...
> One simple so
Abdelrazak Younes wrote:
> I just checked and there is only one reset of TocModels. I guess you are
> talking about the individual TocModel reset? Of course, there is as much
> reset as there are models.
ah yes, i put the breakpoint in the wrong place then ;)
pavel
Abdelrazak Younes wrote:
> There is no sensible delay under Windows, are you sure stdlib-debug is
> disabled?
>
>> - the code would be bigger than just freezng version
>>
>
> But a freezing checkbox is an additional control that encumber the dialog.
> I am definitely against that.
hum. but i
On 30/09/2008 00:11, Pavel Sanda wrote:
Richard Heck wrote:
i tend for 3. solution but would like to hear your opinions.
I prefer 2, kind off. This can be done completely in the frontend using
simple string comparison techniques and session management. Each time a
toc reset is re
On 30/09/2008 08:47, Abdelrazak Younes wrote:
On 30/09/2008 00:11, Pavel Sanda wrote:
even now is editation and movement with outliner significantly
slower.
There is no sensible delay under Windows, are you sure stdlib-debug is
disabled?
Even in full debug mode, typing in a section of t
On 30/09/2008 08:47, Abdelrazak Younes wrote:
On 30/09/2008 00:11, Pavel Sanda wrote:
Richard Heck wrote:
i tend for 3. solution but would like to hear your opinions.
I prefer 2, kind off. This can be done completely in the frontend
using
simple string comparison techniques and session manage
On 30/09/2008 00:11, Pavel Sanda wrote:
Richard Heck wrote:
i tend for 3. solution but would like to hear your opinions.
I prefer 2, kind off. This can be done completely in the frontend using
simple string comparison techniques and session management. Each time a
toc reset is re
Richard Heck wrote:
>>> i tend for 3. solution but would like to hear your opinions.
>>>
>> I prefer 2, kind off. This can be done completely in the frontend using
>> simple string comparison techniques and session management. Each time a
>> toc reset is requested, save in the session the str
Pavel Sanda wrote:
killermike wrote:
is big
enough that full uncollapsing is not usable
How about an "expand current section" button?
how is this connected with persistence ?
It's not directly connected but it does concern management of the
navigation sidebar. Such a featur
killermike wrote:
>> its constant frustration for me that it is not possible to keep outliner
>> tree view
>> in some persistent state. i very often need to uncollapse only few
>> branches in
>> my view to see the structure and move between these places. the document
>> is big
>> enough that ful
On Sun, Sep 28, 2008 at 11:22:02PM +0200, Pavel Sanda wrote:
> hi,
>
> its constant frustration for me that it is not possible to keep
> outliner tree view in some persistent state. i very often need to
> uncollapse only few branches in my view to see the structure and move
> between these places.
its constant frustration for me that it is not possible to keep outliner tree
view
in some persistent state. i very often need to uncollapse only few branches in
my view to see the structure and move between these places. the document is big
enough that full uncollapsing is not usable
How about
Abdelrazak Younes wrote:
On 28/09/2008 23:22, Pavel Sanda wrote:
hi,
its constant frustration for me that it is not possible to keep
outliner tree view
in some persistent state. i very often need to uncollapse only few
branches in
my view to see the structure and move between these places. th
On 28/09/2008 23:22, Pavel Sanda wrote:
hi,
its constant frustration for me that it is not possible to keep outliner tree
view
in some persistent state. i very often need to uncollapse only few branches in
my view to see the structure and move between these places. the document is big
enough th
Charles de Miramon wrote:
> Pavel Sanda wrote:
> >
> > i tend for 3. solution but would like to hear your opinions.
> >
>
> Why not have a Multiple View Component architecture ? The Outliner would be
> one view and the main window another view ; each view would have a
> infrastucture to remember
On 29/09/2008 11:03, Charles de Miramon wrote:
Pavel Sanda wrote:
i tend for 3. solution but would like to hear your opinions.
Why not have a Multiple View Component architecture ? The Outliner would be
one view and the main window another view ; each view would have a
infrastucture
Pavel Sanda wrote:
>
> i tend for 3. solution but would like to hear your opinions.
>
Why not have a Multiple View Component architecture ? The Outliner would be
one view and the main window another view ; each view would have a
infrastucture to remember what is collapsed or not. It would make p
hi,
its constant frustration for me that it is not possible to keep outliner tree
view
in some persistent state. i very often need to uncollapse only few branches in
my view to see the structure and move between these places. the document is big
enough that full uncollapsing is not usable.
it dr
40 matches
Mail list logo
