[Project_owners] RE: Project_owners Digest, Vol 19, Issue 36

Ard & Girlie ardlie at dodo.com.au
Mon Jan 31 11:57:33 EST 2005



-----Original Message-----
From: project_owners-bounces at mozdev.org
[mailto:project_owners-bounces at mozdev.org]On Behalf Of
project_owners-request at mozdev.org
Sent: None
To: project_owners at mozdev.org
Subject: Project_owners Digest, Vol 19, Issue 36


Send Project_owners mailing list submissions to
	project_owners at mozdev.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://mozdev.org/mailman/listinfo/project_owners
or, via email, send a message with subject or body 'help' to
	project_owners-request at mozdev.org

You can reach the person managing the list at
	project_owners-owner at mozdev.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Project_owners digest..."


Today's Topics:

   1. Context menu item for animations (Sam Gentle)
   2. Re: Context menu item for animations (Konstantin Svist)
   3. Re: Download troubles (Karel Kolman)
   4. Re: Download troubles (HJ)
   5. Re: How to listen to location changes? (Stan James)
   6. Working with big XML files: memory and persistence	issues.
      (Stan James)
   7. Re: Bugzilla now completely broken (Justin Wood (Callek))
   8. Re: bug or feature? (Justin Wood (Callek))
   9. Re: Working with big XML files: memory and	persistence
      issues. (Justin Wood (Callek))


----------------------------------------------------------------------

Message: 1
Date: Sun, 30 Jan 2005 05:05:10 +1000
From: Sam Gentle <dywypi at gmail.com>
Subject: [Project_owners] Context menu item for animations
To: project_owners at mozdev.org
Message-ID: <41FBDE66.2010303 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

(Apologies if this appears twice, I sent it from the wrong account and
may not have clicked cancel in time. If both appear please only reply to
this one.)

Heya. I've written a short extension to add a "replay animation" image
context menu item, for people who use image.animation_mode=once. At the
moment it appears for a right-click on any image, but if possible I'd
like to have it trigger only for animations.

Is that possible?

Thanks,
Sam

------------------------------

Message: 2
Date: Sat, 29 Jan 2005 10:56:56 -0800
From: Konstantin Svist <fry.kun at gmail.com>
Subject: Re: [Project_owners] Context menu item for animations
To: Mozdev Project Owners List <project_owners at mozdev.org>
Message-ID: <8da27e3405012910563799915c at mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII

Well, an easy way out is: you could always check whether the target
object source ends on a .gif or .mng (that will work in 80-90% of the
time, but would fail for images that are served dynamically)
Another easy thing you could do is look into the headers and extract
the MIME-type.

And yes, not all gifs are animated - but that's why these are easy ways out
;)



On Sun, 30 Jan 2005 05:05:10 +1000, Sam Gentle <dywypi at gmail.com> wrote:
> (Apologies if this appears twice, I sent it from the wrong account and
> may not have clicked cancel in time. If both appear please only reply to
> this one.)
>
> Heya. I've written a short extension to add a "replay animation" image
> context menu item, for people who use image.animation_mode=once. At the
> moment it appears for a right-click on any image, but if possible I'd
> like to have it trigger only for animations.
>
> Is that possible?
>
> Thanks,
> Sam
> _______________________________________________
> Project_owners mailing list
> Project_owners at mozdev.org
> http://mozdev.org/mailman/listinfo/project_owners
>

------------------------------

Message: 3
Date: Sun, 30 Jan 2005 02:22:05 +0100
From: Karel Kolman <kolmis at gmail.com>
Subject: Re: [Project_owners] Download troubles
To: Mozdev Project Owners List <project_owners at mozdev.org>
Message-ID: <d94571000501291722395762ba at mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII

I may be wrong, but isn't the problem that by calling addDownload you
actually aren't creating the download at all, but creating a progress
listener only ?

The following code saves the content specified by sourceURI into a
file specified by targetFile:

--
var obj =
Components.classes['@mozilla.org/embedding/browser/nsWebBrowserPersist;1']
	    .createInstance(Components.interfaces.nsIWebBrowserPersist);
obj.saveURI(sourceURI, null, null, null, null, targetFile);
--

If you want to see the download listed in download manager's list (or
register a different kind of progress listener) do this:

--
var obj =
Components.classes['@mozilla.org/embedding/browser/nsWebBrowserPersist;1']
	    .createInstance(Components.interfaces.nsIWebBrowserPersist);
obj.progressListener = downloadObj;
obj.saveURI(sourceURI, null, null, null, null, targetFile);
--

where you set the progress listener to the object you created in the
download manager by calling addDownload (your code below).

hope this helps,
karel


On Fri, 28 Jan 2005 23:05:21 -0700, HJ <bugus at universum.org> wrote:
> I am using something like this:
>
>    var downloadManager =
>
Components.classes["@mozilla.org/download-manager;1"].getService(Components.
interfaces.nsIDownloadManager);
>    var downloadObj = downloadManager.addDownload(sourceURI, targetURI,
> fileName, mimeInfo, startTime, null);
>    downloadManager.open(window.opener, downloadObj);
>
> I don't see any warning/errors, but nothing happens, there's no progress
> at all. Do I need to fire an event or notify an observer to get
> downloads started?
>
> Thanks for your help,
> /HJ

------------------------------

Message: 4
Date: Sat, 29 Jan 2005 18:01:15 -0700
From: HJ <bugus at universum.org>
Subject: Re: [Project_owners] Download troubles
To: project_owners at mozdev.org
Message-ID: <cthfe0$9de$1 at mozdev.mozdev.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Karel Kolman wrote:
> I may be wrong, but isn't the problem that by calling addDownload you
> actually aren't creating the download at all, but creating a progress
> listener only ?
>
> The following code saves the content specified by sourceURI into a
> file specified by targetFile:
>
> --
> var obj =
Components.classes['@mozilla.org/embedding/browser/nsWebBrowserPersist;1']
> 	    .createInstance(Components.interfaces.nsIWebBrowserPersist);
> obj.saveURI(sourceURI, null, null, null, null, targetFile);
> --
>
> If you want to see the download listed in download manager's list (or
> register a different kind of progress listener) do this:
>
> --
> var obj =
Components.classes['@mozilla.org/embedding/browser/nsWebBrowserPersist;1']
> 	    .createInstance(Components.interfaces.nsIWebBrowserPersist);
> obj.progressListener = downloadObj;
> obj.saveURI(sourceURI, null, null, null, null, targetFile);
> --
>
> where you set the progress listener to the object you created in the
> download manager by calling addDownload (your code below).
>
> hope this helps,
> karel

This is a bit late, but I had to do some shopping. Anyway, I already
solved the problem by looking at the "Save Link Target As..." source
code for Mozilla but thanks anyway,

/HJ

------------------------------

Message: 5
Date: Sat, 29 Jan 2005 10:52:28 +0100
From: Stan James <sjames at uni-osnabrueck.de>
Subject: Re: [Project_owners] How to listen to location changes?
To: Mozdev Project Owners List <project_owners at mozdev.org>
Message-ID: <41FB5CDC.2010807 at uni-osnabrueck.de>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed

Michael Keppler wrote:

> Hi all,
>
> I'm trying to listen to location changes of the browser and
> implemented an nsIWebProgressListener. All seems to be fine (no syntax
> errors etc.) except I don't get notified.
>
>
> var docService = Components.classes["@mozilla.org/docloaderservice;1"].
> getService(Components.interfaces.nsIWebProgress);
>
> docService.addProgressListener(wikipedia,15 | 128);
> //NOTIFY_STATE_ALL | NOTIFY_LOCATION
>
> ...
>
> onLocationChange: function(webProgress , request , location ) {
>     alert(location);
> },
>
> ...
>
>
> Does anybody see an obvious problem with the above code? Or should I
> use a completely different approach to get notified on location changes?
>
> Ciao and thanks, Michael.
> _______________________________________________
> Project_owners mailing list
> Project_owners at mozdev.org
> http://mozdev.org/mailman/listinfo/project_owners
>
>
I'm no pro, but I am successfully detecting location changes with code
that I found in the mozillazine forum:
http://forums.mozillazine.org/viewtopic.php?t=49716
-stan

const NOTIFY_STATE_DOCUMENT =
  Components.interfaces.nsIWebProgress.NOTIFY_STATE_DOCUMENT;
const STATE_IS_DOCUMENT =
  Components.interfaces.nsIWebProgressListener.STATE_IS_DOCUMENT;
const STATE_START =
  Components.interfaces.nsIWebProgressListener.STATE_START;

var myListener =
{
  onStateChange:function(aProgress,aRequest,aFlag,aStatus)
  {
    //dump("statechange");
    if(aFlag & (STATE_IS_DOCUMENT|STATE_START))
    {
      aRequest.QueryInterface(Components.interfaces.nsIChannel);
      gCurrentURL = aRequest.URI.spec; /* url is now in gCurrentURL */
    }
  },
  onLocationChange:function(a,b,c){
        //dump("locationchange");
        if (c.spec != gCurrentURL)
        {
            gCurrentURL = c.spec;  /* url is now in gCurrentURL */
        }
  },
  onProgressChange:function(a,b,c,d,e,f){},
  onStatusChange:function(a,b,c,d){},
  onSecurityChange:function(a,b,c){},

  /*XXX
    This is not nsIWebProgressListenr method,
    just killing a error in tabbrowser.xml
    Maybe a bug.
  */
  onLinkIconAvailable:function(a){}
}

.
.
.

      window.getBrowser().addProgressListener(myListener ,
NOTIFY_STATE_DOCUMENT);

------------------------------

Message: 6
Date: Sat, 29 Jan 2005 11:09:52 +0100
From: Stan James <sjames at uni-osnabrueck.de>
Subject: [Project_owners] Working with big XML files: memory and
	persistence	issues.
To: Mozdev Project Owners List <project_owners at mozdev.org>
Message-ID: <41FB60F0.6010902 at uni-osnabrueck.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi all,

My FF extension keeps a [potentially] big XML file loaded in memory,
which it needs to access quite often. Right now it works fine with a
~300K file, but I'd like to handle bigger files. (~2megs, but bigger is
better)  Haven't dared to try yet...

How can I keep this data quickly accessible to my extension in all
windows, without each window needing to keep it's own copy? (Right now I
always have a "designated window."  And if it gets closed then the next
window will re-load/parse the file.)

On a side note, is there any way to find out how much memory a structure
is actually using? I have no idea how much overhead there is for
internal XML trees. (Looking at all those properties in the DOM
inspector, I feel there might be a lot!)

Any better ideas on keeping a big store of data quickly accessible?
Anybody else shoving around big XML structures? Thanks for any tips!

-stan

------------------------------

Message: 7
Date: Sat, 29 Jan 2005 12:11:06 -0500
From: "Justin Wood (Callek)"
	<116057-nospam at bacon.NoSpamPlease.qcc.mass.edu>
Subject: Re: [Project_owners] Bugzilla now completely broken
To: project_owners at mozdev.org
Message-ID: <ctgg9q$1gb7$1 at mozdev.mozdev.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Chris Neale wrote:
> On Wednesday 26 January 2005 21:24, Justin Wood (Callek) wrote:
>
>>Chris Neale wrote:
>>
>>>: ]
>>
>>It seems the Server Push Technology with b.md.o is borked, Causing
>>Stylesheet's to not be applied correctly :(
>>
>>Well, Lets hope its fixed.
>>
>
>
> It's nothing to do with that, Pete's upgraded bz to 2.18, and we haven't
> changed any templates yet.
>

Well it _was_ a problem with the server push stuff, now it is back to
normal.  I understand that the templates are not updated, thank you. ;-)

~Justin Wood

------------------------------

Message: 8
Date: Sat, 29 Jan 2005 12:12:31 -0500
From: "Justin Wood (Callek)"
	<116057-nospam at bacon.NoSpamPlease.qcc.mass.edu>
Subject: Re: [Project_owners] bug or feature?
To: project_owners at mozdev.org
Message-ID: <ctggcf$1gb7$2 at mozdev.mozdev.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Matthew Wilson wrote:
> Konstantin Svist wrote:
>
>> Not quite sure if this is the right mailing list for this question but
>> what the heck...
>>
>> I'm trying to convert BGSOUND tag into an EMBED tag (so pages with
>> BGSOUND will make sound in firefox). I've just found out that when
>> encountered with an unknown tag like BGSOUND, Firefox moves it into
>> the head section of HTML.
>>
>> for example this:
>> <html>
>>  <head></head>
>>  <body>
>>   <bgsound src='./canyon.mid'>
>>  </body>
>> </html>
>>
>> becomes this (see live HTML via javascript calls or using the
>> "Generated Source" bookmarklet):
>
>
> (or with DOM Inspector)
>
>> <html>
>>  <head>
>>   <bgsound src='./canyon.mid'>
>>  </head>
>>  <body>
>>  </body>
>> </html>
>>
>>
>> Because of this, replaceChild() doesn't work in my case (embed is not
>> played if located in HEAD section).
>> Is this a bug or is it expected behavior of the browser?
>
>
> Probably occurs as a side-effect of the fact that BGSOUND is not a
> standard HTML element.
>
> Matthew
>

<EMBED> will work in IE6 at the least, and Opera etc.  use replaceChild
if you are in IE, to turn it into bgsound rather than the other way
around, let your page validate

~Justin Wood

------------------------------

Message: 9
Date: Sun, 30 Jan 2005 00:55:43 -0500
From: "Justin Wood (Callek)"
	<116057-nospam at bacon.NoSpamPlease.qcc.mass.edu>
Subject: Re: [Project_owners] Working with big XML files: memory and
	persistence issues.
To: project_owners at mozdev.org
Message-ID: <ctht3l$upm$1 at mozdev.mozdev.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Stan James wrote:
> Hi all,
>
> My FF extension keeps a [potentially] big XML file loaded in memory,
> which it needs to access quite often. Right now it works fine with a
> ~300K file, but I'd like to handle bigger files. (~2megs, but bigger is
> better)  Haven't dared to try yet...
>
> How can I keep this data quickly accessible to my extension in all
> windows, without each window needing to keep it's own copy? (Right now I
> always have a "designated window."  And if it gets closed then the next
> window will re-load/parse the file.)
>
> On a side note, is there any way to find out how much memory a structure
> is actually using? I have no idea how much overhead there is for
> internal XML trees. (Looking at all those properties in the DOM
> inspector, I feel there might be a lot!)
>
> Any better ideas on keeping a big store of data quickly accessible?
> Anybody else shoving around big XML structures? Thanks for any tips!
>
> -stan

The data required for an XML structure as I understand it is not so much
reliant on size of the .xml(ish) file, but more on the number of nodes
included in the document tree.

(Keep in mind I am a relatively un-informed person here).  And the
textual information included is much less memory heavy than other parts.

Due to an XML file needing to be well-formed the entire file must be
parsed to be used unfortunately (as I understand it again).  Good luck
in your endeavors here.

One possibility you may do, is have an object read the file once, and
store pointers (C++) to locations in the file for quick access, and
treat it as a somewhat less-than-XML file...(depending on the needs of
your interface).  This could speed up and reduce the memory required to
use your data.

Again, take my commentary on this somewhat near how you would treat a
5-year old talking about the theory of relativity (or even string theory).

~Justin Wood (Callek)

------------------------------

_______________________________________________
Project_owners mailing list
Project_owners at mozdev.org
http://mozdev.org/mailman/listinfo/project_owners


End of Project_owners Digest, Vol 19, Issue 36
**********************************************



--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.2 - Release Date: 28/01/2005




More information about the Project_owners mailing list