IRC Log Viewer » #firebreath » 2011-08-31

IRC Nick Time (GMT-7) Message
Umesh 04:08 Hi
I want to write a plugin using FireBreath
i wrote a sample plugin
but the Log messages i am putting in that ... are not getting displayed on console
what can be the issue with this ?
FBLOG_INFO("StaticInit", "Static Initialize");
this is my message in the StaticIntialize
which is not getting displayed on console
for sample plugin FBTestPlugin it is working
jshanab_wcw 07:08 Has anyone used CMAKE on windows to build FB using mingw so it builds with GCC? Is their a prep for that
tony_ 07:08 hi guys, I have a problem in windows with 1.6 rc1 version,
I have created window as the child of plugingwindow::m_hWnd
But this window is careated, but not visible :(
any clue
dougma 07:08 you forgot WS_VISIBLE?
tony_ 07:08 done :(
dougma 07:08 you created in another thread which doesn't have an event loop?
tony_ 07:08 I will share the code
dougma 07:08 .pb
FireBreathBot 07:08 When you need to share code, logs, or anything else longer than a couple of lines, use a pastebin. http://fpaste.org, https://pzt.me/, and https://gist.github.com are all good options
tony_ 07:08 https://pzt.me/19qt
HI I have careate that code in the JS handler class , inside a method which is called from js
dougma 07:08 have you tried different browsers?
tony_ 07:08 yes..
I same fate
I can see the window in spy++ still its not painting :(
Its is receiving timer messages
dougma 07:08 well... i've never tried creating a window on the js thread, i'd do it on my own thread because then i know the events are all going to get through
tony__ 07:08 dougma I might missed ur last messagaes
dougma 07:08 last thing was: dougma> well... i've never tried creating a window on the js thread, i'd do it on my own thread because then i know the events are all going to get through
tony__ 07:08 oki..
So let me try creating the control in a new thread..?
hope this may work
dougma 07:08 worth a shot. :)
although... tony__ do you need to call ShowWindow on mAppshareView?
tony__ 07:08 normally it works with a WS_VISIBLE flag
dougma 07:08 ok, i think i misunderstood that method
tony__ 07:08 ok no prob
jshanab_wcw 08:08 I have a saveFileDialog in my plugin and it has been working but after a recent round of changes I cannot get my plugin to link. It says unresolved external SaveFileDialog, but user32.lib is in the linker properties for the project. Any ideas?
dougma 08:08 do you have an msdn reference to SaveFileDialog?
jshanab_wcw 08:08 What do you mean by reference? documentation? or c++ reference
dougma 08:08 yeah, documentation
jshanab_wcw 08:08 This is a linker error, code compiles and is type correct
dougma 08:08 i hear you.
msdn tells you what you should link to.
i don't know about SaveFileDialog
jshanab_wcw 08:08 msdn routes all inquiries to .net componenets and makes it really hard to find it. the only change was to go from winsock.h to winsock2.h in some places. one ref says user32.lib and that is linked
they kept the name and rewrapped it in all the newer technologies and then named the namespace win32 ROTFL
dougma 08:08 i just don't think it is in user32
maybe your recent round of changes changed your link line
jshanab_wcw 08:08 That is the question I am trying to find the answer for.
Not likely, but still if I could find what lib to link...
gdi+ me thinks
taxilian 09:08 Btw, jshanab_wcw: you cant build fb with mingw on windows
jshanab_wcw 09:08 oh, shucks. I could think of a wat that could reduce cross platform issues on GNU libraries, jsut use GCC everywhere. :-)
thanks for the help last night, that solved my problem!
kylehuff 09:08 might not be the same thing you are guys are talking about, but I am able to use cmake in mingw on windows to build my plugin.
taxilian 10:08 jshanab_wcw: well, there is no ATL in mingw, so it'd be possible to make it build (I'm considering it for 2.0) but you'd loose activex support
kylehuff 10:08 ah, makes sense.
jshanab_wcw 10:08 humm, and that would be a bad thing? :-)
kylehuff 10:08 yeah, for my current purpose, lacking activex is okay, since my plugin is only currently for chrome/chromium
taxilian 10:08 and the recent ubiquity of users creating chrome extensions with FireBreath plugins is one reason I'm considering it
there are some other challenges other than just the absense of ATL, of course
but I think they are things I could work around
just need to think about it a bit
kalev 10:08 do the 2.0 plans include making firebreath a shared library? :)
taxilian 10:08 lol. I'm open to suggestions on how to reasonably do that
we could certainly make parts of it a shared library; the core projects
the auto project could be a problem, though
kalev 10:08 I don't have any ideas off hand, would have to study the problem
taxilian 10:08 I have ideas, but they all involve making about 10x as much work for the user
or possibly coming up with a way to generate code without using cmake
kalev 10:08 yeah, 10x more work isn't worth it
taxilian 10:08 10x *might* be an exageration
but basically all the stuff that is currently automatically generated for the user in the PluginAuto project would need to be somehow taken care of
and currently the PluginConfig.cmake settings are used to do a *lot* of configuration and even some code generator
generation
kalev 10:08 I guess one way would be to keep such files out of the shared library and provide an easy way for clients to generate the files and include them in the project
taxilian 10:08 right; and that's the main thing I've considered; not sure what I'd use for the code generation, though, unless we provided a way to use cmake just for code gen
kalev 10:08 cmake seems like an obvious first choice, which of course means that clients need to use cmake to build their projects
taxilian 10:08 well, you could use cmake just as a code generation tool
it has a mode where it just executes scripts
which would make sense if we were going to support other build modes, such as building your own project
linearray 10:08 explain this like for a 4-year-old... you want to make FB into a shared lib that you link with your program and it magically generates a plugin instead of an executable then?
taxilian 10:08 no; you could just create a project without using cmake, is the main thing
it'd still be a plugin, you'd still have to write it as a plugin
linearray 10:08 ah ok
what code is generated by cmake?
taxilian 10:08 everything in gen_templates
kalev 10:08 it's probably easier to solve it step by step. Could just require that everybody use cmake for their own project in 2.0 so that we could rely on cmake for code generation.
taxilian 10:08 however, the bigger issue is that it then needs to compile those files against the PluginAuto project
linearray 10:08 that's pretty cool
taxilian 10:08 kalev: Also, I'm not sure a shared library specifically would really help, because we don't currently maintain any kind of binary compatibility between versions
kalev 10:08 yeah, I was more like thinking of a shared static library, not a dynamic shared library
taxilian 10:08 ahh
sorry, I'm thinking in cmake terms
in cmake terms a shared library is a .so or .dylib or .dll
so…
what you really want is for all of the core projects to be able to be built as static libraries
and you're okay with PluginAuto still being per-project for now?
kalev 10:08 what I don't like is the way how my project's build system is integrated with firebreath
taxilian 10:08 that is definitely in the cards
kalev 10:08 I'd prefer if I could build the plugin project as a main project and link to a (static) library installed on the system
taxilian 10:08 with or without cmake?
kalev 10:08 with
taxilian 10:08 okay; that I think is doable, and that I'm planning
in fact, if you want to play with it it might be possible as of 1.5
kalev 10:08 excellent
taxilian 10:08 I'm not currently planning to actually do a binary distribution, however
kalev 10:08 yes, I don't think there's any need for that.
taxilian 10:08 though you can actually do a build of the core projects so that you don't have to build them each time you blow away your build dir, if youw ant
completely undocumented, but it works :-P
kalev 10:08 oh yes, I remember seeing some INSTALL commands now
but the per-project PluginAuto problem is still there, isn't it?
taxilian 10:08 yes
no way around that
what I am thinking, though
is that you'll have your own root CMakeLists.txt, and you'll include FireBreath and then run some macros to add the needed projects
something like add_firebreath_plugin(PluginName PluginAutoProjectName) or something
still in early stages of thinking it through
but the idea would be that even though FireBreath will need to add a PluginAuto project wtih your customizations, you can include FireBreath rather than FireBreath including you
kalev 10:08 sounds very good, definitely a step in the right direction
taxilian 10:08 I'm also considering renaming a lot of classes, possibly reworking the abstraction around PluginCore and BrowserHost
JSAPI I think is pretty strong; if I make changes to that they would likely be minor
I'm totally open to other suggestions for things that could be cleaned up, improved, etc
kalev 10:08 I think Firebreath's C++ interface is already very nice and easy to use, especially JSAPI like you mentioned
but cleanups are always nice to have :-)
taxilian 10:08 =]
well, I need to go ship some laptops back to facebook
I'll be back later
kalev 10:08 see you
linearray 12:08 omg, another game changer: VS supports emacs shortcuts
taxilian 12:08 lol
some day I need to learn emacs, just to see if it can actually be as nice as vim like some say
because the key bindings are sure more common
linearray 12:08 yes, especially since libreadline copied them
taxilian 12:08 I use viemu with visual studio, which is pretty nice
but on the occasions that I have to use eclipse I miss my vim bindings
I have not heard real fantastic reviews about the eclipse/vim integrations
linearray 13:08 actually, mac os x implemented emacs keybindings as well
pretty much everywhere
so you shouldn't need to learn anything new :)
linearray 17:08 sometimes VS will just stop pointing out errors
I think it's giving up on me
linearray 19:08 so, I see when you need a myClassPtr, you just use FB_FORWARD_PTR(myClass) then and there, instead of having it in myClass.h and including it.
is that better?
taxilian 20:08 absolutely… sometimes
whenever possible, you should avoid including a header file from another header file
so if you can do a forward declaration in the header file and then include myClass.h in the cpp file you're much better off for a number of reasons
however, you can't inherit from a forward declared type
so if you need to do inheritance, you'll have to include the .h file
linearray 20:08 ouch
taxilian 20:08 ?
linearray 20:08 well, after giving up on my plan for one single project header file, I put all includes for a class in its header file to avoid clutter in the .cpp
taxilian 20:08 lol
there are times when that can be okay
but it has a lot of potential to be problematic in a larger project
there are actually places in firebreath where I have interdependant classes, which means they reference each other; in that case, forward declaration is the only option
linearray 20:08 ok, so as little includes in headers as possible.
taxilian 20:08 as a general rule of thumb
that will also help keep your compilation time down
linearray 20:08 did you actually think of an include hierarchy?
taxilian 20:08 what do you mean?
linearray 20:08 e.g. you need FBPointers.h pretty much everywhere
but you often include it via different headers
well, at least I found APITypes.h
taxilian 20:08 well, I'll be the first to admit that FireBreath isn't always as clean as it should be
but APITypes.h is generally the closest thing we have to a generic include
just about everything needs that one
and I think that includes variant
dougma 20:08 i would say firebreath's includes are very sensible. no problems encountered. :)
taxilian 20:08 heh. well, thanks for the vote of confidence =]
I'm actually fairly proud of the FireBreath codebase; I think that as open source projects go it has fairly well designed and clean code
in large part that's because we've been willing to introduce breaking changes when needed to fix architectural problems
but there are certainly some places where it could be improved
linearray 20:08 now that's funny
taxilian 20:08 ?
linearray 20:08 http://pastebin.com/6mEmuQ9x
the rvalue version is not considered a friend apparently
smart pointer library didn't change in ages according to changelog
taxilian 20:08 is that the c++0x stuff you're trying to use?
linearray 20:08 I'm not trying anything
VS thinks that's the right function
that's the version below #if defined( BOOST_HAS_RVALUE_REFS )
taxilian 20:08 huh
linearray 20:08 I can't quite believe no one tried compiling with VS10 yet, so I'm a bit surprised
taxilian 20:08 vs10? vs2010?
linearray 20:08 yes
taxilian 20:08 I use that all the time
linearray 20:08 thought so
is BOOST_HAS_RVALUE_REFS set on your machine?
taxilian 20:08 I dont' know
not at that machine right now =]