|IRC Nick||Time (GMT-7)||Message|
|TomL||03:11||Hey, anyone out there ready to play Q&A?
Whatever, I'll rush out my question anyways :-)
So I'm trying to figure how to dispatch messages from the plugin window into my app. I'm currently developing on windows, to add that before you need to ask.
First off, do I have to (re)dispatch system messages at all? From the little documentation I read I was on the impression that this happens rather automatically
I have the C4 engine running in the browser window and mouse-input seems to work, just as keyboard input does. However only for bound keys, i.e. the engine hooks itself into the input queues of the system (afaik), but when I have a subwindow opened in the engine, no keyboard input is arriving
from that observation I concluded I might have to dispatch the system messages to the engine (child window) myself..
Any ideas will be welcome
|DriesSt||04:11||so the app is something totally independent running in a separate process?
oh, wait, now i get it
yeah, redispatching those messages seems like the most reliable solution to me
|TomL||05:11||am back from lunch
so, I haven't yet figured out how to redispatch them, i.e. how to cast the event..
I'm a bit puzzled with the events that are handled in the generated derivate of plugincore
|TomL||05:11||err.. maybe I shouldn't try to cast just any event to a windows MSG, just realized there is a fb::windowsEvent|
|TomL||05:11||ok, need to drop out and test some more..|
i use the handle of the pluginwindow to create a child window for my application, with the WS_CHILD style the window no longer properly receives keyboard events (and the like), with WS_POPUP it does, but it does of course not position itself properly in the browser window
|TomL_berlin||07:11||Any ideas as to why a WS_CHILD does not respond to keyboard events will be appreciated|
|neilg_||07:11||TomL_berlin: How do you create the child window?|
|TomL_berlin||08:11||createwindow(bla...,styles | ws_child, pluginwindow as handle to parent)
i just figured a way how to do it
i catch windowsevents (those derived from pluginevent) and send them to the child window
i had my sleeves covered so deep in windows mud
i never had ~
|neilg_||08:11||Okay, yes - that would absolutely do it|
|DFUN||08:11||have a good weekend, guys.|
|taxilian||08:11||TomL_berlin: glad to hear you figured it out|
|TomL_berlin||09:11||have a nice one, guys|
|amackera||10:11||So, any reason not to push 1.3.1?|
|danb_||11:11||If one wants to present a simple UI within the browser, what is the best approach (Windows only)? I assume winforms are off the table since they require common runtime language support|
|neilg_||12:11||Gah! I could have answered danb_ :(|
|nitrogenycs||12:11||what would you have answered?
I guess there's no best solution without knowing the requirements
|taxilian||12:11||Best solution is probably to use GDI
Normal windows UI
amackera: I am also thinking we should push 1.3.1. Anyone know of any issues?
|taxilian||12:11||Unless someone finds and reports something critical, I will release 1.3.1 in abt 2 hours|
|amackera||12:11||sounds good to be|
|neilg_||13:11||I would have first found out whether or not the UI could have been a mixture of HTML and JS but otherwise I'd have suggested GDI
Although Winforms would have worked too so long as the plugin installer installed MFC too
|emann||14:11||Anyone actually here, or just sitting idle?
I have a question about the stock prep scripts that come with Firebreath, and I was hoping someone with more experience could help.
I've developing a browser plug-in with two other developers and we're using mercurial to coordinate our efforts ... unfortunately, after I run the prep2008.cmd script on my machine, my local references (C:\Projects\Plugin\) are hard-coded into the vcproj files in the solution
When my co-developers try to build the solution from the same files, they run into significant errors because their file structure is different
Is there a way to tweak the vcproj files to use relative directory references?
Is there another alternative so we can share code as we work?
|amackera||14:11||your co-workers could re-run the prep scripts, couldn't they?
each person generates their own vcproj
|emann||14:11||Would re-runing the prep scripts replace the vcproj on their machine?|
|emann||14:11||Then I guess I could just add .vcproj to the .hginore file so we don't muck things up ...
It's worth a try
|neilg_||15:11||emann: I've had the same problem with the build machine here. The easiest solution was to get it to generate the .vcproj files as part of the build process
It makes source control harder but...
|amackera||15:11||I generally don't even use the IDEs, just compile using cmake --build <builddir>
really just source should be in source control (including cmake files)
then the prepscripts will generate the correct project files for whoever runs them
|taxilian||15:11||emann: emann: you should never try to share the build files
neilg_: why exactly does that make source control harder? You shouldn't have your porject and firebreath in the same source control repo
emann: I recommend that you keep FireBreath and your project files in seperate directories
rather than leaving projects/ in the default location
(and sorry, somehow I didn't see that there was activity on the channel; I've been here, had someone pinged me :-P)
|neilg_||15:11||It makes it harder because you can't check in the .vcproj files, they have to be generated on everybody's machine because they don't use relative paths|
|taxilian||15:11||why is that harder?
you don't *want* to check in the .vcproj files
if you are doing that, you are doing it wrong and will likely cause yourself problems
cmake is part of the build process
and needs to be
if anything, I'm glad cmake doesn't use relative paths *because* it keeps people from thinking that they can safely reuse the cmake generated files
you should not ever do that
every time I have seen someone do that, find a way to keep using the original generated files, it has caused them grief in the end
|neilg_||15:11||Because it's an extra step everybody has to do. Anything extra that anybody has to do is one more complication that makes things harder! It's not a big problem - it's just an extra step to remember|
|taxilian||15:11||I guess it depends on your perspective
to me, it isn't an extra step -- in building FireBreath, it isn't an extra step
it is simply one of the stepos
there isn't an alternative
though if you aren't used to using cmake, I guess it could be seen that way
|neilg_||15:11||Sure, but to anybody else they aren't building FireBreath, they're trying to build their plugin
I'm not saying it's bad, I'm just trying to show a different perspective. I understand why it's done this way - but I can equally understand the perception too
|taxilian||15:11||yeah, I can understand the perception; it just needs to be understood that this is how cmake works
and firebreath plugins use cmake
it annoyed me a bit at first too
but I don't see it as being really all that much more difficult
that's the hardest bit about using cmake, I guess; making the shift from "add things to the project in visual studio" to "add things to the cmake project and then regenerate the visual studio project"
not that hard for people used to makefiles, but for windows devs its a bit unusual
|neilg_||15:11||I suspect that people who don't rebuild using CMake were also trying to update FireBreath which would lead to those sorts of issues. Can't imagine any other reason for problems though!|
|taxilian||15:11||right; as long as you never need to build on another platform, update firebreath, etc, you're set
so if you decide to do things that way, please pray really really hard that all of our code is bug-free and you'll never need an update from us =]
|neilg_||15:11||If the code hasn't changed and the projects haven't changed it would be fine - and I suspect (though I have a sample size of 1 here!) that's what people new to FireBreath expect|
|taxilian||15:11||well, you have to remember that there are a lot of things that firebreath automatically generates for you
that you probably don't think about
.rc files, .rgs files, .h config files, etc
|neilg_||15:11||If somebody updates FireBreath they'd have to regenerate the projects using CMake - it would be silly to think you could get away with not doing that|
|taxilian||15:11||right. the problem is that when people try to just use the build files directly, they start updating their .vcproj files as well|
|emann||15:11||OK, so I got it working
but it wasn't easy
|taxilian||15:11||for the sake of saving a few minutes, maybe an hour or two, they cause themselves an extra day or more of work later trying to fix it again
emann: what was the problem?
|emann||15:11||I needed an .hgignore folder that would ignore the .vcproj files, just about everything from cmake (because many of the .cmake files used local directory references) and .sln files that also defined projects using local directory references|
|taxilian||16:11||you really didn't need that
you only need one directory
don't put anything else in your source control
|emann||16:11||Then I just re-ran prep2008.cmd on each machine to re-generate the cmake files and vcproj files|
|taxilian||16:11||if you want firebreath in your own source control, fine... but put it in a seperate repo
and don't expect that you will only run prep2008.cmd once per machine
that's not how cmake is designed to work
|emann||16:11||@taxilian I tried that the first time, but the projects were referencing source files outside of the /projects/ folder|
they are supposed to
that's why you regenerate the build/ directory on each computer
here is what I do: I have a code/ folder with firebreath/ and fbprojects/ in it
I run prep2008.cmd ..\fbprojects ..\fbbuild
and then I use the ..\fbbuild directory
you can be in any directory when you run prep2008.cmd; you don't have to be in firebreath root
you should *never*, and I repeat: NEVER NEVER NEVER NEVER NEVER store the build/ files in source control
andything in that directory
you don't need a special .hgingore for .vcproj files because you don't want any of it... just ignore the whole directory
you may of course ignore that advice, but you will wish you hadn't later on if you do
and I'm sorry I wasn't here to answer your question earlier when I could have saved you some work :-(
|neilg_||16:11||I concur ;)|
|emann||16:11||just FYI, that use of the prep2008 script is not in any of the documentation and would have saved me about an hour of extra work ...|
|taxilian||16:11||it is in there
but possibly not in a clear place
|emann||16:11||Not in the setup instructions. There are instructions to run prep2008.cmd examples to build the examples and just prep2008.cmd to build a new project|
|taxilian||16:11||The wiki can be updated by anyone registered on the site; we would appreciate it greatly and give you free tech support if you were willing to take some time to clarify it. Possibly a link to the relevant docs? I don't know. I'm not very good at docs.
the documentation is there
I am in the process of typing up a blog post on the subject as well
to try to clarify this issue
it has come up repeatedly recently
and again I do apologize :-(
|amackera||16:11||It's probably the most confusing thing to people new to the project
a blog post is a great idea
|taxilian||16:11||yeah; how can we fix that?
'cause I have to admit; if I were emann, I'd be pretty frustrated too :-/
|amackera||16:11||I'm not so sure... maybe a big warning message on the home page: "YOU MUST USE CMAKE TO DO YOUR STUFF."|
|taxilian||16:11||I will write up a CP post; we really need to find a way to explain it better in the docs, though|
|amackera||16:11||Or maybe in the prep docs something like "a typical FB dev session"
where the user runs prep, develops a bit, etc.
like a step by step thing?
|taxilian||16:11||it might be time to rewrite the "creating a new plugin project" docs
though someone (I think kylehuff) recently went through and improved them, I think we could do even better to start a new one
I really need to try a screencast one of these days as well
|amackera||16:11||i'm really not a big fan of screencasts, but i do know people who like them|
|taxilian||16:11||well, I'm not really either, but it would probably make things a lot more clear to someone to actually watch a basic plugin get created than it would be to read about it
emann: any suggestions you may have on how we can improve the documentation are welcome. If you have time to help that would be even better =]
|emann||16:11||After browsing most of the documentation, the first place I looked for step-by-step instructions was http://www.firebreath.org/display/documentation/Building+on+Windows
After I got the examples working, I tried building my own project, again following the instructions
But placing my project under source control caused problems because I didn't know which files to put under version control or where the projects were referencing things from
It took a lot of trial and error to figure out when the hard-coded local references were added, which is why I ended up placing different files in my .hgignore
it turns out, placing the entire build directory in my hgignore was a better route (as pointed out by a coworker)
But the idea that the /projects/ folder could be in a separate location entirely isn't something I came across .. i.e. why I said it wasn't well-documented
|taxilian||16:11||yeah. I'm writing a post about that right now
I'm sorry I haven't done so sooner
I never claimed it was well documented... just that it is in there somewhere =] we definitely need to improve that
|emann||16:11||the fbgen.py script added the projects directory automatically and referenced the src directory on the same level ... that's why I didnt make the "it can be located elsewhere" connection|
|taxilian||16:11||right; that's partially a throwback from before 1.2.0 when you couldn't locate it elsewhere
I will need to think about that a bit; maybe I can add something to the output of fbgen as well
|emann||16:11||Well it's a great system, and I really like the API
It's just that the setup instructions (particularly for someone just coming into the project) are not very well laid out, somewhat confusing, and incredibly frustrating in the end
|taxilian||16:11||I hope that it is useful enough to you to overcome the bad experience you had getting started =]|
|emann||16:11||It should be|
|taxilian||16:11||Please, please, please help us fix those things|
|emann||16:11||the bad experience was more with figuring out version control than the system itself
And I'll probably try to help, but right now I'm slammed elsewhere ...
|taxilian||16:11||see, the problem is that most of the documentation ends up getting written by one of the core developers; the problem with that is that things that seem obvious to us aren't obvious to you =]
stick around another 10 minutes and I'll have a blog post for you
|emann||16:11||Quick question, when did the FireBreath project start?|
|amackera||16:11||I think a year ago or so?|
|taxilian||16:11||the first commit was Sep 16, 2009
it's come a ways since then
|taxilian||16:11||Hope it helps|
|emann||16:11||It does, and (aside from not keeping FireBreath in the same source control tree) is pretty much exactly what I ended up with
Thanks for your help!
|amackera||16:11||whoa new blog theme
i like it!
|taxilian||17:11||yeah, its been there for all of about 5 minutes
but we needed a new one
I've been meaning to put a new one there for awhile
even bought one I liked, but then I couldn't get it to wrok
|amackera||17:11||I don't even know why PhoneGap has an IRC channel, there's never anybody around to help|
it takes a lot of work to make an IRC channel useful
and requires a community that is willing to help each other out
FireBreath is blessed to have such a community
|taxilian||17:11||1.3.1 is on the download site|
|amackera||17:11||oo ! sweet :D|
|taxilian||17:11||now I just have to go update ohloh and freshmeat... *sigh*|
|amackera||17:11||well i'm off for the night