Re: Let us remove the multi-window support !
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 discussed before. I don't have any problem with your proposal above. OK. I'm only talking about the situation when a user clicks the LyX icon on the desktop or start menu. If LyX is already running, normal behavior for a Windows application is to open a new window in the current process. I pretty mch doubt this can be considered 'normal behaviour'. MS Visual Studio starts another process. Windows Explorer can be configured to use separate processes. The command prompt starts another process. Andre'
Re: Let us remove the multi-window support !
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 discussed before. I don't have > > any problem with your proposal above. > > OK. I'm only talking about the situation when a user clicks the LyX icon > on the desktop or start menu. If LyX is already running, normal behavior > for a Windows application is to open a new window in the current process. I pretty mch doubt this can be considered 'normal behaviour'. MS Visual Studio starts another process. Windows Explorer can be configured to use separate processes. The command prompt starts another process. 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)
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 !
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 do it differently. JMarc
Re: Let us remove the multi-window support !
> "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 do it differently. JMarc
Re: Let us remove the multi-window support !
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 then we need agreement about whether using a single instance | can be the default behavior. Otherwise usability won't improve | compared to 1.4. As already stated. I do not agree with the above statement at all. -- Lgb
Re: Let us remove the multi-window support !
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
Re: Let us remove the multi-window support !
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 worry about the concepts of processes etc. 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. Joost
Re: Let us remove the multi-window support !
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 what Windows users expect. Windows users should not have to worry about the concepts of processes etc. 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. I disagree when you say that in terms of usability 1.4 and 1.5 (such as it is) are equal. Joost -- José Abílio
Re: Let us remove the multi-window support !
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. OK. I'm only talking about the situation when a user clicks the LyX icon on the desktop or start menu. If LyX is already running, normal behavior for a Windows application is to open a new window in the current process. What would be the best way to send a message to another LyX process? Does Qt provide a cross-platform way to send/receive window messages? Joost
Re: Let us remove the multi-window support !
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 then we need agreement about whether using a single instance | can be the default behavior. Otherwise usability won't improve | compared to 1.4. As already stated. I do not agree with the above statement at all. -- Lgb
Re: Let us remove the multi-window support !
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
Re: Let us remove the multi-window support !
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 worry about the concepts of processes etc. 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. Joost
Re: Let us remove the multi-window support !
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 what Windows users > expect. Windows users should not have to worry about the concepts of > processes etc. > > 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. I disagree when you say that in terms of usability 1.4 and 1.5 (such as it is) are equal. > Joost -- José Abílio
Re: Let us remove the multi-window support !
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. OK. I'm only talking about the situation when a user clicks the LyX icon on the desktop or start menu. If LyX is already running, normal behavior for a Windows application is to open a new window in the current process. What would be the best way to send a message to another LyX process? Does Qt provide a cross-platform way to send/receive window messages? Joost
Re: Let us remove the multi-window support !
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 rows() information is not valid any Abdelrazak more. So the rows should be moved to coordcache, right? Abdelrazak Georg is right, the LyX core is not ready for Abdelrazak Multiple-view. There's too much that needs to be Abdelrazak re-designed. So either someone steps up and cleanup that Abdelrazak mess by putting the rows calculation outside of the Buffer Abdelrazak or we disable the multi-windows feature. Disabling multi-window is not very funny, but it might be the best solution indeed. JMarc
Re: Let us remove the multi-window support !
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 Abdelrazak Buffer) because the rows() information is not valid any Abdelrazak more. So the rows should be moved to coordcache, right? Maybe something like that yes. In any case this row information should should be BufferView dependant not Buffer dependant. I think there's not even a need to split up paragraph into rows at the core level. Only the paragraphs that are going to be shown on screen really need to be split up. This job could and should be delegated to the frontend. Abdelrazak Georg is right, the LyX core is not ready for Abdelrazak Multiple-view. There's too much that needs to be Abdelrazak re-designed. So either someone steps up and cleanup that Abdelrazak mess by putting the rows calculation outside of the Buffer Abdelrazak or we disable the multi-windows feature. Disabling multi-window is not very funny, but it might be the best solution indeed. I've hacked a solution to solve the crash in the mean time... dunno if that is enough to keep the feature. Abdel.
Re: Let us remove the multi-window support !
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 Abdelrazak Buffer) because the rows() information is not valid any Abdelrazak more. So the rows should be moved to coordcache, right? Abdelrazak Georg is right, the LyX core is not ready for Abdelrazak Multiple-view. There's too much that needs to be Abdelrazak re-designed. So either someone steps up and cleanup that Abdelrazak mess by putting the rows calculation outside of the Buffer Abdelrazak or we disable the multi-windows feature. Disabling multi-window is not very funny, but it might be the best solution indeed. Well, ability to split the window into a upper and lower part also does the trick - if the requirement for now is that same-width must be maintained. 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. Helge Hafting
Re: Let us remove the multi-window support !
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) you also modify the model (the Abdelrazak Buffer) because the rows() information is not valid any Abdelrazak more. So the rows should be moved to coordcache, right? Abdelrazak Georg is right, the LyX core is not ready for Abdelrazak Multiple-view. There's too much that needs to be Abdelrazak re-designed. So either someone steps up and cleanup that Abdelrazak mess by putting the rows calculation outside of the Buffer Abdelrazak or we disable the multi-windows feature. Disabling multi-window is not very funny, but it might be the best solution indeed. Well, ability to split the window into a upper and lower part also does the trick - if the requirement for now is that same-width must be maintained. This solution requires the multiple work area support which we don't have yet. 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. Yes this last solution would be the best compromise for now as it is relatively easy to implement. Abdel.
Re: Let us remove the multi-window support !
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 maintained. Helge Another idea: When you resize the width of one window, all Helge multiple views are forcibly resized to the same width. This Helge also works around the same-width limitation, and takes away the Helge need to change anything else. If we decide to remove the ability, it is not to spend a lot of time cooking a half baked solution. I'd say that either we decide to make it work, or we drop it. We have many other bugs to work on. JMarc
Re: Let us remove the multi-window support !
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 last solution would be the best compromise for Abdelrazak now as it is relatively easy to implement. So when I resize a window, I will se other windows arbitrarily resized? JMarc
Re: Let us remove the multi-window support !
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 else. Abdelrazak Yes this last solution would be the best compromise for Abdelrazak now as it is relatively easy to implement. So when I resize a window, I will se other windows arbitrarily resized? Hum, this is indeed a usability problem... What about letting it stay like it is now? FYI, what we have now is: 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 maybe not as much as windows resizing by themselves, as the current behaviour will only affect one Buffer. Abdel.
Re: Let us remove the multi-window support !
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 showing, the line breaks in the Abdelrazak second window will be automatically adjusted with the line Abdelrazak breaks of the first window, regardless of the geometry. And what if the text is too large for the window? 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. JMarc
Re: Let us remove the multi-window support !
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 documents simultaneously and paste tables etc. between them. It has always been one or the other. Helge Hafting
Re: Let us remove the multi-window support !
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 would be great! Finally, able to both see two documents simultaneously and paste tables etc. between them. It has always been one or the other. I agree. On Mac, attempting to open an already open file normally switches to that window with a dialog asking if you want to revert to saved. It would be bizarre for Mac users to see the same file in separate windows of the same application. (Splitting a single window into multiple views of the same document is common, of course.) Bennett
Re: Let us remove the multi-window support !
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 instance can be the default behavior. Otherwise usability won't improve compared to 1.4. Joost
Re: Let us remove the multi-window support !
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 some other window is also showing, the line breaks in the Abdelrazak second window will be automatically adjusted with the line Abdelrazak breaks of the first window, regardless of the geometry. And what if the text is too large for the window? Then part of the writings will not the visible in this window. But of course, when you switch back the focus to the second window, the text is automatically adjusted to the correct size. As I said, it is annoying but it still enable to work on the same document in two windows. 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. Fine with me. But let's postpone a bit this decision please. Maybe I (or someone else) will find the time to fix this problem before the second alpha. If not, then we'll make the decision at this point. Abdel.
Re: Let us remove the multi-window support !
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 this point. OK. JMarc
Re: Let us remove the multi-window support !
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 maybe not as much as windows resizing by themselves, as the current behaviour will only affect one Buffer. Personally, I could live with both approaches. They may not be perfect but as long as LyX does no crash they are both a real improvement. Michael
Re: Let us remove the multi-window support !
> "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 rows() information is not valid any Abdelrazak> more. So the rows should be moved to coordcache, right? Abdelrazak> Georg is right, the LyX core is not ready for Abdelrazak> Multiple-view. There's too much that needs to be Abdelrazak> re-designed. So either someone steps up and cleanup that Abdelrazak> mess by putting the rows calculation outside of the Buffer Abdelrazak> or we disable the multi-windows feature. Disabling multi-window is not very funny, but it might be the best solution indeed. JMarc
Re: Let us remove the multi-window support !
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 Abdelrazak> Buffer) because the rows() information is not valid any Abdelrazak> more. So the rows should be moved to coordcache, right? Maybe something like that yes. In any case this row information should should be BufferView dependant not Buffer dependant. I think there's not even a need to split up paragraph into rows at the core level. Only the paragraphs that are going to be shown on screen really need to be split up. This job could and should be delegated to the frontend. Abdelrazak> Georg is right, the LyX core is not ready for Abdelrazak> Multiple-view. There's too much that needs to be Abdelrazak> re-designed. So either someone steps up and cleanup that Abdelrazak> mess by putting the rows calculation outside of the Buffer Abdelrazak> or we disable the multi-windows feature. Disabling multi-window is not very funny, but it might be the best solution indeed. I've hacked a solution to solve the crash in the mean time... dunno if that is enough to keep the feature. Abdel.
Re: Let us remove the multi-window support !
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 Abdelrazak> Buffer) because the rows() information is not valid any Abdelrazak> more. So the rows should be moved to coordcache, right? Abdelrazak> Georg is right, the LyX core is not ready for Abdelrazak> Multiple-view. There's too much that needs to be Abdelrazak> re-designed. So either someone steps up and cleanup that Abdelrazak> mess by putting the rows calculation outside of the Buffer Abdelrazak> or we disable the multi-windows feature. Disabling multi-window is not very funny, but it might be the best solution indeed. Well, ability to split the window into a upper and lower part also does the trick - if the requirement for now is that same-width must be maintained. 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. Helge Hafting
Re: Let us remove the multi-window support !
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) you also modify the model (the Abdelrazak> Buffer) because the rows() information is not valid any Abdelrazak> more. So the rows should be moved to coordcache, right? Abdelrazak> Georg is right, the LyX core is not ready for Abdelrazak> Multiple-view. There's too much that needs to be Abdelrazak> re-designed. So either someone steps up and cleanup that Abdelrazak> mess by putting the rows calculation outside of the Buffer Abdelrazak> or we disable the multi-windows feature. Disabling multi-window is not very funny, but it might be the best solution indeed. Well, ability to split the window into a upper and lower part also does the trick - if the requirement for now is that same-width must be maintained. This solution requires the multiple work area support which we don't have yet. 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. Yes this last solution would be the best compromise for now as it is relatively easy to implement. Abdel.
Re: Let us remove the multi-window support !
> "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 maintained. Helge> Another idea: When you resize the width of one window, all Helge> multiple views are forcibly resized to the same width. This Helge> also works around the same-width limitation, and takes away the Helge> need to change anything else. If we decide to remove the ability, it is not to spend a lot of time cooking a half baked solution. I'd say that either we decide to make it work, or we drop it. We have many other bugs to work on. JMarc
Re: Let us remove the multi-window support !
> "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 last solution would be the best compromise for Abdelrazak> now as it is relatively easy to implement. So when I resize a window, I will se other windows arbitrarily resized? JMarc
Re: Let us remove the multi-window support !
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 else. Abdelrazak> Yes this last solution would be the best compromise for Abdelrazak> now as it is relatively easy to implement. So when I resize a window, I will se other windows arbitrarily resized? Hum, this is indeed a usability problem... What about letting it stay like it is now? FYI, what we have now is: 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 maybe not as much as windows resizing by themselves, as the current behaviour will only affect one Buffer. Abdel.
Re: Let us remove the multi-window support !
> "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 showing, the line breaks in the Abdelrazak> second window will be automatically adjusted with the line Abdelrazak> breaks of the first window, regardless of the geometry. And what if the text is too large for the window? 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. JMarc
Re: Let us remove the multi-window support !
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 documents simultaneously and paste tables etc. between them. It has always been one or the other. Helge Hafting
Re: Let us remove the multi-window support !
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 would be great! Finally, able to both see two documents simultaneously and paste tables etc. between them. It has always been one or the other. I agree. On Mac, attempting to open an already open file normally switches to that window with a dialog asking if you want to revert to saved. It would be bizarre for Mac users to see the same file in separate windows of the same application. (Splitting a single window into multiple views of the same document is common, of course.) Bennett
Re: Let us remove the multi-window support !
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 instance can be the default behavior. Otherwise usability won't improve compared to 1.4. Joost
Re: Let us remove the multi-window support !
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> some other window is also showing, the line breaks in the Abdelrazak> second window will be automatically adjusted with the line Abdelrazak> breaks of the first window, regardless of the geometry. And what if the text is too large for the window? Then part of the writings will not the visible in this window. But of course, when you switch back the focus to the second window, the text is automatically adjusted to the correct size. As I said, it is annoying but it still enable to work on the same document in two windows. 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. Fine with me. But let's postpone a bit this decision please. Maybe I (or someone else) will find the time to fix this problem before the second alpha. If not, then we'll make the decision at this point. Abdel.
Re: Let us remove the multi-window support !
> "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 this point. OK. JMarc
Re: Let us remove the multi-window support !
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 maybe not as much as windows resizing by themselves, as the current behaviour will only affect one Buffer. Personally, I could live with both approaches. They may not be perfect but as long as LyX does no crash they are both a real improvement. 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
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)
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.
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.
