[chromium-dev] Re: Is that unimpossible to add a progress bar of page loading with webkit?
On Fri, Oct 9, 2009 at 8:14 PM, Amanda Walker ama...@chromium.org wrote: But the problem is : where are the count-numbers of files? There is no explicit count. As WebKit parses HTML, we queue up requests for resources that are encountered in that HTML. We only know we're done when there are no more pending requests. There is no way to tell in advance. For example, note that CSS files, once they're loaded, can @import more CSS files, increasing the needed to be loaded count. Each time you load a frame or iframe the mystery Amanda describes repeats. Finally, JavaScript files can add any DOM nodes, including more CSS, iframes, and JavaScript. I don't mean to be discouraging. It might be a fun project to implement some sort of progress bar -- for example, it could show the load progress of each resource as they're discovered (see earlier in the thread where you aren't guaranteed to know how long a given resource is). But if it were possible to make a progress bar that browser developers thought would be meaningful, they would have been integrated into browsers already. --~--~-~--~~~---~--~~ 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 that unimpossible to add a progress bar of page loading with webkit?
Evan Martin wrote: But if it were possible to make a progress bar that browser developers thought would be meaningful, they would have been integrated into browsers already. The bar part of a progress bar is usually useless. What's nice is being able to see that things are actually getting loaded (e.g., Safari displays completed M of N items, where both M and N change; Opera also displays something similar; Firefox displays a mostly-useless progress bar). I feel like the throbber should somehow indicate that things are actually being loaded (as opposed to hanging, waiting for something which may never complete). Maybe it already does that and I haven't noticed (where's a good hanging website when you need one to test?). - Trung --~--~-~--~~~---~--~~ 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 that unimpossible to add a progress bar of page loading with webkit?
On Sat, Oct 10, 2009 at 10:31 AM, Viet-Trung Luu viettrung...@gmail.com wrote: I feel like the throbber should somehow indicate that things are actually being loaded (as opposed to hanging, waiting for something which may never complete). Maybe it already does that and I haven't noticed (where's a good hanging website when you need one to test?). It'd be cool if the throbber pulsed slightly each time a resource completed. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [linux] GTK 3 client-side decorations
The discussion moved on to client-side-decorations with Cody Russell which are already being developed on a side-branch. The work has a goal of being merged for GTK 3. This will enable GTK-support for things like Google Chrome's tab-in-window decorator and (finally!) GTK rendering the theme rather than being drawn by the window manager. http://jasondclinton.livejournal.com/74222.html It's a little strange to read of this use case since it's the first I've heard of this branch. I looked through the branch ( http://git.gnome.org/cgit/gtk+/log/?h=client-side-decorations ) but it seems to be mostly about API for drawing the decorations yourself (which we already do an ok job of) but not the harder part: the window manager hooks we need. But I just skimmed, so maybe I'm missing something. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] String handling in base moved around, and where you should put your shared code
I finished moving the last bit of string stuff in preparation for separating ICU from base. All ICU and related utilities have moved to src/base/i18n. The rest of base should not depend on base/i18n because it will be a separate library, but base/i18n can depend on the rest of base. The core UTF8/UTF16/Wide conversion functions have been added to a new file: base/utf_string_conversions.h. This file doesn't use ICU, but rather a few ICU functions and macros I pulled out into base/third_party/icu. Currently, base/string_util.h includes base/utf_string_conversions.h and is likely to stay this way since nobody wants to change all of the files in the project. But if you write a new file or are updating the includes for an existing one, think about whether you need all of string_util or just the UTF conversion functions. The UTF conversion functions will almost never change, so you won't have to recompile your file when Bill S. Preston, Esq. adds SeparateStringIntoBitsAndInterpretEveryThirdPartAsAnInt64() to string_util. base/sys_string_conversions no longer includes SysUTF8ToWide and friends since there's no longer any point for those. sys_string_conversions contains only functions for converting to the system's native multibyte encoding (which you'll almost never need). The more advanced conversion functions that use ICU are in base/i18n/icu_string_conversions.h. You will have to include this file explicitly if you need them. This is WideToCodepage and friends for general character set conversion. It's rare to need this since you should be using Unicode. The final part I haven't done is make a separate base_i18n project that clients wanting ICU and related stuff will link to. This will replace base_gfx which has no purpose since I moved all the Skia and libpng/jpeg dependencies to app. This will allow clients to decide if they really need internationalization support. = I'm adding something, where does it go? First, please consider putting it inside your component's directory. When everybody adds all their crap to base, it ends up that nobody can find anything and the build is more interdependent. If you're not actually sharing anything between toplevel projects, it shouldn't be in base. Second, consider putting it in src/app. App is the stuff you need to build a Windowed application, whereas src/base is the stuff you need to build *any* application. Think of some random daemon or library on ChromeOS. It should link to base but not app. Is your stuff useful to every client executable, or just applications dealing with the windowing system, clipboard, drag drop, etc.? Note also that WebKit/glue and test_shell can now depend on app, which makes it easy to not put stuff in base now. It's assumed anything in app can depend on ICU (base/i18n) since real applications will be internationalized. Put it in base if it really should be linked in with every Google client application, the crash reporter app, all ChromeOS daemons and login manager, etc. This shouldn't be that much stuff! If it needs ICU, put it in base/i18n. If it doesn't, put it in base or the appropriate subdirectory. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Buildbot upgrade
Hello, Today I upgraded buildbot to the latest version. If you have a bookmark for the failures only waterfall, you will need to change it. Previously it was failures=1 and it is now show_events=truefailures_only=true Other than that, nothing should have changed. If you see any issues with the new version, please let me know! Thank you, Nicolas --~--~-~--~~~---~--~~ 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: String handling in base moved around, and where you should put your shared code
clear,great!!! On 10月11日, 上午4时55分, Brett Wilson bre...@chromium.org wrote: I finished moving the last bit of string stuff in preparation for separating ICU from base. All ICU and related utilities have moved to src/base/i18n. The rest of base should not depend on base/i18n because it will be a separate library, but base/i18n can depend on the rest of base. The core UTF8/UTF16/Wide conversion functions have been added to a new file: base/utf_string_conversions.h. This file doesn't use ICU, but rather a few ICU functions and macros I pulled out into base/third_party/icu. Currently, base/string_util.h includes base/utf_string_conversions.h and is likely to stay this way since nobody wants to change all of the files in the project. But if you write a new file or are updating the includes for an existing one, think about whether you need all of string_util or just the UTF conversion functions. The UTF conversion functions will almost never change, so you won't have to recompile your file when Bill S. Preston, Esq. adds SeparateStringIntoBitsAndInterpretEveryThirdPartAsAnInt64() to string_util. base/sys_string_conversions no longer includes SysUTF8ToWide and friends since there's no longer any point for those. sys_string_conversions contains only functions for converting to the system's native multibyte encoding (which you'll almost never need). The more advanced conversion functions that use ICU are in base/i18n/icu_string_conversions.h. You will have to include this file explicitly if you need them. This is WideToCodepage and friends for general character set conversion. It's rare to need this since you should be using Unicode. The final part I haven't done is make a separate base_i18n project that clients wanting ICU and related stuff will link to. This will replace base_gfx which has no purpose since I moved all the Skia and libpng/jpeg dependencies to app. This will allow clients to decide if they really need internationalization support. = I'm adding something, where does it go? First, please consider putting it inside your component's directory. When everybody adds all their crap to base, it ends up that nobody can find anything and the build is more interdependent. If you're not actually sharing anything between toplevel projects, it shouldn't be in base. Second, consider putting it in src/app. App is the stuff you need to build a Windowed application, whereas src/base is the stuff you need to build *any* application. Think of some random daemon or library on ChromeOS. It should link to base but not app. Is your stuff useful to every client executable, or just applications dealing with the windowing system, clipboard, drag drop, etc.? Note also that WebKit/glue and test_shell can now depend on app, which makes it easy to not put stuff in base now. It's assumed anything in app can depend on ICU (base/i18n) since real applications will be internationalized. Put it in base if it really should be linked in with every Google client application, the crash reporter app, all ChromeOS daemons and login manager, etc. This shouldn't be that much stuff! If it needs ICU, put it in base/i18n. If it doesn't, put it in base or the appropriate subdirectory. Brett --~--~-~--~~~---~--~~ 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: String handling in base moved around, and where you should put your shared code
On Sat, Oct 10, 2009 at 1:55 PM, Brett Wilson bre...@chromium.org wrote: First, please consider putting it inside your component's directory. When everybody adds all their crap to base, it ends up that nobody can find anything and the build is more interdependent. If you're not actually sharing anything between toplevel projects, it shouldn't be in base. string_util is one of the worst in base: % wc -l base/*.h | sort -n | tail -10 500 base/time.h 514 base/tracked_objects.h 519 base/message_loop.h 538 base/file_util.h 587 base/string_util.h 588 base/histogram.h 677 base/task.h 823 base/logging.h 907 base/tuple.h But for the project, it's not too bad: % git ls-files *.h | egrep -v 'third_party|generated|gmock|syscall_support' | xargs wc -l | sort -n | tail -10 1150 ipc/ipc_message_macros.h 1168 chrome/browser/tab_contents/tab_contents.h 1239 views/view.h 1270 ipc/ipc_message_utils.h 1326 chrome/browser/sync/syncable/syncable.h 1921 chrome/common/render_messages_internal.h 2116 tools/traceline/traceline/syscall_map.h 2173 chrome/common/render_messages.h 3323 o3d/command_buffer/common/cross/cmd_buffer_format.h --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
