pygtkmvc-users Mailing List for Pygtkmvc (Page 4)
Brought to you by:
cavada
You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
(3) |
Aug
(8) |
Sep
(3) |
Oct
(3) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(6) |
Jun
(4) |
Jul
(9) |
Aug
(2) |
Sep
(11) |
Oct
(6) |
Nov
(2) |
Dec
(16) |
2010 |
Jan
(3) |
Feb
(8) |
Mar
(13) |
Apr
(13) |
May
(6) |
Jun
(2) |
Jul
(5) |
Aug
(3) |
Sep
(6) |
Oct
(7) |
Nov
|
Dec
(4) |
2011 |
Jan
|
Feb
|
Mar
(19) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(3) |
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(10) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Tobias W. <to...@ce...> - 2010-05-07 11:12:30
|
Hi, desktops like Windows, the Mac, and Gnome provide a key/value storage for user settings. Applications can request notification of external modification of their preferences. GTK does not abstract that functionality. I found two independant implementations using gtkmvc on Gnome, so there is demand for support in the framework: http://github.com/bouvard/nostaples/blob/master/utils/state.py http://bazaar.launchpad.net/%7Esmcgrath23/gvoicebox/trunk/annotate/head%3A/gvoicebox/models/prefs.py The most flexible way might be an Adapter class. Using a special Model class like gVoicebox means that either all or no properties of a particular model have to live in GConf. Nostaples works around that by explicitly replacing the setters for some properties. Our SQLObject persistence works similarly, using a metaclass for prettier syntax. Whatever we do, it should be easily replacable with a mock or dumb file implementation to support other environments. I am constantly annoyed by Glade not remembering how I want the sidebar on the Mac... Outside modification (e.g. using gconf-editor) can introduce bogus information. Schemas don't prevent that. gVoicebox ignores the problem, Nostaples checks against an internal list of possible values (not just types). Currently gtkmvc does not support validation. Opinions please :) |
From: Tobias W. <to...@ce...> - 2010-05-05 11:32:49
|
On 15.04.2010, at 01:11, Luke Morton wrote: > http://lukemorton.com.au/test/gtkmvc-project.tar.gz Thanks! Maybe you could put up a repository somewhere? Finally got myself a http://virtualboxes.org/images/ubuntu/ and actually tried it. The background image is great, do you have the source for it? I'd remove the widget subclassing stuff. It's not necessary in gtkmvc and potentially confusing. |
From: Tobias W. <to...@ce...> - 2010-04-27 22:14:17
|
On 10.12.2009, at 16:40, Roberto Cavada wrote: > Thinking about a solution, I would stay away from 1, and would give a try with 2. There is a 3rd way, very common on the Mac: indirect bindings. It requires Adapter(model, "selected.property") to not only observe getattr(model, "selected") but also model itself, to allow re-using the view by simple assignment model.selected = m1 or m2. I implemented this in a branch http://github.com/Wile/gtkmvc/commit/8cbce28d8083843527c509ae703018387993088f See tests/adapter16.py |
From: Roberto C. <ca...@fb...> - 2010-04-27 07:38:55
|
Hi Tobias, Il 04/27/2010 12:14 AM, Tobias Weber ha scritto: > in the last months I proposed a lot of fixes and changes here, to the point where even I was confused. So I put them all on http://github.com/Wile/gtkmvc for Roberto to pick and choose whenever there's time. Everybody else is welcome as well, but I won't guarantee for anything ;) This is *very* kind of you. I really appreciate it. Even better (?) you may use the project tracker at: http://sourceforge.net/apps/trac/pygtkmvc/report Thanks again, r. |
From: Tobias W. <to...@ce...> - 2010-04-26 22:14:34
|
Hi, in the last months I proposed a lot of fixes and changes here, to the point where even I was confused. So I put them all on http://github.com/Wile/gtkmvc for Roberto to pick and choose whenever there's time. Everybody else is welcome as well, but I won't guarantee for anything ;) |
From: Tobias W. <to...@ce...> - 2010-04-21 09:34:18
|
On 21.04.2010, at 11:27, Tobias Weber wrote: > I don't think "isa swiveling" like in Perl or Objective-C is possible here... I meant swizzling, and it is! http://stackoverflow.com/questions/1022499/emulating-membership-test-in-python-delegating-contains-to-contained-object Sorry for posting prematurely. |
From: Tobias W. <to...@ce...> - 2010-04-21 09:28:03
|
On 20.04.2010, at 18:49, Tobias Weber wrote: > There is a similar bug in the wrapper classes, they setattr(self.__class__, meth, getattr(self._obj, meth)) instead of setattr(self). Of course the latter wouldn't work, something I forget time and again because it is one of the ugly parts of Python: http://docs.python.org/reference/datamodel.html#new-style-special-lookup For now I'd put a warning against using list/dict subclasses in the documentation, and someday we could switch to generating one proxy class per type to wrap: http://mail.python.org/pipermail/python-list/2007-May/1123257.html This then begs the question of what to do with instances. I don't think "isa swiveling" like in Perl or Objective-C is possible here... |
From: Tobias W. <to...@ce...> - 2010-04-20 17:38:02
|
On 20.04.2010, at 19:18, Tobias Weber wrote: > assert not m.mutable.__get_models__() That has to be old.__get_models__(), sorry. |
From: Tobias W. <to...@ce...> - 2010-04-20 17:18:57
|
Hi, when an observable property is assigned a new value, any previous mutable value will stay wrapped (I don't mind that) and connected to the model (IMHO a bug). I'd say ObsWrapperBase needs a __remove_model__ to be called by Model.__remove_observer_notification. import gtkmvc class MyModel(gtkmvc.Model): mutable = None __observables__ = ("mutable",) def __init__(self): gtkmvc.Model.__init__(self) self.mutable = [] self.called = False def property_mutable_before_change(self, *args): self.called = True m = MyModel() m.register_observer(m) old = m.mutable m.mutable = [] assert not m.mutable.__get_models__() old.append(1) assert not m.called #both assertions fail |
From: Tobias W. <to...@ce...> - 2010-04-20 16:49:40
|
On 27.09.2009, at 14:35, Tobias Weber wrote: > as Model.__init calls __set_model on each observable signal, the behaviour of class hierarchies depends on the order of instantiation. There is a similar bug in the wrapper classes, they setattr(self.__class__, meth, getattr(self._obj, meth)) instead of setattr(self). import gtkmvc class CustomList(list): def __len__(self): return 9 class MyModel(gtkmvc.Model): standard = None custom = None __observables__ = ("standard", "custom") def __init__(self): gtkmvc.Model.__init__(self) self.standard = [] self.custom = CustomList() m = MyModel() print len(m.standard) #9! |
From: Luke M. <luk...@in...> - 2010-04-14 23:11:28
|
On Wed, 2010-04-14 at 13:40 +0200, Tobias Weber wrote: > > TODO: issues I'm aware of. (I especially need help with anything tagged with a FIXME.) > > gtkmvc.View.__init__ already does set_transient, so you can remove that code. Done. > > NOTES: list of design decisions I made in adapting the ubuntu-project template. > > I agree that gtkmvc should offer something like your add_subview. But it's not very flexible. I like how these guys just unparent() and let the developer pack it somewhere manually: > > http://bitbucket.org/aafshar/pygtkhelpers-main/ Good point. I've replaced the method with get_subview_widget(view). It simply unparent() the top widget from a view and returns it. New version uploaded to http://lukemorton.com.au/test/gtkmvc-project.tar.gz Cheers. |
From: Tobias W. <to...@ce...> - 2010-04-14 11:40:38
|
On 14.04.2010, at 09:17, Luke Morton wrote: > TODO: issues I'm aware of. (I especially need help with anything tagged with a FIXME.) gtkmvc.View.__init__ already does set_transient, so you can remove that code. > NOTES: list of design decisions I made in adapting the ubuntu-project template. I agree that gtkmvc should offer something like your add_subview. But it's not very flexible. I like how these guys just unparent() and let the developer pack it somewhere manually: http://bitbucket.org/aafshar/pygtkhelpers-main/ BTW Qt does not require window instances, you can just display a VBox as a toplevel... |
From: Luke M. <luk...@in...> - 2010-04-14 07:17:41
|
I've got the Quickly templates to a point where they can be used. The template itself is an adaptation of the default ubuntu-project template that comes with Quickly. The following files (in the archive should explain everything: README: how to install the template. TODO: issues I'm aware of. (I especially need help with anything tagged with a FIXME.) NOTES: list of design decisions I made in adapting the ubuntu-project template. Template available at: http://lukemorton.com.au/test/gtkmvc-project.tar.gz Quickly available at: https://launchpad.net/quickly I've been trying to post these all day and keep thinking of things I've missed, so I've decided to bite the bullet and put them up as is. All comments and suggestions for improvement are welcome. Cheers, Luke. |
From: Tobias W. <to...@ce...> - 2010-04-08 13:51:37
|
Hi, most PyGTK software uses Model/View, as do Qt and Cocoa. I'm not sure pygtkmvc always separates all three. Signal handlers have to match between Glade and Controller. In one direction there's a warning, but I often write a method and forget to edit the UI. Maybe register_view could automatically hook up methods by name: def on__toolbutton_quit__clicked: becomes self.view["toolbutton_quit"].connect("clicked") Models that inherit from gtk can be modified in the Controller, which is a very tight coupling. Try, for instance, to add later a filter to your TreeModel when the Controller is full of methods using TreeIter. I usually do: class My(gtkmvc.Model): @property def tree_model(self): return self.__private # the gtk.ListStore A small change to encourage moving code into the model would be: class gtkmvc.Model: def register_view(self, widget): widget.set_model(self) or widget.set_buffer(self) These are just musings, as I'm still new to GUI programming. I probably chose pygtkmvc because it offers so much structure and a manual that explains why. Beginners using PyGTK directly likely end up with spaghetti. |
From: Damir G. <nbd...@gm...> - 2010-04-07 21:38:20
|
Hello! I'm Damir Gilyazov, student from Russia. I would like to participate in Google Summer of Code - program to donate open-source developers and to help they to integrate in OSS community. This is site of project: http://socghop.appspot.com/ I want to develop a book-keeping software with pygtkmvc, and looking for mentor. Does anybody wants be my mentor? My project proposal: http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/nbdarvin/t127067155183 Best regards, Damir |
From: Luke M. <luk...@in...> - 2010-03-25 22:01:00
|
On Thu, 2010-03-25 at 09:31 +0100, Roberto Cavada wrote: > If you want I think you may send them to this mailing list. I am > sure you are going to get good feedback from its users. Will do. > Then if you wish to, we might distribute the template for gtkmvc > along with the framework. However, I am still not sure about what > Quickly is and how it looks like. In order to decide its integration > I'll need to be spending some time looking at its details, and how > you exploited it in your template. To be honest, I'm not sure how Quickly templates are generated or read, but I'm sure all will become clear soon enough. > Unfortunately, time is a rare resource this month, so the process > may be taking more time than your expectations :( Not a problem. I'd rather see gtkmvc reach 2.0.0 than see Quickly templates integrated :) I'll be developing and using the templates one way or the other though. Regards, Luke Morton |
From: Tobias W. <to...@ce...> - 2010-03-25 14:19:04
|
On 24.03.2010, at 23:09, Luke Morton wrote: > How should I distribute them for review? Send a link. Roberto, one point of Quickly is that it comes with the templates. It wouldn't be included with GtkMVC but the other way round. > (They'll probably need a good look over, Unfortunatly so far no work went into making Quickly play nice with anything else than Ubuntu, which I don't know. |
From: Roberto C. <ca...@fb...> - 2010-03-25 08:31:40
|
Il 03/24/2010 11:09 PM, Luke Morton ha scritto: > How should I distribute them for review? If you want I think you may send them to this mailing list. I am sure you are going to get good feedback from its users. Then if you wish to, we might distribute the template for gtkmvc along with the framework. However, I am still not sure about what Quickly is and how it looks like. In order to decide its integration I'll need to be spending some time looking at its details, and how you exploited it in your template. Unfortunately, time is a rare resource this month, so the process may be taking more time than your expectations :( Thanks in advance, r. |
From: Luke M. <luk...@in...> - 2010-03-24 22:09:11
|
On Wed, 2010-03-24 at 15:27 +0100, Roberto Cavada wrote: > Il 03/24/2010 03:13 PM, Tobias Weber ha scritto: > > > https://wiki.ubuntu.com/Quickly > > Interesting. It would be worth creating a template for gtkmvc > r. I'm currently developing a small app using Quickly and gtkmvc (from svn for builder support). If all goes to plan I'll be writing templates for gtkmvc next week. How should I distribute them for review? (They'll probably need a good look over, I'm a Python novice and my coding skills weren't that good to start with.) Luke Morton. |
From: Roberto C. <ca...@fb...> - 2010-03-24 14:28:05
|
Il 03/24/2010 03:13 PM, Tobias Weber ha scritto: > https://wiki.ubuntu.com/Quickly Interesting. It would be worth creating a template for gtkmvc r. |
From: Tobias W. <to...@ce...> - 2010-03-24 14:14:08
|
Hi, just saw a more generic progen. Also creates setup.py ;) https://wiki.ubuntu.com/Quickly |
From: Tobias W. <to...@ce...> - 2010-03-24 12:41:55
|
On 24.03.2010, at 13:11, Roberto Cavada wrote: Sorry for being a bit sloppy with the research this time. > I am sorry about the delay, but I am currently in a rush I hope to exit sooner or later. No worries. |
From: Roberto C. <ca...@fb...> - 2010-03-24 12:11:28
|
Il 03/24/2010 12:15 PM, Tobias Weber ha scritto: > currently Controller.adapt does not require the exact widget name set in Glade. This is true only if you use one string argument (lazy adaptation). The second argument is used to specify the exact name of the widget in all cases in which this is required (explicit adaptation) > But why use prefixes at all? Right because often people use prefixes in widget names as a name convention (I do it, at least). > The docstring mentions that __match_prop_name can be overriden to customize the search, but so far it is never called. For some reason, that function is dead code. The right name is __find_widget_match > The order of iter(View) is not stable, so with similarly named widgets a different one may get adapted each time the program is run! That is not expected to happen, as lazy adaptation works only IFF there is only _one_ match found. If more than one match is found, the use of explicit adaptation is required when adapting. > I propose two new classes, AbstractView and BuilderView, so that libglade is restricted to View. [...] > What do you think? This needs some thinking I cannot afford at the moment. Similarly for the recent posts you made on the mailing list. I am sorry about the delay, but I am currently in a rush I hope to exit sooner or later. r. |
From: Tobias W. <to...@ce...> - 2010-03-24 11:15:57
|
Hi, currently Controller.adapt does not require the exact widget name set in Glade. But why use prefixes at all? The only reason I can see is that signal handlers have a type-specific signature, so it helps to have entry or button somewhere in the name. The docstring mentions that __match_prop_name can be overriden to customize the search, but so far it is never called. The order of iter(View) is not stable, so with similarly named widgets a different one may get adapted each time the program is run! A weird bug somwhere means that there is no way to get the name of a gtk.Adjustment from gtk.Builder: https://bugzilla.gnome.org/show_bug.cgi?id=607492 The fuzzy matching needs that. Here's a workaround: --- trunk/gtkmvco/gtkmvc/view.py 2010-02-21 11:43:25.000000000 +0100 +++ src/gtkmvc/view.py 2010-03-24 03:52:24.000000000 +0100 @@ -171,7 +171,7 @@ if wid is None and self._builder is not None: wid = self._builder.get_object(key) if wid is not None: - self.autoWidgets[wid.get_name()] = wid + self.autoWidgets[key] = wid pass pass pass --- trunk/gtkmvco/gtkmvc/controller.py 2009-12-09 17:10:06.000000000 +0100 +++ src/gtkmvc/controller.py 2010-03-24 12:03:41.000000000 +0100 @@ -184,6 +184,11 @@ possible corresponding widget to adapt with. This is called by adapt. Returns the matching candidate widget name""" + # Short-circuit exact matches. + wid = self.view[prop_name] + if wid: + return prop_name + names = [] for wid_name in self.view: # if widget names ends with given property name: we skip So far gtk.Builder support has not been released nor documented, so we can still change it. The SVN implementation can use it together with libglade *within a single instance*, but I don't think this would or should ever be used. I propose two new classes, AbstractView and BuilderView, so that libglade is restricted to View. This makes for much cleaner code. If desired there could be automating switching based on the presence of the glade/builder attribute using __new__. What do you think? I still lack an overview of the internals of gtkmvc. Metaclasses are hard ;) |
From: Tobias W. <to...@ce...> - 2010-03-24 10:42:33
|
On 21.02.2010, at 13:23, Tobias Weber wrote: > GTK is a huge pain in the ass on the Mac, especially if you want to avoid X11. I managed it, but had to patch PyGtK. Remember that gtkmvc always enables threading as soon as you import it. https://bugzilla.gnome.org/show_bug.cgi?id=613783 Some unicode characters that worked fine with X11 now show up as boxes. It's hard to get a native look. The gtk-quartz-engine doesn't work well for me and most themes I found need engines that are hard to compile. Long story short, I did not yet get to packing for distribution, but can already say that Gtk, especially with Python, is not a good choice for end user applications on the Mac. |