On Thu, Nov 4, 2010 at 5:24 PM, Kevin Ottens wrote:
> On Thursday 4 November 2010 18:58:09 Dawit A wrote:
>> BTW, I noticed a couple of things in UDisksManager that I want to ask
>> about... The first issue is why does a device that has its
>> "DeviceIsOpticalDisc" property set to true inserted in
---
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/5770/
---
Review request for kdelibs and Kevin Ottens.
Summary
---
This patch add
---
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/5769/
---
Review request for kdelibs and Kevin Ottens.
Summary
---
This patch add
On Wednesday 27 October 2010, Pavel Heimlich, a.k.a. hajma wrote:
> 2010/10/26 Christophe Giboudeaux :
> > Hi,
> >
> > This week, Akonadi, Attica and Soprano moved from the KDE SVN repo to
> > our new Git one.
> >
> > This means you should update your local checkouts right now.
> >
> > You will fin
On Thursday 4 November 2010 18:58:09 Dawit A wrote:
> BTW, I noticed a couple of things in UDisksManager that I want to ask
> about... The first issue is why does a device that has its
> "DeviceIsOpticalDisc" property set to true inserted into the
> m_deviceCache 2x, once normally and once with ":m
On Thursday, 4. November 2010 20:12:27 John Layt wrote:
> Huh. In spite of what the QtMobility site says about the desktop platforms
> being fully supported, it appears they are not. Looking at the 1.10 beta2
> code release, there are no backends for Linux/Mac/Win, only for S60 and
> Maemo. The M
On Thursday, 4. November 2010 19:59:51 Cyrille Berger Skott wrote:
> > Choosing QtMobility also almost feels like a betrayal of the Marble guys
> > as it would inevitably mean apps would choose to use the QtMobility Map
> > and Navigation stuff for compatibility, unless Marble has some feature
> >
On Thursday, November 04, 2010 12:49:31 pm Ariya Hidayat wrote:
> > Huh. In spite of what the QtMobility site says about the desktop
> > platforms being fully supported, it appears they are not. Looking at
> > the 1.10 beta2
>
> Desktop is Tier 2 for Qt Mobility support.
>
> Priority will be al
> Huh. In spite of what the QtMobility site says about the desktop platforms
> being fully supported, it appears they are not. Looking at the 1.10 beta2
Desktop is Tier 2 for Qt Mobility support.
Priority will be always Tier 1, of course.
On Thursday 04 November 2010 18:21:55 John Layt wrote:
> I need to investigate what QtMobility does on desktops (Win and Mac too) if
> Geoclue isn't available. It looks like the Ovi backend isn't an option due
> to the current license. If QtMobility doesn't provide any other backend
> on desktop
On Thursday 04 November 2010 17:01:05 Aaron J. Seigo wrote:
> so we'd have to reimplement the core functionality, which leaves us with
> just the geoclue API and the design done for us. the only way this would
> be a win, imho, is if geoclue was already widely deployed on the target
> system. for
BTW, I noticed a couple of things in UDisksManager that I want to ask
about... The first issue is why does a device that has its
"DeviceIsOpticalDisc" property set to true inserted into the
m_deviceCache 2x, once normally and once with ":media" attached to it
? The second issue is why even bother w
On Thursday, November 4, 2010, John Layt wrote:
> On Wednesday 03 November 2010 22:27:11 Aaron J. Seigo wrote:
> > that said, what dependencies does Geoclue have these days? it used to
> > depend on gconf, which would be a highly unfortunate dependency for
> > kdelibs to acquire. it was said a few
On Thursday, November 4, 2010, Kevin Krammer wrote:
> We don't get any additional dependency, nor do we have to track them.
on devices with constrainted disk, it matters.
for projects that have to maintain the stack on a specific device, every
additional dependency that gets pulled in, it matter
On Thursday 04 November 2010 07:23:38 Cyrille Berger Skott wrote:
> On Wednesday 03 November 2010, John Layt wrote:
> > * Comes packaged with lots of other services that we don't need, such as
> > Solid, Phonon and kdepim equivalents.
>
> It is worth to note that QtMobility is very modular, so you
On Thursday, November 04, 2010 16:56:54 Kevin Krammer wrote:
> On Thursday, 2010-11-04, Sebastian Kügler wrote:
> > On Thursday, November 04, 2010 16:04:33 John Layt wrote:
> > > Which kind-of makes the whole GConf usage moot?
> >
> > No, it doesn't. If that stuff is still needed for actually usi
Am Donnerstag, 4. November 2010 16:46:34 schrieb Ariya Hidayat:
> > API I'm not sure whether we can legally make use of it:
> IANAL but it seems as long as you don't initialize/start using the Ovi
> Maps provider plugin, you should be good. We do not need to remove the
> plugin code completely from
On Thursday, 2010-11-04, Sebastian Kügler wrote:
> On Thursday, November 04, 2010 16:04:33 John Layt wrote:
> > Which kind-of makes the whole GConf usage moot?
>
> No, it doesn't. If that stuff is still needed for actually using it, we're
> still effectively depending on whateverlibgconfisin, and
> From looking at the current state of the Terms and Conditions of the Ovi Maps
> API I'm not sure whether we can legally make use of it:
IANAL but it seems as long as you don't initialize/start using the Ovi
Maps provider plugin, you should be good. We do not need to remove the
plugin code comple
On Thursday, November 04, 2010 16:04:33 John Layt wrote:
> Which kind-of makes the whole GConf usage moot?
No, it doesn't. If that stuff is still needed for actually using it, we're
still effectively depending on whateverlibgconfisin, and that, as Aaron points
out would be rather unfortunate.
B
On Thursday 04 November 2010 14:43:19 Kevin Krammer wrote:
> Ah, you meant using the D-Bus API directly in apps. I interpreted it as in
> not using their C library, i.e. using D-Bus indirectly (through their C
> wrapper).
Phew!
Yes, just to be clear, our api would only call their DBus interfac
On Thursday, 2010-11-04, John Layt wrote:
> We'd then have only one place where we generate the QDbus adaptor instead
> of 50, only one copy of the template set-up/tear-down code instead of 50,
> and only one place that needs maintenance if/when Geoclue changes. [I do
> need to read more on how
On Thu, Nov 4, 2010 at 3:06 AM, Kevin Ottens wrote:
> On Thursday 4 November 2010 02:00:40 Dawit A wrote:
>> On Wed, Nov 3, 2010 at 3:24 PM, Lukáš Tinkl wrote:
>> > Thanks, I'll look into it tomorrow... things can definitely get faster :)
>>
>> To that end I have consolidated all my local changes
On Thursday 04 November 2010 08:54:55 Vishesh Handa wrote:
> Isn't the whole point of Geoclue to provide a telepathy-like-abstraction of
> location providers? ( or phonon like :) What huge advantage would there be
> in implementing yet another abstraction on top of Geoclue? Apart from the
> fact t
On Thursday 04 November 2010 09:01:12 Kevin Krammer wrote:
> On Wednesday, 2010-11-03, Aaron J. Seigo wrote:
> > a) annoyance of using DBus directly
>
> It's a single line in the CMakeLists.txt, isn't it?
>
> > b) changes in the DBus API are out of our control.
>
> Sure, but upstream API changes
On Wednesday, 2010-11-03, Aaron J. Seigo wrote:
> On Wednesday, November 3, 2010, Kevin Krammer wrote:
> > On Wednesday, 2010-11-03, John Layt wrote:
> > > The obvious backend solution is Geoclue, a freedesktop.org project
> > > which is available on almost all distro's now, is used by Gnome, and
>
On Thu, Nov 4, 2010 at 2:04 PM, John Layt wrote:
> On Wednesday 03 November 2010 22:27:11 Aaron J. Seigo wrote:
>
> > that said, what dependencies does Geoclue have these days? it used to
> > depend on gconf, which would be a highly unfortunate dependency for
> > kdelibs to acquire. it was said a
On Wednesday 03 November 2010 22:27:11 Aaron J. Seigo wrote:
> that said, what dependencies does Geoclue have these days? it used to
> depend on gconf, which would be a highly unfortunate dependency for
> kdelibs to acquire. it was said a few years (!) back that this dependency
> would be easy to
On Thursday 4 November 2010 02:00:40 Dawit A wrote:
> On Wed, Nov 3, 2010 at 3:24 PM, Lukáš Tinkl wrote:
> > Thanks, I'll look into it tomorrow... things can definitely get faster :)
>
> To that end I have consolidated all my local changes into a single
> patch and updated bug # 253039 with it. F
29 matches
Mail list logo
