29 May
2012
29 May
'12
4:47 p.m.
Resolving bug report 892 includes important patches to reduce potential conflict with KDE4
and to make our own *.desktop files XDG compliant (recently Trinity/TDE was added to the
list of registered environments:
http://standards.freedesktop.org/menu-spec/latest/apb.html).
Resolving this bug report is important to release R14.
The gritty work of creating patches to update all *.desktop files for each module is
complete. Yet there is hard-coding somewhere deep in the tdelibs/tdebase sources that
affixes the location of $PREFIX/share/applications/kde. I want to change that location to
$PREFIX/share/applications/tde.
During testing, to change the location to $PREFIX/share/applications/tde, I modify the
sources on-the-fly of every module by running the following snippet in my master build
script:
echo "Fixing applications path in $APP_SOURCES_DIR."
if [ -d $APP_SOURCES_DIR/cmake ];then
find $APP_SOURCES_DIR/cmake -name TDESetupPaths.cmake -exec sed -i
's|\${SHARE_INSTALL_PREFIX}/applications/kde|\${SHARE_INSTALL_PREFIX}/applications/tde|g'
{} \;
fi
if [ -d $APP_SOURCES_DIR/admin ]; then
find $APP_SOURCES_DIR/admin -type f -exec sed -i
's|{datadir}/applications/kde|{datadir}/applications/tde|g' {} \;
fi
find $APP_SOURCES_DIR -type f -exec sed -i
's|share/applications/kde/|share/applications/tde/|g' {} \;
echo
After I resolve the mysterious hard-coding I'll patch each module with this on-the-fly
snippet.
tdelibs/tdecore/kstandarddirs.cpp has this snippet:
if (!strcmp(type, "xdgdata-apps"))
return "applications/";
Notice there is no "kde" affixed to the path.
Therefore the "kde" subdirectory is being added somewhere else.
The on-the-fly changes work great and all desktop files get installed to
$PREFIX/share/applications/tde. Nonetheless, there is breakage. The hard-coding is real
because various components stop working in Trinity. For example, opening the Konqueror
Settings dialog reveals that most of the configuration options in the icon list are
missing. I can temporarily create a sym link from $PREFIX/share/applications/tde to
$PREFIX/share/applications/kde and then everything works again --- evidence of
hard-coding.
I've looked and looked and I can't find anything. I would be grateful anybody
would help me find this mysterious hard-coding.
Darrell
29 May
29 May
6:15 p.m.
New subject: [trinity-devel] Mysterious hard-coding
Resolving bug report 892 includes important patches to
reduce potential
conflict with KDE4 and to make our own *.desktop files XDG compliant
(recently Trinity/TDE was added to the list of registered environments:
http://standards.freedesktop.org/menu-spec/latest/apb.html).
Resolving this bug report is important to release R14.
<snip>
I am fairly certain that what you are looking for is in the file
cmake/modules/TDESetupPaths.cmake, specifically the line which sets
XDG_APPS_INSTALL_DIR
tde-config is generate from tdecore/tde-config.cpp.cmake, which uses
XDG_APPS_INSTALL_DIR as defined during the build process.
Tim
6:17 p.m.
New subject: [trinity-devel] Mysterious hard-coding
Resolving bug
report 892 includes important patches to reduce potential
conflict with KDE4 and to make our own *.desktop files XDG compliant
(recently Trinity/TDE was added to the list of registered environments:
http://standards.freedesktop.org/menu-spec/latest/apb.html).
Resolving this bug report is important to release R14.
<snip>
I am fairly certain that what you are looking for is in the file
cmake/modules/TDESetupPaths.cmake, specifically the line which sets
XDG_APPS_INSTALL_DIR
tde-config is generate from tdecore/tde-config.cpp.cmake, which uses
XDG_APPS_INSTALL_DIR as defined during the build process.
Tim
6:51 p.m.
New subject: [trinity-devel] Mysterious hard-coding
I am fairly certain that what you are looking for is
in the
file cmake/modules/TDESetupPaths.cmake, specifically the line
which sets XDG_APPS_INSTALL_DIR
tde-config is generate from tdecore/tde-config.cpp.cmake,
which uses
XDG_APPS_INSTALL_DIR as defined during the build process.
There is a second hardcode for the Autotools build
system
in admin/acinclude.m4.in, line 535. It looks like this:
xdg_appsdir='\${datadir}/applications/kde'
Yes, I have both of those locations covered in my master build script snippet. I just
generated individual patches for each module. The tdelibs patch looks like this:
diff -urN tdelibs/admin/acinclude.m4.in tdelibs.new/admin/acinclude.m4.in
--- tdelibs/admin/acinclude.m4.in 2012-05-10 15:54:53.000000000 -0500
+++ tdelibs.new/admin/acinclude.m4.in 2012-05-29 13:12:09.413139614 -0500
@@ -532,7 +532,7 @@
kde_widgetdir='\${libdir}/trinity/plugins/designer'
fi
if test -z "$xdg_appsdir"; then
- xdg_appsdir='\${datadir}/applications/kde'
+ xdg_appsdir='\${datadir}/applications/tde'
fi
if test -z "$xdg_menudir"; then
xdg_menudir='\${sysconfdir}/xdg/menus'
diff -urN tdelibs/cmake/modules/TDESetupPaths.cmake
tdelibs.new/cmake/modules/TDESetupPaths.cmake
--- tdelibs/cmake/modules/TDESetupPaths.cmake 2012-05-10 15:54:52.000000000 -0500
+++ tdelibs.new/cmake/modules/TDESetupPaths.cmake 2012-05-29 13:12:09.840143049 -0500
@@ -61,7 +61,7 @@
_tde_internal_setup_path( INFO_INSTALL_DIR
"${SHARE_INSTALL_PREFIX}/info" "The info install dir
(default ${SHARE_INSTALL_PREFIX}/info)" )
_tde_internal_setup_path( XDG_MENU_INSTALL_DIR
"${SYSCONF_INSTALL_DIR}/xdg/menus" "The XDG menus dir" )
- _tde_internal_setup_path( XDG_APPS_INSTALL_DIR
"${SHARE_INSTALL_PREFIX}/applications/kde" "The XDG apps dir" )
+ _tde_internal_setup_path( XDG_APPS_INSTALL_DIR
"${SHARE_INSTALL_PREFIX}/applications/tde" "The XDG apps dir" )
_tde_internal_setup_path( XDG_DIRECTORY_INSTALL_DIR
"${SHARE_INSTALL_PREFIX}/desktop-directories" "The XDG directory" )
_tde_internal_setup_path( XDG_MIME_INSTALL_DIR
"${SHARE_INSTALL_PREFIX}/mime/packages" "The install dir for the xdg
mimetypes" )
Darrell
7:03 p.m.
New subject: [trinity-devel] Mysterious hard-coding
I am fairly
certain that what you are looking for is in the
file cmake/modules/TDESetupPaths.cmake, specifically the line
which sets XDG_APPS_INSTALL_DIR
tde-config is generate from tdecore/tde-config.cpp.cmake,
which uses
XDG_APPS_INSTALL_DIR as defined during the build process.
There is a second hardcode for the Autotools
build system
in admin/acinclude.m4.in, line 535. It looks like this:
xdg_appsdir='\${datadir}/applications/kde'
Yes, I have both of those locations covered in my master build script
snippet. I just generated individual patches for each module. The tdelibs
patch looks like this:
diff -urN tdelibs/admin/acinclude.m4.in tdelibs.new/admin/acinclude.m4.in
--- tdelibs/admin/acinclude.m4.in 2012-05-10 15:54:53.000000000 -0500
+++ tdelibs.new/admin/acinclude.m4.in 2012-05-29 13:12:09.413139614 -0500
@@ -532,7 +532,7 @@
kde_widgetdir='\${libdir}/trinity/plugins/designer'
fi
if test -z "$xdg_appsdir"; then
- xdg_appsdir='\${datadir}/applications/kde'
+ xdg_appsdir='\${datadir}/applications/tde'
fi
if test -z "$xdg_menudir"; then
xdg_menudir='\${sysconfdir}/xdg/menus'
diff -urN tdelibs/cmake/modules/TDESetupPaths.cmake
tdelibs.new/cmake/modules/TDESetupPaths.cmake
--- tdelibs/cmake/modules/TDESetupPaths.cmake 2012-05-10
15:54:52.000000000 -0500
+++ tdelibs.new/cmake/modules/TDESetupPaths.cmake 2012-05-29
13:12:09.840143049 -0500
@@ -61,7 +61,7 @@
_tde_internal_setup_path( INFO_INSTALL_DIR
"${SHARE_INSTALL_PREFIX}/info" "The info install dir
(default ${SHARE_INSTALL_PREFIX}/info)" )
_tde_internal_setup_path( XDG_MENU_INSTALL_DIR
"${SYSCONF_INSTALL_DIR}/xdg/menus" "The XDG menus dir" )
- _tde_internal_setup_path( XDG_APPS_INSTALL_DIR
"${SHARE_INSTALL_PREFIX}/applications/kde" "The XDG apps dir" )
+ _tde_internal_setup_path( XDG_APPS_INSTALL_DIR
"${SHARE_INSTALL_PREFIX}/applications/tde" "The XDG apps dir" )
_tde_internal_setup_path( XDG_DIRECTORY_INSTALL_DIR
"${SHARE_INSTALL_PREFIX}/desktop-directories" "The XDG directory" )
_tde_internal_setup_path( XDG_MIME_INSTALL_DIR
"${SHARE_INSTALL_PREFIX}/mime/packages" "The install dir for the
xdg mimetypes" )
Darrell
7:10 p.m.
New subject: [trinity-devel] Mysterious hard-coding
Are you building with Autotools or CMake?
Both, depending on the module.
It might be a good idea to search in the /<TDE
prefix>/bin and /<TDE prefix>/lib directories for the text string
"applications/kde" to see which binary or library contains the hardcoded
string.
This will narrow the search down considerably.
Yes, my master build script (and the script I wrote to create the individual patches)
searches the entire module for that string:
find $MODULE.new -type f -exec sed -i
's|share/applications/kde/|share/applications/tde/|g' {} \;
Darrell
7:18 p.m.
New subject: [trinity-devel] Mysterious hard-coding
Are you
building with Autotools or CMake?
Both, depending on the module. It might be a
good idea to search in the /<TDE
prefix>/bin and /<TDE prefix>/lib directories for the text string
"applications/kde" to see which binary or library contains the hardcoded
string.
This will narrow the search down considerably.
Yes, my master build script (and the script I wrote to create the
individual patches) searches the entire module for that string:
find $MODULE.new -type f -exec sed -i
's|share/applications/kde/|share/applications/tde/|g' {} \;
Darrell
7:41 p.m.
New subject: [trinity-devel] Mysterious hard-coding
Are you building with Autotools or CMake?
Both, depending on the module. Actually, I meant for debugging purposes to perform a
text
search inside the binary and library files themselves, not the source
files.
I did that too, a long time ago. :-)
Nonetheless, I just now ran 'grep -a' against my current installation, which is
built with $PREFIX/share/applications/kde. tde-config is the only executable with a
reference to applications/kde and libkio.so is the only library file, but that library
file reference is to applications/kde4. Changing to share/applications/tde would produce
equivalent results.
I have tested with a new profile, to ensure the hard-coding is not there. Same results
with Konqueror not loading the other Settings options.
In other words, I have beaten myself up pretty good trying to solve this mystery. I'll
be quite tickled if somebody eventually shows me something obvious that I overlooked. I
just want the mystery solved and don't care whether my eyesight or intelligence become
suspect. :-)
At the moment I don't recall other breakages other than the Konqueror example, but I
seem to recall other things. Possibly only Konqueror is broken and nothing else. Possibly
the clue is in the Konqueror code only.
I'm going to try another run today with the new path of
$PREFIX/share/applications/tde.
Darrell
7:51 p.m.
New subject: [trinity-devel] Mysterious hard-coding
Are you
building with Autotools or CMake?
Both, depending on the module. Actually, I meant for debugging purposes to
perform a text
search inside the binary and library files themselves, not the source
files.
I did that too, a long time ago. :-)
Nonetheless, I just now ran 'grep -a' against my current installation,
which is built with $PREFIX/share/applications/kde. tde-config is the only
executable with a reference to applications/kde
8:05 p.m.
New subject: [trinity-devel] Mysterious hard-coding
Good to know. Please look in the generated
tdecore/tde-config.cpp file and see if a reference to applications/kde is in there.
Here is what I see that could be suspect:
...
if (args->isSet("libsuffix"))
{
TQString tmp(KDELIBSUFF);
tmp.remove('"');
printResult(expandvars(tmp.local8Bit()));
return 0;
}
...
type = args->getOption("install");
if (!type.isEmpty())
{
const char *installprefixes[] = {
...
"data", "@kde_datadir@",
...
"xdgdata-apps", "@xdg_appsdir@",
"xdgdata-dirs", "@xdg_directorydir@",
...
I think I see where you are going with this: that apps call tde-config internally to
determine where to find files. Possibly then the hard-coding is with tde-config, or,
tde-config is not being built correctly to detect the changes I make in the respective
automake/cmake files. Is there a way I can check the build logs to confirm how tde-config
is built?
Darrell
8:24 p.m.
New subject: [trinity-devel] Mysterious hard-coding
Good to know.
Please look in the generated
tdecore/tde-config.cpp file and see if a reference to applications/kde
is in there.
Here is what I see that could be suspect:
...
if (args->isSet("libsuffix"))
{
TQString tmp(KDELIBSUFF);
tmp.remove('"');
printResult(expandvars(tmp.local8Bit()));
return 0;
}
...
type = args->getOption("install");
if (!type.isEmpty())
{
const char *installprefixes[] = {
...
"data", "@kde_datadir@",
...
"xdgdata-apps", "@xdg_appsdir@",
"xdgdata-dirs", "@xdg_directorydir@",
...
I think I see where you are going with this: that apps call tde-config
internally to determine where to find files. Possibly then the hard-coding
is with tde-config, or, tde-config is not being built correctly to detect
the changes I make in the respective automake/cmake files. Is there a way
I can check the build logs to confirm how tde-config is built?
Darrell
8:44 p.m.
New subject: [trinity-devel] Mysterious hard-coding
Unfortunately the build logs won't help you, but
if you have
access to your build directory look for the tdecore/tde-config.cpp
file (note: NOT the tde-config.cpp.in or tde-config.cpp.cmake files) and see
what follows "xdgdata*" in the source code.
grep xdgdata $TMP/tdelibs.build/tdecore/tde-config.cpp
"xdgdata-apps", I18N_NOOP("XDG Application menu (.desktop files)"),
"xdgdata-dirs", I18N_NOOP("XDG Menu descriptions (.directory
files)"),
"xdgdata-apps", "/opt/trinity/share/applications/tde",
"xdgdata-dirs", "/opt/trinity/share/desktop-directories",
I'm building new test packages now and will report again soon with the installation
results and Konqueror behavior.
Darrell
9:54 p.m.
New subject: [trinity-devel] Mysterious hard-coding
Unfortunately
the build logs won't help you, but if you have
access to your build directory look for the tdecore/tde-config.cpp
file (note: NOT the tde-config.cpp.in or tde-config.cpp.cmake files) and
see
what follows "xdgdata*" in the source code.
grep xdgdata $TMP/tdelibs.build/tdecore/tde-config.cpp
"xdgdata-apps", I18N_NOOP("XDG Application menu (.desktop files)"),
"xdgdata-dirs", I18N_NOOP("XDG Menu descriptions (.directory
files)"),
"xdgdata-apps", "/opt/trinity/share/applications/tde",
"xdgdata-dirs", "/opt/trinity/share/desktop-directories",
I'm building new test packages now and will report again soon with the
installation results and Konqueror behavior.
Darrell
10:10 p.m.
New subject: [trinity-devel] Mysterious hard-coding
When the rebuild finishes go ahead and search the
tde-config
binary again for "applications/kde". If the string is still in
there please Email the binary to me directly so I can examine it more closely.
No such string.
I just built a new package set (core packages only) to test
$PREFIX/share/applications/tde. Same results. :-(
* All desktop files installed to /opt/trinity/share/applications/tde.
* grep -rna "applications/kde" /opt/trinity/lib produces no results
* grep -rna "applications/kde" /opt/trinity/bin produces no results
* grep -rna "applications/tde" /opt/trinity/lib produces no results
* grep -rna "applications/tde" /opt/trinity/bin produces one result: tde-config
* tde-config --install xdgdata-apps produces: /opt/trinity/share/applications/tde
* Opening Konqueror and selecting Settings/Configure Konqueror shows only four items in
the left-side icon list: 1) Behavior, 2) Appearance, 3) Previews * Meta-Data, 4)
Performance. All other configuration items are missing from the icon list.
* A new profile results in the same Konqueror behavior with only four items showing in the
icon list.
* Creating a sym link (ln -s /opt/trinity/share/applications/tde
/opt/trinity/share/applications/kde) and restarting the session results in all
configuration items in the Konqueror icon list to appear.
* Session saving is disabled throughout this testing (start with new session).
* ksycoca cache was deleted before starting each desktop session.
Darrell
10:33 p.m.
New subject: [trinity-devel] Mysterious hard-coding
When the
rebuild finishes go ahead and search the tde-config
binary again for "applications/kde". If the string is still in
there please Email the binary to me directly so I can examine it more
closely.
No such string.
I just built a new package set (core packages only) to test
$PREFIX/share/applications/tde. Same results. :-(
* All desktop files installed to /opt/trinity/share/applications/tde.
* grep -rna "applications/kde" /opt/trinity/lib produces no results
* grep -rna "applications/kde" /opt/trinity/bin produces no results
* grep -rna "applications/tde" /opt/trinity/lib produces no results
* grep -rna "applications/tde" /opt/trinity/bin produces one result:
tde-config
* tde-config --install xdgdata-apps produces:
/opt/trinity/share/applications/tde
* Opening Konqueror and selecting Settings/Configure Konqueror shows only
four items in the left-side icon list: 1) Behavior, 2) Appearance, 3)
Previews * Meta-Data, 4) Performance. All other configuration items are
missing from the icon list.
* A new profile results in the same Konqueror behavior with only four
items showing in the icon list.
* Creating a sym link (ln -s /opt/trinity/share/applications/tde
/opt/trinity/share/applications/kde) and restarting the session results in
all configuration items in the Konqueror icon list to appear.
* Session saving is disabled throughout this testing (start with new
session).
* ksycoca cache was deleted before starting each desktop session.
Darrell
10:53 p.m.
New subject: [trinity-devel] Mysterious hard-coding
I'm starting to recognize this pattern....try
grepping for
/kde in your XDG directories (that means your system XDG directory as
well as your profile and the XDG directories under the TDE prefix).
I suspect you will run across at least one .desktop file that contains the
string.
Nothing there:
grep -rna "/kde" $TDEHOME
grep -rna "/kde" /opt/trinity | grep -v doc
Using a new profile, I disabled konqueror preloading. I started konqueror with strace
using konsole.
Next I created a sym link (ln -s /opt/trinity/share/applications/tde
/opt/trinity/share/applications/kde) and restarted the session. I again deleted the
ksycoca cache and created another strace.
Other than the typical memory address differences, the two straces are identical. I had
hoped to catch some kind of reference to "applications/kde" but there is none.
Interestingly, when I create the sym link I notice all TDE menu items repeat.
Because only core packages are installed, I can't test a variety of apps. Of those
that are installed, I started kate, kwrite, kjobviewer, kcontrol, konsole. No noticeable
problems.
Curiously, the same configuration items that are missing in the konqueror configuration
icon list all appear in kcontrol -> Internet & Network -> Web Browser. Therein
is a likely clue.
I'm starting to think the bug is in konqueror or in one of my *.desktop patches.
The thing about the patch set is there is no problem when I install all desktop files to
$PREFIX/share/applications/kde during the build process or create the same sym link. Thus
far I seem to notice the breakage only with konqueror.
Searching for "/kde" in my tdelibs and tdebase patches produced nothing.
I'm building the remaining packages of the main suite in order to have more apps to
test. Please let me know what usability tests might help further isolate the problem.
I don't know where in the konqueror sources the configuration icon list is populated,
but I suspect that is a good place to begin snooping. If I knew how konqueror populated
its configuration icon list, then perhaps I could narrow the search to konqueror or
related snippets in the patch set. Because the same configuration options appear in
kcontrol, I'll take a wild guess that somehow konqueror parses the related desktop
files incorrectly or simply can't find them.
Darrell
11:02 p.m.
New subject: [trinity-devel] Mysterious hard-coding
I'm starting to recognize this pattern....try
grepping for
/kde in your XDG directories (that means your system XDG directory as
well as your profile and the XDG directories under the TDE prefix).
I suspect you will run across at least one .desktop file that contains the
string.
Could this be the problem?
In tdebase/konqueror/konq_mainwindow:3878
m_configureModules << "kde-filebehavior.desktop" <<
"kde-fileappearance.desktop" <<
"kde-filepreviews.desktop" << "kde-filetypes.desktop"
<<
"kde-khtml_behavior.desktop" <<
"kde-khtml_java_js.desktop" <<
"kde-khtml_filter.desktop" <<
"kde-khtml_fonts.desktop" << "kde-ebrowsing.desktop"
<<
"kde-kcmhistory.desktop" << "kde-cookies.desktop"
<<
"kde-cache.desktop" << "kde-proxy.desktop" <<
"kde-kcmcss.desktop" <<
"kde-crypto.desktop" << "kde-useragent.desktop" <<
"kde-khtml_plugins.desktop" <<
"kde-kcmkonqyperformance.desktop";
Perhaps change the "kde-" prefix to "tde-"?
I'm rebuilding now with a patch....
Darrell
11:50 p.m.
New subject: [trinity-devel] Mysterious hard-coding (Solved!)
Could this be the problem?
In tdebase/konqueror/konq_mainwindow:3878
m_configureModules <<
"kde-filebehavior.desktop" <<
"kde-fileappearance.desktop" <<
"kde-filepreviews.desktop" <<
"kde-filetypes.desktop" <<
"kde-khtml_behavior.desktop" <<
"kde-khtml_java_js.desktop" <<
"kde-khtml_filter.desktop" <<
"kde-khtml_fonts.desktop" <<
"kde-ebrowsing.desktop" <<
"kde-kcmhistory.desktop" <<
"kde-cookies.desktop" <<
"kde-cache.desktop" <<
"kde-proxy.desktop" << "kde-kcmcss.desktop" <<
"kde-crypto.desktop" <<
"kde-useragent.desktop" <<
"kde-khtml_plugins.desktop" <<
"kde-kcmkonqyperformance.desktop";
Perhaps change the "kde-" prefix to "tde-"?
I'm rebuilding now with a patch....
Yes, Virginia, that is the problem! Woo-hoo! :-)
Looking through the sources reveals this is a common usage form for desktop files. Seems
then I need to amend my patches to change instances in the source code of kde-*.desktop to
tde-*.desktop.
Does this sound same?
Second, a full search of the GIT sources revealed one exception to a "blind"
search-and-replace of all such instances: x-kde-wallet.desktop. This is a mimetype. For
the purposes of resolving bug report 892, I don't want to mess with renaming that
desktop file, but in the bigger picture, do we want to or should be? I don't know how
renaming will break existing profiles.
Darrell
30 May
30 May
1:04 a.m.
New subject: [trinity-devel] Mysterious hard-coding (Solved!)
Yes, Virginia, that is the problem! Woo-hoo! :-)
Looking through the sources reveals this is a common usage
form for desktop files. Seems then I need to amend my
patches to change instances in the source code of
kde-*.desktop to tde-*.desktop.
Does this sound sa[n]e?
To answer my own question, no, not quite sane. Blindly replacing all instances in the
source code of kde-*.desktop -> tde-*.desktop causes a different set of weirdness and
breakage. In tdebase/konqueror/konq_mainwindow:3878 I need to leave four of the references
as kde-*.desktop:
kde-filepreviews.desktop
kde-filetypes.desktop
kde-khtml_behavior.desktop
kde-kcmkonqyperformance.desktop
Curiously, those four files are installed to $PREFIX/share/applnk/.hidden rather than
$PREFIX/share/applications/tde, albeit without the 'kde-' prefix in the file
name.
The following modules contain references in the sources of kde-*.desktop:
applications/tde-systemsettings
applications/kerry
applications/kiosktool
applications/knutclient
tde-i18n
tdebase
tdebindings
tdelibs
tdevelop
I seem to be over the hump with respect to finding the hidden hard-coding, but I don't
know of a systematic way to test which kde-*.desktop references in the source code should
be renamed. Thus far, a simple random usability test of the desktop reveals only those
konqueror references needing to be renamed. I suppose a full package rebuild and
installation might reveal more, but then again, might not.
Any ideas how to isolate which ones need renaming?
I'm curious why this weird behavior happens. Any ideas?
Darrell
4589
days inactive
4590
days old
18 comments
2 participants
participants (2)
-
Darrell Anderson -
Timothy Pearson