[chromium-dev] Re: Does Chromium MacOSX always create NSButtonCell for each html input submit button
Google.com uses custom styling, so chances are a NSButton is not being
created since you can't style OS X widgets (without considerable
resource hacking, at least). It would be better if you just made a
local HTML test page for this.
On Fri, Oct 9, 2009 at 5:02 PM, hap 497 wrote:
>
> Sorry, maybe I used a wrong term in asking my question.
>
> I think I am looking for the code which chormium create a native UI
> widget for each html input submit button in the html source. I assume
> chromium needs to use 1 native UI widget for each input submit button
> so that each one of them can respond to user clicking.
>
> I think I should have asked for 'NSButton' instead?
>
> Regarding www.google.com, it think it does use input submit button, so
> why I am not see chromium calling ThemeChromiumMac.mm's paintButton()
> or button() functions for www.google.com?
> name=btnI type=submit value="I'm Feeling Lucky" class=lsb>
>
> Thank you.
>
>
> On Fri, Oct 9, 2009 at 2:20 PM, Avi Drissman wrote:
>> Oh, and google.com has custom buttons which may or may not go through that
>> function at all (I haven't checked).
>>
>> Avi
>>
>> On Fri, Oct 9, 2009 at 4:44 PM, Avi Drissman wrote:
>>>
>>> You found it.
>>>
>>> At the beginning of the function you see:
>>>
>>>> static NSButtonCell *buttonCell;
>>>> //...
>>>> if (!buttonCell) {
>>>
>>> There is only one cell created ever, and it's reused.
>>>
>>> Avi
>>>
>>> On Fri, Oct 9, 2009 at 4:20 PM, hap 497 wrote:
>>>>
>>>> Hi,
>>>>
>>>> Does Chromium MacOSX always create NSButtonCell for each html input
>>>> submit button?
>>>> I put a printf() statement in ThemeChromiumMac.mm:
>>>> static NSButtonCell* button(ControlPart part, ControlStates states,
>>>> const IntRect& zoomedRect, float zoomFactor).
>>>>
>>>> It gets called and create a NSButtonCell for a input submit button
>>>> when i load this test page:
>>>>
>>>>
>>>>
>>>>
>>>> But when I load www.google.com (which has 2 input buttons), I don't
>>>> see the same button() function gets called to create NSButtonCell.
>>>>
>>>> Can you please tell me where is the code which create native gui
>>>> widget for input submit button for the case of www.google.com?
>>>>
>>>> Thank you.
>>>>
>>>> >>>
>>>
>>
>>
>
> >
>
--
Stefan Nuxoll
--~--~-~--~~~---~--~~
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: Linux HTML5, List of Libraries
I was under the impression that going to 64-bit isn't just a simple switch in build instructions, there were some components (V8, maybe) that weren't x64 compatible. Anyone else want to comment on this? (Oops, hit Reply instead of Reply All, silly gmail) On Tue, Sep 8, 2009 at 12:53 PM, Lei Zhang wrote: > > "Chromium is currently 32-bit x86 only" ... sounds like we need to > update the build instructions for 64-bit. > > On Tue, Sep 8, 2009 at 11:47 AM, Evan Martin wrote: >> >> If http://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites >> doesn't answer your question, please ask it again and/or update that >> page so it does. :) >> >> On Tue, Sep 8, 2009 at 5:29 AM, Luis Canaval wrote: >>> >>> Hello, I'm sorry if this is not the right place for this question bue >>> here I go. >>> Can any of the Linux Version's developers share a list of all the >>> libraries, versions and file names needed for Chromium/Chrome, as >>> dependencies, in Linux 64 bits? >>> Specially those needed for Text rendering (Specially japanese, Korean, >>> Chinese, etc.) and HMLT5 Video and audio tags. I have been trying for >>> a few days now and can't make those characteristics work. >>> >>> Thank you so much in advance. >>> >>> I'm using Archlinux 2009.2 64 Bits edition and I'm familiar with linux >>> development tools, I'm not an expert but I can also help doing >>> specific test under this platform if by any chance needed :D. >>> >>> > >>> >> >> > >> > > > > -- Stefan Nuxoll --~--~-~--~~~---~--~~ 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: Mac Chrome launch speed = the awesome
I wish I had an intel mac now, but alas that's pretty damned impressive for an application with a native cocoa UI. It's good to see the Linux and Mac ports getting the attention they deserve as late. So I guess I'll take this time to throw in my congratulations to you chrome guys too On Mon, Sep 7, 2009 at 11:11 PM, Adam Barth wrote: > > Dear Mac folks: > > Thanks for making Mac Chrome launch ridiculously fast. I really enjoy > that, on my laptop, the main window is painted before the dock icon > has even crested its first bounce. > > Adam > > > > -- Stefan Nuxoll --~--~-~--~~~---~--~~ 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: Login name auto-fill code
Slightly offtopic, but what are you planning to use as the store on OS X? The keychain? On Fri, Jun 12, 2009 at 11:00 AM, Stuart Morgan wrote: > > On Fri, Jun 12, 2009 at 7:46 AM, Lucius Fox wrote: >> Can you please tell me where is the code for 'auto-fill' login name >> for Gmail on MacOS X? > > What part specifically? There are a number of classes involved in > login autofill (assuming you are talking about the password manager, > and not Gmail itself filling the username based on cookies). > > I'm still actively writing the password storage system on the Mac, so > if you are asking because you want to do development in that area > please follow up with me off-list. If you just want to write code > using the password system, you'd want to use the cross-platform > interfaces: either PasswordManager/PasswordFormManager, or > PasswordStore, depending on what you are trying to accomplish. > > -Stuart > > > > -- Stefan Nuxoll --~--~-~--~~~---~--~~ 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: Exclude Tab Bar Area
I have the same issue with the Windows language bar and the SCIM toolbar, I don't think there's really any way to fix this though. On Thu, Jun 11, 2009 at 1:52 PM, Peter wrote: > > Is this possible in chrome currently (perhaps some theme hack would > allow this??) or through and extension? > > I want to exclude the tab bar from using some space near the window > controls in the upper left corner of the window. > This space is permanently occupied by winamp on my system (set to > always on top). So If I have tabs spanning the title bar, some are > blocked by winamp. > > see this image (picasaweb): > http://lh3.ggpht.com/_WL2DyBcS1cw/SjFVU9X6-CI/AKs/EGtobJR828k/s800/Capture.PNG > > please advise. > > > -- Stefan Nuxoll --~--~-~--~~~---~--~~ 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: Adding Mac OS X Spellchecker to Chromium
ince >> >>> > >> there is >> >>> > >> no need to create and manage the char** suggestions variable to >> >>> > >> pass >> >>> > >> to >> >>> > >> hunspell, as NSSpellChecker can give us an >> >>> > >> easy-to-iterate-through >> >>> > >> NSArray. >> >>> > >> Probably just an #if defined(OS_MACOSX) would suffice here, since >> >>> > >> the >> >>> > >> code here will be wholly different. >> >>> > >> -for AddWord, their probably isn't as much of a need to abstract >> >>> > >> the >> >>> > >> hunspell specific code (it's all hunspell code), so just an #if >> >>> > >> defined( >> >>> > >> OS_MACOSX)+language support check would suffice. >> >>> > >> -The other public methods all deal with language selection and >> >>> > >> querying, >> >>> > >> which should remain the same, since the OS X spellchecker only >> >>> > >> supports a >> >>> > >> subset of the languages supported by hunspell. (there may need to >> >>> > >> be >> >>> > >> a >> >>> > >> little bit of code to translate between the codes for supported >> >>> > >> languages so >> >>> > >> that the built-in spellchecker always gets used when it should, >> >>> > >> but >> >>> > >> this >> >>> > >> should be a relatively simple matter. >> >>> > >> -The private method IsValidContraction could call the same new >> >>> > >> private >> >>> > >> method as defined above. >> >>> > >> >>> > >> -This way, the public interface stays the same and the mac folks >> >>> > >> get >> >>> > >> to >> >>> > >> use their own dictionary. >> >>> > >> -The newly added autocorrection code should work just the same as >> >>> > >> before, >> >>> > >> as it relies on SpellCheckWord. >> >>> > >> -also, [NSApplication sharedApplication] needs to be called >> >>> > >> before >> >>> > >> the the >> >>> > >> built in spellchecker is used. I'm not sure of where the best >> >>> > >> place >> >>> > >> to put >> >>> > >> this call is. >> >>> > >> >>> > >> The upside to doing it this way is that it should be relatively >> >>> > >> easy >> >>> > >> to >> >>> > >> modify the spellchecking code for any one platform without >> >>> > >> breaking >> >>> > >> any >> >>> > >> other. >> >>> > >> The main downside that I can see for doing it this way is that >> >>> > >> for >> >>> > >> languages that are supported by OS X, we will be keeping a >> >>> > >> hunspell >> >>> > >> object >> >>> > >> around that we don't need, at least until the language changes to >> >>> > >> something >> >>> > >> hunspell supports and os x doesn't >> >>> > >> >>> > >> There are a few additional features that the OS X spellchecker >> >>> > >> supports >> >>> > >> that need some discussion. >> >>> > >> 1. Grammar checker: I know I've seen some talk about adding this >> >>> > >> to >> >>> > >> chromium somewhere. The OS X spellchecker also has support for >> >>> > >> checking the >> >>> > >> grammar of a string (only in 10.5+), so that is something to keep >> >>> > >> in >> >>> > >> mind >> >>> > >> when that stage is reached. >> >>> > >> 2. Spelling Panel: The OS X spellchecker has support for a >> >>> > >> "Spelling >> >>> > >> Panel". Similar to spellchecking in most word processors, this >> >>> > >> provides a >> >>> > >> seperate GUI Panel that allows for checking a whole paragraph in >> >>> > >> one >> >>> > >> go. The >> >>> > >> main problems here are that this is functionality that is in no >> >>> > >> way >> >>> > >> matched >> >>> > >> by the Windows or Linux Builds. Additionally, it would require >> >>> > >> some >> >>> > >> way of >> >>> > >> identifying the source of each word, since the spelling panel >> >>> > >> allows >> >>> > >> for the >> >>> > >> creation of a list of ignored words, which are unique to a >> >>> > >> document. >> >>> > >> In the >> >>> > >> case of chromium, a document would correspond to a given >> >>> > >> textfield, >> >>> > >> most >> >>> > >> likely. The NSSpellChecker API provides a function >> >>> > >> (uniqueSpellDocumentTag) >> >>> > >> to generate tags for this purpose, but a way would have to be >> >>> > >> found >> >>> > >> to >> >>> > >> generate and match these tags up, which could be complicated >> >>> > >> (although I >> >>> > >> admit that I've not spent a lot of time looking at the code that >> >>> > >> would need >> >>> > >> to be altered to make this aspect of the spelling panel >> >>> > >> function). >> >>> > >> >>> > >> Any thoughts would be great. Thanks, >> >>> > >> >>> > >> -Paul Wicks >> >>> >> >>> >> >> >> >> >> >> > >> >> >> > >> > >> > >> > -- >> > Mike Pinkerton >> > Mac Weenie >> > pinker...@google.com >> > >> > > >> > >> >> > > > > > -- Stefan Nuxoll --~--~-~--~~~---~--~~ 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 there any way to change the default (i.e. default.dll) theme DLL?
How about a compile-time define instead? then it's a simple matter of adding a -DTHEME_DLL my.dll On Tue, Jun 9, 2009 at 10:51 PM, Daniel Cowx wrote: > > Yeah, I could change the value in resource_bundle_win.cc and wrap it > in a PP directive for my own build, but it becomes such a pain to > maintain this over time (merging gets annoying). It would be easier if > I didnt have to do this via a PP directive for my own build. > > Question: > Does anyone have objections to including a default param in the call > to ResourceBundle::LoadThemeResources() that causes default.dll to be > loaded by default? Alternatively, since default params are frowned > upon, I could provide a wrapper function in ResourceBundle to > accomplish the same end. > > -Daniel > > On Jun 9, 9:36 pm, dhhwai wrote: >> I think the answer is no for an official compile of Google Chrome. >> The default.dll is hardcoded in app/resource_bundle_win.cc. >> >> But for your own compile, does changing the hardcoded value in app/ >> resource_bundle_win.cc count as a solution? >> >> On Jun 9, 9:28 pm, Daniel Cowx wrote: >> >> >> >> > ResourceBundle::LoadThemeResources() always loads default.dll from >> > DIR_THEMES. Other than overriding DIR_THEMES via the PathService, is >> > there another way to change the name of the DLL? > > > -- Stefan Nuxoll --~--~-~--~~~---~--~~ 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: recursive directory watcher on linux.
Mmm, the last commit was at 2008-10-20. So it does unfortunately look like using inotify would be for the best. 2009/6/3 Dan Kegel > gamin is probably closer to usable, but I'm a bit nervous about > depending on it. It looks like the JDS guys found a performance bug > last year > http://mail.opensolaris.org/pipermail/jds-review/2008-March/002295.html > but no new release of gamin has appeared in > http://www.gnome.org/~veillard/gamin/sources/ > - Dan > > On Wed, Jun 3, 2009 at 11:03 AM, Stefan Nuxoll > wrote: > > There is a rewrite (or cleaned up version, I'm not sure) maintained by > GNOME > > called gamin. > > > > 2009/6/3 Dan Kegel : > >> FAM is pretty old, and didn't have a sterling reputation for > scalability. > >> inotify would probably be better. > >> (The FAM mailing list at SGI appears to be dead...?) > >> > >> On Wed, Jun 3, 2009 at 10:56 AM, Stefan Nuxoll > >> wrote: > >>> Since we're using GTK for the Linux port would there be any reason not > >>> to use FAM (File Alteration Monitor) which supports things like this? > >>> Yet another dependency for users of other DE's, but most of them > >>> probably won't use chromium due to GTK anyway. > >>> > >>> 2009/6/3 Dan Kegel : > >>>> Indeed. And because it's not recursive, you have to use inotify on > each > >>>> directory in the tree you're watching. Bleah. > >>>> > >>>> One example use is wine, which did have to define its own data > >>>> structure, I think: > >>>> http://source.winehq.org/git/wine.git/?a=history;f=server/change.c > >>>> > >>>> On Wed, Jun 3, 2009 at 10:16 AM, Stefan Nuxoll > >>>> wrote: > >>>>> > >>>>> inotify is a piece of crap, you can only monitor a directory, from > >>>>> that you have to reread the listing and see what's changed for > >>>>> yourself. > >>>>> > >>>>> 2009/6/3 Paweł Hajdan Jr. : > >>>>>> > >>>>>> Looks like it's not that simple. Nobody responded. :-/ > >>>>>> > >>>>>> I analyzed inotify-tools source and they do everything on paths. Of > >>>>>> course that means a lot of careful updating etc, but should work in > >>>>>> lack of more elegant solution. > >>>>>> > >>>>>> Paweł > >>>>>> > >>>>>> On Sun, May 24, 2009 at 20:47, j.din...@gmail.com < > j.din...@gmail.com> > >>>>>> wrote: > >>>>>>> I am trying to make a patch for recursive directory watcher on > linux > >>>>>>> using inotify event. > >>>>>>> > >>>>>>> When a new directory under watched directory is created, inotify > >>>>>>> event > >>>>>>> only gives me event->name relative to the watched directory. > >>>>>>> This makes it difficult to get the inode number of new directory > >>>>>>> because I am keeping track of watched inode numbers so far. > >>>>>>> > >>>>>>> I need to get "/xxx/yyy/newDirectory" from bare "newDirectory" that > >>>>>>> inotify event gives me so that I can get the inode number for > >>>>>>> newDirectory and then in turn update my watched inode structure. > >>>>>>> > >>>>>>> What would be a good way to get the absolute path of a new event > that > >>>>>>> inotify just reported without having to maintain my own data > >>>>>>> structure, i.e without having data structure that keeps watch > >>>>>>> descriptor and it's watched path? > >>>>>> > >>>>>> > > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Stefan Nuxoll > >>>>> > >>>>> >>>> > >>>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> Stefan Nuxoll > >>> > >> > > > > > > > > -- > > Stefan Nuxoll > > > > > > > > > > > -- Stefan Nuxoll --~--~-~--~~~---~--~~ 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: recursive directory watcher on linux.
There is a rewrite (or cleaned up version, I'm not sure) maintained by GNOME called gamin. 2009/6/3 Dan Kegel : > FAM is pretty old, and didn't have a sterling reputation for scalability. > inotify would probably be better. > (The FAM mailing list at SGI appears to be dead...?) > > On Wed, Jun 3, 2009 at 10:56 AM, Stefan Nuxoll wrote: >> Since we're using GTK for the Linux port would there be any reason not >> to use FAM (File Alteration Monitor) which supports things like this? >> Yet another dependency for users of other DE's, but most of them >> probably won't use chromium due to GTK anyway. >> >> 2009/6/3 Dan Kegel : >>> Indeed. And because it's not recursive, you have to use inotify on each >>> directory in the tree you're watching. Bleah. >>> >>> One example use is wine, which did have to define its own data >>> structure, I think: >>> http://source.winehq.org/git/wine.git/?a=history;f=server/change.c >>> >>> On Wed, Jun 3, 2009 at 10:16 AM, Stefan Nuxoll wrote: >>>> >>>> inotify is a piece of crap, you can only monitor a directory, from >>>> that you have to reread the listing and see what's changed for >>>> yourself. >>>> >>>> 2009/6/3 Paweł Hajdan Jr. : >>>>> >>>>> Looks like it's not that simple. Nobody responded. :-/ >>>>> >>>>> I analyzed inotify-tools source and they do everything on paths. Of >>>>> course that means a lot of careful updating etc, but should work in >>>>> lack of more elegant solution. >>>>> >>>>> Paweł >>>>> >>>>> On Sun, May 24, 2009 at 20:47, j.din...@gmail.com wrote: >>>>>> I am trying to make a patch for recursive directory watcher on linux >>>>>> using inotify event. >>>>>> >>>>>> When a new directory under watched directory is created, inotify event >>>>>> only gives me event->name relative to the watched directory. >>>>>> This makes it difficult to get the inode number of new directory >>>>>> because I am keeping track of watched inode numbers so far. >>>>>> >>>>>> I need to get "/xxx/yyy/newDirectory" from bare "newDirectory" that >>>>>> inotify event gives me so that I can get the inode number for >>>>>> newDirectory and then in turn update my watched inode structure. >>>>>> >>>>>> What would be a good way to get the absolute path of a new event that >>>>>> inotify just reported without having to maintain my own data >>>>>> structure, i.e without having data structure that keeps watch >>>>>> descriptor and it's watched path? >>>>> >>>>> > >>>>> >>>> >>>> >>>> >>>> -- >>>> Stefan Nuxoll >>>> >>>> >>>> >>>> >>> >> >> >> >> -- >> Stefan Nuxoll >> > -- Stefan Nuxoll --~--~-~--~~~---~--~~ 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: recursive directory watcher on linux.
Since we're using GTK for the Linux port would there be any reason not to use FAM (File Alteration Monitor) which supports things like this? Yet another dependency for users of other DE's, but most of them probably won't use chromium due to GTK anyway. 2009/6/3 Dan Kegel : > Indeed. And because it's not recursive, you have to use inotify on each > directory in the tree you're watching. Bleah. > > One example use is wine, which did have to define its own data > structure, I think: > http://source.winehq.org/git/wine.git/?a=history;f=server/change.c > > On Wed, Jun 3, 2009 at 10:16 AM, Stefan Nuxoll wrote: >> >> inotify is a piece of crap, you can only monitor a directory, from >> that you have to reread the listing and see what's changed for >> yourself. >> >> 2009/6/3 Paweł Hajdan Jr. : >>> >>> Looks like it's not that simple. Nobody responded. :-/ >>> >>> I analyzed inotify-tools source and they do everything on paths. Of >>> course that means a lot of careful updating etc, but should work in >>> lack of more elegant solution. >>> >>> Paweł >>> >>> On Sun, May 24, 2009 at 20:47, j.din...@gmail.com >>> wrote: >>>> I am trying to make a patch for recursive directory watcher on linux >>>> using inotify event. >>>> >>>> When a new directory under watched directory is created, inotify event >>>> only gives me event->name relative to the watched directory. >>>> This makes it difficult to get the inode number of new directory >>>> because I am keeping track of watched inode numbers so far. >>>> >>>> I need to get "/xxx/yyy/newDirectory" from bare "newDirectory" that >>>> inotify event gives me so that I can get the inode number for >>>> newDirectory and then in turn update my watched inode structure. >>>> >>>> What would be a good way to get the absolute path of a new event that >>>> inotify just reported without having to maintain my own data >>>> structure, i.e without having data structure that keeps watch >>>> descriptor and it's watched path? >>> >>> > >>> >> >> >> >> -- >> Stefan Nuxoll >> >> >> >> > -- Stefan Nuxoll --~--~-~--~~~---~--~~ 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: recursive directory watcher on linux.
inotify is a piece of crap, you can only monitor a directory, from that you have to reread the listing and see what's changed for yourself. 2009/6/3 Paweł Hajdan Jr. : > > Looks like it's not that simple. Nobody responded. :-/ > > I analyzed inotify-tools source and they do everything on paths. Of > course that means a lot of careful updating etc, but should work in > lack of more elegant solution. > > Paweł > > On Sun, May 24, 2009 at 20:47, j.din...@gmail.com wrote: >> I am trying to make a patch for recursive directory watcher on linux >> using inotify event. >> >> When a new directory under watched directory is created, inotify event >> only gives me event->name relative to the watched directory. >> This makes it difficult to get the inode number of new directory >> because I am keeping track of watched inode numbers so far. >> >> I need to get "/xxx/yyy/newDirectory" from bare "newDirectory" that >> inotify event gives me so that I can get the inode number for >> newDirectory and then in turn update my watched inode structure. >> >> What would be a good way to get the absolute path of a new event that >> inotify just reported without having to maintain my own data >> structure, i.e without having data structure that keeps watch >> descriptor and it's watched path? > > > > -- Stefan Nuxoll --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
