Derek Neighbors (Derek) asked whether readonly dialog had not been finished or if it was the final version. Because as of time of writing they did not look like error messages. James Thompson (jamest) explained that now all dialogs were .gfd forms and it was easy to change them to make look like real error boxes.
Later, Anthony Lenton (aa) said he had some patches, but as he was
not working on the *latest* 0.5, could
already be changed/fixed)
. Jason Cater (jcater) noted that
cvs head has changed a lot recently
.
Mainly UIdriver system, bugfixes, lots of rearranging. James said
the biggest change will be you can do
<dialogs> now that work which I think will probably replace
some custom stuff you had to do in that last patch cluster you sent
us
. Most of the internal dialogs
now use the new setup (all but login dialog). You can find examples in
forms/src/dialogs. So you can do custom dialogs a few different ways.
You can define them in .gfd files or gfd libraries, or if you want to
bundle a custom gnue-forms you can add directories under
forms/src/dialogs and follow that format - forms can't tell the
difference where they came from.
. Anthony was interested
how does the caller know the outcome of
the dialog?
James explained - dialogs
are modal and have a parameters dict passed into them. They manipulate
that dict which you can then check
.
Jason Cater (jcater) asked Reinhard Müller (reinhrad) whether he
wanted a point release of appserver with the release of
forms/common/designer (that was planned for a week or two). Jason was
also planning to do a non-major release of reports at the same time.
Reinhard explained this depends on
whether i can get hold of
Jan Ischebeck (siesel) as
I have some points i have to decide
w/ him before any further release of appserver because this decision
could break compatibility and i don't want a release and break it a
week afterwards
.
Derek Neighbors (revDeke) wanted to check some previous work he had done on
item pricing which recorded both a 'cost' and a 'base price' for an item.
every one of their customers had own item and
price list (this is likely more 'distributor' oriented than 'retail' oreinted).
The concept is I might offer 800 products, but to customer A only 100 of them
might be available for purchase and customer A might pay more than customer B
for item xyz, so basically pricing is set at 'customer' level
. Most
customers would default to the default price, but other customers might get
preferential discounts. Mike Vincent (Vee2d2) thought
the best way to do it, is to have simply a 'price'
field in the item table. Then there should be a discounts table (or whatever
you wanna call it) which references the products in the product table and has
a qty and price. Then when needing a price for a product
-
the discount table would need to be checked..
and if no discount item or if the qty ordered were less than that in the
discount table the price from the item table would be used.
Derek said that, if people did not want to use something this complicated,
they could simply have the same discount rate (which might be 0%) for all
customers. Also, he noted that discounts would probably be related to the
total volumes being ordered over time by a customer, not necessarily the
volume of a particular product on a particular order. Mike agreed - he was
aware of wholesalers who had a piece price, dozen
price, and case price and a secret '4th line' price they give to the high
volume accounts which is a bit better than their published 'case
pricing'
Derek said as long as we add
ability to do 'customer' based discounts - you can do 'volume discount'
and then compare that to the 'customer' discount
(if one exists) and take the lower of the two
.
Derek felt that this level of sophistication on pricing was where
the shrink wrap stuff SERIOUSLY falls down on
its face
- the more agile you can be with
your pricing the more effective you can be
. It was not unknown for
gas stations/petrol stations to change price several times a day.
Adam Hull (fixe) doubted whether wxWindows was really a good choice.
Jason Cater (jcater) explained that wxWindows
was a means to an end, not a permanent solution
. As of time of
writing, Jason was committing an almost
complete (usable today) QT3 driver
. Also work was beeing done
on native GTK2 and Win32 drivers.