On Sunday 24 February 2013, Oswald Buddenhagen wrote:
On Sat, Feb 23, 2013 at 11:25:59PM +0100, David Faure wrote:
On Saturday 23 February 2013 19:05:34 Alexander Neundorf wrote:
At configure/cmake time, we can configure e.g. the data install dir,
the lib install dir and the install
On Friday 22 February 2013, David Faure wrote:
On Friday 22 February 2013 18:45:45 Alexander Neundorf wrote:
On Friday 22 February 2013, David Faure wrote:
On Thursday 21 February 2013 22:01:30 Alexander Neundorf wrote:
Why not have a KF5DIRS variable ?
You keep thinking KDE4,
On Saturday, 2013-02-23, Alexander Neundorf wrote:
I do not know the actual code, I am speaking more in the role of a
potential 3rd party user now, somebody who is working on a commercial
custom Qt-only application, who would like to use some kf5 libs.
make install, get the include dir and
On Saturday 23 February 2013 10:43:51 Alexander Neundorf wrote:
Well, it would be great if with KF5, if I install some library which needs
to find its own files, it would find them without needing the help from
environment variables.
You're forgetting the other cases where files have to be
On Saturday 23 February 2013, David Faure wrote:
On Saturday 23 February 2013 10:43:51 Alexander Neundorf wrote:
Well, it would be great if with KF5, if I install some library which
needs to find its own files, it would find them without needing the
help from environment variables.
wrote:
please have a look at the attached patch.
Ok to commit ?
This looks good, but it will break the code, if you don't also update
the code to look into these paths :)
Don't forget to run
perl -pi -e 's,kde5/service,kf5/service,g' `git grep -l kde5/service
On Thursday 21 February 2013 22:01:30 Alexander Neundorf wrote:
Why not have a KF5DIRS variable ?
You keep thinking KDE4, renamed :-)
Think of KF5 as standalone libs on top of Qt. Do you currently have to set a
QCADIRS to use QCA, and a ATTICADIRS to use attica, and a SOPRANODIRS to use
On Friday 22 February 2013, David Faure wrote:
On Thursday 21 February 2013 22:01:30 Alexander Neundorf wrote:
Why not have a KF5DIRS variable ?
You keep thinking KDE4, renamed :-)
Think of KF5 as standalone libs on top of Qt. Do you currently have to set
a QCADIRS to use QCA, and a
,kde5/service,kf5/service,g' `git grep -l
kde5/service` perl -pi -e 's,kde5/libexec,kf5/libexec,g' `git grep
-l kde5/libexec` in kdelibs (and plasma-framework?) when you
commit.
Ah, I didn't expect that to be hardcoded.
Yeah, it's a subdir, and without kstandarddirs we
On Friday 22 February 2013 18:45:45 Alexander Neundorf wrote:
On Friday 22 February 2013, David Faure wrote:
On Thursday 21 February 2013 22:01:30 Alexander Neundorf wrote:
Why not have a KF5DIRS variable ?
You keep thinking KDE4, renamed :-)
Think of KF5 as standalone libs on top
On Friday 22 February 2013 19:29:48 Alexander Neundorf wrote:
On Friday 22 February 2013, David Faure wrote:
How about we make it
CMAKE_INSTALL_PREFIX / LIB_INSTALL_DIR /libexec/kioslave?
Then on Windows, we can just request that PATH contains that (unique)
libexec directory, and we have
On Wednesday 20 February 2013 22:47:15 Alexander Neundorf wrote:
please have a look at the attached patch.
Ok to commit ?
This looks good, but it will break the code, if you don't also update the code
to look into these paths :)
Don't forget to run
perl -pi -e 's,kde5/service,kf5/service,g
forget to run
perl -pi -e 's,kde5/service,kf5/service,g' `git grep -l kde5/service`
perl -pi -e 's,kde5/libexec,kf5/libexec,g' `git grep -l kde5/libexec`
in kdelibs (and plasma-framework?) when you commit.
Ah, I didn't expect that to be hardcoded.
How does QStandardPaths::writableLocation
?
This looks good, but it will break the code, if you don't also update
the code to look into these paths :)
Don't forget to run
perl -pi -e 's,kde5/service,kf5/service,g' `git grep -l kde5/service`
perl -pi -e 's,kde5/libexec,kf5/libexec,g' `git grep -l kde5/libexec
On Monday 18 February 2013, Alexander Neundorf wrote:
On Sunday 17 February 2013, David Faure wrote:
On Saturday 16 February 2013 17:23:46 Sune Vuorela wrote:
On 2013-02-16, Alexander Neundorf neund...@kde.org wrote:
_set_fancy(LIBEXEC_INSTALL_DIR ${LIB_INSTALL_DIR}/kde5/libexec)
is necessary there, to separate kde4-based from KF5-based plugins.
But IIRC Kévin convinced me some time ago to say kf5 instead of kde5.
My thinking was any app will want to install stuff there, so it's not kf5-
specific, but this is about adding files for use by the KF5 kservices
framework, so why
On Monday, February 18, 2013 20:37:20 Alexander Neundorf wrote:
Right.
But AFAIK we always tried to say that there will be no KDE 5...
As Sebas confirms in his email.
And if we'll call it KDE 5 anyway, then why not just use kde5 in names
instead of kf5, which doesn't have the well-known kde
On Sunday, 2013-02-17, David Faure wrote:
The thing is, it could be either a pure QStandardPaths equivalent, or for
more compatibility with kde4-config it would also still answer requests
for e.g. --path xdgdata-icon, even if internally that's just
GenericDataLocation + /icons.
In the
kde4-based from KF5-based plugins.
But IIRC Kévin convinced me some time ago to say kf5 instead of kde5.
My thinking was any app will want to install stuff there, so it's not kf5-
specific, but this is about adding files for use by the KF5 kservices
framework, so why not.
Executive summary
if we go with kde5, I don't see a strong reason to use kf5 in
the plugin install directory.
Just to be clear (I think I wasn't in my previous email): it should be
kf5, not kde5.
Just to be clear too, I don't have a strong opinion on the naming, but if
we continue to say
)
The tool kde4-config has also been renamed to kde5-config.
So if we go with kde5, I don't see a strong reason to use kf5
in the plugin install directory.
Just to be clear (I think I wasn't in my previous email): it should
be kf5, not kde5.
Just to be clear too, I don't
On Monday 18 February 2013 20:37:20 Alexander Neundorf wrote:
On Monday 18 February 2013, David Faure wrote:
I'm not sure what you have in mind here. There's no concrete plans that I
know of, it's too early for that, but I also don't see any point in a
4.15... What would that mean? Porting
): it should be kf5,
not kde5.
Just to be clear too, I don't have a strong opinion on the naming, but if we
continue to say that KDE based on kf5 will still be KDE 4, then we should not
use kde5 in various places.
What will the version number of the first KDE SC release based on KDE
frameworks
On Saturday 16 February 2013 21:39:42 Sune Vuorela wrote:
On 2013-02-16, Alexander Neundorf neund...@kde.org wrote:
The tool kde4-config has also been renamed to kde5-config.
What's the purpose of this tool in a non-monolithic world?
For many purposes (scripting, debugging), we do need a
Hi,
AFAIK KDE based on KDE frameworks will not be KDE 5, but still KDE4.
So... I noticed that we install some things to directories containing kf5,
e.g.
_set_fancy(PLUGIN_INSTALL_DIR${QT_PLUGIN_INSTALL_DIR}/kf5)
but several other things to kde5:
set(BUNDLE_INSTALL_DIR
install application parts or metadata it should say
kde5.
So in your example above the use of kf5 vs kde5 doesn't bother me much except
for probably libexec which is likely about runtime dependencies of frameworks.
Regards.
--
Kévin Ottens, http://ervin.ipsquad.net
Sponsored by BlueSystems and KDAB
parts of the frameworks or runtime
dependencies of frameworks it should say kf5;
* If that's where we install application parts or metadata it should say
kde5.
So in your example above the use of kf5 vs kde5 doesn't bother me much
except for probably libexec which is likely about runtime
above the use of kf5 vs kde5 doesn't bother me much
except for probably libexec which is likely about runtime dependencies
of frameworks.
There is no kde5.
Everything refering to software, pathes and all that should be kf5. It does
not make sense for our libs, neither does it make sense
On 2013-02-16, Alexander Neundorf neund...@kde.org wrote:
_set_fancy(LIBEXEC_INSTALL_DIR ${LIB_INSTALL_DIR}/kde5/libexec)
I still don't see a reason for a *shared* libexec directory. libexec is
implementation details of specific libraries, just like one shouldn't
mess around with each others
On 2013-02-16, Alexander Neundorf neund...@kde.org wrote:
The tool kde4-config has also been renamed to kde5-config.
What's the purpose of this tool in a non-monolithic world?
/Sune
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
30 matches
Mail list logo
