Subject: FVWM: FvwmTabs v1.3

From: SCoTT SMeDLeY <[email-masked]>
Date: Thu, 16 Jan 2003 10:54:08 +1100

Hi all,

FvwmTabs v1.3 allows you to resize an app in a tab simply by resizing
the FvwmTabs window when that app/tab is displayed.

Also added 'Multi-Add' & 'Release All (Iconify)' features.

http://users.tpg.com.au/users/scottie7/fvwmtabs.html

SCoTT. :)
-- 
[email-masked]
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: parv <[email-masked]>
Date: Wed, 15 Jan 2003 21:47:05 -0500

in message <[email-masked]>,
wrote SCoTT SMeDLeY thusly...
> Hi all,

hi scott.

> FvwmTabs v1.3 allows you to resize an app in a tab simply by
> resizing the FvwmTabs window when that app/tab is displayed.
> 

i tried it for the first time a few minutes ago.  resizing is quite
odd in the sense i would have expected the -Tabs (FvwmTabs) window
size to remain the same when switching from one sized window to
another.

-Tabs would have added empty space when switching to a smaller sized
window (from a larger one).  it follows that -Tabs window size would
be the composed of largest of widths & largest of heights to reduce
the flashing.

running applications in ion in vnc in fvwm -- at the costs (1) of
two sets of key bindings, (2) difficult job of sharing copy buffer
among applications, and (3) avoiding xv (in ion) -- is just as
easy or painful as far as concept of running application in tabs go.

  - parv

--

---

From: SCoTT SMeDLeY <[email-masked]>
Date: Thu, 16 Jan 2003 15:09:54 +1100

Hi Parv,

: resizing is quite
: odd in the sense i would have expected the -Tabs (FvwmTabs) window
: size to remain the same when switching from one sized window to
: another.

Mmmmm, well I deliberately DIDN'T want this behaviour - I don't want
my xterms to be as big as my Mozilla window! (or padded/buffered with
space the size of Mozilla windows.)

You could probably get very close to the behaviour you want by
removing this line of code:

$tabWin{$tId}{toplevel}->geometry("");

in the showTab() function.

I'll make it a configuration option once FVWM::Module is able to
handle user-specific configuration options.

SCoTT. :)

---

From: parv <[email-masked]>
Date: Thu, 16 Jan 2003 02:08:34 -0500

in message <[email-masked]>,
wrote SCoTT SMeDLeY thusly...
> Mmmmm, well I deliberately DIDN'T want this behaviour -

yes, i forgot about that as it was mentioned indirectly on your
page.

> I don't want my xterms to be as big as my Mozilla window! (or
> padded/buffered with space the size of Mozilla windows.)

first time i opened an xterm in ion, above behaviour was quite
a shock from which i recovered soon.  :)

> in the showTab() function.

thanks, i will try that.

> handle user-specific configuration options.

super!

  - parv

--

---

From: Glen Lee Edwards <[email-masked]>
Date: Fri, 17 Jan 2003 01:24:55 -0600

> http://users.tpg.com.au/users/scottie7/fvwmtabs.html

I like the general concept of FvwmTabs.  I'm using Fvwm-2.5.5 and have 
noticed that FvwmTabs doesn't have a title bar, and is sticky - no 
matter what desktop or page I go to it's there.  Is there a way to make 
it work like regular Fvwm windows?  I don't want it to replace my 
existing setup, but rather I'd like to use it to organize projects into 
FvwmTabs.  For example, if I'm writing a PERL cgi script, I'd like to 
be able to place Emacs, Konsole, and a web browser that I'm using for 
the project into one tab, yet still be able to change desktops to 
access the other apps that are active but unrelated to the project.

Regards,

Glen

---

From: Scott Smedley <[email-masked]>
Date: Sat, 18 Jan 2003 10:37:59 +1100

Hi Glen,

> it work like regular Fvwm windows?

Sounds like an Fvwm config problem as I have FvwmTabs working exactly
as you desire. Try something like:

Style FvwmTabs NoSticky, Title

in your .fvwm2rc file.

SCoTT. :)

---

From: Dan Espen <[email-masked]>
Date: Fri, 17 Jan 2003 18:49:52 -0500

> Style FvwmTabs NoSticky, Title

Most likely, there's a:

Style Fvwm* Sticky, NoTitle

arlready in the .fvwm2rc.
Make sure to add the

after it.

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Glen Lee Edwards <[email-masked]>
Date: Fri, 17 Jan 2003 21:44:41 -0600

> arlready in the .fvwm2rc.

That is the problem.

> Style FvwmTabs NoSticky, Title

That didn't fix it.  It's not responding to any configuration options
I'm putting on the line:

Style "FvwmTabs" etc

For example,

Style "FvwmTabs" NoSticky, Title, BorderWidth 10

makes no difference.  It's still Sticky, no Title, with a BorderWidth
of 2.  When I removed the 'Style "Fvwm*" Sticky, NoTitle' line it and
all the other Fvwm Modules had a Title and weren't Sticky.  I seem to be
unable to find a way to individually configure FvwmTabs.  It I need to
I can leave out the 'Style "Fvwm*"...' line and add it individually to
each module, but that wouldn't be my first choice.

Glen

---

From: parv <[email-masked]>
Date: Fri, 17 Jan 2003 23:30:54 -0500

in message <[email-masked]>, wrote Glen Lee Edwards
thusly...
> makes no difference.  It's still Sticky, no Title, with
> a BorderWidth of 2.  When I removed the 'Style "Fvwm*" Sticky,
> NoTitle' line it and all the other Fvwm Modules had a Title and
> weren't Sticky.  I seem to be unable to find a way to individually
> configure FvwmTabs.

you need to mind the order of Style:  first write the default
behaviour then change it for special cases, assuming number of
special cases would be lower than the cases covered by default
behaviour.  otherwise, there won't be any need or reason for
"default".

below is what i have (fvwm 2.5.5) which defines the default behaviour
for all Fvwm* modules w/ changes for particular ones...

  Style  Fvwm*         Sticky , NoHandles , WindowListSkip, !Borders , SloppyFocus
  Style  FvwmCo*       Slippery
  Style  FvwmIdent*    Layer 6 , WindowListHit , NoButton 1 , NoButton 2 , NoButton 4 , Title
  Style  FvwmPager*    Layer 6 , NoButton 1 , NoButton 2 , TitleAtRight
  Style  FvwmButton*   Layer 6 , NoButton 1 , NoButton 2 , TitleAtRight

  - parv

--

---

From: Glen Lee Edwards <[email-masked]>
Date: Fri, 17 Jan 2003 22:43:12 -0600

>   Style  FvwmButton*   Layer 6 , NoButton 1 , NoButton 2 , TitleAtRight

Parv,

I am set up that way:

# Styles for various Fvwm modules:
# Style "Fvwm*"	NoTitle,  Sticky, WindowListSkip
Style "Fvwm*"	BorderWidth 2
Style "FvwmPager"	StaysOnTop, NoTitle,  Sticky, WindowListSkip
Style "FvwmBanner"	StaysOnTop, FocusFollowsMouse, NoTitle,  Sticky, WindowListSkip
Style "FvwmButtons"	WindowListSkip,MouseFocus,NoIcon, NoTitle,  Sticky, WindowListSkip
Style "FvwmButtonsPanel"       	NoTitle, FocusFollowsMouse, NoTitle,  Sticky, WindowListSkip

I commented out the first Style line after my last letter.  I'm able to get FvwmTabs to work
the way I want as long as I don't have a default Fvwm Module setting.  It doesn't seem to
recognize FvwmTabs as the module (window?) name. I removed the 'Style "FvwmTabs"...' line
because it isn't doing anything.

Glen

---

From: Anssi Saari <[email-masked]>
Date: Sat, 18 Jan 2003 09:17:47 +0200

> because it isn't doing anything.

I have a similar problem, but a little weirder: I get a  message saying
NoSticky isn't a valid Style option?!?

I tried 

Style FvwmTabs    Title, NoSticky

as the last line of my .fvwm2rc, but I get a message 

[FVWM][CMD_Style]: <<ERROR>> Bad style option:  NoSticky

with restart and FvwmTabs is sticky and has no title.

I've also tried 

Style FvwmTabs    Title

but FvwmTabs still doesn't have a title. I do have these lines

Style Fvwm*       NoTitle,  Sticky, WindowListSkip
Style Fvwm*       BorderWidth 2, CirculateSkipIcon, CirculateSkip

earlier in my .fvwm2rc. If I remove the upper, then Title and NoSticky will
work for FvwmTabs. 

Now, it gets weirder. If I use Style FvwmTabs* NoSticky, Title I get a title
but FvwmTabs is still Sticky... 

Running Fvwm 2.5.4 on FreeBSD 4.7-STABLE.

---

From: Scott Smedley <[email-masked]>
Date: Sat, 18 Jan 2003 18:34:23 +1100

Hi Glen,

> It doesn't seem to

Quite right. By default perl/Tk sets the class/resource name to 'Toplevel'.

To fix, replace the Toplevel() function call in createNewTabber()
with this line of code:

my $tl = $TOP->Toplevel(Name => 'FvwmTabs', -class => 'FvwmTabs', -title => $title);

& all should be fine.

SCoTT. :)

---

From: parv <[email-masked]>
Date: Sat, 18 Jan 2003 11:48:27 -0500

> http://users.tpg.com.au/users/scottie7/fvwmtabs.html

could it be possible to add an option of releasing a single client?

i noticed that sometimes after restarting fvwm, -Tabs doesn't
release all the clients; it takes some of the clients down with it.
aterm is killed, but netscape or mozilla are no where to be seen
still present in "ps".  behaviour is different depending upon
whether -Tabs was started via "StartFunction"; i will narrow it
down.

as a side note, why are you calling the non referenced named subs
via "&", e.g. "&showTab($tId, $tabNo);"?  won't the named subs will
just work w/o "&",  am i missing something?

  - parv

--

---

From: Glen Lee Edwards <[email-masked]>
Date: Sat, 18 Jan 2003 12:00:30 -0600

> my $tl = $TOP->Toplevel(Name => 'FvwmTabs', -class => 'FvwmTabs', -title => $title);

Scott,

Bingo.  I now have a Title Bar. However, NoSticky isn't working - it's still sticky.
Glancing through the man pages it appears that NoSticky only works in a WindowList
context.  That's not a major problem.  I'll just remove Sticky as a default Fvwm
Module behavior and set it on an individual basis.

A couple of questions:

1) When capturing web browsers, I can't type a URL into the location field.
    Is it supposed to behave like that?  Is there a fix?
2) Is there a way to program shortcut keys so I can Alt-left or Alt-right
    between tabs instead of using the mouse?

Great module.  Thanks for writing it!

Glen

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 18 Jan 2003 18:07:05 +0000

> Style FvwmTabs NoSticky, Title

It should be either "Slippery" or "!Sticky", but not "NoSticky".
This is an answer to 2 other messages in this thread.

Regards,
Mikhael.

---

From: parv <[email-masked]>
Date: Sat, 18 Jan 2003 17:40:46 -0500

in message <[email-masked]>, wrote
Scott Smedley thusly...
>
> Hi Glen,
>
> > It doesn't seem to recognize FvwmTabs as the module (window?)
> > name. I removed the 'Style "FvwmTabs"...' line because it isn't
> > doing anything.
>

hunh. it's odd that fvwm (2.5.5) didn't have any problems applying
the Style to FvwmTab* by 'Name' only.  i don't have anything
specific which would tell fvwm to use name instead of class or
resource (from what i can tell).  then again man page does say...

  Style stylename options
        ...
        stylename  can be a window's name, class, or
                                     ^ ^
                                     ^ ^
        resource string.  It may contain  the  wild-
        cards  '*' and '?', which are matched in the
        usual  Unix  filename  manner.    They   are
        searched  in the reverse order stated.  When
        two conflicting styles  apply  to  the  same
        window,  the  style  that  was  changed last
        wins.

...so unless, there are some bug(s) in some fvwm version(s), style
should have worked for glenn as it is w/o changes to -Tabs.  btw,
i noticed that he was using '"FvwmTabs"' & i was 'FvwmTabs*'; does
* make the difference?

  - parv

--

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 18 Jan 2003 22:54:01 +0000

> i noticed that he was using '"FvwmTabs"' & i was 'FvwmTabs*'; does

Of course if the window name is "FvwmTabs [0]" the asterisk makes a
difference in the non-patched version.

Regards,
Mikhael.

---

From: Scott Smedley <[email-masked]>
Date: Sun, 19 Jan 2003 12:51:29 +1100

Hi Parv,

> could it be possible to add an option of releasing a single client?

Clicking the middle mouse button (2) on a tab will release the program
for that tab.

> release all the clients; it takes some of the clients down with it.

Hmmm, well that is a bug. I think I know what might be causing it.
I'll investigate & let you know.

> just work w/o "&",  am i missing something?

Both are valid Perl syntax. The '&' just means the subroutine
doesn't have to be declared before it is used. I probably don't need
it, but using '&' everywhere means I don't even have to worry about
whether I should use it or not.

SCoTT. :)

---

From: parv <[email-masked]>
Date: Sat, 18 Jan 2003 23:26:52 -0500

in message <[email-masked]>,
wrote Mikhael Goikhman thusly...
> difference in the non-patched version.

oops(?) i should have noticed that, didn't.  now i will go in
a corner w/ back facing everybody else for a moment.

  - parv

--

---

From: Scott Smedley <[email-masked]>
Date: Sun, 19 Jan 2003 16:28:55 +1100

Hi Glen,

>     Is it supposed to behave like that? Is there a fix?

Not yet - FvwmTabs doesn't do any focusing. I had a quick go &
implementing it, but I'm having trouble. Hopefully I'll nut it out
soon.

>     between tabs instead of using the mouse?

Not yet - one implementation (& the one I'll likely take) will be to
intercept the key presses for left/right in Fvwm & pass them through to
FvwmTabs using the SendToModule command.

Relatively trivial, but I'm distracted with the focusing problem at
the moment. :)

For a list of some other unimplemented features, see the TODO list
at the bottom of the FvwmTabs source file.

SCoTT. :)

---

From: parv <[email-masked]>
Date: Sun, 19 Jan 2003 15:59:18 -0500

in message <[email-masked]>,
wrote Scott Smedley thusly...
> Hi Parv,

helloo,

> Clicking the middle mouse button (2) on a tab will release the
> program for that tab.

ah, yes. yes, it does.

is this somehow dependent on the number of the current tab such that
it couldn't be part of the menu (popped up by 3d button mouse click
on "FvwmTabs")?

> > via "&", e.g. "&showTab($tId, $tabNo);"?  won't the named subs
> > will just work w/o "&",  am i missing something?
> 
> doesn't have to be declared before it is used. I probably don't
> need it, but using '&' everywhere means I don't even have to worry
> about whether I should use it or not.

unless you are using non-parenthesis version of subs, it really does
not matter where you declare/define subs.  if you do keep '&', then
you are wasting your efforts by defining prototypes as prototype
checking will be ignored.

perlsub(1) SYNOPSIS says it quite succinctly & clearly...

  To call subroutines:

     NAME(LIST);    # & is optional with parentheses.
     NAME LIST;     # Parentheses optional if predeclared/imported.
     &NAME(LIST);   # Circumvent prototypes.
     &NAME;         # Makes current @_ visible to called subroutine.

  - parv

--

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 19 Jan 2003 23:11:22 +0000

On 19 Jan 2003 15:59:18 -0500, parv wrote:
> not matter where you declare/define subs.

No, this is incorrect. Starting with perl-5.6.0, if you define a function
with parameters (and for the fvwm's perllib such definition is a rule),
the function should be declared before its first usage, otherwise you get
a warning.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 19 Jan 2003 23:21:56 +0000

> the function should be declared before its first usage, otherwise you get

This is quite an off topic, but I forgot to add. I didn't mean '&' should
be used everywhere, I would prefer a predeclaration. There is though one
case when I prefer the '&' syntax - recursive functions.

Regards,
Mikhael.

---

From: parv <[email-masked]>
Date: Sun, 19 Jan 2003 20:39:18 -0500

in message <[email-masked]>,
wrote Mikhael Goikhman thusly...
> > the function should be declared before its first usage,
> > otherwise you get a warning.

oops, yes you are correct.

let me elaborate on ampersand usage in function calls...

perl really doesn't have parameters -- unlike C++, C, Rexx, etc. --
just the TYPE CHECKING of arguments as long as it is NOT BYPASSED.
as soon as function name (during calling it) is prefixed w/ '&', the
type checking just becomes useless decoration.  observe...

  #!perl -w

  use strict;

  #  function accepts only one scalar argument
  #  unless name is preceded by '&'
  sub print_one($)
  { print $_[0] ||  'undef'; }

  #  normal call, no surprise
  print_one('blah');

  #  no parameter is passed, yet perl doesn't complain
  &print_one();

  #  no parameter is passed, program will abort
  #print_one();

  #  array will be passed but scalar is expected
  #  since prototype checking is bypassed, doesn't matter
  my @array = (2,3);
  &print_one(@array);

  #  another blow up
  print_one(@array);

...so if somebody happen to omit an argument, pass wrong kind or
number of argument, no errors will be generated if function is
called w/ '&'.  i suppose one would have been expecting errors in
such cases (unless bypassing the prototype check was intentional, of
course).

curious... could it be that perl prototypes are being used for the
wrong kind of reasons (as fvwm perllib requirement)?

> I didn't mean '&' should be used everywhere, I would prefer
> a predeclaration. There is though one case when I prefer the '&'
> syntax - recursive functions.

why for recursive functions?  also see above.

  - parv

--

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 20 Jan 2003 10:56:33 +0000

> wrong kind of reasons (as fvwm perllib requirement)?

Usually it is enough for me to see the method prototypes to understand
what it does, for example "sub name ($;$)" means object method that is
setter/getter. Functions without prototypes require code examination to be
understood. Since prototypes are unrelable and the function should check
its parameters itself anyway, the main usage is readability.

> why for recursive functions?  also see above.

If you think about a function as a small solid unit that either works or
does not work, it makes sence to predeclare it for external usage and has
no much justification to predeclare it for mere internal usage. Anyway,
since prototypes are ignored for method calls the whole discussion is more
related to scripts/modules than to perllib classes.

Regards,
Mikhael.