Hi Jeremy,
On 02/03/2015, at 11:42 PM, Jeremy Whiting wrote:
> I read that KDEInstallDirs documentation [2], and it seems it's a bit outdated
Well, it is part of the official documentation for ECM, in api.kde.org, so it
*ought* to be up-to-date, but there is no date or version number AFAICS.
What
Hi Ian,
On 02 Mar 2015, at 03:30 , Ian Wadham wrote:
> I am talking about regular apps, not Frameworks, but I am glad that
> Frameworks'
> doctools is inserting the "kf5/" subdir.
> But also I expect "/Library/Application Support/kxmlgui5/“,
> If I have understood [2] correctly (BTW there seem
On Sunday March 01 2015 17:37:35 Ian Wadham wrote:
Hi Ian
>Let me kick off by saying that I am not necessarily in favour of "doing what
>the Romans do"… ;-)
Heh, I got that! :)
>And I do not like directory names with a space in them
>either, but that is just an annoying detail...
I *hope* it
Ian,
I read that KDEInstallDirs documentation, and it seems it's a bit outdated
or at least not complete. If I change just -DKDE_INSTALL_DATADIR but
nothing else here. kdesrc-build is installing data (stuff that went under
$prefix/share) in "~/Library/Application Support" but nothing else so far.
Hi René,
On 01/03/2015, at 8:17 PM, René J.V. Bertin wrote:
> On Sunday March 01 2015 17:37:35 Ian Wadham wrote:
>> Let me kick off by saying that I am not necessarily in favour of "doing what
>> the Romans do"… ;-)
>
> Heh, I got that! :)
Yeah, but I am keeping an open mind…
>> And I do not
Hi Jeremy,
My apologies for going back to basics. Some things you said earlier made me
think we are not on the same page, but I now see that we are.
On 02/03/2015, at 3:15 AM, Jeremy Whiting wrote:
>
> The example code you've given does already use prefixes. I'll explain below.
>
> On Sat, Feb
Ian,
The example code you've given does already use prefixes. I'll explain below.
On Sat, Feb 28, 2015 at 7:56 PM, Ian Wadham wrote:
> Hi Jeremy,
>
> On 28/02/2015, at 11:20 PM, Jeremy Whiting wrote:
> > On Sat, Feb 28, 2015 at 4:51 AM, René J.V. wrote:
> > On Saturday February 28 2015 22:00:0
On February 28, 2015 1:20:27 PM CET, Jeremy Whiting wrote:
>Then data will all be under ~/Library/Application Support/Qt5/appname ?
I think Ian's idea was not to use the appname bit (for stuff shared with other
apps).
>that's a bit cleaner, but why would Qt/KDE applications need to use a
>n
On Saturday February 28 2015 22:00:07 Ian Wadham wrote:
Hi Ian,
> Esprit d'escalier. We could change GenericDataDir in QStandardPaths to be:
>
> "~/Library/Application Support/Qt5", "/Library/Application Support/Qt5"
>
> That would work for ALL applications that use Qt5 and QSP, regardles
On Saturday February 28 2015 18:12:40 Ian Wadham wrote:
>One problem is that these are NOT exactly like "~/.local/share",
>"/usr/local/share",
>"~/.local/share/" and "/usr/local/share/" on Linux.
...
>A bundle identifier is something like "org.kde.". Actually, on my
>system I find:
>
>Tara:
Hi René,
Let me kick off by saying that I am not necessarily in favour of "doing what
the Romans do"… ;-) And I do not like directory names with a space in them
either, but that is just an annoying detail...
I just wanted to follow up on Jeremy's experiments at the start of this thread
(and subs
Hello Ralf,
On 28/02/2015, at 7:32 PM, Ralf Habacker wrote:
> Am 28.02.2015 um 08:12 schrieb Ian Wadham:
>> But I do not know how or when this could be done. Clearly, we cannot
>> hard-wire that into
>> the QSP code, because there are other apps that use Qt but do not come from
>> the KDE
>> Co
Hi Jeremy,
On 28/02/2015, at 11:20 PM, Jeremy Whiting wrote:
> On Sat, Feb 28, 2015 at 4:51 AM, René J.V. wrote:
> On Saturday February 28 2015 22:00:07 Ian Wadham wrote:
> > > We could change GenericDataDir in QStandardPaths to be:
> > >
> > > "~/Library/Application Support/Qt5", "/Library/
On Sat, Feb 28, 2015 at 4:51 AM, René J.V. wrote:
> On Saturday February 28 2015 22:00:07 Ian Wadham wrote:
>
> Hi Ian,
>
> > Esprit d'escalier. We could change GenericDataDir in QStandardPaths to
> be:
> >
> > "~/Library/Application Support/Qt5", "/Library/Application
> Support/Qt5"
> >
>
Hi René,
On 28/02/2015, at 8:15 PM, René J.V. Bertin wrote:
> On Saturday February 28 2015 18:12:40 Ian Wadham wrote:
>
>> One problem is that these are NOT exactly like "~/.local/share",
>> "/usr/local/share",
>> "~/.local/share/" and "/usr/local/share/" on Linux.
> ...
>> A bundle identifier i
Am 28.02.2015 um 08:12 schrieb Ian Wadham:
> But I do not know how or when this could be done. Clearly, we cannot
> hard-wire that into
> the QSP code, because there are other apps that use Qt but do not come from
> the KDE
> Community. It would be easy enough to put it into ECM modules when b
Hi Jeremy,
On 27/02/2015, at 2:03 PM, Jeremy Whiting wrote:
> Yeah, obviously to share with all users installing data files into
> /Library/Application Support/ is better, I just didn't do that in my test
> since my user doesn't own that folder and I didn't want to install with sudo
> for a tes
Yeah, obviously to share with all users installing data files into
/Library/Application Support/ is better, I just didn't do that in my test
since my user doesn't own that folder and I didn't want to install with
sudo for a test.
On Thu, Feb 26, 2015 at 7:26 PM, Aleix Pol wrote:
> On Thu, Feb 26
On Thu, Feb 26, 2015 at 10:45 AM, René J.V. wrote:
> On Wednesday February 25 2015 19:10:08 Jeremy Whiting wrote:
>
>>QStandardPaths there that worked pretty well. In discussion with the Qt
>>developers I began to think that we maybe should be installing our data
>>files in the places that QStanda
On Wednesday February 25 2015 19:10:08 Jeremy Whiting wrote:
>QStandardPaths there that worked pretty well. In discussion with the Qt
>developers I began to think that we maybe should be installing our data
>files in the places that QStandardPaths expect to find them, rather than
>get QStandardPat
20 matches
Mail list logo
