Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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'
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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'
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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
Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 but for the sake of clarity let me repeat that again: The buffers are not opened again in the second window. They are opened once and only once. A window can only show one buffer at a time. The new tabbar is designed to show a list of all available buffer (this is Peter's doing, not mine). So this is independent from the number of opened windows. As it is now, the TabBar is just a shortcut for the View-Document submenu, that's all. I've already warned you all about that multiple times. My proposal was that we do not open any buffer but allow users to switch to them from view menu item. That was just my preference though. Read above: the Buffer is not opened again, only shown. With the new tabbar, it is all or nothing, you don't have a choice. All, please listen: 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). Abdel.
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 but for the sake of clarity let me repeat that again: The buffers are not opened again in the second window. They are opened once and only once. Maybe it helps when we describe it in other words. Due to Abdel's great work we now have a Model/View design. The buffers are the models and the Windows are the views. As you know there is only one model but arbitrarily much views. The problem is now, what do we with the views, they are all identical, because currently they are a whole view of the model. Maybe it is really the best do disable the multiple-view support until we know how we will handle this. One idea is to divide the one bug buffer into several smaller ones which all are viewed by a view, which doesn't know anything about other buffers. But then a multiple view of one document becomes impossible. To have this we could use something like a buffer-proxy... A other solution is to somehow handle within the views which part of the buffer is viewed. A window can only show one buffer at a time. The new tabbar is designed to show a list of all available buffer (this is Peter's doing, not mine). So this is independent from the number of opened windows. As it is now, the TabBar is just a shortcut for the View-Document submenu, that's all. I've already warned you all about that multiple times. My proposal was that we do not open any buffer but allow users to switch to them from view menu item. That was just my preference though. Read above: the Buffer is not opened again, only shown. With the new tabbar, it is all or nothing, you don't have a choice. All, please listen: 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). Abdel. -- Peter Kümmel
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 is only ONE document in your computer-memory but you could edit this ONE document with MULTIPLE windows. Then we will have some feedback how usefull this is, how the user likes it, which ideas they have to change the behavior, and so on. Isn't THIS the purpose a alpha release? We want feedback, not release the final product. -- Peter Kümmel
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 bug), this is working fine. Abdel.
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 cursor bug (the famous dEPM bug), this is working fine. Abdel. Ah, didn't know that. So could you describe the design a little bit with the MVC language, I think this will help a lot of people to read and understand the code. Something like this: model: - buffer the one big buffer view: - WorkArea partly view of the buffer - lyxview frontent impl of the view -- Peter Kümmel
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 the document. | Except for some cursor bug (the famous dEPM bug), this is working fine. ..except that metrics is shared between views. (And this fails miserably when the windows are of different widths.) -- Lgb
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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. Except for some cursor bug (the famous dEPM bug), this is working fine. Abdel. Ah, didn't know that. So could you describe the design a little bit with the MVC language, I think this will help a lot of people to read and understand the code. Something like this: model: - buffer the one big buffer view: - WorkArea partly view of the buffer - lyxview frontent impl of the view OK, here is my try at it: 1) The Model: Buffer The Buffer is the in-memory representation of a LyX file format. The Buffer does not (should not) have any information on what part of it is represented on screen. There is one unique Buffer per opened LyX file. 2) The Controller: BufferView/Painter The BufferView is a tool used by the view that translates a part of the Buffer contents into drawing routines. The BufferView asks each inset of the Buffer to draw itself onto the screen using the Painter. There is only Buffer loaded per BufferView. While there is the possibility to switch Buffer inside the BufferView, the goal is to instantiate a new BufferView on each Buffer switch. The Painter is just a virtual interface to formalize each kind of drawing routines (text, line, rectangle, etc). The BufferView also contains a Cursor which may or may not be visible on screen. The cursor is really just a bookmark to remember where the next Buffer insertion/deletion is going to take place. 3) The View: WorkArea (and it's qt4 specialisation GuiWorkArea) This contains the real screen area where the drawing is done by the Painter. One WorkArea holds one unique BufferView. While it could be possible that multiple WorkArea share one BufferView, this is not possible right now. The WorkArea also provide a scrollbar which position is translated into scrolling command to the inner BufferView. The WorkArea use the BufferView to translate each keyboard or mouse events into terms that the Buffer can understand: - insert/delete char - select char - etc. 4) The Window: LyXView (and its qt4 specialisation GuiView) This is a full window containing a menubar, toolbars, a tabbar and a WorkArea. One LyXView could in theory contain multiple WorkArea (ex: with split window) but this number is limited to one only for now. In any case, there would be only one WorkArea that gets the focus at a time. Now, concerning the TabBar versus TabWidget issue. Right now, there is only one WorkArea and the TabBar just used to tell the BufferView inside the WorkArea to switch to this another Buffer. With a TabWidget, each Tab would own its own WorkArea. Clicking on a tab would switch a WorkArea instead of a Buffer. That's all, I hope my English is clear enough and that helps some of you better understand the global picture. Back to my real work. Abdel.
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 which is a view of one part of the document. | Except for some cursor bug (the famous dEPM bug), this is working fine. ..except that metrics is shared between views. This should not be. Each BufferView now has its own CoordCache. If there's still something shared, this should be fixed. (And this fails miserably when the windows are of different widths.) The problem is different here. I believe that there's some cursor interaction problem that leads. This leads to crashes but most of the time, if you have two BufferView sharing the same Buffer, changing the geometry of one does not impact the other one (except if there's some editing that invalidated the cursor of the other BufferView). Abdel.
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 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 bug), this is working fine. | ..except that metrics is shared between views. | | This should not be. Each BufferView now has its own CoordCache. If | there's still something shared, this should be fixed. | | | (And this fails miserably when the windows are of different widths.) | | The problem is different here. I believe that there's some cursor | interaction problem that leads. This leads to crashes but most of the | time, if you have two BufferView sharing the same Buffer, changing the | geometry of one does not impact the other one (except if there's some | editing that invalidated the cursor of the other BufferView). Just try it for yourself and you will see. -- Lgb
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 one part of the document. Except for some cursor bug (the famous dEPM bug), this is working fine. Abdel. Ah, didn't know that. So could you describe the design a little bit with the MVC language, I think this will help a lot of people to read and understand the code. Something like this: model: - buffer the one big buffer view: - WorkArea partly view of the buffer - lyxview frontent impl of the view OK, here is my try at it: 1) The Model: Buffer The Buffer is the in-memory representation of a LyX file format. The Buffer does not (should not) have any information on what part of it is represented on screen. There is one unique Buffer per opened LyX file. 2) The Controller: BufferView/Painter The BufferView is a tool used by the view that translates a part of the Buffer contents into drawing routines. The BufferView asks each inset of the Buffer to draw itself onto the screen using the Painter. There is only Buffer loaded per BufferView. While there is the possibility to switch Buffer inside the BufferView, the goal is to instantiate a new BufferView on each Buffer switch. The Painter is just a virtual interface to formalize each kind of drawing routines (text, line, rectangle, etc). The BufferView also contains a Cursor which may or may not be visible on screen. The cursor is really just a bookmark to remember where the next Buffer insertion/deletion is going to take place. 3) The View: WorkArea (and it's qt4 specialisation GuiWorkArea) This contains the real screen area where the drawing is done by the Painter. One WorkArea holds one unique BufferView. While it could be possible that multiple WorkArea share one BufferView, this is not possible right now. The WorkArea also provide a scrollbar which position is translated into scrolling command to the inner BufferView. The WorkArea use the BufferView to translate each keyboard or mouse events into terms that the Buffer can understand: - insert/delete char - select char - etc. 4) The Window: LyXView (and its qt4 specialisation GuiView) This is a full window containing a menubar, toolbars, a tabbar and a WorkArea. One LyXView could in theory contain multiple WorkArea (ex: with split window) but this number is limited to one only for now. In any case, there would be only one WorkArea that gets the focus at a time. Now, concerning the TabBar versus TabWidget issue. Right now, there is only one WorkArea and the TabBar just used to tell the BufferView inside the WorkArea to switch to this another Buffer. With a TabWidget, each Tab would own its own WorkArea. Clicking on a tab would switch a WorkArea instead of a Buffer. That's all, I hope my English is clear enough and that helps some of you better understand the global picture. Back to my real work. Abdel. Thanks Abdel, this is very good. We should add it some where in the wiki. Peter
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 one part of the document. Except for some cursor bug (the famous dEPM bug), this is working fine. Abdel. Ah, didn't know that. So could you describe the design a little bit with the MVC language, I think this will help a lot of people to read and understand the code. Something like this: model: - buffer the one big buffer view: - WorkArea partly view of the buffer - lyxview frontent impl of the view OK, here is my try at it: 1) The Model: Buffer The Buffer is the in-memory representation of a LyX file format. The Buffer does not (should not) have any information on what part of it is represented on screen. There is one unique Buffer per opened LyX file. 2) The Controller: BufferView/Painter The BufferView is a tool used by the view that translates a part of the Buffer contents into drawing routines. The BufferView asks each inset of the Buffer to draw itself onto the screen using the Painter. There is only Buffer loaded per BufferView. While there is the possibility to switch Buffer inside the BufferView, the goal is to instantiate a new BufferView on each Buffer switch. The Painter is just a virtual interface to formalize each kind of drawing routines (text, line, rectangle, etc). The BufferView also contains a Cursor which may or may not be visible on screen. The cursor is really just a bookmark to remember where the next Buffer insertion/deletion is going to take place. 3) The View: WorkArea (and it's qt4 specialisation GuiWorkArea) This contains the real screen area where the drawing is done by the Painter. One WorkArea holds one unique BufferView. While it could be possible that multiple WorkArea share one BufferView, this is not possible right now. The WorkArea also provide a scrollbar which position is translated into scrolling command to the inner BufferView. The WorkArea use the BufferView to translate each keyboard or mouse events into terms that the Buffer can understand: - insert/delete char - select char - etc. 4) The Window: LyXView (and its qt4 specialisation GuiView) This is a full window containing a menubar, toolbars, a tabbar and a WorkArea. One LyXView could in theory contain multiple WorkArea (ex: with split window) but this number is limited to one only for now. In any case, there would be only one WorkArea that gets the focus at a time. Now, concerning the TabBar versus TabWidget issue. Right now, there is only one WorkArea and the TabBar just used to tell the BufferView inside the WorkArea to switch to this another Buffer. With a TabWidget, each Tab would own its own WorkArea. Clicking on a tab would switch a WorkArea instead of a Buffer. That's all, I hope my English is clear enough and that helps some of you better understand the global picture. Back to my real work. Abdel. We could also add it some where in to development/. -- Peter Kümmel
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 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 bug), this is working fine.
| ..except that metrics is shared between views.
|
| This should not be. Each BufferView now has its own CoordCache. If
| there's still something shared, this should be fixed.
|
|
| (And this fails miserably when the windows are of different widths.)
|
| The problem is different here. I believe that there's some cursor
| interaction problem that leads. This leads to crashes but most of the
| time, if you have two BufferView sharing the same Buffer, changing the
| geometry of one does not impact the other one (except if there's some
| editing that invalidated the cursor of the other BufferView).
Just try it for yourself and you will see.
As I said, the problem is not related to metrics but to a bad paragraph
model. More exactly this (in paragraph.h):
/// LyXText updates the rows using this access point
RowList rows() { return rows_; }
/// The painter and others use this
RowList const rows() const { return rows_; }
This is really, really _wrong_, a paragraph should not have any notion
of rows. By modifying the geometry of the windows (the BufferView) you
also modify the model (the Buffer) because the rows() information is not
valid any more.
rows is a RowList, that is a vector of row:
/**
* Each paragraph is broken up into a number of rows on the screen.
* This is a list of such on-screen rows, ordered from the top row
* downwards.
*/
typedef std::vectorRow RowList;
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.
Abdel.
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 mutlti-view gone. It is the biggest feature I would like to have in 1.5.x. You see, if it does not come with 1.5.0, then it will be too big for 1.5.x and we have to wait till 1.6 ... People who knows lyx-core better please help. Bo
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 disappointed to see mutlti-view gone. It is the biggest feature I would like to have in 1.5.x. You see, if it does not come with 1.5.0, then it will be too big for 1.5.x and we have to wait till 1.6 ... People who knows lyx-core better please help. If this is really wanted there's two solutions: 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 exact same size. Abdel.
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 exact same size. 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. Bo
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 would have the exact same size. 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. Here is some explanations that I wrote earlier: 1) The Model: Buffer The Buffer is the in-memory representation of a LyX file format. The Buffer does not (should not) have any information on what part of it is represented on screen. There is one unique Buffer per opened LyX file. 2) The Controller: BufferView/Painter The BufferView is a tool used by the view that translates a part of the Buffer contents into drawing routines. The BufferView asks each inset of the Buffer to draw itself onto the screen using the Painter. There is only Buffer loaded per BufferView. While there is the possibility to switch Buffer inside the BufferView, the goal is to instantiate a new BufferView on each Buffer switch. The Painter is just a virtual interface to formalize each kind of drawing routines (text, line, rectangle, etc). The BufferView also contains a Cursor which may or may not be visible on screen. The cursor is really just a bookmark to remember where the next Buffer insertion/deletion is going to take place. 3) The View: WorkArea (and it's qt4 specialisation GuiWorkArea) This contains the real screen area where the drawing is done by the Painter. One WorkArea holds one unique BufferView. While it could be possible that multiple WorkArea share one BufferView, this is not possible right now. The WorkArea also provide a scrollbar which position is translated into scrolling command to the inner BufferView. The WorkArea use the BufferView to translate each keyboard or mouse events into terms that the Buffer can understand: - insert/delete char - select char - etc. 4) The Window: LyXView (and its qt4 specialisation GuiView) This is a full window containing a menubar, toolbars, a tabbar and a WorkArea. One LyXView could in theory contain multiple WorkArea (ex: with split window) but this number is limited to one only for now. In any case, there would be only one WorkArea that gets the focus at a time. Now, concerning the TabBar versus TabWidget issue. Right now, there is only one WorkArea and the TabBar just used to tell the BufferView inside the WorkArea to switch to this another Buffer. With a TabWidget, each Tab would own its own WorkArea. Clicking on a tab would switch a WorkArea instead of a Buffer. That's all, I hope my English is clear enough and that helps some of you better understand the global picture. Back to my real work. Abdel.
Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 but for the sake of clarity let me repeat that again: The buffers are not opened again in the second window. They are opened once and only once. A window can only show one buffer at a time. The new tabbar is designed to show a list of all available buffer (this is Peter's doing, not mine). So this is independent from the number of opened windows. As it is now, the TabBar is just a shortcut for the View->Document submenu, that's all. I've already warned you all about that multiple times. My proposal was that we do not open any buffer but allow users to switch to them from view menu item. That was just my preference though. Read above: the Buffer is not opened again, only shown. With the new tabbar, it is all or nothing, you don't have a choice. All, please listen: 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). Abdel.
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 but for the sake of clarity let me > repeat that again: The buffers are not opened again in the second > window. They are opened once and only once. Maybe it helps when we describe it in other words. Due to Abdel's great work we now have a Model/View design. The buffers are the models and the Windows are the views. As you know there is only one model but arbitrarily much views. The problem is now, what do we with the views, they are all identical, because currently they are a whole view of the model. Maybe it is really the best do disable the multiple-view support until we know how we will handle this. One idea is to divide the one bug buffer into several smaller ones which all are viewed by a view, which doesn't know anything about other buffers. But then a multiple view of one document becomes impossible. To have this we could use something like a buffer-proxy... A other solution is to somehow handle within the views which part of the buffer is viewed. > A window can only show one buffer at a time. The new tabbar is designed > to show a list of all available buffer (this is Peter's doing, not > mine). So this is independent from the number of opened windows. > > As it is now, the TabBar is just a shortcut for the View->Document > submenu, that's all. I've already warned you all about that multiple times. > >> My proposal was that we do not open any buffer but allow users to >> switch to them from view menu item. That was just my preference >> though. > > Read above: the Buffer is not opened again, only shown. With the new > tabbar, it is all or nothing, you don't have a choice. > > All, please listen: > > 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). > > Abdel. > > -- Peter Kümmel
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 is only ONE document in your computer-memory but you could edit this ONE document with MULTIPLE windows." Then we will have some feedback how usefull this is, how the user likes it, which ideas they have to change the behavior, and so on. Isn't THIS the purpose a alpha release? We want feedback, not release the final product. -- Peter Kümmel
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 bug), this is working fine. Abdel.
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 cursor bug (the famous dEPM bug), this is working fine. > > Abdel. > > Ah, didn't know that. So could you describe the design a little bit with the MVC language, I think this will help a lot of people to read and understand the code. Something like this: model: - buffer the one big buffer view: - WorkArea partly view of the buffer - lyxview frontent impl of the view -- Peter Kümmel
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 the document. | Except for some cursor bug (the famous dEPM bug), this is working fine. ..except that metrics is shared between views. (And this fails miserably when the windows are of different widths.) -- Lgb
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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. Except for some cursor bug (the famous dEPM bug), this is working fine. Abdel. Ah, didn't know that. So could you describe the design a little bit with the MVC language, I think this will help a lot of people to read and understand the code. Something like this: model: - buffer the one big buffer view: - WorkArea partly view of the buffer - lyxview frontent impl of the view OK, here is my try at it: 1) The Model: Buffer The Buffer is the in-memory representation of a LyX file format. The Buffer does not (should not) have any information on what part of it is represented on screen. There is one unique Buffer per opened LyX file. 2) The Controller: BufferView/Painter The BufferView is a tool used by the view that translates a part of the Buffer contents into drawing routines. The BufferView asks each inset of the Buffer to draw itself onto the screen using the Painter. There is only Buffer loaded per BufferView. While there is the possibility to switch Buffer inside the BufferView, the goal is to instantiate a new BufferView on each Buffer switch. The Painter is just a virtual interface to formalize each kind of drawing routines (text, line, rectangle, etc). The BufferView also contains a Cursor which may or may not be visible on screen. The cursor is really just a bookmark to remember where the next Buffer insertion/deletion is going to take place. 3) The View: WorkArea (and it's qt4 specialisation GuiWorkArea) This contains the real screen area where the drawing is done by the Painter. One WorkArea holds one unique BufferView. While it could be possible that multiple WorkArea share one BufferView, this is not possible right now. The WorkArea also provide a scrollbar which position is translated into scrolling command to the inner BufferView. The WorkArea use the BufferView to translate each keyboard or mouse events into terms that the Buffer can understand: - insert/delete char - select char - etc. 4) The Window: LyXView (and its qt4 specialisation GuiView) This is a full window containing a menubar, toolbars, a tabbar and a WorkArea. One LyXView could in theory contain multiple WorkArea (ex: with split window) but this number is limited to one only for now. In any case, there would be only one WorkArea that gets the focus at a time. Now, concerning the TabBar versus TabWidget issue. Right now, there is only one WorkArea and the TabBar just used to tell the BufferView inside the WorkArea to switch to this another Buffer. With a TabWidget, each Tab would own its own WorkArea. Clicking on a tab would switch a WorkArea instead of a Buffer. That's all, I hope my English is clear enough and that helps some of you better understand the global picture. Back to my real work. Abdel.
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 which is a view of one part of the document. | Except for some cursor bug (the famous dEPM bug), this is working fine. ..except that metrics is shared between views. This should not be. Each BufferView now has its own CoordCache. If there's still something shared, this should be fixed. (And this fails miserably when the windows are of different widths.) The problem is different here. I believe that there's some cursor interaction problem that leads. This leads to crashes but most of the time, if you have two BufferView sharing the same Buffer, changing the geometry of one does not impact the other one (except if there's some editing that invalidated the cursor of the other BufferView). Abdel.
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 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 bug), this is working fine. | > ..except that metrics is shared between views. | | This should not be. Each BufferView now has its own CoordCache. If | there's still something shared, this should be fixed. | | | > (And this fails miserably when the windows are of different widths.) | | The problem is different here. I believe that there's some cursor | interaction problem that leads. This leads to crashes but most of the | time, if you have two BufferView sharing the same Buffer, changing the | geometry of one does not impact the other one (except if there's some | editing that invalidated the cursor of the other BufferView). Just try it for yourself and you will see. -- Lgb
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 one part of the document. Except >>> for some cursor bug (the famous dEPM bug), this is working fine. >>> >>> Abdel. >>> >>> >> >> Ah, didn't know that. So could you describe the design a little bit >> with the MVC language, I think this will help a lot of people to >> read and understand the code. >> >> Something like this: >> >> model: >> - buffer the one big buffer >> >> view: >> - WorkArea partly view of the buffer >> - lyxview frontent impl of the view > > OK, here is my try at it: > > 1) The Model: Buffer > > The Buffer is the in-memory representation of a LyX file format. The > Buffer does not (should not) have any information on what part of it is > represented on screen. There is one unique Buffer per opened LyX file. > > > 2) The Controller: BufferView/Painter > > The BufferView is a tool used by the view that translates a part of the > Buffer contents into drawing routines. The BufferView asks each inset of > the Buffer to draw itself onto the screen using the Painter. > There is only Buffer loaded per BufferView. While there is the > possibility to switch Buffer inside the BufferView, the goal is to > instantiate a new BufferView on each Buffer switch. > > The Painter is just a virtual interface to formalize each kind of > drawing routines (text, line, rectangle, etc). > > The BufferView also contains a Cursor which may or may not be visible on > screen. The cursor is really just a bookmark to remember where the next > Buffer insertion/deletion is going to take place. > > > 3) The View: WorkArea (and it's qt4 specialisation GuiWorkArea) > > This contains the real screen area where the drawing is done by the > Painter. One WorkArea holds one unique BufferView. While it could be > possible that multiple WorkArea share one BufferView, this is not > possible right now. > The WorkArea also provide a scrollbar which position is translated into > scrolling command to the inner BufferView. > > The WorkArea use the BufferView to translate each keyboard or mouse > events into terms that the Buffer can understand: > - insert/delete char > - select char > - etc. > > > 4) The Window: LyXView (and its qt4 specialisation GuiView) > > This is a full window containing a menubar, toolbars, a tabbar and a > WorkArea. One LyXView could in theory contain multiple WorkArea (ex: > with split window) but this number is limited to one only for now. In > any case, there would be only one WorkArea that gets the focus at a time. > > Now, concerning the TabBar versus TabWidget issue. Right now, there is > only one WorkArea and the TabBar just used to tell the BufferView inside > the WorkArea to switch to this another Buffer. > With a TabWidget, each Tab would own its own WorkArea. Clicking on a tab > would switch a WorkArea instead of a Buffer. > > That's all, I hope my English is clear enough and that helps some of you > better understand the global picture. Back to my real work. > > Abdel. Thanks Abdel, this is very good. We should add it some where in the wiki. Peter
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 one part of the document. Except >>> for some cursor bug (the famous dEPM bug), this is working fine. >>> >>> Abdel. >>> >>> >> >> Ah, didn't know that. So could you describe the design a little bit >> with the MVC language, I think this will help a lot of people to >> read and understand the code. >> >> Something like this: >> >> model: >> - buffer the one big buffer >> >> view: >> - WorkArea partly view of the buffer >> - lyxview frontent impl of the view > > OK, here is my try at it: > > 1) The Model: Buffer > > The Buffer is the in-memory representation of a LyX file format. The > Buffer does not (should not) have any information on what part of it is > represented on screen. There is one unique Buffer per opened LyX file. > > > 2) The Controller: BufferView/Painter > > The BufferView is a tool used by the view that translates a part of the > Buffer contents into drawing routines. The BufferView asks each inset of > the Buffer to draw itself onto the screen using the Painter. > There is only Buffer loaded per BufferView. While there is the > possibility to switch Buffer inside the BufferView, the goal is to > instantiate a new BufferView on each Buffer switch. > > The Painter is just a virtual interface to formalize each kind of > drawing routines (text, line, rectangle, etc). > > The BufferView also contains a Cursor which may or may not be visible on > screen. The cursor is really just a bookmark to remember where the next > Buffer insertion/deletion is going to take place. > > > 3) The View: WorkArea (and it's qt4 specialisation GuiWorkArea) > > This contains the real screen area where the drawing is done by the > Painter. One WorkArea holds one unique BufferView. While it could be > possible that multiple WorkArea share one BufferView, this is not > possible right now. > The WorkArea also provide a scrollbar which position is translated into > scrolling command to the inner BufferView. > > The WorkArea use the BufferView to translate each keyboard or mouse > events into terms that the Buffer can understand: > - insert/delete char > - select char > - etc. > > > 4) The Window: LyXView (and its qt4 specialisation GuiView) > > This is a full window containing a menubar, toolbars, a tabbar and a > WorkArea. One LyXView could in theory contain multiple WorkArea (ex: > with split window) but this number is limited to one only for now. In > any case, there would be only one WorkArea that gets the focus at a time. > > Now, concerning the TabBar versus TabWidget issue. Right now, there is > only one WorkArea and the TabBar just used to tell the BufferView inside > the WorkArea to switch to this another Buffer. > With a TabWidget, each Tab would own its own WorkArea. Clicking on a tab > would switch a WorkArea instead of a Buffer. > > That's all, I hope my English is clear enough and that helps some of you > better understand the global picture. Back to my real work. > > Abdel. We could also add it some where in to development/. -- Peter Kümmel
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 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 bug), this is working fine.
| > ..except that metrics is shared between views.
|
| This should not be. Each BufferView now has its own CoordCache. If
| there's still something shared, this should be fixed.
|
|
| > (And this fails miserably when the windows are of different widths.)
|
| The problem is different here. I believe that there's some cursor
| interaction problem that leads. This leads to crashes but most of the
| time, if you have two BufferView sharing the same Buffer, changing the
| geometry of one does not impact the other one (except if there's some
| editing that invalidated the cursor of the other BufferView).
Just try it for yourself and you will see.
As I said, the problem is not related to metrics but to a bad paragraph
model. More exactly this (in paragraph.h):
/// LyXText updates the rows using this access point
RowList & rows() { return rows_; }
/// The painter and others use this
RowList const & rows() const { return rows_; }
This is really, really _wrong_, a paragraph should not have any notion
of rows. By modifying the geometry of the windows (the BufferView) you
also modify the model (the Buffer) because the rows() information is not
valid any more.
rows is a RowList, that is a vector of row:
/**
* Each paragraph is broken up into a number of rows on the screen.
* This is a list of such on-screen rows, ordered from the top row
* downwards.
*/
typedef std::vector RowList;
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.
Abdel.
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 mutlti-view gone. It is the biggest feature I would like to have in 1.5.x. You see, if it does not come with 1.5.0, then it will be too big for 1.5.x and we have to wait till 1.6 ... People who knows lyx-core better please help. Bo
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 disappointed to see mutlti-view gone. It is the biggest feature I would like to have in 1.5.x. You see, if it does not come with 1.5.0, then it will be too big for 1.5.x and we have to wait till 1.6 ... People who knows lyx-core better please help. If this is really wanted there's two solutions: 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 exact same size. Abdel.
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 exact same size. 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. Bo
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
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 would have the exact same size. 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. Here is some explanations that I wrote earlier: 1) The Model: Buffer The Buffer is the in-memory representation of a LyX file format. The Buffer does not (should not) have any information on what part of it is represented on screen. There is one unique Buffer per opened LyX file. 2) The Controller: BufferView/Painter The BufferView is a tool used by the view that translates a part of the Buffer contents into drawing routines. The BufferView asks each inset of the Buffer to draw itself onto the screen using the Painter. There is only Buffer loaded per BufferView. While there is the possibility to switch Buffer inside the BufferView, the goal is to instantiate a new BufferView on each Buffer switch. The Painter is just a virtual interface to formalize each kind of drawing routines (text, line, rectangle, etc). The BufferView also contains a Cursor which may or may not be visible on screen. The cursor is really just a bookmark to remember where the next Buffer insertion/deletion is going to take place. 3) The View: WorkArea (and it's qt4 specialisation GuiWorkArea) This contains the real screen area where the drawing is done by the Painter. One WorkArea holds one unique BufferView. While it could be possible that multiple WorkArea share one BufferView, this is not possible right now. The WorkArea also provide a scrollbar which position is translated into scrolling command to the inner BufferView. The WorkArea use the BufferView to translate each keyboard or mouse events into terms that the Buffer can understand: - insert/delete char - select char - etc. 4) The Window: LyXView (and its qt4 specialisation GuiView) This is a full window containing a menubar, toolbars, a tabbar and a WorkArea. One LyXView could in theory contain multiple WorkArea (ex: with split window) but this number is limited to one only for now. In any case, there would be only one WorkArea that gets the focus at a time. Now, concerning the TabBar versus TabWidget issue. Right now, there is only one WorkArea and the TabBar just used to tell the BufferView inside the WorkArea to switch to this another Buffer. With a TabWidget, each Tab would own its own WorkArea. Clicking on a tab would switch a WorkArea instead of a Buffer. That's all, I hope my English is clear enough and that helps some of you better understand the global picture. Back to my real work. Abdel.
