GNOME.org
 

Re: Glade extra code?

On Wed, 2002-06-19 at 13:47, Dr. Peter Rottengatter wrote:

On 19 Jun 2002 13:00:45 -0700, "William L. Thomson Jr." <support obsidian-studios com> wrote:


On Wed, 2002-06-19 at 07:43, Olivier Sessink wrote:

On Tue, 18 Jun 2002 14:32:16 -0700 "William L. Thomson Jr."
<support obsidian-studios com> wrote:


I assume the Glade code will make up for differences in font size, and
etc. that can change when the use changes themes, font sizes, etc. Which
would be one reason to stick with the Glade code.


as long as you don't use gtk_widget_set_usize() on labels/buttons etc.
then gtk does this already for you, no glade needed


I am confused. You are saying do not use gtk_widget_set_usize(), because
I am using it on a variety of different widgets. Not so much labels, but
buttons, entries, and windows.

Otherwise since I am now using a table, the widgets will be the size of
the table cell.


Not necessarily. You should check the attributes of the table and of the widgets
inside the table cells. There is for instance the "padding" attribute which by
default is set to zero and controls the amount of "free" space around the widget,
inside the cell.


But that padding applies to both sides of the widget evenly, not one or
the other. So shifting left or right is not that easy, or shrinking?

Unless there is something I am missing, but I have played around with
the padding, and not really had any positive results. At least not in
the cases that I use the usize function.


Here also the solution to your question above: There are lots of attributes, and
Glade sets all of them according to what you set for each widget when constructing
it in the Glade GUI. This tends to become some a bit lengthy code, but quite worth
it. In Glade, click "Show Properties" in the "View" menu to get a window that displays
the properties (attributes, callbacks etc.) for each widget upon selecting it.


Yeah I played around with the table properties. There was some property
of Left, Right or Center justify that seems to have no effect at all? I
would assume it to be part of what I need. But I still need to resize
widgets in a table cell, so the widget is not the size of the cell, and
also aligned properly.


I wrote an earlier response, but apparently it did not make it to the mailing list.
That's why this in personal mail. I'll attach my earlier reply.


I am pretty sure I saw it unless it was not sent to the list or me
personally.


-
      Dr. Peter Rottengatter       peter rottengatter de
                                   http://www.rottengatter.de

 PGP fingerprint : FD8C 16E5 25CB ED06 43FD  3A0F 11AD E2F8 E89A 83E8


Old reply:


 On 17 Jun 2002 18:50:38 -0700, "William L. Thomson Jr." <support obsidian-studios com> wrote:

 > On Mon, 2002-06-17 at 17:55, James M. Cape wrote:
 > > On Mon, 2002-06-17 at 18:36, William L. Thomson Jr. wrote:
 > > > I am trying to make a form look pretty. :)
 > > > 
 > > > I am coming from a Java background, and in Java I used a gridbaglayout
 > > > with various constraints.
 > > > 
 > > > With GTK+ I am not sure what to use. I am using GTK+1.2, and using the
 > > > vbox and hbox to control layout. I am thinking about experimenting with
 > > > the a table?
 > > > 
 > > > Or should I just stick with the vbox, and hbox, and do my best with
 > > > them?

 Both (the Table, and the VBox/HBox) approaches are pretty similar to each other.
 The only difference is that VBox/HBox won't enforce  alignment in both directions
 at once. What do I mean by that. If you use two columns of user interaction items
 (tm ;-), a VBox/HBox setup does not necessarily enforce the vertical alignment of 
 the second items in the columns, which may be desirable if they are not related 
 to each other. Often, however, you want to vertically align a Label and an Entry 
 widget, because the Label describes the Entry, and you want to horizontally align 
 Labels and Entries because that's pretty. That's the situation where you wanna 
 use a Table.

 Note: You can always emulate a Table by using VBox/HBox, with little overhead, but
 there are situations where a Table does not look as good.

 I'd suggest you experiment a little using Glade, which is a GTK+ GUI construction kit.
 You can directly compare VBoxes, HBoxes and Tables and play with all attributes.
 You'll almost immediately get a feeling for which is good for which situation.

 You even save a lot of tedious GUI-coding work if you let it write some code for
 you.


 > Yes, it looks like I do need to play around with the table. I can get
 > close but not perfect with the vbox, and hbox.

 You'll probably want to learn of the attributes. There is a lot you can do by 
 tweaking them.


 > Yes this I would like to avoid. If my windows are resized, I think I can
 > turn that off,

 Yes, you can.


 > In every language there is allot of crap required just to position
 > things. Why can't I just specify x and y coordinates. :(

 You can. There is the very basic class GtkFixed which lets you position
 anything at fixed x and y coordinates. 

 I started thinking like you here, but quickly found out that fixed
 coordinates usually is not what you want. Reason is that all the alignment
 decisions you make are based on the actual font style/size. However, if
 you do not nail everything down, the user will choose a font that is twice
 as large because he is using a 3200x2400 screen resolution, and all your 
 x/y choices are broken. If you do nail it to a fixed font, the same user 
 jwon't be able to read the dialog labels anymore.

 Sure you can decide on x/y dynamically, by calculating string extensions
 etc. but that's exactly the tedious, error-prone work GTK to designed to
 save you from. So do yourself a favour and do not use GtkFixed. ;-)


 > Bottom line I have to do allot of trial and error, and widget fidget. :)
 > The annoying part of gui development.

 That's why I recommended Glade.


 Cheers  Peter





-- 
Sincerely,
William L. Thomson Jr.
Support Group
Obsidian-Studios Inc.
439 Amber Way
Petaluma, Ca. 94952
Phone  707.766.9509
Fax    707.766.8989
http://www.obsidian-studios.com
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]