|IRC Nick||Time (GMT-7)||Message|
|jshanab_wcw||07:02||I am jumping from 1.2 to 1.4 on an existig project and am trying to figure out what I need to change. i figure there are changes to the generated files to match the new version and since I am not regenerating, i will have to make changes. (wow, that would be a cool prep feature). The first one however is an error thrown trying to compile variant.cpp, which came in the new 1.4 right?|
|iaincollins||07:02||jshanab_wcw: for me, I found it easier to create a new blank project with the same base information and add my classes and properties to the new skeleton project (not that there were many differences, just didn't want to miss something subtle)|
|jshanab_wcw||07:02||I am diffing now against a project I created...LOL, i called it Skeleton :-) The part that is odd is that the file not compiling is not pert of the project, it is part of the firebreath|
|taxilian||07:02||jshanab_wcw: yes, if you are getting an error in variant then you're trying to use a data type that isn't valid
figure out which datatype it is
and you've found your problem
most likely you're trying to use a JSObject instead of JSObjectPtr
see version history for a list of breaking changes
got some question about installing plugin
is there a way to make a setup for all user instead of current one only?
|jshanab_wcw||08:02||Thanks. i am reading the version history, but i was not sure where that directed me in my code as the compile errors were in the FireBreath directory and not my project. But I am REdoing everything on the update because of last nights issues with gethub, i may have missed something in all my copying around|
|jshanab_wcw||08:02||I have a redefinition error on the int8_t type because there is a stdint in a header I include and a fb_stdint.h :-( both are headers that don't belong to me. ( i thought include guards took care of this kind of issue). Is fb_stdint.h new?|
|jshanab_wcw||09:02||How do i handle this issue. pragma once is not an include guard, it uses the whole path+filename and since the fb_stdint.h and the one deep in the avcodec includes has the name stdint.h, it gets included twice. this breaks the build because the typedefs try to run twice. looks like I would have to change the headers in either FireBreath or Libavcodec :-(|
|taxilian||09:02||pq_H: yes, there is a setting in PluginConfig.cmake|
|iaincollins||09:02||oh really? that's cool|
|taxilian||09:02||jshanab_wcw: include guard should cover that; not sure why it isn't. yes, fb_stdint.h is new
pq_H: if you look in your PluginConfig.cmake file (assuming you're using 1.4) you'll see: # If you want to register per-machine on Windows, uncomment this line
#set (FB_ATLREG_MACHINEWIDE 1)
|jshanab_wcw||09:02||They don't use include guards, they use pragma, which generates a key off the filename and I hear the path. Since the filename is different, it considers them differnt and tries to include them both. I am not sure about the path part, but I generally replace prama with include guards when I can.|
|taxilian||09:02||they should be using an include guard that checks to see if the stdint stuff is already defined
if they aren't, you'll probably need to add it
|jshanab_wcw||09:02||taxilian. let me try renaming it|
|taxilian||09:02||sure, but I'd be shocked if it helped|
|jshanab_wcw||09:02||these includes are identical. but pragma just doesn't work the same as a real include guard. Suppose to be faster :-)
well, not identical...
I have a deadline and this update to 1.4 is killing me, can I do without fb_stdint.h?
Or do I add your guard to the other library so it sees it as already loaded?
Ah ha! both do have guards, but they have different names.
i have question about FB events
when I generate plugin by fbgen.py and open FBControl.htm, everything is ok
but when I change "pluginLoaded" in FBControl.htm to another name that doesn't exist, then plugin crash
|pq_H||09:02||taxilian: thanks, reading just now|
|zmichl||09:02||firefox-bin: /home/zmichl/ffdnssec/dnssec-plugin/plugin/FireBreath/src/3rdParty/boost/boost/smart_ptr/shared_ptr.hpp:418: T* boost::shared_ptr<T>::operator->() const [with T = FB::JSObject]: Assertion `px != 0' failed.
|pq_H||09:02||taxilian: though I'm using 1.3 as now. Will that work on 1.3 too?|
it's new in 1.4
|taxilian||09:02||zmichl: what version are you on?
pq_H: 1.4 will be out before you release anything; it's pretty close to RC anyway
just use 1.4
|zmichl||09:02||taxilian: Date: Wed Jan 5 15:25:17 2011 -0700|
|taxilian||09:02||I think tha'ts a bug we fixed already
if updating doesn't fix it, please file an issue
|zmichl||09:02||taxilian: I use it becase I had some issues with newer ones|
if you have issues with the newer ones, don't use the old ones… tell me what the issues are so I can fix them =]
|zmichl||09:02||some compilation issues as far as I remember|
|taxilian||09:02||well, they should be fixed now
as far as I know there are no major blocking issues
just the chrome issue and anything reported
so if there are things I don't know, please report them =]
I still have the flu and picked up an ear infection besides today, so I'm headed to the dr
but I'm more concious today, so I can do some minor fixes if need be later this afternoon
|zmichl||09:02||i didn't have time to play with it, I needed to compile my plugin :)
i'll try the newest commit next week ;)
|taxilian||09:02||=] well, that fix should be in there. so you can either fix it yourself (find that line and add a check for validity before calling it) or update =]|
|zmichl||09:02||ok, I need to go, bye!|
bbl, headed to the doctor
|jshanab_wcw||09:02||Anyone have the issue where it cannot find win_common.h because np_winmain.cpp has the "include Win/win_common.h" even thought win_common.h is in src/config?|
|amackera||09:02||I believe that "Win/win_common.h" should be just "win_common.h"
that's a breaking change in 1.4
There are a few other breaking changes for moved files
see the "Files Moved" section
|jshanab_wcw||09:02||oh, so np_winmain.cpp was generated, duh.. thanks|
|amackera||09:02||np_winmain.cpp was probably generated by fbgen.py, yeah|
|jshanab_wcw||09:02||I seem to be getting around my stdint.h problem by modifiny the header guards in the avcodec includes, but if someone has a more elegant solution i would like to here it. seem to becuse it hasn't built and ran yet since the upgrade...|
|jshanab_wcw||10:02||FYI Plugin built and ran. I modified the include guard in the avcodec's stdint.h|
Good news, I'm back on working with Firebreath again. This time on the mac!
|taxilian||12:02||jshanab_wcw: you can also just remove np_winmain.cpp and dllmain.cpp from your project as of 1.4
they are optional
neilg_: awesome =]
|neilg_||12:02||Are there any good docs or example on rendering using Firebreath/NPAPI on OSX? I figure I can read up over the weekend so I'm not a complete n00b. :)|
|taxilian||12:02||not that I'm aware of|
|neilg_||12:02||Oh dear god, I feel dirty for using l33t speak. And again! Ugh. lol|
we all have our weeknesses
|neilg_||12:02||I guess I'll have to figure it out by trial and error then. It sounds a lot more involved that the Windows method|
|neilg_||12:02||I've learned more about OSX internals and dyld than I ever wanted to in the last couple of months... lol|
|fireplug||17:02||Hi, I have build a firebreath plugin on mac and it works wonderful. however if i try to access and opengl functions. it is crashing.
I am calling glReadPixels(0,0,1,1,GL_RGB,GL_UNSIGNED_BYTE, pix) and the browser crashes here.
|taxilian||17:02||hmm. amackera might be a good person to help you there
I'm not an ogl guy
the drawing model you use is going to make a big difference, though
|fireplug||17:02||any pointers to debug this. can we call opengl/glut apis from browser|
|taxilian||17:02||and you'll really want to create another thread to do all ogl stuff on
|fireplug||17:02||yes i created another thread. that part is ok|
|taxilian||17:02||have you read up on drawing models?
do you know what browsers you want to support?
|fireplug||17:02||firefox/safari on mac
i am testing on firefox now
|taxilian||17:02||have you read this page yet? https://github.com/sitaramc/gitolite/blob/pu/doc/gitolite.conf.mkd#_advanced_access_control|
|fireplug||17:02||no. i have not read this page.|
|taxilian||17:02||read up =] drawing on mac is tricky because there are different event models and different drawing models depending on the browser|
|fireplug||17:02||i will read now. i am trying to get pixel value (RGB) from the above mentioned api|
|taxilian||17:02||some of those do and some don't allow you to access AGL|
|fireplug||17:02||i dont want to draw anything, just capture pixels from the screen|
|taxilian||17:02||doesn't matter; you're still interacting with the drawing engine|
|amackera||17:02||i'm here now
one sec to read
so it's crashing on glReadPixels?
have you initialized OGL?
|fireplug||18:02||yes, it is crashing on glReadPixels|
|amackera||18:02||have you allocated memory for pix?|
|fireplug||18:02||yes i have allocated memory|
|fireplug||18:02||but have not initialized any other OGL|
|amackera||18:02||you will need to establish an opengl context|
|fireplug||18:02||initialize OGL? could you please tell me what all needs to be done|
it's a little complicated, what exactly are you trying to do?
|fireplug||18:02||ok. i need to get RGB values of all pixels on the screen|
|amackera||18:02||all pixels being displayed on the screen?|
|amackera||18:02||that's not what glReadPixels does
glReadPixels will give you the pixels in the rendering context
|fireplug||18:02||can that context be the entire screen or part of the screen|
|amackera||18:02||if you render into a rendering context, you can read the pixels out again and see what you've rendered|
|amackera||18:02||the context can be fullscreen, but i suspect that might not be what you want to do
you can't get pixel data from opengl about pixels that you have not drawn
|amackera||18:02||so, for instance, you can't take a screenshot of the desktop from opengl|
|amackera||18:02||you can do that through other means though, i image
Carbon probably has a screenshot API
|fireplug||18:02||ok. do you have the API reference handy|
|amackera||18:02||let me see if i can dig something up|
|amackera||18:02||It looks like CGWindow has something you can use|
|fireplug||18:02||let me take a look at it|
"Son of Grab"
sample code that should do it
I should also say that I may be wrong about OpenGL's ability to capture screenshots
It might be worth looking into
I probably won't be able to help much though
|amackera||18:02||man the bloody OGL windowless rendering code breaks mysteriously on some computers :(|
|taxilian||18:02||yeah; aren't plugins fun?|
|amackera||18:02||taxilian: Can I get your opinion on something quickly?|
|taxilian||18:02||I'm good at quick opinions|
I am trying to figure out how to handle mouse events in my plugin
the trouble is that each mouse move handler is likely to call back into the plugin to change some state of some objects
not a big deal on reasonably new computers
that was badly worded
i mean: you move you mouse, there's a circle that follows your mouse around
old hardware: circle lags behind mouse
Do you know of any common strategies or design patterns that address this?
I'm thinking of limiting the rate of mouse move callbacks to JS
|taxilian||19:02||well, there are two approaches you can take
that's the first, probably the easiest
|taxilian||19:02||the second would be to see if you can identify the main bottleneck on the events and see if there is a way to optimize the speed|
that's pretty much what I had in mind also
|taxilian||19:02||since you're on the main thread it shouldn't be cross-threading issues that are causing you slowdown|