Subject: Re: WindowStyle in functions

From: Dominik Vogt <[email-masked]>
Date: Fri, 1 Aug 2003 09:39:28 +0200

On Thu, Jul 31, 2003 at 11:45:34PM +0200, Grzegorz wrote:
> Dominik Vogt nawypisowywa?(a):
> >> As an end-user (not fvwm-hacker, so I'm not "tainted") I can say that
> >> the biggest "misdesign" in current FVWM code is the scripting engine. It
> >> has this "I'm a never ending hack" look&feel. A true overflowing
> >> bucket'o'patches.
> > 
> > Sure, you must know it.  I guess you have spent weeks studying it.
> 
> That's the point. I don't study it - I just came, compiled it and
> started to use it.
> 
> > Apart from its lousy speed and some problems with quoting, the
> > scripting engine isn't *that* bad.
> 
> I wanted a "QuakeTerm" once (a xterm window sliding from top of the
> screen and hiding) - a toggle function actually, very simple, move the
> window from desk 666 to current, bring it to the front and unshade. Then
> shade it and move it back to 666. In the end I needed to split the code
> into 3 functions just to keep it sane with all those Cond and CondCases.

*Shrug*  Complicated tasks should be split into small parts
anyway.  But I guess it can be done in two lines in sawfish-lisp,
right?

> Quoting is very bad, those ugly hacks with PipeRead just to get
> something expanded right.

Well, *actually*, it is documented precisely in the man page.
Reading carefully should allow you write properly quoted functions
without trying.  Don't get me wrong - I'm not defending the
quoting.  In the best case one could call it odd.  But I find it
somewhat odd that you do not complain that you have to learn lisp
for sawfish, but on the other hand do not care to look at the man
page to learn the fvwm command language.

By the way, this is the main strength of the "language":  you can
start writing your own config snippets right away by looking at
the examples in your config file.  That will not take the beginner
very far, but it helps to overcome one's inhibitions.

> But the real problems are (IMO) the way to many
> commands, functions which can't really return useful results, no
> internal data structures (only env. vars).
> 
> You say it's not bad because you have been sitting in its code for such
> a long time you've got the Blessings of Immunity :)

Say what you want, but *please* stop insulting me without reading
the mailing list archives first.  I have criticised the command
language more than anybody else in the past.

> >> Employing a true scripting language (python maybe?)
> >> would make fvwm much easier to understand and script.
> > 
> > Actually, it would make it much harder to script for the
> > non-(insert scripting language of your choice)-junkie.
> 
> And right now it's hard to script for _everyone_ but fvwm-junkies.

I strongly disagree.  It is quite easy to write small functions like

  AddToFunc foo
  + I MoveToDesk
  + I MoveToPage
  + I WindowShade off
  + I Iconify off
  + I Raise

Of course, writing things like the "Quake" console is a difficult
task in any language.  It may vary with the given syntax, but it's
an impossible task for most normal users.

> It's
> unlike any other language. Choosing a widely-used scripting language
> makes it _easier_ for some people, but not harder for anybody else. Do
> you think that if fvwm would use perl natively I would have bigger
> trouble learning it (I'm no perl junkie, so according to your words
> switching to Perl would mean trouble for me)?
> 
> I mentioned Python because it has a reputation for an "easy to learn
> language" with clear and well-thought syntax. If you don't know it, you
> have to learn it. If its fvwm or python, doesn't matter. With Python (or
> perl, or scheme, or lisp, or ruby) there is simply the possibility that
> some users will already know it and that there will be good books on the
> topic.
> 
> >> It would also be a great opportunity to reduce the number of commands
> >> and clean it up.
> > 
> > Funny, a couple of lines further up you complain about exactly this:
> > that I want to remove superfluous commands like WindowStyle.
> 
> What I was thinking about: if fvwm had true programming abilities, you
> know, loops, data structures, conditional blocks etc. you could
> represent windows, keybindings and the likes as ordered structures of
> properties (or groups of variables, if you like). A window could be
> represented by an object with a set of keys (properties). You could
> alter these properties by assigning values to them. Like change the name
> of a decor assigned to a window by changing a "decor" property.  Or
> check if a window is maximized by checking the value of the "maximized"
> key.
> 
> Keybindings could be represented as a table, with pairs of
> key-context-function. This table could be searched or altered just as
> you do it with variables - by using simple assignements.  Styles could
> be represented by a list similar to the "managed window list", with the
> twist that windows in the "styles" list would serve as masks altering
> the properties of matching windows. It's hard for me to explain, I'm no
> programmer. But maybe you understand what I mean.
> 
> The simplicity lies in the reduced amount of commands. You no longer
> need the Style command - you just change a group of objects, defining
> their properties. You don't need the WindowStyle command - you operate
> directly on the list of managed windows. Arrange the internals in a neat
> and clean way, show them through an API to the user and that's all.
> Instead of a "All" or "Any" command the user could loop over the list of
> managed windows and test some keys. Deleting styles would be possible.
> A couple of lines of code and you could remove all defined bindings for
> the "R" context. Silly examples, but they show how flexible it is.
> 
> And adding new features means mostly "adding new properties" to objects.
> Once you've done it, there's no more work. For instance now in fvwm you
> can test only certain conditions, those that were predestined by the
> coders. For instance it is impossible to select all windows of the same
> decor or all of a certain size. Because no-one thought that it could be
> usefull and added a link between such properties and arguments to
> Current/All/Any.  Now fvwm is doing the "a function for every occasion"
> thing. That's nice, but for simple programs and spawns problems as the
> whole code gets overly complex and hard to understand in its
> interdependencies.
> 
> If, however, you would choose to simply show all the props of objects to
> the user, those functions could be implemented as scripting functions
> - easy to redefine or customize. Adding a new property to a window
> wouldn't require changing anything else - for instance the ability to
> have titles at left implies the existence of a property
> "title-placement".  And if it exists it could get values assigned or
> tested in conditionals.  So you don't need to add new Style options
> "TitleAtLeft, ..." or new Conditions to reflect the changes.
> 
> That's what I was really thinking about. Anybody that ever Sawfish-ed
> will know what I mean. I'm just trying to show an approach that could
> really simplify things in fvwm. Of course it comes with high initial
> costs - dumping the current model and quite an amount of code, backwards
> compatibility gets lost, but it's more, how do you say it, "ready for
> what the future brings". Sorry for making it that long and boring.

All these extensions can be done without fundamental changes to
the xommand language.  I already proposed most of this and much
more last year, but apparently nobody is interested in it.

> >> scripting Sawfish is much easier, even if their chosen language is
> >> a lisp variation (not the best choice for a WM, but still better than
> >> fvwm scripts).
> > 
> > I disagree. Lisp allows only hardcore programmers to do anything.
> 
> I was able write some simple extensions to Sawfish on my own (random
> background changer, desk title popup after desktop switch, center window
> on screen, functions like FvwmBacker, popup-clock-and-date etc.) but
> I don't consider myself a hardcore programmer.

I can already see my 66 year old mother writing lisp functions ...

> Sawfish comes with good
> Info documentation, even regarding the basics of sawfish-lisp (no wonder
> since it's a dialect), so I quickly knew how to write simple loops,
> conditional blocks or manipulate lists. :) There are things in fvwm that
> are IMO way more difficult to understand than the basics of Lisp, like
> the ItemFormat option of MenuStyle.

Bye

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

---

From: Grzegorz <[email-masked]>
Date: Fri, 1 Aug 2003 23:31:38 +0200

Dan Espen nawypisowywał(a):
>> the biggest "misdesign" in current FVWM code is the scripting engine. =
>> It
> Please, constructive comments only.

There was some constructive stuff further down (with an alternative
"described" - I guess only a ready-to-apply patch could be more
constructive).

>> would make fvwm much easier to understand and script. It would also be
>> a great opportunity to reduce the number of commands and clean it up.
> 
> Feel free to use any language you want.
> 
> FvwmCPP
> FvwmM4
> FvwmPerl
> PipeRead
> FvwmCommand

cpp and m4 are macro expanders, not real scripting languages.
FvwmCommand, PipeRead and FvwmPerl are nice extensions, but only
extensions, FvwmPerl isn't really easier to use, as it has a visible
line separating "native perl" from "native fvwm" (yes, I've tried
writing perl extensions and I noticed that it was much like calling
FvwmCommand, only that you did it in a perl script).
PipeRead/FvwmCommand has huge overhead problems (running a external
command isn't really efficient).
 
> Except when playing pysol, I don't have the python interpreter in
> memory. I wouldn't be happy with a window manager that pulled an
> interpreter into memory.

It's just a library. Makes some of fvwm code obsolete, so the costs are
reduced a bit.

But that isn't that important. If fvwm would be able to do things that
you can do in Python (or any other popular language) just as easily,
I would be very satisfied. Pulling a external library with an
interpreter is only a "possible solution". So is "rewriting the engine".
But I believe that the second wouldn't give smaller code and would
probably have more bugs (shorter devel-debug-cycle compared to
a well-tested libperl or libpython, or lib<whatever>).

Fvwm isn't really *that* good at saving memory[1], so I don't think it
would brake any "fundamental fvwm rule" here.

[1] - take the modules for instance. If saving ram would be such a high
priority, then it should be possible to load FvwmButtons and then use it
to create more than one container, perhaps in different areas of the
screen. But no, if you want two containers you need to load two copies
of FvwmButtons, even if 80% of that code could probably be shared (only
config-related data is different). And fvwm modules are quite big
already.

-- 
\hoppke
(Grzegorz Niewęgłowski)
http://lubuska.zapto.org/~hoppke/

---

From: Grzegorz <[email-masked]>
Date: Fri, 1 Aug 2003 22:57:08 +0200

Dominik Vogt wrote:
> anyway.

"if..then..else" constructions are not what you could call
"complicated". Well, maybe in fvwm they are.

> Well, *actually*, it is documented precisely in the man page.

It's not about the lack (or presence) of documentation. Pulling PipeRead
with a "echo" command just to expand some variables isn't what I would
call "nice".  So it's fully documented. Do man pages change anything
about it being inconvenient or not well-thought?

> But I find it somewhat odd that you do not complain that you have to
> learn lisp for sawfish, but on the other hand do not care to look at
> the man page to learn the fvwm command language.

I never said that I'm against reading docs. I just found lisp easier,
clearer, more coherent than what fvwm has to offer.

> start writing your own config snippets right away by looking at the
> examples in your config file.  That will not take the beginner very
> far, but it helps to overcome one's inhibitions.

That's true for any given higher-level language. Not only fvwm's
configs.

>> You say it's not bad because you have been sitting in its code for
>> such a long time you've got the Blessings of Immunity :)
> 
> Say what you want, but *please* stop insulting me

Did I insult you? In what way?

a. You said it "isn't that bad"
b. You are sitting in the code for a long time now
c. Your perceive fvwm mainly from the "developer" point of view.  Proof:
   I spoke about it being bad, and you replied "I'm sure you analysed
   the code" - but not everybody reads the code. I can tell if something
   is nice or ugly by using it. I don't care if it's easy to read or if
   it's variables are named after a pattern. I just use it. That's what
   WM's are for - using. Not analysing the code. Yes, not only fervent
   programmers use fvwm. Us, stupid[1] users do it too.

So where's the insult?

> I strongly disagree.  It is quite easy to write small functions like

It differs from most languages and is more complicated than batch
scripts.

a. there's this weird "+ I "

b. you can glue code to the function after invoking some different
commands (I know it's a feature, but still - it's different from most
languages with functions and it complicates things)

c. You know how my first errors looked like?

+I maximize

It just didn't work. No error message, nothing. I had to understand what
was wrong by myself, 'cause the manual obviously considers it as
"obvious".

> an impossible task for most normal users.

[1] - now I could say that I feel insulted. I consider myself a normal
user. And you say that most people with my knowledge of computers
wouldn't be able to write more complex(?) fvwm functions? Just how
stupid you think normal users are?

> more last year, but apparently nobody is interested in it.

Alright, how do you picture deleting all bindings for the "I" context?
Add twenty new commands, like
DeleteBindingsInContext(contex name),
DeleteBindingsToFunction(function name),
...
?

Sure, you can do everything that I mentioned if you add new functions.
But it's like constructing a cell phone with buttons for every entry in
it's address book. Is that really "user friendly"? That's good when
the address book has 10 entries. But when it has more than 100 of them
it's time to think of a new interface for the user.

>> background changer, desk title popup after desktop switch, center
>> window on screen, functions like FvwmBacker, popup-clock-and-date
>> etc.) but I don't consider myself a hardcore programmer.
> 

Sorry, I don't know the lady so I'll pass on that one.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 4 Aug 2003 10:09:49 +0200

On Fri, Aug 01, 2003 at 11:31:38PM +0200, Grzegorz wrote:
[snip]
> config-related data is different).

What is the problem with starting the same module twice?  All you
waste is a few hundred bytes of dynamic memory that could be
shared by different containers, namely the memory used to store
the constant parts of the configuration.  And of course the two
additional pipes and the process structure in the kernel.  The
executable itself is loaded into RAM only once.  Any decent kernel
is clever enough not to load multiple copies of the same
write-only data.

> And fvwm modules are quite big already.

Try

  $ make install-strip

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 4 Aug 2003 10:28:06 +0200

> clearer, more coherent than what fvwm has to offer.

I guess many people disagree with this opinion.  The main
difference is that to learn lisp, you have to learn programming.
This requires a lot of dedication.  Many people are simply not
interested in this deep level of understanding.

> That's true for any given higher-level language. Not only fvwm's

I don't know where you get that idea from.  It's certainly not
true for PERL, Python or shells.  They all require sound knowledge
in programming.

>    programmers use fvwm. Us, stupid[1] users do it too.

The insult is that you claim that I am unable to consider what
users want (hint:  read mailing list archive).  You ranted about
the scripting *engine*.  Only in the follow up mail you made it
clear that you were talking about its *interface*, not the engine
itself.  So don't condemn me for replying on the same level.

  ----------------------- foo --------------------------
  MoveToDesk
  MoveToPage
  WindowShade off
  Iconify off
  Raise
  ------------------------------------------------------

  Read foo

> a. there's this weird "+ I "

Agreed.

> languages with functions and it complicates things)

And it is very, very flexible and a *great* debugging help.

> was wrong by myself, 'cause the manual obviously considers it as

Well, that is not part of the design but simply a bug (in my
eyes).  Parsing of the "+" command is not good.

> user.

Then our image of a "normal user" differs very much.  In my eyes,
the typical computer user:

 - Will not learn a programming language to configure a program
 - Hates having to learn sopmething just to use the machine
 - Has no deep knowledge of programming, or even the computer
 - Sees the computer as a tool, not as a toy
 - Has little time to learn the internal workings of the computer
   or a program.

So I would hardly classify you as a "normal user".  Okay, fvwm is
a bit hard to configure anyway, but that is no good excuse to not
think about the most inept users too.

> And you say that most people with my knowledge of computers
> wouldn't be able to write more complex(?) fvwm functions?

No.

> Just how stupid you think normal users are?

Not stupid at all.  I think "normal users" are simply not
interested in programming.

> it's time to think of a new interface for the user.

I wonder how you would delete bindings without a binding specific
interface in a different language.

Bye

Dominik ^_^  ^_^

---

From: Grzegorz Nieweglowski <[email-masked]>
Date: Mon, 4 Aug 2003 23:01:18 +0200

> difference is that to learn lisp, you have to learn programming.

In Sawfish you could get very far without real knowledge of lisp. All
you needed was the ability to invoke functions and pass parameters. And
maybe know that head/tail thing in lists. Sawfish provided/provides
some predefined popular functions, similar to those in fvwm. And
sawfish-ui (~FvwmConsole) had tab-completion, so it was really
convenient.

> true for PERL, Python or shells.  They all require sound knowledge

You were talking about simple, primitive examples ("That will not take
the beginner very far"). So I could name a simple shell script,
consisting only of a list of external commands to execute. Or a perl
script with a couple of print's. If you meant something more
complicated, then please compare it with something equally complicated
in fvwm, for example

Current (!State 2)
KeepRc TestRc (Match) foo
TestRc (Match) bar

It depends on how complicated the example is. With easy examples most
languages are easy to understand. With "advanced" code snippets most
languages are difficult, fvwm is no exception.

> users want

Don't take it hard, but yes, sometimes at least. I could name some
examples, but since you put so much weight to it I won't. I bet
you would just see thing "in a different light". If you insist we can
continue this topic in less... public conditions. My private email is
hoppke _at_ lubuska.zapto.org

My apologies if that insults you, but it shouldn't. We are all humans
and with bigger projects it's never possible to please *everyone*.
Just as it is impossible to read the minds of others and predict with
100% accuracy "what they want". That would be much like the theory of
politics ;)

> You ranted about the scripting *engine*.  Only in the follow up mail
> you made it clear that you were talking about its *interface*, not the
> engine itself.  So don't condemn me for replying on the same level.

I'm sorry, but there is no (IMVHO) definition of an "engine" or
"interface" when it comes to fvwm. If I would say from the start that
I mean the "interface", you could've thought that I mean FvwmConsole (as
a module) or something similar. In your mind the "engine" is that what
*you* know best - C code implementation. For me the "engine" is the set
of commands, the syntax - what keeps the whole thing running. That what
is under the interface (and the interface is, of course, the GUI). All
a matter of semantics.

> And it is very, very flexible and a *great* debugging help.

I don't know about debugging, but I've never used that
"flexibility" since I use fvwm. In my opinion it may be a nice feature,
but I haven't found any use for it. I could imagine that this comes
handy with menu definitions (dynamical menus), but functions? And one
more thing: I would have found it easier if you could only continue
definitions after an AddTo* command. Right now if you interrupt
a definition you can continue by just using the "+ ". I don't know if
that's so great. Many times it meant troubles for me. The code got
appended to the "wrong" function or menu definition. I have never ever
needed this feature and I would have found it much easier if you would
always have to use a AddTo* after interrupting a definition to continue.

> eyes).

I thought it was designed that way. The "+" is allowed in names of
functions, so I thought that it's not a "reserved word". To give users
the possibility to do:

addtofunc foo+bar
+ I ...
+ I ...

function foo+bar

Although I didn't knew why anyone would want to allow a "plus" sing in
functions names...

>  - Has little time to learn the internal workings of the computer

Oh, you mean a "ZU" ;) That's what we call those people in my language.

> think about the most inept users too.

Yeah, but I really don't think that a ZU (or "normal user") will ever
want to use fvwm. Fvwm is to hard to use:

a. It comes with no fancy default configuration
b. Not that much eye-candy as in most popular WMs
c. No GUI configurators (those scripts that come installed by default
   can only setup a small subset of fvwm's features)
d. It's ugly like 1981 (by default, of course)
e. You have to download fvwm-themes to make it look somewhat "modern".
f. Sounds. No nice wizard to do the configuration, no support for esd or
   arts - and they are standards in the "normal user" computer worlds.
g. The manual page is too cryptic and too long, there are too many
   options to actually get a strong grip on the WM
h. Some (very important for the Normal User) things don't work:
   - tray icons. Mostly KDE or Gnome apps.
   - fullscreen maximizing. In mplayer, Mozilla, ...
   - no fancy panel (plain taskbars are prehistory)
i. ...

Really, I would be amazed if an Normal User would choose fvwm. All that
I know have removed it from their systems and installed something
easier. Less powerfull, but easier. WindowMaker is very popular, so is
IceWM. Then, let's not forget, Normal Users mostly use ready-set
Desktop Environments like KDE or Gnome, and I believe they won't
exchange Gnome's Metacity for FVWM.

IMO the only way for a Normal User to use fvwm is in larger networks,
where the user has no influence. Universities etc. But on such sites
fvwm is preconfigured by sysadmins, so you don't need to worry about
making fvwm "not so easy".

I admire what you're trying to do, but I think that fvwm is unusable (or
not tempting enough) for a Normal User unless he receives
a preconfigured version of this WM.

> interface in a different language.

You mean "keybindings"? In Sawfish there was a "table of bindings". It was
as if you would put all Key's and Mouse's into a table.

(...)
(Key,c,M,W,Close)
(Key,z,M,W,Minimize)
(Key,s,M,W,Shade)
(...)

Every row describes a binding. The row itself is split into fields which
can be separately analyzed if it's necessary.

The "binding specific interface" consisted of a synchronization
procedure between the table and WM's internals. You push a new row into
the table and a new binding comes to life. You remove a row, and
a binding get's wiped out. As you have normal acces to the list you can
pick specific rows just as you do it with data in lisp.

There was no other way to add a binding[1]. You simply had to place it
in a special table/variable. And because it was a normal table you could
modify it like a normal table. So there only needed to exist this
feedback pipe between the table and the WM, the developers didn't need
to think about all possible needs or wishes. This was done later by the
users themselfs. You want to make a function clearing the root context?
No problem, scan the table for "R" in fourth field and delete matching
rows.

[1] - well, there was also a convenience macro to do it quickly.

For Sawfish existed/exists a wiki with many custom functions, for people
who just can't write it on their own or want to publish something. With
this "open the internals" approach much load slipped off the developers.
Instead of patches for C code the users started to send in functions in
Lisp - easier to integrate and less prone to crash the WM (errors etc.
are caught by the interpreter).
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Grzegorz Nieweglowski <[email-masked]>
Date: Mon, 4 Aug 2003 15:40:45 +0200

Dominik Vogt wrote:
> Any decent kernel is clever enough not to load multiple copies of the
> same write-only data.

I'm using the linux kernel, 2.4.21.

Results of the "free" command with 100 instances of FvwmPager running:

         total       used       free     shared    buffers     cached
Mem:    224728     131148      93580          0          0      18396
-/+ buffers/cache: 112752     111976
Swap:    51192       1372      49820

And the same after "killall FvwmPager":

         total       used       free     shared    buffers     cached
Mem:    224728      70896     153832          0          0      18416
-/+ buffers/cache:  52480     172248
Swap:    51192       1372      49820

I guess that with 'a few hundreds' per module te amount of memory freed
after killing all those pagers should change by a couple of megabytes in
worst case , not by ~60MBs. And I believe these readings are correct
- starting more modules (200 and up) chewed up all of RAM and swap, and
the infamous OOM killer started killing processes.

Either it's my config, or running two pagers uses more ram than just "(1
FvwmPager) + (less than 1KB)"

>> And fvwm modules are quite big already.

I meant the memory usage, not executable size (and debug info never gets
loaded while executing a binary (except for running under debuggers),
right?)
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Ethan Blanton <[email-masked]>
Date: Mon, 4 Aug 2003 16:31:14 -0500

> > Any decent kernel is clever enough not to load multiple copies of the

Dominik is completely correct here.

[ snip numbers ]

> the infamous OOM killer started killing processes.

The point is that the memory consumed here is not consumed by either
the FvwmPager text (that is, executable data) itself or the minimal
bookkeeping required to load a second instance of the program.  It was
probably the actual run-time data required by each FvwmPager in order
to do its job -- this data is not likely to change significantly
whether each FvwmPager loads its own text or operates out of the same
text.  It is possible that some of this data could be shared between
multiple pagers running out of the same process ... it is also
possible that handling the contention for this sharing would
sufficiently complicate and enlarge the FvwmPager binary that the
_common_ case (one pager per X session) would actually use more
resources.  (I haven't looked, I do not know this for sure; it is
intended only to be an example showing that things are not always
black and white.)

Consider most of the other Fvwm modules, as well...  Exactly how many
concurrent instances do you typically run at one time?  I think you'll
find that this is not a large issue.

> FvwmPager) + (less than 1KB)"

It is guaranteed to be at least a few pages (4kB each on most 32-bit
architectures).  It is, however, still negligible for a desktop
system.

Ethan

-- 
"The Constitution shall never be construed to prevent the people of the
 United States who are peaceable citizens from keeping their own arms."
		-- Samuel Adams, 1788

---

From: Grzegorz Nieweglowski <[email-masked]>
Date: Tue, 5 Aug 2003 15:29:25 +0200

Ethan Blanton nawypisowywa³(a):
> resources.

I understand. But even so, something still seems wrong. Why is a module
like FvwmPager using so much memory?

> I think you'll find that this is not a large issue.

Well, a couple of megs, making fvwm one of the bigger WM's. I wanted to
get the words "negligible for a desktop system" - to show that adding an
perl/python/scheme/whatever interpreter would have no real influence on
memory performance - it would be like running another FvwmIconMan.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Tue, 05 Aug 2003 10:48:57 -0400

> FvwmPager) + (less than 1KB)"

Here is my calculation of what the pager uses.  This is on Solaris 8
using the "pmap" command.  This is the output, slightly reformattted:

3490:	/opt/public/src//fvwm/2.5.7/FvwmPager 10 7 none 4800003 1 0 1
00052000     16K read/write/exec   /opt/public/src/fvwm/2.5.7/FvwmPager
00056000     72K read/write/exec     [ heap ]
FF036000     24K read/write/exec   /usr/lib/libc.so.1
FF03C000      8K read/write/exec   /usr/lib/libc.so.1
FF072000      8K read/write/exec   /usr/openwin/lib/libdga.so.1
FF11A000     32K read/write/exec   /usr/lib/libnsl.so.1
FF122000     32K read/write/exec   /usr/lib/libnsl.so.1
FF154000      8K read/write/exec   /usr/lib/libmp.so.2
FF170000      8K read/write/exec     [ anon ]
FF21C000     24K read/write/exec   /usr/openwin/lib/libX11.so.4
FF254000      8K read/write/exec   /usr/lib/libm.so.1
FF27A000      8K read/write/exec   /usr/lib/libsocket.so.1
FF2A8000      8K read/write/exec   /usr/openwin/lib/libXext.so.0
FF2D4000      8K read/write/exec   /usr/openwin/lib/libICE.so.6
FF2D6000      8K read/write/exec   /usr/openwin/lib/libICE.so.6
FF2FA000      8K read/write/exec   /usr/openwin/lib/libSM.so.6
FF31C000      8K read/write/exec   /usr/lib/libz.so.1
FF366000      8K read/write/exec   /opt/public/lib/libpng.so.3.1.2.5
FF38C000     16K read/write/exec   /opt/public/lib/libXpm.so.4.10
FF3B0000      8K read/write/exec     [ anon ]
FF3E0000      8K read/write/exec   /usr/lib/ld.so.1
FFBE8000     32K read/write/exec     [ stack ]

            360K

00010000    208K read/exec         /opt/public/src/fvwm/2.5.7/FvwmPager
FEF70000     16K read/exec         /usr/platform/sun4u/lib/libc_psr.so.1
FEF80000    664K read/exec         /usr/lib/libc.so.1
FF050000     72K read/exec         /usr/openwin/lib/libdga.so.1
FF080000    552K read/exec         /usr/lib/libnsl.so.1
FF140000     16K read/exec         /usr/lib/libmp.so.2
FF180000    560K read/exec         /usr/openwin/lib/libX11.so.4
FF230000     88K read/exec         /usr/lib/libm.so.1
FF260000     40K read/exec         /usr/lib/libsocket.so.1
FF280000     96K read/exec         /usr/openwin/lib/libXext.so.0
FF2B0000     80K read/exec         /usr/openwin/lib/libICE.so.6
FF2E0000     40K read/exec         /usr/openwin/lib/libSM.so.6
FF300000     48K read/exec         /usr/lib/libz.so.1
FF330000    160K read/exec         /opt/public/lib/libpng.so.3.1.2.5
FF370000     56K read/exec         /opt/public/lib/libXpm.so.4.10
FF3A0000      8K read/exec         /usr/lib/libdl.so.1
FF3C0000    128K read/exec         /usr/lib/ld.so.1

           2832K

 total     3192K

The total memory is 3meg.
I separated that into read/write and read/exec.
The read/exec is common memory (its only used once no matter how
often the pager is loaded).  Of the 3meg, thats 2.8 meg thats common.
The balance is 360K.

So, I'd say that the each instance of the pager takes 360K.

Probably what is most important is how much of this actually resides
in memory.  That could be a lot less than 360K.

Another issue is how many libaries got mapped into memory that
I wasn't already using.  I this case, I think I have all of them
already mapped.

One of the nice things about Fvwm is how much memory the pager
consumes for me. (Zero, I don't use it.)

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