On Saturday 05 July 2014 20:47:13 Marko Käning wrote:
> > This is the issue: there isn't just "one vendor". Anyone can build apps on
> > top of Qt and KF5. So we can't hardcode a vendor in Qt or KF5 APIs.
>
> Well, I thought, that the frameworks themselves have a vendor, namely KDE!
> System-wide framework-specific configuration could then go into
>
> /Library/Application Support/KDE/<framework name>
>
> couldn’t it?
Framework-specific yes. But again, take the case of kxmlgui files as an
example. They are loaded by the kxmlgui framework itself, whether they got
installed by a kde framework, a kde app, a non-kde app (= an application not
developed by the KDE community ("vendor") but still using the KXmlGui
framework)...
If each of these installs .rc files in a randomly named location, how is
KXmlGui supported to find them?
The current solution is
<DATADIR>/<application name>/foo.rc
Where I say <application name>, it's rather <component name>, where "khtml" is
a component too, for instance. This is why we end up with
DATADIR/khtml/khtml5.rc
The only other solution I can think of is
<DATADIR>/kxmlgui5/<application name>/foo.rc
i.e. grouping by technology rather than by vendor or application.
In fact, we already do this with share/knotifications5/*.notifyrc and
share/kservices5/*.desktop -- for the same reasons. So let's go for that.
This can be done with the attached patches.
Everyone: please review :)
I'll upload the kxmlgui one to reviewboard since it's larger.
SC/BC is kept, the files can be loaded from the "old" locations, with a
runtime warning.
Marko, if this goes in, can you port everything kf5-based to install .rc files
in KXMLGUI_INSTALL_DIR just like kwrite.diff does for kwrite?
> > We could design APIs that force passing a vendor string,
> > or we could use the name of the technology as the vendor string,
> > like /Library/Application Support/KXMLGUI but that would mean that every
> > app would end up installing something in there, rather than in
> > /Library/Application Support/<application name>.
>
> Well, I thought the vendor string was there. At least I remember to have
> seen code like that in QStandardPaths...
Not in GenericDataLocation, which is DATADIR.
There's this weird old DataLocation which appends org domain and app name to
the DATADIR, I find that totally useless, it assume monolithic apps rather
than components which can live in the same process (i.e. same domain name and
same app name).
--
David Faure, [email protected], http://www.davidfaure.fr
Working on KDE Frameworks 5
diff --git a/kde-modules/KDEInstallDirs.cmake b/kde-modules/KDEInstallDirs.cmake
index 061e542..90ed5b8 100644
--- a/kde-modules/KDEInstallDirs.cmake
+++ b/kde-modules/KDEInstallDirs.cmake
@@ -69,6 +69,9 @@
# ``KSERVICETYPES5DIR``
# service types for KDE Frameworks 5 (``DATAROOTDIR/kservicetypes5``)
# [``SERVICETYPES_INSTALL_DIR``]
+# ``KXMLGUI5DIR``
+# knotify description files (``DATAROOTDIR/kxmlgui5``)
+# [``KXMLGUI_INSTALL_DIR``]
# ``KNOTIFY5RCDIR``
# knotify description files (``DATAROOTDIR/knotifications5``)
# [``KNOTIFYRC_INSTALL_DIR``]
@@ -384,6 +387,9 @@ _define_relative(KSERVICETYPES5DIR DATAROOTDIR "kservicetypes5"
_define_relative(KNOTIFY5RCDIR DATAROOTDIR "knotifications5"
"knotify description files"
KNOTIFYRC_INSTALL_DIR)
+_define_relative(KXMLGUI5DIR DATAROOTDIR "kxmlgui5"
+ "kxmlgui .rc files"
+ KXMLGUI_INSTALL_DIR)
# Cross-desktop or other system things
_define_relative(ICONDIR DATAROOTDIR "icons"
diff --git a/tests/KDEInstallDirsTest/vars_defined/CMakeLists.txt b/tests/KDEInstallDirsTest/vars_defined/CMakeLists.txt
index f1617da..3940b81 100644
--- a/tests/KDEInstallDirsTest/vars_defined/CMakeLists.txt
+++ b/tests/KDEInstallDirsTest/vars_defined/CMakeLists.txt
@@ -31,6 +31,7 @@ set(relative_path_vars
KF5_INCLUDE_INSTALL_DIR
KF5_LIBEXEC_INSTALL_DIR
KNOTIFYRC_INSTALL_DIR
+ KXMLGUI_INSTALL_DIR
LIBEXEC_INSTALL_DIR
LIB_INSTALL_DIR
LOCALE_INSTALL_DIR
@@ -73,6 +74,7 @@ set(relative_path_vars
CMAKE_INSTALL_KCFGDIR
CMAKE_INSTALL_KCONFUPDATEDIR
CMAKE_INSTALL_KNOTIFY5RCDIR
+ CMAKE_INSTALL_KXMLGUI5DIR
CMAKE_INSTALL_KSERVICES5DIR
CMAKE_INSTALL_KSERVICETYPES5DIR
CMAKE_INSTALL_LIBDIR
@@ -117,6 +119,7 @@ set(absolute_path_vars
CMAKE_INSTALL_FULL_KCFGDIR
CMAKE_INSTALL_FULL_KCONFUPDATEDIR
CMAKE_INSTALL_FULL_KNOTIFY5RCDIR
+ CMAKE_INSTALL_FULL_KXMLGUI5DIR
CMAKE_INSTALL_FULL_KSERVICES5DIR
CMAKE_INSTALL_FULL_KSERVICETYPES5DIR
CMAKE_INSTALL_FULL_LIBDIR
diff --git a/kwrite/CMakeLists.txt b/kwrite/CMakeLists.txt
index 8ba24c6..365398c 100644
--- a/kwrite/CMakeLists.txt
+++ b/kwrite/CMakeLists.txt
@@ -17,4 +17,4 @@ target_link_libraries(kdeinit_kwrite
install(TARGETS kwrite ${INSTALL_TARGETS_DEFAULT_ARGS})
install(TARGETS kdeinit_kwrite ${INSTALL_TARGETS_DEFAULT_ARGS})
install(PROGRAMS org.kde.kwrite.desktop DESTINATION ${XDG_APPS_INSTALL_DIR})
-install(FILES kwriteui.rc DESTINATION ${DATA_INSTALL_DIR}/kwrite)
+install(FILES kwriteui.rc DESTINATION ${KXMLGUI_INSTALL_DIR}/kwrite)
usage: git [--version] [--help] [-c name=value]
[--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
[-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
[--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
<command> [<args>]
The most commonly used git commands are:
add Add file contents to the index
bisect Find by binary search the change that introduced a bug
branch List, create, or delete branches
checkout Checkout a branch or paths to the working tree
clone Clone a repository into a new directory
commit Record changes to the repository
diff Show changes between commits, commit and working tree, etc
fetch Download objects and refs from another repository
grep Print lines matching a pattern
init Create an empty Git repository or reinitialize an existing one
log Show commit logs
merge Join two or more development histories together
mv Move or rename a file, a directory, or a symlink
pull Fetch from and integrate with another repository or a local branch
push Update remote refs along with associated objects
rebase Forward-port local commits to the updated upstream head
reset Reset current HEAD to the specified state
rm Remove files from the working tree and from the index
show Show various types of objects
status Show the working tree status
tag Create, list, delete or verify a tag object signed with GPG
'git help -a' and 'git help -g' lists available subcommands and some
concept guides. See 'git help <command>' or 'git help <concept>'
to read about a specific subcommand or concept.
_______________________________________________
Kde-frameworks-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
