(In reply to comment #0)
> If a new iso is indexed by tracker while the list is displayed, it will not
> automatically appear.

It will but currently limitation is that only if you are not in the wizard's 'source' page. The "rationale" can be found the commit log:

commit: 02538bd 02538bd54c89f7302bb7d762d0cb5eed3e293996
Author: Zeeshan Ali (Khattak) <zeeshanak@gnome.org>
Date:   Fri Feb 10 03:08:15 2012 +0200

    wizard: Present bootable ISO files on 'Source' page
    
    Since for each addition/deletion Tracker, you get an integer ID from
    Tracker against which you use a Sparql query to check what Tracker is
    talking about, the code to handle the these signals will be inefficient
    and unnecessarily complicated. So instead of keeping a list of medias (HW
    and ISO images), we now:
    
    1. Asynchronously fetch list of medias on startup and create the widgets
    for them in the wizard.
    
    2. When the 'Source' page of wizard is activated/shown, we refetch the
    list (again asynchronously) and add/remove widgets accordingly.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=666373

But yes, we need to make this perfect.

I guess this is still relevant, so upgrading version to latest stable.

(In reply to comment #2)
> I guess this is still relevant, so upgrading version to latest stable.

This is not really critical or major bug so I'll not want to fix this in stable cycle.

We've been mostly keep tracking of target versions though 'feature tracker for X' metabugs. I thought I set deps for all the Boxes bugs but I guess i missed some.

(In reply to Zeeshan Ali (Khattak) from comment #1)
>     Since for each addition/deletion Tracker, you get an integer ID from
>     Tracker against which you use a Sparql query to check what Tracker is
>     talking about, the code to handle the these signals will be inefficient
>     and unnecessarily complicated. So instead of keeping a list of medias (HW
>     and ISO images), we now:

Not sure about inefficient, but if you are worried about complexity, here are some examples:
JS: https://git.gnome.org/browse/gnome-documents/tree/src/changeMonitor.js
C: https://git.gnome.org/browse/gnome-photos/tree/src/photos-tracker-change-monitor.c

(In reply to Debarshi Ray from comment #4)
> (In reply to Zeeshan Ali (Khattak) from comment #1)
> >     Since for each addition/deletion Tracker, you get an integer ID from
> >     Tracker against which you use a Sparql query to check what Tracker is
> >     talking about, the code to handle the these signals will be inefficient
> >     and unnecessarily complicated. So instead of keeping a list of medias (HW
> >     and ISO images), we now:
> 
> Not sure about inefficient, but if you are worried about complexity, here
> are some examples:
> JS: https://git.gnome.org/browse/gnome-documents/tree/src/changeMonitor.js
> C:
> https://git.gnome.org/browse/gnome-photos/tree/src/photos-tracker-change-
> monitor.c

Thanks for pointing out examples I can follow but sad that API remains complicated.

(In reply to Zeeshan Ali (Khattak) from comment #5)
> (In reply to Debarshi Ray from comment #4)
> > Not sure about inefficient, but if you are worried about complexity, here
> > are some examples:
> > JS: https://git.gnome.org/browse/gnome-documents/tree/src/changeMonitor.js
> > C:
> > https://git.gnome.org/browse/gnome-photos/tree/src/photos-tracker-change-
> > monitor.c
> 
> Thanks for pointing out examples I can follow but sad that API remains
> complicated.

Not anymore. :)

Since tracker-1.11.0 (bug 773028), there is such a thing called TrackerNotifier that is meant to simplify GraphUpdated handling. See:
https://developer.gnome.org/libtracker-sparql/unstable/TrackerNotifier.html

(In reply to Debarshi Ray from comment #6)
> (In reply to Zeeshan Ali (Khattak) from comment #5)
> > (In reply to Debarshi Ray from comment #4)
> > > Not sure about inefficient, but if you are worried about complexity, here
> > > are some examples:
> > > JS: https://git.gnome.org/browse/gnome-documents/tree/src/changeMonitor.js
> > > C:
> > > https://git.gnome.org/browse/gnome-photos/tree/src/photos-tracker-change-
> > > monitor.c
> > 
> > Thanks for pointing out examples I can follow but sad that API remains
> > complicated.
> 
> Not anymore. :)
> 
> Since tracker-1.11.0 (bug 773028), there is such a thing called
> TrackerNotifier that is meant to simplify GraphUpdated handling. See:
> https://developer.gnome.org/libtracker-sparql/unstable/TrackerNotifier.html

Awesome \o/

That's great, I'm looking forward to land this feature in Boxes.

Currently though we are blocked by https://mail.gnome.org/archives/tracker-list/2017-April/msg00026.html

You can check that the Notifier bits are not present in tracker's vapi.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-boxes/issues/5.