On Nov 20, 1:56 am, Andrea Gavana <andrea.gav...@gmail.com> wrote:
2009/11/20 Robin Dunn:
> On 11/18/09 2:31 PM, cappy2112 wrote:
>>> What's the use-case for persisting every little thing about a widget instance? I can
>>> only see a use for persisting a few specific things:
>> With a GUI that has many widgets filled with lots of information,
>> saving the exact state of the gui so it can be restored
>> without the user having to perform all of the same actions to get the
>> same info on the screen.
> I'd argue that those kinds of things belong in the application's data
> model and not in the widget persistence data. The things that should go
> there are things like frame size and position, splitter window sash
> position, etc. If you're mixing all that with the values in the widgets
> then you'll certainly run into problems somewhere along the line unless
> it's a very simple app.
It depends on what you are actually saving and restoring. Saving and
restoring a textctrl value or a treectrl expansion state makes sense
to me as a "persistent" attribute. The only 2 reasons why the code in
PersistentControls ended up being longer than I expected are:
1) Lots of documentation;
2) The API inconsistency between widgets that should be very similar
(i.e. wx.TreeCtrl, wx.lib.agw.CustomTreeCtrl, wx.gizmos.TreeListCtrl
and wx.lib.agw.HyperTreelist, not to mention the nightmare of the
various wx.ListCtrl, wx.ListBox, wx.VListBox, wx.HtmlListBox and so
on).
Other than that, I don't think there was much interest in
PersistentControls in the end. I haven't received a single feedback
(not even a bad one, which is not a good sign ).
Andrea.
Don't give up! I'm just not sure how I would use it right now as I
don't really persist anything in my current programs (beyond some user
settings in an INI file).
I thought I saw someone reply to your announcement that they would be
checking it out this week.
Yes, I'd second Mike's point. I was intrigued by PersistentControls
and intend to check it out at some point soon, but wanted to fix some
other problems I have been struggling with first. I'm also unsure whether
or not it would be helpful for what I am hoping to do--it very well might be,
I will just need a chance to play with it and see. I have been trying to
figure out how to have sort of "optional panels", in which each panel
would be a different set of widgets, but the user can sub in or out the
ones s/he'd want, or even create custom panels...and so I thought
maybe PersistentControls could be useful for that. I'll look into it.
But again, the rapidity and frequency with which you bring new value to
wxPython is pretty astonishing, and although few have commented on
it, I'd be surprised if most weren't pleased that it is made available as
an option. I certainly continue to appreciate all these new controls!
Che
···
On Fri, Nov 20, 2009 at 2:56 AM, Andrea Gavana <andrea.gavana@gmail.com> wrote:
2009/11/20 Robin Dunn:
On 11/18/09 2:31 PM, cappy2112 wrote:
What's the use-case for persisting every little thing about a widget instance? I can
only see a use for persisting a few specific things:
With a GUI that has many widgets filled with lots of information,
saving the exact state of the gui so it can be restored
without the user having to perform all of the same actions to get the
same info on the screen.
I'd argue that those kinds of things belong in the application's data
model and not in the widget persistence data. The things that should go
there are things like frame size and position, splitter window sash
position, etc. If you're mixing all that with the values in the widgets
then you'll certainly run into problems somewhere along the line unless
it's a very simple app.
It depends on what you are actually saving and restoring. Saving and
restoring a textctrl value or a treectrl expansion state makes sense
to me as a "persistent" attribute. The only 2 reasons why the code in
PersistentControls ended up being longer than I expected are:
1) Lots of documentation;
2) The API inconsistency between widgets that should be very similar
(i.e. wx.TreeCtrl, wx.lib.agw.CustomTreeCtrl, wx.gizmos.TreeListCtrl
and wx.lib.agw.HyperTreelist, not to mention the nightmare of the
various wx.ListCtrl, wx.ListBox, wx.VListBox, wx.HtmlListBox and so
on).
Other than that, I don't think there was much interest in
PersistentControls in the end. I haven't received a single feedback
(not even a bad one, which is not a good sign ).
I'd argue that those kinds of things belong in the application's data
model and not in the widget persistence data. The things that should go
there are things like frame size and position, splitter window sash
position, etc.
The user's desired default values might not represent the current
state of the model. I know this is a fuzzy thing, but if, for example, I
have some sort of auction bidding app which presents me with a bid
increment, what might actually be represented in the model is the
last price I bid. The bid increment is just a convenience. (Though I
will agree that you could convincingly argue that the bid increment
is a piece of model data. The bid increment for a rare coin might
be different than the bid increment for a rare car.)
Other than that, I don't think there was much interest in
PersistentControls in the end. I haven't received a single feedback
(not even a bad one, which is not a good sign ).
/me silently likes it
"Imagination Is The Only Weapon In The War Against Reality."
/me using my imagination
···
On Fri, Nov 20, 2009 at 2:56 AM, Andrea Gavana <andrea.gavana@gmail.com> wrote:
- Save everything that might be needed (and can be saved).
In that case that means values of published properties.
- Make it work even with non-visual objects (e,g, cell attributes
in grid table models)
It's fast as hell !
PS: I know things are different in wxPy-land
···
On Fri, Nov 20, 2009 at 1:49 PM, Skip Montanaro <skip.montanaro@gmail.com> wrote:
I'd argue that those kinds of things belong in the application's data
model and not in the widget persistence data. The things that should go
there are things like frame size and position, splitter window sash
position, etc.
The user's desired default values might not represent the current
state of the model. I know this is a fuzzy thing, but if, for example, I
have some sort of auction bidding app which presents me with a bid
increment, what might actually be represented in the model is the
last price I bid. The bid increment is just a convenience. (Though I
will agree that you could convincingly argue that the bid increment
is a piece of model data. The bid increment for a rare coin might
be different than the bid increment for a rare car.)
I'd argue that those kinds of things belong in the application's data
model and not in the widget persistence data. The things that should go
there are things like frame size and position, splitter window sash
position, etc.
The user's desired default values might not represent the current
state of the model. I know this is a fuzzy thing, but if, for example, I
have some sort of auction bidding app which presents me with a bid
increment, what might actually be represented in the model is the
last price I bid. The bid increment is just a convenience. (Though I
will agree that you could convincingly argue that the bid increment
is a piece of model data. The bid increment for a rare coin might
be different than the bid increment for a rare car.)
IOW, save the Value of the text box where the user specifies the default increment for automobiles versus coins. Saving/restoring the Value of a textbox can be a widget-level thing, but saving/restoring the bid increment for coins versus autos is very much an application-specific thing.
If the persistence mixin could also be used independently, then app-specific things could be saved to the same database, alongside widget values. Indeed, this is what Dabo does: there's dApp.get|setUserSetting methods, and these very methods are what get called by the widgets when saving/restoring window size, positions, textbox values, etc.
Due to the SWIG interface between Python and wx, the ability to pickle
some of the wx objects becomes problematic.
-------------------
Mike Driscoll
Mike-
I did try this just to see what would happen, and I did get an
exception related to a swig object.
Is this something unique to pickling, or would you expect the same to
occur with marshal & shelve?
When I tried pickling, I passed the upper most Window handle, did not
try picking textboxes or other single widgets.
You might give Andrea's new Perspectives saving script a try. It may
overcome this issue or at least give you some ideas.
···
On Nov 30, 12:37 pm, cappy2112 <cappy2...@gmail.com> wrote:
> Due to the SWIG interface between Python and wx, the ability to pickle
> some of the wx objects becomes problematic.
> -------------------
> Mike Driscoll
Mike-
I did try this just to see what would happen, and I did get an
exception related to a swig object.
Is this something unique to pickling, or would you expect the same to
occur with marshal & shelve?
When I tried pickling, I passed the upper most Window handle, did not
try picking textboxes or other single widgets.
Due to the SWIG interface between Python and wx, the ability to pickle
some of the wx objects becomes problematic.
-------------------
Mike Driscoll
Mike-
I did try this just to see what would happen, and I did get an
exception related to a swig object.
Is this something unique to pickling, or would you expect the same to
occur with marshal &
don't know.
shelve?
Shelve relies on pickle too
···
On Mon, Nov 30, 2009 at 1:37 PM, cappy2112 <cappy2112@gmail.com> wrote:
When I tried pickling, I passed the upper most Window handle, did not
try picking textboxes or other single widgets.
The swig object contains a pointer to the C++ object someplace in memory. Python has no idea what this pointer means nor what is the structure of what it is pointing to, so there is no way for it to serialize a copy of that data to a stream of bytes.
If you have a class derived from a wx class that you really want to be picklable, then what I suggest is to simply separate the UI object from the parts that need to be saved and restored, and pickle that instead. Also look up __reduce__ in the pickle documentation and how implementing it in a class can help out the process.
···
On 11/30/09 10:37 AM, cappy2112 wrote:
Due to the SWIG interface between Python and wx, the ability to pickle
some of the wx objects becomes problematic.
-------------------
Mike Driscoll
Mike-
I did try this just to see what would happen, and I did get an
exception related to a swig object.
Is this something unique to pickling, or would you expect the same to
occur with marshal& shelve?
).
