[PATCH] Add user definible options to the print menu

Salvador Cuñat salvador.cunat at gmail.com
Sun Mar 17 18:22:39 PDT 2013


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 ?

"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.

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.

> > @@ -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
> > +/*
>           ...
>
> > + * would be bigger than maximum size avaliable for printing 93%.
> > + * There's a 7% reserved for the header which isn't scaled
> > + */
> > +#define SCALECALLBACK(name, scales1, scales2, scales3)\
> > +static void name(GtkWidget *button, Spin_buttons_block *data)\
> > +{ \
> > +    print_options.scales1 = gtk_spin_button_get_value(GTK_SPIN_BUTTON(button)); \
> > +	print_options.scales2 = 93 - print_options.scales1 - print_options.scales3; \
> > +	if (print_options.scales2 < scales2##_min) { \
> > +		print_options.scales2 = scales2##_min; \
> > +		print_options.scales3 = 93 - print_options.scales1 - print_options.scales3; \
> > +	} \
> > +	gtk_spin_button_set_value (GTK_SPIN_BUTTON(data->spin1), print_options.profile_height);\
> > +	gtk_spin_button_set_value (GTK_SPIN_BUTTON(data->spin2), print_options.notes_height);\
> > +	gtk_spin_button_set_value (GTK_SPIN_BUTTON(data->spin3), print_options.tanks_height);\
> > +	gtk_box_pack_start (GTK_BOX(data->box), data->spin1, TRUE, TRUE, 5);\
> > +	gtk_box_pack_start (GTK_BOX(data->box), data->spin2, TRUE, TRUE, 5);\
> > +	gtk_box_pack_start (GTK_BOX(data->box), data->spin3, TRUE, TRUE, 5);\
> > +}
> 
> 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.
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.

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.

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

Regards.

Salva


More information about the subsurface mailing list