headers
Will Stephenson | 1 Nov 2009 09:45
Picon
Favicon
Gravatar

Re: Review Request: wetter.com Weather Ion


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2026/#review2882
-----------------------------------------------------------

I don't see a reason for the first leak you highlight in your code.  You should create the url using
QLatin1String as this saves QString having to guess the encoding -see
http://labs.trolltech.com/blogs/2008/04/28/string-theory/ for details.

The second leak is due to the main IonInterface (outside your code) leaking its d-pointer.  I can't see why it
or your WetterComIon::Private need to be QObjects, when they don't do any QObject-type things, so I'd
remove this unless I am wrong for some subtle reason.  I fixed this with r1043227 but you should probably
also remove the QObject inheritance from your code.

- Will

On 2009-10-31 14:02:05, Thilo-Alexander Ginkel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2026/
> -----------------------------------------------------------
> 
> (Updated 2009-10-31 14:02:05)
> 
> 
> Review request for kdelibs, Plasma and Shawn Starr.
> 
>
(Continue reading)

Permalink | Reply | 8 comments |
headers
David Faure | 1 Nov 2009 11:52
Picon
Favicon
Gravatar

Re: KDE is not an OS platform... (And neither is Gnome)

On Saturday 31 October 2009, Luciano Montanaro wrote:
> On venerdì 30 ottobre 2009, David Faure wrote:
> > On Friday 30 October 2009, Benoit Jacob wrote:
> > > 1) Make sure that both KIO and GVFS can be mounted into the OS's native
> > >  VFS. 2) Make it so that KIO and GVFS agree on a filesystem layout (a
> > > "name mangling" if you want) so that the same filename can be used
> > > regardless of the choice of KIO or GVFS. By a "name mangling" i mean a
> > > translation from addresses like "sftp://user <at> server/path" to addresses
> > > like "/mountpoint/ssh/user/server/path".
> >
> > Please keep in mind the difference between sync and async APIs.
> >
> > You download a file over FTP. KIO is async: the application remains
> >  responsive, you get a progress dialog. The "native VFS" is most of the
> >  time used in a blocking way. fopen,fwrite,fclose. Which means the
> >  application freezes until the FTP server sends the whole data. Not good.
> > A remote filesystem is NOT like the local filesystem.
> 
> Well, the filesystem calls are synchronous, yes, but that's not a problem
>  for the file:// kioslave, is it?

Right. But my point is that people saying "by mounting stuff into the filesystem
we can allow even non-KDE non-Gnome applications to benefit from kioslaves"
are omitting the fact that those non-kde non-gnome applications would then
use synchronous API, and would block for a very long time.
So a KIO-like API is needed. So mounting things into a filesystem mountpoint 
doesn't get you anything.

--

-- 
David Faure, faure <at> kde.org, http://www.davidfaure.fr
(Continue reading)

Permalink | Reply | 50 comments |
headers
David Faure | 1 Nov 2009 11:58
Picon
Favicon
Gravatar

Re: KDE is not an OS platform... (And neither is Gnome)

On Saturday 31 October 2009, Pau Garcia i Quiles wrote:
> In platforms where FUSE is not available, just fallback to plain KIO.

And how will you sort out the bugs, when someone says something
doesn't work, and we have no clue if that's on top of the KIO stack
or on top of the FUSE stack? Am I the only one who sees a problem
with "multiple backends" approaches? N times the maintainance,
N times the headache. And all this for providing a bad (because blocking) 
solution to non-kde apps !?

> > For instance FTP can't be mapped into the expected
> > POSIX behavior properly

Ah! Why am I not surprised...
And if that's a problem for FTP, it most certainly is a problem with
other protocols.

--

-- 
David Faure, faure <at> kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
Permalink | Reply | 1 comment |
headers
David Faure | 1 Nov 2009 12:05
Picon
Favicon
Gravatar

Re: Comicbook Thumbnails

On Saturday 31 October 2009, Qwerty Maniac wrote:
> Hi,
> 
> It _also_ uses a QEventLoop locally due to that, is that alright in a
> thumbnailer module?

Yes, because there is no main event loop running in kioslaves (so, no
socket handling nor non-modal GUI, and therefore no risk of 
reentrancy). kio_trash does this too.

--

-- 
David Faure, faure <at> kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror 
(http://www.konqueror.org).
Permalink | Reply | 1 comment |
headers
nf2 | 1 Nov 2009 15:08
Picon

Re: KDE is not an OS platform... (And neither is Gnome)

On Sun, Nov 1, 2009 at 11:52 AM, David Faure <faure <at> kde.org> wrote:
> On Saturday 31 October 2009, Luciano Montanaro wrote:
>> On venerdì 30 ottobre 2009, David Faure wrote:
>> > On Friday 30 October 2009, Benoit Jacob wrote:
>> > > 1) Make sure that both KIO and GVFS can be mounted into the OS's native
>> > >  VFS. 2) Make it so that KIO and GVFS agree on a filesystem layout (a
>> > > "name mangling" if you want) so that the same filename can be used
>> > > regardless of the choice of KIO or GVFS. By a "name mangling" i mean a
>> > > translation from addresses like "sftp://user <at> server/path" to addresses
>> > > like "/mountpoint/ssh/user/server/path".
>> >
>> > Please keep in mind the difference between sync and async APIs.
>> >
>> > You download a file over FTP. KIO is async: the application remains
>> >  responsive, you get a progress dialog. The "native VFS" is most of the
>> >  time used in a blocking way. fopen,fwrite,fclose. Which means the
>> >  application freezes until the FTP server sends the whole data. Not good.
>> > A remote filesystem is NOT like the local filesystem.
>>
>> Well, the filesystem calls are synchronous, yes, but that's not a problem
>>  for the file:// kioslave, is it?
>
> Right. But my point is that people saying "by mounting stuff into the filesystem
> we can allow even non-KDE non-Gnome applications to benefit from kioslaves"
> are omitting the fact that those non-kde non-gnome applications would then
> use synchronous API, and would block for a very long time.
> So a KIO-like API is needed. So mounting things into a filesystem mountpoint
> doesn't get you anything.
>
(Continue reading)

Permalink | Reply | 42 comments |
headers
Harsh J | 1 Nov 2009 14:34
Picon
Gravatar

Re: Review Request: Comic Book Thumbnailer


> On 2009-10-31 22:01:28, Ingo Klöcker wrote:
> > Please use shared pointers instead of C-pointers whereever it makes sense. Now that Qt finally provides
QSharedPointer (new in Qt 4.5) and QScopedPointer (new in Qt 4.6; see
http://doc.qt.nokia.com/4.6-snapshot/qscopedpointer.html) there's really no reason anymore for
risking memory leaks by using C-pointers which need to be deleted explicitly.

A few queries before I try changing the variables to QScopedPointer.

* To initialize a QImage, I'd have to do m_comicCover.reset(new QImage()) in the code, yes?
* Must I change all the current C-pointer types (QEventLoop, KArchiveDirectory etc.) to this type?

Would be helpful if I can understand when to do this and when not to..

- Harsh

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1983/#review2880
-----------------------------------------------------------

On 2009-10-31 21:37:21, Harsh J wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1983/
> -----------------------------------------------------------
> 
> (Updated 2009-10-31 21:37:21)
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dario Freddi | 1 Nov 2009 15:27
Picon
Gravatar

Re: KDE is not an OS platform... (And neither is Gnome)

On Sunday 01 November 2009 15:08:49 nf2 wrote:
> I agree. GUI applications should always use async APIs like KIO or
> GIO. But: At the moment many of them won't, because that implies
> deciding for a certain desktop environment. That's the problem i would
> like to solve.

As we discussed on IRC some time ago, this is where a shared interface should 
kick in and be implemented on both sides.

Then you can provide it in various forms (DBUS API as the main entry point, 
and eventually qt/gobject wrapper libraries to ease the dbus handling) to any 
3rd party application (such as firefox), and write bridges from/to KIO to/from 
GIO (as you are currently doing right now, if I understood correctly) to allow 
native KDE/GNOME applications to appear native on the other side as well.

Done that, there's no actual need to replace one or the other.

> 
> The free desktop desperately needs those 3rd party applications, and
> it's definitely not in the market position to tell application
> developers: "Then you just write your application twice! One for KDE
> and one for Gnome".

Let me remind you that, even if GNOME and KDE have a huge portion of the 
market, there are some other DE out there, that might (one day, if not 
already) have their own IO subsystem. And that's another good reason for 
having a shared interface

> 
> Regards,
(Continue reading)

Permalink | Reply | 41 comments |
headers
Qwerty Maniac | 1 Nov 2009 15:51
Picon
Gravatar

Re: Comicbook Thumbnails

Ok, great! Thanks for clearing this up :)

On Sun, Nov 1, 2009 at 4:35 PM, David Faure <faure <at> kde.org> wrote:
> On Saturday 31 October 2009, Qwerty Maniac wrote:
>> Hi,
>>
>> It _also_ uses a QEventLoop locally due to that, is that alright in a
>> thumbnailer module?
>
> Yes, because there is no main event loop running in kioslaves (so, no
> socket handling nor non-modal GUI, and therefore no risk of
> reentrancy). kio_trash does this too.
>
> --
> David Faure, faure <at> kde.org, http://www.davidfaure.fr
> Sponsored by Nokia to work on KDE, incl. Konqueror
> (http://www.konqueror.org).
>

--

-- 
Harsh J
www.harshj.com
Permalink | Reply | 0 comments |
headers
Benoit Jacob | 1 Nov 2009 15:58
Picon

Re: KDE is not an OS platform... (And neither is Gnome)

2009/11/1 David Faure <faure <at> kde.org>:
> On Saturday 31 October 2009, Luciano Montanaro wrote:
>> On venerdì 30 ottobre 2009, David Faure wrote:
>> > On Friday 30 October 2009, Benoit Jacob wrote:
>> > > 1) Make sure that both KIO and GVFS can be mounted into the OS's native
>> > >  VFS. 2) Make it so that KIO and GVFS agree on a filesystem layout (a
>> > > "name mangling" if you want) so that the same filename can be used
>> > > regardless of the choice of KIO or GVFS. By a "name mangling" i mean a
>> > > translation from addresses like "sftp://user <at> server/path" to addresses
>> > > like "/mountpoint/ssh/user/server/path".
>> >
>> > Please keep in mind the difference between sync and async APIs.
>> >
>> > You download a file over FTP. KIO is async: the application remains
>> >  responsive, you get a progress dialog. The "native VFS" is most of the
>> >  time used in a blocking way. fopen,fwrite,fclose. Which means the
>> >  application freezes until the FTP server sends the whole data. Not good.
>> > A remote filesystem is NOT like the local filesystem.
>>
>> Well, the filesystem calls are synchronous, yes, but that's not a problem
>>  for the file:// kioslave, is it?
>
> Right. But my point is that people saying "by mounting stuff into the filesystem
> we can allow even non-KDE non-Gnome applications to benefit from kioslaves"
> are omitting the fact that those non-kde non-gnome applications would then
> use synchronous API, and would block for a very long time.
> So a KIO-like API is needed. So mounting things into a filesystem mountpoint
> doesn't get you anything.

But what about my other mail above, where I mentioned that Linux 2.6
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sebastian Sauer | 1 Nov 2009 16:44
Gravatar

Review Request: startup faster; don't wait for kwin or kcm's in ksmserver


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2034/
-----------------------------------------------------------

Review request for kdelibs.

Summary
-------

* The fallback logic in wmProcessChange() does not work for kwin anyway cause kwin is the fallback. So, just
don't wait and increase startup by 1/2 second for me.

* Waiting for the initialization of kcm's is not needed. Saves another 1/2 second.

Diffs
-----

  /trunk/KDE/kdebase/workspace/ksmserver/startup.cpp 1042693 

Diff: http://reviewboard.kde.org/r/2034/diff

Testing
-------

Thanks,

Sebastian
(Continue reading)

Permalink | Reply | 9 comments |

Gmane