Re: [pygtk] user-controllable treeview column suppression
"Gustavo J. A. M. Carneiro" <[EMAIL PROTECTED]> writes: > A Qui, 2004-07-22 Ãs 15:09, Doug Quale escreveu: > > "Gustavo J. A. M. Carneiro" <[EMAIL PROTECTED]> writes: > > > > > BonoboUI stores toolbar state in GConf. But the programmer has to > > > specify the GConf key, so it isn't 100% automatic (thankfully). > > > > Isn't the gconf key set up automatically when you call > > gnome.program_init()? I don't know, but it seemed to work that way > > when I played around with it. > > Nope. You need some code like this: > window.get_ui_engine().config_set_path(UICONFIG_KEY) Sorry, I got that wrong again. If you use GnomeApp, I think calling gnome.ui.App(appname, title) is all that's required to setup the gconf key appname, but I've been wrong a couple of times recently, so ... ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
A Qui, 2004-07-22 às 15:09, Doug Quale escreveu: > "Gustavo J. A. M. Carneiro" <[EMAIL PROTECTED]> writes: > > > BonoboUI stores toolbar state in GConf. But the programmer has to > > specify the GConf key, so it isn't 100% automatic (thankfully). > > Isn't the gconf key set up automatically when you call > gnome.program_init()? I don't know, but it seemed to work that way > when I played around with it. Nope. You need some code like this: window.get_ui_engine().config_set_path(UICONFIG_KEY) > > (Some of the GNOME libraries are probably the most underdocumented > part of the entire GNOME system. I think a lot of people are looking > forward to the time when a few of them will go away, maybe starting > with gnome.ui.) gnome.ui will be gone soon. Large parts of it are already deprecated. Most widgets are moving to gtk+. -- Gustavo João Alves Marques Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
"Gustavo J. A. M. Carneiro" <[EMAIL PROTECTED]> writes: > BonoboUI stores toolbar state in GConf. But the programmer has to > specify the GConf key, so it isn't 100% automatic (thankfully). Isn't the gconf key set up automatically when you call gnome.program_init()? I don't know, but it seemed to work that way when I played around with it. (Some of the GNOME libraries are probably the most underdocumented part of the entire GNOME system. I think a lot of people are looking forward to the time when a few of them will go away, maybe starting with gnome.ui.) ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
On Thu, 2004-07-22 at 08:41, Christian Robottom Reis wrote: > On Thu, Jul 22, 2004 at 10:26:26AM +0100, Gustavo J. A. M. Carneiro wrote: > > > I'd shoot for something transparent, that you simply threw a switch in > > > the application and ~user/.appname/state was generated and kept up to > > > date automatically for you. That'd be a killer feature for app-writers. > > > > Let's not get carried away. I bet this problem will eventually get > > solved by the GNOME folks. > > But not everybody wants to use GNOME, and this "eventually" business > isn't really useful to anybody right now. It would be pretty easy to > implement in Python given the wonders of monkey-patching and runtime > introspection. Right. I've purposefully not used Gnome stuff like the druid widget, even though I could really use it, so that if I ever try to make my app run on Win32 I wouldn't have dependencies to prevent that. > > > Of course, if wiki wants to do its own thing in the mean time[1], it > > makes perfect sense. > > Who is Wiki? I feel like Gustavo's mildly intoxicated this chilly July > morning . > > Take care, > -- > Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 > ___ > pygtk mailing list [EMAIL PROTECTED] > http://www.daa.com.au/mailman/listinfo/pygtk > Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/ -- Steve McClure Racemi email: [EMAIL PROTECTED]75 5th St NE voice: 404-892-5850 Suite 214 fax: 404-892-7215 Atlanta, GA 30308 http://www.racemi.com ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
On Thu, Jul 22, 2004 at 10:26:26AM +0100, Gustavo J. A. M. Carneiro wrote: > > I'd shoot for something transparent, that you simply threw a switch in > > the application and ~user/.appname/state was generated and kept up to > > date automatically for you. That'd be a killer feature for app-writers. > > Let's not get carried away. I bet this problem will eventually get > solved by the GNOME folks. But not everybody wants to use GNOME, and this "eventually" business isn't really useful to anybody right now. It would be pretty easy to implement in Python given the wonders of monkey-patching and runtime introspection. > Of course, if wiki wants to do its own thing in the mean time[1], it > makes perfect sense. Who is Wiki? I feel like Gustavo's mildly intoxicated this chilly July morning . Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
A Qui, 2004-07-22 às 01:49, Christian Robottom Reis escreveu: > On Wed, Jul 21, 2004 at 07:18:25PM -0500, Doug Quale wrote: > > > You'd also need to specify a way to discover, store (and restore on > > > startup/widget construction) these preferences per-user and per-widget > > > -- or is that up to the application programmer? > > > > I was imagining a simple system that required the application > > programmer to save the preferences and load them into the appropriate > > widgets by hand. This would be very tedious, but smarter mechanisms > > could be built on top of those low level facilities. Maybe this is > > aiming too low. > > > > A more integrated facility such as what bonobo docks and toolbars > > provide (automatically remembers and restores toolbar configuration at > > application shutdown and startup) would be even better. BonoboUI stores toolbar state in GConf. But the programmer has to specify the GConf key, so it isn't 100% automatic (thankfully). > > I'd shoot for something transparent, that you simply threw a switch in > the application and ~user/.appname/state was generated and kept up to > date automatically for you. That'd be a killer feature for app-writers. Let's not get carried away. I bet this problem will eventually get solved by the GNOME folks. I will probably involve GConf, by making GConf depend on D-Bus instead of Bonobo, then gtk+ would depend on GConf, and we live happily ever after. Of course, if wiki wants to do its own thing in the mean time[1], it makes perfect sense. [1] could take a long time to get this implemented in gtk+, if one remembers about the file selector... -- Gustavo João Alves Marques Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
On 21 Jul 2004 19:18:25 -0500
Doug Quale <[EMAIL PROTECTED]> wrote:
> I was imagining a simple system that required the application
> programmer to save the preferences and load them into the appropriate
> widgets by hand. This would be very tedious, but smarter mechanisms
> could be built on top of those low level facilities. Maybe this is
> aiming too low.
Well, here's some code that aims even lower -- I use the attached class in my
applications as a way to remember where a user has positioned a window and the state
of various widgets (panes, toggles). I haven't yet used it for scrollbars, but it
should be do-able. I ran into some trouble with adjustable column-widths as I couldn't
find a reliable way to get and set them while still allowing the user to reset them (I
believe this has already been commented on). I haven't even thought about touching the
parts of the TreeView that would require knowing something about the TreeModel.
Tom
#!/usr/bin/env python
import gtk, gtk.gdk
class WidgetSaver:
"""A class to save and load widget properties to/from a
dictionary. We leave it to whoever hands us the dictionary to save
the dictionary. dictionary should contain a property name as a key
and a value as a value. On __init__, we will load these properties
into the widget and who the widget. Each signal in signals will be
connected to save_properties"""
def __init__ (self, widget, dictionary={}, signals=['destroy'], show=True):
self.w = widget
self.dictionary = dictionary
self.signals = signals
self.load_properties()
for s in self.signals:
self.w.connect(s,self.save_properties)
if show: self.w.show()
def load_properties (self):
for p,v in self.dictionary.items():
self.w.set_property(p,v)
def save_properties (self, *args):
for p in self.dictionary.keys():
self.dictionary[p]=self.w.get_property(p)
return False # we don't handle any signals
class WindowSaver (WidgetSaver):
def __init__ (self, widget, dictionary={},
signals=['configure-event','delete-event'],
show=True):
"""We save the position and state of the window
in dictionary. The dictionary consists of
{window_size: widget.get_size(),
position: widget.get_position(),}"""
widget.set_gravity(gtk.gdk.GRAVITY_STATIC)
WidgetSaver.__init__(self, widget, dictionary, signals, show)
def load_properties (self):
for p,f in ['window_size', self.w.resize],['position',self.w.move]:
if self.dictionary.has_key(p) and self.dictionary[p]:
apply(f,self.dictionary[p])
def save_properties (self, *args):
self.dictionary['window_size']=self.w.get_size()
self.dictionary['position']=self.w.get_position()
return False
if __name__ == '__main__':
import os.path, pickle
# set up a quick preference saver which will save the
# dictionary quick_prefs.config to the config file
# ~/.testing/widget_positions and load from that file
# on startup
class quick_prefs:
def __init__ (self, file=os.path.expanduser(os.path.join('~/','.testing','widget_positions'))):
self.file=file
self.config={}
self.load()
def get_pref (self, key, default=None):
if not self.config.has_key(key):
self.config[key]=default
return self.config[key]
def save (self):
if not os.path.exists(os.path.split(self.file)[0]):
## if our config directory doesn't exist...
os.makedirs(os.path.split(self.file)[0])
ofi=open(self.file,'w')
pickle.dump(self.config,ofi)
ofi.close()
def load (self):
if os.path.isfile(self.file):
ifi=open(self.file,'r')
self.config=pickle.load(ifi)
return True
else:
return False
prefs = quick_prefs()
# a list of savers we're using...
savers=[]
w = gtk.Window()
wsaver = WindowSaver(w,prefs.get_pref('window',{}))
savers.append(wsaver)
vp=gtk.VPaned()
vps=WidgetSaver(vp,prefs.get_pref('vpane',{'position':vp.get_position()}))
savers.append(vps)
vp.add1(gtk.Label('WidgetSaver can remember where this pane was left'))
w.add(vp)
exp=gtk.Expander('Expander')
exp.add(gtk.Label('WidgetSaver can remember whether this widget is expanded or not.'))
exps=WidgetSaver(exp,
prefs.get_pref('expander',
{'expanded':exp.get_expanded()}),
signals=['activate'])
savers.append(exps)
vb = gtk.VBox()
vb.add(exp)
vp.add2(vb)
tog = gtk.CheckButton("WidgetSaver will remember the state\nof this CheckButton")
togs=WidgetSaver(tog,
prefs.get_pref
Re: [pygtk] user-controllable treeview column suppression
On 21 Jul 2004 19:18:25 -0500
Doug Quale <[EMAIL PROTECTED]> wrote:
> I was imagining a simple system that required the application
> programmer to save the preferences and load them into the appropriate
> widgets by hand. This would be very tedious, but smarter mechanisms
> could be built on top of those low level facilities. Maybe this is
> aiming too low.
Well, here's some code that aims even lower -- I use the attached class in my
applications as a way to remember where a user has positioned a window and the state
of various widgets (panes, toggles). I haven't yet used it for scrollbars, but it
should be do-able. I ran into some trouble with adjustable column-widths as I couldn't
find a reliable way to get and set them while still allowing the user to reset them (I
believe this has already been commented on). I haven't even thought about touching the
parts of the TreeView that would require knowing something about the TreeModel.
Tom
#!/usr/bin/env python
import gtk, gtk.gdk
class WidgetSaver:
"""A class to save and load widget properties to/from a
dictionary. We leave it to whoever hands us the dictionary to save
the dictionary. dictionary should contain a property name as a key
and a value as a value. On __init__, we will load these properties
into the widget and who the widget. Each signal in signals will be
connected to save_properties"""
def __init__ (self, widget, dictionary={}, signals=['destroy'], show=True):
self.w = widget
self.dictionary = dictionary
self.signals = signals
self.load_properties()
for s in self.signals:
self.w.connect(s,self.save_properties)
if show: self.w.show()
def load_properties (self):
for p,v in self.dictionary.items():
self.w.set_property(p,v)
def save_properties (self, *args):
for p in self.dictionary.keys():
self.dictionary[p]=self.w.get_property(p)
return False # we don't handle any signals
class WindowSaver (WidgetSaver):
def __init__ (self, widget, dictionary={},
signals=['configure-event','delete-event'],
show=True):
"""We save the position and state of the window
in dictionary. The dictionary consists of
{window_size: widget.get_size(),
position: widget.get_position(),}"""
widget.set_gravity(gtk.gdk.GRAVITY_STATIC)
WidgetSaver.__init__(self, widget, dictionary, signals, show)
def load_properties (self):
for p,f in ['window_size', self.w.resize],['position',self.w.move]:
if self.dictionary.has_key(p) and self.dictionary[p]:
apply(f,self.dictionary[p])
def save_properties (self, *args):
self.dictionary['window_size']=self.w.get_size()
self.dictionary['position']=self.w.get_position()
return False
if __name__ == '__main__':
import os.path, pickle
# set up a quick preference saver which will save the
# dictionary quick_prefs.config to the config file
# ~/.testing/widget_positions and load from that file
# on startup
class quick_prefs:
def __init__ (self, file=os.path.expanduser(os.path.join('~/','.testing','widget_positions'))):
self.file=file
self.config={}
self.load()
def get_pref (self, key, default=None):
if not self.config.has_key(key):
self.config[key]=default
return self.config[key]
def save (self):
if not os.path.exists(os.path.split(self.file)[0]):
## if our config directory doesn't exist...
os.makedirs(os.path.split(self.file)[0])
ofi=open(self.file,'w')
pickle.dump(self.config,ofi)
ofi.close()
def load (self):
if os.path.isfile(self.file):
ifi=open(self.file,'r')
self.config=pickle.load(ifi)
return True
else:
return False
prefs = quick_prefs()
# a list of savers we're using...
savers=[]
w = gtk.Window()
wsaver = WindowSaver(w,prefs.get_pref('window',{}))
savers.append(wsaver)
vp=gtk.VPaned()
vps=WidgetSaver(vp,prefs.get_pref('vpane',{'position':vp.get_position()}))
savers.append(vps)
vp.add1(gtk.Label('WidgetSaver can remember where this pane was left'))
w.add(vp)
exp=gtk.Expander('Expander')
exp.add(gtk.Label('WidgetSaver can remember whether this widget is expanded or not.'))
exps=WidgetSaver(exp,
prefs.get_pref('expander',
{'expanded':exp.get_expanded()}),
signals=['activate'])
savers.append(exps)
vb = gtk.VBox()
vb.add(exp)
vp.add2(vb)
tog = gtk.CheckButton("WidgetSaver will remember the state\nof this CheckButton")
togs=WidgetSaver(tog,
prefs.get_pref
Re: [pygtk] user-controllable treeview column suppression
On Wed, Jul 21, 2004 at 07:18:25PM -0500, Doug Quale wrote: > > You'd also need to specify a way to discover, store (and restore on > > startup/widget construction) these preferences per-user and per-widget > > -- or is that up to the application programmer? > > I was imagining a simple system that required the application > programmer to save the preferences and load them into the appropriate > widgets by hand. This would be very tedious, but smarter mechanisms > could be built on top of those low level facilities. Maybe this is > aiming too low. > > A more integrated facility such as what bonobo docks and toolbars > provide (automatically remembers and restores toolbar configuration at > application shutdown and startup) would be even better. I'd shoot for something transparent, that you simply threw a switch in the application and ~user/.appname/state was generated and kept up to date automatically for you. That'd be a killer feature for app-writers. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
On Wed, Jul 21, 2004 at 07:12:20PM -0500, Doug Quale wrote: > Actually I'd be happy with a smaller goal: If the default sorts were > guarranteed to be stable (rows with equal values of the sort column > remain in the input order) this would allow you to select sort > columns in reverse order and get the effect of multiple sort columns. > Unfortunately this doesn't work in gtk+. Really?! I'm very surprised -- [good ole] CList definitely implemented a stable sort (and Kiwi does too, when it needs to do type verification). Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
Christian Robottom Reis <[EMAIL PROTECTED]> writes: > On Wed, Jul 21, 2004 at 04:41:23PM -0500, Doug Quale wrote: > > > I think all the API is in-place; what seems to be necessary is a > > > cross-platform (cross-language?) mechanism to persist user preferences. > > > Maybe PyGTK should just go ahead and grow one . > > > > Pygtk provides a great opportunity to experiment with an interface. > > Probably what we want is a function to serialize the treeview state to > > an XML string to be saved and another function to load the saved state > > string and set the treeview properties. Some flags would be required > > to tell what parts of the state are wanted. In many applications > > expanded/collapsed node state could be quite large and not > > interesting. > > You'd also need to specify a way to discover, store (and restore on > startup/widget construction) these preferences per-user and per-widget > -- or is that up to the application programmer? I was imagining a simple system that required the application programmer to save the preferences and load them into the appropriate widgets by hand. This would be very tedious, but smarter mechanisms could be built on top of those low level facilities. Maybe this is aiming too low. A more integrated facility such as what bonobo docks and toolbars provide (automatically remembers and restores toolbar configuration at application shutdown and startup) would be even better. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
Danny Milosavljevic <[EMAIL PROTECTED]> writes: > Am Mit, den 21.07.2004 um 16:41 Uhr -0500 schrieb Doug Quale: > [...] > > Since my column sizing concerns seem to be a non-issue, now I think > > getting the sort info is hard. It might require connecting to column > > Sort Info ? By Code ? > > model.get_sort_column_id() returns: (column_id, sort_order) [for example > gtk.SORT_DESCENDING] Thanks. Obviously I didn't check this very thoroughly before posting. I made two poorly researched posts in a row! > > I don't know if sort order on *multiple* columns is possible. It > certainly would be useful, if implicitly applied (i.e. it sorts by the > sort column, for equal cells it sorts by the column following the sort > column, and so on)... but maybe someone else can shed a light. Multiple sort columns have been suggested before. One problem is that it isn't clear how to indicate the sort columns. The simple arrow is a good indicator for the primary sort column, but what to do with the rest? You also need some way to select multiple sort columns versus replacing the existing sort with a sort on a single column. For sorting on multiple columns I like the idea of using a popup menu. It could also be used to control column visibility. Actually I'd be happy with a smaller goal: If the default sorts were guarranteed to be stable (rows with equal values of the sort column remain in the input order) this would allow you to select sort columns in reverse order and get the effect of multiple sort columns. Unfortunately this doesn't work in gtk+. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
On Wed, Jul 21, 2004 at 04:41:23PM -0500, Doug Quale wrote: > > I think all the API is in-place; what seems to be necessary is a > > cross-platform (cross-language?) mechanism to persist user preferences. > > Maybe PyGTK should just go ahead and grow one . > > Pygtk provides a great opportunity to experiment with an interface. > Probably what we want is a function to serialize the treeview state to > an XML string to be saved and another function to load the saved state > string and set the treeview properties. Some flags would be required > to tell what parts of the state are wanted. In many applications > expanded/collapsed node state could be quite large and not > interesting. You'd also need to specify a way to discover, store (and restore on startup/widget construction) these preferences per-user and per-widget -- or is that up to the application programmer? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
Danny Milosavljevic wrote: Am Mit, den 21.07.2004 um 16:41 Uhr -0500 schrieb Doug Quale: [...] Since my column sizing concerns seem to be a non-issue, now I think getting the sort info is hard. It might require connecting to column Sort Info ? By Code ? model.get_sort_column_id() returns: (column_id, sort_order) [for example gtk.SORT_DESCENDING] I don't know if sort order on *multiple* columns is possible. It certainly would be useful, if implicitly applied (i.e. it sorts by the sort column, for equal cells it sorts by the column following the sort column, and so on)... but maybe someone else can shed a light. I think you'd have to install your own sort function to do this: http://www.pygtk.org/pygtk2reference/class-gtktreesortable.html#method-gtktreesortable--set-sort-func John ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
Am Mit, den 21.07.2004 um 16:41 Uhr -0500 schrieb Doug Quale: [...] > Since my column sizing concerns seem to be a non-issue, now I think > getting the sort info is hard. It might require connecting to column Sort Info ? By Code ? model.get_sort_column_id() returns: (column_id, sort_order) [for example gtk.SORT_DESCENDING] I don't know if sort order on *multiple* columns is possible. It certainly would be useful, if implicitly applied (i.e. it sorts by the sort column, for equal cells it sorts by the column following the sort column, and so on)... but maybe someone else can shed a light. > header 'clicked' signals and tracking the state by hand. Of course I hope I'm wrong > about this too. > > Maybe someone has already worked on this and has some code to share? cheers, Danny signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
Christian Robottom Reis <[EMAIL PROTECTED]> writes: > On Tue, Jul 20, 2004 at 01:47:11PM -0500, Doug Quale wrote: > > Of course this is an issue that really needs better support at the > > gtk+ level. Tree views actually have quite a bit of state that we > > would like to persist: expanded/collapsed node state, visible columns, > > column order, sorting order and column widths. I think this will > > require gtk+ API additions because I don't think there's any way to > > reset column widths to saved values. > > Doesn't Treeview have the equivalent of CList's set_column_width? I'm > seeing here a TreeViewColumn.set_fixed_width() method that seems to do > what would be necessary. And there's set_min_width, which is perhaps > less radical. I think I was wrong about this. The set_min_width() method doesn't really help since the treeview will still grow the column based on model data, but set_fixed_width() will work if you make the treeview column sizing TREE_VIEW_COLUMN_FIXED. The user can still resize the column and you can set the initial column width yourself. > I think all the API is in-place; what seems to be necessary is a > cross-platform (cross-language?) mechanism to persist user preferences. > Maybe PyGTK should just go ahead and grow one . Pygtk provides a great opportunity to experiment with an interface. Probably what we want is a function to serialize the treeview state to an XML string to be saved and another function to load the saved state string and set the treeview properties. Some flags would be required to tell what parts of the state are wanted. In many applications expanded/collapsed node state could be quite large and not interesting. Since my column sizing concerns seem to be a non-issue, now I think getting the sort info is hard. It might require connecting to column header 'clicked' signals and tracking the state by hand. Of course I hope I'm wrong about this too. Maybe someone has already worked on this and has some code to share? ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
On Tue, Jul 20, 2004 at 09:41:27AM -0700, John Finlay wrote: > Skip Montanaro wrote: > > >Is it possible to give users the ability to suppress display of certain > >columns of a treeview? Perhaps I should be using a table widget instead. > >(Treeview widgets seem way too complex for fairly simple use, which I > >suspect is what they are used for 90% of the time.) > > > >Thx, > > > > > > > Should be able to using gtk.TreeViewColumn.set_visible(): > > http://www.pygtk.org/pygtk2reference/class-gtktreeviewcolumn.html#method-gtktreeviewcolumn--set-visible -> FAQ 13.37 http://www.async.com.br/faq/pygtk/index.py?req=show&file=faq13.037.htp Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
On Tue, Jul 20, 2004 at 01:47:11PM -0500, Doug Quale wrote: > Christian Robottom Reis <[EMAIL PROTECTED]> writes: > > > On Tue, Jul 20, 2004 at 01:57:54PM -0400, Steve McClure wrote: > > > Kiwi has a nice way of doing it. Its CList object has a popup menu on > > > the right click where the user can decide which columns to display. > > > > If only we could make those changes transparently persistent. We need > > "user-cookies" for PyGTK apps. :-) > > Of course this is an issue that really needs better support at the > gtk+ level. Tree views actually have quite a bit of state that we > would like to persist: expanded/collapsed node state, visible columns, > column order, sorting order and column widths. I think this will > require gtk+ API additions because I don't think there's any way to > reset column widths to saved values. Doesn't Treeview have the equivalent of CList's set_column_width? I'm seeing here a TreeViewColumn.set_fixed_width() method that seems to do what would be necessary. And there's set_min_width, which is perhaps less radical. I think all the API is in-place; what seems to be necessary is a cross-platform (cross-language?) mechanism to persist user preferences. Maybe PyGTK should just go ahead and grow one . Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
On Tue, 2004-07-20 at 14:47, Doug Quale wrote: > Christian Robottom Reis <[EMAIL PROTECTED]> writes: > > > On Tue, Jul 20, 2004 at 01:57:54PM -0400, Steve McClure wrote: > > > Kiwi has a nice way of doing it. Its CList object has a popup menu on > > > the right click where the user can decide which columns to display. > > > > If only we could make those changes transparently persistent. We need > > "user-cookies" for PyGTK apps. :-) > > Of course this is an issue that really needs better support at the > gtk+ level. Tree views actually have quite a bit of state that we > would like to persist: expanded/collapsed node state, visible columns, > column order, sorting order and column widths. I think this will > require gtk+ API additions because I don't think there's any way to > reset column widths to saved values. Quite true. I use an XML file and callbacks to persist expansion and sorting but it would nice to have something that could do it all without too much overhead on every single application out there. > > I think the gtk+ treeview gurus are aware of this. > ___ > pygtk mailing list [EMAIL PROTECTED] > http://www.daa.com.au/mailman/listinfo/pygtk > Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/ -- Steve McClure <[EMAIL PROTECTED]> ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
Christian Robottom Reis <[EMAIL PROTECTED]> writes: > On Tue, Jul 20, 2004 at 01:57:54PM -0400, Steve McClure wrote: > > Kiwi has a nice way of doing it. Its CList object has a popup menu on > > the right click where the user can decide which columns to display. > > If only we could make those changes transparently persistent. We need > "user-cookies" for PyGTK apps. :-) Of course this is an issue that really needs better support at the gtk+ level. Tree views actually have quite a bit of state that we would like to persist: expanded/collapsed node state, visible columns, column order, sorting order and column widths. I think this will require gtk+ API additions because I don't think there's any way to reset column widths to saved values. I think the gtk+ treeview gurus are aware of this. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
On Tue, Jul 20, 2004 at 01:20:38PM -0500, Skip Montanaro wrote: > > Steve> Kiwi has a nice way of doing it. Its CList object has a popup > Steve> menu on the right click where the user can decide which columns > Steve> to display. > > Thanks for the pointer. I installed it but importing Kiwi failed with an > ImportError (no module named libglade). We import glade here as gtk.glade. > I don't know if that means we're weird or that PyGTK has changed since Kiwi > was last released. It means Kiwi is still for PyGTK 0.6/GTK+ 1.2, a situation bound to change soon. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
Steve> Kiwi has a nice way of doing it. Its CList object has a popup Steve> menu on the right click where the user can decide which columns Steve> to display. Thanks for the pointer. I installed it but importing Kiwi failed with an ImportError (no module named libglade). We import glade here as gtk.glade. I don't know if that means we're weird or that PyGTK has changed since Kiwi was last released. Skip ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
On Tue, Jul 20, 2004 at 01:57:54PM -0400, Steve McClure wrote: > Kiwi has a nice way of doing it. Its CList object has a popup menu on > the right click where the user can decide which columns to display. If only we could make those changes transparently persistent. We need "user-cookies" for PyGTK apps. :-) Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
On Tue, 2004-07-20 at 13:37, Skip Montanaro wrote: > >> Is it possible to give users the ability to suppress display of > >> certain columns of a treeview? > > John> Should be able to using gtk.TreeViewColumn.set_visible(): > > John> > http://www.pygtk.org/pygtk2reference/class-gtktreeviewcolumn.html#method-gtktreeviewcolumn--set-visible > > Thanks. I guess I was really wondering if any sort of point-n-click > functionality is exposed to the user by default. I guess I'll have to > create some sort of preferences dialog so the user can select which columns > to view. > > Skip Kiwi has a nice way of doing it. Its CList object has a popup menu on the right click where the user can decide which columns to display. > > > ___ > pygtk mailing list [EMAIL PROTECTED] > http://www.daa.com.au/mailman/listinfo/pygtk > Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/ -- Steve McClure <[EMAIL PROTECTED]> ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
>> Is it possible to give users the ability to suppress display of >> certain columns of a treeview? John> Should be able to using gtk.TreeViewColumn.set_visible(): John> http://www.pygtk.org/pygtk2reference/class-gtktreeviewcolumn.html#method-gtktreeviewcolumn--set-visible Thanks. I guess I was really wondering if any sort of point-n-click functionality is exposed to the user by default. I guess I'll have to create some sort of preferences dialog so the user can select which columns to view. Skip ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] user-controllable treeview column suppression
Skip Montanaro wrote: Is it possible to give users the ability to suppress display of certain columns of a treeview? Perhaps I should be using a table widget instead. (Treeview widgets seem way too complex for fairly simple use, which I suspect is what they are used for 90% of the time.) Thx, Should be able to using gtk.TreeViewColumn.set_visible(): http://www.pygtk.org/pygtk2reference/class-gtktreeviewcolumn.html#method-gtktreeviewcolumn--set-visible John ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
