RE: [gnomemm] How to use persistent history with GnomeEntry?

[Christopher Smith <x xman org>]

On Mon, 2003-10-20 at 10:19, Murray Cumming Comneon com wrote:
> > Keep in mind that your existing 
> > behavior is exactly correct for those who create their 
> > entries by passing a null to gnome_entry_new.
> 
> Is there a difference between "" and NULL here? They are normally treated
> the same by GTK+ and GNOME.

In this case they are not, and I'd argue this is correct behavior.

> If "" is an invalid and useless value, then the implementation should just

"" turns out to be a valid history id, and could actually prove to be
valid and useful in certain scenarios. I could imagine a scenario where
it was used as the default history id for controls in an app.

> pass a NULL when history_id.empty(). Constructors can be manually
> implemented - search for _CONSTRUCT in .ccg files.

Cool, I'll check this stuff out. Now that you've found the internals
docs for me, I am feeling far less intimidated by the code.

> > You could try 
> > special casing the empty string case, but personally I'm a 
> > big fan of the "a null is not the same as an empty string" theory.
> 
> I don't think it's a useful distinction unless you are playing around with
> pointers and character arrays without the benefit of a string class. I see
> no need of the null-string concept here.

This tends to be a bit of a political issue, but I'd argue that a C
programmer who can't distinguish between pointers and values is not
going to go very far without shooting themselves in the foot.

> > Yeah, it does work, indeed, you don't have to ever invoke 
> > set_history_id(). If you never set it, then your "history" is 
> > never persisted. If you set_history_id() after creation, it 
> > doesn't appear to load the history, but will persist it. 
> > Bizarre but true.
> 
> This bug should at least be in bugzilla.

Hmmm... you referring to the gnomemm issue or the fact that
set_history_id() behaves the way it does? For the former, I'll submit a
bug and a patch at the same time, probably in the next day or so. For
the latter, I could see where the developers might have chosen that
approach (although I'd sure like to see an explicit
"load_history_from_id()" type function), as otherwise, setting the
history id for an Entry object could potentially wipe out it's current
history.

-- 
Christopher Smith <x xman org>