On Tue, Nov 07, 2006 at 08:00:18PM +0100, Joost Verburg wrote:
José Matos wrote:
Instead of hard-coding this like on Mac OS X right now, the Windows /
Mac installers can set a default in lyxrc.dist and users will always be
able to change it.
There are two separate issues as we have
On Tue, Nov 07, 2006 at 08:00:18PM +0100, Joost Verburg wrote:
> José Matos wrote:
> >>Instead of hard-coding this like on Mac OS X right now, the Windows /
> >>Mac installers can set a default in lyxrc.dist and users will always be
> >>able to change it.
> >
> > There are two separate issues as
On Thu, Nov 02, 2006 at 01:34:20PM +0100, Peter Kümmel wrote:
Thanks Abdel, this is very good. We should add it some where in the wiki.
And to the code somewhere. Perhaps BufferView.C with pointers from
buffer and LyXView.
Andre'
On Thu, Nov 02, 2006 at 01:34:20PM +0100, Peter Kümmel wrote:
> Thanks Abdel, this is very good. We should add it some where in the wiki.
And to the code somewhere. Perhaps BufferView.C with pointers from
buffer and LyXView.
Andre'
José == José Matos [EMAIL PROTECTED] writes:
Instead of hard-coding this like on Mac OS X right now, the Windows
/ Mac installers can set a default in lyxrc.dist and users will
always be able to change it.
The OSX case is different : this is specified at OS level and we
are not supposed to
> "José" == José Matos <[EMAIL PROTECTED]> writes:
>> Instead of hard-coding this like on Mac OS X right now, the Windows
>> / Mac installers can set a default in lyxrc.dist and users will
>> always be able to change it.
The OSX case is different : this is specified at OS level and we
are
Joost Verburg [EMAIL PROTECTED] writes:
| Jean-Marc Lasgouttes wrote:
| We could also have multiwindow without the possibility to have a
| buffer shown in two different views. This is still much better than
| two separate LyX instances, in terms of cut-and-paste in particular.
|
| Sure, but
On Tuesday 07 November 2006 4:59 pm, Lars Gullik Bjønnes wrote:
As already stated. I do not agree with the above statement at all.
I agree with Lars.
--
José Abílio
José Matos wrote:
As already stated. I do not agree with the above statement at all.
I agree with Lars.
What's wrong with a preference to configure this behavior? On Mac OS X
LyX already uses a single process and that's also what Windows users
expect. Windows users should not have to
On Tuesday 07 November 2006 6:10 pm, Joost Verburg wrote:
José Matos wrote:
As already stated. I do not agree with the above statement at all.
I agree with Lars.
What's wrong with a preference to configure this behavior? On Mac OS X
LyX already uses a single process and that's also
José Matos wrote:
Instead of hard-coding this like on Mac OS X right now, the Windows /
Mac installers can set a default in lyxrc.dist and users will always be
able to change it.
There are two separate issues as we have discussed before. I don't have any
problem with your proposal above.
Joost Verburg <[EMAIL PROTECTED]> writes:
| Jean-Marc Lasgouttes wrote:
| > We could also have multiwindow without the possibility to have a
| > buffer shown in two different views. This is still much better than
| > two separate LyX instances, in terms of cut-and-paste in particular.
|
| Sure,
On Tuesday 07 November 2006 4:59 pm, Lars Gullik Bjønnes wrote:
>
> As already stated. I do not agree with the above statement at all.
I agree with Lars.
--
José Abílio
José Matos wrote:
As already stated. I do not agree with the above statement at all.
I agree with Lars.
What's wrong with a preference to configure this behavior? On Mac OS X
LyX already uses a single process and that's also what Windows users
expect. Windows users should not have to
On Tuesday 07 November 2006 6:10 pm, Joost Verburg wrote:
> José Matos wrote:
> >> As already stated. I do not agree with the above statement at all.
> >
> > I agree with Lars.
>
> What's wrong with a preference to configure this behavior? On Mac OS X
> LyX already uses a single process and
José Matos wrote:
Instead of hard-coding this like on Mac OS X right now, the Windows /
Mac installers can set a default in lyxrc.dist and users will always be
able to change it.
There are two separate issues as we have discussed before. I don't have any
problem with your proposal above.
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak This is really, really _wrong_, a paragraph should not
Abdelrazak have any notion of rows. By modifying the geometry of the
Abdelrazak windows (the BufferView) you also modify the model (the
Abdelrazak Buffer) because the
Jean-Marc Lasgouttes wrote:
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak This is really, really _wrong_, a paragraph should not
Abdelrazak have any notion of rows. By modifying the geometry of the
Abdelrazak windows (the BufferView) you also modify the model (the
Jean-Marc Lasgouttes wrote:
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak This is really, really _wrong_, a paragraph should not
Abdelrazak have any notion of rows. By modifying the geometry of the
Abdelrazak windows (the BufferView) you also modify the
Helge Hafting wrote:
Jean-Marc Lasgouttes wrote:
Abdelrazak == Abdelrazak Younes
[EMAIL PROTECTED] writes:
Abdelrazak This is really, really _wrong_, a paragraph should not
Abdelrazak have any notion of rows. By modifying the geometry of the
Abdelrazak windows (the BufferView)
Helge == Helge Hafting [EMAIL PROTECTED] writes:
Disabling multi-window is not very funny, but it might be the best
solution indeed.
Helge Well, ability to split the window into a upper and lower part
Helge also does the trick - if the requirement for now is that
Helge same-width must be
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Another idea: When you resize the width of one window, all multiple
views are forcibly resized to the same width. This also works
around the same-width limitation, and takes away the need to change
anything else.
Abdelrazak Yes this
Jean-Marc Lasgouttes wrote:
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Another idea: When you resize the width of one window, all multiple
views are forcibly resized to the same width. This also works
around the same-width limitation, and takes away the need to change
anything
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak Hum, this is indeed a usability problem... What about
Abdelrazak letting it stay like it is now? FYI, what we have now is:
Abdelrazak If you resize one window showing one document, then, if
Abdelrazak some other window is also
Jean-Marc Lasgouttes wrote:
We could also have multiwindow without the possibility to have a
buffer shown in two different views. This is still much better than
two separate LyX instances, in terms of cut-and-paste in particular.
Yes - that would be great! Finally, able to both see two
On Nov 6, 2006, at 10:06 AM, Helge Hafting wrote:
Jean-Marc Lasgouttes wrote:
We could also have multiwindow without the possibility to have a
buffer shown in two different views. This is still much better than
two separate LyX instances, in terms of cut-and-paste in particular.
Yes - that
Jean-Marc Lasgouttes wrote:
We could also have multiwindow without the possibility to have a
buffer shown in two different views. This is still much better than
two separate LyX instances, in terms of cut-and-paste in particular.
Sure, but then we need agreement about whether using a single
Jean-Marc Lasgouttes wrote:
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak Hum, this is indeed a usability problem... What about
Abdelrazak letting it stay like it is now? FYI, what we have now is:
Abdelrazak If you resize one window showing one document, then, if
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak Fine with me. But let's postpone a bit this decision
Abdelrazak please. Maybe I (or someone else) will find the time to
Abdelrazak fix this problem before the second alpha. If not, then
Abdelrazak we'll make the decision at
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
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> This is really, really _wrong_, a paragraph should not
Abdelrazak> have any notion of rows. By modifying the geometry of the
Abdelrazak> windows (the BufferView) you also modify the model (the
Abdelrazak> Buffer)
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> This is really, really _wrong_, a paragraph should not
Abdelrazak> have any notion of rows. By modifying the geometry of the
Abdelrazak> windows (the BufferView) you also modify the model (the
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> This is really, really _wrong_, a paragraph should not
Abdelrazak> have any notion of rows. By modifying the geometry of the
Abdelrazak> windows (the BufferView) you also modify
Helge Hafting wrote:
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes
<[EMAIL PROTECTED]> writes:
Abdelrazak> This is really, really _wrong_, a paragraph should not
Abdelrazak> have any notion of rows. By modifying the geometry of the
Abdelrazak> windows (the
> "Helge" == Helge Hafting <[EMAIL PROTECTED]> writes:
>> Disabling multi-window is not very funny, but it might be the best
>> solution indeed.
>>
Helge> Well, ability to split the window into a upper and lower part
Helge> also does the trick - if the requirement for now is that
Helge>
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> Another idea: When you resize the width of one window, all multiple
>> views are forcibly resized to the same width. This also works
>> around the same-width limitation, and takes away the need to change
>> anything else.
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Another idea: When you resize the width of one window, all multiple
views are forcibly resized to the same width. This also works
around the same-width limitation, and takes away the need to change
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Hum, this is indeed a usability problem... What about
Abdelrazak> letting it stay like it is now? FYI, what we have now is:
Abdelrazak> If you resize one window showing one document, then, if
Abdelrazak> some other
Jean-Marc Lasgouttes wrote:
We could also have multiwindow without the possibility to have a
buffer shown in two different views. This is still much better than
two separate LyX instances, in terms of cut-and-paste in particular.
Yes - that would be great! Finally, able to both see two
On Nov 6, 2006, at 10:06 AM, Helge Hafting wrote:
Jean-Marc Lasgouttes wrote:
We could also have multiwindow without the possibility to have a
buffer shown in two different views. This is still much better than
two separate LyX instances, in terms of cut-and-paste in particular.
Yes - that
Jean-Marc Lasgouttes wrote:
We could also have multiwindow without the possibility to have a
buffer shown in two different views. This is still much better than
two separate LyX instances, in terms of cut-and-paste in particular.
Sure, but then we need agreement about whether using a single
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Hum, this is indeed a usability problem... What about
Abdelrazak> letting it stay like it is now? FYI, what we have now is:
Abdelrazak> If you resize one window showing one document, then, if
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Fine with me. But let's postpone a bit this decision
Abdelrazak> please. Maybe I (or someone else) will find the time to
Abdelrazak> fix this problem before the second alpha. If not, then
Abdelrazak> we'll make the
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
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
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
Abdelrazak Younes wrote:
Bo Peng wrote:
Yeah, it was not that hard (see below). It's just that I don't have much
time.
This does solves my bookmark problem, but are you sure it is a good
idea to open all buffers that was opened in the parent window?
I know you understand the difference
Abdelrazak Younes wrote:
I propose to remove the multi-window feature from the menu, or even
remove the LFUN entirely. We can have it back when the new TabWidget
that will replace the tabbar is ready (most probably in 1.6).
But we could also explain it to the user how it works:
Beware there
Peter Kümmel wrote:
A other solution is to somehow handle within the views which part
of the buffer is viewed.
This is what we have already: Each LyXView (WorkArea really) has its own
unique BufferView which is a view of one part of the document. Except
for some cursor bug (the famous dEPM
Abdelrazak Younes wrote:
Peter Kümmel wrote:
A other solution is to somehow handle within the views which part
of the buffer is viewed.
This is what we have already: Each LyXView (WorkArea really) has its own
unique BufferView which is a view of one part of the document. Except
for some
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Peter Kümmel wrote:
|
| A other solution is to somehow handle within the views which part
| of the buffer is viewed.
|
| This is what we have already: Each LyXView (WorkArea really) has its
| own unique BufferView which is a view of one part of
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
A other solution is to somehow handle within the views which part
of the buffer is viewed.
This is what we have already: Each LyXView (WorkArea really) has its own
unique BufferView which is a view of one part of the document.
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Peter Kümmel wrote:
|
| A other solution is to somehow handle within the views which part
| of the buffer is viewed.
|
| This is what we have already: Each LyXView (WorkArea really) has its
| own unique BufferView
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| Abdelrazak Younes [EMAIL PROTECTED] writes:
| | Peter Kümmel wrote:
| | | A other solution is to somehow handle within the views which
| part
| | of the buffer is viewed.
| | | This is what we have already: Each
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
A other solution is to somehow handle within the views which part
of the buffer is viewed.
This is what we have already: Each LyXView (WorkArea really) has its own
unique BufferView which is a view of
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
A other solution is to somehow handle within the views which part
of the buffer is viewed.
This is what we have already: Each LyXView (WorkArea really) has its own
unique BufferView which is a view of
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| Abdelrazak Younes [EMAIL PROTECTED] writes:
| | Peter Kümmel wrote:
| | | A other solution is to somehow handle within the views which
| part
| | of the buffer is viewed.
| | | This is
Georg is right, the LyX core is not ready for Multiple-view. There's too
much that needs to be re-designed. So either someone steps up and
cleanup that mess by putting the rows calculation outside of the Buffer
or we disable the multi-windows feature.
I would be really disappointed to see
Bo Peng wrote:
Georg is right, the LyX core is not ready for Multiple-view. There's too
much that needs to be re-designed. So either someone steps up and
cleanup that mess by putting the rows calculation outside of the Buffer
or we disable the multi-windows feature.
I would be really
1) make sure that the two windows size (the BufferView) are exactly the
same size.
2) Instead of multi-window we could implement the multi-workarea within
one window using the TabWidget solution I have outlined earlier. Then,
we will be sure that two BufferView of the same Buffer would have the
Bo Peng wrote:
1) make sure that the two windows size (the BufferView) are exactly the
same size.
2) Instead of multi-window we could implement the multi-workarea within
one window using the TabWidget solution I have outlined earlier. Then,
we will be sure that two BufferView of the same Buffer
Abdelrazak Younes wrote:
> Bo Peng wrote:
>>> Yeah, it was not that hard (see below). It's just that I don't have much
>>> time.
>>
>> This does solves my bookmark problem, but are you sure it is a good
>> idea to open all buffers that was opened in the parent window?
>
> I know you understand
Abdelrazak Younes wrote:
> I propose to remove the multi-window feature from the menu, or even
> remove the LFUN entirely. We can have it back when the new TabWidget
> that will replace the tabbar is ready (most probably in 1.6).
But we could also explain it to the user how it works:
"Beware
Peter Kümmel wrote:
A other solution is to somehow handle within the views which part
of the buffer is viewed.
This is what we have already: Each LyXView (WorkArea really) has its own
unique BufferView which is a view of one part of the document. Except
for some cursor bug (the famous dEPM
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>
>>
>> A other solution is to somehow handle within the views which part
>> of the buffer is viewed.
>
> This is what we have already: Each LyXView (WorkArea really) has its own
> unique BufferView which is a view of one part of the document.
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Peter Kümmel wrote:
|
| > A other solution is to somehow handle within the views which part
| > of the buffer is viewed.
|
| This is what we have already: Each LyXView (WorkArea really) has its
| own unique BufferView which is a view of one part
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
A other solution is to somehow handle within the views which part
of the buffer is viewed.
This is what we have already: Each LyXView (WorkArea really) has its own
unique BufferView which is a view of one part of the document.
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Peter Kümmel wrote:
|
| > A other solution is to somehow handle within the views which part
| > of the buffer is viewed.
|
| This is what we have already: Each LyXView (WorkArea really) has its
| own unique
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Peter Kümmel wrote:
| > | | > A other solution is to somehow handle within the views which
| > part
| > | > of the buffer is viewed.
| > | | This is what we have
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> Abdelrazak Younes wrote:
>>> Peter Kümmel wrote:
>>>
A other solution is to somehow handle within the views which part
of the buffer is viewed.
>>> This is what we have already: Each LyXView (WorkArea really) has its own
>>> unique
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> Abdelrazak Younes wrote:
>>> Peter Kümmel wrote:
>>>
A other solution is to somehow handle within the views which part
of the buffer is viewed.
>>> This is what we have already: Each LyXView (WorkArea really) has its own
>>> unique
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Peter Kümmel wrote:
| > | | > A other solution is to somehow handle within the views which
| > part
| > | > of the buffer is viewed.
| >
Georg is right, the LyX core is not ready for Multiple-view. There's too
much that needs to be re-designed. So either someone steps up and
cleanup that mess by putting the rows calculation outside of the Buffer
or we disable the multi-windows feature.
I would be really disappointed to see
Bo Peng wrote:
Georg is right, the LyX core is not ready for Multiple-view. There's too
much that needs to be re-designed. So either someone steps up and
cleanup that mess by putting the rows calculation outside of the Buffer
or we disable the multi-windows feature.
I would be really
1) make sure that the two windows size (the BufferView) are exactly the
same size.
2) Instead of multi-window we could implement the multi-workarea within
one window using the TabWidget solution I have outlined earlier. Then,
we will be sure that two BufferView of the same Buffer would have the
Bo Peng wrote:
1) make sure that the two windows size (the BufferView) are exactly the
same size.
2) Instead of multi-window we could implement the multi-workarea within
one window using the TabWidget solution I have outlined earlier. Then,
we will be sure that two BufferView of the same Buffer
76 matches
Mail list logo
