IRC Log Viewer » #firebreath » 2010-12-06

IRC Nick Time (GMT-7) Message
DFUN 02:12 Hi there. Does anybody know how to register a plugin.dll to every browser installed on a system? I want to prepare an installer that does this job but don't know how to set up the windows registry.
_Vi 05:12 How to create a windowless plugin with Firebreath (using firebreath-dev-1.4-nightly-40)
DFUN 06:12 you can set the "IsWindowless"-property to true.
I'm working on a windowless plugin. Under firefox it works fine, under IE there remains a little white box
I think I read of the windowless-feature is still not working for IE. But I'm not sure about that.
in your Plugin-class derived from FB::PluginCore add: bool IsWindowless() { return true; }
_Vi 06:12 DFUN, OK, trying that.
jshanab_wcw 06:12 I want to draw decoded video frames onto the browser. windows for now, mac and linux later. Ther was a post about how to draw on windows that had 3 options, I took the easist for now, but the instructions are a bit vauge. I get unknown symbol PluginWindowWin and when i try to include the header I get cannot open include file. Do I need to change something in the template before typeing prep?
_Vi 06:12 Where should I write my painting code?
How to check that if plugin is really windowless?
DFUN 07:12 hm... I just opened a html file including some plugin code with the IE. It contained a white box which wasn't shown on Firefox
and still does... :s
taxilian 08:12 Lots of people this morning
IE windowless support is not yet working
jshanab_wcw: Look at basicmediaplayer for example of what to include for pluginwindowwin
_Vi: If the plugin is windowless your pluginwindow will be a pluginwindowlesswin
DFUN: Windowless mode on IE does not work yet.
taxilian 08:12 If someone wants to implement windowless on IE it would be awesome
amackera 08:12 Hey all
taxilian 09:12 amackera: people are complaining about no IE support for windowless ;-)
you should, like, totally fix that :-P
amackera 09:12 okay okay okay :P
DFUN 09:12 good "morning", Richard
IF found this link https://developer.mozilla.org/En/Plugins:_The_first_install_problem
for plugin registration
for the protocol
I think it could/should be included to the installer help
done.
ok, bye
taxilian 09:12 *sigh*. Turn my back and forget to check the window for a few minutes....
the built-in WiX stuff already takes care of everything mentioned in that page (that is needed)
I'll just update the wiki stuff he added to clarify
hopefully he'll see it
jshanab_wcw 09:12 what is "windowless" is it like it sounds?
taxilian 09:12 pretty much
it means that you draw to the browser window instead of getting your own
the advantage is that you can participate in the DOM z-order
disadvantage is that it tends to be slower, no hardware acceleration can be used, etc
jshanab_wcw 09:12 Is it for when your plugin doesn't draw anything? just is a javascript API?
taxilian 09:12 you could use it then as well. the latest in the dev branch supports a FB_GUI_DISABLED option that uses windowless mode
jshanab_wcw 09:12 oh, got it
taxilian 09:12 but you can draw with windowless
how's that plugin coming?
jshanab_wcw 10:12 I got to the point where everything built then it was throwing the link errors on all the GDI stuff. Now I am converting the plugin and pluginAPI and my media player to a similar structure of the BasicMediaPlayer example. This may take all day....:-)
When i get it working, it will be properly structured for the Mac and Linux builds in the future.
What is the #define _WIN32_DCOM in the windows media player? does that provide the XPCOM interface tot he javascript?
windows version of MediaPlayerWin.cpp in the BasicMediaPlayer example
taxilian 10:12 jshanab_wcw: I have no idea what that is, but no, it doesnt' define the interface to javascript
if you're getting link errors on GDI stuff that's an easy fix
you just need to add a new link library
no need to restructure your project
basicmediaplayer isn't a bad example, but it's not so perfect that i'd recommend changing the way you do things just to be like it, unless you like the structure better
jshanab_wcw 10:12 I do. Our player was an older windows only player that had two projects that happened to share files. IE and FF only and safari and mac is a future feature requirement. My office mate manually got the existing system to work again (6 days+) now he is trying to figure out how to reproduce it. I am working on the port to firebreath to ensure sanity moving forward!
taxilian 10:12 ok; if you tell me the link errors, though, I can probably tell you how to fix it
I think BasicMediaPlayer may be the only firebreath project that still exists that wasn't created with fbgen.. =]
jshanab_wcw 10:12 I am back to compile errors, having just merged 4 files and resturctured. You know that inital state after a masive cut-n-paste. It will be a while brofre i am building again :-) (Thanks, I will be asking Q's in the very near future )
taxilian 10:12 =]
jshanab_wcw 10:12 I would say we need more examples, but i don't want to paint a target on my back :-)
taxilian 10:12 lol
you'd be totally correct
but I can either spend my name working on weird examples, or I can keep adding features and fixing bugs
therefore, we'd need some hypothetical person to work on some... =]
jshanab_wcw 10:12 At pelco we defined people that made suggestions like that "Pelco Volunteers"
taxilian 10:12 actually, there are a couple (one in particular) open source projects that were made with FireBreath, but nobody has updated them to post-1.2
I keep meaning to, but... =]
jshanab_wcw 10:12 I have been an open source nut and like to contribute, but i keep working for people and companies that need to protect their IP
taxilian 10:12 something about how I haven't even had time to do any actual work (that I get paid for) in the last 2 weeks because I've been trying not to fail any classes
see, that's why FireBreath is the perfect open source project... you can keep your own IP confidential, but still contribute back improvements to the framework. It benefits everyone, since we get the improvements and you get people testing those improvements
it does make examples harder to get, though
but it's totally understandable
jshanab_wcw 10:12 I think once i know something valuable, an example of an "advanced media player" may be doable. But we both know my time schedule...
taxilian 10:12 yeah... you have only slightly more free time than I do. ;-)
we'll get more examples as time goes on
the project has really been growing fast (in userbase) over the last few months
I would give a lot to be able to know how many plugins there are out there that are built on FireBreath
amackera 10:12 You could probably get a pretty good estimate from how many downloads we get around a release
taxilian 10:12 that's true; 'course, hard to know how many of those are people downloading to try it out and how many are using it and updating
amackera 10:12 Yeah true
kylehuff 10:12 or how many of them are using it to build/maintain more than 1 plugin.
taxilian 10:12 right
amackera 10:12 Good point
taxilian 10:12 there have been 188 downloads of 1.3.1
but what does that neccesarily mean? who knows
I'm thinking there are probably a few dozen by now, but that's more a gut feeling than anything.
kylehuff 10:12 so that count does not include people who are currently using -dev, like me...
taxilian 10:12 right
or people who got it from source control
kylehuff 10:12 yeah, me also.
amackera 10:12 I guess it's too inaccurate really to give us meaningful info
taxilian 10:12 and I can't think of a way to do any better
'course, the survey results we got back when had 26 responses, so there have to be at least that many =]
and now more
I'm really thinking that I should create a new survey; one that I can leave up longer
but I don't have time right now
jshanab_wcw 12:12 Is there a maximum number of arguments that the make_method templating can handle?
looks like 10 ?
taxilian 12:12 probably
that sounds right
did you need more for some reason?
there is a workaround
you could use FB::CatchAll
which will catch 0 or more
but then you have to do the conversion yourself
(btw, if you want to get my attention mention my nickname; that makes my chat program flash the window. otherwise, I may not see it 'til later when I think to check the chat window)
jshanab_wcw 12:12 taxilian: Ok, thanks. It looks like the current code arch had another level of redirectioon that got the url, parse it out then called the internal function with 17 arguments. I just nned to do that processing in the ....API.cpp
taxilian 12:12 you seriously are calling a method with 17 arguments? good grief
if it were me, I'd have it pass that in as an array
but you could also create your own version of make_method that supports 17 arguments
jshanab_wcw 12:12 yeah, i know. And i haven't figured out exactly how it gets it yet either
taxilian 12:12 or easiest would just be to use FB::CatchAll and do your own conversion
FB::CatchAll will basically get an array of arguments as FB::variants
jshanab_wcw 12:12 looks like it is passed a string from the javascript, 1 argument that represents a key=value set. Then it is ripped apart. I just need to memic that. I just haven't figured out where the args are in this example
jshanab_wcw 13:12 taxilian. I figured out how the 17 arguments are being passed in the old code, a PARAM is set in the <OBJECT> tag. How do i extract PARAM's in firebrreath? Are they "properties"
amackera 13:12 Youre plugins object should have a variant map of the params given to it in the m_params member
Your plugin*
http://www.firebreath.org/display/documentation/class%20FB%20PluginCore%20m_params#a74050056ee0296ca06cd4605fa25f844
jshanab_wcw 13:12 Thanks!. I was searching the wiki and misspelled params (tail between legs)
amackera 13:12 jshanab_wcw: hehe, no biggie :)
taxilian 13:12 jshanab_wcw: keep in mind that you need to tell the plugin which params it should look for
the easiest way is to add the param names to m_supportedParamSet http://www.firebreath.org/display/documentation/class%20FB%20PluginCore%20m_supportedParamSet
jshanab_wcw 13:12 I want the m_params available in the "API" generated by the fbgen, but the plugin has a api. Is there a magic way or do i have to add a setParams method
taxilian 13:12 you have to query them from the plugin
if you did fbgen not too long ago you should have a getPlugin() method on your API that uses a weak_ptr to get a reference to the plugin?
jshanab_wcw 13:12 ahh
taxilian 13:12 you could also pass them into the api object, but it's probably easier to call back into the plugin
I think one of the video tutorials covers getting a param, actually
like, #4 for mac, or maybe #5
and I even got it from the API object
jshanab_wcw 13:12 thanks. I now just need to figure out when this gets called. I think it is in attachWindow, there is no corresponding javascript, this just is there on creation
taxilian 13:12 when what gets called?
hmm. not sure I understand. anyway, I gotta run; I'll be back later
jshanab_wcw 13:12 OK, I think I got it, thanks
jshanab_wcw 14:12 How do I get a PARAM passed in as a string? i am getting cannot convert from 'FB::variant' to std::string error
taxilian 14:12 did you add it to the m_supportedParamSet?
and what browser?
oh, wait...
to get a string out of a variant, use convert_cast<type>
so m_params["param"].convert_cast<std::string>()
jshanab_wcw 14:12 ah, ok, thanks.
taxilian 14:12 http://www.firebreath.org/display/documentation/classVariant
jshanab_wcw 14:12 what do you include to get that convert_cast (or is it time to rerun prep)?
taxilian 14:12 convert_cast is a method of variant
jshanab_wcw 14:12 oops, to many instances of visual studio open, wrong window, my bad
jshanab_wcw 15:12 Is the onWindowAttached the best place to handle the PARAMS or is onPluginReady() a better location., It sounds like onPluginReady occurs after onWindowAttached?
amackera 15:12 Hmm... it seems to me like that best place would be in your plugin constructor
(can you get at the params from there?)
jshanab_wcw 15:12 sure, i think so
amackera 15:12 I believe the WindowAttached() event fires whenever you get a window
taxilian 15:12 onPluginReady
amackera 15:12 Ah, nvm
taxilian 15:12 onpluginready is actually fired right after you get the params
jshanab_wcw 15:12 Thanks, I am getting closer and closer! i can almost taste success
taxilian 15:12 the window may or may not already be there
but you should add the param names to m_supportedParamSet in the constructor
jshanab_wcw 15:12 taxilian. Oh, I did. I rewatched the video and it was very straight forward.
taxilian 15:12 good =]
just checking
taxilian 15:12 nice thing about being limited to 5 minutes; you have to be concise
jshanab_wcw 15:12 is the 5 min limit, the license you have? 5 min is a good size
taxilian 15:12 the free version of jing is limited to 5 minutes =]
jshanab_wcw 15:12 Well you did a Grrreat job of utilizing the 5 min
taxilian 15:12 thanks =] I need to start a list somewhere of other segments that should be done
and try to con other people into doing some of them
kalev_ 15:12 me no speak english
neilg_ 15:12 I speak English very good. I learn eet from a book!
taxilian 15:12 lol. considering that most of our userbase probably don't speak english as a primary language, I doubt it would be a big problem
though granted I haven't heard your accent to know =]
amackera 15:12 I don't know many english, but I do as good as I are!
taxilian 15:12 lol
ужас
what I really need is a user with spare time who writes better than I do
amackera 15:12 For docs?
and tutorials and such?
taxilian 15:12 yeah
it's almost a problem… I'm probably one of the better writers on the project (in English, anyway), but I'm also the one who has the most code work to do. need people who write well and want to contribute by doing docs =]
you're probably pretty good, but I'd rather you work on code
granted, our docs aren't bad considering
amackera 15:12 Yeah they are pretty good, but stellar docs are sooo nice to have in open source projects
taxilian 15:12 exactly
brb
Abhi 17:12 hey taxilian
How are u doing
is anyone ol
right now
??
Abhi 18:12 Guys I have a question
do we need to have cmake utility while building the installer project in order to generate the msi
taxilian 18:12 hey, back
you need to run the prep script after you install wix to get the installer project
after that the project should be in visual studio
Abhi 18:12 hey taxilian
thanks for all the help
yeah i did got the installer project as you told me last time
i was also able to generate the msi
taxilian 18:12 okay
so what is the question?
Abhi 18:12 so i unistalled cmake
however, today I was trying to clean up the project for final checkin
utility and then tried to change the hard coded paths to relative paths
this started giving me errors
taxilian 18:12 okay, serious problem here
Abhi 18:12 i cannot have cmake utility installed on build box
taxilian 18:12 then you are hosed, long term
it is technically possible to do what you want
but it is *NOT* a good idea
Abhi 18:12 hmm
taxilian 18:12 I will even help you if you want, but I'm telling you that you will regret it
Abhi 18:12 what can be the solution
taxilian 18:12 why can you not install cmake on the build machine?
Abhi 18:12 so what should be done
taxilian 18:12 you can install wix and visual studio, but you can't install cmake?
what should be done is you should install cmake
Abhi 18:12 ok
i did on my development machine
also the cmake
taxilian 18:12 so what is the problem with putting it on the build machine?
Abhi 18:12 well even though all like firebreath project but there are certain constraints with installing
this
taxilian 18:12 which are?
Abhi 18:12 they say just for one plugin we should install wix or cmake
taxilian 18:12 I will help you clean cmake out of the project if you can convince me that it is really neccesary
Abhi 18:12 it is taxilian
taxilian 18:12 why?
Abhi 18:12 i had a long discussion on this with my team
taxilian 18:12 let me explain
Abhi 18:12 ok
taxilian 18:12 if you trip all the cmake stuff out, it's going to take you probably at least a couple of hours
and then you'll have to do it over again if you ever need to change the plugin config, because you'll need cmake to use that
if there are any bugfixes in firebreath, you'll have to regenerate the project
if you ever want to update firebreath, you'll need to regenerate the project
if you ever need to build this on another platform, you'll need to regenerate the project
Abhi 18:12 yes i agree and this is what i informed my team as well
taxilian 18:12 and there are so many little ways that you can mess up your project configuration while doing this that if you do so, please do not come asking for help if something suddenly stops working
when you use a tool, you use the tools that it expects. cmake is not going to hurt the stability of your build server; it's not going to introduce any difficulties in maintenance
Abhi 18:12 hey I am sorry if it offended you
taxilian 18:12 you aren't
sorry
you didn't
I'm just trying to explain
because every time someone tries to do this it causes them issues later
Abhi 18:12 ok
taxilian 18:12 every single time
and I don't understand why it could possibly every in 1000000 years be a better idea to do this than to install one single additional program on your build server
and nobody has ever been able to come up with one
with a reason
it doesn't offend me… just frustrates me, because I don't understand it
Abhi 18:12 i can understand that very well
taxilian 18:12 you'll need to remove a couple of cmake-only projects… RUN_TESTS, BUILD_ALL, and there might be another
Abhi 18:12 actually i tried discussing this with the build engineer also
taxilian 18:12 and then you need to remove any cmake triggers (pre or post-build triggers)
Abhi 18:12 and he was of the opinion
this might mess up other VS2008 projects
taxilian 18:12 not a chance
I've used cmake for years
it doesn't even touch the vs2008 configuration
that just means he has no idea how cmake works
Abhi 18:12 ok
taxilian 18:12 is that his only concern?
Abhi 18:12 yeah and also that the manager is reluctant to allow him to install cmake utility as well
on build box
taxilian 18:12 in other words, "We've never used it, we don't know what it is, so we don't want anything to do with it"
well, like I said; I'll help you figure it out if you want
but you have my personal guarantee as the man who wrote 95% of the cmake code in the project that it will cause you problems later if you do
Abhi 18:12 i can understand
dont really know
what to do
one alternative way
which i guess ur the best judge
to guide me
if i paste my plugin.dll under mozilla/plugins folder..similarly if i do the same for IE do u think that will work
taxilian 18:12 if you put your plugin.dll in the plugins folder it will only work on mozilla
Abhi 18:12 in that case I will just have to get my dll from server and put under these locations
ok not for IE?
taxilian 18:12 not for IE
you can install using regsvr32, but it's not really a good idea
Abhi 18:12 so u mean to say we have to in any case register the dll
taxilian 18:12 yes
Abhi 18:12 yeah I agree
taxilian 18:12 doing actual installs with regsvr32 isn't really a great way to do it
upgrades and uninstalls become somewhat more dangerous
still, many do it that way
and it will work
copying it to a plugin dir is a really bad way that won't always work
Abhi 18:12 right
taxilian 18:12 it should theoretically be possible to get the installer working, if you're already stripping out cmake
Abhi 18:12 may be i can again discuss this problem tomorrow with my team
taxilian 18:12 if you're far enough that you can build it without cmake on the build server you've already messed with the project dir enough to regret it
there is absolutely no reason that cmake would cause any problems; cmake is one of the most used build tools available
Abhi 18:12 i guess so
taxilian 18:12 it's supported by a reputable company, and they do release candidates for 2 months before releases
what I would do if they refuse to let you put cmake there (this is the next best solution) is to write a script that will strip out cmake
convert all the absolute paths to relative, etc
Abhi 18:12 okay
taxilian 18:12 then it should be possible to do so in such a way that your installer will also work
but you'll still need the build dir and the plugin dir in the same place relative to each other
Abhi 18:12 yeah that seems to a big task taxilia even if I have cmake
taxilian 18:12 you could then generate the project on a dev box, convert the project, and put it on the build server
Abhi 18:12 because right now all paths seems to be hard coded
taxilian 18:12 they are, but with python (or something similar) you could build a script that would convert those absolute paths to relative paths
Abhi 18:12 is there an easy I can convert them to relative paths
taxilian 18:12 python has a function os.path.relpath
if you know python
that's what I've considered doing a few times
anyway, it can be done
Abhi 18:12 i havent actually worked on python but i can certainly try
taxilian 18:12 it's not nearly as dangerous if you're just building with the stripped stuff, and you keep developing on your main one
the main problem is that if you have to do it by hand, it's going to be a nightmare any time you have to update
which, to me, seems like a horrendous waste of man-hours compared to just installing a single well-known, reputable build program on your build server
Abhi 18:12 i agree if need to upgrade FB
it will be a big problem
taxilian 18:12 and while I think we've done a pretty good job with FireBreath, I guarantee there are still bugs in it
there always are
they might affect you, they might not
FB is really easy to upgrade, partially because of cmake
Abhi 18:12 right
so your recommendation is to have cmake utility installed
taxilian 18:12 absolutely
if you're working on plumbing, you use plumbing tools
Abhi 18:12 but still hard coded paths needs to be changed to relative paths
taxilian 18:12 sure, you could do it with an auto mechanic's tools, but it's not going to work right and you might break something
not at all
the build/ dir is not supposed to go in source control
it should never leave the box it is created on
the prep script is *part of the build process* of firebreath
Abhi 18:12 actually they way it works for me is
i have to create this project
run the prep script and can then checkin the code
to source control
thats the process
taxilian 18:12 there is mistake #1; the build/ dir does not go in source control
it should not, rather
only your project doe
does
Abhi 18:12 i know but
taxilian 18:12 Hey, you can do whatever you want… I'm just telling you that it won't work well if you do
if you install cmake, then you can use the prep script
Abhi 18:12 yeah I got that taxilian
taxilian 18:12 if you install cmake and try not to use the prep script, you'll be worse off than you would have been not installing cmake
because it's really going to get confused
so if you do it with cmake, use cmake
Abhi 18:12 got you
taxilian 18:12 if you strip out cmake, strip out cmake; just be aware of the probable issues
Abhi 18:12 so when you say stripping out cmake
you mean removing all cmake.txt files
taxilian 18:12 no
that won't help
I mean modify all vcproj and sln files in the build/ dir
and remove all the pre and post-build conditions, all the custom rules, etc that use cmake
and convert all absolute paths to relative paths
so that you can build it on another computer without cmake
the cmakelists.txt files can be left there
Abhi 18:12 ok
but as you informed this might have issues later on
taxilian 18:12 yeah; if you can do it every time you change the plugin, then it should minimize them
I'm not saying that's a good way to do it
Abhi 18:12 i agree
taxilian 18:12 but if you're not going to use cmake, then it is the best alternative
Abhi 18:12 okay
all these changes will have to be done in build folder
right
in case i need to strip off cmake
taxilian 18:12 exactly
you'll cause yourself a lot of work
but hey, you can always blame the build guys, right?
Abhi 18:12 i agree
but what to do those ppl are not ready to agree
to what i have been telling them
i'll try to explain them again tmw
lets hope they can understand it
taxilian 18:12 have them come ask me if they have specific concerns
but the only config that it changes is the solution that it generates
Abhi 18:12 sure
taxilian 18:12 it doesn't touch any of the visual studio configuration
thus can't affect other projects
it's just a project generator
Abhi 18:12 i agree
i cant thank you enough taxilian
thanks so much
taxilian 18:12 good luck
Abhi 18:12 for helping me out
i shall bother you again in case i need some more help
thanks again
taxilian 18:12 good luck
cya
I gotta run too
Abhi 18:12 sure
Sinisa 20:12 hi all
i'm back on win32 plugin for a moment, but wanted to share one "issue" i've found on mac
it appears that in Safari, JSAPI will be allocated after window is attached, while in Chrome and Firefox will be allocated before
since my browser-independent-class receives void * for API and void * for window handle (win32) that is CALayer/CGContextRef (mac), I've assumed that safe place to initialize app is in window attached, but then in safari pointer to API is NULL in that moment.
I don't know if that's intentional, or even if order of these events is not guaranteed in any of browsers, and it just appeared on my mac that in FF/Chrome window attach was first and api second and maybe on someone else's mac would be opposite
but maybe it should be mentioned in the documentation