IRC Log Viewer » #firebreath » 2013-01-04

IRC Nick Time (GMT-7) Message
vshih 00:01 taxilian: all right, thanks
Hibernatus34 05:01 hi
I want to generate pictures with my plugin and display them in HTML, without uploading them to the server. So far, the only solution i got is encoding them as base64 data URIs, and for older browsers (<= IE8 since IE8 is limited to 32KB URIs), i use a temporary file and file://. In IE >= 7 i need to save the temporary file in a low integrity folder for protected mode. I'm not sure i can do it in WinXP. Is there a better way
Another question : what would a good strategy for a self updating plugin ? FF and Chrome seem to lock the DLL, so it requires closing the browser. If i ignore updates of FireBreath itself, i could put all the logic in a separate DLL.
Hibernatus34 09:01 Is there a reason for installing in Roaming instead of Local ?
taxilian 11:01 Hibernatus34: there is a way to find a local filesystem location you can always write to
if you want to try to do it that way
but it's a bit of a security consideration to be exposing file paths to the DOM
however, the only other option besides the two you've mentioned that I know is to embed a web server (there is actually one in the source tree) that will serve up the files you want from a random port. The problem with this approach is that it will always be a HTTP server (since you can't securely give it an ssl cert) so if you're on a website that is https you'll get security warnings from the http images
Hibernatus34 11:01 Thanks taxilian. An HTTP server seems a bit overkill.
Even though i suppose it's very lightweight :)
taxilian 11:01 yeah, but I've done it before =]
Look at SystemHelper.h
it has a GetLocalAppDataPath (or somethign similar) that will return a path where you have rights to write to
Hibernatus34 11:01 In fact solutions don't work for one damned case : IE8 on XP. I just can't get a low integrity directory. So i'll have a look at your solution.
i meant *my* solutions :)
taxilian 11:01 IE8 on XP you can write anywhere in the user's home directory
Hibernatus34 11:01 but you can't access through file://
taxilian 11:01 the path you'll be given by the function I told you will return a path in AppData/LocalLow on vista and later, a path in Local Settings in XP
why not?
Hibernatus34 11:01 while in IE9 in win7 i can (can't try IE8 in vista seven right now)
i tried and it didn't work
taxilian 11:01 interesting. I don't like the idea of exposing filesystem paths through the plugin so I've never actually tried that
but that will give you a reliable way to get a cross-platform place you can write to, anyway
Hibernatus34 11:01 yes, of course. in fact the temp dir is good too (for temp data of course), it becomes Temp/Low automatically
taxilian 11:01 hmm. yeah, I could see that working
I think there is a gettempdir there as well
Hibernatus34 11:01 i wish IE8 supported more than 32KB data URIs
yes that must be the function i used
there is another solution : filters.item("DXImageTransform.Microsoft.AlphaImageLoader").src = "file://blah.png"
taxilian 11:01 haven't tried that
Hibernatus34 11:01 But this is hell :)
taxilian 11:01 https://gist.github.com/1289031
that's an example of getting a localappdatapath
Hibernatus34 11:01 it works. MS forbbids img.src = "file://" but not the thing with DXImageTransform
taxilian 11:01 huh
Hibernatus34 11:01 thanks for the reminder. i forgot i could use FB functions for that
taxilian 11:01 https://github.com/firebreath/FireBreath/blob/master/src/PluginCore/SystemHelpers.h
main advantage is that they are cross platform
also main advantage of the localappdatapath function is that it works on both XP and Vista+; that takes a little bit of magic
Hibernatus34 11:01 yeah, some functions weren't in shell32.dll in XP, were they ?
taxilian 11:01 correct
and the equivilent ones won't give you a locallow path
Hibernatus34 11:01 if i decided to turn my HTML GUI into a visual plugin, would it be easy, given i've already developed with GDI32 and GDI+ ? I mean, is it just a matter of implementing 2 or 3 even handlers and acquire a DC ?
even->event
taxilian 11:01 hmm. more or less, yes, if that's what you want to do
if you use a windowed plugin then you get an HWND
and you just need to draw to it
if you use windowless then you are given an hDC to draw to whenever the browser tells you to draw and you can request a refresh
windowless has the advantage of allowing other DOM elements to layer over the top of you
Hibernatus34 11:01 a windowed plugin wouldn't do since i'd like to keep HTML buttons over the plugin
taxilian 11:01 then you'll want windowless
Hibernatus34 11:01 so the browser passes me a clipped DC or a DC + a RECT ? Sounds not too difficult.
taxilian 11:01 something along those lines, yes =] I have an example, hang on
Hibernatus34 11:01 thanks a lot
taxilian 11:01 huh; I could swear it was in a gist somewhere, but I'm only finding the mac one
may take me a couple of minutes
Hibernatus34 11:01 :)
no problem, i could take the time to search on my own too. i've been lazy recently because i had a lot of work, plus an urgent PoC to release. (thanks to FB we'll avoid developing a Java applet !)
taxilian 12:01 https://gist.github.com/1099740
that's got the mac code too
and it's just a blitter; you give it a pixel buffer and it draws it
but it shows how to detect whether you're windowed or windowless and draw in either
Hibernatus34 12:01 great. thanks again.
taxilian 12:01 glk
Hibernatus34 12:01 had another question :) when you say : "Don't add files, dependencies, or link libraries to your project from inside your IDE". Does it mean i should modify cmake script so that the prep script will make these changes itself ?
taxilian 12:01 correct
it's not a big deal to do things fast for testing, of course, but your build directory should be disposable
Hibernatus34 12:01 what file should i look at first ? :)
taxilian 12:01 if it's cross platform, modify CMakeLists.txt
if it's windows specific, modifiy Win/projectDef.cmake
Hibernatus34 12:01 project file is not disposable, is it ? :)
taxilian 12:01 you mean your project directory where your PluginConfig.cmake and all of your source files are?
that one is usually not disposable, no =]
but the build/ directory where all the .sln, .vcproj, etc files are
Hibernatus34 12:01 oh, sorry, i didn't even notice vcproj files where in build/
ok, then i understand exactly what you meant :)
taxilian 12:01 yeah
cmake builds all of the ide related files and configured / generated files in build/
so if you modify the .sln or the .vcproj and then have to reprep you'll lose any changes
may seem a bit of a hassle when you only support one platform, but consider how much harder it would be to even just support all the different variants of visual studio, much less supporting mac and linux...
Hibernatus34 12:01 i understand
vshih 12:01 re: my multiple binaries per OS, etc. issue. I discovered that 32-bit vs. 64-bit seems to be the only issue, at least on linux. I still need to investigate the mac issue.
jshanab 14:01 Can we do "fat" binaries on linux? or is it the loader the OS that allows that.
taxilian 14:01 not as far as I know
but if you find a way let me know =]
jshanab 14:01 sure .. ;-)
alyoshak 14:01 Trying to do the Mac version now. But running into a strange error(s) when running prepmac.sh. Found one very similar issue online. Had to do with location of the Xcode installation. "not able to compile a simple test program".
Here's the pastebin of the error: http://pastebin.com/TfSSiKb4
taxilian 14:01 alyoshak: what version of cmake are you using?
alyoshak 14:01 I just downloaded the most recent version.
taxilian 14:01 type cmake --version
just to be safe
and tell me what it says
alyoshak 14:01 Ok.
2.8.10.2
taxilian 14:01 what version of Mac OS are you on?
alyoshak 14:01 10.7.5
jshanab 14:01 I was adding the OSX_SYSROOT to the commandline for the prep, does he need to do that also (my little python script)
taxilian 14:01 does the directory /Applications/Xcode.app/Contents/Developer/SDKs/MacOSX10.7.sdk exist?
what version of xcode?
alyoshak 14:01 Looking . . .
taxilian 14:01 alyoshak: looking at line 20 of that paste (and thanks for using a pastebin =]), it looks like you still have an old cmake that is getting used as well
delete the old one to make sure it's completely gone
alyoshak 14:01 Nope. Goes as far as "Developer". But no "SDKs" under Developer
taxilian 14:01 xcode version?
alyoshak 14:01 You're the one that got me to using pastebin some time ago! :)
That sounds like pretty good news. I just need to cause the newly installed cmake to be invoked?
taxilian 14:01 maybe, but maybe that's not all
alyoshak 14:01 just installed latest Xcode from ITunes. But I'll check.
taxilian 14:01 definitely need to get rid of the old one entirely, though
you may need to load xcode and download the command-line tools if you haven't already
alyoshak 14:01 I assumed the new wd overwrite the old (of course). Do you know what file I cd search for to find Cmake?
jshanab 14:01 My command and path on my mac : ../common/FireBreath/prepmac.sh MVSArchivePlayer build/MVSArchivePlayer -D CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -D CMAKE_OSX_DEPLOYMENT_TARGET=10.7 -D CMAKE_OSX_ARCHITECTURES=x86_64
alyoshak 14:01 Ok. Some things to do now. I'll be back if these don't fix it. Thx.
taxilian 14:01 alyoshak: yeah, cmake installer on mac has some weaknesses
jshanab 14:01 The last option is only becuase I have external libs not yet built for 32bit
taxilian 14:01 looks like your old version is installed in /Applications/CMake\ 2.8-6.app
you may need to delete the cmake symlinks in /usr/bin/
as well
alyoshak 14:01 4.5.2 is the Xcode version
taxilian 14:01 make sure command line utils are installed
alyoshak 14:01 Wow. Wd not have thought of that. Not a power mac user by any stretch.
Ok.
taxilian 14:01 well, I'm off for awhile. good luck y'all