Julian Foad writes:
For those of us with a two-button mouse it's a little awkward; I've
configured Xwindows to emulate a middle button when I press both together.
It should be very easy to add action areas over the actual displayed
digits -- that way, even one-button-mouse Mac types can be
Norman Vine writes:
Actually I was thinking about writing self documenting code
ie something like
// virtual base class
class FGProperty : public SGPropertyNode {
FGProperty () = 0 ;
}
// type specific derived classes for each property 'type'
class FGInt : public
Norman Vine writes:
GoF book??
esoteric geek speak :-)
http://hillside.net/patterns/DPBook/DPBook.html
If you can't dazzle em with
Nah, it's just shorter than typing DESIGN PATTERNS: ELEMENTS OF
REUSABLE OBJECT-ORIENTED SOFTWARE or the
Gamma/Helm/Johnson/Vlissades book all
David Megginson writes:
Norman Vine writes:
We really need a dictionary of the 'known' property 'nouns',
'verbs', 'adjectives' and 'adverbs' and *require* that this list is
updated before a new 'word' is introduced into the XML.
That would be nice, but it would require a committed
Perhaps a master document describing every property used in the
application is unreasonable, just like asking someone to maintain a
list of every variable used in the application would be unreasonable
and impossible to maintain.
Instead, it might be more reasonable to ask the author of every
Curtis L. Olson writes:
Perhaps a master document describing every property used in the
application is unreasonable, just like asking someone to maintain a
list of every variable used in the application would be unreasonable
and impossible to maintain.
go for it :-)
http://lxr.linux.no/ident
Norman Vine writes:
This requirement is especially true in that 'the FGFS properties'
is a 'one-of-a-kind' system
I wish it were -- I could accept some kind of fame as the inventor of
something new -- but in fact it's just a simple, in-memory
hierarchical database. Its structure is very
David Megginson writes:
I am willing to accept a little lag but one can of course take the
'exteme-programming' approach of writing the documentation
first before you code :-)
Actually, they write the unit tests before they code. Kent Beck, at
least, doesn't seem to be a big fan of
Julian Foad writes:
I attach a patch which does these, and an update to navcom-radio.xml
which specifies resolution appropriately and sets max to 118 or 136
instead of 117.95 or 135.975. Other files will need to be updated
similarly; how is this for a start? It seems to work without
David Megginson writes:
Norman Vine writes:
This requirement is especially true in that 'the FGFS properties'
is a 'one-of-a-kind' system
I wish it were -- I could accept some kind of fame as the inventor of
something new -- but in fact it's just a simple, in-memory
hierarchical
Norman Vine wrote:
We really need a dictionary of the 'known' property 'nouns',
'verbs', 'adjectives' and 'adverbs' and *require* that this list is
updated before a new 'word' is introduced into the XML.
Here is what I gleaned from your listing of the commands towards this end
Curtis L. Olson writes:
I was always taught: 1) Make a requirements specification 2) Make a
perfect and complete design (implies documentation could or should be
written at this point), 3) Impliment, 4) Test. When you finish one of
these steps, you move forward and never go back (too
Norman Vine writes:
I know nothing of Java and less about Gnome, but in Windows land
*most* programs that manipulate the registry at times other then
program installation are called 'viruses'
And therefore, since the windows operating system can manipulate the
registry while it is running ...
Norman Vine writes:
I know nothing of Java and less about Gnome, but in Windows land
*most* programs that manipulate the registry at times other then
program installation are called 'viruses'
In this case, the application is the Windows operating system.
All the best,
David
--
David
Curtis L. Olson writes:
Norman Vine writes:
I know nothing of Java and less about Gnome, but in Windows land
*most* programs that manipulate the registry at times other then
program installation are called 'viruses'
And therefore, since the windows operating system can manipulate the
Norman Vine writes:
I think that what we are really trying to say is
class SomeSystem : public FGSubsystem
{
.
private:
FGProperty* _serviceable;
FGProperty* _rpm;
FGProperty* _pressure;
FGProperty* _suction;
};
Not if this means what I think it
David Megginson writes:
Norman Vine writes:
I think that what we are really trying to say is
class SomeSystem : public FGSubsystem
{
.
private:
FGProperty* _serviceable;
FGProperty* _rpm;
FGProperty* _pressure;
FGProperty* _suction;
I just updated SimGear, FlightGear source, and base package from cvs.
Now when I try to change frequencies, the numbers to the right of the
decimal change mod 1, but the 1's, 10's and 100's didgits don't change.
I know there were changes made in this area. Did I miss updating
something?
Dave Perry wrote:
I just updated SimGear, FlightGear source, and base package from cvs.
Now when I try to change frequencies, the numbers to the right of the
decimal change mod 1, but the 1's, 10's and 100's didgits don't change.
Yes, David changed it so that it is more like the real radio;
David Megginson writes:
Norman Vine writes:
I think that what we are really trying to say is
class SomeSystem : public FGSubsystem
{
.
private:
FGProperty* _serviceable;
FGProperty* _rpm;
FGProperty* _pressure;
FGProperty* _suction;
David Megginson wrote:
Julian Foad writes:
I attach a patch which does these, and an update to navcom-radio.xml
which specifies resolution appropriately and sets max to 118 or 136
instead of 117.95 or 135.975. Other files will need to be updated
similarly; how is this for a start?
Michael Bonar writes:
...snip
To understand the Command design pattern better, you can look at page
233 of the GoF book. There's not a precise pattern in there
corresponding to the property tree, but it does share some
characteristics with the Mediator pattern (page 273).
GoF book??
Julian Foad writes:
The (previously) smooth rotation of angular values is worth
restoring and, unless it is tackled, I'm pretty sure floating-point
imprecision will result in users sometimes being unable to set an
end-point value like 118.000 MHz.
Both use cases (1) and (2) can be
David Megginson writes:
Julian Foad writes:
The (previously) smooth rotation of angular values is worth
restoring and, unless it is tackled, I'm pretty sure floating-point
imprecision will result in users sometimes being unable to set an
end-point value like 118.000 MHz.
Both
Norman Vine wrote:
This is the poor man's version taken from sg_inlines.h
// normalize a value to lie between min and max
template class T
inline void SG_NORMALIZE_RANGE( T val, const T min, const T max ) {
T step = max - min;
while( val = max ) val -= step;
while( val min ) val
Julian Foad writes:
Norman Vine wrote:
This is the poor man's version taken from sg_inlines.h
// normalize a value to lie between min and max
template class T
inline void SG_NORMALIZE_RANGE( T val, const T min, const T max ) {
T step = max - min;
while( val = max ) val
David Megginson wrote:
Julian Foad writes:
I don't like to add more configuration and code, I like to pare things
down to the simplest correct implementation. But I think this snap to
valid value behaviour will be necessary.
I might have a go at an implementation. How do you feel
Norman Vine wrote:
Julian Foad writes:
Norman Vine wrote:
This is the poor man's version taken from sg_inlines.h
// normalize a value to lie between min and max
template class T
inline void SG_NORMALIZE_RANGE( T val, const T min, const T max ) {
T step = max - min;
while( val = max )
I (Julian Foad) wrote:
I attach a patch which does these, ...
... It seems to work without skipping values.
Ooh, I hate it when people say it seems to work. It sounds so sloppy.
What I meant is I designed it and analysed it very carefully, and then
did just a quick test to confirm that it
Julian Foad writes:
Take a look at the patch I just submitted and let me know if you think
it's OK.
it looks llike it will work
rant not aimed at any one or thing in particular
but where are all these 'properties' documented ?
'min', 'max', 'resolution', and 'wrap' all make perfect sense
David Megginson wrote:
Julian Foad writes:
I noticed that the radios had nav. freq. range 108.00 to 117.95 but com.
freq. 0 to 140; this should be 118 to 140. But while playing with that
I noticed that the wrapping is a bit unpredictable. With (min=118,
max=140, step=1, wrap=true)
I (Julian Foad) wrote:
and, unless it is tackled, I'm pretty sure floating-point imprecision
will result in users sometimes being unable to set an end-point value
like 118.000 MHz.
Not actually unable to, because they can go back to 135.975 and then
forward to 118.000.
- Julian
Julian Foad writes:
I don't like to add more configuration and code, I like to pare things
down to the simplest correct implementation. But I think this snap to
valid value behaviour will be necessary.
Sounds like this could make a useful addition
FWIW - I have tried to keep some
Julian Foad writes:
I noticed that the radios had nav. freq. range 108.00 to 117.95 but com.
freq. 0 to 140; this should be 118 to 140. But while playing with that
I noticed that the wrapping is a bit unpredictable. With (min=118,
max=140, step=1, wrap=true) adjusting it up and down,
I noticed that the radios had nav. freq. range 108.00 to 117.95 but com.
freq. 0 to 140; this should be 118 to 140. But while playing with that
I noticed that the wrapping is a bit unpredictable. With (min=118,
max=140, step=1, wrap=true) adjusting it up and down, it sometimes skips
118 and
35 matches
Mail list logo
