Subject: FVWM: Module development in c++ ?

From: Tomas <[email-masked]>
Date: Sun, 12 Oct 2003 14:17:30 +0200 (CEST)

Hello. I was missing some functionality (specifically saving the position
and size of windows) so I started to develop a module. The problem is that
I don't like C very much, so I tried to do it in c++, after hacking some
scripts and headers, which caused some compilation and linking errors.

So, my question is: is it worth the effort to try to make some sort of
c++-interface to the modules? I was thinking of doing it in that case, but
I ask of your opinions first since I'm not really into the code yet.
Because I believe that my problems could be solved this way, and also, it
could be a nice project :)

Additionally, in the configure-scripts I read that: "Actually, we don't
use it (c++) at _all_ anymore, since the only module that used it has been
removed.  It causes problems so we'll comment it out for now.  Hopefully
by the time we need it again autoconf will handle it better :-/ "
What are these problems? Is my project doomed, or could it be solved?

/Tomas

--
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: Dan Espen <[email-masked]>
Date: Sun, 12 Oct 2003 08:58:35 -0400

> What are these problems? Is my project doomed, or could it be solved?

As I remember, C++ worked, it was that the module wasn't worth the
extra portability issues.

I'd guess Perl would be the best language for a module like this.

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

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 12 Oct 2003 16:39:42 +0300

> could be a nice project :)

You should know the internals pretty well to consider to do such project.
You should also learn perllib thorouhly, because you will want to reuse
its class design (if you dislike C function approach). At this point, you
probably decide just to stick with Perl, because you will not be able to
find C++ equivalents for many elegant Perl solutions. In this regard, C++
is not much different from C.

> What are these problems? Is my project doomed, or could it be solved?

Dan already answered, but I may add some bits.

You may see how FvwmKb (use Google) solved this. I think it has its own
Makefile.

If you describe exactly what do you need to do in your module, it is
possible there is a solution without additional modules.

Regards,
Mikhael.

---

From: Tomas <[email-masked]>
Date: Sun, 12 Oct 2003 16:14:10 +0200 (CEST)

> I'd guess Perl would be the best language for a module like this.

I guess you're right, maybe I should consider Perl instead of digging to
deep into the internals just to get to use my favourite language.

Thanks
/Tomas

---

From: Tomas <[email-masked]>
Date: Sun, 12 Oct 2003 16:23:53 +0200 (CEST)

On Sun, 12 Oct 2003, Mikhael Goikhman wrote:
> > and size of windows) so I started to develop a module.
> [..]
> 

The thing is that I would like to select windows and choosing "Save
position/size" or something from a menu (or whatever), to save theyre
state in some kind of file. Next time the window opens, the window is
resized/moved to the saved state. I use FvwmEvent for this right now (with
inspiration from the FAQ), but I have to put all the window-names in the
fvwm config-file, I would like to simplify this a bit.

/Tomas

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 12 Oct 2003 17:57:50 +0300

> fvwm config-file, I would like to simplify this a bit.

It is not much longer to write a Perl module, but let's do it without it.

  DestroyFunc RestoreWindowGeometry
  AddToFunc   RestoreWindowGeometry
  Read saved-window-geometries Quiet

  DestroyModuleConfig FvwmEvent-NewWindow: *
  *FvwmEvent-NewWindow: add_window RestoreWindowGeometry

  AddToFunc StartFunction
  + I Module FvwmEvent FvwmEvent-NewWindow

  DestroyFunc SaveWindowGeometry
  AddToFunc   SaveWindowGeometry
  + I AddToFunc RestoreWindowGeometry
  + I + I ThisWindow ('$0') ResizeMove $1 $2 $3 $4
  + I Exec echo "+ I ThisWindow ('$0') ResizeMove $1 $2 $3 $4" >>$[FVWM_USERDIR]/saved-window-geometries

  Key F4 A CS Pick SaveWindowGeometry $[w.name] $[w.x] $[w.y] $[w.width] $[w.height]

Not tested, but it should work, I think. Press Ctrl-Shift-F4 to save the
current window geometry, it is restored automatically on the next launch.

To remove the old windows with the same name you may do something like:
Exec grep -v "ThisWindow ('$0')" file >file.new && mv file.new file; echo ..

This supposes window names do not include double quotes. To make it more
robust, write a module in Perl rather than relying on Exec+shell quotes
to work. If you ask me nicely I may write a Perl module for you doing
the same. But I don't really want to spoil your fun. :)

Regards,
Mikhael.

---

From: Tomas <[email-masked]>
Date: Sun, 12 Oct 2003 18:21:13 +0200 (CEST)

> the same. But I don't really want to spoil your fun. :)

Wow, thanks! That'll do for now. But I think I need to improve my
Perl-skills sometime, so it seems like a nice project to try when I have
the time.

/Tomas

---

From: Tomas Åkesson <[email-masked]>
Date: Fri, 17 Oct 2003 17:41:13 +0200 (CEST)

Ok, I said before that I planned to develop a module for saving of
window-position/size, so here we go. My Perl skills are not the best so if
you are interested, feel free to improve the code or make comments on it.

The module (FvwmSaveWindow) is found under the fvwm-section on my website:
http://radikal.ath.cx/software/

/Tomas

---

From: Marcin G?ogowski <[email-masked]>
Date: Sat, 18 Oct 2003 00:01:37 +0200

>you are interested, feel free to improve the code or make comments on it.
...
Thx :-)

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 18 Oct 2003 02:51:43 +0300

> The module (FvwmSaveWindow) is found under the fvwm-section on my website:

I took a short look (without running) at
  http://radikal.ath.cx/software/files/FvwmSaveWindow

I can't say you don't know Perl if you wrote such module in several days.
The module as it is now may probably be named FvwmMemorizeGeometry or so.

Some small notes that are hopefully intended to simplify your module.

1) You may use General::FileSystem to load/save/append file in one go.
You may probably also keep the whole config in memory (in hash) instead
of always loading/saving it from/to file.

2) You may use a single ResizeMove command to simplyify the module logic;
with "keep" arguments it may simulate both Move and Resize.

3) You may use ModuleConfig tracker to get the module configuration.

4) If you replace "Debug => $debugging," with "Debug => \$debugging,"
then this will also automagically work if you uncomment EnableOptions.

5) I see you (and Scott too) use this form to operate on a window:

  $module->send("WindowId $winId Move ...");

It is better (and a bit faster) to immediately define a window context:

  $module->send("Move ...", $winId);

6) You may omit the explicit module mask in the constructor if you wish,
but only in cvs versions.

7) In the future I hope that WindowList tracker (the only non functional
yet) will save you dozens of lines in your module. Of course it is pretty
difficult to come up with a perfect WindowList API that makes easier the
work on such completely different modules like FvwmWindowMenu, FvwmTabs
and FvwmSaveWindow, but I am working on this.

Regards,
Mikhael.

---

From: Tomas Åkesson <[email-masked]>
Date: Sun, 19 Oct 2003 15:18:05 +0200 (CEST)

Thanks for your input, I'll see to it when I have the time.
Some comments are below...
/Tomas

> then this will also automagically work if you uncomment EnableOptions.

What is ModuleConfig tracker anyway, and what is the difference between
this and EnableOptions? Are they two different ways of doing the same
thing, in that case what's best?

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 19 Oct 2003 22:20:30 +0300

> thing, in that case what's best?

These are pretty independent things, ModuleConfig tracker (see perllib
documentation) automatically gives you all "*YourModule: name value"
configuration, statical and dynamical.

EnableOptions gives you command line options, like --verbose --desk 2.
See FvwmPager or other modules that use both, options and module config.

Usually, the user preferences are defined using module configuration
and the things that may be different for different module instances are
passed as command line options.

Regards,
Mikhael.

---

From: Tomas Åkesson <[email-masked]>
Date: Wed, 22 Oct 2003 15:53:14 +0200 (CEST)

When my module (FvwmSaveWindow) is called from a menu or button (by the
use of SendToModule), I do this in my module-code:
$module->send("Send_WindowList");

This causes an event-handler being called:
$module->addHandler(M_WINDOW_NAME, sub {
    my ($module, $event) = @_;
    ...
});

My problem is that I would like to know some data (mainly position and
size) about the window which was selected when the
"Send_WindowList"-command was issued. I can't seem to find a reasonable
way to get this in the handler.
I tried to listen for M_CONFIGURE_WINDOW-event, but then I might get
another window's data since the focus may change during the time between
tha handler is called and the M_WINDOW_NAME-handler is executed.

I could maybe call the module with the window-id explicitly in the config:
SendToModule FvwmSaveWindow $winId "save"
(or however it would look like?) but I would rather do it in the 
module-code.

Hmm, hope you can figure out what I mean by all this.. guess my english
isn't so good, or maybe I'm a bit confused and tired, well well..
/Tomas

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 22 Oct 2003 15:32:00 +0000

> way to get this in the handler.

I think you do this correctly. The window size/position is passed using
M_ADD_WINDOW or M_CONFIGURE_WINDOW events, not M_WINDOW_NAME.

Continue with this, it's the only way. Another way will be using
WindowList tracker (but not very soon) that will hide all this black work
from you.

> (or however it would look like?) but I would rather do it in the

I am not sure what is your problem, you already get the window context of
SendToModule command in your code (M_STRING event).

If your module would be transient (not your case) you could run it from a
window context rather than from StartFunction. In this case the window
context of your module may be found in $module->{winId}.

Regards,
Mikhael.