IRC Log Viewer » #firebreath » 2010-11-19

IRC Nick Time (GMT-7) Message
tempie 01:11 morning
nitrogenycs 01:11 morning
DFUN 01:11 morning
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..
TomL_berlin 07:11 meh
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?
kalev 12:11 Good idea
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?
amackera 14:11 yep
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
taxilian 16:11 emann: right
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
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 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 =]
I understand
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
emann 16:11 fantastic! Thanks
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
taxilian 17:11 building firebreath-1.3.1
amackera 17:11 I don't even know why PhoneGap has an IRC channel, there's never anybody around to help
taxilian 17:11 lol
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
amackera 17:11 :D
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
g'night all!