fxruby-users

[Fxruby-users] layout probs with TreeList.

[Hugh S. S. E. E. <hg...@dm...>]

I have an FXDialog window with a treelist created like this:



class CategoryDialog < FXDialogBox
    CATEGORIES = :CATEGORIES
    ITEMS = :ITEMS
    BOTH = :BOTH
    def initialize(parent, edit=CATEGORIES)
        super(parent, "Category Dialogue",DECOR_TITLE|DECOR_BORDER|LAYOUT_FILL_X)

        puts "called FXDialogBox.initialize"
        menubar = FXMenubar.new(self)
        filemenu = FXMenuPane.new(self)
        FXMenuCommand.new(filemenu, "&Quit", nil, getApp(), FXApp::ID_QUIT, 0)
        FXMenuTitle.new(menubar, "&File", nil, filemenu)

        FXHorizontalSeparator.new(self)
        # Contents
        contents = FXHorizontalFrame.new(self, LAYOUT_FILL_X )
        @treeview = Hash.new()
        @treeview[""] = FXTreeList.new(contents, 10)
        @treeview[""].listStyle |= TREELIST_SHOWS_LINES | TREELIST_SHOWS_BOXES | TREELIST_ROOT_BOXES|LAYOUT_FILL_X
        @treeview["equipment"] =
        @treeview[""].addItemLast(nil,
        "equipment",nil, # openIcon
        nil, # closedIcon
        TreeData.new(@treeview[""], "#{$equipdir}" ) # data
        )
    end

    #...
end

I find that the TreeList only takes up half the space of contents,
the lower pane, and that it is too narrow.  LAYOUT_FILL_X is not
doing what I expected in this regard.  Have I missed some layout
facilities?  Also the right hand half of contents is blank, despite
there being nothing in it: I thought it would expand to fit its
contents, which in this case would be not expand at all.

        Hugh

Re: [Fxruby-users] layout probs with TreeList.

[Lyle J. <jl...@cf...>]

Hugh Sasse Staff Elec Eng wrote:

> I find that the TreeList only takes up half the space of contents,
> the lower pane, and that it is too narrow.  LAYOUT_FILL_X is not
> doing what I expected in this regard.  Have I missed some layout
> facilities?  Also the right hand half of contents is blank, despite
> there being nothing in it: I thought it would expand to fit its
> contents, which in this case would be not expand at all.

This is just based on a quick scan of the code, but see what (if 
anything) happens if you make these changes:

First, remove the LAYOUT_FILL_X from the dialog box's constructor 
options. I don't guess it's hurting anything, but it's being ignored; a 
dialog box is a top-level window and thus doesn't have a parent 
container to stretch out in:

     super(parent, "Category Dialogue", DECOR_TITLE|DECOR_BORDER)

Next, change the layout hints for the contents frame so that it 
stretches in both the x and y directions:

     contents = FXHorizontalFrame.new(self,
         LAYOUT_FILL_X|LAYOUT_FILL_Y)

Similarly, change the layout hints on the tree list so that it stretches 
in both the x and y directions:

     @treeview[""].listStyle |=
         (TREELIST_SHOWS_LINES |
          TREELIST_SHOWS_BOXES |
          TREELIST_ROOT_BOXES|
          LAYOUT_FILL_X|LAYOUT_FILL_Y)

By telling these two widgets to (additionally) stretch to fill up the 
remaining space in the y-direction, you shouldn't see any wasted space, 
vertically speaking.

Now as for your comment about the right-hand side of contents being 
blank: is it drawn with a white background? If so, that is just the tree 
list stretching to fill in the x-direction. But it doesn't "stretch" the 
tree items, if that's what you're asking. In other words, the tree 
items' text is going to be drawn in whatever the current text font is 
for that tree list.

Hope this helps; please follow up if this doesn't cover it.

Lyle

Lyle

Re: [Fxruby-users] layout probs with TreeList.

[Hugh S. S. E. E. <hg...@dm...>]

On Wed, 16 Jul 2003, Lyle Johnson wrote:

> Hugh Sasse Staff Elec Eng wrote:
>
> > I find that the TreeList only takes up half the space of contents,
> > [...]  Also the right hand half of contents is blank, despite
>
> This is just based on a quick scan of the code, but see what (if
> anything) happens if you make these changes:
>
> First, remove the LAYOUT_FILL_X from the dialog box's constructor
> options. I don't guess it's hurting anything, but it's being ignored; a
> dialog box is a top-level window and thus doesn't have a parent
> container to stretch out in:

Oh, yes, of course.... You were right: that alone made no
difference, but I can just let the layout default now.

> Next, change the layout hints for the contents frame so that it
> stretches in both the x and y directions:
>
>      contents = FXHorizontalFrame.new(self,
>          LAYOUT_FILL_X|LAYOUT_FILL_Y)

This seemed to make no difference, but I'll leave it in for now.
>
> Similarly, change the layout hints on the tree list so that it stretches
> in both the x and y directions:
>
>      @treeview[""].listStyle |=
            [...]
>           LAYOUT_FILL_X|LAYOUT_FILL_Y)

OK, so the problem is not due to using that ATTR to do the job,
anyway....
>
> By telling these two widgets to (additionally) stretch to fill up the
> remaining space in the y-direction, you shouldn't see any wasted space,
> vertically speaking.

I didn't notice much difference here.  But since my problem is in
the X direction that is reasonable.
>
> Now as for your comment about the right-hand side of contents being
> blank: is it drawn with a white background? If so, that is just the tree

No, it is grey like the rest of the tool, not white like the
TreeList background.  I have managed to capture a small == low
quality jpg of it, gzipped and attached.

> list stretching to fill in the x-direction. But it doesn't "stretch" the
> tree items, if that's what you're asking. In other words, the tree
> items' text is going to be drawn in whatever the current text font is
> for that tree list.

Agreed, I expected it to stretch the rectangle that is white, which
holds all these.
>
> Hope this helps; please follow up if this doesn't cover it.
>
> Lyle
>
> Lyle
>
        Thank you,
        Hugh
>

Re: [Fxruby-users] layout probs with TreeList.

[Lyle J. <jl...@cf...>]

Hugh Sasse Staff Elec Eng wrote:

>> Similarly, change the layout hints on the tree list so that it stretches
>> in both the x and y directions:
>>
>>      @treeview[""].listStyle |=
>             [...]
>>           LAYOUT_FILL_X|LAYOUT_FILL_Y)
> 
> OK, so the problem is not due to using that ATTR to do the job,
> anyway....

Whoops, yes, that is a problem. My mistake. The 'listStyle' attribute 
only deals with the treelist-specific options (e.g. 
TREELIST_SHOWS_LINES). So let's break that line up into:

     @treeview[""].listStyle |=
         TREELIST_SHOWS_LINES|TREELIST_SHOWS_BOXES|TREELIST_ROOT_BOXES
     @treeview[""].layoutHints = LAYOUT_FILL_X|LAYOUT_FILL_Y

and see if the layout hints "take" this time ;)

Re: [Fxruby-users] layout probs with TreeList.

[Hugh S. S. E. E. <hg...@dm...>]

On Wed, 16 Jul 2003, Lyle Johnson wrote:

> Hugh Sasse Staff Elec Eng wrote:
>
> > OK, so the problem is not due to using that ATTR to do the job,
> > anyway....
>
> Whoops, yes, that is a problem. My mistake. The 'listStyle' attribute
> only deals with the treelist-specific options (e.g.
> TREELIST_SHOWS_LINES). So let's break that line up into:
>
>      @treeview[""].listStyle |=
>          TREELIST_SHOWS_LINES|TREELIST_SHOWS_BOXES|TREELIST_ROOT_BOXES
>      @treeview[""].layoutHints = LAYOUT_FILL_X|LAYOUT_FILL_Y

Oh, so that is an inherited attribute then, as it is not listed....
>
> and see if the layout hints "take" this time ;)

Yes, that did the job.

I have since tried removing the layout hints from contents (the
horizontal frame, and found that I get the uncorrected behaviour.
I see from the FOX Docs that these FILL_ hints cause this hehaviour:
"If more than one child with this option is placed side by side, the
available space will be subdivided proportionally to their default
size."
So when I had not set the FILL_X before, I was effectively getting
this anyway because of how LAYOUT_MIN_(WIDTH|HEIGHT) hehave, and
when I turned this off in the contents (Horiz.  frame) I was getting
this too.  Only if One child and the the parent use LAYOUT_FILL will
that child be stretched to fill the parent.  Is that about right?

If so this feels rather like Tk: I remember having to use fill
rather a lot when I used that.

        Hugh
>
>

Re: [Fxruby-users] layout probs with TreeList.

[Lyle J. <jl...@cf...>]

Hugh Sasse Staff Elec Eng wrote:

> Oh, so that is an inherited attribute then, as it is not listed....

Yes.

> Yes, that did the job.

Good.

> I have since tried removing the layout hints from contents (the
> horizontal frame, and found that I get the uncorrected behaviour.

Right.

> I see from the FOX Docs that these FILL_ hints cause this hehaviour:
> "If more than one child with this option is placed side by side, the
> available space will be subdivided proportionally to their default
> size."
> So when I had not set the FILL_X before, I was effectively getting
> this anyway because of how LAYOUT_MIN_(WIDTH|HEIGHT) behave, and
> when I turned this off in the contents (Horiz.  frame) I was getting
> this too.  Only if One child and the the parent use LAYOUT_FILL will
> that child be stretched to fill the parent.  Is that about right?

Ummm, you lost me somewhere in there ;)

When you don't specify, say, LAYOUT_FILL_X, the widget will usually just 
take up as much space as it needs (a.k.a. its "default" width). I don't 
think LAYOUT_FILL_* is ever a default behavior, though.

> If so this feels rather like Tk: I remember having to use fill
> rather a lot when I used that.

Yes, most modern GUI toolkits' layout managers owe a lot of their 
heritage to Tk's Packer layout manager. I know that some of GTK's layout 
managers are based on this concept, and I'm guessing that Qt's are as well.

Re: [Fxruby-users] layout probs with TreeList.

[Hugh S. S. E. E. <hg...@dm...>]

On Wed, 16 Jul 2003, Lyle Johnson wrote:

> Hugh Sasse Staff Elec Eng wrote:
>
> > Oh, so that is an inherited attribute then, as it is not listed....
>
> Yes.
>
> > Yes, that did the job.
>
> Good.
>
> > I have since tried removing the layout hints from contents (the
> > horizontal frame, and found that I get the uncorrected behaviour.
>
> Right.
>
> > I see from the FOX Docs that these FILL_ hints cause this hehaviour:
> > "If more than one child with this option is placed side by side, the
> > available space will be subdivided proportionally to their default
> > size."
> > So when I had not set the FILL_X before, I was effectively getting
> > this anyway because of how LAYOUT_MIN_(WIDTH|HEIGHT) behave, and
> > when I turned this off in the contents (Horiz.  frame) I was getting
> > this too.  Only if One child and the the parent use LAYOUT_FILL will
> > that child be stretched to fill the parent.  Is that about right?
>
> Ummm, you lost me somewhere in there ;)
>
> When you don't specify, say, LAYOUT_FILL_X, the widget will usually just
> take up as much space as it needs (a.k.a. its "default" width). I don't
> think LAYOUT_FILL_* is ever a default behavior, though.

I think LAYOUT_MIN_WIDTH and LAYOUT_MIN_HEIGHT are the defaults for
the child widgets.  So the parent would, by default, allocate
according to that space.  If two children in the same (X|Y) have
LAYOUT_FILL_(X|Y) they conflict, so the parent must still use the
defaults.  If only one child has LAYOUT_FILL_(X|Y) then the parent
must have it too for it to take notice.  Is that right?
It is the parent's need for this hint that is difficult for me: I
thought it got the hints from its children...


> > If so this feels rather like Tk: I remember having to use fill
> > rather a lot when I used that.
>
> Yes, most modern GUI toolkits' layout managers owe a lot of their
> heritage to Tk's Packer layout manager. I know that some of GTK's layout
> managers are based on this concept, and I'm guessing that Qt's are as well.

Yes, I have got this impression, too. But there is a surprising
amount of criticism of Tk, particularly about it being "old
fashioned", about the place.
>
>
        Hugh