Agreed. Much better that way, since minimize is a much more common and
less disruptive operation.
And since the argument goes that what was once called "close" is now
called "minimize," it follows that the minimize button should be where
the close button was.
- Luke
On Jul 7, 10:47 pm, sir_brizz <bj.car...@gmail.com> wrote:
> Agreed. Much better that way, since minimize is a much more common and
> less disruptive operation.
> And since the argument goes that what was once called "close" is now
> called "minimize," it follows that the minimize button should be where
> the close button was.
> - Luke
> On Jul 7, 10:47 pm, sir_brizz <bj.car...@gmail.com> wrote:
> > Bah, I thought you were moving the X to the left of the buttons :(
> > On Jul 7, 10:05 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
Because I don't want to? Because it's not my habit? Because it's
counterintuitive? Because I'll have to think to remember that clicking
the bug again will minimize, not close, even though clicking the bug
the first time activated Firebug, so even though it mostly *looks*
like clicking again undid the action, it didn't entirely, and I'd have
to look closely and realize the bug isn't grayed out to figure that
out, which I won't do because I have shit to do?
It's not our job to conform our thinking and habits to the design.
- Luke
On Jul 8, 1:37 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> I would like to understand why you don't want to use the status bar
> icon for minimize/unminize.
> jjb
> On Jul 8, 1:24 pm, Luke Maurer <luke.v.mau...@gmail.com> wrote:
> > Agreed. Much better that way, since minimize is a much more common and
> > less disruptive operation.
> > And since the argument goes that what was once called "close" is now
> > called "minimize," it follows that the minimize button should be where
> > the close button was.
> > - Luke
> > On Jul 7, 10:47 pm, sir_brizz <bj.car...@gmail.com> wrote:
> > > Bah, I thought you were moving the X to the left of the buttons :(
> > > On Jul 7, 10:05 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
Maybe it will help to think of the Firebug status bar icon as a "I
want to see Firebug now" / "I don't want to see Firebug now". Lots of
people find this very effective.
jjb
On Jul 8, 1:45 pm, Luke Maurer <luke.v.mau...@gmail.com> wrote:
> Because I don't want to? Because it's not my habit? Because it's
> counterintuitive? Because I'll have to think to remember that clicking
> the bug again will minimize, not close, even though clicking the bug
> the first time activated Firebug, so even though it mostly *looks*
> like clicking again undid the action, it didn't entirely, and I'd have
> to look closely and realize the bug isn't grayed out to figure that
> out, which I won't do because I have shit to do?
> It's not our job to conform our thinking and habits to the design.
> - Luke
> On Jul 8, 1:37 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> > I would like to understand why you don't want to use the status bar
> > icon for minimize/unminize.
> > jjb
> > On Jul 8, 1:24 pm, Luke Maurer <luke.v.mau...@gmail.com> wrote:
> > > Agreed. Much better that way, since minimize is a much more common and
> > > less disruptive operation.
> > > And since the argument goes that what was once called "close" is now
> > > called "minimize," it follows that the minimize button should be where
> > > the close button was.
Ah! But it's much trickier than that nowadays. In 1.3, that was
exactly how it worked. But now, whether you can "see" firebug is
caught up with whether Firebug is monitoring Ajax and such.
You're right, the icon *can* still be used to toggle visibility. But I
don't always use the icon; sometimes I use the [X] because after all
that also means "let me not see this," right? Er, no, not anymore.
(Incidentally, using the status icon to control the window and the
window buttons to control the background tasks is exactly *backward.*)
- Luke
On Jul 8, 1:59 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> Maybe it will help to think of the Firebug status bar icon as a "I
> want to see Firebug now" / "I don't want to see Firebug now". Lots of
> people find this very effective.
> jjb
> On Jul 8, 1:45 pm, Luke Maurer <luke.v.mau...@gmail.com> wrote:
> > Because I don't want to? Because it's not my habit? Because it's
> > counterintuitive? Because I'll have to think to remember that clicking
> > the bug again will minimize, not close, even though clicking the bug
> > the first time activated Firebug, so even though it mostly *looks*
> > like clicking again undid the action, it didn't entirely, and I'd have
> > to look closely and realize the bug isn't grayed out to figure that
> > out, which I won't do because I have shit to do?
> > It's not our job to conform our thinking and habits to the design.
> > - Luke
> > On Jul 8, 1:37 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> > > I would like to understand why you don't want to use the status bar
> > > icon for minimize/unminize.
> > > jjb
> > > On Jul 8, 1:24 pm, Luke Maurer <luke.v.mau...@gmail.com> wrote:
> > > > Agreed. Much better that way, since minimize is a much more common and
> > > > less disruptive operation.
> > > > And since the argument goes that what was once called "close" is now
> > > > called "minimize," it follows that the minimize button should be where
> > > > the close button was.
I don't use the bug because it is farther down to the bottom of the page. I only take the mouse to the status bar when I want to open it. Then the mouse is up in firebug doing stuff, and when I want to minimize, I go to the closest place, which is the top right corner. The bug feels too far out of the way for me. I've used it every now and then to minimize, but it feels like I'm going out of my way to minimize the panel while using the top right corner just feels right.
-----Original Message-----
From: firebug@googlegroups.com [mailto:firebug@googlegroups.com] On Behalf Of johnjbarton
Sent: Wednesday, July 08, 2009 2:59 PM
To: Firebug
Subject: Re: 1.4 Issue Summary Revisited
Maybe it will help to think of the Firebug status bar icon as a "I
want to see Firebug now" / "I don't want to see Firebug now". Lots of
people find this very effective.
jjb
On Jul 8, 1:45 pm, Luke Maurer <luke.v.mau...@gmail.com> wrote:
> Because I don't want to? Because it's not my habit? Because it's
> counterintuitive? Because I'll have to think to remember that clicking
> the bug again will minimize, not close, even though clicking the bug
> the first time activated Firebug, so even though it mostly *looks*
> like clicking again undid the action, it didn't entirely, and I'd have
> to look closely and realize the bug isn't grayed out to figure that
> out, which I won't do because I have shit to do?
> It's not our job to conform our thinking and habits to the design.
> - Luke
> On Jul 8, 1:37 pm, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> > I would like to understand why you don't want to use the status bar
> > icon for minimize/unminize.
> > jjb
> > On Jul 8, 1:24 pm, Luke Maurer <luke.v.mau...@gmail.com> wrote:
> > > Agreed. Much better that way, since minimize is a much more common and
> > > less disruptive operation.
> > > And since the argument goes that what was once called "close" is now
> > > called "minimize," it follows that the minimize button should be where
> > > the close button was.
Neither
Issue 1697: Console stops auto-scrolling
nor
Issue 1724: Firebug no longer keeps the console window scrolled to
the bottom
have test cases.
So, no we can't wait on these.
> Are those not considered blockers for 1.4.0?
Realistically the console scrolling problem could be fixed for 1.4.1
next week....if we had a solid test case for it. (We hope to have
1.4.0 out Friday, Monday for AMO).
jjb
I was pretty bummed about this too, and haunted by flashbacks of other
good software turning sour, notably amarok2, kde4.
It's not hard to fix though, just edit ~/.mozilla/firefox-3.5/
*.default/extensions/fire...@software.joehewitt.com/content/firebug/
firebugOverlay.xul. Look for 'Off'.
On Jul 7, 10:47 pm, sir_brizz <bj.car...@gmail.com> wrote:
On Jul 9, 5:32 pm, Tim Cube <timec...@gmail.com> wrote:
> I was pretty bummed about this too, and haunted by flashbacks of other
> good software turning sour, notably amarok2, kde4.
> It's not hard to fix though, just edit ~/.mozilla/firefox-3.5/
> *.default/extensions/fire...@software.joehewitt.com/content/firebug/
> firebugOverlay.xul. Look for 'Off'.
Just to confirm, the order of the three buttons is solely determined
by the order of the declaration in firebugOverlay.xul and as far as I
know reordering these declarations to create a different order will
not other wise affect Firebug function.
the problems is, if I'm not mistaken, that xul file is in the Firebug
jar and I don't really want to extract that and all just to change the
layout of some buttons.
On Jul 10, 8:55 am, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> On Jul 9, 5:32 pm, Tim Cube <timec...@gmail.com> wrote:
> > I was pretty bummed about this too, and haunted by flashbacks of other
> > good software turning sour, notably amarok2, kde4.
> > It's not hard to fix though, just edit ~/.mozilla/firefox-3.5/
> > *.default/extensions/fire...@software.joehewitt.com/content/firebug/
> > firebugOverlay.xul. Look for 'Off'.
> Just to confirm, the order of the three buttons is solely determined
> by the order of the declaration in firebugOverlay.xul and as far as I
> know reordering these declarations to create a different order will
> not other wise affect Firebug function.
> the problems is, if I'm not mistaken, that xul file is in the Firebug
> jar and I don't really want to extract that and all just to change the
> layout of some buttons.
> On Jul 10, 8:55 am, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> > On Jul 9, 5:32 pm, Tim Cube <timec...@gmail.com> wrote:
> > > I was pretty bummed about this too, and haunted by flashbacks of other
> > > good software turning sour, notably amarok2, kde4.
> > > It's not hard to fix though, just edit ~/.mozilla/firefox-3.5/
> > > *.default/extensions/fire...@software.joehewitt.com/content/firebug/
> > > firebugOverlay.xul. Look for 'Off'.
> > Just to confirm, the order of the three buttons is solely determined
> > by the order of the declaration in firebugOverlay.xul and as far as I
> > know reordering these declarations to create a different order will
> > not other wise affect Firebug function.
Well I have no problem with this. Even if it gets overwritten in the
next updates, I don't really mind having to change one line in an
uncompressed file to get what I want.
On Jul 10, 11:01 am, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> On Jul 10, 9:35 am, sir_brizz <bj.car...@gmail.com> wrote:
> > the problems is, if I'm not mistaken, that xul file is in the Firebug
> > jar and I don't really want to extract that and all just to change the
> > layout of some buttons.
> > On Jul 10, 8:55 am, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> > > On Jul 9, 5:32 pm, Tim Cube <timec...@gmail.com> wrote:
> > > > I was pretty bummed about this too, and haunted by flashbacks of other
> > > > good software turning sour, notably amarok2, kde4.
> > > > It's not hard to fix though, just edit ~/.mozilla/firefox-3.5/
> > > > *.default/extensions/fire...@software.joehewitt.com/content/firebug/
> > > > firebugOverlay.xul. Look for 'Off'.
> > > Just to confirm, the order of the three buttons is solely determined
> > > by the order of the declaration in firebugOverlay.xul and as far as I
> > > know reordering these declarations to create a different order will
> > > not other wise affect Firebug function.
Since 1.4.0b7 I now get this error when developing locally... not sure
what causes it:
nreadystatechange FAILS Error: Permission denied for <http://vm:3000>
to create wrapper for object of class UnnamedClass Error: Permission
denied for <http://vm:3000> to create wrapper for object of class
UnnamedClass [xpconnect wrapped nsIDOMEventListener]
Details:
fileName = "XPCSafeJSObjectWrapper.cpp"
lineNumber = 450
message = "Permission denied for <http://vm:3000> to create wrapper
for object of class UnnamedClass"
name = "Error"
stack = "handleEvent([object Event])@:0\nXPC_SJOW_CallWrapper
(handleEvent,[object Event])@:0\n(XPC_SJOW_CallWrapper,handleEvent,
[object Event])@XPCSafeJSObjectWrapper.cpp:450\n@:0\n"
> Since 1.4.0b7 I now get this error when developing locally... not sure
> what causes it:
> nreadystatechange FAILS Error: Permission denied for <http://vm:3000>
> to create wrapper for object of class UnnamedClass Error: Permission
> denied for <http://vm:3000> to create wrapper for object of class
> UnnamedClass [xpconnect wrapped nsIDOMEventListener]
> Details:
> fileName = "XPCSafeJSObjectWrapper.cpp"
> lineNumber = 450
> message = "Permission denied for <http://vm:3000> to create wrapper
> for object of class UnnamedClass"
> name = "Error"
> stack = "handleEvent([object Event])@:0\nXPC_SJOW_CallWrapper
> (handleEvent,[object Event])@:0\n(XPC_SJOW_CallWrapper,handleEvent,
> [object Event])@XPCSafeJSObjectWrapper.cpp:450\n@:0\n"
On Jul 9, 12:34 am, johnjbarton <johnjbar...@johnjbarton.com> wrote:
> 1307 does not happen for me.
Ok, it's not happening for me now either. Very, very weird. Hopefully
it stays that way :-)
> Neither
> Issue 1697: Console stops auto-scrolling
> nor
> Issue 1724: Firebug no longer keeps the console window scrolled to
> the bottom
> have test cases.
1697 is trivially easy for me to repro. I've added a test case and
some commentary.
