--e89a8fb206a8785ade04d14a75a7 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 20, 2012 at 8:47 PM, Frank Reininghaus wrote: > Hi Vishesh, > > 2012/12/20 Vishesh Handa: > > Hey Frank > > > > I know I'm very very late, but I finally fixed the few annoying bugs in > > Nepomuk2::FileMetadataWidget, and even made it show data when Nepomuk in > not > > running. > > Sounds good, thanks! > > > I think this satisfies all the conditions that you had. > > > > Would it be possible to use it for 4.10? I would really like it cause > then I > > don't have to fix the bugs in KFileMetadatWidget for 4.10. I've attached > a > > patch which uses it instead of the KFileMetadataWidget. > > > > Current problems - > > > > 1. When right clicking on the file -> Properties -> Information. This > > Information is supposed to be the same as what is displayed in the > > Information Panel. However, its code resides in kio, and cannot be made > to > > use Nepomuk::FileMetadataWidget. > > > > 2. Configure Shown Data -> Internally, Nepomuk's FileMetadataWidget also > > uses the same config file, but this might have problems. Maybe I should > have > > my own different config file. > > > > I really want to get this into 4.10 cause it makes my job a lot easier. I > > don't need to maintain the kdelibs/nepomuk code then. It would also make > bug > > fixing a lot easier. > > > > What do you think? > > We are in hard feature freeze since November 8 [1], so it seems to me > that this can only go into the master branch. > Well. I was hoping you wouldn't consider this a feature. It's just a port of KFileMetadataWidget to Nepomuk2. At the end, it's your call. There are significant advantages of moving to the new MetadataWidget. Since the previous one used a separate process, it could not utilize any of the cache, and had to query the db each time a file was selected. Considering that Dolphin internally uses Nepomuk to show a lot of metadata, the data would already be loaded in memory and we wouldn't have to query for it again and again. I hate the idea of users having to wait 8 months to get these improvements. Anyway, it's your choice. I do hope you reconsider. > Best regards, > Frank > > [1] > http://techbase.kde.org/Schedules/KDE4/4.10_Release_Schedule#Thursday.2C_November_8.2C_2012:_KDE_SC_4.10_Hard_Feature_Freeze > -- Vishesh Handa --e89a8fb206a8785ade04d14a75a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Dec 20, 2012 at 8:47 PM, Frank Reininghaus <frank78= ac@googlemail.com> wrote:
Hi Vishesh,

2012/12/20 Vishesh Handa:
> Hey Frank
>
> I know I'm very very late, but I finally fixed the few annoying bu= gs in
> Nepomuk2::FileMetadataWidget, and even made it show data when Nepomuk = in not
> running.

Sounds good, thanks!

> I think this satisfies all the conditions that you had.
>
> Would it be possible to use it for 4.10? I would really like it cause = then I
> don't have to fix the bugs in KFileMetadatWidget for 4.10. I'v= e attached a
> patch which uses it instead of the KFileMetadataWidget.
>
> Current problems -
>
> 1. When right clicking on the file -> Properties -> Information.= This
> Information is supposed to be the same as what is displayed in the
> Information Panel. However, its code resides in kio, and cannot be mad= e to
> use Nepomuk::FileMetadataWidget.
>
> 2. Configure Shown Data -> Internally, Nepomuk's FileMetadataWi= dget also
> uses the same config file, but this might have problems. Maybe I shoul= d have
> my own different config file.
>
> I really want to get this into 4.10 cause it makes my job a lot easier= . I
> don't need to maintain the kdelibs/nepomuk code then. It would als= o make bug
> fixing a lot easier.
>
> What do you think?

We are in hard feature freeze since November 8 [1], so it seems to me=
that this can only go into the master branch.

Well. I was hoping you wouldn't consider this a feature. It'= s just a port of KFileMetadataWidget to Nepomuk2.

At the = end, it's your call. There are significant advantages of moving to the = new MetadataWidget. Since the previous one used a separate process, it coul= d not utilize any of the cache, and had to query the db each time a file wa= s selected. Considering that Dolphin internally uses Nepomuk to show a lot = of metadata, the data would already be loaded in memory and we wouldn't= have to query for it again and again.

I hate the idea of users having to wait 8 months to get thes= e improvements. Anyway, it's your choice. I do hope you reconsider.
=

Best regards,
Frank

[1] http://techbase.kde.org/Schedules/KDE4/4.10_Release_Schedule#Thurs= day.2C_November_8.2C_2012:_KDE_SC_4.10_Hard_Feature_Freeze



--
Vishesh Handa
--e89a8fb206a8785ade04d14a75a7--