DOM inspector needed in trunk
JoeS
https://bugzilla.mozilla.org/show_bug.cgi?id=271812 Domi not shipped in trunk. This does not work in trunk TB
Now for the Deja Vu part:
https://bugzilla.mozilla.org/show_bug.cgi?id=254031
Rather than figuring out why the current extension does not work, why not just ship it as part of the build,
at least for now.
--
JoeS
Tony Mechelynck
DOM Inspector is very useful to "some" people, such as extension developers
and people savvy enough to use and modify <profile>/chrome/user*.css
In my humble opinion:
a) it would be nice bordering on necessary to keep shipping DOMi with Firefox
nightly builds (including "branch" nightlies), and to start shipping it with
Thunderbirds nightly builds (here too, also "branch" nightlies). Shipping it
with "release" builds would be nice too but maybe less necessary.
b) for builds shipped without DOMi, an appropriate, compatible DOMi extension
(or several, for different builds, if necessary), available at AMO, would be
an absolute necessity.
Note: There is already a DOMi extension for Thunderbird at AMO; it works (or
did, last time I tried) with Tb2 (release 2.0.0.* and "latest-mozilla1.8"
nightlies), I don't know about Tb3 (and trunk).
Best regards,
Tony.
--
"I generally avoid temptation unless I can't resist it."
-- Mae West
Robert Kaiser
> Firefox is getting ready to strip out Dom inspector, and make it an
> extension only.
Sorry for being blunt, but the primary Firefox target audience doe not
have a clue what DOMi even is for.
If you want a browser that comes prepackaged with DOMi, maybe even
venkman, and where you can even inspect mail UI with DOMi, you can
always grab SeaMonkey :P
Robert Kaiser
Sailfish
> JoeS wrote:
>> Firefox is getting ready to strip out Dom inspector, and make it an
>> extension only.
>
> Sorry for being blunt, but the primary Firefox target audience doe not
> have a clue what DOMi even is for.
>
does have lots of clues about add-ons (extensions and themes) and would
be very much less enthusiastic about staying with the product if, for
the savings of a few bits, the vast extensions/themes store became
depleted because 3rd party developers no longer have an essential tool
in which to migrate and/or develop the next great add-on.
> If you want a browser that comes prepackaged with DOMi, maybe even
> venkman, and where you can even inspect mail UI with DOMi, you can
> always grab SeaMonkey :P
>
No disagreement there ... dropping DOMi from Fx/Tb could be a real boon
to SeaMonkey :-)
--
Sailfish - Netscape/Mozilla Champion
Netscape/Mozilla Tips: http://www.ufaq.org/ , http://ilias.ca/
Rare Mozilla Stuff: http://www.projectit.com/
Dan Mosedale
> DOM Inspector is very useful to "some" people, such as extension
> developers and people savvy enough to use and modify
> <profile>/chrome/user*.css
>
> In my humble opinion:
>
> a) it would be nice bordering on necessary to keep shipping DOMi with
> Firefox nightly builds (including "branch" nightlies), and to start
> shipping it with Thunderbirds nightly builds (here too, also "branch"
> nightlies). Shipping it with "release" builds would be nice too but
> maybe less necessary.
Shipping it with end-user release builds feels wrong to me. Most users
aren't going to use it, so we shouldn't accept the download size hit or
the confusion created by a menu item that many users won't be able to
decipher.
Nightlies (and even alpha/beta release builds) might be different, since
they're aimed at people who are likely to be doing testing.
I'm not sure about the trunk/branch tradeoff here, though.
> b) for builds shipped without DOMi, an appropriate, compatible DOMi
> extension (or several, for different builds, if necessary), available at
> AMO, would be an absolute necessity.
I agree that this sounds very desirable, though I might not go so far as
to say "absolute necessity".
Dan
Mark Banner
> Now for the Deja Vu part:
> https://bugzilla.mozilla.org/show_bug.cgi?id=254031
> Rather than figuring out why the current extension does not work, why
> not just ship it as part of the build,
> at least for now.
I'm looking at this now. For one thing, TB is missing shipping a core
file on Windows, which explains one problem. I'm still building, so I'll
post more when I know what's happening.
Standard8
Mark Banner
> I'm looking at this now. For one thing, TB is missing shipping a core
> file on Windows, which explains one problem. I'm still building, so I'll
> post more when I know what's happening.
Missing file will be shipped with tomorrow's nightly and thereafter,
please test with DOMI (soon to be available from amo:
https://addons.mozilla.org/en-US/seamonkey/addon/6622), and report back
if it works or doesn't.
Thanks
Standard8
Ron K.
I would be happy to have DOMi as an extension available at AMO like it
is for Tb2. It has been a great tool for tweaking Chrome and the Themes
when adjustments to visuals are important for users with Asseability
needs. I and others have found DOMi very useful while doing Tb U-2-U
support in mozilla.support.thunderbird. As more people grab the alpha
builds the pressure for support is increasing and the depth of support
is not keeping pace.
--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
JoeS
Worked fine as I commented in the bug.
Thanks again Mark.
--
JoeS
JoeS
> Tony Mechelynck wrote:
>> DOM Inspector is very useful to "some" people, such as extension
>> developers and people savvy enough to use and modify
>> <profile>/chrome/user*.css
>>
>> In my humble opinion:
>>
>> a) it would be nice bordering on necessary to keep shipping DOMi with
>> Firefox nightly builds (including "branch" nightlies), and to start
>> shipping it with Thunderbirds nightly builds (here too, also "branch"
>> nightlies). Shipping it with "release" builds would be nice too but
>> maybe less necessary.
>
> Shipping it with end-user release builds feels wrong to me. Most users
> aren't going to use it, so we shouldn't accept the download size hit or
> the confusion created by a menu item that many users won't be able to
> decipher.
It probably would cause some confusion.
On the other hand although I can't claim any in-depth knowledge, what I have learned, started out of curiosity
about what Dom inspector actually was. That opportunity was created when Domi was a standard part of the build.
JoeS
> Nightlies (and even alpha/beta release builds) might be different, since
> they're aimed at people who are likely to be doing testing.
>
> I'm not sure about the trunk/branch tradeoff here, though.
Given that someone who uses the nightlies is probably a potential tester/contributor at least provide a link
to the newly function addon (thanks to Mark Banner) The start page could be used to encourage participation
and testing. But that's kinda buried. There used to be a full html page when TB first started, maybe that could
be used again. (I haven't seen that for a long time, maybe it's because I use zip builds)
SeaMonkey's "start page" is an excellent example.
JoeS
Tony Mechelynck
> JoeS wrote:
>> Firefox is getting ready to strip out Dom inspector, and make it an
>> extension only.
>
> Sorry for being blunt, but the primary Firefox target audience doe not
> have a clue what DOMi even is for.
Well, maybe you're underestimating the Firefox (and _Thunderbird_ since that
is what this group is about) user, and overestimating your own SeaMonkey user,
but even if you aren't, there will always be some Fx/Tb users which will have
a use, what am I saying? a _need_ for it, and among these I'll most definitely
count all Fx/Tb theme writers, most Fx/Tb extension writers, and even a few
above-average users.
>
> If you want a browser that comes prepackaged with DOMi, maybe even
> venkman, and where you can even inspect mail UI with DOMi, you can
> always grab SeaMonkey :P
>
> Robert Kaiser
Oh, I did. But I'm finding out that I've started using SeaMonkey and Firefox
in not exactly interchangeable ways, so that I need both (and even Konqueror
and Lynx) for somewhat different purposes.
Best regards,
Tony.
--
In Greene, New York, it is illegal to eat peanuts and walk backwards on
the sidewalks when a concert is on.
Robert Kaiser
> Robert Kaiser wrote:
>> JoeS wrote:
>>> Firefox is getting ready to strip out Dom inspector, and make it an
>>> extension only.
>>
>> Sorry for being blunt, but the primary Firefox target audience doe not
>> have a clue what DOMi even is for.
>
> Well, maybe you're underestimating the Firefox (and _Thunderbird_ since
> that is what this group is about) user, and overestimating your own
> SeaMonkey user, but even if you aren't, there will always be some Fx/Tb
> users which will have a use, what am I saying? a _need_ for it, and
> among these I'll most definitely count all Fx/Tb theme writers, most
> Fx/Tb extension writers, and even a few above-average users.
Surely there are people among the Firefox users who want it, but those
can get it from AMO - the vast majority of FF users are more confused
than helped by that extension, and the others should know how to find
AMO (or be able to find DOMi in the new "Get Add-Ons" section of the
Add-Ons window). Same for Thunderbird, which is the target audience of
this newsgroup.
Robert Kaiser
Mark Banner
> It probably would cause some confusion.
> On the other hand although I can't claim any in-depth knowledge, what I
> have learned, started out of curiosity
> about what Dom inspector actually was. That opportunity was created when
> Domi was a standard part of the build.
I think what's coming out here and in other parts of this thread is that
we really need to promote DOMI in appropriate places so that a) users
who are likely to want it know of it and can find it and b) Developers
can also be pointed in the right direction.
How/where we do this I'm not sure of yet.
Standard8
Mark Banner
> Tested with an hourly, and the sandbox version.
> Worked fine as I commented in the bug.
Excellent, thanks for testing.
> Thanks again Mark.
No problem, it was especially helpful that FF actually had the same
missing file as well, hence point me in the right direction ;-)
Standard8
David Ascher
which can be different for nightlies, specific alphas, betas, &
releases, and which can give important pointers to either information
for testers & developers, or for end-users.
-david
Ron K.
> Dan Mosedale wrote:
>> Tony Mechelynck wrote:
>>> DOM Inspector is very useful to "some" people, such as extension
>>> developers and people savvy enough to use and modify
>>> <profile>/chrome/user*.css
>>>
>>> In my humble opinion:
>>>
>>> a) it would be nice bordering on necessary to keep shipping DOMi with
>>> Firefox nightly builds (including "branch" nightlies), and to start
>>> shipping it with Thunderbirds nightly builds (here too, also "branch"
>>> nightlies). Shipping it with "release" builds would be nice too but
>>> maybe less necessary.
>>
>> Shipping it with end-user release builds feels wrong to me. Most
>> users aren't going to use it, so we shouldn't accept the download
>> size hit or the confusion created by a menu item that many users
>> won't be able to decipher.
>
> It probably would cause some confusion.
> On the other hand although I can't claim any in-depth knowledge, what
> I have learned, started out of curiosity
> about what Dom inspector actually was. That opportunity was created
> when Domi was a standard part of the build.
>
> JoeS
My experience with DOMi is similar. Yes it was intimidating at first,
but as I began to see it giving access to the CSS information of the
Chrome I invested in learning the tool.
Ron K.
>
>> Nightlies (and even alpha/beta release builds) might be different,
>> since they're aimed at people who are likely to be doing testing.
>>
>> I'm not sure about the trunk/branch tradeoff here, though.
>
> Given that someone who uses the nightlies is probably a potential
> tester/contributor at least provide a link
> to the newly function addon (thanks to Mark Banner) The start page
> could be used to encourage participation
> and testing. But that's kinda buried. There used to be a full html
> page when TB first started, maybe that could
> be used again. (I haven't seen that for a long time, maybe it's
> because I use zip builds)
> SeaMonkey's "start page" is an excellent example.
>
> JoeS
>
Tb releases still have a "Start Page" but it is now a remote link, not a
link into one of the Tb local files. I don't like either method,
preferring to see a local HTML file in the programs root folder, or
placed within the default theme. With Tb 1.x I skinned the start page
to coordinate with the Sky Pilot theme.
Ron K.
Yes, I like this line of thought. These are the related preferences
which have the needed variables to point a build to remote pages based
on Local and Version ID. This will require coordinated webmastering
support. Can Gary support this plan with the other MoMess items also on
his plate?
browser.startup.homepage =
chrome://navigator-region/locale/region.properties
mailnews.start_page.override_url =
http://%LOCALE%.www.mozilla.com/%LOCALE%/%APP%/%VERSION%/start/
mailnews.start_page.url =
http://%LOCALE%.www.mozilla.com/%LOCALE%/%APP%/%VERSION%/start/
mailnews.start_page.welcome_url =
http://%LOCALE%.www.mozilla.com/%LOCALE%/%APP%/%VERSION%/start/
I believe one of these is currently used as an install confirmation
message, however that page could include links to things like a list of
Add-on items confirmed as useable with an Alpha or Beta.