IRC Log Viewer » #firebreath » 2011-04-25

IRC Nick Time (GMT-7) Message
Lta 06:04 taxilian_away: hello back
Lta 06:04 i will need to build firebreath activeX with gcc, cross compiling
from Linux, and since im not at all a windows developper, i guess i'll need you help
Lta 09:04 taxilian_away: just to know, how strong is the FB dependency on ATL ?
i don't know anything to win32 apis, but i know vlc activex, for example, doesn't depend on the atl
taxilian 10:04 Lta: you can't build FireBreath without ATL; you'd need to rewrite the ActiveX side. it can be done, but I don't have time to do it (nor good enough reason to spend the time)
you'd also need to build an abstraction for doing the DLL registration (either to process the .rgs files or a new method that is also user configurable), since what we have now is part of ATL
even then I'm not sure if it'll work to build it with GCC, which lacks several COM-specific data types; seems like it should be possible to fake them somehow, but I'm not certain
Lta 11:04 taxilian: do you have an idea on how long it would take to rewrite the activeX side, just to have an idea if at some point i need it
i think the dll registration shouldn't be taking to much time, but the com part :/
i know it's possible to build com objects with gcc using the w32api package from mingw
taxilian 11:04 I dont know
Lta 11:04 btw, i'm currently trying to use the atl from gcc, but the cmake just don't find the headers and libs, althought it searchs in the right library
so i currently can't give you any report on this
taxilian 11:04 interesting
I don't know why cmake wouldn't find it
Lta 11:04 maybe the list separator is different under unix and win32
taxilian 11:04 in cmake? no, cmake lists are cmake lists
Lta 11:04 ok, not used it on win32 for a long time
taxilian 11:04 however, there are branches of cmake code that probably won't execute without modification
if (WIN32) will pretty well return false
Lta 11:04 i think cmake handle this well, WIN32 seems to be true since it complains about not finding atl headers
taxilian 11:04 hard to say for sure; I'm just saying that could affect it (if not WIN32 then something similar)
Lta 11:04 that's what am working on
taxilian 11:04 well, honestly I'll be shocked if you get it working, but it would be cool =]
so keep me posted
Lta 11:04 what's crazy is that {ATl/MFC}_GUESSES have the correct values
taxilian 11:04 lol. seriously?
Lta 11:04 yes
taxilian 11:04 do the variables that those provide have correct values?
those variables themselves are only used to search
Lta 11:04 thoses variables are good, but the find_file(atlwin.h) for example says not found
taxilian 11:04 you could also try defining ATL_INCLUDE_DIR yourself
will gcc link cleanly with msvc lib files?
Lta 11:04 it seems that they are both using the COFF format
but this is the next step :)
taxilian 11:04 heh
I expect a writeup on this if you get it working =]
Lta 11:04 don't worry
i guess setting directly the variables will work, but i hate strange stuff like this
taxilian 11:04 did you set the env variable DDK_PATH?
(I assume it's the DDK atl headers you're using...)
Lta 11:04 no i added src/3rdParty/WinDDK in DDK_SEARCH_PATHS
which does pretty much the same thing
taxilian 11:04 ok
Lta 11:04 it's ok
my bad :)
taxilian 11:04 ?
Lta 11:04 when crosscompiling, cmake add previously defined root folders to every searches
that's a good thing it avoids using host system libs and headers, but had to be disables in that precise case :)
taxilian 11:04 ahh
Lta 11:04 if my build attempt is a success we might talk about how to integrate this cleanly
taxilian 11:04 hehe. if it can be done in a clean way I'm not opposed to it
Lta 11:04 the atl/mfc check passes, just had to add NO_CMAKE_FIND_ROOT_PATH to the find_file commands
taxilian 11:04 ahh
neilg_ 11:04 Hey all!
taxilian: Congrats!
I did reply to the list but it bounced... I don't understand why. :)
taxilian 12:04 neilg_: heh. if your from email isn't the one registered on the list it'll do that
and thanks
neilg_ 12:04 My email is the one registered on the list (I only have one email address at work which is where the emails go). And I've emailed it before too for that matter. ;)
I'm just going to claim it was a glitch with Google Groups and ignore it for now :)
taxilian 12:04 huh
neilg_ 12:04 Anyway, has much gone on in the last couple of weeks? I was away on vacation for one week and then catching up with everything last week so I wasn't around!
taxilian 12:04 well, 1.5 is released
neilg_ 12:04 Well that's awesome, cool!
taxilian 12:04 quite a few memory leaks have been found and fixed
as well as edge-case crashes
definitely recommend updating to 1.5
the mac plugin windows are completely refactored, but you knew that I think
neilg_ 12:04 Sounds like it's well worth updating to! I'm already on a pre-release 1.5 so hopefully there shouldn't be any problems
Right, I already have those changes :)
taxilian 12:04 yeah, don't think there are any breaking changes for you, then
neilg_ 12:04 Sounds fantastic, I'll get on that for sure
Great work everyone!
cxo 12:04 I can successfully build firebreath using prep2008.cmd, but using via cygwin it complain that it cannot find the -VS DIR-
Do I need to have setup some environment path
Lta 12:04 cxo: cross compiling is still a WIP :)
cxo 12:04 Not cross compiling. Just using prepmake instead of visual studio stuff
Lta 12:04 taxilian_away: I'm surprised you had to resort on fb_stdint.h, doesn't stdint.h exists on windows ?
nitrogenycs 12:04 Lta: I think visual c++ doesn't ship with stdint.h, at least on 2005 and earlier
haven't checked since then
Lta 12:04 cxo: it's not a problem if it doesn't find VS DIR, if you have the ddk installed
cxo 12:04 Ok. But I was able to build fine using the vs sln file
nitrogenycs 12:04 it's a C99 header and visual C is only C89
Lta 12:04 nitrogenycs: ty, wasn't knowing
cxo 12:04 Why do I need the DDK if im using prepmake but I dont if Im using prep2008
Lta 12:04 i think the problem might come from cygwin posix emulation, especially path handling
cxo: are you using the windows binary version of cmake, or some cygwin version ?
cxo 12:04 hmm good question
i think I have both installed. Which one should I be using
Lta 12:04 this is the problem
none of them can perform the task correctly without cmake tweaking
cxo 12:04 So i basically cannot use prepmake under windows
Lta 12:04 are you wanting to use gnu/bsd make or VS nmake ?
gcc on windows isn't supported, that's the same problem as cross compiling
cxo 12:04 Does the make program matter? Its the compiler thats important
Lta 12:04 cxo: it is, but it don't know if cmake is able to produce Makefile which uses vs compilers
*i don't know
cxo 12:04 Well I supose i could just use nmake and talk to the .sln file directly
taxilian 12:04 Lta: stdint.h only exists on vs2010 and later; I kept having problems, finally fixed it with fb_stdint.h
vxo: you can't build firebreath with cygwin
cxo: what are you actually trying to accomplish? why do you need to use gcc?
cxo 12:04 I dont have to use gcc. I had some other code and Makefiles setup to use gcc, so I thoujght i could just make firebreath do the same
Buts its not an issue to use VC++
taxilian 12:04 yeah, you have to use vs, basically. if you just want to build from the command line, that's pretty easy
but FireBreath uses ATL, which doesn't work on non-microsoft compilers (though Lta is trying to find a way)
neilg_: the other thing I think that has happened while you were gone is I finally set up a forum; you probably saw that on the list, though
Lta 12:04 taxilian: some part of the project are compiling, but there are problems with the atl (Oh! Surprise ! :P)
a lot of headers are missing, WinDDK isn't enought i guess
taxilian 12:04 not terribly surprising
Lta 12:04 sal.h crtdbg.h urlmon.h msstkppg.h and mshtmhst.h
except all the ignored #pragma warning, this isn't that bad
taxilian 12:04 hmm. those might be in the windows sdk
Lta 12:04 i've both on my other computer, i'll have a look
the problem is i'm not sure i'll be able to link with vlc using vs, which is not supported at all iirc, so it's easier to make FB support mingw than make vlc (and its dependencies) supports vs
btw, i'll take a break, maybe i'll look again later this night. Thank you taxilian for the help
taxilian 12:04 good luck =]
Lta 13:04 taxilian: ps, they seems to be in the platform sdk
taxilian 13:04 makes sense
Lta 13:04 taxilian: is there any atl use outside from src/ActiveXCore ?
taxilian 13:04 no
cxo 14:04 Almost forgot how annoying windows development is
taxilian 14:04 lol
sabotaged|wk 17:04 is moving a firebreath plugin or plugin in general around in the dom tree possible?
i saw there was an IE issue with that which was resolved
but there might be ff4 issue with it?
sidenote: would be nice if you could search for strings, not just ungrouped words. eg "dom tree"
taxilian 17:04 sabotaged|wk: I dont recommend it
why do you need to?
sabotaged|wk 17:04 the ui that sits ontop of this plugin is going to be a little bit fancy
i think we did some tests with 1.4 and things went pretty bad when we tried to move it around
taxilian 17:04 dont move it in the dom
abs position it
works fine
taxilian 17:04 sabotaged|wk: (sorry, I was holding my son earlier and couldn't type easily) in FF4 there is still (as far as I know) a crash that can happen w/ moving things in the DOM and on IE if you move it it will lose all reference to anything passed in from the page (including event handlers). There is nothing that I can do about that, as far as I know
so it might work, but it's definitely safer not to move it around in the DOM. however, since you can move and resize it using absolute positioning (put it 100%x100% inside a div and absolute position the div — much safer) it's not a big issue
also sometimes the browsers handle hiding the plugin in a weird way; never set visibilty to hidden or change the overflow of the container the plugin is in. that can cause the window to get messed with and/or the plugin reloaded. if you need to hide the plugin, resize it to 1x1 (again, better to resize a container div)