I've written a few simple wx & pythoncard-based Gui's.
I am now starting on a program with a wx-based GUI, will be quite
more complex than the others.
Complex- in the sense it will probably have 6-10 tabs, each with many
(30+ ??) widgets or so.
The users of this GUI have expressed the ability to save the state of
the GUI once all of the information has been loaded into the widgets
(mostly text boxes).
Initially I had thought of pickling the entire Window to disk, passing
the outermost Frame as the object to pass to the pickle function, then
doing the reverse when un-pickling. This seems like a better way than
iterating over all of the widgets, and manually saving their contents.
I don't know if this will work with a GUI and I'm curious how others
would go about this.
It's quite possible wx already has an API do do this. Is this the
case?
I've written a few simple wx & pythoncard-based Gui's.
I am now starting on a program with a wx-based GUI, will be quite
more complex than the others.
Complex- in the sense it will probably have 6-10 tabs, each with many
(30+ ??) widgets or so.
The users of this GUI have expressed the ability to save the state of
the GUI once all of the information has been loaded into the widgets
(mostly text boxes).
Initially I had thought of pickling the entire Window to disk, passing
the outermost Frame as the object to pass to the pickle function, then
doing the reverse when un-pickling. This seems like a better way than
iterating over all of the widgets, and manually saving their contents.
I don't know if this will work with a GUI and I'm curious how others
would go about this.
It's quite possible wx already has an API do do this. Is this the
case?
Thanks
Due to the SWIG interface between Python and wx, the ability to pickle
some of the wx objects becomes problematic. If they're just filling
out a form, I'd save the data to a database and open the last record
when the program is opened. Python 2.5+ includes SQLite.
There's a new AUI in the agw set that allows you to save
"perspectives", which I think means you can save the sizes of the
notebooks and panes. I'm not sure if that includes the data too
though.
···
On Nov 9, 12:48 pm, cappy2112 <cappy2...@gmail.com> wrote:
I've written a few simple wx & pythoncard-based Gui's.
I am now starting on a program with a wx-based GUI, will be quite
more complex than the others.
Complex- in the sense it will probably have 6-10 tabs, each with many
(30+ ??) widgets or so.
The users of this GUI have expressed the ability to save the state of
the GUI once all of the information has been loaded into the widgets
(mostly text boxes).
Initially I had thought of pickling the entire Window to disk, passing
the outermost Frame as the object to pass to the pickle function, then
doing the reverse when un-pickling. This seems like a better way than
iterating over all of the widgets, and manually saving their contents.
I don't know if this will work with a GUI and I'm curious how others
would go about this.
It's quite possible wx already has an API do do this. Is this the
case?
Due to the SWIG interface between Python and wx, the ability to pickle
some of the wx objects becomes problematic. If they're just filling
out a form, I'd save the data to a database and open the last record
when the program is opened. Python 2.5+ includes SQLite.
There's a new AUI in the agw set that allows you to save
"perspectives", which I think means you can save the sizes of the
notebooks and panes. I'm not sure if that includes the data too
though.
This definitely calls for a database. You are wanting to save and restore data, so use a database. Use SQLite as Mike mentioned.
Consider using Dabo, which comes with some out-of-the-box solutions, one of which is the relatively heavy db/biz/ui interaction where you define a connection, define a bizobj with your business rules, and then define your ui to get/set the data from/to the bizobj. You do this using the DataSource and DataField properties of the UI controls. Once set up, Dabo does the rest.
The other Dabo alternative, if this really isn't a database app but you still want the form to come up pre-populated with the last values, is to let Dabo save the values for you to the daboPreferences.db file (a sqlite database persisted to the user's %appdata% directory). Just set SaveRestoreValue to True for the controls you want to persist like this, and when you open the form all those values will be prepopulated, and when you close the form the current values will be persisted. No other code needed, although you can explicitly call saveValue() whenever you want.
Paul
···
On Nov 9, 12:48 pm, cappy2112 <cappy2...@gmail.com> wrote:
I've written a few simple wx & pythoncard-based Gui's.
I am now starting on a program with a wx-based GUI, will be quite
more complex than the others.
Complex- in the sense it will probably have 6-10 tabs, each with many
(30+ ??) widgets or so.
The users of this GUI have expressed the ability to save the state of
the GUI once all of the information has been loaded into the widgets
(mostly text boxes).
For these kind of "complex" visual designs,
I created GUI_support, which not only saves and stores but also gives
you a quit easy way of designing the GUI http://mientki.ruhosting.nl/data_www/pylab_works/pw_gui_support.html
I've you're interested, I can load up the latest version.
cheers,
Stef
···
Initially I had thought of pickling the entire Window to disk, passing
the outermost Frame as the object to pass to the pickle function, then
doing the reverse when un-pickling. This seems like a better way than
iterating over all of the widgets, and manually saving their contents.
I don't know if this will work with a GUI and I'm curious how others
would go about this.
It's quite possible wx already has an API do do this. Is this the
case?
I've written a few simple wx & pythoncard-based Gui's.
I am now starting on a program with a wx-based GUI, will be quite
more complex than the others.
Complex- in the sense it will probably have 6-10 tabs, each with many
(30+ ??) widgets or so.
The users of this GUI have expressed the ability to save the state of
the GUI once all of the information has been loaded into the widgets
(mostly text boxes).
Initially I had thought of pickling the entire Window to disk, passing
the outermost Frame as the object to pass to the pickle function, then
doing the reverse when un-pickling. This seems like a better way than
iterating over all of the widgets, and manually saving their contents.
I don't know if this will work with a GUI and I'm curious how others
would go about this.
It's quite possible wx already has an API do do this. Is this the
case?
Other than the solutions Stef and Paul proposed (I like the Dabo one,
although I am no fan of Dabo in general), it would be nice to have
some kind of mixin (let's call it PersistentControlsMixin) that allows
you to save and restore GUI components values/sizes/whatever else.
Pretty much like the wxWidgets' one on which Vadim Zeitlin was working
on, although I believe it has not been finished (and possibly it has
been discontinued).
One day or the other I may end up writing something like this to have
a wxPython-pluggable mixin ready to use and independent from 3rd party
libraries (no offence anyone).
Do you have any other alternatives to using a db?
I've got tons of work to do with the gui, and I'd say I'm a bit passed
the beginners stage with wx, but not at intermed level.
I've also got to parse three different files of symbolic data from a C
compiler, and get that into a viewable form in the gui.
I know 0 about db technology, and the thought of having to learn it at
this point just doesn't seem like the best approach as far as time is
concerned.
Learning how to insert and update SQLite is very easy. Just look at the docs:
Of course, if all you care about is the current data being worked on,
then you could just iterate over the widgets and create a list that
you could pickle or you could save it all to some kind of file. I've
been using ConfigParser and ConfigObj to store user preferences, but
you could use them to store the data too. I think ConfigObj is the
more flexible of the two.
Here's a couple of links:
www.voidspace.org.uk/python/configobj.html
···
On Mon, Nov 9, 2009 at 2:23 PM, cappy2112 <cappy2112@gmail.com> wrote:
When you're ready to do this let me know. I wrote a little settings saving framework in one of the projects I've worked on, which also allows different targets for where the settings are actually stored. It may be able to be extracted from the project it is in now and could serve as a starting point for you.
···
On 11/9/09 1:09 PM, Andrea Gavana wrote:
One day or the other I may end up writing something like this to have
a wxPython-pluggable mixin ready to use and independent from 3rd party
libraries (no offence anyone).
One day or the other I may end up writing something like this to have
a wxPython-pluggable mixin ready to use and independent from 3rd party
libraries (no offence anyone).
When you're ready to do this let me know. I wrote a little settings
saving framework in one of the projects I've worked on, which also
allows different targets for where the settings are actually stored. It
may be able to be extracted from the project it is in now and could
serve as a starting point for you.
I am already half-way or more with this thing: I took a couple of
hours today to do it and it is surprisingly simple with Python. In any
case, I had thought about different targets myself too and this
feature is already incorporated in the project. I am currently
creating saving/restoring features for
treectrls/CustomTreeCtrl/HyperTreeList/etc (I am going in alphabetic
order and I already reached the "T" letter ).
It should be ready in few days, then we might see if I interpreted
correctly your sentence about "different targets".
I wrote a widget saver for PyGTK a couple years ago. It was quite easy
given the ability to connect to the various signals GTK widgets emit. You
just save the state of the widgets and when the program exits you pickle the
result. Next time you start your app the pickled data are used to
(re)initialize the widgets.
I don't know wx well enough to know if such a scheme will work there or not.
The PyGTK version is less than 250 lines of code. If it would be of
interest I'll check at work to see if I can release it.
I wrote a widget saver for PyGTK a couple years ago. It was quite easy
given the ability to connect to the various signals GTK widgets emit. You
just save the state of the widgets and when the program exits you pickle the
result. Next time you start your app the pickled data are used to
(re)initialize the widgets.
I don't know wx well enough to know if such a scheme will work there or not.
The PyGTK version is less than 250 lines of code. If it would be of
interest I'll check at work to see if I can release it.
It would be interesting to see the approach you used: I am pretty much
finished wrapping all the possible widgets in wxPython and I got close
to 2,000 lines of code :-D. I simply followed the wxWidgets
implementation (which currently supports 4 widgets only) by having a
central and unique PersistenceManager and delegate all the
saving/restoring to appropriate classes depending on the widget type.
In any case, I believe that having 2 implementations of the same
feature will only be beneficial to wxPython
It would be interesting to see the approach you used: I am pretty much
finished wrapping all the possible widgets in wxPython and I got close
to 2,000 lines of code :-D. I simply followed the wxWidgets
implementation (which currently supports 4 widgets only) by having a
central and unique PersistenceManager and delegate all the
saving/restoring to appropriate classes depending on the widget type.
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:
1) The value of a widget, like the text in a TextCtrl or the selection index in a list.
2) The window state (maximized, minimized, etc.), the window size, and the window position, but only for top-level windows.
3) Other control-specific things such as the current sash position and the column order in a grid.
In other words, you persist things that the *user* changed.
It would be interesting to see the approach you used: I am pretty much
finished wrapping all the possible widgets in wxPython and I got close
to 2,000 lines of code :-D. I simply followed the wxWidgets
implementation (which currently supports 4 widgets only) by having a
central and unique PersistenceManager and delegate all the
saving/restoring to appropriate classes depending on the widget type.
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:
1) The value of a widget, like the text in a TextCtrl or the selection index in a list.
2) The window state (maximized, minimized, etc.), the window size, and the window
position, but only for top-level windows.
3) Other control-specific things such as the current sash position and the column
order in a grid.
In other words, you persist things that the *user* changed.
I pretty much knew that already, no need for a lesson. Persistent
object save and restore only attributes that the user can change, not
the ones the programmer input. This is the same philosophy the
wxWidgets Persistent Objects follow.
It would be interesting to see the approach you used: I am pretty much
finished wrapping all the possible widgets in wxPython and I got close
to 2,000 lines of code :-D. I simply followed the wxWidgets
implementation (which currently supports 4 widgets only) by having a
central and unique PersistenceManager and delegate all the
saving/restoring to appropriate classes depending on the widget type.
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:
1) The value of a widget, like the text in a TextCtrl or the selection index in a list.
2) The window state (maximized, minimized, etc.), the window size, and the window
position, but only for top-level windows.
3) Other control-specific things such as the current sash position and the column
order in a grid.
In other words, you persist things that the *user* changed.
I pretty much knew that already, no need for a lesson. Persistent
object save and restore only attributes that the user can change, not
the ones the programmer input. This is the same philosophy the
wxWidgets Persistent Objects follow.
Oh I misunderstood you then. My apologies! You said "all possible widgets" and "~2000 lines of code" which made me wonder.
I really want to believe you are not being ironic with your message.
···
2009/11/12, Paul McNett <p@ulmcnett.com>:
Andrea Gavana wrote:
Hi,
2009/11/12 Paul McNett:
Andrea Gavana wrote:
It would be interesting to see the approach you used: I am pretty much
finished wrapping all the possible widgets in wxPython and I got close
to 2,000 lines of code :-D. I simply followed the wxWidgets
implementation (which currently supports 4 widgets only) by having a
central and unique PersistenceManager and delegate all the
saving/restoring to appropriate classes depending on the widget type.
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:
1) The value of a widget, like the text in a TextCtrl or the selection
index in a list.
2) The window state (maximized, minimized, etc.), the window size, and
the window
position, but only for top-level windows.
3) Other control-specific things such as the current sash position and
the column
order in a grid.
In other words, you persist things that the *user* changed.
I pretty much knew that already, no need for a lesson. Persistent
object save and restore only attributes that the user can change, not
the ones the programmer input. This is the same philosophy the
wxWidgets Persistent Objects follow.
Oh I misunderstood you then. My apologies! You said "all possible widgets"
and "~2000
lines of code" which made me wonder.
I really want to believe you are not being ironic with your message.
I simply started from a bad assumption (that you were saving every detail about the instance). So, I misuderstood, and I apologized. No (intended) irony at all.
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.
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.
Right, but how many ways can a user change a given widget?
The frame:
size
position
state (maximized, minimized, ...)
A text ctrl:
value
etc.
Andrea already corrected my false assumption that things like font would be persisted (because ostensibly if the user was changing something like this, they'd be using a widget somewhere to do this, and *that* widget would persist its value).
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.
···
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.
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 ).
>> 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.
).