Post by d***@netzero.comI just did. Please try it out and let me know what you think.
Way better than before :-)
Non-cosmetic comments:
- Drop the type selector for wallpaper and ringtone tab
- See if the category manager can be invoked from the
categories tab
- At some point we will want the changed fields to show
up in a different way (eg colour or bold). That will
give an indication what the revert button will undo.
It would be nice if the revert also becomes available
to the phonebook editor.
- There needs to be the ability to have multiple categories
and to order them. I think the category control could
be changed to a single control like you get with View
Columns with Move Up/Down, select add and delete buttons.
Cosmetic stuff:
- The dialog comes up a little bit too narrow for me.
- Change the "description" label to be "summary". That way people
won't get upset at it not letting them enter much information.
- The labels in priority should be "1 - Highest", "5 - Normal",
"10 - Lowest"
- The Notes doohickey should wx.EXPAND to the space available
- Various layouts should be tweaked to move items away from the edges
of the pane
- It may be better to have daily/weekly repeat options visible but
grayed out until the relevant type is chosen. That way users
can see what is possible. It will also fill up all that empty
space :-)
Post by d***@netzero.comLater on in your post, I think you answered this question pretty well,
touching on the pros and cons of both sides. One minor thing you did
not point out is that an object would have a well defined set of
properties whereas a dict can take on anything. For example, you can
mistype a dict key (in my case 'ringtones-index' instead of
'ringtone-index') and the dict would happily take it and not complain,
but the code would not work. That would not be the case for an object.
I'll admit to having made that same mistake as well once or twice :-)
The issue is that the item *needs* to accept any key. This is especially
likely to happen if they use a more recent version of BitPim and then
go back to an older one. The FILE_VERSION didn't work well in practise.
Any version should be able to deal with new keys from future versions,
just by ignoring them.
(We can still use objects for this - just have it whine about unknown
keys when run from the dev tree, but be silent when running
production)
Post by d***@netzero.comPost by Roger BinnsI also note the stringid creeping back in. What is the benefit?
I modeled this after your design of the database storage. It is an
'sourcetype': 'bitpim', 'id': <random generated hex string>
This entry is created for every object at instantiation time and can
be used as the dict key. ie: calendar[object.id]=object.
Ok, I see what you are trying to do and it is a bad idea (trust me).
Just use plain integers for the dict key (which makes it behave
like a list that can have holes). That will also make things
work right during times like importing, syncing, merging and
various other times when multiple lists of entries are in play.
If the id field is calculated in the fly that is ok. It should
definitely not be stored seperately. There isn't much use for
it except for undo.
(And you are right about what the database code is doing behind
the scenes. However the intention is abstracting out the entry id
and how it is found which will be useful for other datatypes
that aren't structured like the phonebook and calendar.
Post by d***@netzero.comPost by Roger BinnsThe field should just be omitted if no value is set.
In general, this is true for the internal data of the object.
However, you'd get a None back if you get the value through its
property. This is also true in the context of passing dict data
between bpcalendar and com_phone* should we decide to take that route.
I don't like doing that because None gets confusing. One context
would be "this value is set to a none value" and the other would
be "this value has never been set". They are semantically different,
although in many cases it will make no difference.
Post by d***@netzero.comI assume you're talking about the means of exchanging data between
bpcalendar & com_phone*. Within that context, I don't think of it
so much as "right" or "wrong" answer but more of different approaches
to achieve the same goal. I have my personal preference, but can
accommodate either approach.
I am referring to how the data is stored internally. This format
is a superset of what we accept via import and from phones and
is what the phone and export code have to deal with write back
out/export. (It is especially important that if you suck data
in, it is the same when it is spat back out. There are already
cases where this doesn't happen in the phonebook such as internally
we only store "fax" whereas some data sources have "business fax"
and "home fax".)
I do think it is important that the calendar and phonebook operate
the same way in terms of the data being an object vs being a dict
with seperate methods. Whatever the resulting mechanism will
then also be extended to the other data types as we get round
to them.
I think the approach to take is the following:
- use objects
- the object should be a subclass of dict
- in the constructor and setitem methods it should print
a complaint about unknown keys (prints are automatically
ignored in production builds)
- "properties" that are not present generate an exception
when accessed and are semantically different than
"properties" set to None
We can use the factory pattern for constructing the objects
so the factory can decide what to do about data that gets
attached such as lists of dicts (it can wrap them in objects
also derived from list and dict respectively) or leave them
as is.
This approach will let the existing codebase treat the
entries as dicts, but also gives us a convenient place
to hang methods on.
Post by d***@netzero.comPlease let me know what you think of the new (tabbed) GUI.
Looks good. It seems like we will definitely need tabs
for the wallpaper and ringtones, so we may as well have
tabs for everything. Both Outlook and Evolution take the
approach of stuffing as many of the most frequently used
fields as possible on the first tab with less frequent
stuff on other tabs.
Roger