|IRC Nick||Time (GMT-7)||Message|
|needHelp||03:02||can someone help me?|
|prem||06:02||ok, i decided against using mfc.. too ugly for my liking..|
|ch||08:02||i'd guess distributing mfc with the plugin won't be too nice as well :)|
|FireBreathBot||10:02||taxilian: I'll pass that on when kun is around.|
@taxilian: i added height and width parameters to the resized event in window..
would it be ok if i sent a pull request?
|taxilian||11:02||pull requests are fine
I won't promise that I'll accept it until after I've looked at it, though =]
however, is there a reason not to just query the pluginwindow for the width and height when the event fires?
|prem||11:02||oh, ya.. i guess i overlooked that.. i guess i might be spoilt from getting all the data in the event itself.. lol..
was working in android before this.. and all required data was given in the evnt itself.. stupid me..
oh, there is a prob that the plugin won't retain focus in chrome and opera.. in windows..
it will get all the mouse button events no prob, but the mouse scroll event never gets fired..
|taxilian||11:02||I don't necessarily have a problem with putting it on the event as well; however, to do that we'd need to modify all of the different pluginwindows and it seems like a bit more work. Also it's an extra API call that would always be made on resize when we may not actually care about the specifics|
|prem||11:02||ya, u are right.. i'll just change my implementation here..
about the focus, when i put the setfocus(m_hWnd) in the WM_LBUTTONDOWN event, the focus is retained
|taxilian||11:02||so there was a jira issue awhile back dealing with setfocus where a recommendation was made to put it in mouseactivate
I think that's why it was put there
trying tor emember the reasoning
|prem||11:02||ya, i saw the post
it was an effort to consider all the mouse down events
left, right or middle
|FireBreathBot||11:02||FIREBREATH-69: Summary: Incorrect windows focus management for Window's platforms
FIREBREATH-69: Assigned To: richard
FIREBREATH-69: Priority: Major, Status: Closed, http://jira.firebreath.org/browse/FIREBREATH-69
|prem||11:02||oh and i tried calling setfocus from mbuttondown and rbuttondown
but i lose focus as soon as the button is released
i'm using firebreath 1.6 stable version...
well, I haven't had any reason to play much with the mouse stuff, so if it needs to be changed back file a jira ticket with the details
|prem||11:02||ya, sure.. i'll just do a bit more digging around... i would like to know as to why this happens..|
|taxilian||13:02||yes, Safari removed support for a NPAPI call that we were relying on without notice and we had to add a workaround
the 1.6 release branch should have that fixed
of course, any time you have a problem it's a good idea to update to the latest firebreath release; I don't support old releases. I don't get paid enough to do so ;-)
|rcohn||13:02||Thanks very much. Please keep up the good work and evolving as you go.|
I need to recive a string as an argument inside a firebreath function... but if I use it like const char * arg
and if I put it of type string it says that "string" is undefined...
|taxilian||14:02||even better, const std::string&
cornel__: highly recommend reading the "Getting Started" page on the wiki
|cornel__||14:02||ok, I understand.... thank you
I have read the gatting started... but this is more like an visual c++ question...
which is one of hte pages referenced on the getting started page
as to the "string" is undefined thing, that's not a visual C++ quesiton, it's just a c++ question =]
the namespace std is often imported as a matter of course in many c++ apps, but FireBreath does not do that
though you can yourself
|taxilian||14:02||which is why FireBreath doesn't import it for you =]
another good trick is you can just do "using std::string;" and it'll import just string
hehe. I'm fine with autotools… they just don't do what I'd need to use them for FireBreath
so I dont' use them
they work fine for me now :)
and it still builds properly with the real firebreath
which i think is a good compromise
|taxilian||14:02||what did you end up doing?|
|reichi||14:02||well basically, the decision was "making it toolchain compatible" or keep cmake
and we decided we'd like to have it working nicely with our toolchain
|cornel__||14:02||one more quick question... can I unload the plugin dll from the memory without close the browser ( I closed that tab but I still can't compile the plugin because the dll is in use... )|
|reichi||14:02||so basicall it's a copy of FBs src directory, extended with my specific project and a set of makefiles/configure.ac et cetera|
|taxilian||14:02||cornel__: no you sure can't
though Chrome seems to unload the plugin faster than most other browsers, if that helps
|cornel__||14:02||ok, thank you.. brb :)|
|reichi||14:02||taxilian: the real drawback is, that i have to get rid of the x11 dependencies
that will be quite some fun ;)
|taxilian||14:02||reichi: I think you're crazy, but let me know how it works out|
|reichi||14:02||crazy is just what i like!
i think firebreath is just of so much value that it's worth the effort
|taxilian||14:02||well thanks :-P
if you find any specific things I could do in FireBreath 2.0 to make it easier to work with autotools I'll be interested in hearing about them when you're done
|reichi||14:02||it was pretty straight forward, tbh|
it's the code generation and such that is the trickiest
i let firebreath do that
and copy it over ;)
|taxilian||14:02||but I could maybe require CMake and just have the option of using cmake to generate that stuff into an arbitrary dir that you can then use with anything|
|reichi||14:02||that's basically what i made of it
i copied global/config.h
and well... that little helper-programm that told me about the missing symbols in the resulting was also helpful
(good i've got colleagues that actually know what they're doing)
|prem_||22:02||i would like some pointers as to how to create a right click context menu in firebreath.. can someone please help me?|