On Mon, 7 Jun 1999, [EMAIL PROTECTED] wrote:
> On 7 Jun 1999, Lars R.Clausen wrote:
>
>> I don't think that storing the currently selected objects is necessary,
>> or even the right thing to do. But that's a minor point at the moment.
>>
> I wasn't really happy about it either, but since the dialog is not modal
> things get a little fuzzy. I'd agree to just taking the currently
> selected items at apply time. If a user selected more/less objects with
> the dialog up and then clicked Apply that's their intention I suppose.
Yes. It is very rare for dialogs to really have to be modal.
> [snip my stuff]
>> resolved: We need to allow new objects to introduce new properties when
>> loaded. This means we can't just have static (integer) identifiers, but
>> more likely use string identifiers with a mapping, or something... The
>> type of a value is a problem. It can essentially be arbitrarily large.
>> If we just use a pointer to the value, we must be careful to avoid
>> pointing at values on the stack. That would probably be the right way
>> to do it. Then we'd have value comparison functions, at least for
>> unknown kinds of values. It must be easy to code with this, yet
>> possible to do things like bounds check, file loading for the image
>> object[1] etc. Possibly the definition of a property type would be in a
>> .h file with some macros for setting and getting the value. So for
>> instance the line object would have something like this:
>>
> Motif does something like this, which is:
> #define XM_SUCHANDSUCH "somestring"
>
> and then passes XM_SUCHANDSUCH around, neatly avoiding the problem of
> misspellings. And while I wouldn't normally quote motif as a model to be
> emulated, this works fairly well and allows each object to extend without
> clashing like integers can.
Well, the problem of misspelling is solved this way, but at the cost of it
being less efficient. I was hoping to think of some way that will allow us
to use strings for identification, but integers internally.
> I agree that type checking and handling is a big problem, especially for
> any complex types. It gets messy.
>
> [code snipped]
>> or something... this needs more thought. Maybe have a function table
>> for each object type containing appropriate get/set functions?
>>
> Generically building dialogs really bothers my sense of aethetics. They
> just don't seem as pretty and functional as hand crafted ones.
Which is why we want to have the ability to hand craft, but the simpler
dialogs can be generically built. Many of them are really cut-and-paste
jobs at the moment.
>> -Lars will continue thinking...
>>
>> [1] BTW, what was that other image library somebody mentioned? I'd like
>> to check it out.
>>
> GD? Look at www.boutell.com (I think) it has perl bindings too...which
> are really nice.
No, that's too small for our use. We need to be able to load just about
any bitmap format, not just GIF.
-Lars
--
Lars R. Clausen (http://shasta.cs.uiuc.edu/~lrclause) Hårdgrim of Westfield
"I do not agree with a word that you say, but I will defend to the death your
right to say it." -- Voltaire (?)
