Re: size/lines clist initialisation fix.

[Ali Akcaagac <ali akcaagac stud fh-wilhelmshaven de>]

On 2001.08.13 10:23:58 +0200 Maciej Golebiewski wrote:
> > values, that thing could be somewhere in the clist, and if we open
> > a scrollable window inside that then you might be getting a size field
> > that is 100000 pixels wide for any unlucky and sad circumstances.
> 
> There are two things. I agree that not saving the size after the user
> changed it was a bug. But another thing is when you have to set the
> pixel size for every widget because the widget can't reasonably
> calculate some defaults itself - that's a terminal brokenness of said
> widget and I do not believe that Gtk has such problems.

no...

you still don't understand. well let's say we have a window of 640x480
pixels. we give these fields a default value to have them all fit
nicely into this 640 pixels wide window. noting else.

if you don't set some startvalues for width then all tabs would look
like this if they calculate dynamically.

[figure 1]

.----------------------------------------------------------------------.
| # | S | A | From | Subject | Date | Size                             |
`----------------------------------------------------------------------'
<------------------------ 640 pixels ---------------------------------->

they calculate themselves for the width of the labeled text and end. if
you now give them some serious startvalues for width then they could look
more reasonable. this has nothing to do with dynamically calculation
afterwards.

[figure 2]

.----------------------------------------------------------------------.
| # | S | A | From          | Subject            | Date         | Size |
`----------------------------------------------------------------------'
<------------------------ 640 pixels ---------------------------------->

> I am pretty sure that not setting pixel widths explicitely for column
> widths will cause Gtk to set them automatically so that the labels fit.

yes, exactly 'labels fit' (see figure 1) but the intention for balsa and
balsa's code is (figure 2).

> Well, if the total is constant at 640 and you have to carve some pixels
> out for a new widget, then you have to decide which columns have to get
> narrower and how much. So you do recalculate something.

no, i still have the feeling that you don't understand what i was up to
we are talking about two different things, the one has nothing to do
with the other. these values are initial values that are sent to the
widget before its realized and before its shown, after this process the
widget's container takes over with sizing etc. another scenario would be
this.

.----------------------------------------------------------------------. ^
|                                                                      | |
|  .----------------------.                                            | |
|  |                      |                                            | | 4
|  |    B U T T O N  1    |                                            | | 8
|  |                      |                                            | | 0
|  '----------------------'                                            | |
|                                                                      | | p
|                                                                      | | i
|                                                                      | | x
|                                            .----------------------.  | | e
|                                            |                      |  | | l
|                                            |    B U T T O N  2    |  | | s
|                                            |                      |  | |
|                                            '----------------------'  | |
`----------------------------------------------------------------------' v
<------------------------ 640 pixels ---------------------------------->

in this scenario we have a 640x480 pixels window and we want to set two
buttons inside it, now these buttons need initial values, the size, the
x,y origin etc. sure we could argue now about the maincontainer that
coordinates the childwidgets inside, e.g are the widgets selfattaching,
is the dialog able to resize etc. but who cares, we designed out app to
have some initial values that looks good and end. its like painting your
program with glade. now lets think about an easy example. we set the
initial values and now we shrink the dialog.

.-------------------------------------------------------------. ^
|                                                             | |
|  .------------------.                                       | | 2
|  |                  |                                       | | 4
|  |  B U T T O N  1  |                                       | | 0
|  |                  |                                       | |
|  '------------------'                                       | | p
|                                                             | | i
|                                       .------------------.  | | x
|                                       |                  |  | | e
|                                       |  B U T T O N  2  |  | | l
|                                       |                  |  | | s
|                                       '------------------'  | |
`-------------------------------------------------------------' v
<--------------------- 320 pixels ------------------------------>

oki you see we shrinked the window, so the elements inside shrink,
our window is resizeable and the widgets inside are selfattaching.

the viewable field for the clist still stays 640 pixels, if you now
move these objects, e.g. make the 'date' field really big, move the
arrow as far right as possible, you notice that you get a horizontal
scrollbar, because you increased the default view of 640 pixels.
(besides mentioned that this 640 pixels mustn't be valid for now
because your balsa window may be 1024x786 now, then for sure 640
pixels DEFAULT initial value for new settings aren't valid anymore)

another example would be, the windowmanager, lets say you run some
apps, and you wonder why you get some BIG fileselectorboxes with
OK, CANCEL and whatever buttons you have they are soo damn big that
you could press them beeing 20 meters away from your monitor now go
to this window, and shrink it.. also the elements are getting shrinked
dynamically.

oki. well i think i explained enough.

> As I already wrote above: I admit not saving preferences was a bug.
> But not specifying explicit default pixel width was a feature
> (and was done intentionally) - I left it out to Gtk to do that.

yeah, i'd better leave the initialisation to balsa and leave the
rest to the container that manages the widgets after realizing and
after they get shown.

> > solve the current problem. besides mentioned that you didn't take any
> > care about 2 CASE statements that only go from 0-5 and skip the 6th
> 
> Can you be more explicit which stmts? There are plenty of switch statements
> in balsa but not all of them are relevant to everything. :) (I'm at work,
> don't have balsa sources here and way too much work to dig into them right
> now).

sure.

balsa-index.c

/* When a column is resized, store the new size for later use */
static void
resize_column_event_cb(GtkCList * clist, gint column, gint width,
		       gpointer data)
{
    switch (column) {
    case 0:
	balsa_app.index_num_width = width;
	break;

    case 1:
	balsa_app.index_status_width = width;
	break;

    case 2:
	balsa_app.index_attachment_width = width;
	break;

    case 3:
	balsa_app.index_from_width = width;
	break;

    case 4:
	balsa_app.index_subject_width = width;
	break;

    case 5:
	balsa_app.index_date_width = width;
	break;

    case 6:
	balsa_app.index_size_width = width;
	break;

    default:
	if (balsa_app.debug)
	    fprintf(stderr, "** Error: Unknown column resize\n");
    }
}

i've added the 6th case, otherwise we may run in default on worst
case.

cheers.

-- 
Name....: Ali Akcaagac
Status..: Student Of Computer & Economic Science
E-Mail..: mailto:ali.akcaagac@stud.fh-wilhelmshaven.de
WWW.....: http://www.fh-wilhelmshaven.de/~akcaagaa