[bug#38538] [PATCH] gnu: Add gnome-shell-extension-hide-app-icon

[Leo Prikler]

Am Donnerstag, den 19.12.2019, 15:38 +0200 schrieb Efraim Flashner:
> On Thu, Dec 19, 2019 at 01:44:47PM +0100, Leo Prikler wrote:
> > Am Donnerstag, den 19.12.2019, 12:00 +0100 schrieb Leo Prikler:
> > > Am Donnerstag, den 19.12.2019, 11:20 +0200 schrieb Efraim
> > > Flashner:
> > > > What does this need glib and glib:bin for? Is it just for
> > > > building
> > > > the
> > > > schemas or does it actually need it at runtime?
> > > To be honest, I'm not quite sure.  I've copied this part from my
> > > dash-
> > > to-dock extension, wherein I copied it from the gnome-shell-
> > > extensions
> > > package.
> > > 
> > > As far as I'm aware both packages do build schemas, but I'm not
> > > sure
> > > how extensions handle them at runtime.  Perhaps this is already
> > > wrong
> > > in the package I originally copied the snippet from.  I'll try to
> > > see
> > > how far I can get with depropagation.
> > > 
> > > Regards,
> > > Leo
> > Upon closer inspection, it appears depropagation is indeed
> > possible. 
> > See the attached patch.
> 
> It makes sense to me that glib:bin should be a native-input but I
> assume
> glib, if it's needed at runtime, would probably need to be propagated
> since the extension doesn't refer to it. Likely it's getting glib
> from
> another package in the environment.
I'm not really sure, what the correct thing would be here.  I did have
very weird behaviour with hide-app-icon, where having glib as input vs.
not having it made the difference of having to reload the extension
after changing settings vs. not having to.  However, I'm really not
sure whether that was due to the extension or a weirdness in GNOME
Shell.

> Also, the depropagation patch should really be a separate patch for
> each
> package if we go that route.
Perhaps.  I just wanted to "prove" that you can at least depropagate
glib:bin and probably glib as well.