On Tue, 4 Jan 2005, bulia byak wrote:
> On Tue, 4 Jan 2005 13:26:56 -0800 (PST), Bryce Harrington
> <bryce@...> wrote:
> > Actually, it does use the 0.80 factor, but in its inverted fashion
> > (1.25). However I chose to make px the primary unit so the conversion
> > factors are expressed as functions of px's rather than pt's.
> This sounds good. I just did mostly the same, now there's only one 0.8
> defined in one place.
> Actually what I need from SPUnit is this:
> sp_pixels_from_units, sp_units_from_pixels
> SP_PX_TO_METRIC_STRING (currently it's in SPMetrics, but this class is
> redundant, it should be merged with SPUnit)
Okay, I'll make sure equivalents for those are there. This is good to
know, because there's a lot of routines in there that I wonder whether
they may not be needed.
Do you want to have wrapper functions by those exact names to hook to
those, or do you just want a routine that provides the equivalent
functionality? (I've dropped the sp prefix for this code and have
been implementing routines as class members, but wrappers could probably
be created if needed.)
> functions to get ratios to and from px for all units (to replace the
> defines from unit-constants.h)
All of the linear document units are based on px as the primary unit so
trivially these can be obtained via `u.factor` in the Unit structure.
For the unit widget I also added a convenience function for getting the
conversion factor from whatever the user's selected to a different unit:
double getConversion(Glib::ustring const &new_unit_abbr) const;
Basically this just returns old_unit.factor / new_unit.factor but also
does some checking that new_unit_abbr exists, and checks that neither
factor is ~ zero. Possibly we could promote this convenience function
up higher if other areas of the codebase also need to do similar
> sp_get/set_value_in_pixels for an adjustment with a unit menu
Derek and I have crafted a new compound widget called ScalarUnit, which
incorporates this functionality a bit more conveniently, and handles the
Adjustments internally. To set the value/units for this unit, this
function is provided:
void setValue(double number, Glib::ustring const &units);
(I am assuming the performance cost of specifying units as a string will
be negligible; I think that's a pretty safe assumption, but if not, we
can gain back most of the performance by using Quarks.)
In addition, if you wish to flip the units, this function can be used:
bool setUnit(Glib::ustring const &units);
This will also recalculate the value so it "means" the same thing in the
There will also be signal handlers for unit system changes. That is, if
the user changes preferences regarding their units (such as switching
the default unit for the document), a signal can be issued and all unit
widgets will update accordingly.
> If you provide this in your implementation of SPUnit, it will be
> almost a drop-in replacement. Just please don't touch any unit stuff
> outside of SPUnit and SPMetrics and SPUnitMenu, because there were
> tons of changes and fixes recently, throughout the codebase, caused by
> the removal of 0.8 and the change in base zoom. Please just provide
> the above API and it should be easy to merge.
Alright, will do. Like I mentioned earlier, the only place this is
hooked into right now is the Transformation dialog. We'll take care to
not hook it in anywhere else for the time being.