I'm just unsure what clarity was actually lost in the 1.3 model. If you had enabled Firebug for a domain, then it was on on that domain. You could have expanded this by introducing the bug lit/unlit design you have for 1.4 now to show whether Firebug was active on the page or not. Who cares what the panel is doing? If you want to know if Firebug is on, just look at the bug. (As a sidenote, I have no clue about the panel being detached as my screen space doesn't allow for that to be done well, but it seems to me that, like Safari 4, this could have just been done on the active page in Firefox)
As before, I realize the current model makes some sense, I just don't see it as a worthwhile change over what we had. As someone who heavily prefers the 1.2 design to this day, I would much prefer just being able to have firebug either always on or always off and then have domain settings for the opposite action to occur. I realize all of this isn't going to go anywhere, the core development team is happy with the activation model regardless of what any individual person wants, so nothing is likely to change as far as how the model is functionally. So roping this all back in to what can actually happen for the current design, the X is confusing in "On for all pages" mode. I understand that it isn't doing the blacklisting of the domain, though that might be a nice feature, but, in my opinion, the state of the panel itself (showing or hidden) should stay static across all pages when the option is set. On another note, I don't really get the "Off for all pages" option. Is that for debugging? Or does it change your per-domain settings in some way? Because unchecking "On for all pages" should just revert to your original settings. The thing I dislike most about 1.4 is that Activation is linked sooooo tightly to the panel displaying. It doesn't feel like these things are separate at all anymore, so it feels like it is "Panel showing, Firebug active. Panel not showing, Firebug inactive" (despite the fact that that is not quite how it works) and I hate that to extreme levels. On Jul 2, 6:26 pm, johnjbarton <[email protected]> wrote: > The question here isn't what should happen when you go to a new tab. > The "on for all pages" means Firebug should be on. > > The question is what should the [X] do when "On for all pages " is > true. > > Probably it should be disabled. After all the UI promised "on for all > pages", not "on for all but ones you click the [X]" Does that make > sense? > > I think the clarity of the 1.3 model is partly because most people > actually did not understand it. If you set the panels enabled once and > focused on the site controls, then you probably were lucky. Else not: > the 1.3 model coupled the panel activation, site activation, and > placement (detached, minimized, in browser) So if you start changing > these other settings you can get mixed up pretty quick. > > The 1.4 model is much clearer. The activation, placement, and panel > enablement are all separate. If you notice in all of these > discussions we did not once get into panel enable/disable. That was a > huge issue in 1.3. The placement part of the UI (the [_] [-][X] > controls) was added later in the design and we have less feedback on > them. I do not think we have all of the UI for these prefect by any > means, but its also just not that bad. > > jjb > > On Jul 2, 5:00 pm, sir_brizz <[email protected]> wrote: > > > Perhaps. > > > 1) Are you suggesting that Firebug should keep a blacklist of disabled > > sites when "On for all sites" is checked? Currently it doesn't, I > > believe that is the correct behavior. > > > 2) In the case where "On for all pages" is checked, the meaning of > > "Close" and "Minimize" blurs almost entirely. Close could just mean > > "get out of my way" as much as minimize could. > > > Anyway, I believe the appropriate behavior should be that the panel is > > up on the following page only if it was up on the page previous. If > > the panel is not showing for any reason on the originating page, it > > should not pop up on the resulting page, either. This is certainly one > > of those cases I was talking about before when I said that "How should > > [some process] function?" question is way too easy to bring up with > > the new activation model. In 1.3, or with an even more flexible > > whitelist/blacklist model, there would simply be no question what > > should happen in this case. > > > On Jul 2, 5:54 pm, johnjbarton <[email protected]> wrote: > > > > On Jul 2, 3:07 pm, sir_brizz <[email protected]> wrote: > > > ... > > > > > You're right, this is the correct use-case: > > > > > 1) Right click Firebug, check "On for all pages". > > > > 2) CLOSE Firebug (with the 'x'). > > > > That would be "Deactivate FIrebug for this page" ;-) > > > > > 3) Open a new tab > > > > -- Firebug panel pops open instead of staying minimized. > > > > It wasn't minimized so it won't stay minimized. It was deactivated on > > > a page, then the tab obeys "On for all pages". > > > > jjb --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Firebug" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/firebug?hl=en -~----------~----~----~----~------~----~------~--~---
