Re: [rox-devel] DeviceHandler problems

[Tony H. <h...@re...>]

In <465...@gm...>, Dennis Tomas wrote:

> Tony Houghton wrote:
> > In <200...@re...>, Tony Houghton wrote:
> >
> >   
> >> In <465...@gm...>, Dennis Tomas wrote:
> >>     
> [snip DevTray announcement]
> >> Thanks. It picked up my soundcard immediately, so that's an improvement
> >> over DeviceHandler. But it still has the problem of becoming
> >> unresponsive when removing a device or when quitting manually. It's
> >> probably something to do with the version of hal I'm currently running
> >> (Debian x86_64 0.5.9-3) or some other dependency perhaps.
> >>     
> >
> > That's a strong possibility, or it's dbus or its python bindings. The
> > problem occurs at line 156 [1] of AppRun in device_removed():
> >
> >     system_bus.remove_signal_receiver(item._property_modified,
> >                                      'PropertyModified',
> >                                      'org.freedesktop.Hal.Device',
> >                                      'org.freedesktop.Hal',
> >                                      udi)
> >
> >   
> Yes, seems like a problem with dbus or hal. Does hal-device-manager also 
> hang when devices are removed?

Yes, it does! I'll report it as a Debian bug. My guess is that the
problem is in python-dbus because hal-device-manager is also written in
python.

For a while I thought it might be a dbus mainloop issue, so I checked
how you initialised it in hal_helper.py. You're supposed to do it a
different way in python-dbus 0.80 or later, so I've attached a patch.
Unfortunately this hasn't fixed the problem I'm having though.

> > That was when udi was for my soundcard. To try to see if other devices
> > were affected I tried disabling it in DevTray, but I got an error:
> >
> >     TypeError: _handler_toggled() takes exactly 2 arguments (3 given)
> >   
> Fixed, thanks.
> 
> > I guess the error dialog isn't finished yet either, because none of the
> > buttons in it do anything, but it can be closed with the window's close
> > icon.
> >   
> The error dialog comes from rox-lib. I don't know why the buttons are 
> unresponsive.

I'll update rox-lib anyway.

> > I fixed the _handler_toggled bug by making it a staticmethod (or you
> > could add a disused self argument). Unfortunately attempting to disable
> > the sound card made it freeze again, presumably because it calls
> > device_removed(). To get around this I made it save disabled_handlers
> > before calling update_devices so it would ignore the soundcard next time
> > I ran it. Anyway, it still froze while the soundcard was disabled.
> >   
> At which point did it freeze then?

I presume at the same place but when removing the printer and/or media
rather than when removing the soundcard.

> > Also two cosmetic problems:
> >
> >     After moving the applet about on the panel it leaves the highlighted
> >     icon zoomed in instead of reducing it again.
> I know. But it's very low on my list, because normally you don't move it 
> a lot.
> 
> >     It has the same problem I reported in TaskTray: zoomed icons appear
> >     to be fuzzily scaled up from their reduced size instead of
> >     re-rendered from the original at the larger size.
> This depends on the icon size. DevTray just passes the chosen size to 
> icon_theme.lookup_icon() and gtk picks the closest icon.

It isn't that simple. As well as the chosen size it uses a range of
larger sizes (I think it's that way round, judging by comparing its
configured size with my panel's configured size). So I suppose it passes
the smallest size to icon_theme.lookup_icon(), uses that as its master
copy and scales it up for zoomed icons. It would look better if it
passed the largest size to icon_theme.lookup_icon() and scaled it down.

You can see the difference in TaskTray, which appears to scale in both
directions for some reason - scaling up the small icon when hovering
over it, but using the larger size natively for focused windows.  I've
attached a couple of PNGs demonstrating this. In the first ROXTerm was
focused and I was hovering over IceWeasel in TaskTray. The ROXTerm icon
is reasonably sharp and the IceWeasel icon is fuzzier. In the second
shot things are the other way round.

Speaking of sizes, could there be an alternative option to read the
panel size and base the zoomed-in size on that and from there calculate
the smaller size? Reading the panel size etc isn't the easiest thing to
do, but it's worth it IMO; if it's any help, tgauge
<http://tgauge.sourceforge.net> provides an example of doing this if you
understand C, and feel free to ask me if there's anything you get a bit
stuck with.

> > Another cosmetic thing: it's a bit hard to work out where to click to
> > get DevTray's global menu instead of a device-specific one. Perhaps it
> > could always open the global menu, but put the current device at the top
> > of it?
> >   
> I don't like this idea, because the main menu is quite big and you don't 
> (or shouldn't) need it very often. Maybe I'm gonna make the menu areas a 
> bit bigger or use separators.

Gnome applets usually have a grab handle which you can menu over. I
think it's a good idea to have something visual like that; it should
help DevTray and TaskTray look better when they're empty too.

-- 
TH * http://www.realh.co.uk