[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fvwm
Subject:    Re: FVWM: FvwmIconMan questions
From:       Ryan Daly <daly () ctcnet ! net>
Date:       2007-10-27 14:35:40
Message-ID: 1193495740.3419.7.camel () riddler
[Download RAW message or body]

> On 16 Jan 2003 09:05:19 -0500, Maciej Kalisiak wrote:
> > On Thu, Jan 16, 2003 at 02:43:41AM -0500, Mikhael Goikhman wrote:
> > > On 15 Jan 2003 21:30:14 -0500, Maciej Kalisiak wrote:
> > > > 
> > > > 1) Is there a way to control the thickness of the relief for the buttons in
> > > >    FvwmIconMan? (i.e., the border that shows up around each button when 
> > > >    (Plain|Focus|...)Button style is anything other than "flat")
> > > 
> > > Since such option does not appear anywhere in the FvwmIconMan man page,
> > > it is not configurable as of now.
> > 
> > Is this feature planned?  If not, are you accepting patches for it?  (I
> > imagine it's not very hard to do, so I might give it a stab)
> 
> Not planned, but feel free to submit patches. Although at this point you
> should convince developers that your changes are needed for 2.6.0 and do
> the testing thoroughly.
> 
> > > > 2) Is there a way to have FvwmIconMan resize dynamically?  I have one
> > > >    swallowed inside FvwmButtons, but it doesn't want to expand to fill
> > > >    the space provided therein.
> > > 
> > > If I understand you correctly, you don't like that FvwmButtons is resized
> > > together with FvwmIconMan.
> > 
> > Not quite.  I don't like that, when I resize FvwmButtons, FvwmIconMan does not
> > adjust its overall size to fit within the Swallow area provided to it by
> > FvwmButtons.  Ideally I would like the FvwmIconMan to vary the size of *its*
> > buttons, using the specified a desired ManagerGeometry, so that everything fits
> > within the designated FvwmButtons space.
> > 
> > BTW, I'm using FVWM 2.5.5.
> > 
> > > As for FvwmIconMan, its geometry is configured using ManagerGeometry and
> > > ButtonGeometry, but they may be ignored if conflict with the reallity.
> > > For example if you specify "ManagerGeometry 2x5" this is equivalent to
> > > "ManagerGeometry 2x0" if no ButtonGeometry is specified, but it may also
> > > be equivalent to "0x5" if there is a place for 5 rows accourding to
> > > ButtonGeometry and the actual FvwmIconMan size. Note that this is only
> > > my experience, I have no time now to learn the source code.
> > 
> > Right.  I'm looking instead for why "actual FvwmIconMan's size" is not
> > adjusting to reflect the space provided within FvwmButtons.
> 
> I suppose this is because the button size (at least height) is fixed and
> is not changed dynamically. If you think that there is a better behaviour
> when no ButtonGeometry is configured, you may patch it. This could be done
> as a new option, because the current behaviour is useful.
> 
> I think that in any case (fixed button size or not) FvwmIconMan should
> define size hints, so there would be no gaps, at least when not swallowed.

What is the best way to handle this situation?

I'm looking for a way to have FvwmIconMan swallowed by FvwmButtons, but
am having trouble when I surpass the amount of space available for
FvwmIconMan (I start having buttons creep outside the space available
instead of FvwmIconMan scrunching them into the space available).


[prev in list] [next in list] [prev in thread] [next in thread]