Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2010-04

New feature - View same source in multiple Windows

36 messages · 7 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Martin

You can now spread the open units across multiply Windows (Context-Menu "Move to new Window"). This allows to view to open files next to each other.

You can also view (and edit) the same source across 2 or more windows (Context-Menu "Move to new Window"). So you can look at different locations in the same file, without the need of jumping forward and backward.

Once a 2nd Window is open, you can drag and drop tabs (ctrl drag for copy).

Note: as before, closing a SourceEditor window (X-button in title bar) will hide it. => the tabs in it stay open. Use the "View" or "window" menu to show it again

Martin

Reply by email

Hans-Peter Diettrich
to Martin
You can now spread the open units across multiply Windows (Context-Menu "Move to new Window"). This allows to view to open files next to each other.

Great :-)

DoDi

Reply by email

Alexander Klenin
to Martin: You can now spread the open units across multiply Windows (Context-Menu "Move to new…
Martin wrote
You can also view (and edit) the same source across 2 or more windows (Context-Menu "Move to new Window"). So you can look at different locations in the same file, without the need of jumping forward and backward.

Works good (it is, of course, "Copy to new Window"). How about "Copy to new tab"? would be handy in some cases.

Alexander S. Klenin

Reply by email

Martin
to Alexander Klenin
Alexander Klenin wrote 9 lines
On Thu, Apr 8, 2010 at 05:41, Martin wrote: > You can also view (and edit) the same source across 2 or more windows > (Context-Menu "Move to new Window"). So you can look at different locations > in the same file, without the need of jumping forward and backward. > Works good (it is, of course, "Copy to new Window"). How about "Copy to new tab"? would be handy in some cases

you mean having 2 tabs with the same source, in just one window? It can be added, but I though it wasn't needed (since you can only view one of them at any time)

From discussions it has emerged, that splitting the space within one tab (so you have 2 editors or 2 views in the same tab) would be desirable... someday...

---
if you want to enable tabs in the same window

SourceEditor.pp line 4905 onwards
(and find similar checks in TSourceDraggableNotebook)

     {$IFnDEF SingleSrcWindow}
     SrcEditMenuMoveToOtherWindowList.Clear;
     NBAvail := False;
     for i := 0 to Manager.SourceWindowCount - 1 do
       if (i  Manager.IndexOfSourceWindow(self)) and

(Manager.SourceWindows[i].IndexOfEditorInShareWith(GetActiveSE) < 0) then begin

         NBAvail := True;
         with RegisterIDEMenuCommand(SrcEditMenuMoveToOtherWindowList,
                                     'MoveToWindow'+IntToStr(i),
                                     Manager.SourceWindows[i].Caption,
@SrcEditMenuMoveToExistingWindowClicked)
         do
           Tag := i;
       end;
     SrcEditMenuMoveToNewWindow.Visible := not NBAvail;
     SrcEditMenuMoveToNewWindow.Enabled := PageCount > 1;
     SrcEditMenuMoveToOtherWindow.Visible := NBAvail;
     SrcEditMenuMoveToOtherWindowNew.Enabled := (PageCount > 1);
     NBAvail := False;
     SrcEditMenuCopyToOtherWindowList.Clear;
     for i := 0 to Manager.SourceWindowCount - 1 do
// XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
// remove the if below / always registerIDEMenuCommand / and Always
NBAvail := true.
// XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
       if
(Manager.SourceWindows[i].IndexOfEditorInShareWith(GetActiveSE) < 0) and
          (i  Manager.IndexOfSourceWindow(self))
       then begin
         NBAvail := True;
         with RegisterIDEMenuCommand(SrcEditMenuCopyToOtherWindowList,
                                     'CopyToWindow'+IntToStr(i),
                                     Manager.SourceWindows[i].Caption,
@SrcEditMenuCopyToExistingWindowClicked)
         do
           Tag := i;
       end;
     SrcEditMenuCopyToNewWindow.Visible := not NBAvail;
     SrcEditMenuCopyToOtherWindow.Visible := NBAvail;
     {$ENDIF}

Reply by email

David W Noon
to Martin

On Thu, 08 Apr 2010 15:41:09 +0100, Martin wrote about Re: [Lazarus] New feature - View same source in multiple Windows:

Show quoted text 14 lines
On 08/04/2010 15:33, Alexander Klenin wrote: > On Thu, Apr 8, 2010 at 05:41, Martin wrote: > >> You can also view (and edit) the same source across 2 or more >> windows (Context-Menu "Move to new Window"). So you can look at >> different locations in the same file, without the need of jumping >> forward and backward. > Works good (it is, of course, "Copy to new Window"). > How about "Copy to new tab"? would be handy in some cases > you mean having 2 tabs with the same source, in just one window? It can be added, but I though it wasn't needed (since you can only view one of them at any time)

This also raises the question as to whether both tabs should be updated when the users modifies the source, or if one tab should be kept as history. If the latter, there would need to be a "synchronize" option to bring the history up to date when the user no longer needs the older version.

Having two or more potential sources of modification for a single file poses all kinds of issues about consistency, unless they are intrinsically synchronized internally.

Regards, Dave [RLU #314465] ======================================================================= (David W Noon) =======================================================================

Reply by email

Martin
to David W Noon
David W Noon wrote 14 lines
> you mean having 2 tabs with the same source, in just one window? > It can be added, but I though it wasn't needed (since you can only > view one of them at any time) > This also raises the question as to whether both tabs should be updated when the users modifies the source, or if one tab should be kept as history. If the latter, there would need to be a "synchronize" option to bring the history up to date when the user no longer needs the older version. Having two or more potential sources of modification for a single file poses all kinds of issues about consistency, unless they are intrinsically synchronized internally.

There is only one document internally => So both tabs are updated synchronously.

Type in one, and you will see the changes happen in both. Make changes in one, go to the other, and press undo => it will undo the changes you made in the other tab => since the changes where made to the document, and since both editors share the same document.

If anyone wants to keep a "history", that is what (IMHO) backups are for. save to a backup file, and open the backup file.

Best Regards
Martin

Reply by email

Hans-Peter Diettrich
to Martin: You can now spread the open units across multiply Windows (Context-Menu "Move to new…
Show quoted text 6 lines
You can also view (and edit) the same source across 2 or more windows (Context-Menu "Move to new Window"). So you can look at different locations in the same file, without the need of jumping forward and backward. Once a 2nd Window is open, you can drag and drop tabs (ctrl drag for copy).

"Copy" seems not to work on Linux, right now?

DoDi

Reply by email

Martin
to Hans-Peter Diettrich
Hans-Peter Diettrich wrote 11 lines
Martin schrieb: > You can also view (and edit) the same source across 2 or more windows > (Context-Menu "Move to new Window"). So you can look at different > locations in the same file, without the need of jumping forward and > backward. > > Once a 2nd Window is open, you can drag and drop tabs (ctrl drag for > copy). "Copy" seems not to work on Linux, right now?

It works here:
- Ubuntu 9 with GTK2
- Gtk2 on Vista

Martin

Reply by email

Hans-Peter Diettrich
to David W Noon: On Thu, 08 Apr 2010 15:41:09 +0100, Martin wrote about Re: [Lazarus] New feature - View…
Show quoted text 11 lines
>> How about "Copy to new tab"? would be handy in some cases >> > you mean having 2 tabs with the same source, in just one window? > It can be added, but I though it wasn't needed (since you can only > view one of them at any time) This also raises the question as to whether both tabs should be updated when the users modifies the source, or if one tab should be kept as history. If the latter, there would need to be a "synchronize" option to bring the history up to date when the user no longer needs the older version.

IMO real backup files should be used for that purpose, distinct from the current versions in the editor pages and windows.

Having two or more potential sources of modification for a single file poses all kinds of issues about consistency, unless they are intrinsically synchronized internally.

A single internal copy of the file can be updated from multiple sources, and changes can be signaled to all SynEdits of the same file. This already should have been realized in the current implementation, I assume.

DoDi

Reply by email

Martin
to Hans-Peter Diettrich
Hans-Peter Diettrich wrote 11 lines
David W Noon schrieb: > Having two or more potential sources of modification for a single file > poses all kinds of issues about consistency, unless they are > intrinsically synchronized internally. A single internal copy of the file can be updated from multiple sources, and changes can be signaled to all SynEdits of the same file. This already should have been realized in the current implementation, I assume. DoDi

It is.

Reply by email

Michael Schnell
to Martin: You can now spread the open units across multiply Windows (Context-Menu "Move to new…
Martin wrote
You can now spread the open units across multiply Windows (Context-Menu "Move to new Window").

I suppose the cursor position can be different with the several instances of the same file. sounds good. (Might be feasible with multiple tabs for the same file, as well, which I i9n fact did see by accident with an svn version a week or so ago, but I supposed it to be a bug).

Which of the multiple instances is to get the focus and a new cursor position when a break point is hit ?

BTW.: I found that I can reorder the tabs in the code explorer. Great !

-Michael

Reply by email

Michael Schnell
to Martin: You can now spread the open units across multiply Windows (Context-Menu "Move to new…
Martin wrote
You can now spread the open units across multiply Windows (Context-Menu "Move to new Window").

I suppose the cursor position can be different with the several instances of the same file. sounds good. (Might be feasible with multiple tabs for the same file, as well, which I i9n fact did see by accident with an svn version a week or so ago, but I supposed it to be a bug).

Which of the multiple instances is to get the focus and a new cursor position when a break point is hit ?

-Michael

Reply by email

Michael Van Canneyt
to Michael Schnell
Michael Schnell wrote 12 lines
On 04/07/2010 08:41 PM, Martin wrote: > You can now spread the open units across multiply Windows > (Context-Menu "Move to new Window"). I suppose the cursor position can be different with the several instances of the same file. sounds good. (Might be feasible with multiple tabs for the same file, as well, which I i9n fact did see by accident with an svn version a week or so ago, but I supposed it to be a bug). Which of the multiple instances is to get the focus and a new cursor position when a break point is hit ?

That seems easy enough:

The top one, if it shows the source file.
Otherwise the last created instance ?

Michael.

Reply by email

Michael Schnell
to Michael Van Canneyt
Michael Van Canneyt wrote
The top one, if it shows the source file. Otherwise the last created instance ?

Sound nice. I asked because (with some older version) sometimes a new tab was created with the file already displayed in another tab. Seems top be fixed with a later version.

-Michael

Reply by email

Martin
to Michael Schnell: It does not work here either: Suse 11.1- -Michael
Michael Schnell wrote 7 lines
On 04/08/2010 07:18 PM, Hans-Peter Diettrich wrote: > "Copy" seems not to work on Linux, right now? > > It does not work here either: Suse 11.1-

GTK2 or QT?

Does it work, if you "MOVE" another tab to a new window before (open a new window this way first), and then copy a tab (or drag?)

How does it manifest exactly?
Does the Window Open.
does the tab show (empty or with something?)? Title of tab? ....

Martin

Reply by email

Martin
to Michael Schnell: I suppose the cursor position can be different with the several instances of the same…
Michael Schnell wrote 14 lines
On 04/07/2010 08:41 PM, Martin wrote: > You can now spread the open units across multiply Windows > (Context-Menu "Move to new Window"). > I suppose the cursor position can be different with the several instances of the same file. sounds good. (Might be feasible with multiple tabs for the same file, as well, which I i9n fact did see by accident with an svn version a week or so ago, but I supposed it to be a bug). Which of the multiple instances is to get the focus and a new cursor position when a break point is hit ?

For each tab (of all tabs of a unique source code), the order of which one was last focused/active is remembered.

For breakpoint, bookmarks, history jumps,
Find-in-file-result-list/msg-window clicks the last active one is used (maybe later options will be add, so you could stick with the current window...)

e.g for msg-window, or find in fles result => you focus the desired tab, and then choose the result.

Onlty exception "goto prev/next bookmark" looks for the tab that is closest located according to the search order (forward/back). (excluding the current source other tabs)
{ } indocate a window (win1 and win2)

{ unit1 unit2 unit3 } {unit2 unit1}

each unit has a bookmark,

W1U1 is active / the order forward will be :
w1-u1
w1-u2
w1-u3
w2-u2 (it's the next tab with a bookmark)
w2-u1
w1-u2 (w1 u1 would have been next, but it will not go ti itself)

Reply by email

Martin
to Michael Van Canneyt: That seems easy enough: The top one, if it shows the source file. Otherwise the last…
Michael Van Canneyt wrote 21 lines
On Fri, 9 Apr 2010, Michael Schnell wrote: > On 04/07/2010 08:41 PM, Martin wrote: >> You can now spread the open units across multiply Windows >> (Context-Menu "Move to new Window"). > > I suppose the cursor position can be different with the several > instances of the same file. sounds good. (Might be feasible with > multiple tabs for the same file, as well, which I i9n fact did see by > accident with an svn version a week or so ago, but I supposed it to be a > bug). > > Which of the multiple instances is to get the focus and a new cursor > position when a break point is hit ? That seems easy enough: The top one, if it shows the source file. Otherwise the last created instance ?

last focused

Reply by email

Martin
to Michael Schnell: Sound nice. I asked because (with some older version) sometimes a new tab was created…
Michael Schnell wrote 9 lines
On 04/09/2010 09:22 AM, Michael Van Canneyt wrote: > The top one, if it shows the source file. Otherwise the last created > instance ? > Sound nice. I asked because (with some older version) sometimes a new tab was created with the file already displayed in another tab. Seems top be fixed with a later version.

That must have been, when you still had to compile with -dSyndualView ? yes a bug like this existed.

Reply by email

Martin
to Hans-Peter Diettrich: Here not: Ubuntu 9 with gtk2 Suse 10 with gtk2 The menu entry is not present, and…
Hans-Peter Diettrich wrote 16 lines
Martin schrieb: >> "Copy" seems not to work on Linux, right now? > > It works here: > - Ubuntu 9 with GTK2 > - Gtk2 on Vista Here not: Ubuntu 9 with gtk2 Suse 10 with gtk2 The menu entry is not present, and Ctrl-drag does nothing. Does it depend on some $Define (SynDualView, OldAutoSize...)?

The menu entry for "move to other window" does exist? Can you open a 2nd window wiht move? and then try to ctrl-drag?

Tt used to be -dSynDualView => but I removed the IfDef about 3 or 4 days back.
There is -dSingleSrcWindow which you must NOT use => it prevents the feature (both Move and Copy)

Delete all *.ppu and *.o and recompile?

Martin

Reply by email

Hans-Peter Diettrich
to Martin: For each tab (of all tabs of a unique source code), the order of which one was last…
For breakpoint, bookmarks, history jumps, Find-in-file-result-list/msg-window clicks the last active one is used (maybe later options will be add, so you could stick with the current window...)

What about Code Explorer? Delphi allows for multiple explorers, docked to the editor windows. Something like this should come in a future version, with a dockable IDE.

DoDi

Reply by email

Michael Schnell
to Martin: GTK2 or QT? Does it work, if you "MOVE" another tab to a new window before (open a new…
Martin wrote
GTK2 or QT?

KDE 4

Show quoted text 7 lines
Does it work, if you "MOVE" another tab to a new window before (open a new window this way first), and then copy a tab (or drag?) How does it manifest exactly? Does the Window Open. does the tab show (empty or with something?)? Title of tab?

I intermediately upgraded to the most recent svn version and now it works (I seem to remember that it worked exactly like "move" (like not pressing ctrl).

-Michael

Reply by email

Hans-Peter Diettrich
to Martin: The menu entry for "move to other window" does exist? Can you open a 2nd window wiht…
The menu entry for "move to other window" does exist?

Yes, only "copy..." is missing.

Can you open a 2nd window wiht move?

Yes

and then try to ctrl-drag?

Acts the same as only drag, the page is moved.

BTW, the DragCursor never changes into "accept" state.

Tt used to be -dSynDualView => but I removed the IfDef about 3 or 4 days back. There is -dSingleSrcWindow which you must NOT use => it prevents the feature (both Move and Copy)

I just tried with all -d removed - no change.

Delete all *.ppu and *.o and recompile?

Didn't help.

If you could tell me where the menu entries are created or shown?

DoDi

Reply by email

Andrew Brunner
to Martin: You can now spread the open units across multiply Windows (Context-Menu "Move to new…

Before I complain I want to say THANKS for this feature. It helps me greatly. But in using it in the following way it leads me to the following problem...

Example: Two source windows with the same unit.
Source (1) scrolled down to implementation (for entering source) and Source (2) window scrolled to the top for the declarations and types (just viewing).
When I am "fleshing out" the framework of my objects / data structures in Source (1) I don't want Source (2) to scroll at all when the page is synchronized. The current system is scrolling to see what has been changed - disregarding my explicit will for Source (2) to stay on the top of the document.

One purpose for the second window is to see what types / classes are defined so I can implement methods correctly. Fleshing out these objects is getting cumbersome b/c I have to keep scrolling up to see them every time the page updates.

Thanks again! Love the work. Let me know when I can grab an updated version from SVN.

Reply by email

Martin
to Andrew Brunner
Andrew Brunner wrote 14 lines
Before I complain I want to say THANKS for this feature. It helps me greatly. But in using it in the following way it leads me to the following problem... Example: Two source windows with the same unit. Source (1) scrolled down to implementation (for entering source) and Source (2) window scrolled to the top for the declarations and types (just viewing). When I am "fleshing out" the framework of my objects / data structures in Source (1) I don't want Source (2) to scroll at all when the page is synchronized. The current system is scrolling to see what has been changed - disregarding my explicit will for Source (2) to stay on the top of the document.

Source 2 is on the top (above source 1), so it shouldn't scroll anyway?

Indeed it did happen the other way round. if text was edited, above the viewed section, scrolling took place (annoyingly) That was fixed yesterday: Revision: 24519 Date: 17:45, 08 April 2010

If it still happens, I need a better description, as it does not happen here.

Martin

Reply by email

Martin
to Andrew Brunner: Before I complain I want to say THANKS for this feature. It helps me greatly. But in…
Andrew Brunner wrote 14 lines
Before I complain I want to say THANKS for this feature. It helps me greatly. But in using it in the following way it leads me to the following problem... Example: Two source windows with the same unit. Source (1) scrolled down to implementation (for entering source) and Source (2) window scrolled to the top for the declarations and types (just viewing). When I am "fleshing out" the framework of my objects / data structures in Source (1) I don't want Source (2) to scroll at all when the page is synchronized. The current system is scrolling to see what has been changed - disregarding my explicit will for Source (2) to stay on the top of the document.

Do you have any settings, like cursor always visible?

Reply by email

Martin
to Martin: Source 2 is on the top (above source 1), so it shouldn't scroll anyway? Indeed it did…
Martin wrote
Indeed it did happen the other way round. if text was edited, above the viewed section, scrolling took place (annoyingly) That was fixed yesterday: Revision: 24519 Date: 17:45, 08 April 2010

You may ensure you upgrade to version 24538 (just checked in)

There was a bug, introduced in 24519 => causing selection to become persistent, and the caret to jump around

Martin

Reply by email

Andrew Brunner
to Andrew Brunner: First thing I did this morning was svn update and make clean all. I'm rebuilding Lazarus…
Andrew Brunner wrote 7 lines
> Indeed it did happen the other way round. if text was edited, above the > viewed section, ?scrolling took place (annoyingly) > That was fixed yesterday: Revision: 24519 Date: 17:45, 08 April 2010 First thing I did this morning was svn update and make clean all. ?I'm rebuilding Lazarus now. Let's see if Rev 24537 works w/o scrolling.

Fixed with rebuild... LOL. Preemptive feature development. LOL.

Reply by email

Martin
to Andrew Brunner
Andrew Brunner wrote 13 lines
On Fri, Apr 9, 2010 at 11:04 AM, Andrew Brunner wrote: >> Indeed it did happen the other way round. if text was edited, above the >> viewed section, scrolling took place (annoyingly) >> That was fixed yesterday: Revision: 24519 Date: 17:45, 08 April 2010 >> > First thing I did this morning was svn update and make clean all. I'm > rebuilding Lazarus now. Let's see if Rev 24537 works w/o scrolling. > > Fixed with rebuild... LOL. Preemptive feature development. LOL.

Please see my other mail => you need to update once more

Reply by email

Martin
to Martin: You may ensure you upgrade to version 24538 (just checked in) There was a bug, introduced…
Martin wrote 10 lines
On 09/04/2010 16:37, Martin wrote: > > Indeed it did happen the other way round. if text was edited, above > the viewed section, scrolling took place (annoyingly) > That was fixed yesterday: Revision: 24519 Date: 17:45, 08 April 2010 You may ensure you upgrade to version 24538 (just checked in) There was a bug, introduced in 24519 => causing selection to become persistent, and the caret to jump around

Sorry make that 24539 (24538 made it worse).

Martin

Reply by email