> On Ян. 25, 2016, 10 преди обяд, Martin Gräßlin wrote:
> > Pointing out the obvious: though shall not animate window positions! This
> > needs to be moved to KWin (I'm disappointed that such code still exists in
> > frameworks). Which would kind of solve the problems automatically.
> >
> > Of
On Donnerstag, 28. Januar 2016 12:07:54 CET Andre Heinecke wrote:
> Hi,
>
> On Wednesday 27 January 2016 21:28:36 Andreas Hartmetz wrote:
> > On Mittwoch, 27. Januar 2016 17:21:33 CET Boudewijn Rempt wrote:
> > [snip]
> >
> > > whether kglobalshortcuts is functional or not is besides the
> > > po
On Thu, Jan 28, 2016 at 8:12 PM, Stephen Kelly wrote:
> Aleix Pol wrote:
>>> QML bindings are "one layer above" the class they bind. Just like
>>> kdebindings is separate rather than "mixed into every framework". Having
>>> the javascript bindings for KIO in KIO would tick all your criterias
>>> a
Aleix Pol wrote:
>> QML bindings are "one layer above" the class they bind. Just like
>> kdebindings is separate rather than "mixed into every framework". Having
>> the javascript bindings for KIO in KIO would tick all your criterias
>> above ("simpler to use because part of the framework", "all th
René J. V. Bertin wrote:
> Which is all I'm hinting at, and certainly not that a single (or small group
> of) person(s) implement this for all platforms.
Of course, if cross-process WIds are basically only usable under X11/Xcb one
could probably replace their use with something that encapsulates
> On Jan. 26, 2016, 6:40 p.m., Aleix Pol Gonzalez wrote:
> > Hi,
> > I'm a bit afraid of all these ifndef. Do you think it would make sense to
> > abstract out the KGlobalAccel usage?
> >
> > Otherwise, would it be possible to make KGlobalAccel useful (or just dumb)
> > on Windows?
>
> Boudew
Martin Graesslin wrote:
> What we do is take the KF5 based software and integrate it into our platform.
> That's the same as you are doing. You integrate KF5 based software into OSX.
> The only difference is that we also have full control over the platform.
>
> So far where we have done this we
> On Jan. 26, 2016, 7:40 p.m., Aleix Pol Gonzalez wrote:
> > Hi,
> > I'm a bit afraid of all these ifndef. Do you think it would make sense to
> > abstract out the KGlobalAccel usage?
> >
> > Otherwise, would it be possible to make KGlobalAccel useful (or just dumb)
> > on Windows?
>
> Boudew
> On Jan. 26, 2016, 6:40 p.m., Aleix Pol Gonzalez wrote:
> > Hi,
> > I'm a bit afraid of all these ifndef. Do you think it would make sense to
> > abstract out the KGlobalAccel usage?
> >
> > Otherwise, would it be possible to make KGlobalAccel useful (or just dumb)
> > on Windows?
>
> Boudew
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126895/
---
(Updated Jan. 28, 2016, 1:29 p.m.)
Review request for KDE Frameworks.
C
> On Jan. 26, 2016, 7:40 p.m., Aleix Pol Gonzalez wrote:
> > Hi,
> > I'm a bit afraid of all these ifndef. Do you think it would make sense to
> > abstract out the KGlobalAccel usage?
> >
> > Otherwise, would it be possible to make KGlobalAccel useful (or just dumb)
> > on Windows?
>
> Boudew
> On Jan. 26, 2016, 6:40 p.m., Aleix Pol Gonzalez wrote:
> > Hi,
> > I'm a bit afraid of all these ifndef. Do you think it would make sense to
> > abstract out the KGlobalAccel usage?
> >
> > Otherwise, would it be possible to make KGlobalAccel useful (or just dumb)
> > on Windows?
>
> Boudew
Hi,
On Wednesday 27 January 2016 21:28:36 Andreas Hartmetz wrote:
> On Mittwoch, 27. Januar 2016 17:21:33 CET Boudewijn Rempt wrote:
> [snip]
>
> > whether kglobalshortcuts is functional or not is besides the point:
> > the point is that whether it works or not it doesn't add any
> > functionalit
GENERAL INFO
BUILD SUCCESS
Build URL:
https://build.kde.org/job/kio%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/216/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 28 Jan 2016 10:56:16 +
Build duration: 6 min 21 sec
CHANGE SET
Revision a39bcd6e7fde4cd91c6aeea38d91da37b458012b b
GENERAL INFO
BUILD SUCCESS
Build URL:
https://build.kde.org/job/kio%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/216/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 28 Jan 2016 10:56:16 +
Build duration: 6 min 21 sec
CHANGE SET
Revision a39bcd6e7fde4cd91c6aeea38d91da37b458012b b
On Thursday, January 28, 2016 11:10:20 AM CET Jaroslaw Staniek wrote:
> Now instead of that, everything but truly uncommon stuff would be ON by
> default. If someone knows what she/he is doing, will set to OFF but this
> will be actually a choice, hopefully informed choice.
>
> Can we encourage
On Thu, 28 Jan 2016, Aleix Pol wrote:
The problem I see with having a big KDeclarative framework is that it
requires to have many KDE Frameworks available. The root
CMakeLists.txt file [4] already shows that it's full of conditionals
and it largely depends on whether the actual framework is avai
On Thu, 28 Jan 2016, Aleix Pol wrote:
Personally, I don't really see how QtQml build-time dependency is
holding back the adoption of KCoreAddons. Is QtQml something that
often isn't available?
All dependencies are bad. Really -- I know I sound like a broken record here,
but _all_ dependencies
On Sat, Jan 23, 2016 at 12:05 PM, David Faure wrote:
> On Tuesday 19 January 2016 10:11:06 Aleix Pol wrote:
>> On Tue, Jan 19, 2016 at 9:15 AM, David Faure wrote:
>> > Git commit 3b13ef97925725b2a273a4d3e7d1c0c7e151522d by David Faure.
>> > Committed on 19/01/2016 at 08:14.
>> > Pushed by dfaure
On Thu, Jan 28, 2016 at 1:11 AM, David Faure wrote:
> On Wednesday 27 January 2016 18:19:49 Aleix Pol wrote:
>> Hi,
>> I would like to move KCoreAddons qml plugin into KCoreAddons. Now it's
>> KDeclarative where we are dumping all QML plugins.
>>
>> I think it's a good idea because:
>> - it simpli
On 27 January 2016 at 21:28, Andreas Hartmetz wrote:
> On Mittwoch, 27. Januar 2016 17:21:33 CET Boudewijn Rempt wrote:
> [snip]
>
> > whether kglobalshortcuts is functional or not is besides the point:
> > the point is that whether it works or not it doesn't add any
> > functionality to the aver
On Thursday, January 28, 2016 10:40:57 AM CET René J. V. Bertin wrote:
> Martin Graesslin wrote:
> > Sorry, we *are* the platform. If we extend the desktop shell to [...]
>
> With all due respect, that sounds very wrong for software that's supposed to
> be cross-platform. At the very least those d
Martin Graesslin wrote:
> Sorry, we *are* the platform. If we extend the desktop shell to [...]
With all due respect, that sounds very wrong for software that's supposed to be
cross-platform. At the very least those desktop shell extensions should be
accessed via KF5 or Qt APIs designed to have
Am 28.01.2016 um 09:48 schrieb David Faure:
> On Wednesday 27 January 2016 10:32:50 Boudewijn Rempt wrote:
>> On Sat, 23 Jan 2016, David Faure wrote:
>>
>>> Not sure this answers Boud's question, since he *is* seeing "Local" on
>>> Windows.
>>> He said: "I noticed that krita on windows wrote its k
On Thu, 28 Jan 2016, David Faure wrote:
Sounds to me like Patrick's pending patch to add configurable paths in
QStandardPaths using qt.conf
would work exactly right for this. Your windows installer for krita would
install a qt.conf where
GenericConfigLocation = [...]\AppData\Roaming\Krita.
On Wednesday 27 January 2016 10:32:50 Boudewijn Rempt wrote:
> On Sat, 23 Jan 2016, David Faure wrote:
>
> >
> > Not sure this answers Boud's question, since he *is* seeing "Local" on
> > Windows.
> > He said: "I noticed that krita on windows wrote its kritarc to
> > Roaming\local\ or Local\loca
Hi
I like the idea to move away from dbus.
It's better for sure.
Le jeudi 28 janvier 2016, 01:33:32 CET David Faure a écrit :
> I'm working on a replacement for the favicons kded module (which lives in
> libkonq), which will be a class in kio instead (proper C++ API certainly
> beats just a DBus
> On Jan. 26, 2016, 7:40 p.m., Aleix Pol Gonzalez wrote:
> > Hi,
> > I'm a bit afraid of all these ifndef. Do you think it would make sense to
> > abstract out the KGlobalAccel usage?
> >
> > Otherwise, would it be possible to make KGlobalAccel useful (or just dumb)
> > on Windows?
>
> Boudew
On Wednesday, January 27, 2016 10:06:00 PM CET René J. V. Bertin wrote:
> Martin Graesslin wrote:
> > That depends on the Wayland compositor. In Plasma (KWin) we will certainly
> > make sure this works properly.
>
> I'd appreciate if that could be done in a way that makes sense on other
> platform
On Thursday, January 28, 2016 1:11:38 AM CET David Faure wrote:
> I honestly don't see the problem with having this in KDeclarative, but maybe
> I'm missing a good reason for splitting such qml plugins into a separate
> framework. Or maybe there's no point in doing that either.
The problem is that
On Wed, 26 Jan 2016, Andreas Hartmetz wrote:
Here is something that is never beside the point:
maintenance burden and continuous-integration-ability.
ifdefs are somewhat bad for maintainability and really, really bad for a
continuous integration systems's ability to detect relevant build
break
On Wed, 27 Jan 2016, Matthew Dawson wrote:
Won't this change the behaviour from Unix like systems? They won't have the
Krita folder in the name, so they will just get dumped in the common config
folder. I don't think carrying a patch like that for KConfig is a good idea.
Yes, but that's exa
32 matches
Mail list logo
