IRC Log Viewer » #firebreath » 2010-10-20

IRC Nick Time (GMT-7) Message
chucksplatt 08:10 Hey everyone. Looking for some help on using Firebreath to create a plug-in that just renders a file based on its mime-type.
Something that behaves like a document viewer, a la Acrobat.
amackera 08:10 what sorts of documents? pdfs, docs, txts, that kind of thing?
chucksplatt 08:10 Yeah. We're actually looking to render a file format of our own. I just haven't been able to figure out a way to make a plug-in that just grabs a file stream from the browser when invoked by accessing a file, vs. being embedded on a page.
amackera 09:10 taxilian_away really is the guy to talk to, but you'll have to wait until he's back to get a proper answer
as far as i understand a plugin *must* be embedded on a page, somewhere
i wonder how the reader plugin does it then
you'll have to wait until taxilian_away comes back :P
chucksplatt 09:10 THe NPAPI docs indicate that a plugin can render in "full page" mode, which is what thos doc rendering plug ins do.
amackera 09:10 ah, i see
chucksplatt 09:10 The browser creates the stream there, but I can only find stuff in firebreath where the plugin creates the stream, so it would have to know ahead of time what the URL of the file being accesses is, or somehow get that information without it being a parameter.
amackera 09:10 can you point me to the docs you're reading about the full page mode?
brb
chucksplatt 09:10 https://developer.mozilla.org/en/Gecko_Plugin_API_Reference/Plug-in_Basics#Plug-in%20Display%20Modes
I don't think that target works, you'll have to scroll about halfway down the page.
amackera 09:10 sorry about that, internet is flakey at the new office :P
taxilian 09:10 chucksplatt: yeah, so I've actually wondered about that for awhile; however, I have never actually needed to do it, so I don't know
amackera 09:10 the gecko reference isn't very helpful either
taxilian 09:10 that's normal
the gecko reference is usually only useful for helping you explain what you already know
not for learning it in the first place
amackera: any chance I could get you to write up some doxygen docs for the mac pluginwindows?
amackera 09:10 yeah sure no problem
taxilian 09:10 that would be awesome =]
amackera 09:10 i'll take a look at your docs and emulate the style
taxilian 09:10 probably easiest
chucksplatt 09:10 Hm, okay. I am a n00b to the plugin world. What references do you guys recommend?
taxilian 09:10 chuckpoint: give me a few minutes, I'm doing some reading
might be able to tell you something
chucksplatt 09:10 Also, it sounds like firebreath as it is doesn't really make a provision for that kind of a plugin.
taxilian 09:10 chucksplatt: not currently, but there is always 1.4
amackera 09:10 taxilian: what's the best way for me to merge my windowless changes to dev? just merge and push? or would you like to inspect the changesets in the clone first?
or in a fresh clone, since my existing one is all mashed with dev
taxilian 09:10 amackera: at this point, go ahead and put it in dev
dev and stable are the same right now
amackera 09:10 alright
taxilian 09:10 until you push, anyway =]
dev is the 1.4 branch
stable is 1.3 rc1
chucksplatt: FireBreath *might* actually work for full page plugins already
from what I'm reading, the main thing is that your plugin must handle the mimetype of the file you want it to load
then when the browser encounters the mimetype in question on a file, it should open the plugin
I'm not sure how that'll work on IE, though...
hmm
yeah, that'll probably take some doing
http://devedge-temp.mozilla.org/library/manuals/2002/plugin/1.0/intro.html is a good resource and says a little bit about them in npapi
chucksplatt 09:10 The part I'm trying to figure out is how to get a hold of the file stream. It looks like with NPAPI the browser calls NPP_NewStream, and the plugin can set the stream mode (cached or not, etc)
Then you can call NPP_StreamAsFile to get the file
taxilian 09:10 yeah; FireBreath has BrowserStream that could probably be tweaked for that
chucksplatt 09:10 In firebreath, I only see examples where you create the stream in the plugin, needing to know the URL of the file beforehand
Or otherwise grabbing it from the parameters, if it were embedded
taxilian 09:10 yeah; I suspect you can probably tweak those to handle unexpected streams as well
but as is it doesn't handle that, AFAIK
hmm. and I really don't have any idea how to do something like this in IE
chucksplatt 09:10 Ok, well. Good to know, at least.
taxilian 10:10 yeah
sorry I can't help more
amackera 10:10 taxilian: okay i just want to make sure i'm doing it right
i've pulled changesets from dev.firebreath.googlecode.com/hg/
then merged them with my local changesets
then committed
taxilian 10:10 sounds right
amackera 10:10 now i just need to push to https://dev.firebreath.googlecode.com/hg/ and it should push my merged-with-dev working copy to the dev.firebreath clone, righ?
taxilian 10:10 correct
amackera 10:10 hehe, okay good
amackera 10:10 How should periods be used in doxygen?
taxilian 10:10 not sure I understand the question?
amackera 10:10 for instance:
@brief Mac OS X Cocoa specific implementation of PluginWindow.
or
@brief Mac OS X Cocoa specific implementation of PluginWindow
taxilian 10:10 I think I usually leave them off
amackera 10:10 ok
is the doxygen stuff generated from the stable repo?
taxilian 10:10 no, it's generated from dev
amackera 10:10 taxilian: what shell do you use in windows? just the regular command prompt?
taxilian 10:10 usually cygwin
with console2
I also use:
alias wpwd='cygpath -w -a .'
function open() { TMPPARAM="$1" WINDIR=`cygpath -w -a -s "$TMPPARAM"`; cmd /c start $WINDIR; }
as helpers
wpwd then gives you the current windows path (when you're in bash and normally get the cygwin path)
and open can be used to open a folder or a file
amackera 10:10 i see, very nice
amackera 10:10 brb
NeilG 11:10 Hey
So, about CMake... ;)
I'd like FB to use a specific version of Boost in a specific directory
I can change the path in paths.cmake but making it look at a relative path below the CMake dir seems to cause problems (in that it doesn't find the directory) and so prep2008.cmd fails
taxilian 12:10 NeilG: welcome back =] don't change paths.cmake
to use system boost libraries, see http://firebreath.org/display/documentation/Prep+Scripts#PrepScripts-ExternalBoost
you probably also need -DWITH_SYSTEM_BOOST, I'm guessing
NeilG 12:10 Yup, that's not going to do what I want unfortunately
Each of our projects is a complete sandbox - they could have wildly different versions of Boost. I need to point it at that particular version. I'd already tried -DWITH_SYSTEM_BOOST which finds 1.40 in my Program Files - but that's simply the first version it finds (and definitely isn't the one I want to use which is 1.44)
I'm just looking through the CMake files now adding a new define so I can point it at the right directory. It seems like the path of least resistance!
taxilian 12:10 NeilG: did you read the part about "External Boost" where it tells you you can use -DBOOST_ROOT?
(I haven't tried it; if you have and it didn't work I apologize, but that's what I was pointing you to)
NeilG 12:10 Yes. It appeared to completely ignore that option and just find the one in Program Files anyway - although now I've moved the files around so that boost is inside the CMAKE root dir it may actually work
I haven't tried that since that change, let me go see... :)
taxilian 12:10 well, good luck. I have to go take a test now
amackera: there is a build error from your windowless stuff
undefined symbol
NeilG 12:10 Good luck with your test!
That doesn't work but I'm seeing the same behaviour that I've had before with CMake - it's not picking up changes
taxilian 12:10 we really need it to not need that symbol unless a config option has been set to indicate that windowless plugins are supported if possible
NeilG: Well, generally it's not considered a good idea to use lots of different versions of boost; usually you just want one, so that's not really a feature I've played with much =]
so good luck
NeilG 12:10 Despite getting rid of the WITH_SYSTEM_BOOST define (or even in conjuction) it still points at Program Files
taxilian 12:10 hmm
dunno
bbl
NeilG 12:10 That's the problem - FireBreath is using one version of Boost and I'm using another
Anyway, good luck!
taxilian 12:10 right; solution? make everything use 1.44 and it'll all be good :-P
thx
NeilG 12:10 :P
NeilG 13:10 So yes, I was hit by the CMake bug I've seen before - it doesn't notice changes. Deleting the entire build folder and regenerating it got me a lot further! Now it finds the correct boost headers from the sandbox. But it finds the libs in Program Files still. Doh! At least I have an idea why now...
amackera 13:10 taxilian_away: i'll look into the missing symbol
amackera 13:10 so if we want to remove the symbol we'll need to add a FBWIN_SUPPORTS_WINDOWLESS flag or something to PluginConfig.cmake
amackera 14:10 ok there's an FB_WINDOWLESS cmake define you can make in PluginConfig.cmake now
if you don't then it won't bitch about undef'd symbols
it's a little flakey though, since you can still ask the plugin to be windowless at runtime, via the windowless parameter
taxilian 14:10 amackera: yeah; I'm open to other suggestions :-/
but at least for now, that will do, I think
I am starting to think that we really need a better solution for our factories
unfortunately, that really would be a breaking change
hmm… unless we could do it in such a way that it defaulted to the old way...
amackera 15:10 although hopefully we won't need to make many further changes, and we have an added benefit of not compiling in things that the plugin doesn't explicitly ask for
taxilian 15:10 yeah
I have a thought; I would like to run it by you
but I need to run for a few minutes; you gunna be here in 10?
amackera 15:10 yep :)
taxilian 15:10 amackera: back
ok; so what I'm thinking
is that we should create a configuration class
and there is just one normal "Factory function" that returns an instance of that class
and that class takes care of returning things like the plugincore object and the window
then you only override what you care about
and sensible defaults can be maintained
the default for that class could be to call the functions that we have now
then if we add something like getPluginWindowless, or add another version of getPluginCore that accepts a mimetype, we can provide a default implementation
so that changes can hypothetically be made without making them breaking changes
amackera 15:10 that's a good idea
taxilian 15:10 the tricky part would come in when we tried to do platform specific stuff on it
they'd need 4 versions; the base class and one for each platform
but the platform ones couldn't just inherit from the normal one, since the base one would...
NeilG 15:10 Can I ask something that may well be a silly question?
taxilian 15:10 we love silly questions
they provide entertainment when you're not around
go ahea
NeilG 15:10 I've added a new method that takes a FB::VariantList& parameter
The first argument should be a string so I'm trying to get it like so:
std::string strVersion = args[0].convert_cast<std::string>();
But I get: error C2039: 'bad_cast' : is not a member of 'FB::variant'
That might suggest it doesn't know what std::string is but it's definitely included
taxilian 15:10 can you pastebin the full error message?
and the function?
is that a compile-time error?
NeilG 15:10 It's a compile-time error, yep
I haven't converted over the entire function yet from using NPAPI directly to using the FB functionality
taxilian 15:10 incidently, is what you're really after to pass in an array of strings?
amackera 15:10 brb
NeilG 15:10 An example of what's going on is http://pastebin.com/r41PyHLR
In this case... no. This particular function can just take one string and will be fine - but there are others that will have this problem!
taxilian 15:10 ok, the problem is not actually with the convert_cast
the problem is that there is no FB::variant::bad_cast
http://firebreath.org/display/documentation/struct+FB+bad_variant_cast
NeilG 16:10 Awesome, thanks!
You may want to update the documentation when you get a chance (unless anybody can do it?) because I based that around what I found on http://firebreath.org/display/documentation/JSAPIAuto
taxilian 16:10 anybody can sign up and update the wiki
sure enough; that's wrong
huh
didn't notice that
do you mind updating it?
NeilG 16:10 Not at all
taxilian 16:10 awesome, thanks =]
so I think I have JSAPISecure written; it's actually pretty simple
now I just need to do some testing and I may slip it into 1.3 after all
NeilG 16:10 Okay, done. I actually like that much better than mediawiki (which is pretty much the only wiki I've used before!)
taxilian 16:10 we're pretty happy with it so far; we've only been on it for a week, and it's already much better than the docs we had with google code, IMHO
kylehuff 16:10 lol; how is this possible? top says that chrome is using 180% of my CPU...
taxilian 16:10 do you have multiple cores?
NeilG 16:10 That's the answer
kylehuff 16:10 yeah, but I am pretty sure top reports combined.. I have never seen a value over 100 percent
NeilG 16:10 Nope, it reports where 100% = 1 core
Chances are anything you saw before was single threaded (or had the threading affinity set to the same core)
kylehuff 16:10 well, that may be the case, but a single process cannot use both cores
taxilian 16:10 kylehuff: a single multithreaded process can use multiple cores
chrome is certainly multithreaded
NeilG 16:10 Correct
kylehuff 16:10 not when running --single-process mode
taxilian 16:10 NeilG: back to the original question; do you actually want to pass in a list of variant types, or are you always passing in a list of strings?
kylehuff: —single-process does not mean single thread
kylehuff 16:10 at least, I don't it can in single
NeilG 16:10 I think most arguments are lists of strings
taxilian 16:10 NeilG: VariantList is for when you actually need to be able to accept an array of variant values
if you just need to pass in an array of strings, it's easier to use std::vector<std::string>
it'll do the cast for you and fire an exception into javascript if it can't be converted to string (very rare)
NeilG 16:10 Sure, I saw that. But I didn't know THAT would work. That's pretty damned useful!
taxilian 16:10 thanks, we thought so =]
NeilG 16:10 Well, that's reduced how much work I have left to do down to very little... :)
taxilian 16:10 that was the plan
you can use any type in the vector
you can also use a std::map to get key:value pairs from a js object
NeilG 16:10 There are definitely some methods which use variants so I'll have to use that - but that's fantastically useful to know :)
taxilian 16:10 I think that returning you have to use VariantList or VariantMap, but since you don't have to worry about the type coersion that's not a problem
NeilG 16:10 That makes things much easier.
taxilian 16:10 feel free to update the docs to clarify that =]
I think Georg wrote those, and English is his second language; considering that, they are fantastic, but there are some places that could be improved
NeilG 16:10 I will. I can't right now, I have to head home - but I'll definitely do that tomorrow. It'll be useful for everybody to know that!
taxilian 16:10 yep
it is here: http://firebreath.org/display/documentation/JSAPIAuto#JSAPIAuto-Catchingcontainers
but could be improved
NeilG 16:10 I really need to sit and read through the docs some more, it's just that right now I'm under pressure to get things working in IE so... :)
taxilian 16:10 understood
NeilG 16:10 Awesome. Well, I'm off for now - see you all later!
kylehuff 16:10 something is definitely screwy with top, it just reported 8000 something % cpu usage for a good 2 minutes
taxilian 16:10 lol
yeah, that does sound a little bit high
btw, I read over the doc changes you made on building a firebreath plugin; looks good. thanks for doing that
feel free to update anywhere else you see in need as well =]
I think we need to add a section on working with JSAPI
not under building, just in there somewhere
kylehuff 16:10 no problem; glad I could help.. also, I can't complain about the docs anymore.. =c )
taxilian 16:10 lol. sure you can. they are not perfect; that part is much better, but there are lots of areas where it needs help
I'm quite proud of the doxygen integration, though =]
kylehuff 16:10 I never had a problem with the content of the docs - just the format/organization. (which I understand was not a design decision, but a problem with the google tools)
taxilian 16:10 well, it is possible to organize them well
even with google docs
it's just more work =]
this is much better
I think I might even update my opinion of the FireBreath documentation to "Good" now
but it's still not "great"
kylehuff 16:10 btw; I 1.3.0 RC1 works so far on line after migrating the breaking changes
taxilian 16:10 awesome
it should be pretty good; we're always pretty careful, and mostly we've added things, we haven't really changed much in core functionality
I just want to make sure it gets used in some real things before we mark it as officially "stable"
kylehuff 16:10 yeah; I only mention it because to commits ago or so, it was broken..
taxilian 16:10 what was broken?
actually, probably the log stuff; I think kalev fixed that
kudos to him
kylehuff 16:10 i have no idea; it just wouldn't make - something with the linking..
taxilian 16:10 are you working off the repo or the archives?
kylehuff 16:10 the repo
taxilian 16:10 dev or stable?
kylehuff 17:10 how do you tell?
lol
taxilian 17:10 look at .hg/hgrc
kylehuff 17:10 [paths] default = https://firebreath.googlecode.com/hg/
I don't know what that means
taxilian 17:10 ok, that's the trunk
that's where you should be =]
dev is now moving towards 1.4 is why I ask =]
kylehuff 17:10 ah, roger
taxilian 17:10 you're welcome to use it, and we try to keep it pretty stable, but things will keep changing in minor (usually) ways
at the moment, I'm working in importing a webserver library, in fact =]
kylehuff 17:10 tell me this isn't fsck'ed: https://photos-1.dropbox.com/i/xl/H85XeI4VKGdz3z97hq4OaemnWULfFelB830dahpMmOk/3922816/1287705600/a81fe9f
mocp using 1726 % of my cpu; while paused! lol
taxilian 17:10 huh. interesting
kylehuff 17:10 I think I may have messed up my kernel cpu table somehow.. I was catting various junk to /dev/random to gain entropy; maybe I got some of it backwards and was catting /dev/random to varous places in /proc - lol
taxilian 17:10 lol
brb
kylehuff 17:10 I'm going to reboot and run while I do it; bbl
taxilian 18:10 sometimes I really hate C++
amackera 20:10 the logging module is going to be very, very useful!
taxilian 21:10 amackera: that is certainly the plan
do you have it working?
amackera 21:10 i do
i have already been able to debug a problem because of it!
taxilian 21:10 excelent
feel free to suggest ways we can improve it to a really useable point
amackera 21:10 the file logging path should default to the plugin's install directory, or be configurable
taxilian 21:10 I agree; I just haven't had time to figure out how best to do that
one thing is certain; we definitely need a better way to handle configuration
and I'm still brainstorming good ways to do that
amackera 21:10 it's weird seeing Facebook in the copyright notices :P
weird but cool
taxilian 21:10 so as I've thought more about the class idea, my current mad scheme is to have a FB::VariantMap of config options that you could set "plugin_window_win" to a function ptr
hehe
yeah
it's weird but entertaining to put them there =]
amackera 21:10 haha i bet
i don't quite understand the class idea
taxilian 21:10 well, it would be a global configuration object
so instead of relying on predefined functions that may or may not be there, we check a VariantMap to see if they have specified a function ptr for creating, for example, a PluginWindowWindowless or whatnot
this little embedded web server is actually pretty cool
amackera 21:10 ah i understand
taxilian 21:10 I am certainly open to suggestions on that point, though; what we have is definitely not sufficient, but I haven't decided for certain what to do
amackera 22:10 oh man it's been a long day
taxilian 22:10 hehe
amackera 22:10 i've got to hand it to you, though, you're on here all the time helping people out
you have got to be the most dedicated open source project leader i've ever seen :)
taxilian 22:10 lol
well thanks
amackera 22:10 haha, thank you!
i appreciate all your help and patience :)
taxilian 22:10 hey, I'm just glad that you and Georg are helping out; there is no way I could do all of this myself, even if I knew how
hey, are you on LinkedIn?
amackera 22:10 yeah
taxilian 22:10 I should start connecting with everyone I interact with on FireBreath with LinkedIn
amackera 22:10 good idea
taxilian 22:10 I may need the network some day =] Facebook contract is up in March… :-P
amackera 22:10 you had better search for me: anson mackeracher
i tried searching for you but i'm afraid there's a few people with your name on linkedin
taxilian 22:10 lol
yeah
it's not as uncommon as yours =]
yours returned exactly 1 result :-P
amackera 22:10 haha :P
taxilian 22:10 easiest way to find me is usually my email address or screen name
taxilian is less common
on facebook? http://www.facebook.com/taxilian :-P
amackera 22:10 toootally friending you
taxilian 22:10 kalev, kylehuff, NeilG_Away, iaincollins, elthariel: if you guys are on linkedin, add me [email protected]
amackera 22:10 well i think i'm off for the night
good night all :)