A few changes.

[Phil Norman]

Hi.

I've pushed a few changes to Evergreen that, IMO, are bug fixes. But I wanted to check, in case someone disagrees.

1: (this one's really a bug fix). Fixed a NPE triggered when changing the font settings while at least one PTextArea was open in a non-current workspace.

2: Made the 'Find in Files' dialog stop focus from reverting to the PTextArea which had focus when the dialog was opened, in the case that the user has used FiF to open a different PTA. Now it works consistently with "Open Quickly".

3: I've changed the 'build' action so it will reuse an already-open ErrorsWindow which was running the same command, rather than always opening a new one each time you hit ctrl-B. I think this is a reasonable trade-off between spamming with an unbounded number of windows, and the old old behaviour where only one errors window was reused for everything.

I've also added the ability to change the log output to a specific file (set EVERGREEN_LOG_FILENAME), which makes debugging way quicker.

I think that's pretty much all for this weekend though.

Cheers,

Phil

[Martin Dorey]

Does a reused Errors window pop to the top of the window stack?  I don't think it does, leading me to think that "oh, the errors window disappeared again, I must have fixed the bug" and hence check-in code that doesn't compile for the second time in the last hour.  There's a FIXME in ShellCommand.java that appears to have been invalidated by this change and a couple of commented-out lines that seems to fix the problem I'm reporting here:

        // This causes ugly flickering if the window's already on the top of the stack, but it fixes the problem on small screens where your main window covers your build window and you don't remember/want to close the build window before you start editing.

        // As usual, we can't use toFront because the GNOME morons (okay, well-intentioned fascists, but aren't fascists always well-intentioned in their own minds?) broke it for us, and Sun hasn't worked around the breakage.

        // I don't know of any way to test whether we're already on top.

        // FIXME: this isn't relevant at the moment, because each build gets a new EErrorsWindow.

        //errorsWindow.setVisible(false);

        if (outputDisposition == ToolOutputDisposition.ERRORS_WINDOW) {

            // We might get fewer useless windows if we don't display them until they've something to say.

            //errorsWindow.setVisible(true);

        }

So I should delete the FIXME too and commit that, right?

--
You received this message because you are subscribed to the Google Groups "evergreen-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to evergreen-use...@googlegroups.com.
To post to this group, send email to evergre...@googlegroups.com.
Visit this group at https://groups.google.com/group/evergreen-users.
For more options, visit https://groups.google.com/d/optout.

[Phil Norman]

Hmm... yes, the FIXME look inaccurate now. I agree getting the errors window to the top when a rerun is requested is a good thing. Not sure if what you're suggesting is right though; I'm not really in a position to test right now. Try it and see?

Cheers,

Phil

To unsubscribe from this group and stop receiving emails from it, send an email to evergreen-users+unsubscribe@googlegroups.com.
To post to this group, send email to evergreen-users@googlegroups.com.

Visit this group at https://groups.google.com/group/evergreen-users.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "evergreen-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to evergreen-users+unsubscribe@googlegroups.com.
To post to this group, send email to evergreen-users@googlegroups.com.

[Martin Dorey]

I did and it seemed to fix it, as I did try to say, though it came out somewhat ungrammatically.  Will commit mañana...

To unsubscribe from this group and stop receiving emails from it, send an email to evergreen-use...@googlegroups.com.
To post to this group, send email to evergre...@googlegroups.com.

Visit this group at https://groups.google.com/group/evergreen-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "evergreen-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to evergreen-use...@googlegroups.com.
To post to this group, send email to evergre...@googlegroups.com.

Visit this group at https://groups.google.com/group/evergreen-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "evergreen-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to evergreen-use...@googlegroups.com.
To post to this group, send email to evergre...@googlegroups.com.

[Elliott Hughes]

(i don't use C-B at work, but this had been annoying me at home. much
better now!)

Elliott Hughes - http://www.jessies.org/~enh/

[Elliott Hughes]

well, except now i've finally installed scm.deb. now the big empty errors window when i start them is annoying. pushed another tweak that i think addresses both sides' issues. the only time it's annoying now is when you submit in checkintool and the errors window appears because it suddenly has something to say (that you actually don't care about).

the fix for that seems like it's either (a) run those classes directly in Evergreen's existing VM (removing the 2s startup delay too) or (b) make SCM stick its logs somewhere else like Evergreen/Terminator do...

[Martin Dorey]

I see your extra change includes:

+            // TODO: do we need to keep track of whether we've started a new build/whatever and only toFront if it's our first time through here since then?

Yes, yes we do.  If I have, say, revisiontool start Firefox to show me a bug database entry (because I can't get Chrome to work against :1, which doesn't have hardware accelerated graphics, without crashing gnome-shell and I haven't been able to get VNC to work against :0 since Gnome3 in Jessie), then any attempt to select text in Firefox causes this sort of thing to be vomited into the errors window:

(firefox-esr:17750): GLib-GObject-WARNING **: /build/glib2.0-y6934K/glib2.0-2.42.1/./gobject/gsignal.c:3410: signal name 'selection_changed' is invalid for instance '0x7fb8b2988420' of type 'MaiAtkType919'

(firefox-esr:17750): GLib-GObject-WARNING **: /build/glib2.0-y6934K/glib2.0-2.42.1/./gobject/gsignal.c:3410: signal name 'selection_changed' is invalid for instance '0x7fb8b2988420' of type 'MaiAtkType919'

(firefox-esr:17750): GLib-GObject-WARNING **: /build/glib2.0-y6934K/glib2.0-2.42.1/./gobject/gsignal.c:3410: signal name 'selection_changed' is invalid for instance '0x7fb8b2988420' of type 'MaiAtkType919'

(firefox-esr:17750): GLib-GObject-WARNING **: /build/glib2.0-y6934K/glib2.0-2.42.1/./gobject/gsignal.c:3410: signal name 'selection_changed' is invalid for instance '0x7fb8b2988420' of type 'MaiAtkType919'

... which then pops to the front, having an unfortunate effect on the selection that I was trying to make.

I thought just the second part of this would be enough, but it didn't have any effect that I noticed until I reverted your removal of the first condition too:

--- a/evergreen/src/e/edit/EErrorsWindow.java

+++ b/evergreen/src/e/edit/EErrorsWindow.java

@@ -269,11 +269,15 @@ public class EErrorsWindow extends JFrame {

         

         public void run() {

             // You always want the errors window visible if there are errors.

-            setVisible(true);

+            // This conditional stops the errors window from grabbing the focus every time it's updated.

+            if (isVisible() == false) {

+                setVisible(true);

+            }

             

-            // And you probably want it on top, so it's visible to a human.

-            // TODO: do we need to keep track of whether we've started a new build/whatever and only toFront if it's our first time through here since then?

-            toFront();

+            // And you want to let the user know that their job produced output.

+            if (textArea.getLineCount() == 0) {

+                toFront();

+            }

             

             textArea.append(text);

             if (isStdErr) {

The first bit on its own isn't enough either.

[Elliott Hughes]

yeah, that seems reasonable to me. no point keeping track of our own boolean if we can just check the line count. (ctrl-B clears the errors window, so this doesn't regress on your previous problem of not bringing the window to the front if the previous build failed.)

[Elliott Hughes]

(since you don't seem to be around and i've been hitting this myself [trying to use a terminal to do something else during a long slow build] i'll go ahead and submit this for you...)

[Elliott Hughes]

checkintool itself is still a bit annoying, but i think we might be fixing the wrong problem there --- i think checkintool should just behave more like evergreen/terminator and keep its logging to itself. (with the possible exception of the "i'm actually doing stuff" lines... but certainly as a user i don't care if it took 111ms to start ispell(1) or any other random logging like that.)

[Martin Dorey]

(Ta.  I am ~around but the code's at work and I had the fix already, so it didn't seem urgent.)