Re: [Tracker] [PATCH] fixing a _bad_ bug in tracker-handler.py

["Marcus Fritzsch" <fritschy googlemail com>]

On 8/5/07, jamie <jamiemcc blueyonder co uk> wrote:
> On Sun, 2007-08-05 at 02:53 +0200, Marcus Fritzsch wrote:
> > On 8/5/07, jamie <jamiemcc blueyonder co uk> wrote:
> > > On Thu, 2007-08-02 at 20:49 +0200, Mikkel Kamstrup Erlandsen wrote:
> > > > 2007/8/2, Marcus Fritzsch <fritschy googlemail com>:
> > > >         Hey there...
> > > >
> > > >         There was a pretty bad bug in tracker-handler.py which only
> > > >         pops up if
> > > >         one has so strange usage patterns as I do ;). A related
> > > >         problem was
> > > >         reported[1].
> > > >
> > > >         If traker is running in a different session tracker-handler.py
> > > >         will be
> > > >         happy with its requirements but will actually fail to connect
> > > >         to
> > > >         tracker. The problem is solved by adding one more check to the
> > > >         requirements.
> > > >
> > > >         The downside of this is, that tracker will be started, even if
> > > >         the
> > > >         tracker-handler will not be used.
> > > >
> > > >         Cheers, Marcus
> > > >
> > > >         [1] http://bugzilla.gnome.org/show_bug.cgi?id=403752
> > > >
> > > >         PS: I am looking for 'how' to put apps into the handler, but
> > > >         haven't
> > > >         found it yet.
> > > >
> > > > Where can I review this fix?
> > > >
> > > > I am very skeptic about the idea that trackerd will be started even if
> > > > the handler is deactivated. It will be almost impossible for users to
> > > > tracker down why Tracker always starts up during the session
> > > > initialization.
> > > >
> > > > Cheers,
> > > > Mikkel
> > > >
> > > >
> > > > PS: I wrote the current code to check the availability of tracker, and
> > > > I think that it should fix the bug you refer to - I might be mistaken
> > > > though, I received only little feedback from testers (positive
> > > > though). I think your issue is another bug..?
> > >
> > > whats the status of this?
> > >
> > > can I apply his patch or is there still a problem?
> >
> > No decision yet.
> >
> > Mikkel, I think the added error section can be left out, after all it
> > just prevents a misbehavior that no one other than me has ever seen.
> >
> > I attached a slightly modified version w/o the bogus error check,
> > fixed the regex a bit and removed the (unknown) string. Mikkel, can
> > you check this one please?
> >
> > What about the other legal field codes for the Exec value specified[1]?
> >
> > Kind regards, Marcus
> >
> > [1] http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.0.html#exec-variables
>
>
> it might be worth excluding everything that starts with a "%" - dunno
> how easy that is with python?

Could use a regex substitution, don't know if i is faster than a doing
lot of separate string.replace (which return a whole new string copy).

> Or I guess you could parse the exec til you hit the first % and use
> whatever came before it

Oh, but, wait, with the deskbar handler I am xdg-open $uri - where uri
is returned from tracker. That uri is the .desktop file itself which
is than read by xdg-open --- there should not be those %-fields in the
uri as it is not the Exec field. My bad... So, is the xdg-open $uri he
correct way of doing this? It gets us away from understanding the
.desktop anyway.

Cheers, Marcus