VW8.0.1

I started to use VW8.0.1 yesterday, and I've noticed a few items (many
of which aren't in older 7.X images):

*) In the browser, Ctrl-B claims to be for Debug it, Insert Breakpoint,
and Remove Breakpoint -- pick one.

*) VW still doesn't have good support for multiple monitors (at least on
Windows). First, if you have monitors of different heights, it may open
a window where the title bar is displayed off the screen making it
difficult to move or close the window. Second, if you have a monitor
with negative coordinates, it will not open a window on that display --
you can move the window there though.

*) In the past you could specify a menu's indication by having an
indicationSelector method that returned a symbol. If that symbol was the
ID of the menu item, then it would be checked. If it wasn't, the check
wouldn't be displayed. Someone has changed the MenuItem>>indication:
method so this no longer works. Was this done on purpose? I didn't see
anything in the release notes that talks about the change. With the
change, the symbol returned by the indicationSelector method becomes the
new indicationSelector.

*) Find/replace is somewhat broken. The Ctrl-F find operation should use
the selected text for the initial find. If find is already displayed,
Ctrl-F should set the focus to the field input field. I can't read the
selected found item (white on yellow is unreadable -- I assume it is
yellow -- I'm colorblind). Sometimes find gets into a state where it
can't find the text even though it is there. Many times replace doesn't
show the replace input field (or sometimes the arrows are displayed on
top of the replace input field). Finally, sometimes the method's context
menu doesn't display while find is being displayed and I have to
explicitly left click inside the method before it will display.

*) The warnings displayed in a method are too in your face. I think they
should be displayed more like comments are displayed in word processors
or displayed at the side of the code like is done in most other IDEs.
Also, when you start editing they get removed so your text shifts
causing you to refocus to a different location.

*) On my retina display Mac laptop, the store connection dialog is
barely usable. The displayed cursor position in the environment field is
not displayed in the correct location and when you edit the field the
displayed contents start overprinting. You can't see where you are going
to insert (or delete) a character. I have to make a change and tab out
of the field to see the real contents.

*) If you have a buffer/view on a really large method (e.g., one that
has been generated), the arrow keys become really slow (even if you are
currently in a very small method). For each arrow key, it generates the
menus to see if anyone handles the arrow key. In the process of
generating the View submenu, it checks if any of the buffers have
modified their contents (to display the "*" besides the menu item). To
see if the source has changed requires getting the
#documentWithoutBreakpoints which does a Text2.Document>>copy. This is
slow for large methods.

*) If you start extract to temporary refactoring, it opens "Enter name
forTemporary:"(sp) dialog. Now, if you cancel this dialog, it tries to
perform the refactoring anyway so you get an error dialog " is not a
valid instance variable name". Also, if you select a message selector
and do an extract to temporary refactoring, you get a "Cannot assign to
non-value nodes" error that didn't occur previously. Finally, if you
select some part of a literal array and do extract to temporary, it
breaks the method (the variable name becomes a symbol in the literal
array). I think this one has existed for 20 years...


John Brant
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi John,

The multiple-monitor positioning problems are at least as far back as VW 7.5 too. I use five monitors of three display dimensions, with three in portrait mode. The five monitors are connected to two ATI video cards, and one card is rather old. If windows reopen and entirely avoid a monitor then sequence your monitors in the same order as Windows reports for each video card (order of all displays can be mixed between different video cards though). Avoid having the same video card use monitors with a different top coordinate. With those tricks, I very rarely have window titles above the display. Those tricks worked for others here too. It is hard to say if those are ATI driver problems, Windows problems, or VW problems. It seems code somewhere presumes the top-most position of a card would be the same for all monitors connected to the card, and so the window opens positioned above the shorter monitor on that card. Before I discovered those tricks I was using this program very !
 often from a taskbar shortcut:

http://www.taenarum.com/software/Borderline.html

It will be nice to reduce the monitor count when more 4K-capable video cards become available.

Paul Baumann


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of John Brant
Sent: Wednesday, June 24, 2015 11:34
To: [hidden email]
Subject: [vwnc] VW8.0.1

I started to use VW8.0.1 yesterday, and I've noticed a few items (many of which aren't in older 7.X images):

...

*) VW still doesn't have good support for multiple monitors (at least on Windows). First, if you have monitors of different heights, it may open a window where the title bar is displayed off the screen making it difficult to move or close the window. Second, if you have a monitor with negative coordinates, it will not open a window on that display -- you can move the window there though.

...


John Brant
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

________________________________

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I have a single video card with three displays:
        Screen default instVarNamed: 'subRegions'
        #(1920 @ -720 corner: 3120 @ 1200 0 @ 0 corner: 1920 @ 1200 -1600 @ 0
corner: 0 @ 1200)

I have them physically aligned at the bottom so that's how I also told
Windows to manage them. The opening with the title bar off screen is
solely a VW problem (I've had it with 3 different computer/video cards
combinations). It started occurring when the code was added to try to
pick a good location to open the browser -- I don't remember what VW
release that was added in.

Looking at the code, it appears that it may be caused by the
UIBuilder>>openSavedPosition:type:name:. That method tries to get the
#savedPositionInCurrentScreen:for: and the #lastSavedSize:for: and then
passes this to the #openIn:withType: method which eventually makes sure
the rectangle is inside a display by using the
Screen>>makeRectangleVisible: method. The
#savedPositionInCurrentScreen:for: method takes into account the
"ScheduledWindow windowTopLeftHeadroom" so the rectangle passed to
#openIn:withType: is valid to display the title bar. However, if the
extent of the rectangle (returned by #lastSavedSize:for:) is too large
for the display, then Screen>>makeRectangleVisible: moves it to have
origin y = 0.

You can see the problem by evaluating something like this:

        ((RefactoringBrowser savedWindowInformation at: #windowSpec) at:
#savedSize) y: 1600

and then opening a browser. If your display is less than 1600 pixels
tall, then you likely be missing the title bar. If you change
ScheduledWindow>>openIn: you can get the title bar:

        newBounds := Screen default makeRectangleVisible: aRectangle.
->
        newBounds := aRectangle.


BTW, when I was looking at the code, I did have some browsers open on
the screen with the negative x coordinate (-1600 @ 0 corner: 0 @ 1200)
so the second issue I listed below isn't valid.


John Brant


On 6/24/2015 11:34 AM, Paul Baumann wrote:
> Hi John,
>
> The multiple-monitor positioning problems are at least as far back as VW 7.5 too. I use five monitors of three display dimensions, with three in portrait mode. The five monitors are connected to two ATI video cards, and one card is rather old. If windows reopen and entirely avoid a monitor then sequence your monitors in the same order as Windows reports for each video card (order of all displays can be mixed between different video cards though). Avoid having the same video card use monitors with a different top coordinate. With those tricks, I very rarely have window titles above the display. Those tricks worked for others here too. It is hard to say if those are ATI driver problems, Windows problems, or VW problems. It seems code somewhere presumes the top-most position of a card would be the same for all monitors connected to the card, and so the window opens positioned above the shorter monitor on that card. Before I discovered those tricks I was using this program ver!
 y often
from a taskbar shortcut:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc