[PATCH] Add user definible options to the print menu

Dirk Hohndel dirk at hohndel.org
Sun Mar 17 20:13:05 PDT 2013


Salvador Cuñat <salvador.cunat at gmail.com> writes:

> On Sun, Mar 17, 2013 at 02:54:36PM -0700, Dirk Hohndel wrote:
>> Salvador Cuñat <salvador.cunat at gmail.com> writes:
>> 
>> 
>> Wouldn't this lend itself to something like this:
>> 
>>  +	if (print_options.notes_up)
>>  +		NOTES_BLOCK()
>>  +	PROFILE_BLOCK()
>>  +	if (!print_options.notes_up)
>>  +		NOTES_BLOCK()
>> 
>> less duplicated code...
>> Or even better, turn this into functions :-)
>>
> Good night.
>
> Are you trying to confuse me, Dirk ?

Not intentionally :-)

> "less duplicated code" is exactly what I meant.  As the default option
> is !print_options.notes_up it has to be "the if option" not the else.
> May be I haven't understand you.

Well, the macro expands into actual code, right? So if you look at what
is actually there in the function than my version creates a lot less
code. But I guess that's silly and yours is easier to read...

> Obviously functions are better and a much more elegant way of doing
> things  (personally, I hate very much macros, I'm old fashioned, I
> know), *but* I think we're headed to a fully user customizable printout,
> and this will supose heavy changes in the funcs we're managing today. So
> let's have a cheap, functional version instead of bother with functions
> that, for sure, will get useless as the printing evolves.

I'm ok with that.

>> > @@ -873,11 +888,55 @@ static void name(GtkWidget *w, gpointer data) \
>> >  
>> >  OPTIONSELECTEDCALLBACK(print_selection_toggle, print_options.print_selected)
>> >  OPTIONSELECTEDCALLBACK(color_selection_toggle, print_options.color_selected)
>> > +OPTIONSELECTEDCALLBACK(notes_up, print_options.notes_up)
>> > +
>> > +/*
>> > + * Hardcoded minimum and maximum values for the scaling spin_buttons
>> > + */
>> > +#define profile_height_min (37)
>> > +#define notes_height_min (7)
>> > +#define tanks_height_min (7)
>> > +#define profile_height_max (77)
>> > +#define notes_height_max (49)
>> > +#define tanks_height_max (17)
>> 
>> So these are now percentages - which means that sum(...) = 100?
>> 
> They'd always been, only changed base 200 to 100, but sum won't be 100
> but a maximum of 93, because as said below

Got it.

>> Ok, this confuses me. These callbacks are supposed to ensure that we
>> don't violate the maximum and minimum values - but they do allow me to
>> have values that don't sum up to 100?
>> 
> If things go well will never sum more than 93.  If reaches 100 ... Well
> the function is worse designed than I expected.

I included the 7% for headers in my mental calculation.

> As said, I hate macros, and if they involves functions much more.  The
> macro reads the button we are changing and computes a value for one of
> the others, keeping the third constant. Then evaluates the second
> against it's minimum preset value and, if lower, defaults to minimum and
> computes a value for the third one. Then displays them.

That's... ummm... insanely complicated for what you are trying to do...

> This contrived thing is triggered by the fact that, under some selected
> numbers, we could compute other value lower than its minimum. Not too
> bad, except because GtkSpinButton will default to the minimum and then
> the sum would be > 93  (+7 >100) and the printout get out of bounds.
>
>> > +SCALECALLBACK (prof_spin_button, profile_height, notes_height, tanks_height)
>> > +SCALECALLBACK (notes_spin_button, notes_height, profile_height, tanks_height)
>> > +SCALECALLBACK (tanks_spin_button, tanks_height, notes_height, profile_height)
>> 
>> Wouldn't it make much more sense to have spin buttons for notes and
>> tanks and simply give the rest to the profile?
>> 
> This may be true.  Could have only two values set, and the third
> calculated, but if I should have to choose would prefer tanks and profile
> and give the rest to notes, as these, by default, are ellipsized.

Ok, that works for me.

> If you prefer, I'll get rid of one of the buttons, this will simplify
> things a lot.

Yes, I think this will make things both easier to implement AND easier
to use.

/D


More information about the subsurface mailing list