pygtkmvc-users Mailing List for Pygtkmvc (Page 2)
Brought to you by:
cavada
Menu
▾
▴
pygtkmvc-users — The public mailing list of python-gtkmvc
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: <to...@ce...> - 2011-03-21 12:56:29
|
On 21.03.2011, at 11:41, Stefan Otte wrote: > When the master_doc in conf.py is set to 'documentation.rst' that file is used for the 'content' link. Would this ease some pain? Yes, but then I see no link back to index.rst anywhere |
|
From: <to...@ce...> - 2011-03-21 12:55:00
|
On 21.03.2011, at 11:20, Stefan Otte wrote: > See http://sphinx.pocoo.org/theming.html . 'agogo' looks good. It requires a rather wide browser window :( I prefer the default theme. Breadcrumbs really help navigation. Also everybody is familiar with it from the Python documentation. > Just try them and change it to your liking. My vote in order of preference: default, nature, haiku, sphinxdoc |
|
From: Roberto C. <ca...@fb...> - 2011-03-21 10:46:09
|
Hi, I fixed a problem with the inclusion path in conf.py To make your setting more robust (and to be able to test more effectively), I'd suggest to remove the installed version of 'gtkmvc' from your system, and use the local trunk instead. Tests and examples all have a module _importer which set the python path to contain the local devel version of gtkmvc. I had to manually remove the sphinx package provided by ubuntu (10.10) and install the latest version 1.0.7 to have the docs compiled. It would better to rely on the version distributed by ubuntu, but it is fine to use a more recent version if special features are needed. As soon as I can find the time to see your work, I will provide some further feedback. Thanks again, r. |
|
From: Stefan O. <ste...@gm...> - 2011-03-21 10:42:06
|
and... When the master_doc in conf.py is set to 'documentation.rst' that file is used for the 'content' link. Would this ease some pain? Best, Stefan On Mon, Mar 21, 2011 at 11:20 AM, Stefan Otte <ste...@gm...> wrote: > On Mon, Mar 21, 2011 at 10:21 AM, <to...@ce...> wrote: >> On 21.03.2011, at 09:05, Stefan Otte wrote: >> >>> I used sphinx 1.x. to generate the docs and I don't know if I used any 1.x features. >> >> I had to update from 0.6.5 for the viewcode extension. >> 1.0.7 is much faster, so I don't mind that you removed the individual makefiles, except that it makes debugging the autodoc for the API harder. >> >>> /home/otte/coding/projects/pygtkmvc_sfclone/trunk/gtkmvco/docs/api/metaclasses.rst:36: >>> (WARNING/2) autodoc can't import/find class >>> 'gtkmvc.support.metaclasses.ObservablePropertyMetaSQL', it reported >>> error: "ObservablePropertyMetaSQL", please check your spelling and >>> sys.path >>> /home/otte/coding/projects/pygtkmvc_sfclone/trunk/gtkmvco/docs/api/model.rst:17: >>> (WARNING/2) autodoc can't import/find class >>> 'gtkmvc.model.SQLObjectModel', it reported error: "SQLObjectModel", >>> please check your spelling and sys.path >> >> That's cause you don't have SQLObject installed. >> >> I got more of those because I don't have gtkmvc installed. The old conf.py prepended ../.. to the path so autodoc imports the *development* tree. It also used get_version instead of hard-coding it. Please restore both. > > * get_version is back again. > * prepending '..' to the path of the conf.py. > >> >> The new theme looks nice, but I miss the per-page TOC in the left margin. > > I really like the theme. It's pretty minimal. The missing TOC just a > tiny annoyance, I my opinion. There are some more themes which are all > nicer than the default theme. > See http://sphinx.pocoo.org/theming.html . 'agogo' looks good. Just > try them and change it to your liking. > >> >> There is one problem with the common root: the contents link at the top no longer jumps to a useful toctree. Not for the book you're in and not for the whole thing (which would be unwieldy). You also don't see *what* book you're in. I'd like a workaround (longer breadcrumbs?) before we merge chapters. >> > > The top link brings you to the index of the documentation. The current > layout uses the index as the index of the homepage. So I guess it's > 'as intended'. > > I'm not sure what you mean with the useful toctree. Do you mean the > toctree for all the 'old' docs? If so, that document wasn't available > online. > If you mean the description of the purpose of the individual docs (5 > min tut, 45 min tut, manual, etc.) > https://sourceforge.net/apps/trac/pygtkmvc/wiki/Documentation > I'll add it to the "Documentation" page. > > The toc behavior you describe is the standard behavior of sphinx. I > think sphinx does not support the concept you called 'book'. I could > add links to at the top/bottom of every page to get to the TOC of the > book. > Would that work be a suitable workaround for you? > The transitions from one book to another would still be transparent though. > >> If index.rst is the new homepage it needs more copying from the wiki. > > I put the rest of the information (and some more) on the getting > started page. I thought the index of the homepage was a bit to > overcrowded thats why I split it. > Do you want me to put all on the index.rst like it is now in the wiki? > >> >> I hope the long list doesn't dampen your spirits ;) > > Better a lot feedback than nothing :) > > >> ------------------------------------------------------------------------------ >> Colocation vs. Managed Hosting >> A question and answer guide to determining the best fit >> for your organization - today and in the future. >> http://p.sf.net/sfu/internap-sfd2d >> _______________________________________________ >> pygtkmvc-users mailing list >> pyg...@li... >> https://lists.sourceforge.net/lists/listinfo/pygtkmvc-users >> > |
|
From: Stefan O. <ste...@gm...> - 2011-03-21 10:21:11
|
On Mon, Mar 21, 2011 at 10:21 AM, <to...@ce...> wrote: > On 21.03.2011, at 09:05, Stefan Otte wrote: > >> I used sphinx 1.x. to generate the docs and I don't know if I used any 1.x features. > > I had to update from 0.6.5 for the viewcode extension. > 1.0.7 is much faster, so I don't mind that you removed the individual makefiles, except that it makes debugging the autodoc for the API harder. > >> /home/otte/coding/projects/pygtkmvc_sfclone/trunk/gtkmvco/docs/api/metaclasses.rst:36: >> (WARNING/2) autodoc can't import/find class >> 'gtkmvc.support.metaclasses.ObservablePropertyMetaSQL', it reported >> error: "ObservablePropertyMetaSQL", please check your spelling and >> sys.path >> /home/otte/coding/projects/pygtkmvc_sfclone/trunk/gtkmvco/docs/api/model.rst:17: >> (WARNING/2) autodoc can't import/find class >> 'gtkmvc.model.SQLObjectModel', it reported error: "SQLObjectModel", >> please check your spelling and sys.path > > That's cause you don't have SQLObject installed. > > I got more of those because I don't have gtkmvc installed. The old conf.py prepended ../.. to the path so autodoc imports the *development* tree. It also used get_version instead of hard-coding it. Please restore both. * get_version is back again. * prepending '..' to the path of the conf.py. > > The new theme looks nice, but I miss the per-page TOC in the left margin. I really like the theme. It's pretty minimal. The missing TOC just a tiny annoyance, I my opinion. There are some more themes which are all nicer than the default theme. See http://sphinx.pocoo.org/theming.html . 'agogo' looks good. Just try them and change it to your liking. > > There is one problem with the common root: the contents link at the top no longer jumps to a useful toctree. Not for the book you're in and not for the whole thing (which would be unwieldy). You also don't see *what* book you're in. I'd like a workaround (longer breadcrumbs?) before we merge chapters. > The top link brings you to the index of the documentation. The current layout uses the index as the index of the homepage. So I guess it's 'as intended'. I'm not sure what you mean with the useful toctree. Do you mean the toctree for all the 'old' docs? If so, that document wasn't available online. If you mean the description of the purpose of the individual docs (5 min tut, 45 min tut, manual, etc.) https://sourceforge.net/apps/trac/pygtkmvc/wiki/Documentation I'll add it to the "Documentation" page. The toc behavior you describe is the standard behavior of sphinx. I think sphinx does not support the concept you called 'book'. I could add links to at the top/bottom of every page to get to the TOC of the book. Would that work be a suitable workaround for you? The transitions from one book to another would still be transparent though. > If index.rst is the new homepage it needs more copying from the wiki. I put the rest of the information (and some more) on the getting started page. I thought the index of the homepage was a bit to overcrowded thats why I split it. Do you want me to put all on the index.rst like it is now in the wiki? > > I hope the long list doesn't dampen your spirits ;) Better a lot feedback than nothing :) > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > pygtkmvc-users mailing list > pyg...@li... > https://lists.sourceforge.net/lists/listinfo/pygtkmvc-users > |
|
From: <to...@ce...> - 2011-03-21 09:21:40
|
On 21.03.2011, at 09:05, Stefan Otte wrote: > I used sphinx 1.x. to generate the docs and I don't know if I used any 1.x features. I had to update from 0.6.5 for the viewcode extension. 1.0.7 is much faster, so I don't mind that you removed the individual makefiles, except that it makes debugging the autodoc for the API harder. > /home/otte/coding/projects/pygtkmvc_sfclone/trunk/gtkmvco/docs/api/metaclasses.rst:36: > (WARNING/2) autodoc can't import/find class > 'gtkmvc.support.metaclasses.ObservablePropertyMetaSQL', it reported > error: "ObservablePropertyMetaSQL", please check your spelling and > sys.path > /home/otte/coding/projects/pygtkmvc_sfclone/trunk/gtkmvco/docs/api/model.rst:17: > (WARNING/2) autodoc can't import/find class > 'gtkmvc.model.SQLObjectModel', it reported error: "SQLObjectModel", > please check your spelling and sys.path That's cause you don't have SQLObject installed. I got more of those because I don't have gtkmvc installed. The old conf.py prepended ../.. to the path so autodoc imports the *development* tree. It also used get_version instead of hard-coding it. Please restore both. The new theme looks nice, but I miss the per-page TOC in the left margin. There is one problem with the common root: the contents link at the top no longer jumps to a useful toctree. Not for the book you're in and not for the whole thing (which would be unwieldy). You also don't see *what* book you're in. I'd like a workaround (longer breadcrumbs?) before we merge chapters. If index.rst is the new homepage it needs more copying from the wiki. I hope the long list doesn't dampen your spirits ;) |
|
From: Roberto C. <rob...@gm...> - 2011-03-19 11:04:31
|
On Sat, 2011-03-19 at 11:38 +0100, Stefan Otte wrote: > >> Stefan would you be available to make the work? > > I'll do it. I already wrote something but the mail bounced because of > the size. I'll send it to you directly. Got it thanks. BTW if you have an account on sourceforge, I will add it to svn, to simplify the work. r. |
|
From: Stefan O. <ste...@gm...> - 2011-03-19 10:38:50
|
On Fri, Mar 18, 2011 at 10:07 PM, Roberto Cavada <rob...@gm...> wrote:
> On Fri, 2011-03-18 at 18:45 +0100, Stefan Otte wrote:
>> What is the official name for pygtkmvc? In the docs there are several variants.
>>
>> * pygtkmvc
>> * gtkmvc
>> * PYGTKMVC
>> * GTKMVC
>
> Mmm this is an issue which I did not correctly handled at the beginning,
> so for historical reason there is some confusion about the name.
>
> Let's limit to the lower cases pygtkmvc and gtkmvc, and for sure
> discharge {PY}GTKMVC.
>
> gtkmvc is the name of the python package. The 'py' prefix was initially
> added to it to make clearer it was a python project. So the official
> name in sourceforge is 'pygtkmvc'. However, later when debian
> maintainers created the deb package, they (correctly) named it
> python-gtkmvc.
>
> So it is a mess... Anyway, we have three names at the moment:
> 1. pygtkmvc: the official name of the project
> 2. gtkmvc: the name of the package
> 3. python-gtkmvc: the name if the debian package
>
> Aside note:
> To be honest, I don't like any of them. For 2.0 I wanted to change the
> name with one which people would keep in their mind. But this is the
> historical name and now it is getting harder and harder to change it.
>
> Back on topic: what about my pending question:
>> Stefan would you be available to make the work?
I'll do it. I already wrote something but the mail bounced because of
the size. I'll send it to you directly.
Stefan
>
> Cheers,
> r.
>
>
|
|
From: Roberto C. <rob...@gm...> - 2011-03-18 21:07:23
|
On Fri, 2011-03-18 at 18:45 +0100, Stefan Otte wrote:
> What is the official name for pygtkmvc? In the docs there are several variants.
>
> * pygtkmvc
> * gtkmvc
> * PYGTKMVC
> * GTKMVC
Mmm this is an issue which I did not correctly handled at the beginning,
so for historical reason there is some confusion about the name.
Let's limit to the lower cases pygtkmvc and gtkmvc, and for sure
discharge {PY}GTKMVC.
gtkmvc is the name of the python package. The 'py' prefix was initially
added to it to make clearer it was a python project. So the official
name in sourceforge is 'pygtkmvc'. However, later when debian
maintainers created the deb package, they (correctly) named it
python-gtkmvc.
So it is a mess... Anyway, we have three names at the moment:
1. pygtkmvc: the official name of the project
2. gtkmvc: the name of the package
3. python-gtkmvc: the name if the debian package
Aside note:
To be honest, I don't like any of them. For 2.0 I wanted to change the
name with one which people would keep in their mind. But this is the
historical name and now it is getting harder and harder to change it.
Back on topic: what about my pending question:
> Stefan would you be available to make the work?
Cheers,
r.
|
|
From: Stefan O. <ste...@gm...> - 2011-03-18 17:45:49
|
What is the official name for pygtkmvc? In the docs there are several variants. * pygtkmvc * gtkmvc * PYGTKMVC * GTKMVC Cheers, Stefan |
|
From: Stefan O. <ste...@gm...> - 2011-03-18 17:38:41
|
Here is the 'five min tutorial' as sphinx page. I'll add a common root for all existing documents next. Alessandro is right. It's pretty easy to interconnect the documentation as soon it's in one sphinx document. Cheers, Stefan On Fri, Mar 18, 2011 at 11:51 AM, Roberto Cavada <ca...@fb...> wrote: > On 03/18/2011 11:22 AM, Alessandro Dentella wrote: > >> My site http://sqlkit.argolinux.org is totally created by sphinx. > > > That's gorgeous! > > Stefan would you be available to make the work? I can support you if > needed. It would allows us to use the former 'official' site again [1] > instead of forcing a redirection to the trac wiki page. > > [1] http://pygtkmvc.sourceforge.net > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > pygtkmvc-users mailing list > pyg...@li... > https://lists.sourceforge.net/lists/listinfo/pygtkmvc-users > |
|
From: Roberto C. <ca...@fb...> - 2011-03-18 10:51:25
|
On 03/18/2011 11:22 AM, Alessandro Dentella wrote: > My site http://sqlkit.argolinux.org is totally created by sphinx. That's gorgeous! Stefan would you be available to make the work? I can support you if needed. It would allows us to use the former 'official' site again [1] instead of forcing a redirection to the trac wiki page. [1] http://pygtkmvc.sourceforge.net |
|
From: Alessandro D. <sa...@e-...> - 2011-03-18 10:38:46
|
On Thu, Mar 17, 2011 at 11:20:11PM +0100, Roberto Cavada wrote: > Hi, > > On Thu, 2011-03-17 at 18:59 +0100, Stefan Otte wrote: > > Thanks for offering your contribution, it is very appreciated. > > I personally don't see any problem with your idea. > > I take the opportunity to ask for a further improvement. I would like to > improve also: > 1. The web site (couldn't it be sphinx based as well?) yes, definitely. > 2. Cross linking of docs (5-minutes guide, 45 minutes guide, tutorial > and user manual) with the reference (API) manual. that's trivial as soon as you have all sphinx based > I think 1 would be very easy to obtain, as the homepage contains very > few pages. > > About 2, having a common root would simplify things a lot, but I don't > know if cross linking would work also for off-line reading. no it works off-line also. Sphinx creates relative links. My site http://sqlkit.argolinux.org is totally created by sphinx. I added some customization to achieve that and used mako templates but you can use the default ones. sandro *:-) -- Sandro Dentella *:-) http://www.reteisi.org Soluzioni libere per le scuole http://sqlkit.argolinux.org SQLkit home page - PyGTK/python/sqlalchemy |
|
From: Roberto C. <rob...@gm...> - 2011-03-17 22:20:25
|
Hi, On Thu, 2011-03-17 at 18:59 +0100, Stefan Otte wrote: Thanks for offering your contribution, it is very appreciated. I personally don't see any problem with your idea. I take the opportunity to ask for a further improvement. I would like to improve also: 1. The web site (couldn't it be sphinx based as well?) 2. Cross linking of docs (5-minutes guide, 45 minutes guide, tutorial and user manual) with the reference (API) manual. I think 1 would be very easy to obtain, as the homepage contains very few pages. About 2, having a common root would simplify things a lot, but I don't know if cross linking would work also for off-line reading. Cheers, r. |
|
From: Stefan O. <ste...@gm...> - 2011-03-17 17:59:42
|
Hey, I have a suggestion to improve pymvc. I think the documentation should be in one place (not spread in the trac wiki and sphinx). As a big sphinx fan I could port the '5 min tutorial' to sphinx and add a common index.rst so that the documentation is accessible from one sphinx main page (instead of different sphinx projects for each part of the documentation as it is now). This would ease the use and look much nicer. Does anyone like trac-wikis? :) So let me know if you are interested. Cheers, Stefan |
|
From: Stefan O. <ste...@gm...> - 2011-03-11 09:55:03
|
Hi, thanks for the quick answer. Using glade instead of gtkbuilder worked. In the 'quickstart' builder is used. Perhaps it should be changed or the bug should be mentioned there. http://pygtkmvc.sourceforge.net/docs/quickstart/index.html#views btw: I use rev 319. Cheers, Stefan On Fri, Mar 11, 2011 at 10:22 AM, Roberto Cavada <ca...@fb...> wrote: > On 03/10/2011 07:37 PM, to...@ce... wrote: > >> On 10.03.2011, at 19:17, Stefan Otte wrote: >>> >>> What is the best practice for developing GUIs with pygtkmvc: >>> * develop the entire GUI in one main window and then assign every view >>> a part GUI? >>> * put all guis in one *.glade in separate Windows and connect the >>> parts in the python code? >>> * one *.glade for every view and put all parts together in the python >>> code? >> >> Personally I'd say the second is the worst option, and you should adopt >> the third. > > I personally use always the third. My latest preferences actually go to: > > 1. Separate glade 'builder' files per each view > 2. Subview instantiated and connected in parent views > 3. menu and toolbars not designed in glade, but constructed in ui manager > 3.1 The top-level view has the space to accomodate the "tools" subview (menu > and toolbars) > 3.2 There is a glade (builder) file associated to one or more views to > represent menu ad toolbars. The glade file contains actions, action groups > and one uimanager object. > 3.3 The view(s) for the menu and toolbars sets up the action groups, the > actions, the accelerators, and using the uimanager instance create menus and > toolbars out of xml files. The view has also the methods for dynamically > change menu and toolbars throught visibility and sensitivity of actions and > action groups. > > Cheers, > r. > |
|
From: Roberto C. <ca...@fb...> - 2011-03-11 09:22:46
|
On 03/10/2011 07:37 PM, to...@ce... wrote: > On 10.03.2011, at 19:17, Stefan Otte wrote: >> What is the best practice for developing GUIs with pygtkmvc: >> * develop the entire GUI in one main window and then assign every view >> a part GUI? >> * put all guis in one *.glade in separate Windows and connect the >> parts in the python code? >> * one *.glade for every view and put all parts together in the python code? > > Personally I'd say the second is the worst option, and you should adopt the third. I personally use always the third. My latest preferences actually go to: 1. Separate glade 'builder' files per each view 2. Subview instantiated and connected in parent views 3. menu and toolbars not designed in glade, but constructed in ui manager 3.1 The top-level view has the space to accomodate the "tools" subview (menu and toolbars) 3.2 There is a glade (builder) file associated to one or more views to represent menu ad toolbars. The glade file contains actions, action groups and one uimanager object. 3.3 The view(s) for the menu and toolbars sets up the action groups, the actions, the accelerators, and using the uimanager instance create menus and toolbars out of xml files. The view has also the methods for dynamically change menu and toolbars throught visibility and sensitivity of actions and action groups. Cheers, r. |
|
From: <to...@ce...> - 2011-03-10 19:00:19
|
On 10.03.2011, at 19:17, Stefan Otte wrote:
> I don't know what I'm doing wrong.
If you save your interface in libglade format it should work as expected.
With the transition to GtkBuilder the way to load only parts of the XML has changed, so we don't currently support that.
If you only need one instance of each class here is a workaround:
xml = gtk.Builder()
xml.add_from_file("application.glade")
m = MainView(builder=xml)
s = SubView(builder=xml)
> What is the best practice for developing GUIs with pygtkmvc:
> * develop the entire GUI in one main window and then assign every view
> a part GUI?
> * put all guis in one *.glade in separate Windows and connect the
> parts in the python code?
> * one *.glade for every view and put all parts together in the python code?
Personally I'd say the second is the worst option, and you should adopt the third.
--
Tobias Weber
|
|
From: Stefan O. <ste...@gm...> - 2011-03-10 18:17:58
|
Hey,
I'm playing with pygtkmvc and really like it so far. I just have a
problem creating subviews from one gtkbuilder file.
I have a MainView and (for brevity) a SubView. The gtkbuilder file
contains all views (each in a separate window). When the MainView
instanciates the SubView I end up with two windows of the MainView
which I don't want. I already looked at the 'converter' example which
does something similar. I don't know what I'm doing wrong.
If I only work with the MainView I can't select the subviewpart from
the gtkbuilder file.
The code looks something like this.
class MainView(View):
builder = os.path.join(utils.globals.GLADE_DIR, "application.glade")
top = "main_window"
def __init__(self):
View.__init__(self)
self.subView = SubView(self)
...
class SubView(View):
builder = os.path.join(utils.globals.GLADE_DIR, "application.glade")
top = "camera_frame"
def __init__(self, parent=None):
self.parent = parent
View.__init__(self)
What is the best practice for developing GUIs with pygtkmvc:
* develop the entire GUI in one main window and then assign every view
a part GUI?
* put all guis in one *.glade in separate Windows and connect the
parts in the python code?
* one *.glade for every view and put all parts together in the python code?
Thanks in advance!
Cheers,
Stefan
|
|
From: Roberto C. <rob...@gm...> - 2010-12-30 13:46:07
|
We are proud to announce that version 1.99.1 of pygtkmvc has been released. Project homepage: <http://apps.sourceforge.net/trac/pygtkmvc/wiki> Download: <http://sourceforge.net/projects/pygtkmvc/> ============== About pygtkmvc ============== pygtkmvc is a fully Python-based implementation of the Model-View-Controller (MVC) and Observer patterns for the PyGTK2 toolkit. MVC is a pattern that can be successfully used to design and develop well structured GUI applications. The MVC pattern basically helps in separating semantics and data of the application, from their representation. The Observer pattern helps to weaken dependencies among parts that should be separated, but need to be connected each other. pygtkmvc provides a powerful and still simple infrastructure to help designing and implement GUI applications based on the MVC and Observer patterns. The framework has been designed to be: * Essential and small, it does only what it was designed for. * Not an external dependency for your application: it fits in 200KB and can be released along with it. * Easy to understand and to use; fully documented. * Portable: straightly runs under many platforms. License: LGPL ********************************************************************** * Dec 30 2010 * ********************************************************************** Released version 1.99.1 This is a release that keeps compatibility with previous version 1.99.0. However, some features provided in 1.99.0 are deprecated in 1.99.1. This version goes in the direction of stabilizing the API and making the code more robust. Many bugs were fixed, and a new, clean API is now provided for defining notification methods in observers, and logical observable properties in models. The documentation has been updated and extended to reflect all changes, and a complete Library Reference is now available. Furthermore, the documentation now uses Sphinx instead of Latex to generate both pdf and html documentation formats. Last but not the least, the team grew up! * New - Models now feature Logical Observable Properties, along with already supported Concrete Observable Properties. - In Observers notification methods have all the same prototype, which make much cleaner the application code. - New mechanism to declare both dynamically and statically notification methods in Observers. - Auto-adapt of FileChooserButton, ComboBox and Adjustment - API to extend default adapter list - More widget types now correctly cast when adapted to unicode/int/float properties. - Enable RoUserClassAdapter to update the widget. It used to only do it when connecting, not on property changes. This makes the built-in support for gtk.Calendar work in both directions. - Controller's method adapt() allows auto-adaption even if the view does not have corresponding widgets for *all* properties in the model. - Adapters can optionally call prop_write *instead of* casting the value from the widget to the type of the old property value. This was the intended behaviour all along. Default is still to call it after the cast. - Decorators for property setters/getters in models. The methods can now have arbitrary names and you are no longer limited to one property per method. * Changed - Name-based notification methods like `property_<name>_value_change` are still supported, but their usage is now discouraged. A new mechanism for declaring notifications is now available, and you should consider porting applications accordingly. - Decorator Observer.observes is now deprecated. A new mechanism for declaring notifications is now available, and you should consider porting applications accordingly. - Support GtkBuilder in addition to libglade, which is no longer required. This changed the signature of the View constructor. The two formats are not equivalent, as GTK cannot build only parts of a file. - Allow creation of adapters that act on spurious notifications. - Use less eval(codestring) This changed how adapters create observer functions. If you have adapter subclasses you will have to adjust them. - Misuse of the framework that used to exit your application can now be caught as exceptions. - Fewer warnings printed by the framework. Remember to increase the logging level during development. * Fixed - Assigning a tuple with length 3 to a property no longer raises - Pass the correct model when emitting notifications for an inherited signal. This changes how all property wrappers track their owners, but your code should not be affected. - Wrapped sequences lacked crucial special methods like len and iter. - Inspecting wrappers no longer omits the class name. - Various changes to make SQLObjectModel actually usable. - Wrapping more than one sequence class could cause the wrong methods to be called on all but the last instance created. This did not affect programs that only use the built-in list type. - Mutable instances that used to be assigned to properties would notify of their changes even after being replaced in the model. - No more errors from static container adapters you didn't create. - Multiple concurrent iterators on views no longer steal each other widgets. Many thanks to Christian Spoer for narrowing down a bug and to Tobias Weber for joining the team. -- Roberto Cavada <P><A HREF="http://pygtkmvc.sourceforge.net">pygtkmvc 1.99.1</A> - Pygtk MVC is a thin, multiplatform framework that helps to design and develop GUI applications based on the PyGTK toolkit. (30-Dec-10) |
|
From: Roberto C. <rob...@gm...> - 2010-12-11 11:52:43
|
Hi, On Thu, 2010-12-09 at 16:57 +1100, Mirsad Makalic wrote: > What would be the best way to support dynamic properties in my model? In the current version we are working hard to get a stable API for declaring static behaviour. After release 1.99.1, we will be working on adding dynamical behaviours. In trunk there is already a first tentative for dynamic observations, but there is no support for dynamic properties. For the moment, a hack may be to make the controller relieve the model after you added the properties, and then re-observe it. See Observer.relieve_model and Observer.observe_model. However, the trick does not work with adapters, which if needed will have to be added explicitly for the properties you added dynamically. Let us know if the trick works. r. |
|
From: Tobias W. <to...@ce...> - 2010-12-09 11:40:11
|
On 09.12.2010, at 12:06, Mirsad Makalic wrote: > yes we are using version 1.99.0 > >> You want to add properties after creating the controller? >> May I ask what you're trying to achieve in the end? > > The reason I am adding them after creating the controller is that I'm trying to parse large sets of data that is received on a socket over time. I don't want to create each model statically because it would take a while to do. A while to write the code or to run it? You could take a sample of the data and create all the needed model classes in code before instantiating any. > So what I'd like to do is create the model dynamically as data is presented to be. How about using container properties, like a dictionary? > The view will of course only look at certain properties that it expects to be in the model. Those could be stored separatly from the container. Or you could use StaticContainerAdapter: python-gtkmvc-1.99.0/examples/adapters/container3.py |
|
From: Mirsad M. <mi...@gm...> - 2010-12-09 05:57:16
|
Hi,
I have an empty model to which I am dynamically adding properties after it
has been created with an associated view and controller. The code for that
looks something like:
class DynamicProperty(object):
def add_property(self, name, value):
# Ensure property is new
if self.property_exists(name):
raise RuntimeError('Property already exists')
# Create getter/setter functions
fget = lambda self: self.get_property(name)
fset = lambda self, value: self.set_property(name, value)
setattr(self.__class__, name, property(fget, fset))
setattr(self, '_' + name, value)
def set_property(self, name, value):
setattr(self, '_' + name, value)
def get_property(self, name):
return getattr(self, '_' + name)
then my model:
class DeviceModel(DynamicProperty, gtkmvc.Model):
__observables__ = []
def add_property(self, name, value):
# Add dynamic property
DynamicProperty.add_property(self, name, value)
# We'll make this property observable
self.__observables__.append(name)
In my controller I am not getting any calls when the model changes. After
scouring through the framework sourcecode I noticed that most of the
property monitoring is achieved on creation of the model class. What would
be the best way to support dynamic properties in my model?
|
|
From: Tobias W. <to...@ce...> - 2010-10-11 15:54:37
|
On 11.10.2010, at 11:35, Roberto Cavada wrote: > 1. Renaming custom value properties to "logical properties" (LP) > 2. Making LP getter/setter pair explicit, using decorators instead of > implicit naming convention > 3. Support for dependencies among LP So applications written against the current SVN will still work? If not see my last line in: https://sourceforge.net/apps/trac/pygtkmvc/ticket/7 |
|
From: Roberto C. <rob...@gm...> - 2010-10-11 14:22:14
|
On Sun, 2010-10-10 at 20:02 +0200, Tobias Weber wrote: > Should we use? > https://sourceforge.net/apps/trac/pygtkmvc/ticket/3 Of course! Thanks for reminding me of it. I added my thoughts to the ticket, let's continue the discussion there. r. |
2 messages has been excluded from this view by a project administrator.
