- webkit-efl - lists.webkit.org

Re: [webkit-efl] RFC: Changes to the ewk_settings_cache_* API
by Ryuan Choi 01 Jan '12

01 Jan '12

I like what you want. I have one minor points for the renaming. IMO, ewk_view_setting_offline_app_cache_{get,set} also should be considered. Best Regards, Ryuan Choi ------- Original Message ------- Sender : Raphael Kubo da Costa<kubo(a)profusion.mobi> Date : 2011-11-08 01:17 (GMT+09:00) Title : [webkit-efl] RFC: Changes to the ewk_settings_cache_* API The ewk_settings_cache_* family of functions is quite messy right now. Some calls deal with Offline Web Applications (ewk_settings_cache_directory_path_{get,set}) and others deal with in-memory cache settings (ewk_settings_cache_enable_{get,set} and ewk_settings_cache_capacity_set). I see the following issues with the current situation: 1) Offline Web Applications are completely unrelated to the in-memory cache. The former handles the appcache part of the HTML5 spec, wheareas the latter just caches stylesheets, images and scripts in memory. Yet they both share the same function prefix. The current apidox also does not help at all (the term "offline web applications" is not even mentioned). 2) The exposed API to control the memory cache is redundant and insufficient. - It is insufficient because one cannot pass all parameters accepted by MemoryCache::setCapacities(). It also does not clear other in-memory caches, such as the page and the font caches. - It is redundant because if the user could specify all the parameters accepted by MemoryCache::setCapacities() there would be no need to have the getter and setter for MemoryCache::disabled(). Please tell me what you think of the following proposal: - Rename ewk_settings_cache_directory_path_{get,set} to ewk_settings_offline_web_applications_cache_directory_{get,set}. - Follow more closely what the Qt API does and have: - ewk_settings_cache_clear(Ewk_Cache_Clear_Mode mode) Ewk_Cache_Clear_Mode is an enum which currently has only one value: enum Ewk_Cache_Clear_Mode { EWK_CACHE_CLEAR_MODE_MEMORY_CACHE }; This one clears the memory cache, the page cache, the font cache and the cross-origin preflight cache, like Qt does. Once we have the necessary code to have a network disk-cache, we can add another item to the enum to make it possible to clear it as well. - ewk_settings_object_cache_capacity_set(minDeadBytes, maxDeadBytes, totalBytes) Pass the received parameters to MemoryCache::setCapacities(). If they are all 0, disable the in-memory object cache. -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi _______________________________________________ webkit-efl mailing list webkit-efl(a)lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-efl

2 2

Re: [webkit-efl] [webkit-dev] Announcement of Coding Style Change in WebKit EFL port
by Ryosuke Niwa 30 Dec '11

30 Dec '11

These are great changes! Thanks for making the change for the rest of the WebKit community. - Ryosuke 2011/12/27 Gyuyoung Kim <gyuyoung.kim(a)samsung.com> > Hello WebKit folks, > > > As you may know, I have changed the coding style of EFL port via Bug > 68209. This is to eliminate unnecessary difficulties > > that reviewers have experienced when they review EFL bugs, due to EFL > specific coding style. > > > > Bug 68209 - [EFL] Change WebKit EFL coding style > > (https://bugs.webkit.org/show_bug.cgi?id=68209) > > > > Major changes are as below, > > > > 1. Use full variable name instead of abbreviation name. > > 2. Use standard boolean type instead of EFL boolean type. > > 3. Place '*' operator immediately after the data type. (For example, use > char* userAgent. instead of char *userAgent.) > > 4. Use C++ type casting instead of C type casting. > > 5. Remove void parameter from internal functions. > > 6. Use camelCase instead of underbar(_) in variable names. > > > > I made a wiki page for this rule. I will update this page whenever EFL > port coding style guide is changed. > > (http://trac.webkit.org/wiki/EFLWebKitCodingStyle) > > > > To sum up, EFL port adheres to WebKit coding style except for public > header from now. > > (Because public header is used by EFL applications, public header will > continue to follow the coding style rule of EFL.) > > > > We hope that reviewing of EFL port patches will be much easier after this > change. > > > > Happy new year !! > > > > Regards, > > Gyuyoung Kim. > > _______________________________________________ > webkit-dev mailing list > webkit-dev(a)lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >

1 0

About using ewk_view* to other ewk_xxx.cpp files.
by Kihong Kwon 27 Dec '11

27 Dec '11

Hi. WebKit-EFL I have a patch for adding the notification api to the WebKit-EFL.(https://bugs.webkit.org/show_bug.cgi?id=73544) But, I have a issue about using ewk_view pointer in the ewk_notification.cpp. I would like to make a ewk_notification.h/cpp independently from ewk_view.h/cpp, because ewk_view.h/cpp is too large and I think the Notification API can be made independently. But, I have to use Evas_Object* ewkView, because of notification callback functions for the JS. Can I use ewk_view* in the ewk_notification.h/cpp files? There is no example like this in the EFL. How do you think about this? For example : ewk_notification.cpp --------------------------------------------------------------------------------------------------------------------------------------------------------- void ewk_notification_displayed(const Evas_Object* ewkView, const Ewk_Notification* ewkNotification) { #if ENABLE(NOTIFICATIONS) static_cast<WebCore::NotificationPresenterClientEfl*>(EWKPrivate::corePage(ewkView)->notificationController()->client())->notificationDisplayed(static_cast<WebCore::Notification*>(ewkNotification->notification)); #endif } …… void ewk_notification_request_permission(Evas_Object* ewkView, const char* domain) { evas_object_smart_callback_call(ewkView, "notification,contents,requestPermission", (void*)domain); } ---------------------------------------------------------------------------------------------------------------------------------------------------------- Thank you. BR. Kihong

1 0

About using ewk_view* to other ewk_xxx.cpp files.
by 권기홍 27 Dec '11

27 Dec '11

1 0

libsoup dependency bump (at least for now)
by Raphael Kubo da Costa 15 Dec '11

15 Dec '11

Hey there. I'm not sure you guys are all actively following trunk, so this is a heads-up if you are using the libsoup network backend (by default you are). As of SVN r101917, committed 12 days ago, the webkit-gtk folks (who maintain the libsoup network backend) have bumped the minimum required libsoup version to 2.37.2.1. If you don't know GNOME's conventions, this means it is an unstable, development version that will later become 2.38.x when the next stable GNOME release comes out. As webkit-gtk follows GNOME's release cycle, it is OK for them to depend on development versions of GNOME libraries. For now, there is not much we can do, as using an older, stable libsoup version will cause random crashes. If you use the libsoup backend with webkit-efl (you should, as there are many features which are not implemented for the curl backend), consider installing the bleeding edge libsoup version locally and remember to use it when using webkit-efl. -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi

1 0

ewk API documentation
by Praveen Kumar Gattu 01 Dec '11

01 Dec '11

Hello, I am very much new to ewk. Can some body help to get the reference manual for ewk APIs. Br, Praveen

2 1

WebKit EFL Coding Style Change
by Gyuyoung Kim 30 Nov '11

30 Nov '11

1 0

Re: [webkit-efl] RFC: Changes to the ewk_settings_cache_* API
by Ryuan Choi 10 Nov '11

10 Nov '11

> > I like what you want. > > > > I have one minor points for the renaming. > > IMO, ewk_view_setting_offline_app_cache_{get,set} also should be considered. > > The abbreviation kind of makes sense, but there should be "path" or > "directory" somewhere in the name. I mean that ewk_view_setting_offline_app_cache_{get,set} should be changed properly when you change ewk_settings_cache_directory_path_{get,set} If we changed as you suggested at below, we don't need to touch ewk_view_setting_offline_app_cache_{get,set}. So please ignore this. For the list which you suggested, It's good to me. > What do you guys think of having the following set of calls in > ewk_settings from now on: > > == General purpose == > * ewk_settings_repaint_throttling_set > * ewk_settings_default_timer_interval_get > > == Web Database (aka WebSQL) == > * ewk_settings_web_database_default_quota_get > * ewk_settings_web_database_path_set > * ewk_settings_web_database_path_get > > * ewk_settings_web_database_default_quota_set > * ewk_settings_web_database_clear > > The last two are new functions. > > == Icon Database == > * ewk_settings_icon_database_path_set > * ewk_settings_icon_database_path_get > * ewk_settings_icon_database_clear > * ewk_settings_icon_database_icon_surface_get > * ewk_settings_icon_database_icon_object_add > > == Offline Web Apps == > * ewk_settings_offline_app_cache_path_get > * ewk_settings_offline_app_cache_path_set > > These two replace ewk_settings_cache_directory_path_{get,set}. > > * ewk_settings_offline_app_cache_max_quota_get > * ewk_settings_offline_app_cache_max_quota_set > > These functions are new. > > == In-Memory Cache == > * ewk_settings_object_cache_capacity_set > * ewk_settings_memory_cache_clear > > The former is a modified version of ewk_settings_cache_capacity_set, > and the latter is a new function. > > ewk_settings_cache_enable_{get,set} would be removed.

1 0

RFC: Changes to the ewk_settings_cache_* API
by Raphael Kubo da Costa 07 Nov '11

07 Nov '11

The ewk_settings_cache_* family of functions is quite messy right now. Some calls deal with Offline Web Applications (ewk_settings_cache_directory_path_{get,set}) and others deal with in-memory cache settings (ewk_settings_cache_enable_{get,set} and ewk_settings_cache_capacity_set). I see the following issues with the current situation: 1) Offline Web Applications are completely unrelated to the in-memory cache. The former handles the appcache part of the HTML5 spec, wheareas the latter just caches stylesheets, images and scripts in memory. Yet they both share the same function prefix. The current apidox also does not help at all (the term "offline web applications" is not even mentioned). 2) The exposed API to control the memory cache is redundant and insufficient. - It is insufficient because one cannot pass all parameters accepted by MemoryCache::setCapacities(). It also does not clear other in-memory caches, such as the page and the font caches. - It is redundant because if the user could specify all the parameters accepted by MemoryCache::setCapacities() there would be no need to have the getter and setter for MemoryCache::disabled(). Please tell me what you think of the following proposal: - Rename ewk_settings_cache_directory_path_{get,set} to ewk_settings_offline_web_applications_cache_directory_{get,set}. - Follow more closely what the Qt API does and have: - ewk_settings_cache_clear(Ewk_Cache_Clear_Mode mode) Ewk_Cache_Clear_Mode is an enum which currently has only one value: enum Ewk_Cache_Clear_Mode { EWK_CACHE_CLEAR_MODE_MEMORY_CACHE }; This one clears the memory cache, the page cache, the font cache and the cross-origin preflight cache, like Qt does. Once we have the necessary code to have a network disk-cache, we can add another item to the enum to make it possible to clear it as well. - ewk_settings_object_cache_capacity_set(minDeadBytes, maxDeadBytes, totalBytes) Pass the received parameters to MemoryCache::setCapacities(). If they are all 0, disable the in-memory object cache. -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi

1 0

Does anyone use EDJ based custom cursor ?
by Ryuan Choi 03 Nov '11

03 Nov '11

Hello, WebKit/Efl guys. I'd like to know whether we keep an edj based cursor support. Now, WebKit/Efl support EDJ based cursor and Ecore_X based cursor. But, eve and our applications use default.edj which doesn't have cursor related code. IMO, providing basic cursor-sets is the role of platform library. and ecore provide Ecore_X_Cursor for X and Ecore_Win32_Cursor for Win32. So, I'd like to remove EDJ based cursor for the code clean up. If someone want to use different backend, I think that we'd better to support related ecore APIs like Ecore_Win32_Cursor. How do you think about it? If you are using EDJ based cursor or want to keep it, please let me know. Thanks Best Regards, Ryuan Choi ----------------------------------------------------------------------- Listen and listen and listen -----------------------+

2 1