IRC Log Viewer » #firebreath » 2010-09-28

IRC Nick Time (GMT-7) Message
amackera 09:09 Hey guys! So did my last push last night eff up stable again?
taxilian 09:09 nope
it was just fine
seriously, man, don't worry about it too much =]
amackera 09:09 Ok good :)
taxilian 09:09 it happens
amackera 09:09 Ok, but I'll still try to be more careful when I push to stable from now on
taxilian 09:09 that will be appreciated =]
amackera 09:09 I'm going to create an issue and fix this bug this morning
taxilian 09:09 cool
where do you think that should go? stable/1.2.2 or dev/1.3.0?
amackera 09:09 Dev, it's not critical, just confusing
taxilian 09:09 sounds good
amackera 09:09 FireBreaths RefreshEvent should fire when the plugin should draw, yes?
taxilian 09:09 I would think so, yes
that's how it works on windows, I believe
amackera 09:09 ok
taxilian 09:09 amackera: would you mind glancing at issue #23 and tell me what would be the easiest way to accomplish this on Mac?
amackera 09:09 hmm
taxilian 09:09 it's the oldest issue still open; I'm thinking it would be good to get it done finally :-P
amackera 09:09 does no GUI mean no keyboard events, no mouse events, etc?
taxilian 09:09 yes
no window attachedevent
no system events
scripting only, essentially
amackera 09:09 then you could just specify in the PluginConfig.cmake all of the FBMAC_* flags to be 0
taxilian 09:09 I was hoping that would work
amackera 09:09 it should work
taxilian 09:09 just wanted to double check =]
amackera 09:09 it might fail on browser that *require* an event model negotiation, i'm thinking safari
can we create a separate issue for mac and i'll take a look at it?
taxilian 09:09 sure
issue #77
nirvdrum 09:09 Did I hear rumblings about a pending 1.3 release? I'm looking to finally upgrade from 1.1, but may hold off.
taxilian 10:09 nirvdrum: there will always be a pending release of some sort =]
1.2 just pended longer than most
I *strongly* recommend you update to 1.2.1
or even to the stable trunk, as that has a couple of other minor fixes in it
upgrading from that to 1.3 should be negligable
nirvdrum 10:09 Cool.
taxilian 10:09 the only breaking change is that we are changing the way that the JSAPI_DOM… functions operate a little bit
nirvdrum 10:09 Was there a wiki page on how to upgrade?
Since my code is kinda embedded into the downloaded project.
taxilian 10:09
there are notes under "Breaking changes"
for 1.2.0
when you say "embedded", you mean it's in the projects dir of the downloaded FireBreath tree, right?
nirvdrum 10:09 Okay. I'll have to figure out what directories to move over then I guess.
taxilian 10:09 just move your projects dir over
that's all you should need
if you used cmake correctly =]
nirvdrum 10:09 Heh.
I'm sure I didn't ;-)
taxilian 10:09 if you didn't, tell us what problems you run into and we'll help you fix it
amackera is the cmake master
(I should know, since I just arbitrariliy decided that he is)
nirvdrum 10:09 I recall having to customize a couple things in Firebreath outside my project. But, my git log should help me out.
taxilian 10:09 great; contribute them back so you don't have to worry about it again =]
what I would recommend is to keep your projects dir away from the FB source
and get the FB source from a clone
from hg, I mean
then you can hg update to whatever revision you want
nirvdrum 10:09 Yeah, this was when I first started, so I just downloaded the zip.
taxilian 10:09 and not worry about changing other things
I'm recomending that you start this while you're upgrading anyway, since a little more change in flow won't hurt =]
nirvdrum 10:09 Heh.
taxilian 10:09 make your own clone so you can more easily control when things upgrade
nirvdrum 10:09 Yeah. It'll make contributing patches easier, for sure.
taxilian 10:09 also, before 1.2.0 there wasn't an easy way to keep your projects outside of the source dir
now there is
(takes a bow)
nirvdrum 10:09 Heh.
taxilian 10:09 anyway, the upgrade to 1.2 shouldn't be too strenuous; the main breaking change is just the change to boost::shared_ptr
so anywhere you're passing around a JSAPI* you need to change it to be FB::JSAPIPtr, which is just a typedef for boost::shared_ptr<FB::JSAPI>
if you want to just use 1.3 before it's officially 1.3, though, it's pretty stable
nirvdrum 10:09 I just picked up a mercurial ebook for firebreath, too.
What's landing in 1.3?
taxilian 10:09 hehe. great; when you learn really good tricks, tell me =]
nirvdrum 10:09 I changed my vote on git to moving towards github, but that movement seems to have died ;-)
Too bad. I know git fairly well.
taxilian 10:09 lol. well, I'm still kinda wanting to
but the problem is
it's a lot of change
and I decided it isn't (yet) justified
we still may at some point
nirvdrum 10:09 There's that git plugin for hg and the hg plugin for git, too.
Maybe that would make me feel more at home.
But, I'm liking the new pull request UI in GitHub.
taxilian 10:09 yeah; I even thought about trying to maintain a repo on both places
we'll see
I haven't given up on that
the main improvement on 1.3 is much better DOM interaction
the JSAPI_DOM… classes have been renamed to DOM::...
and they are browser specific to a point
so things on ActiveX that require special apis, like getElementByTagName, etc, work
nirvdrum 10:09 Hmm . . .
taxilian 10:09 also the auto type conversion has been improved
nirvdrum 10:09 I'd like an API for NPAPI that provides easy DOM access like IE provides.
taxilian 10:09 that's pretty much what this is
nirvdrum 10:09 Ooh.
taxilian 10:09 though it could stand to be improved
nirvdrum 10:09 When I last looked, it was just way too complicated navigating all the properties.
taxilian 10:09 you can now use an int as a parameter, but it will throw an exception if you pass in something that is out of bounds
there is also an API for getting the location url for the current document
nirvdrum 10:09 One thing we do is serialize a DOM into JSON. Doing a depth-first search against IE is surprisingly easy.
taxilian 10:09 I think that's it for now
not sure I understand what you're doing
nirvdrum 10:09 Since every IHTMLElement has a way of accessing its own properties and getting a list of its children.
I want a textual representation of a DOM with key fields, like position & dimensions.
taxilian 10:09 I think that NPObjectAPI supports that, more or less
most of that is either there or could be added easily
if you'd like to do a little legwork =]
nirvdrum 10:09 For Chrome & Firefox I just do it with jQuery. That was excruciatingly slow in IE.
So, I rewrote it in C++ for IE and it's incredibly fast.
I'll check it out. Like I said, it seemed the last time I looked I had to fetch everything as an invariant type through getProperty() or something like that and it was really painful traversing the tree.
taxilian 10:09 you probably didn't know about the JSAPI_DOMDocument class, then
one sec...
you get the Document from the BrowserHost
you can do things like doc->getProperty<long>("width")
nirvdrum 10:09 Ahh. That's definitely better than I thought, but not as nice as IE still.
taxilian 10:09 so add the methods you need to either Document, Window, Element, or Node as appropriate
nirvdrum 10:09 Right.
taxilian 10:09 in fact, you can already do getWidth() and getHieght()
or setWidth, setHeight()
nirvdrum 10:09 Yeah, I'm looking at that.
taxilian 10:09 so the basics are there
nirvdrum 10:09 The offset stuff I'd have to look into.
taxilian 10:09 well, offset works differently in all browsers
so you'd need to play with it
but I've done it before
nirvdrum 10:09 Indeed.
taxilian 10:09 I'm just sayin', there is an easy solution to just about any of the problems you describe =] and most are just a question of adding little helper methods that would take 5 min
nirvdrum 10:09 I know you'd like to prevent the API from getting fat, but it'd probably be nice if tagName, id, and class were available out of the box, like the dimensions are.
taxilian 10:09 actually, I'm fine with that on the DOM objects
that's what it's there for
I just haven't added things I didn't need
nirvdrum 10:09 Ahh.
taxilian 10:09 I considered other things to be more important
like fixing crashers that were logged for 4 months without resolution =]
nirvdrum 10:09 I still prefer the out-of-the-box rich classes in MSHTML. But this is definitely workable.
taxilian 10:09 I'm open to suggestions
particularly if you're willing to help code it =]
nirvdrum 10:09 Well, we could replicate it. It's just a fair bit of grunt work.
Just about every element has a corresponding class.
taxilian 10:09 I personally think that the IE stuff tends to be a tiny bit overweight; however, the ones that actually matter we could do, if it makes sense
I just created the basics because I didn't have a specific use case and they were adequate for what I needed
nirvdrum 10:09 Well, what's really nice about is it's type-safe and documented.
Versus a method that just takes a string and that I need to coerce into the appropriate type.
taxilian 10:09 NPAPI is not typesafe by nature
and ActiveX isn't really either
but we could certainly create typesafe methods on the DOM objects
as their intention is to wrap the browser objects and provide a more useable API
I'll always want to have the "uber-flexible" apis on it as well, but that's just for the "I'm doing something you never conceived of, how do I do it?" cases
nirvdrum 10:09 Well, when I look at that again, I'll wrap some of the more common ones up.
taxilian 10:09 I'm even willing to create a Table object, for example; just only if there is actually a legitimate reason why it should be there
if that makes sense
I don't want to create an API just for the sake of creating an API
but if there is a reason… sure
one thing to always remember: I never reject a patch out of hand. in fact, I don't think I have ever actually rejected one, though a few I requested minor changes to. I just personally only focus on the cases that everyone needs or the cases that I personally need for work =]
nirvdrum 10:09 Heh.
Well, my gripe wasn't with Firebreath, but rather the browser APIs.
taxilian 10:09 right; and the fact that they should have something unified is exactly why I created FireBreath =]
so by all means
see a problem? let's fix it
amackera 12:09 Hey guys, I'm really quite confused about something in C++
for example creating a MouseMoveEvent
taxilian 12:09 okay
amackera 12:09 one can go MouseMoveEvent ev(x, y);
and that instantiates the object on the stack?
taxilian 12:09 err, yeah, in general
amackera 12:09 wheras MouseMoveEvent ev = new MouseMoveEvent(x, y) instantiates it on the heap?
taxilian 12:09 but only for that line
amackera 12:09 so once i exit the scope of that function, the object instantiated on the stack is not retained, right?
taxilian 12:09 once you go to the next line
amackera 12:09 really?
taxilian 12:09 oh, wait
no, I misread
yes, you are correct
amackera 12:09 ok
taxilian 12:09 when it goes out of scope, the object will be destructed
amackera 12:09 alright
so if the object has a constructor that takes no arguments,
it would make sense to me that i could say RefreshEvent ev();
and SendEvent(&ev);
taxilian 12:09 usually you'd just say RefreshEvent ev;
but I think either works
amackera 12:09 and drop the parens?
that makes sense now :)
taxilian 12:09 glad I could help
the case I was thinking you were using is if you do something like "SendEvent(&RefreshEvent())"
which will create a RefreshEvent, send it, and then the next line (after the function call) destroy it
some compilers scream at you when you do that, though
even though the way I use it should be fine =]
amackera 12:09 That does intuitively make sense
taxilian 12:09 MSVC doesn't mind it. I think GCC works, but throws warnings
amackera 12:09 I suppose the compiler might think you're trying to send the address of the member function
Well, no, that would imply no parens
taxilian 13:09 I think the warning is something like "sending address of temporary object" or some such
amackera 13:09 ahh well that makes sense
taxilian 13:09 you can certainly see how someone not really familiar with C++ (and some who are) could do bad things with such a thing
amackera 13:09 ohh yeah
taxilian 13:09 but it's still annoying, since I'm using it properly =]
amackera 13:09 like retain the object in the function they are calling or something
taxilian 13:09 well, gotta go talk to a professor
amackera 13:09 ttyl!
amackera 13:09 taxilian: have you had any luck debugging on chrome?
taxilian 13:09 on Windows yes
I haven't tried on Mac
amackera 13:09 ok
i have a build of InvalidatingCoreAnimation, and as far as i know chrome on mac is the only browser that supports it
taxilian 13:09 the main trick you need is the flag that causes the dialog to pop up
not sure how that works on mac, though
amackera 13:09 Yeah.. I'm not sure either
taxilian 14:09 lol; the second link on a search for "debug plugin chrome mac" is the firebreath wiki page
amackera 14:09 lol
taxilian 14:09 you've tried --plugin-startup-dialog?
amackera 14:09 i tried it on the .app bundle but it didn't seem to have an effect
like /Applications/Google\ Chrome/ --args --plugin-startup-dialog
i also tried it on the actual executable in the bundle, but it didn't seem to happy about that either
yeah it just crashes for me
taxilian 14:09
looks like you can add switches if you launch it from xcode
amackera 14:09 ah, single process mode
taxilian 14:09 yeah, but I wouldn't use that if you can avoid it
according to smorgan, who claims to work on the project, single process mode npapi plugins don't really work
but if you can add command line switches you can probably add the —plugin-startup-dialog switch
amackera 14:09 ah yes good point
Oh hey, so I totally got offscreen rendering to work with Carbon
render openGL to an FBO, then draw with a CGContextRef
taxilian 14:09 awesome
how is the performance?
amackera 14:09 i haven't had a chance to benchmark (even by inspection), so i can't say
almost certainly pretty slow though
there's lots of buffer munging going on
taxilian 14:09 seems likely
amackera 14:09 So it's possible to have openGL accelerated windowless plugins on both windows and mac, on all major browsers
taxilian 14:09 excelent
what did you do to get around the problems on windows?
amackera 14:09 the only problem on windows, i think is a timer, no?
you get an HDC from the browser, which is all you need to get an OGL context
taxilian 14:09 I thought you were getting a different HDC each time or some such
amackera 14:09 hmm yes, now that you mention it i do remember that
i'm going to check it out tonight, so i'll let you know :P
maybe i was doing it wrong
taxilian 14:09 I still think there has to be a way, though
taxilian 14:09 so amackera: does this (reviewing your changes) mean that you figured it out and got InvalidatingCoreAnimation working?
awesome! =]
amackera 15:09 yeah, it seems to work on my plugin
taxilian 15:09 awesome
did I mention? awesome =]
amackera 15:09 lol, it's really not much different at all from regular CA
taxilian 15:09 someday I'll have time to review your windowless changes and look at importing them :-/
amackera 15:09 no biggie, i'm going to revisit them soon so i can fix them up
taxilian 15:09 that would be cool
I'd love to have that (or at least a beta version) ready for 1.3
amackera 15:09 what's the release timeline on 1.3?
taxilian 15:09 still up in the air to some extent
basically it's when we have enough features that are ready to go live that we want in 1.3
most of what is planned for 1.3 is there
amackera 15:09 sounds good
taxilian 15:09 the three things that aren't done yet that we've been talking about for 1.3 are "no gui" mode, windowless plugins, and JSAPISecure
oh, and synchronous JSAPI calls
taxilian 15:09 cygmatic: I used something very similar to your JSAPIAuto make_method stuff on my VM assembler/executor for class; it's really slick =]
cygmatic 15:09 nice to hear
cygmatic 16:09 taxilian, how would you push a single change on default to dev too?
taxilian 16:09 well, there are multiple schools of thought on that… ;-)
from what I've read, the easiest might be to create a patch and then apply it to the other one
cygmatic 16:09 ok, export/import would be that?
taxilian 16:09
no, export is something else, I believe
cygmatic 16:09 so for the single line change i'll just apply it manually? ^^
taxilian 16:09 it might even just be diff / patch
probably =]
this would be another reason it would be nice to use git
the Transplant Extension is designed for things like that
I haven't used it, though
cygmatic 16:09 hm, might be worth trying out such things on a clone
taxilian 16:09 yeah
oh, yeah, thanks for getting that
it's a good day when so many issues get cleared without me doing anything =]
cygmatic 16:09 no problem, was just 5 chars anyway ;)
taxilian 16:09 hehe.
Anson did a pretty good commit today, though =] InvalidatingCoreAnimation support is in dev
cygmatic 16:09 nice
taxilian 16:09 trying to think what else needs to be in before we do a 1.3.0
thinking I'd like to get the cross-thread calls w/ functor working
and JSAPISecure
cygmatic 16:09 huh, google code closes automatically with a revision comment?
taxilian 16:09 never noticed
cygmatic 16:09
only comment 2 is from me
taxilian 16:09 I wondered about that
cygmatic 16:09 hm, seems like it does that on "fixes issue #nn" but not on "fixed issue #nn"
ah, found it:
so preferrably use "fixes issue NNN" in the future (amackera, taxilian)
amackera 16:09 mm ok
cygmatic 16:09 taxilian: wasn't there a bit missing for the refactoring for 1.3?
taxilian 16:09 hmm
I don't remember for sure
cygmatic 16:09 those typedefs in APITypes.h i think?
taxilian 16:09 we had discussed changing BrowserHostWrapper to BrowserHost and normalizing on BrowserHostPtr, same probably with BrowserObjectAPI -> JSObject and JSObjectPtr
my only concern
is backwards compatibility
do we leave typedefs so that the old ways still work for a few versions?
cygmatic 16:09 hm, if its possible?
taxilian 16:09 I don't know why it wouldn't be
they are just typedefs =]
cygmatic 16:09 on the other hand, you broke a part now anyway?
with the dom refactoring etc.
taxilian 16:09 true
but the dom refactoring isn't real major
since most people (even nirvdrum) don't know it's there
cygmatic 16:09 heh, ok
nirvdrum 16:09 Ouch.
cygmatic 16:09 leaving the typedefs for browserhostwrapper and browserobjectapi doesn't hurt anyway :)
taxilian 16:09 true
nirvdrum: that wasn't intended as a slam on you =] just that you are here often, and if you didn't even know it was there, it's a fair bet that most people haven't seen it
nirvdrum 16:09 Heh. Yeah, I just wanted to make you feel bad :-)
taxilian 16:09 Georg, do you want to do that part of the refactor, or should I add it to my list?
cygmatic 16:09 i'll take a look at it
mac & windows, no linux here currently
taxilian 16:09 that's okay, I can build on windows
and I bet kalev can test it for us (though maybe not immediately when done, that's still fine)
build on linux, I mean
I can build on linux
cygmatic 16:09 whoa, that problem with is new: "CMAKE_OSX_DEPLOYMENT_TARGET (10.6) is greater than CMAKE_OSX_SYSROOT SDK (/Developer/SDKs/MacOSX10.5.sdk). Please set CMAKE_OSX_DEPLOYMENT_TARGET to 10.5"
taxilian 16:09 ...
I've never seen that issue
where did you see it? on your own machine?
cygmatic 16:09 anyone know where those are set?
never seen it before
amackera 16:09 hmm
cygmatic 16:09 so it has to be a recent change
taxilian 16:09 amackera: is that you somehow? you're the only one who has pushed anything lately =]
amackera 16:09 might have been me
taxilian 16:09 it might not be a bad idea to have the default be 10.5
as long as it can be overridden
amackera 16:09 well if it's me it's a flag i'm setting in the
Yes it's my fault
shall i push a fix?
taxilian 16:09 yes, please =]
amackera 17:09 sorry about that
taxilian 17:09 happens
if it makes you feel any better, we would have known about it in another hour or two, since it would have broken the build
and the build goes every 6 hours if there are changes
amackera 17:09 hah, well it's good we caught it
taxilian 17:09 yep
btw, what I would recommend instead of modifying directly
is creating your own prep script in another directory that calls the first
but that's just me
amackera 17:09 yeah good call
ok i've pushed the fix
taxilian 17:09 ok, anything else for 1.3? I have: windowless support (issue 80, if amackera has time), top-left window coordinates (71, higher priority, I think), "no-gui" mode (issue 23, 77), name refactor (issue 81)
JSAPISecure support, probably — though I don't have an issue for that yet
amackera 17:09 seems pretty reasonable to me
taxilian 17:09 nirvdrum: if you have any strong requests for 1.3, now is the time =]
nitrogenycs, kalev: if you guys are around, feel free to weigh in
nirvdrum 17:09 taxilian: I haven't been able to crack my VM to look at this yet, so nope.
taxilian 17:09 well, we're not going to be releasing it today; probably not this week, in fact
the timeline I'm thinking is maybe next Thursday
with this Thursday being the 1.2.2 release
amackera 17:09 what else is left for 1.2.2?
just testing/bug fixes?
cygmatic 17:09 taxilian: what backwards compatible typedefs do you want for the refactoring. e.g. i can't keep BrowserHost with the same meaning if changing to BrowserHost as the class & BrowserHostPtr as the smart ptr
taxilian 17:09 hmm
just a typedef for BrowserObjectAPI to the new JSObject
and BrowserHostWrapper to BrowserHost
cygmatic 17:09 ok
nitrogenycs 18:09 taxilian: no special wishes here, I'm currently writing a bigger extjs ui around my plugin so I barely get time to work on the plugin itself. Additionally, it already has most features I need right now :)
taxilian 18:09 glad to hear it =]
cygmatic 18:09 hm, didn't we have any FB define for the platform?
taxilian 18:09 where?
there is one, yes
cygmatic 18:09 nevermind, i don't think the header belongs there anyway
taxilian 18:09 lol
I totally agree
cygmatic 18:09 FBTestPlugin.cpp shouldn't include mac plugin window headers
taxilian 18:09 agreed
I have toyed with the idea of extending FBTestPlugin into FBTestPluginWin/Mac/X11
and put just the drawing handler stuff in those classes
cygmatic 19:09 might be helpful as an example
alternatively fbgen could generate those stubs?
taxilian 19:09 I've debated it
if I create a "paid" web version, the paid version will definitely be able to generate it that way
I'm not sure if all plugins will want to have that
cygmatic 19:09 ok, good point
it would be a bit confusing as to what one can safely remove
taxilian 19:09 but it could be good to do with FBTestPlugin as an example
btw, have I shown you this yet?
can't remember if you were in the room when I posted it before
cygmatic 19:09 yes, you did :)
taxilian 19:09 ok
cygmatic 19:09 taxilian, any problems with a src/common/ directory?
taxilian 19:09 what do you plan to put in it?
cygmatic 19:09 at the moment only a FB_UNUSED_VARIABLE() macro
taxilian 19:09 lol. what for?
and why in common/?
cygmatic 19:09 the unused warnings in FBTestPlugin are at the moment annoying ^^
taxilian 20:09 lol. can those variables not just be removed?
cygmatic 20:09 they were nitros example code
for the streams
taxilian 20:09 ahh
well, I would prefer you just clean up the code :-P
cygmatic 20:09 plus the pluginName/pluginDesc always give those warnings too
taxilian 20:09 I guess I'm just not sure I like the idea of creating a dir that isn't specific to a project
cygmatic 20:09 but then we wouldn't have any example code for the streams
taxilian 20:09 hmm
why don't you just put it in APITypes?
I know it doesn't really go there
cygmatic 20:09 ok, maybe if there is more stuff that is used across multiple projects
taxilian 20:09 but it still seems cleaner than an extra dir
I'm not saying there are no situations that I would feel justify it.. just that I'm not sure that does =]
cygmatic 20:09 alright
i wonder why the "BOOST_LIB_NAME redefined" warning still turns up - i thought kalev had this fixed with an earlier commit :|
taxilian 20:09 it's mainly because boost has this autolink stuff that normally defines that
and I disabled it
so now that turns up
I haven't had time to try to track it down yet
probably not hard to do
at least to hack
cygmatic 20:09 today the 100th user joined the google group
and we have the first question tagged as firebreath on SO:
taxilian 20:09 nice =]
I think I'll tweet about that =]
cygmatic 20:09 btw, i already had a help forum post:
taxilian 20:09 I knew it was there somehwere
but I thought maybe a second from another project might help get their attention :-P
here's hoping that the silence means they're working on it and they don't want to answer 'til they can give good news
and not that they just haven't bothered to read it
cygmatic 20:09 i always wonder why some people can't just post a "looking into it"
taxilian: refactoring is done - will you mark this as fixed after test-build on linux?
taxilian 20:09 yes
is it pushed?
cygmatic 20:09 yep
kylehuff 20:09 maybe a dumb question - I am trying to find out if there are any async thread methods provided by firebreath that I can use, or if I should just use NPN_PluginThreadAsyncCall?
taxilian 20:09 what are you trying to do?
(first, though, you should never call a NPN_ function directly)
kalev: there is an Async call method on BrowserHost, *but*, there is probably an easier way… depending on what you want to do
kylehuff 20:09 I have a method that takes an extremely long time to execute - (5-10 minutes) and I don't care that the plugin is unavailable throughout that time, but for example chrome pops up a kill|wait dialog - I am currently getting around that with a boost::thread, but that is just interim.
(the method is crypto key-generation, and has to wait on available entropy from the system.)
cygmatic 20:09 so you have a worker thread and want to call javascript from it? or invoke a callback?
i mean, throw an event?
kylehuff 20:09 yes, and all of that works, it invokes a callback that emits a registered event ATM. the primary reason for needing to have it thread is to free up the main JS thread and allow the page to continue
taxilian 20:09 firing events from other threads should be no problem
also, a JSObject has an InvokeAsync function
that is threadsafe
kylehuff 20:09 Is that in the docs? I don't know how I missed that.. =c )
taxilian 20:09 you must have forgotten to add it… do you want me to give you access so you can? ;-)
welcome, btw
cygmatic 20:09 kylehuff:
should all be in there :)
taxilian 20:09 well, what'd'ya know… it *is* in the docs. huh. I didn't think it was. :-P
we should probably add a page about dealing with javascript methods/objects, though
kylehuff 20:09 I don't understand, doesn't that page describe firing events that get picked up by <plugin>.attachEvent|addEventListener ?
the method I am trying to thread is a method within the plugin
cygmatic 20:09 and you wanted to fire a event when it is done, no?
taxilian 20:09 wow, I totally misread; I thought you were kalev for the first half of this conversation. I must not be getting enough sleep =]
kylehuff 20:09 yes, which I have already implemented using the docs on that page.
taxilian 20:09 so from your thread, you just fire the event
it will be threadsafe
kylehuff 20:09 the thread fired via InvokeAsync, yes?
taxilian 20:09 the thread you start with boost::thread
just like you normally would
we try to stay out of your way while you're doing silly things like playing with threads =]
just do whatever you were going to do
but when you want to make the callback? Either call it using InvokeAsync on the method they passed in or probably better just fire an event
I think I understand
we're not quite talking about the same thing
kylehuff 20:09 lol
I am getting that
taxilian 20:09 you were wanting to use NPN_PluginThreadAsyncCall to start your 5-10 minute process?
kylehuff 20:09 yes - or whatever is best..
taxilian 20:09 yeah… don't do that
bad idea =]
see, PluginThreadAsyncCall is actually an async call on the main plugin thread… which is the main UI thread
which means if you do something blocking on that thread, it locks up the whole browser
so instead, you create your own thread and do you thing; then when it's ready to talk to the page again it uses PluginThreadAsyncCall to fire the callback into javascript
because you can't call NPN_ functions (except that one) from another thread
does that make more sense?
kylehuff 20:09 yes, I believe so.
taxilian 20:09 so we don't specify a way that you have to create your thread
kylehuff 20:09 I understand
taxilian 20:09 but we do try to provide mechanisms that you can use to make the call back into the browser; hence you don't ever call NPN_ functions directly, but you could use the AsyncCall method on the BrowserHost to schedule something to run on the main thread if for some reason you needed to. It's signature is pretty much the same as NPN_PluginThreadAsyncCall, and on NPAPI browsers it usually uses that on the backend
sorry for the confusion =]
I think I've been using ML too much today
Hmm. Perhaps we should create a wiki page on dealing with threads
kylehuff 20:09 It's okay - I am not in my element with C++, I have been confused all day...
taxilian 20:09 well, you've come to the right place =] usually, anyway… when I'm actually paying attention (or more often when Georg/cygmatic catches where I'm off in my own world)
cygmatic 20:09 kylehuff: no worries, it gets easier after a few years ;)
taxilian 20:09 let us know if you run into any other problems
and feel free to keep a list of things that you didn't find in the docs clearly =] we are well aware that they need improvement
kylehuff 21:09 so, this is not really a firebreath API question, but; how would *you* implement a long running, blocking worker thread? is boost::thread the best way to do that?
likewise; if there is somethign I can do to help with the docs, I am willing to help as time allows..
cygmatic 21:09 i'd go with boost::thread too, especially if you want it to be portable
no need to reinvent what they did :)
taxilian 21:09 kylehuff: just give me your google userid and I'll give you access
I have a policy of "trust them until they prove they can't be trusted" =] so I trust you
kylehuff 21:09 [email protected]
I am trustworthy; so long as we are not playing poker or going after the same girl...
=c )
taxilian 21:09 if you're considering a major change, run it by us (at least at first). otherwise, just go ahead and do it; we can always change it back if need be =]
well, I'm married and don't gamble… you might want to watch out for Georg, though… ;-)
cygmatic 21:09 hm, depends on where you live ^^
kylehuff 21:09 well, I am also married, so don't tell my wife I gamble..
taxilian 21:09 lol
cygmatic 21:09 so telling her about the girls you go after is fine? ;)
kylehuff 21:09 lol
as long as we weren't in Vegas, I guess it is fine you tell her..
taxilian 21:09 LOL.
so my son just got into the cornmeal while we weren't looking...
he's got it dumped in a pile on the floor playing in it like a sandbox
kylehuff: you should have access to edit the wiki now
and I think keeping track of and documenting your experience figuring out how to use threads well in FireBreath would be a great place to start, though whatever you'd like to do is appreciated
cygmatic: all 4 builds succeeded
lin32, lin64, macos, and win32
kylehuff 21:09 so, I have been using the prep scrips and building on Linux and Windows - just FYI, it has been working great..
taxilian 21:09 awesome
kylehuff 21:09 So, another possibly dumb question, just confirming, if I am using boost::thread, will I need to make the boost libs a dependency for the plugin? or does that get packaged with the plugin? (since some elements of boost are being used already)
cygmatic 21:09 per default boost thread is already linked in
taxilian 21:09 it's currently the only one that is linked in by default
I'll probably be adding support for optionally linking in boost filesystem sometime soon, but it won't be on by default, most likely
kylehuff 21:09 oh, well, that makes my first question completely irrelevant.. I have no need to ditch the threading I already have implemented
taxilian 21:09 nice to suddenly find out you didn't waste any of your work, no?
cygmatic 21:09 taxilian: great... i left the BrowserObjectAPI.h & BrowserHostWrapper.h there to address your backwards compability concerns... they just include the renamed headers
taxilian 21:09 ok; we'll leave 'em there for a few releases and then take 'em out
is there a #pragma that will give a deprecated warning?
cygmatic 21:09
kylehuff 21:09 yes, especially since it is a damned miracle it works..
taxilian 21:09 hehe =]
one of the things I'm hoping to have implemented by 1.3 is the ability to call Invoke and have it return a value from javascript… cross-thread
that's trickier than it initially sounds
cygmatic 21:09 #pragma deprecated( identifier1 [,identifier2, ...] )
hm, but i don't know wether the deprecated things make sense for typedefs
taxilian 21:09 cygmatic: what do you think, is it worth putting that in?
cygmatic 21:09 oops, that was weird - sorry about that ^^
taxilian 21:09 I don't know either
"You can deprecate macro names. Place the macro name in quotes or else macro expansion will occur."
if you can deprecate a macro, you should be able to deprecate a typedef...
cygmatic 21:09 ok, GCC can deprecate typedefs
taxilian 21:09 awesome
so kylehuff: how long have you been using FireBreath? and how did you find it?
if you don't mind me asking
cygmatic 21:09 ok, VS can do the same
now its just a question of putting that in a nice macro
kylehuff 21:09 taxilian: about 3-4 months - I went searching for information on cross browser/platform NPAPI development and stumbled on firebreath. so far I have no reason to continue my search
taxilian 21:09 glad to hear it. have we heard from you on the list or anything before and I'm not remembering?
(my memory for names is notoriously bad)
cygmatic 21:09 taxilian: this appears to be the best we can do:
kylehuff 21:09 no, I am subscribed to the list, but I have never used it. I am pretty stubborn and will usually fight with a problem until I find a way around it. (mostly because I know next to nothing about C/C++ and sometimes have trouble identifying if the problem is technique or an actual issue.
cygmatic 21:09 oops, make that an #elif... but you get the idea
taxilian 21:09 cygmatic: not as pretty as we might want, but will it do what we need?
kylehuff: well, I'm glad you stopped in. Sometimes I feel like we only hear from users who things aren't working well for =] feel free to ask questions in here whenever you need. we might be slow sometimes at answering, but we'll answer
also, if it helps, I was pretty novice at C++ when I started working with browser plugins. Georg is the C++ expert in the group
cygmatic 21:09 i'd say advanced c++ user... maybe expert in 10 years or so ;)
taxilian 21:09 I was speaking relative to the rest of us ;-)
I consider myself an advanced c++ user, but when you start talking about meta programming it makes my head spin
cygmatic 21:09 taxilian: yes and it doesn't get better as we can't generate a preprocessor directive from a macro
taxilian 21:09 cygmatic: well, if it does what we need, let's throw it in; do it for JSOutObject as well
cygmatic 21:09 GCC gives me a nice: warning: 'BrowserHostWrapper' is deprecated (declared at [...]/src/ScriptingCore/APITypes.h:58)
kylehuff 21:09 thanks, I appreciate it. So far everything is working great. I am on IRC every day, but just before I popped in I heard about this room. I mostly wanted to stop in and let you know overall, it works great for me and my primary development platform is linux, and I have no complaints, and 2.) I can find nothing wrong with CMake. (granted, I am not an expert..)
taxilian 21:09 kylehuff: I really do appreciate that. we've spent a *lot* of time on this project, and I can't tell you how nice it is to occasionally hear that there are people using it that we haven't heard from simply because… it all works =]
do you do any graphics stuff with it?
my main concern on linux is that the graphics/drawing stuff still feels like it needs work
kylehuff 21:09 no, in fact, the plugin is loaded in an isolated sandbox (in chrome in anyway), it does not load on web pages ever, it will be packaged inside of an extension, loaded into a background page and only the extension will interact with it.
taxilian 21:09 cool. well, sounds like you're primarily using the parts that are most solid, then =]
cygmatic 21:09 taxilian: should i add a #warning "deprecated" to the compability headers while i'm at it?
taxilian 21:09 yes
kylehuff 21:09 for this project yes, but as I become more familiar with the process, I can see several more applications for use in places where there is currently activex controls (on our clients corporate intranets)
we *hate* implementing client side functionality for our clients that locks them into IE - which we hate even more. =c )
taxilian 21:09 ahh. and firebreath is great for those, since it's actually easier to do things in firebreath than it is in activex… and then it works everywhere =]
kylehuff 21:09 right - and for any platform. this is all *really* great news.. the project I am working on is personal hobby stuff, however, I am charge of the development division of our company, so while this is for (masochistic) pleasure - it will undoubtedly end up being a pilot program.. lol
taxilian 21:09 hehe. good to hear
if you need any professional consulting, talk to cygmatic. he needs a new KVM =]
kylehuff 21:09 I will keep that in mind.
so, firebreath related question; how would one access the boost::thread methods? the only way I can seem to make it work is to #include "boost/thread/thread.hpp" in my header file, but it doesn't resolve the symbols unless I add in the ${Boost_THREAD_LIBRARY} in the projectDef.cmake target_link_librarires(${PROJNAME} directive
which, that links the file against the boost libraries...
taxilian 21:09 what version of FireBreath are you using?
kylehuff 21:09 v1.1.1
taxilian 21:09 update to at least 1.2.0
preferably 1.2.1
it will require some changes
kylehuff 21:09 okay,
taxilian 21:09 but the thread stuff is integrated
kylehuff 22:09 yeah, that is why I was holding off =c )
taxilian 22:09 also there are more protections against accidently doing something dangerous / bad with threading
it shouldn't be too bad
kylehuff 22:09 well, I am comfortable with upgrading now, and making the needed changes as the plugin is in a stable state now.
taxilian 22:09 you can also keep your projects/ directory outside of the firebreath root as of 1.2
kylehuff 22:09 I do already.. god bless `ln -s`
taxilian 22:09 hehe
there is that in linux
kylehuff 22:09 that will be godsend for compiling on windows though...
taxilian 22:09 yep
you can even run the prep script from elsewhere
which helps particularly if you want to write your own script with special cmake params
kylehuff 22:09 I currently have to checkout the project source, then copy it over, then I make a tweak in the wrong damn version.. ugh..
taxilian 22:09 ../firebreath/ projects build
kylehuff 22:09 sweet
taxilian 22:09 yeah; 1.2 was the first version released after Facebook hired me and I could actually spend some real time on it again
then with me doing more, the other contributors stepped it up as well
and the 1.2 branch is, frankly, awesome
1.3 will be even better
but will not be as difficult to upgrade to =]
kylehuff 22:09 I haven't used 1.2 yet, but I already agree.. lol
have you thought about mentioning #firebreath on the wiki home "Shout-out to us!" section?
taxilian 22:09 probably a good idea
it's on the home page
but nobody sees it
would you like to add it? =]
(if you remove the ?… stuff at the end of the url, the edit link reappears)
kylehuff 22:09 I see it every day!
taxilian 22:09 but the #firebreath link has been there for months, and you just barely noticed it, no?
kylehuff 22:09 I still don't see it, I found it mentioned here:
taxilian 22:09 huh. glad I wrote that, then =]
do a search for "#firebreath"
it is there =]
kylehuff 22:09 oh, yeah, I don't even look at the "Project Page" or any home-page.. I go right to Issues and Wiki.. I have issues..
taxilian 22:09 cygmatic: running test builds on dev/ now
well, I can add it to the wiki page
you are also welcome to add it =]
(I'm working on homework, so trying not to get too sidetracked)
kylehuff 22:09 I will add it to the shout-out section.. if nothing else than to test out my edit privs...
taxilian 22:09 =]
I bet that's why nobody ever comes in here… they don't ever see it =]
looks good to me =]
cygmatic: all the builds have succeeded except the windows one (which takes twice as long), so that will probably also succeed
kylehuff 22:09 lol.. yeah, I would have joined sooner for sure. I like to help out where possible when I am using a project, and for me, IRC is the best place to establish a connection with the developers. It is sometimes hard to identify the goal and focus of a development team when they seem inaccessible. In this environment, I can passively listen without interrupting and lend a hand when it something I can handle.
taxilian 22:09 nitro and nirvdrum are usually here in about that capacity as well =] and I will ocasionally ping everyone in the channel for an opinion when we're trying to make a decision
I did today asking what features they would like to see in 1.3, as we are working on narrowing down the release for 1.3 and when we want to do it
I would like to think that this project is pretty open as far as helping new people and accepting ideas
though we sometimes have to respond with "implement it and we'll merge it in" =]
kylehuff 22:09 =c )
yeah, sometimes that has to be said..
taxilian 22:09 the sad thing is that often it's a good idea
but there are really only three people currently actively doing development
and we all have our own agenda
kylehuff 22:09 and lives, family, etc.. sometimes I don't think people understand how time-consuming this stuff is..
taxilian 22:09 hehe
however, I've been pretty impressed with the FireBreath community so far
this is my first (and only, really) open source project
and so it's really cool to see people using it, see it gain some recognition, etc
kylehuff 22:09 well, personally, firebreath has saved me loads of development time. it abstracts a lot of crap I don't want to *have* to know in order to do what I want to do - if someone kidnapped my kids, they could totally get away with it if they were wearing a firebreath t-shirt...
taxilian 22:09 lol
the problem with having a firebreath t-shirt
is it would require a firebreath logo in order to look good ;-)
we definitely need to get one
just in case I decide to start kidnapping kids...
kylehuff 22:09 lol
taxilian 22:09 but I'm glad to hear that it's been helpful for you
makes my day =]
kylehuff 22:09 well, I am due to release this project soon - which is a miracle beings as I wrote it for a specific browser/platform, and other than the extension - it already works on the other major platforms and browsers... automatically, without trying.. (that is to say, without ME trying.. speaks nothing of your efforts!)
taxilian 22:09 lol. awesome =] actually, another thing you could help with when you have some time; it would be really cool to see a wiki page about how FireBreath can be used as part of a browser extension
kylehuff 22:09 my plan was to make it work in all browsers for linux and mac, then hack it to death making it work in windows, step 2 is not needed thanks to firebreath
taxilian 22:09 windows is, unfortunately, the platform I'm most familiar with developing on
however, the good news is that that means that it's the most solid in FireBreath
kylehuff 22:09 I have most of it written in the docs explaning the innards of the extension. I will be cleaning those up soon and can merge the relevant parts into the wiki.
taxilian 22:09 since it was written first for that platform
kylehuff 22:09 well, if you would have asked me, I would have guessed it was written first in linux.. (not much stuff written for windows first uses CMake..)
taxilian 22:09 yeah; that's why so many windows devs hate cmake =]
kylehuff 22:09 lol
taxilian 22:09 but it actually didn't initially use cmake
I was trying really hard not to use cmake
but I couldn't find another way to do it
so finally I got tired of trying to keep multiple project files in sync
and just created a cmake structure for it
kylehuff 22:09 yeah, I think CMake does a very elegant job..
rather, does an elegant job doing an inelegant task..
taxilian 22:09 hehe. yeah, it works pretty well
I will probably eventually create a little python tool that will traverse the project and de-cmakeify it for those die-hard windows guys that refuse to do something that uses cmake
kylehuff 22:09 speaking of windows - is there a solution to building on windows that doesn't require visual studio? has anybody successfully cross-compiled it?
taxilian 22:09 no
the reason is that we depend on ATL
I would love to be able to rewrite it to not require ATL
but I lack the time
I am learning more and more, and I don't really think it would take that much work
the hardest part would be to come up with an alternate method of parsing the .rgs files to insert into the registry
kylehuff 22:09 ah, I see..
visual studio is expensive, and I am cheap. visual studio has lots of buttons, and I use vim. visual studio requires windows, and I live in the rainy-state - we don't open windows..
taxilian 22:09 hehe
well, if you have any COM experience, you're welcome to write us a fix =]
many would love you for it
I'm really tempted
kylehuff 22:09 lol
yeah, I am not a programmer.. for sure...
taxilian 22:09 but it's probably a decent week of work, and I don't have the time
kylehuff 22:09 I don't know COM worth a damn - but I know people who do.. and they all work for me... lol - if I can justify it, I might find a way to weasel it in...
taxilian 22:09 if you can find someone to work on it, I'll help
I can even point you at some example code, though it's GPL so we can't steal it
kylehuff 22:09 yeah, I will look into it.. I would love to not have to fire up my windows vm..
taxilian 22:09 so would a lot of other people =]
I do all my development work on a mac
kylehuff 22:09 ha, yeah.. I have stopped testing in windows for the time being because my 90day visual studio trial ran out.. =c (
taxilian 22:09 lol
didn't you say it's a VM? revert to earlier state, and...
or reinstall
kylehuff 22:09 yeah, the problem is, the last snapshot was BEFORE I installed - and it takes like 5 hours to install..
taxilian 22:09 overnight =]
just sayin' =]
kylehuff 22:09 yeah, I am have been waiting until I actually need to test it.. I was testing like, after every change - you know, skeptical about if it would work in windows or not.. lol
but, that was when I was working on my part of it.. see, I did it backwards. I wrote a standalone binary with all of my methods and logic, etc. and then import that into PluginAPI.c, and call methods from there - I don't need, but want the other part to be able to run as an application.