[chromium-dev] Default.dll and toolstrips
Hi, the background for the toolstrips / bookmark bar isn't included in default.dll theme file. As a result, when you create themes, the bookmarks bar remains blue. I'm guessing the toolstrip has a .css file somewhere and i'm not sure about the bookmarks bar. Are there any plans to merge all of these backgrounds etc. into the default.dll file for the benefit of the people making themes? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Default.dll and toolstrips
The theming and extensions code is undergoing a number of changes right now, but yes, you should expect that these pieces will be part of themes. Erik On Mon, May 18, 2009 at 10:39 AM, Meok wrote: > > Hi, the background for the toolstrips / bookmark bar isn't included in > default.dll theme file. As a result, when you create themes, the > bookmarks bar remains blue. I'm guessing the toolstrip has a .css file > somewhere and i'm not sure about the bookmarks bar. > > Are there any plans to merge all of these backgrounds etc. into the > default.dll file for the benefit of the people making themes? > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: cryptoht.h not found
On Sat, May 16, 2009 at 12:13 AM, Mohamed Mansour wrote: > Weird, > > I just received this error while compiling a "fresh" build on linux. > Downloaded the tarball, and hammer (clean). The first error I saw on the > screen was: > cd: 1: can't cd to > /auto/filer28.mtvvolmtvhome51/chrome-svn/tarball/chromium/src/base > > Then it stated: > /home/m0/chromium/src/base/crypto/signature_verifier.h:11:22: error: > cryptoht.h: No such file or directory > > I checked my pkg-config --cflags nss which returned: > -I/usr/include/nss -I/usr/include/nspr > > I looked into it further and grep'd the gyp with mtvvolmtvhome51 and it > appeared in couple. I had to do runhooks: > gclient runhooks --force > > So my question, why does the tarball come with bad .scons files? Why doesn't > the gclient sync regenerate them? > Maybe add another step to the linux process that will tell the user to > regenerate them after initial build. Many users having this problem it > seems. I guess it's because when we used "gclient sync" to check out the source tree in the tarball, and that "gclient sync" command did runhooks at the end and generated .scons files that are only good on that computer. I don't know why another "gclient sync" didn't regenerate them. Perhaps because the timestamps of the .scons files were newer than the timestamps of the .gyp files? Wan-Teh --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [extensions] Moved all tasks to issue tracker
Thanks for doing this. Very useful. Erik On Mon, May 18, 2009 at 9:38 AM, Aaron Boodman wrote: > > FYI, I've moved all the tasks I'm aware of for the extensions project > to the normal issue tracker. Here's a nice query: > > > http://code.google.com/p/chromium/issues/list?q=Area:extensions&sort=pri+size&colspec=ID%20Pri%20Area%20Status%20Summary%20Owner%20Size > > Here is how I filled out the fields: > > P1: Some other team is blocked on this, or a high frequency crash that > is already showing up on crash reports > P2: Everything besides P1 that we want to do for a v1 of extensions > P3: Other things > > Size-Small: 1 day > Size-Medium: Between 1 day and 1 week > Size-Large: More than 1 week > > And I also assigned owners in cases where people were obviously the > one to do the work, or they had already started. > > > - a > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [extensions] Moved all tasks to issue tracker
FYI, I've moved all the tasks I'm aware of for the extensions project to the normal issue tracker. Here's a nice query: http://code.google.com/p/chromium/issues/list?q=Area:extensions&sort=pri+size&colspec=ID%20Pri%20Area%20Status%20Summary%20Owner%20Size Here is how I filled out the fields: P1: Some other team is blocked on this, or a high frequency crash that is already showing up on crash reports P2: Everything besides P1 that we want to do for a v1 of extensions P3: Other things Size-Small: 1 day Size-Medium: Between 1 day and 1 week Size-Large: More than 1 week And I also assigned owners in cases where people were obviously the one to do the work, or they had already started. - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Is creating a custom PDF rendering backend a sound idea?
Here's the blog of the guy who seems to do the most work on the Windows+Cairo WebKit build: http://lwat.blogspot.com/ He occasionally posts status updates. On Mon, May 18, 2009 at 1:10 AM, Ben Harper wrote: > > Thanks for all the feedback. I think I'll give the plain WebKit + > Cairo > thing a go. > > On May 18, 3:06 am, Joel Stanley wrote: >> On Mon, May 18, 2009 at 05:46, Evan Martin wrote: >> > WebKit (but not the Chromium port) already targets Cairo via GTK, and >> > Cairo supports PDF output. I'm not sure anyone's using it for PDF >> > output yet though. >> >> Midori uses it. 'midori -shttp://path.to/website'will output a pdf >> of the site. >> >> http://www.twotoasts.de/index.php?/pages/midori_summary.html >> >> Joel > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Destruction of C++ objects attached to V8 objects
On Sat, May 16, 2009 at 12:10 PM, Marshall Greenblatt <
magreenbl...@gmail.com> wrote:
> On Sat, May 16, 2009 at 1:27 PM, Mike Belshe wrote:
>
>> You can create a weak reference to the object, and when the object is GC'd
>> in v8, the weak reference handler will get called. Check out the v8.h
>> documentation for weak references and it will probably make sense.
>> Mike
>>
>
> Hi Mike,
>
> So I guess the code would look like this:
>
> void MyDestructor(Persistent object, void*)
> {
> // do whatever cleanup is required
> }
>
> static v8::Handle MyCallback(const v8::Arguments& args) {
> // Create a new V8 object template with one internal field.
> v8::Handle my_templ = v8::ObjectTemplate::New();
> my_templ->SetInternalFieldCount(1);
>
> // Create a new MyClass instance.
> MyClass* my_class = ...;
>
> // Create a new persistent V8 object.
> v8::Persistent obj =
> v8::Persistent::New(my_templ->NewInstance());
>
> // Attach the MyClass instance to the V8 object.
> obj->SetInternalField(0, v8::External::New(my_class));
>
> // Make the V8 object a weak reference and assign the destructor.
> obj.MakeWeak(NULL, &MyDestructor);
>
> return obj;
> }
>
Yes, that code looks about right. I'd recommend testing it out in test
programs so you can see it all in action.
> In what circumstances, if any, would it be appropriate to make the
> ObjectTemplate a weak reference instead of the Object? Would any Objects
> created with a weak reference ObjectTemplate automatically have the
> destructor called for them?
>
In general, don't go too crazy with Weak handles. Use it when you need it.
Cases where you need it include:
a) You're churning through lots of large C++ objects, causing memory
usage to skyrocket because V8 doesn't realize the C++ side is holding onto
so much memory
b) You're holding onto some system resource (like a file, lock, etc) that
you want to clean up quickly.
I can't imagine cases where you'd want the ObjectTemplate itself to be weak
much - because I can't envision a case where (a) or (b) above is relevant to
the ObjectTemplate. But maybe I lack vision :-)
Mike
>
>
> Thanks,
> Marshall
>
>
>>
>>
>> On Fri, May 15, 2009 at 8:38 PM, Marshall Greenblatt <
>> magreenbl...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> I'm seeking a way to trigger destruction (or reference decrement) of a
>>> C++ object attached to a V8 object when the V8 object is destroyed. For
>>> instance, consider the following code where I create and return a new V8
>>> object in a function template callback:
>>>
>>> static v8::Handle MyCallback(const v8::Arguments& args) {
>>> // Create a new V8 object template with one internal field.
>>> v8::Handle my_templ = v8::ObjectTemplate::New();
>>> my_templ->SetInternalFieldCount(1);
>>>
>>> // Create a new MyClass instance.
>>> MyClass* my_class = ...;
>>>
>>> // Create a new V8 object.
>>> v8::Local obj = my_templ->NewInstance();
>>>
>>> // Attach the MyClass instance to the V8 object.
>>> obj->SetInternalField(0, v8::External::New(my_class));
>>>
>>> return obj;
>>> }
>>>
>>> How can I clean up the MyClass instance when the associated V8 object
>>> destroyed? Is there some way that I can assign a destructor callback for
>>> the V8 object?
>>>
>>> Thanks,
>>> Marshall
>>>
>>> >>>
>>>
>>
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] checkdeps.py now also scans .m and .mm files and #imports
I just commited http://src.chromium.org/viewvc/chrome?view=rev&revision=16273 which expands set of things that checkdeps.py looks at by Mac-specific files. Just during the review it caught a small issue, an #include "chrome/common/..." in app/ which is forbidden. Now it should have full cross-platform coverage. Paweł --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: problem with gclient config on windows vista
No problem. Yes, depot_tools keeps its own copy of svn and python. "Reinstalling" is an overstatement, it just puts it into depot_tools with svn.bat and python.bat. :) M-A On Sun, May 17, 2009 at 1:49 PM, Eeyore wrote: > >> Try (assuming you already have svn on your system) >> rd /q /s depot_tools >> svn co http://src.chromium.org/svn/trunk/tools/depot_tools/ >> >> It seems like an issue with svn version clash. Yay. > > Wow, that seems to have worked. When I ran gclient after pulling > depot_tools from SVN, in actually *reinstalled* SVN and python, both > of which already exist on my system. I have no idea why it would do > that, but now "gclient sync" is working so I'm up and running. > > THANKS!! > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Is creating a custom PDF rendering backend a sound idea?
Thanks for all the feedback. I think I'll give the plain WebKit + Cairo thing a go. On May 18, 3:06 am, Joel Stanley wrote: > On Mon, May 18, 2009 at 05:46, Evan Martin wrote: > > WebKit (but not the Chromium port) already targets Cairo via GTK, and > > Cairo supports PDF output. I'm not sure anyone's using it for PDF > > output yet though. > > Midori uses it. 'midori -shttp://path.to/website'will output a pdf > of the site. > > http://www.twotoasts.de/index.php?/pages/midori_summary.html > > Joel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
