In <20051005193031.GA3771@...>, Thomas Leonard wrote:
> On Wed, Oct 05, 2005 at 06:16:49PM +0100, Tony Houghton wrote:
> > I've uploaded some patches etc to get the ROX desktop working with D-BUS
> > 0.3x. The page detailing them is at
> > <http://www.realh.co.uk/roxdbus.html>.
> Had a quick look at settings.py. A few thoughts:
> Python convention is to use CamelCaps for classes, and
> lowercase_with_underscores for functions (except when copying some external
> non-Python API). I'd prefer to do this for consistency with the rest of
I didn't realise that. Coincidentally I was reading the Python tutorial
today, which recommended distinguishing between data and function
members, with capitalised function names as one possibility. That didn't
become an established convention then?
> Can GetBus(), etc, be made private (start with _)? Perhaps we need a
> rox_dbus.py module? Also, it should be get_xsettings() or something; it
> doesn't return the bus itself.
It might be useful to provide more general access to the dbus settings.
But in that case perhaps the session interface should be available as
well as the settings.
> __init__(self, bus = GetBus(), client = None): probably doesn't do what you
> want. Defaults are evaluated when the function is defined:
I don't think that matters in this case. In fact, I might have
accidentally used the better solution :).
> The theme parameter seems to be ignored. The constructor does:
> self.theme = True
A typo I think. It should be self.theme = theme.
> The orignal commit that added the idle timeout had this log message:
> "Work around GTK bug triggered by Python's garbage collector
> where changing the font would crash LookAndFeel (reported by
> Stephen Watson)."
> So, we probably still need it for older GTKs.
But only for the one setting? I guess therre should be an extra option
parameter to enable the deferred behaviour then, because as I commented
on my web page, the deferment seems to cause an extra phantom click
event on the DPI spin button if the first change causes a redraw.
> Do we need BoolSetting? It seems inconsistent to check for strings and
> ints within Setting, but not to check for bools. However, bools are only
> a separate type in Python2.3 and later. Maybe we should have IntSetting,
I guess we could get away without BoolSetting on 2.3 upwards because it
uses the type of "default", not the current value, to determine which
gconf method to use. But the relevant AppRuns would need changing I
think, to pass True/False instead of 1/0 as a default. And do you want
to keep support for python 2.2? In that case I suppose adding IntSetting
and StringSetting would be more consistent.
I've just remembered another question I thought of, but forgot to ask
earlier. Why are the object paths "/Session" and "/Settings"? It seems
to be convention to use a URL-based prefix eg
"/net/sourceforge/rox/Session". There's a comment saying multi-element
paths aren't supported, but not why.
TH * http://www.realh.co.uk