IRC Log Viewer » #firebreath » 2011-02-24

IRC Nick Time (GMT-7) Message
taxilian 00:02 well, good night
doppiabeo 06:02 Hy... upgraded to fb 1.4 with cmake 2.8.4 -> cannot run examples
any clue?
doppiabeo 06:02 cmake -> Could NOT find Threads (missing: Threads_FOUND)
taxilian 06:02 Hmm. Weird
Could try restarting your shell
doppiabeo 06:02 osx
raffaello 06:02 hi!
a quick question..
i'm trying to download a file from the plugin i'm developing
but i can't figure out how can i download it after i created the stream..
i has a look to both the plugin sample and the help online
i had a look to both the plugin sample and the help online
and i'm trying to download the file using a custom stream handler
which inherits from DefaultBrowserStreamHandler
but i receive only onStreamCreated event
is this the right way?
doppiabeo 06:02 CMake Error at /Applications/CMake (MESSAGE):
Could NOT find Threads (missing: Threads_FOUND)
:D maybe found
wait I'm gonna tell you
raffaello 07:02 solved :)
my big mistake
saiaman 07:02 hello, i've got a question : i want to prevent some sites from using my plugin, i'm checking it with an http request with referer header. Is it possible to prevent registering methods if website is not allowed ?
doppiabeo 08:02 no ... doesn't work!
still got the "Could NOT find Threads (missing: Threads_FOUND)"
taxilian 08:02 doppiabeo: Very odd
doppiabeo 08:02 don't understand... :P
using default env
taxilian 08:02 saiaman: Use host->getDOMWindow->getLocation()
doppiabeo: I have never seen that... I dont know either
doppiabeo 08:02 the full error is:
CMake Error at /Applications/ (MESSAGE):
Could NOT find Threads (missing: Threads_FOUND)
taxilian 08:02 I really have no idea :( i use 2.8.4 on mac and it works
What fb ver?
neilg_ 08:02 doppiabeo: You did do "git submodule update --recursive --init
" right?
doppiabeo 08:02 ?
maybe no
taxilian 08:02 Try updating submodule. Worth trying
doppiabeo 08:02 no way
taxillian: did you download the dmg?
I did...
taxilian 08:02 Yes
doppiabeo: Dont understand. Did you try updating submodule?
doppiabeo 08:02 yes
but didn't work
taxilian 08:02 Hmm
doppiabeo 08:02 I pasted the line above in my terminal in the FB_ROOT directroy...
taxilian 08:02 You got fb from git?
zmichl 08:02 taxilian: hi
taxilian 08:02 Gotta run to the dr, guys. I will be on late
Maybe in an hour to an hour and a half
zmichl 08:02 taxilian: so now I can call FB methods from BHO that returns some simple type value (like bool). But I don't know how to import FB::VariantList that I use?
doppiabeo 09:02 yes i got fb from git
git clone git:// -b firebreath-1.4 firebreath-1.4
doppiabeo 09:02 solved
erased the whole dir
raffaello 10:02 hi..
which is the right way to alert the main plugin when an async download is ended?
taxilian 10:02 rafaello: you could do it in several ways; one would be to keep a weak_ptr to the plugin in your async download class
doppiabeo: did you ever try just deleting the build dir? sometimes that fixes things too. glad you got it figured out
taxilian 10:02 zmichl: that's very much not a simple question. FireBreath was never intended to be used across a DLL boundary
I guess you could include ScriptingCore and PluginCore in your BHO
but you'll have to be careful to maintain binary compatibility
zmichl 10:02 taxilian: yes, I tried to include header files from FB, it compiles now, but crashes. I need to do more research what's wrong :)
taxilian 10:02 you'll need more than just headers
I'm surprised it compiles
I guess you can get it across the dll boundary, so that makes sense after all
the problem you likely have is that since it is created by the plugin, it has to be released by the plugin
so if your BHO tries to release something that was allocated on the plugin's heap you'll have a problem
zmichl 10:02 taxilian: I have another question. Do you think that I will be able to use callback from FB back to my BHO?
taxilian 10:02 hypothetically I'm sure it's possible; again, you have the memory management issues
you'll almost need to build your own API for passing things across
and add a proxy on the FireBreath side
but if you can solve that, it should be possible to do that
neilg_ 10:02 Hmm. I think I messed something up. lol What command should I be doing to switch from the 1.4 branch to the 1.5 branch (which I assume is master?)
taxilian 10:02 neilg_: when you do "git branch" is master listed?
neilg_ 10:02 No... At least it wasn't. I got it to list master in the end but "git pull" did nothing
So I think I messed something up :)
zmichl 10:02 taxilian: ok, thanks
taxilian 10:02 neilg_: okay; do git branch -D master
that will delete the local master branch
then do git checkout -b master origin/master
that will create a local branch that tracks origin/master
neilg_ 10:02 Awesome! That worked. And is pretty much what I did too - but I think one of my previous attempts messed something up. Anyway, thank you!
taxilian 10:02 hehe. yeah, git remotes and branches are awesome, but it does take a little orientation at first
so you're taking the plunge to 1.5, huh? =]
good plan
btw, if anyone is interested in pimping their git setup, here are the aliases that I use:
also at the bottom is a comment for a PS1 (unix prompt) that I set
that makes it so that whenever you're in a directory with is part of a git repo it'll show you on the prompt which branch is currently selected
which IMO is about the most useful thing I've learned this year
neilg_ 10:02 Yes, I'm totally switching to 1.5. Since we're doing Mac stuff it makes sense - plus I've rarely found issues with Firebreath. And nothing that wasn't easily fixed!
taxilian 10:02 wish I could say the same ;-)
of course, easy always seems to be a relative thing... =]
neilg_ 11:02 Well, sure. But my biggest problem was with the browser streams back on 1.2->1.3 and once I'd figured out the problem the three of us solved it pretty quickly
One of the reasons I like FB so much :)
taxilian 11:02 =]
taxilian 12:02 how is everyone feeling about the stability of 1.4?
do we think we need another RC, or should I just release it?
neilg_ 12:02 I found it worked just fine
I didn't notice any problems with it (which is why I was fine with upgrading to 1.5...)
taxilian 12:02 1.5 has relatively little in it that is new, to be honest
and still fairly little planned
1.4 is a huge release
neilg_ 12:02 Sure, but my point was that 1.4 seemed very stable. If I'd have had big issues it would have put me off - but other than the (documented!) breaking changes... it all seemed fine
taxilian 12:02 how are the (documented) breaking changes in 1.5, btw?
neilg_ 12:02 It seems to be fine other than ${PLUGIN_INCLUDE_DIRS} - I added it to my set of include directories but that didn't work
Using a completely separate include_directories() command works for that but it's not finding my own includes now. Just trying to figure that out!
taxilian 12:02 huh
that's weird
neilg_ 12:02 Oh, I am stupid. Stupid, stupid, stupid.
taxilian 12:02 lol
what was it?
neilg_ 12:02 Figured it out now. This is an entirely new source tree and our headers are brought in via an internal tool (because Boost kills SVN performance!). And I forgot to run that tool for this checkout
So, quite correctly, it couldn't find the headers because they weren't there...
That'll teach me for looking at the old checkout in Finder... :)
taxilian 12:02 lol
why don't you just keep the source trees seperate and then you don't have to worry about firebreath being in svn?
neilg_ 12:02 Hey, I do have a question for you (or anybody who may have some insight). How do you deal with proxy authentication if you're trying to make connections from within the plugin?
taxilian 12:02 I assume that you can't use browserstreams?
neilg_ 12:02 We'll actually be doing that soon, I just need to upgrade all of the build servers to have git - and then update the build scripts to use it
Unfortunately not, we could do that to upload/download data - but this part is for playing multiplayer games
We have it working over proxies now (which is pretty cool!) - but we now have to deal with authentication
taxilian 12:02 if you can't get it from IE, I don't know of a good solution
neilg_ 12:02 Right, that's pretty much what I'd figured. And since we're also supporting the mac - we need a good solution. Looks like we'll need to dynamically bring up a box on the page when we get a 407 error
taxilian 12:02 there is a new(ish) NPAPI function for getting that info
but I haven't played with it yet
NPN_GetValueForUrl or some such
neilg_ 12:02 That's very useful, thank you!
taxilian 12:02 doesn't help you on IE
neilg_ 12:02 Do you know if there's a way to get it through IE?
dan2 12:02 taxilian, I've got al inking problem
it doesn't appear to be adding the API*.cpp to the build
taxilian 12:02 neilg_: if there is, I don't know it
neilg_ 12:02 Thanks Richard :)
taxilian 12:02 dan2: that sounds like a cmake project issue
dan2 12:02 correction it is, but it doesn't link no matter what order I put it in
particularly concerned that the last part is not found
I haven't implemented the mixer functions yet
taxilian, theoretically those functions should be implemented in
and conversemixer is in libconverse.a
taxilian 12:02 I have no idea; there is too much going on that I don't know anything about
your cmake files, your other classes, what is being included from where, etc
dan2 12:02 the problem is likely because the plugin itself is a shared library
taxilian 12:02 that's possible, but I've linked static libraries into a .so before and it worked fine
dan2 12:02 that logic doesn't work here
this is a static library looking for a share lib dependency
then building a shared executable
which library is JSAPI defined in?
neilg_ 12:02 ScriptingCore
dan2 12:02 k, well that's included
not sure why it is missing symbols
neilg_ 12:02 Are you on the mac or Linux?
I'm assuming Linux given I saw mention of .so files - so I'd be using objdump -x if I were you
taxilian 12:02 dan2: what order are you linking things in?
let'se see… it's on here
you are using system boost, I see
dan2 12:02
libconverse.a depends on the symbol makeVIdeoWindow
which is defined in the plugin
taxilian 12:02 I think this is a problem related to link order
I don't understand fully how it works; every time I think I have a handle on it something proves me wrong
but with GCC if the dependencies are linked in the wrong order you'll get things that didn't link in because when it did the actual link it didn't know it would need that library
dan2 12:02 the link order is correctI'm fairly certain
there is no way the static library should be after the symbol..
but I can try
taxilian 12:02 I could be wrong, but every other time I've seen a case where we had link errors for missing symbols but everything that needed to be linked in was linked in, it was always an order issue
dan2 12:02 didn't work
taxilian 13:02 what didn't work?
dan2 13:02 putting the shared in front of the static
I need a way to make a static library for the plugin
taxilian 13:02 dan2: I still think it's an order issue; you could even try adding ScriptingCore a second time somewhere, just for testing
physicsrob 13:02 hello
dan2 13:02 it doesn't appear to be scriptingcore
taxilian, it can't find the vtable for ConversePluginAPI
taxilian 13:02 ahh, I see in the second one
I misread
hang on...
what I would do, personally
is move your API classes into another (new) project
then you can link against it from both the plugin and the other place you need it
hey, physicsrob
how is that ugly hack going?
dan2 13:02 taxilian, yuk
taxilian 13:02 dan2: and making hte plugin a static library would be better??
physicsrob 13:02 it's going well -- now I'm just trying to get windowless plugins to work in windows
dan2 13:02 having the plugin be a static library and a shared library would be better
taxilian 13:02 err, if you say so
of course, that gives you two different copies of the same thing if you're linking both a static and dynamic version of the same library together
but if that's cleaner to you, it's your plugin
or maybe I just don't understand what you're trying to do
physicsrob: yeah, aren't those fun?
physicsrob 13:02 taxilian: do you know if invalidatewindow should work correctly? It doesn't seem to be (or I'm missing something)
taxilian 13:02 on 1.4? it should, AFAIK
physicsrob 13:02 I invalidate the window but it never redraws
taxilian 13:02 you could step through it and make sure it's doing what it should
how are you trying to draw?
physicsrob 13:02 I'm drawing with the getHDC() in onWindowRefresh
taxilian 13:02 hmm. well, trace through invalidatewindow and see if you can figure out what it is doing
physicsrob 13:02 and it appears to be working -- if I drag the window off screen and back it ends up getting drawn
taxilian 13:02 huh. this is a busy place lately
I like it =]
phsicsrob: yeah, I'd step through the invalidatewindow function and make sure it's plumbed correctly
I thought it was, but I may have missed something
I haven't really used it much yet
dan2 13:02 taxilian, really crappy workaround, but I inlined the destructor and the function in question and it links properly now
taxilian 13:02 huh. well, whatever works, I guess :-/
dan2 13:02 I'm certain it is because it is a shared library
if this was designed in such a way that the API*s were a static library, and the plugin was shared
and linked to that
it would solve this whole problem
taxilian 13:02 …right… that's what I suggested and you said "ick"
dan2 13:02 no
you suggested making another project
and putting it somewhere else
taxilian 13:02 I aparently explained myself poorly
I'm used to thinking in terms of visual studio
in vs, every target is a project
so that's what I meant; put the API objects in a static lib target, seperate from the plugin target (as in only in the static target, not in the plugin one)
and link that way
dan2 13:02 then I'll still have to back and figure out the proper link order for that static lib if I link like that
physicsrob 13:02 taxilian, IOleInPlaceSiteWindowless::InvalidateRect gets called, but it doesn't trigger an onWindowRefresh. Any ideas?
taxilian 13:02 not a clue :-/
in my tests it did
physicsrob 13:02 hmm
taxilian 13:02
dan2: true, but it would probably be easier than trying to link back to a shared lib; I have no idea how that works in the linker
dan2 13:02 taxilian, now when I run fireevent, it hits javascript method in like the global scope right?
taxilian 13:02 physicsrob: try changing the InvalidateRect call to (NULL, TRUE)
actually, it probably should be NULL, FALSE
physicsrob 13:02 ihmm
right now I'm checking the return value to see if the call is working
taxilian 13:02 dan2: negative; when you run fireevent it hits whatever javascript method was passed in to attachEvent or addEventListener regardless of where it resides
dan2: that might be the global scope, but it doesn't have to be
dan2 13:02 taxilian, ok, so browser javascript needs to register its methods with the plugin?
taxilian 13:02 physicsrob: for some reason I get coordinate changes on IE a lot; I'm wondering if some of them are spurious
dan2: correct
dan2: there are two ways you can do that; one is with attachEvent (ie) or addEventListener (NPAPI), the other is with obj.onevent = function() { .. }
the first allows multiple handlers, the second only allows one
dan2 13:02 the last one requires that I register an event first in the plugin?
taxilian 13:02 all of them do
dan2 13:02 ok
taxilian 13:02 well, technically it'll still work on firefox, but not on IE
dan2 13:02 where is FB::variant_list_of?
taxilian 13:02 #include "variant_list_of.h", I think
ahh, nope
#include "variant_list.h"
dan2 13:02 k
physicsrob 13:02 taxilian: IOleInPlaceSiteWindowless::InvalidateRect is returning E_UNEXPECTED. I'll try using NULL
taxilian 13:02 ok
actually we should probably do NULL, FALSE, rather than TRUE, since TRUE erases the background and we may not want to do that
physicsrob 13:02 how is the background defined in this context?
taxilian 13:02 the area inside your rectangle
whatever happens to be there
if I understand the docs correctly
physicsrob 13:02 then why wouldn't we want to erase that?
invalidate that rather
taxilian 13:02 there is a difference between invalidating that and erasing it
physicsrob 13:02 Ah, I see
taxilian 13:02 invalidating it means we will get a draw event
erasing it means it will wipe the background before that draw event
you may not want that to happen
physicsrob 13:02 right.. so probably would result in a flicker
taxilian 13:02 potentially
but not neccesarily
in fact I'd say probably not
since it'd all be part of the same draw call
dan2 13:02 taxilian, so, onVideoWindowCreationEvent?
taxilian 13:02 all lowercase
physicsrob 13:02 this should be thread safe, right? I'm calling InvalidateWindow() from a different thread
taxilian 13:02 phsicsrob: yes, it is threadsafe
physicsrob: hmm. well, not as threadsafe as I was thinking, actually; it probably isn't causing you issues, but let me look at some things
physicsrob: in fact, I found your issue
and I will try to fix it. hang tight
physicsrob 13:02 cool
I'm not having any luck on the NPAPI browser either, FYI -- just trying to tackle IE first
kylehuff 13:02 that is the dirtiest thing I've heard said on IRC or IRL.
oh, you said tackle, not tickle
=c )
physicsrob 13:02 hehe
taxilian 13:02 physicsrob: yeah, I wasn't handling either of the coordinate systems correctly
worth reading probably for all of us: interesting review of google's new native client (NaCl)
physicsrob: just doing some quick testing before I commit this
physicsrob 13:02 cool thanks
taxilian 13:02 thanks for catching it before I released 1.4 =]
physicsrob 13:02 yeah -- I've been keeping an eye on NaCl.. I don't think it's going to be a viable solution for my product in the next few years
but it's an awesome concept
taxilian 13:02 agreed
physicsrob: try that, let me know if it helps
FB_GitHubBot 13:02 FireBreath: firebreath-1.4 Richard Bateman * 2fcc76b (3 files in 1 dirs): Serialize PluginWindowlessWin calls, fix invalidate -
neilg_ 14:02 I'll admit that I haven't googled for this yet - I'm about to. But I don't want CMake to generate Xcode projects for x64 right now - I link against libraries which are i386 only. Is that easy to change from within CMake?
taxilian 14:02 yeah; I wouldn't google it, though, I'd look at the prep script page on the wiki
random fact for the group: FireBreath 1.0 was officially released on March 24, 2010; exactly 11 months ago today
neilg_ 14:02 Oh. I was looking at the building on Mac OS X page on the wiki... I apologise!
dan2 14:02 taxilian, on window detached, does the window handle become invalid?
taxilian 14:02 dan2: you should assume that it does, yes
dan2 14:02 ok
taxilian 14:02 how soon it actually does depends on the browser
dan2 14:02 just checking
neilg_ 14:02 I've edited the wiki for people like me so hopefully you won't get bugged with silly questions like that in future. :)
taxilian 14:02 neilg_: thank you sir, you are a scholor and a saint
obviously I'm not, since I can't spell "scholar"
kylehuff 14:02 haha; my grandfather used to say that
I haven't heard that in years
neilg_ 14:02 Isn't that a quote from Blackadder?
taxilian 14:02 oh, it's an old expression
kylehuff 14:02 he also used to call me "squire"
taxilian 14:02 I could run sed on the logs and change your name to squire in all the logs if you want
neilg_ 14:02 Well, the expression I know is "You are a scholar and a gentleman" - that's all. :)
taxilian 14:02 neilg_: you know how much better the docs would be, though, if everyone did that? every time they couldn't find something, they added or put a link to the information when they did find it?
neilg_ 14:02 (But I have heard your version many times before too, I just thought it was a quote from Blackadder!)
taxilian 14:02 never seen it, but I'm pretty sure the expression predates it by quite a bit =]
neilg_ 14:02 Well, hopefully I've started off a new wave of wiki editing :)
taxilian 14:02 that would be nice
FB_GitHubBot 14:02 FireBreath: firebreath-1.4 Richard Bateman * 78c12eb (2 files in 2 dirs): Fixed issue #147 staticInitialize not called on IE -
FireBreath: master Richard Bateman * b82ede7 (2 files in 2 dirs): Fixed issue #147 staticInitialize not called on IE -
physicsrob 14:02 taxilian: can one plugin ever encounter multiple PluginWindows?
neilg_ 14:02 In its lifetime, yes
Oh, wait, that's not useful. You're talking about the class
I don't believe so in that case. You get one per plugin instance
Knowing that it handles windows messages, I'm pretty sure that's going to be the case
physicsrob 14:02 what's the best way to gain access to the PluginWindow outside an event handler (e.g. from a different thread)?
neilg_ 14:02 I'd try to avoid that, there's no thread-safety mechanisms built in
What are you trying to do?
physicsrob 14:02 I update what needs to be displayed in my plugin from a different thread. In the past I just used a timer that polled to see if something had changed, and ran InvalidateWindow() from the onTimer(). Now I'm making my plugin support windowless mode, and it's not easy to create a timer
plus it just makes more sense to asynchronously invalidate rather than poll
neilg_ 14:02 I'm assuming this isn't on Windows?
physicsrob 14:02 it is on windows
neilg_ 14:02 Then you could just pass the HWND through to your other thread from your plugin and render directly
physicsrob 14:02 it's windowless, so there is no HWND, and the issue isn't rendering, it's invalidating.
besides that's equivalent to what I was saying -- what's the best way to gain access to the PluginWindow outside an event handler
dan2 14:02 where is X11/PluginWindowX11.h defined..?
taxilian 14:02 physicsrob: you can call getWindow on the plugin object
dan2: in PluginAuto
physicsrob: Just make sure you have a mechanism that warns your other thread that the pluginwindow is gone when DetachedEvent is fired
physicsrob 14:02 taxilian, awesome. thats way less ugly.
taxilian, by the way, that commit didn't fix things
I still get E_UNEXPECTED
taxilian 14:02 physicsrob: I haven't a clue, then :-/ does passing NULL instead of the coords work?
physicsrob 14:02 nope
dan2 14:02 taxilian, man, we've really got to do something about these out of tree builds
taxilian 14:02 dan2: talk to me after you've looked at 1.5's cmake updates
neilg_ 14:02 taxilian: I'm on FB 1.5. I'm running and passing in WITH_SYSTEM_BOOST and my BOOST_ROOT. I'm getting some strange CMake errors when I do this
-- Found the following Boost libraries:
-- date_time
CMake Error at src/ScriptingCore/CMakeLists.txt:99 (export):
export given target "optimized" which is not built by this project.
dan2 14:02 taxilian, I'm sure it doesn't solve the problems I'm having right now
taxilian 14:02 dan2: what problems are you having?
dan2 14:02 taxilian, finding all these damn include directories and such just to build this
taxilian 14:02 neilg_: hmm. I didn't test that; you may need to go into that file and add a check for WITH_SYSTEM_BOOST
dan2: should fix that, or at least make it easier
dan2 14:02 where is global/config.h?
taxilian 14:02 in src/
oh, wait
it's a generated file
dan2 14:02 and there's my point
taxilian 14:02 dan2: please look at 1.5
dan2 14:02 I have to get a demo done first
taxilian 14:02 I have already addressed your issues as best I know how, and until you finally switch over to it I won't know if it helped
but every single item you've complained about is there
and it's not hard to switch to
dan2 14:02 hmm
taxilian 14:02 you should just have to set a couple of variables and add_subdirectory FB_ROOT
dan2: well, it still uses configure_template
but it has build directories specified so you can do out-of-tree
and the variables are all prefixed so you shouldn't have conflicts
dan2 14:02 taxilian, ok, but I don't see how this automatically allows me to get the header include directory for that plugin?
taxilian 14:02 you need this outside the plugin?
or inside?
meaning the plugin CMakeLists.txt file
dan2 14:02 well I have parts of my application that communicate with the plugin, which need plugin headers, e.g. being able to grab the window handle
taxilian 14:02 you should be able to just set a couple of variables and include
of course, options you could just pull out yourself
dan2 14:02 I'm already including common.cmake
taxilian 14:02 anyway, the variables are prefixed, so it shouldn't be hard to use those files externally if you needed to
dan2 14:02 I need to generate the path to the generated include directory
taxilian 14:02 well, if you used 1.5
you could add FB_ROOT with no projects
and then include the projects seperately
and if you set the variables for FireBreath right
dan2 14:02 and that's going to contain global/config.h?
taxilian 14:02 it would put the projects wherever you want
FB_PROJECTS_BINARY_DIR is the variable that holds the plugin projects by default, though
so if you have that variable, it's just that/<plugin name>/gen
I'm sure you can hack that into whatever your setup is right now, though
it's up to you… I really think that you're making your whole config way harder than it needs to be, though
but whatever works for you
so to be clear, I was getting mixed up; I was thinking FB_CONFIG_DIR had what you needed
it doesn't, sorry
what you need is normally stored in <build dir>/projects/<plugin name>/gen
if you run firebreath normally
dan2 14:02 I think I need to check with cmake guys to see if there is a way to export variable names up the food chain
taxilian 14:02 there is
dan2 14:02 yes, but is there a way to export all the includes of a target?
taxilian 14:02 includes? includes aren't specific to a target
dan2 14:02 include_directories
relatively speaking they are
taxilian 14:02 no, they are specific to a scope
the question is whether you can get those into a variable or not...
and that is an interesting quesiton
dan2 14:02 are you setting any variables that have all the include directories?
for a given plugin?
taxilian 14:02 in 1.5, yes
in 1.4 no
dan2 14:02 ok
I'll comit
remove, reinstall
taxilian 14:02 it shouldn't be that hard
dan2 14:02 1.5 isn't like really broken right?
taxilian 14:02 no
there are only a couple of changes
and they seem pretty solid
I dont' put anything that is really broken in the trunk, at least not intentionally
my own plugin projects use the master branch, so I have to keep it working =]
dan2: however, FYI, you can get_directory_property(VARNAME <directory> INCLUDE_DIRECTORIES) should give you the include directories in that scope
physicsrob 14:02 taxilian, is there any support for timers in windowless plugins yet?
taxilian 15:02 physicsrob: not directly, but you could create a WinMessageWindow
look at src/PluginCore/WinMessageWindow
physicsrob 15:02 ok.. I'm not sure if I need it yet, but it's nice to know that at least part of it has been abstracted
taxilian 15:02 just instantiate it and it will give you a HWND that you can use for sending messages or timers; you'll have to change the winproc, though
well, not really =] but it gives you an HWND that you can use
timer abstraction is on the list, but we haven't come up with a good way to do it yet
physicsrob 15:02 well if I can InvalidateWindow from a different thread I don't need it
taxilian 15:02 dan2: for breaking changes info
physicsrob: you can
just make sure you don't try to access it after DetachedEvent
physicsrob 15:02 you don't think that's my problem right now?
taxilian 15:02 no
if you were doign that it would crash
physicsrob 15:02 m_spInPlaceSite->InvalidateRect is returning E_UNEXPECTED
taxilian 15:02 yeah, I don't know
dan2 15:02 taxilian, not sure that directive seems to be working..
taxilian 15:02 the directory_properties thing? I've never actually tried it, just saw it in the docs
so I don't know :-/
dan2 15:02 ok, so what I needed to do was rearrange the order, use that get_directory_properties inside the plugin dir, then do a set from that variable to PARENT_SCOPE
taxilian 15:02 ahh
physicsrob 15:02 taxilian: It is a threading issue. If I call InvalidateWindow from an event handler everything works fine
from a different thread I get E_UNEXPECTED
taxilian 15:02 oh… I see what is happening
I will need to fix that for 1.5
but in the mean time
use host->ScheduleOnMainThread
host->ScheduleOnMainThread(boost::bind(win, &PluginWindowlessWin::invalidateWindow)); or something similar
physicsrob 15:02 cool
dan2 16:02 is there any case where onPluginReady would not be called before onWindowAttached?
nice, no guarantee about onPluginReady vs. onWindowAttached
physicsrob 17:02 how can I get a shared_ptr for either my plugin object or the plugin window? Any tips?
taxilian 18:02 physicsrob: use shared_from_this
dan2: yes, the order of those two varies depending on the browser, unfortunately
physicsrob: just be careful not to create a circular reference
anyone want to buy a used 17" 2.8Ghz core 2 duo w/ 8 gig ram macbook pro?
dan2 18:02 taxilian, SetWindow is called BEFORE onWindowAttached right?
taxilian 18:02 dan2: setwindow causes onwindowattached
dan2 18:02 ok if I use GetWindow()
in the onwindowattached method
is it safe?
taxilian 18:02 yes
dan2 18:02 ok, perfect
taxilian 18:02 the window is also passed in to the handler as a parameter.../
dan2 18:02 I'm aware
but I have redundant code between onPluginReady
and onWindowAttached
taxilian 18:02 okay
dan2 18:02 that I would prefer to consolidate
taxilian 18:02 makes sense
I have considered forcing the order to always be the same; it would involve delaying onwindowattached in some cases
dan2 18:02 I am also make an assumption that onWindowDetached will always be called before the destructor correct?
taxilian 18:02 yes
if it ever doesn't, file an issue, it's a bug
dan2 18:02 ok
why do onWindowAttached and such return boolean?
taxilian 18:02 some events we need to indicate if they were handled or not
so that they aren't passed on to the system
windowattached is not one of them, but they all use the same system
dan2 18:02 so I should just return true in all cases eh?
if they're handled
taxilian 18:02 probably
physicsrob 18:02 taxilian, if I do MyPlugin::MyMethod() { m_host->ScheduleOnMainThread(shared_from_this(), boost::bind(&MyPlugin::MyOtherMethod));} I get a ton of boost compilation errors. Any thoughts off the top of your head?
taxilian 18:02 that means your method signature doesn't match what you gave it
physicsrob 18:02 The first being: y:\documents\workspace\firebreath\src\3rdparty\boost\boost\bind\bind.hpp(69): error C2825: 'F': must be a class or namespace when followed by '::'
taxilian 18:02 which makes sense
because you need to provide the object to run the method on as part of bind
physicsrob 18:02 oh
taxilian 18:02 so boost::bind(&MyPlugin::MyOtherMethod, FB::ptr_cast<MyPlugin>(shared_from_this())) might work
if it doesn't expect any parameters
physicsrob 19:02 taxilian, thanks again
that did the trick
taxilian 19:02 physicsrob: any time you see lots of weird boost::bind errors that's probably what it is; unmatched parameters
amackera 20:02 hey guys :D
taxilian 20:02 amackera!
a voice from the dead
amackera 20:02 i'm heeere
taxilian 20:02 how are things?
amackera 20:02 getting back to normal
sorry i've been on vacation for a bit :|
taxilian 20:02 wow. that's a scary thought =]
hehe. was it fun?
amackera 20:02 it was pretty good, it's been a little tough settling back into work
how close are we to 1.4? is it out?
taxilian 20:02 it's pretty close; I did a few bugfixes today, trying to decide if I should just release it or if I should put out an RC2
amackera 20:02 hmm
where do we keep out issues? gcode?
taxilian 20:02 yes
keep meaning to set up Jira, keep not having time
amackera 20:02 nothing serious
on the list i mean
taxilian 20:02 yeah; the one issue that I do know of is that if you move something around in the dom on IE it can crash the plugin
amackera 20:02 hm that's bad
taxilian 20:02 it's a really weird edge case
but it is still a crash
amackera 20:02 what do you mean move it around in the dom?
and which IE?
taxilian 20:02 probably any IE
the case we saw it was you create a div with document.createElement, then you add the object tag to the div (before injecting it into the dom). it creates the plugin right there
then you inject it into the dom and everything explodes in a giant fireball
amackera 20:02 harsh :|
taxilian 20:02 trying to find a good hack that will just keep it from crashing
and accept that it won't work if you try that
amackera 20:02 hey you want to hear an awesome story ?
taxilian 20:02 let's hear it
amackera 20:02 we are thinking of supporting IE on our site (we don't even support any IE right now :S)
we make people install chrome frame :P
but chrome frame is breaking recently so we want to start supporting IE
taxilian 20:02 lol
amackera 20:02 i haven't even tried out our plugin in IE in a loooong time
and last time i did it crashed :S
but this time i loaded it and everything worked perfectl
so basically firebreath rules
taxilian 21:02 hehe. like, even the windowless stuff?
amackera 21:02 hmm i didn't test windowless, good idea :D
taxilian 21:02 ahh, okay
I committed a fix for invalidating windowless earlier today
amackera 21:02 really?
I think the invalidating in mac is wrong too
i have a commit for that
taxilian 21:02 I fixed that the other day
physicsrob reported it
(hey, rob)
so I bought a shiny new macbook pro today
now I need to sell my old one
amackera 21:02 sweet!
taxilian 21:02 core i7, 2.3Ghz… yeah, that's definitely an appropriate word =]
at least until I get the credit card bill…. :-P
amackera 21:02 that is a beast :D
taxilian 21:02 it's only got 4gb of ram, but I already ordered 8gb to put in it
it's a little early to tell, but it feels blazing fast… and since I'm coming from a 2.8ghz core 2 duo w/ 8gb of ram, that's pretty fast
to be noticable
amackera 21:02 kicks the hell out of my little white macbook :P